attempting local merge of e1000 from RELENG_8 to RELENG_8_0

Charles Owens cowens at greatbaysoftware.com
Mon Apr 19 13:50:05 UTC 2010


Hello,

We're trying to backport the latest e1000 driver from the -STABLE branch
into our internal release that is based around the 8.0 security branch
(RELENG_8_0).  Specifically, we see some flakiness with the igb driver
on one of our hardware platforms that we're hoping the new driver will
address.  Our initial test with this custom kernel seems not quite
right, and I think a suggestion or two from someone more familiar with
this code could be a big help.

I merged in the driver code last Wednesday... in addition to all files
in sys/dev/e1000 I also brought in changes to these files:

    * sys/conf/files
    * sys/net/if.c
    * sys/net/if.h
    * sys/net/if_var.h
    * sys/net80211/ieee80211_ioctl.c
    * sys/sys/priv.h
    * sys/sys/sockio.h


More or less this amounts to this (admittedly simplistic) approach: 
bring in just enough to get it to compile.  Most changes were brought in
from -STABLE in full (so each affected file in our source tree now
matches STABLE, as of last Wednesday).

When we test the igb driver with this kernel, communication seems iffy,
and we're seeing this on the console:

igb0: Watchdog timeout -- resetting
igb0: Queue(1) tdh = 4, hw tdt = 4
igb0: TX(1) desc avail = 1020,Next TX to Clean = 0

On the upside, link-state detection (which was messed up in the 8.0
driver) now seems to work properly.

This morning I note that on Friday a number of additional "fixes" to
em/igb were MFC'd.  So... here are my questions:

    * Are the error messages likely related to the bugs fixed by these
      latest commits?  --or-- is it more likely a problem with how we
      did the merge?
    * Should we expect to succeed at all, or are there other bits of new
      plumbing (changes since 8.0 was cut) that the newer driver relies
      on somehow, such that this is an iffy proposition?
    * Has the e1000 driver in -STABLE now mostly stabilized... or is
      additional engineering expected in the near term?


Any and all assistance is greatly appreciated!

Thanks,

Charles

-- 
 Charles Owens
 Great Bay Software, Inc.



More information about the freebsd-net mailing list