[etherlab-users] r8169 patch - packet timeout boot failures

[Jeroen Van den Keybus]

It would be very useful to know whether e.g. the interfaces ended up in
100M half duplex or so. Is there a link in those cases ? What's the first
EtherCAT station ? Maybe it doesn't handle autoneg properly during its
reset phase ?

J.



2013/12/3 Raz <raziebe at gmail.com>

> hey
> Problem happens with intel e1000e as well as realtek.  One way to bypass
> it is to boot the master while the ethernet-ethercat cable is disconnected,
> and once master claims the interface , connect this cable. This appears to
> work.
> So , There some sort of of initialisation error.
>
>
> On Mon, Dec 2, 2013 at 11:32 AM, Raz <raziebe at gmail.com> wrote:
>
>> I still do not have a scenario. it "sometimes" happens. The
>> -DRTL8169_DEBUG is something i did not know, so i will check and see. thx
>>
>>
>> On Mon, Dec 2, 2013 at 11:27 AM, Jeroen Van den Keybus <
>> jeroen.vandenkeybus at gmail.com> wrote:
>>
>>> Is there a difference between cold and warm boot ? Does unloading the ec
>>> driver, loading/unloading the stock r8169 driver and then reloading the ec
>>> driver work better ? Same scenario but with Realtek drivers (r8168) ? Also
>>> perhaps compile with -DRTL8169_DEBUG ?
>>>
>>> Just some thoughts.
>>>
>>> J.
>>>
>>>
>>> 2013/12/2 Raz <raziebe at gmail.com>
>>>
>>>> The timeouts happens after the system boots and not while slaves are in
>>>> in OP mode. So my transmit is irrelevant here, even though a transmit
>>>> happens only from a single thread of through an ioctl ( SDO reads and so
>>>> on..)
>>>>
>>>>
>>>>
>>>>
>>>> On Mon, Dec 2, 2013 at 11:01 AM, Jeroen Van den Keybus <
>>>> jeroen.vandenkeybus at gmail.com> wrote:
>>>>
>>>>>
>>>>>> 1. why do you disable the rtl8169_phy_timer  timer ?
>>>>>>
>>>>>
>>>>> The rtl8169_phy_timer is regularly polled in ec_poll instead.
>>>>>
>>>>>
>>>>>
>>>>>> 2.  In rtl_hw_start_8168 : why do disable RTL_W16(IntrMask,
>>>>>> tp->intr_event); ?
>>>>>>
>>>>>>
>>>>> The drivers are all non-blocking and interrupt-free. All work that
>>>>> interrupt handlers normally do is done in ec_poll instead.
>>>>>
>>>>> If you cannot send packets anymore, I suspect that you may have
>>>>> overrun the tx queue, i.e. sent a packet before the previous one has been
>>>>> completed. You're also not calling the ethercat transmission functions from
>>>>> different threads, right ?
>>>>>
>>>>>
>>>>> thank you
>>>>>> raz
>>>>>>
>>>>>> --
>>>>>> https://sites.google.com/site/ironspeedlinux/
>>>>>>
>>>>>> _______________________________________________
>>>>>> etherlab-users mailing list
>>>>>> etherlab-users at etherlab.org
>>>>>> http://lists.etherlab.org/mailman/listinfo/etherlab-users
>>>>>>
>>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>> https://sites.google.com/site/ironspeedlinux/
>>>>
>>>
>>>
>>
>>
>> --
>> https://sites.google.com/site/ironspeedlinux/
>>
>
>
>
> --
> https://sites.google.com/site/ironspeedlinux/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20131203/b0a12c42/attachment-0003.htm>