Jesse Brandeburg wrote:
> On 10/22/06, Martin J. Bligh <mbligh@mbligh.org> wrote:
>> Martin J. Bligh wrote:
>> > I'm getting a lot of these type of errors if I run 2.6.18. If
>> > I run the standard Ubuntu Dapper kernel, I don't get them.
>> > What do they indicate?
> 
> Hi Martin, they indicate that you're getting transmit hangs.  Means
> your hardware is having issues with some of the buffers it is being
> handed.  Because the TDH and TDT noted below are not equal, it means
> the hardware is hung processing buffers that the driver gave to it.
> 
> We need the standard bug report particulars,

Sure.

> lspci -vv, 

0000:00:0a.0 Ethernet controller: Intel Corporation 82546EB Gigabit 
Ethernet Con
troller (Copper) (rev 01)
         Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Step
ping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium 
 >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
         Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes)
         Interrupt: pin A routed to IRQ 5
         Region 0: Memory at ef020000 (64-bit, non-prefetchable) [size=128K]
         Region 4: I/O ports at a000 [size=64]
         Capabilities: [dc] Power Management version 2
                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot
+,D3cold+)
                 Status: D0 PME-Enable- DSel=0 DScale=1 PME-
         Capabilities: [e4]      Capabilities: [f0] Message Signalled 
Interrupts:
  64bit+ Queue=0/0 Enable-
                 Address: 0000000000000000  Data: 0000

0000:00:0a.1 Ethernet controller: Intel Corporation 82546EB Gigabit 
Ethernet Con
troller (Copper) (rev 01)
         Subsystem: Intel Corporation PRO/1000 MT Dual Port Server Adapter
         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
ParErr- Step
ping- SERR- FastB2B-
         Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium 
 >TAbort- <TAbort
- <MAbort- >SERR- <PERR-
         Latency: 32 (63750ns min), Cache Line Size: 0x08 (32 bytes)
         Interrupt: pin B routed to IRQ 11
         Region 0: Memory at ef000000 (64-bit, non-prefetchable) [size=128K]
         Region 4: I/O ports at a400 [size=64]
         Capabilities: [dc] Power Management version 2
                 Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA 
PME(D0+,D1-,D2-,D3hot
+,D3cold+)
                 Status: D0 PME-Enable- DSel=0 DScale=1 PME-
         Capabilities: [e4]      Capabilities: [f0] Message Signalled 
Interrupts:
  64bit+ Queue=0/0 Enable-
                 Address: 0000000000000000  Data: 0000

> cat /proc/interrupts, 

            CPU0
   0:  146271373          XT-PIC  timer
   1:     179459          XT-PIC  i8042
   2:          0          XT-PIC  cascade
   5:    1975991          XT-PIC  ehci_hcd:usb2, VIA8237, eth0
   6:          2          XT-PIC  floppy
  10:          0          XT-PIC  uhci_hcd:usb4, uhci_hcd:usb5, 
uhci_hcd:usb6
  11:          0          XT-PIC  ehci_hcd:usb1, uhci_hcd:usb3, 
uhci_hcd:usb7, uhci_hcd:usb8
  12:    2758142          XT-PIC  i8042
  14:    6344745          XT-PIC  ide0
  15:   20014468          XT-PIC  ide1
NMI:          0
LOC:  146264664
ERR:      52805

> dmesg

Did that bit already.

> ethtool -e eth0,

root@titus:/usr/local/autotest/bin # ethtool -e eth0
Offset          Values
------          ------
0x0000          00 07 e9 09 0b 08 30 05 ff ff ff ff ff ff ff ff
0x0010          44 a9 03 98 0b 46 11 10 86 80 10 10 86 80 68 34
0x0020          0c 00 10 10 00 00 02 21 c8 18 ff ff ff ff ff ff
0x0030          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0040          0c c3 61 78 04 50 02 21 c8 08 ff ff ff ff ff ff
0x0050          ff ff ff ff ff ff ff ff ff ff ff ff ff ff 02 06
0x0060          2c 00 00 40 07 11 00 00 2c 00 00 40 ff ff ff ff
0x0070          ff ff ff ff ff ff ff ff ff ff ff ff ff ff 4f 29
0x0080          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0090          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00a0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00b0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00c0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00d0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00e0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x00f0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0100          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0110          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0120          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0130          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0140          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0150          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0160          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0170          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0180          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x0190          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01a0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01b0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01c0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01d0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01e0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
0x01f0          ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

> and maybe output of
> dmidecode, etc. 

Attached.

> only a little.  There are so many different pieces of e1000 hardware
> and so few specifics in this report that I'll be able to tell you lots
> more when you get us the info requested.

Thanks. Not sure if the bug wasn't there in earlier kernels, or if we
just weren't printing anything.

M.