[etherlab-users] r8169 patch - packet timeout boot failures
Raz
raziebe at gmail.com
Tue Dec 3 10:48:13 CET 2013
I do not have ethtool over the ethercat device as it is removed. How can I
tell ? eth0 is 100Mbps but it is my public interface. eth1 is my ethercat
interface.
There is always a link. the first slave is a drive, not an io device .
This drive is running xilinix with port stack and ip core of beckhof.
I am trying to debug now the realtek driver, let see...
On Tue, Dec 3, 2013 at 11:36 AM, Jeroen Van den Keybus <
jeroen.vandenkeybus at gmail.com> wrote:
> 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/
>>
>
>
--
https://sites.google.com/site/ironspeedlinux/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.etherlab.org/pipermail/etherlab-users/attachments/20131203/e47782ff/attachment-0003.htm>
More information about the Etherlab-users
mailing list