[etherlab-dev] e1000e driver for 3.2.x kernel

[Gavin Lambert]

Quoth Jürgen Kunz:
> Attached you'll find the e1000e driver for 3.2.x kernel versions. 
> I've tested it on a 64-bit Debian Squeeze with 3.2.0-rt backports 
> kernel (=RT-Preempt).

As recently mentioned over on the users list, I'm having a problem with this
driver.

I'm using the same distribution (Debian Squeeze x64) but I'm trying to use
the vanilla 3.2.31 kernel (plus PREEMPT_RT rt47 patches).

(The in-kernel e1000e driver plus the "generic" driver appear to work fine,
but I'm presuming this has less functionality or performance.)

The 3.2.31 in-kernel sources for the driver don't quite match the -orig
sources provided in the hg tip, so there have been some minor changes but
nothing that seems directly relevant to my problem.

I've found two separate issues so far; the first is that initialisation
aborts due to an interrupt failure:
> ec_e1000e 0000:01:00.0: irq 41 for MSI/MSI-X
> ec_e1000e 0000:01:00.0: (unregistered net_device): MSI interrupt 
> test failed, using legacy interrupt.

I've traced this to netdev-3.2-ethercat.c line 3869 (inside e1000_open),
where it calls e1000_request_irq (which does nothing for EC devices for some
reason) and then tries to test that the interrupt works, which of course it
won't.  I've tried working around this by putting this whole block into an
"if (!adapter->ecdev)" block; this seems to avoid the error but I'm not sure
if it has any negative consequences.

(Note that my line numbers will probably not quite match yours as I'm
looking at a repatched version of the 3.2.31 sources; but these problems
happen with the original hg tip driver too.)

The second issue is that I get this every couple of seconds:
> ec_e1000e 0000:01:00.0: (unregistered net_device): Reset adapter

And as a result, communication is impossible since it keeps resetting.  I've
traced this to e1000_watchdog_task, specifically line 4563 just after the
"we've lost link" comment block.  The link-test logic here looks wrong;
specifically, it is only checking the tx_ring in the !ecdev case.  Rewriting
this condition "properly" appears to get me past this issue, at least to the
point at which low-speed bus scans etc seem to be working again.  I haven't
yet tested under high-speed conditions.

I can send through patches for the fixes and for the 3.2.0 -> 3.2.31 update;
how would you prefer them?
  1. entire file contents
  2. all-in-one patch from current hg tip to my modified version
  3. separate patches from current hg tip to 3.2.31 basic, and from that to
"fixed" version