svn commit: r267935 - head/sys/dev/e1000 (with work around?)

[Yonghyeon PYUN]

On Sun, Sep 14, 2014 at 04:23:02PM -0400, Mike Tancsa wrote:
> On 9/14/2014 4:08 PM, Eric Joyner wrote:
> >I'll try to, but I can't promise anything soon -- there's a lot of
> >10gig/40gig stuff to do.
> 
> Thanks Eric. At first, I thought it was just a certain variant of the 
> em, but I have found at least two that get wedged.  Its pretty easy to 
> reproduce.
> 
> One other thing I noticed is that the README states,
> 
> "TSO is not supported on 82547 and 82544-based adapters, as well as 
> older adapters."
> 

If my memory serve me right, this is correct.

> Yet, by default its enabled with the driver.  Perhaps a check to just 
> disable TSO for NICs not supported automatically ?  The other NIC I can 

Yes, it should.

> recreate the problem with is
> 
> root at backup3:/usr/home/mdtancsa # pciconf -lvcb em0
> em0 at pci0:0:25:0:        class=0x020000 card=0x34ec8086 chip=0x10ef8086 
> rev=0x05 hdr=0x00
>     vendor     = 'Intel Corporation'
>     device     = '82578DM Gigabit Network Connection'
>     class      = network
>     subclass   = ethernet
>     bar   [10] = type Memory, range 32, base 0xb1a00000, size 131072, 
> enabled
>     bar   [14] = type Memory, range 32, base 0xb1a25000, size 4096, enabled
>     bar   [18] = type I/O Port, range 32, base 0x2040, size 32, enabled
>     cap 01[c8] = powerspec 2  supports D0 D3  current D0
>     cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message
>     cap 13[e0] = PCI Advanced Features: FLR TP
> root at backup3:/usr/home/mdtancsa #
> 
> The odd thing however is that all works fine with the previous rev that 
> was in the tree.
> 

It looks like previous drivers have a code that conditionally
enables TSO for 'MAC rev > 82544 && MAC rev != 82547'.  It seems
em(4) in CURRENT blindly set TSO for all controllers.