Enclosed the patch for the "reset adapter" issue of the e1000e driver for 3.2 kernel. It avoids continuously calling e1000_reset_task when EtherCAT is used and link is down.
Regards, Jürgen Kunz Am 05.02.2013 07:54, schrieb Jürgen Kunz: > Hello Gavin, > > thanks for the hint, I'll have a look for Florians patch and your > post. I applied Florians "Link detection" patch for e1000e driver 3.4 > to the 3.2er driver (see attatchment), it solves the link detection > issue here. > > Regards, > Jürgen Kunz > > Am 05.02.2013 06:26, schrieb Gavin Lambert: >> >> Hi Jürgen & Daniel, >> >> >> >> I have a fix for the first issue in my local copy of the driver (see >> my post to the dev list on 25 October for specific details). I have >> seen the second issue but not chased down a fix for it yet. >> >> >> >> Also I just noticed that Florian updated the drivers on 4 January >> (posted in response to my message; I haven't checked whether it >> includes the same fix or not). I haven't had a chance to test the >> new version myself yet but maybe it will help in your case too? >> >> >> >> Regards, >> >> Gavin Lambert >> >> >> >> *From:*[email protected] >> [mailto:[email protected]] *On Behalf Of *Jürgen Kunz >> *Sent:* Tuesday, 5 February 2013 18:16 >> *To:* Daniel Helmick >> *Cc:* [email protected] >> *Subject:* Re: [etherlab-users] e1000e driver still not working with >> 3.2 kernel with latest stable-1.5 branch? >> >> >> >> Hello Daniel, >> >> I am using this combination for a while now, with 32- and 64-bit >> versions of the 3.2er Debian RT-Kernel. If there is a EtherCAT device >> connected to the computer, the driver works fine. >> There are two issues in this driver version, if there are no EtherCAT >> devices connected. The first, the one you mentioned here, is when the >> EtherCAT Master starts up with no device connected, then the >> network-adapter is continously reseted until a device is connected. >> It may hang the computer if no device is connected for a while. >> The second issue is that when the link is plugged off, the link state >> is not updated. Unfortunately, I did not have time yet to correct >> these issues. >> >> Greetings, >> Jürgen Kunz >> >> Am 05.02.2013 01:59, schrieb Daniel Helmick: >> >> Has anyone else gotten this combination of driver and kernel to work? >> >> Here's the /var/log/messages output when I start the ethercat master: >> >> [ 869.854110] EtherCAT: Master driver 1.5.1 9cdd7669dc0b >> [ 869.854252] EtherCAT: 1 master waiting for devices. >> [ 869.944866] e1000e 0000:04:00.0: PCI INT A disabled >> [ 869.948134] ec_e1000e: EtherCAT-capable Intel(R) PRO/1000 >> Network Driver - 1.5.1-k-EtherCAT >> [ 869.948138] ec_e1000e: Copyright(c) 1999 - 2011 Intel Corporation. >> [ 869.948202] ec_e1000e 0000:04:00.0: Disabling ASPM L0s >> [ 869.948261] ec_e1000e 0000:04:00.0: PCI INT A -> GSI 17 >> (level, low) -> IRQ 17 >> [ 869.948530] ec_e1000e 0000:04:00.0: setting latency timer to 64 >> [ 869.951386] ec_e1000e 0000:04:00.0: irq 65 for MSI/MSI-X >> [ 869.951393] ec_e1000e 0000:04:00.0: irq 66 for MSI/MSI-X >> [ 869.951397] ec_e1000e 0000:04:00.0: irq 67 for MSI/MSI-X >> [ 870.120739] EtherCAT: Accepting 68:05:CA:10:C0:82 as main >> device for master 0. >> [ 870.197588] EtherCAT 0: Starting EtherCAT-IDLE thread. >> [ 870.197651] ec_e1000e 0000:04:00.0: (unregistered net_device): >> (PCI Express:2.5GT/s:Width x1) 68:05:ca:10:c0:82 >> [ 870.197656] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Intel(R) PRO/1000 Network Connection >> [ 870.197687] ec_e1000e 0000:04:00.0: (unregistered net_device): >> MAC: 3, PHY: 8, PBA No: E46981-008 >> [ 870.197825] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Reset adapter >> [ 872.196168] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Reset adapter >> [ 874.196169] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Reset adapter >> [ 876.196159] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Reset adapter >> [ 878.196162] ec_e1000e 0000:04:00.0: (unregistered net_device): >> Reset adapter >> >> >> And the reset adapter message occurs every 2 seconds until I stop >> the ethercat master. >> >> Thanks, >> Dan >> >> >> >> _______________________________________________ >> >> etherlab-users mailing list >> >> [email protected] <mailto:[email protected]> >> >> http://lists.etherlab.org/mailman/listinfo/etherlab-users >> >> >> >> -- >> Dipl.-Inform. Jürgen Kunz >> >> Technische Universität Darmstadt <http://www.tu-darmstadt.de> >> FG Simulation, Systemoptimierung und Robotik >> <http://www.sim.tu-darmstadt.de> >> Hochschulstr. 10 >> 64289 Darmstadt >> >> Tel.: ++49 (0) 6151-16-70383 >> Fax: ++49 (0) 6151-16-6648 >> E-Mail: kunz(at)sim.tu-darmstadt.de >> Homepage: http://www.sim.tu-darmstadt.de >> > > -- > Dipl.-Inform. Jürgen Kunz > > Technische Universität Darmstadt <http://www.tu-darmstadt.de> > FG Simulation, Systemoptimierung und Robotik > <http://www.sim.tu-darmstadt.de> > Hochschulstr. 10 > 64289 Darmstadt > > Tel.: ++49 (0) 6151-16-70383 > Fax: ++49 (0) 6151-16-6648 > E-Mail: kunz(at)sim.tu-darmstadt.de > Homepage: http://www.sim.tu-darmstadt.de > > > _______________________________________________ > etherlab-users mailing list > [email protected] > http://lists.etherlab.org/mailman/listinfo/etherlab-users -- Dipl.-Inform. Jürgen Kunz Technische Universität Darmstadt <http://www.tu-darmstadt.de> FG Simulation, Systemoptimierung und Robotik <http://www.sim.tu-darmstadt.de> Hochschulstr. 10 64289 Darmstadt Tel.: ++49 (0) 6151-16-70383 Fax: ++49 (0) 6151-16-6648 E-Mail: kunz(at)sim.tu-darmstadt.de Homepage: http://www.sim.tu-darmstadt.de
diff -r 9cdd7669dc0b devices/e1000e/netdev-3.2-ethercat.c
--- a/devices/e1000e/netdev-3.2-ethercat.c Thu Jan 10 17:36:41 2013 +0100
+++ b/devices/e1000e/netdev-3.2-ethercat.c Tue Feb 05 09:19:10 2013 +0100
@@ -4546,9 +4544,8 @@
e1000e_update_adaptive(&adapter->hw);
- if ((adapter->ecdev && !ecdev_get_link(adapter->ecdev))
- || (!adapter->ecdev && (!netif_carrier_ok(netdev) &&
- (e1000_desc_unused(tx_ring) + 1 < tx_ring->count)))) {
+ if (!adapter->ecdev && (!netif_carrier_ok(netdev) &&
+ (e1000_desc_unused(tx_ring) + 1 < tx_ring->count))) {
/*
* We've lost link, so the controller stops DMA,
* but we've got queued Tx work that's never going
<<attachment: kunz.vcf>>
_______________________________________________ etherlab-users mailing list [email protected] http://lists.etherlab.org/mailman/listinfo/etherlab-users
