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 <[email protected]> > 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 <[email protected]> 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 < >> [email protected]> 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 <[email protected]> >>> >>>> 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 < >>>> [email protected]> 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 >>>>>> [email protected] >>>>>> 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/ >
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
