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

[Jeroen Van den Keybus]

Perhaps try hooking up a normal eth interface to the drive and see what the
autoneg comes up with using ethtool. In the past, I have had trouble
interfacing an FPGA IP core to a PC Ethernet card when the core was hard
wired to 100M FD instead of advertising this using autoneg. The PC card
tried to autoneg and then fell back to 100M HD.

You could try testing with an EK1100 in between the PC and the drive.

J.


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

> 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/8a8dc8f3/attachment-0003.htm>