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