8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

Michael Grollman <[email protected]> :

No html please.

[...]

Can you simply check with the latest -rc that 'lspci -vx' correctly displays the pci registers of the 8102 when the device does not work ?

Ueimor

Francois,

Per instructions, I built an 2.6.26-rc8 system on the target Intel hardware, and was able to re-recreate the intermittent failure of the 8201. When in failure mode, the lspci -vx' display of the pci registers of the 8102 is as follows:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev ff) (prog-if ff)
!!! Unknown header type 7f
00: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
10: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
20: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff
30: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff

When the same hardware, running the same kernel, lspci -vx' display of the pci registers of the 8102 is as follows:

01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8101E PCI Express Fast Ethernet controller (rev 02)
Subsystem: Intel Corporation Unknown device 0001
Flags: bus master, fast devsel, latency 0, IRQ 16
I/O ports at 1000 [size=256]
Memory at 30100000 (64-bit, non-prefetchable) [size=4K]
Memory at 30000000 (64-bit, prefetchable) [size=64K]
Expansion ROM at 30020000 [disabled] [size=128K]
Capabilities: [40] Power Management version 3
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/0 Enable-
Capabilities: [70] Express Endpoint IRQ 1
Capabilities: [ac] MSI-X: Enable- Mask- TabSize=2
Capabilities: [cc] Vital Product Data
00: ec 10 36 81 07 00 10 00 02 00 00 02 08 00 00 00
10: 01 10 00 00 00 00 00 00 04 00 10 30 00 00 00 00
20: 0c 00 00 30 00 00 00 00 00 00 00 00 86 80 01 00
30: 00 00 fe ff 40 00 00 00 00 00 00 00 0b 01 00 00

Note as well, uname -a = "Linux nscibus 2.6.26-rc8 #1 PREEMPT Thu Jun 26 20:02:39 GMT 2008 i686 GNU/Linux"

I list the full dmesg for this system during failure modem below, as reference only.

Let me know if there is anything else I can do to collect information on this situation.

Merci,'

- Michael Grollman

---------------------------------

_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
ACPI: IRQ0 used by override.
ACPI: IRQ2 used by override.
ACPI: IRQ9 used by override.
Enabling APIC mode: Flat. Using 1 I/O APICs
Using ACPI (MADT) for SMP configuration information
Allocating PCI resources starting at 30000000 (gap: 20000000:d0000000)
PM: Registered nosave memory: 000000000008f000 - 00000000000a0000
PM: Registered nosave memory: 00000000000a0000 - 00000000000e0000
PM: Registered nosave memory: 00000000000e0000 - 0000000000100000
PM: Registered nosave memory: 000000001f525000 - 000000001f52d000
PM: Registered nosave memory: 000000001f5bd000 - 000000001f5c1000
PM: Registered nosave memory: 000000001f660000 - 000000001f6f0000
PM: Registered nosave memory: 000000001f6f3000 - 000000001f6ff000
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 127762
Kernel command line: root=/dev/sdb2
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 1596.171 MHz processor.
Console: colour VGA+ 80x25
console [tty0] enabled
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 503208k/515072k available (2142k kernel code, 10272k reserved, 858k data, 204k init, 0k highmem) virtual kernel memory layout:

   fixmap  : 0xfffa7000 - 0xfffff000   ( 352 kB)
   pkmap   : 0xff800000 - 0xffc00000   (4096 kB)
   vmalloc : 0xe0000000 - 0xff7fe000   ( 503 MB)
   lowmem  : 0xc0000000 - 0xdf700000   ( 503 MB)
     .init : 0xc03f2000 - 0xc0425000   ( 204 kB)
     .data : 0xc0317878 - 0xc03ee418   ( 858 kB)
     .text : 0xc0100000 - 0xc0317878   (2142 kB)

Checking if this processor honours the WP bit even in supervisor mode...Ok.
CPA: page pool initialized 1 of 1 pages preallocated
Calibrating delay using timer specific routine.. 3194.16 BogoMIPS (lpj=1597082) Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 24K
CPU: L2 cache: 512K
using mwait in idle threads.
CPU: Intel(R) Atom(TM) CPU 230 @ 1.60GHz stepping 02
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 0k freed
ACPI: Core revision 20080321
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
net_namespace: 628 bytes
NET: Registered protocol family 16
No dock devices found.
ACPI: bus type pci registered
PCI: Found Intel Corporation 945G/GZ/P/PL Express Memory Controller Hub without MMCONFIG support.
PCI: Using configuration type 1 for base access
Setting up standard PCI resources
ACPI: EC: Look up EC in DSDT
ACPI: Interpreter enabled
ACPI: (supports S0 S1 S3 S4 S5)
ACPI: Using IOAPIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
pci 0000:00:1f.0: Force enabled HPET at 0xfed00000
pci 0000:00:1f.0: quirk: region 0400-047f claimed by ICH6 ACPI/GPIO/TCO
pci 0000:00:1f.0: quirk: region 0500-053f claimed by ICH6 GPIO
PCI: Transparent bridge - 0000:00:1e.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P32_._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX0._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX2._PRT]
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PEX3._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 *9 10 11 12)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 9 10 *11 12)
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 7 9 10 11 12) *0, disabled.
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 *9 10 11 12)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 9 *10 11 12)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
ACPI: bus type pnp registered
pnp: PnP ACPI: found 11 devices
ACPI: ACPI bus type pnp unregistered
SCSI subsystem initialized
libata version 3.00 loaded.
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
PCI: Using ACPI for IRQ routing
hpet clockevent registered
system 00:01: iomem range 0xf0000000-0xf3ffffff could not be reserved
system 00:01: iomem range 0xfed13000-0xfed13fff could not be reserved
system 00:01: iomem range 0xfed14000-0xfed17fff could not be reserved
system 00:01: iomem range 0xfed18000-0xfed18fff could not be reserved
system 00:01: iomem range 0xfed19000-0xfed19fff could not be reserved
system 00:01: iomem range 0xfed1c000-0xfed1ffff could not be reserved
system 00:01: iomem range 0xfed20000-0xfed3ffff could not be reserved
system 00:01: iomem range 0xfed45000-0xfed99fff could not be reserved
system 00:01: iomem range 0xc0000-0xdffff could not be reserved
system 00:01: iomem range 0xe0000-0xfffff could not be reserved
system 00:06: ioport range 0x500-0x53f has been reserved
system 00:06: ioport range 0x400-0x47f has been reserved
system 00:06: ioport range 0x680-0x6ff has been reserved
PCI: Bridge: 0000:00:1c.0
IO window: 1000-1fff
MEM window: 0x30100000-0x301fffff
PREFETCH window: 0x0000000030000000-0x00000000300fffff
PCI: Bridge: 0000:00:1c.2
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1c.3
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
PCI: Bridge: 0000:00:1e.0
IO window: disabled.
MEM window: disabled.
PREFETCH window: disabled.
ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 17 (level, low) -> IRQ 17
PCI: Setting latency timer of device 0000:00:1c.0 to 64
ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1c.2 to 64
ACPI: PCI Interrupt 0000:00:1c.3[D] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1c.3 to 64
PCI: Setting latency timer of device 0000:00:1e.0 to 64
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 5, 131072 bytes)
TCP bind hash table entries: 16384 (order: 4, 65536 bytes)
TCP: Hash tables configured (established 16384 bind 16384)
TCP reno registered
NET: Registered protocol family 1
checking if image is initramfs... it is
Freeing initrd memory: 2357k freed
msgmni has been set to 988
io scheduler noop registered
io scheduler cfq registered (default)
pci 0000:00:02.0: Boot video device
PCI: Setting latency timer of device 0000:00:1c.0 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.0:pcie00]
Allocate Port Service[0000:00:1c.0:pcie02]
PCI: Setting latency timer of device 0000:00:1c.2 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.2:pcie00]
Allocate Port Service[0000:00:1c.2:pcie02]
PCI: Setting latency timer of device 0000:00:1c.3 to 64
assign_interrupt_mode Found MSI capability
Allocate Port Service[0000:00:1c.3:pcie00]
Allocate Port Service[0000:00:1c.3:pcie02]
input: Power Button (FF) as /class/input/input0
ACPI: Power Button (FF) [PWRF]
input: Sleep Button (CM) as /class/input/input1
ACPI: Sleep Button (CM) [SLPB]
ACPI: ACPI0007:00 is registered as cooling_device0
Serial: 8250/16550 driver $Revision: 1.90 $ 2 ports, IRQ sharing enabled
Switched to high resolution mode on CPU 0
serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
brd: module loaded
Uniform Multi-Platform E-IDE driver
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
ICH7: IDE controller (0x8086:0x27df rev 0x01) at PCI slot 0000:00:1f.1
ACPI: PCI Interrupt 0000:00:1f.1[A] -> GSI 18 (level, low) -> IRQ 18
ICH7: not 100% native mode: will probe irqs later
ICH7: IDE port disabled
ide0: BM-DMA at 0x20b0-0x20b7
Probing IDE interface ide0...
hda: CD-RW IDE5232, ATAPI CD/DVD-ROM drive
hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4
hda: host side 80-wire cable detection failed, limiting max speed to UDMA33
hda: UDMA/33 mode selected
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide_generic: please use "probe_mask=0x3f" module parameter for probing all legacy ISA IDE ports
ide_generic: I/O resource 0x1F0-0x1F7 not free.
ide_generic: I/O resource 0x170-0x177 not free.
hda: ATAPI 52X CD-ROM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.20
usbmon: debugfs is not available
ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.7 to 64
ehci_hcd 0000:00:1d.7: EHCI Host Controller
ehci_hcd 0000:00:1d.7: new USB bus registered, assigned bus number 1
ehci_hcd 0000:00:1d.7: debug port 1
PCI: cache line size of 32 is not supported by device 0000:00:1d.7
ehci_hcd 0000:00:1d.7: irq 23, io mem 0x302c4000
ehci_hcd 0000:00:1d.7: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 8 ports detected
ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
USB Universal Host Controller Interface driver v3.0
ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 23 (level, low) -> IRQ 23
PCI: Setting latency timer of device 0000:00:1d.0 to 64
uhci_hcd 0000:00:1d.0: UHCI Host Controller
uhci_hcd 0000:00:1d.0: new USB bus registered, assigned bus number 2
uhci_hcd 0000:00:1d.0: irq 23, io base 0x00002080
usb usb2: configuration #1 chosen from 1 choice
hub 2-0:1.0: USB hub found
hub 2-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 19 (level, low) -> IRQ 19
PCI: Setting latency timer of device 0000:00:1d.1 to 64
uhci_hcd 0000:00:1d.1: UHCI Host Controller
uhci_hcd 0000:00:1d.1: new USB bus registered, assigned bus number 3
uhci_hcd 0000:00:1d.1: irq 19, io base 0x00002060
usb usb3: configuration #1 chosen from 1 choice
hub 3-0:1.0: USB hub found
hub 3-0:1.0: 2 ports detected
ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 18
PCI: Setting latency timer of device 0000:00:1d.2 to 64
uhci_hcd 0000:00:1d.2: UHCI Host Controller
uhci_hcd 0000:00:1d.2: new USB bus registered, assigned bus number 4
uhci_hcd 0000:00:1d.2: irq 18, io base 0x00002040
usb usb4: configuration #1 chosen from 1 choice
hub 4-0:1.0: USB hub found
hub 4-0:1.0: 2 ports detected
usb 1-3: new high speed USB device using ehci_hcd and address 2
ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:00:1d.3 to 64
uhci_hcd 0000:00:1d.3: UHCI Host Controller
uhci_hcd 0000:00:1d.3: new USB bus registered, assigned bus number 5
uhci_hcd 0000:00:1d.3: irq 16, io base 0x00002020
usb usb5: configuration #1 chosen from 1 choice
hub 5-0:1.0: USB hub found
hub 5-0:1.0: 2 ports detected
usb 1-3: configuration #1 chosen from 1 choice
Initializing USB Mass Storage driver...
scsi0 : SCSI emulation for USB Mass Storage devices
usb-storage: device found at 2
usb-storage: waiting for device to settle before scanning
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
PNP: PS/2 Controller [PNP0303:PS2K,PNP0f03:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 KBD port at 0x60,0x64 irq 1
serio: i8042 AUX port at 0x60,0x64 irq 12
mice: PS/2 mouse device common for all mice
input: AT Translated Set 2 keyboard as /class/input/input2
padlock: VIA PadLock not detected.
padlock: VIA PadLock Hash Engine not detected.
TCP cubic registered
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Using IPI Shortcut mode
Freeing unused kernel memory: 204k freed
input: ImPS/2 Generic Wheel Mouse as /class/input/input3
r8169 Gigabit Ethernet driver 2.2LK-NAPI loaded
ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
PCI: Setting latency timer of device 0000:01:00.0 to 64
r8169 0000:01:00.0: unknown MAC (27a00000)
r8169 0000:01:00.0: no MSI. Back to INTx.
eth0: RTL8169 at 0xe0020000, 00:1c:c0:45:de:94, XID 24a00000 IRQ 16
ata_piix 0000:00:1f.2: version 2.12
ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 19 (level, low) -> IRQ 19
ata_piix 0000:00:1f.2: MAP [ P0 P2 P1 P3 ]
PCI: Setting latency timer of device 0000:00:1f.2 to 64
scsi1 : ata_piix
scsi2 : ata_piix
ata1: SATA max UDMA/133 cmd 0x20c8 ctl 0x20ec bmdma 0x20a0 irq 19
ata2: SATA max UDMA/133 cmd 0x20c0 ctl 0x20e8 bmdma 0x20a8 irq 19
ata1.00: ATA-8: WDC WD600BEVS-22UST0, 01.01A01, max UDMA/133
ata1.00: 117210240 sectors, multi 16: LBA48 NCQ (depth 0/32)
ata1.00: configured for UDMA/133
scsi 1:0:0:0: Direct-Access ATA WDC WD600BEVS-22 01.0 PQ: 0 ANSI: 5
Driver 'sd' needs updating - please use bus_type methods
sd 1:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA sd 1:0:0:0: [sda] 117210240 512-byte hardware sectors (60012 MB)
sd 1:0:0:0: [sda] Write Protect is off
sd 1:0:0:0: [sda] Mode Sense: 00 3a 00 00
sd 1:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
sda: sda1 sda2
sd 1:0:0:0: [sda] Attached SCSI disk
scsi 0:0:0:0: Direct-Access OEI-USB2 Ultra Disk Drive 2.22 PQ: 0 ANSI: 0
sd 0:0:0:0: [sdb] 1981728 512-byte hardware sectors (1015 MB)
sd 0:0:0:0: [sdb] Write Protect is off
sd 0:0:0:0: [sdb] Mode Sense: 0b 00 00 08
sd 0:0:0:0: [sdb] Assuming drive cache: write through
sd 0:0:0:0: [sdb] 1981728 512-byte hardware sectors (1015 MB)
sd 0:0:0:0: [sdb] Write Protect is off
sd 0:0:0:0: [sdb] Mode Sense: 0b 00 00 08
sd 0:0:0:0: [sdb] Assuming drive cache: write through
sdb: sdb1 sdb2 sdb3 sdb4
sd 0:0:0:0: [sdb] Attached SCSI removable disk
usb-storage: device scan complete
ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 22 (level, low) -> IRQ 22
PCI: Setting latency timer of device 0000:00:1b.0 to 64
hda_codec: Unknown model for ALC662, trying auto-probe from BIOS...
intel_rng: Firmware space is locked read-only. If you can't or
intel_rng: don't want to disable this in firmware setup, and if
intel_rng: you are certain that your system has a functional
intel_rng: RNG, try using the 'no_fwh_detect' option.
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.03 (30-Apr-2008)
iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
natsemi dp8381x driver, version 2.1, Sept 11, 2006
originally by Donald Becker <[email protected]>
2.4.x kernel port by Jeff Garzik, Tjeerd Mulder
ieee80211_crypt: registered algorithm 'NULL'
device-mapper: ioctl: 4.13.0-ioctl (2007-10-18) initialised: [email protected] EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
EXT2-fs warning (device sda1): ext2_fill_super: mounting ext3 filesystem as ext2 EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
r8169: eth0: link up
r8169: eth0: link up
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
warning: `ntpd' uses 32-bit capabilities (legacy support in use)
eth0: no IPv6 routers present

(linux-pci Cced)

Michael Grollman <[email protected]> :
[...]

Bad mojo.

Can you reproduce the failure of the driver or lspci when you boot the kernel with "pci=nommconf" (assuming CONFIG_PCI_MMCONFIG is set in your .config) or "pci=conf1" (if CONFIG_PCI_DIRECT is instead).

[...]

The (gzipped) content of your .config.

Kasper, could you check if you have the same symptoms with 2.6.26-rc8 (once your rendering is finished of course) ?

Ueimor

Francois,

The failure can be reproduced with:

pci=nommconf

and also with:

pci=conf1

I attached a gzip of the .config used for this build. It should be very close to 'right out of the box.'

- Michael

Michael Grollman
National Scientific Corporation
8361 East Evans Rd Ste 106
Scottsdale, AZ.  85260  USA
Voice: +1-480-948-8324 x 303
Fax: +1-480-483-8893
[email protected]
www.nsct.info

Mmm. All f's means that the device has fallen off the bus. Nothing is responding when we ask the device about it's config space. What do you do to get this device into this state?

Intel are signing my paycheques ... these opinions are still mine
"Bill, look, we understand that you're interested in selling us this
operating system, but compare it to ours.  We can't possibly take such
a retrograde step."

Matthew,

The only remedy I have found to date is a system reboot, sometimes a soft one will work, sometimes a full
power down is needed. It may take a few boots to get it happy. If I can get it to boot with the Realtek working OK, the system does not seem to fail, even after hours of use. So either it comes up working, or it does not.

But I am open to any ideas to try and correct! I have an extra motherboard around, if you guys think it may be in this particular unit's hardware.

- Michael

-----Original Message-----
From: Matthew Wilcox [mailto:[email protected]]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; [email protected]; Kasper Sandberg; [email protected]; [email protected]
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

8201.

Mmm. All f's means that the device has fallen off the bus. Nothing is responding when we ask the device about it's config space. What do you do to get this device into this state?

--
Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."

This is *not* just specific to your hardware. I've encountered it on two other platforms that have RTL8102's. I posted some comments in another thread the other day.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Thursday, June 26, 2008 9:58 PM
To: 'Matthew Wilcox'; 'Francois Romieu'
Cc: [email protected]; 'Kasper Sandberg'; [email protected]; [email protected]
Subject: RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

Matthew,

The only remedy I have found to date is a system reboot, sometimes a soft
one will work, sometimes a full
power down is needed. It may take a few boots to get it happy. If I can
get it to boot with the Realtek working OK, the system does not seem to fail, even after hours of use. So either it comes up working, or it does
not.

But I am open to any ideas to try and correct! I have an extra motherboard
around, if you guys think it may be in this particular unit's hardware.

- Michael

-----Original Message-----
From: Matthew Wilcox [mailto:[email protected]]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; [email protected]; Kasper Sandberg; [email protected]; [email protected]
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in
Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

the
8201.

Mmm. All f's means that the device has fallen off the bus. Nothing is responding when we ask the device about it's config space. What do you do
to get this device into this state?

--
Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde
step."

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

I can pass additionally on the following observation, if it helps some more clever than I:

In a boot where the RTL8102 is going to work, just prior to DHCP initiation in the boot process, it will print:

	r8169: eth0: link up
	r8169: eth0: link up

Exactly twice.

Whereas, in any boot where it is on the road to failure, it will print it exactly once:

	r8169: eth0: link up

No idea what it means, but the observation is very consistent. The dmesg log also supports this. I attach a dmesg.gz log from a successful 2.5.26-rc8 boot, with eth0 working, to support this observation.

-Michael

-----Original Message-----
From: [email protected] [mailto:[email protected]]
Sent: Thursday, June 26, 2008 8:25 PM
To: [email protected]; [email protected]; [email protected]
Cc: [email protected]; [email protected]; [email protected]; [email protected]
Subject: RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

This is *not* just specific to your hardware. I've encountered it on two other platforms that have RTL8102's. I posted some comments in another thread the other day.

-----Original Message-----
From: [email protected] [mailto:[email protected]] On Behalf Of [email protected]
Sent: Thursday, June 26, 2008 9:58 PM
To: 'Matthew Wilcox'; 'Francois Romieu'
Cc: [email protected]; 'Kasper Sandberg'; [email protected]; [email protected]
Subject: RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

Matthew,

The only remedy I have found to date is a system reboot, sometimes a soft one will work, sometimes a full power down is needed. It may take a few boots to get it happy. If I can get it to boot with the Realtek working OK, the system does not seem to fail, even after hours of use. So either it comes up working, or it does not.

But I am open to any ideas to try and correct! I have an extra motherboard around, if you guys think it may be in this particular unit's hardware.

- Michael

-----Original Message-----
From: Matthew Wilcox [mailto:[email protected]]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; [email protected]; Kasper Sandberg; [email protected]; [email protected]
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)

the
8201.

Mmm. All f's means that the device has fallen off the bus. Nothing is responding when we ask the device about it's config space. What do you do to get this device into this state?

--
Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step."

--
To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [email protected] More majordomo info at
http://vger.kernel.org/majordomo-info.html

Sorry for the delay, i had to do an onsite thing in another country, so i first see your message now.

Would it be okay if i took rc9 instead? also, i saw you posted a set of patches to sync more with realteks code, is this something you would like me to test too, or aswell? (remember, i have the 8111c).

Btw, a thought just crossed my mind as to a possible reason why this might be happening, i was googling around, and it seems the TWO nic's are supposed to have some sort of hardware bonding thing, could it be because such stuff isnt handled?

mvh.
Kasper Sandberg

Kasper:

Particularly try the patch that I posted to the list. It solved the ifup (and resume) failures for me on two platforms using that chipset.

Regards

Mario Limonciello
*Dell | Linux Engineering*
[email protected]

Mario,

Apologies in advance for my ignorance.

When you write below about 'the patch' and 'the list,' can you be a bit more specific, particularly about which list you posted it to?

Also, I think Kasper's question below related to, was the patch you used to fix your 8169 issues now part of rc9, or is it still independent of the main tree? For those like me not used to be bleeding edge, its cleaner to just snag the rc candidate than to try the hand patch method.

Any insight you can offer is appreciated.

Cheers,

- Michael

Michael Grollman
National Scientific Corporation
8361 East Evans Rd Ste 106
Scottsdale, AZ.  85260  USA
Voice: +1-480-948-8324 x 303
Fax: +1-480-483-8893
[email protected]
www.nsct.info

Hi Michael:

Sorry, I posted this to the list I received your message from ([email protected]). I don't believe it's been applied by anyone as of yet.

Regards

Mario Limonciello
*Dell | Linux Engineering*
[email protected]

Mario,

I think patch noted below worked to resolve the remaining issues I have been experiencing with with realtek Ethernet port on the Intel D945GCLF motherboard (Atom Mini-ITX). I tested with the 2.6.26-rc9 kernel this time, although I applied the patch to the 2.6.25's r8169.c.

Likely it is my inexperience, but the patch as I copied it from the [email protected] posting did not apply cleanly using the patch tool, so I had to hand-apply the patch code changes to 8169.c. However, once this was done and compiled, the Ethernet began working much better. I have not been able so far to make it fail, even more than two dozen or more cold and warm resets. Previous failure rate was at least during 50% of resets, so it is at a minimum much more stable on startup.

Much thanks!

- Michael

Michael Grollman
National Scientific Corporation
8361 East Evans Rd Ste 106
Scottsdale, AZ.  85260  USA
Voice: +1-480-948-8324 x 303
Fax: +1-480-483-8893
[email protected]
www.nsct.info

Sorry, i am not subscribed to netdev or pci list, could you post here aswell?

Kasper:

http://marc.info/?l=linux-netdev&m=121498012600793&w=2

Regards

Mario Limonciello
*Dell | Linux Engineering*
[email protected]

I just tested it. It fails.

after a few unloads/loads the lspci -x output is garbled again. the funny thing is (i have a dual nic board) its random which one that breaks..

Francois, i tested your patch,
http://userweb.kernel.org/~romieu/r8169/2.6.26-rc9/20080710-r8169-test.patch against .26 and it WORKS. with all the other tests i've done, ~5 unloads/loads is more than enough to trigger it, i just did 50 on your patch, and it functions.

Now i can have both msi and apic on.. Thanks alot.

Do you have plans to get this merged?

Is there any chance this helps with the famous 8101 problems, e.g.
http://bugzilla.kernel.org/show_bug.cgi?id=6807 ?

There is a typo in the description of 91ba1a976c214766b5ee8c6d17086903c10f6405 (serie should be series I think).

Greetings,

Eike

Kasper:

Interesting that it failed for you though. I was able to run through a script of 200x rmmod/modprobe without any trouble when that patch was applied.

Regards

Mario Limonciello
*Dell | Linux Engineering*
[email protected]

Well are you sure it actually catches my nics?

i have 8111c:

05:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev
02)
Subsystem: Giga-byte Technology Unknown device [1458:e000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 376
        Region 0: I/O ports at c000 [size=256]
        Region 2: Memory at e9010000 (64-bit, prefetchable) [size=4K]
        Region 4: Memory at e9000000 (64-bit, prefetchable) [size=64K]
        [virtual] Expansion ROM at e9020000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1

+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Address: 00000000fee0f00c Data: 416e
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 4096 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
TransPend-

                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,

Latency L0 <512ns, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: r8169
Kernel modules: r8169
00: ec 10 68 81 07 04 10 00 02 00 00 02 08 00 00 00
10: 01 c0 00 00 00 00 00 00 0c 00 01 e9 00 00 00 00
20: 0c 00 00 e9 00 00 00 00 00 00 00 00 58 14 00 e0
30: 00 00 00 00 40 00 00 00 00 00 00 00 0a 01 00 00

06:00.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller [10ec:8168] (rev
02)
Subsystem: Giga-byte Technology Unknown device [1458:e000]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-

        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 375
        Region 0: I/O ports at d000 [size=256]
        Region 2: Memory at e9110000 (64-bit, prefetchable) [size=4K]
        Region 4: Memory at e9100000 (64-bit, prefetchable) [size=64K]
        [virtual] Expansion ROM at e9120000 [disabled] [size=64K]
        Capabilities: [40] Power Management version 3
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA PME(D0+,D1

+,D2+,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] Message Signalled Interrupts: Mask- 64bit+
Queue=0/1 Enable+
Address: 00000000fee0f00c Data: 4176
Capabilities: [70] Express (v1) Endpoint, MSI 01
DevCap: MaxPayload 256 bytes, PhantFunc 0, Latency L0s
<512ns, L1 <8us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop- MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+
TransPend-

                LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1,

Latency L0 <512ns, L1 <64us
ClockPM+ Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- Retrain-
CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
Capabilities: [b0] MSI-X: Enable- Mask- TabSize=2
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data <?>
Capabilities: [100] Advanced Error Reporting <?>
Capabilities: [140] Virtual Channel <?>
Capabilities: [160] Device Serial Number 00-00-00-00-00-00-00-00 Kernel driver in use: r8169
Kernel modules: r8169
00: ec 10 68 81 07 04 10 00 02 00 00 02 08 00 00 00
10: 01 d0 00 00 00 00 00 00 0c 00 11 e9 00 00 00 00
20: 0c 00 10 e9 00 00 00 00 00 00 00 00 58 14 00 e0
30: 00 00 00 00 40 00 00 00 00 00 00 00 0b 01 00 00

Either way, the patchset from Francois seems to fix it, With this in mind, do we actually know exactly what causes it?

Kasper:

If I was to guess (I didn't actually work out which one yours identifies as), most likely your NIC isn't caught in my check for MAC_VER_13 or MAC_VER_16, but Francois's patch has:

- dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
- RTL_W8(0x82, 0x01);
+ if (tp->mac_version <= RTL_GIGA_MAC_VER_06) {
+ dprintk("Set MAC Reg C+CR Offset 0x82h = 0x01h\n");
+ RTL_W8(0x82, 0x01);
+ }

Which I've got indirectly but checking for 13 & 16.

Regards

Mario Limonciello
*Dell | Linux Engineering*
[email protected]

Mario Limonciello <[email protected]> :
[...]

+1

(actually this change was contributed by Marcus Sundberg: see the Signed-off-by and/or the patch named 0003-r8169-avoid-thrashing-PCI-conf-space-above-RTL_GIGA.patch)

I doubt that it will break anybody's 8101 (resp. 8102) but I would welcome a report from a 8101/8102 owner before sending it upstream.

Sorry for disturbing linux-pci.

Ueimor

Yeah, this change will definetly be good news to lots of realtek pci express owners, googling for this issue myself i found that alot of people are having it, and finding it difficult/annoying to grab 8168 from realteks site, not to mention often compatibility issues, so this is a very welcome fix :D

Rolf Eike Beer <[email protected]> :
[...]

Yes, it is worth a try.

Ueimor

Did Francois's patch ever make it upstream? I recently tested against a stock debian sid kernel based on 2.6.26-5, and although my tests were not exhaustive, it seemed that the 8169 failure mode was still present.

Michael Grollman
National Scientific Corporation
8361 East Evans Rd Ste 106
Scottsdale, AZ.  85260  USA
Voice: +1-480-948-8324 x 303
Fax: +1-480-483-8893
[email protected]
www.nsct.info