Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 19 Apr 2010 09:50:01 -0400
From:      Charles Owens <cowens@greatbaysoftware.com>
To:        freebsd-net@freebsd.org
Cc:        Seth Jeacopello <sethj@greatbaysoftware.com>
Subject:   attempting local merge of e1000 from RELENG_8 to RELENG_8_0
Message-ID:  <4BCC5F89.3000907@greatbaysoftware.com>

next in thread | raw e-mail | index | archive | help
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.




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BCC5F89.3000907>