* 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
@ 2008-06-24 23:27 Michael Grollman
0 siblings, 0 replies; 25+ messages in thread
From: Michael Grollman @ 2008-06-24 23:27 UTC (permalink / raw)
To: netdev
(This is a newbie reporting the problem, so take it with a grain of
salt, to be sure.)
Patch of http://lkml.org/lkml/2008/4/17/298 seems to fix the boot-up
modprobe crash related to r8169 Intermittent Issue With RTL8102E Chipset
in Intel's New D945GCLF Atom Board. However, the r8169 still only seems
to work with this motherboard / realtek combo a certain percentage of
the time. I have found the best luck when unplugging the power supply
for 5 minutes, and then bring it up cold, thought his was also not
perfect. Warm boots, then r8169 driver will load, but not work
correctly all the time.
I have done most of this testing in 2.6.25-5. The port led's do come
on, its just that the driver will (apparently) not pass packets
correctly, including DHCP packets.
Bounced this off some Intel guys, who had no special ideas at this point
(see thread
http://softwarecommunity.intel.com/isn/Community/en-US/forums/thread/30257590.aspx).
Cheers,
- Michael
Below is a dmesg of it in failure mode:
pic_id[0x00] enabled)
Processor #0 7:12 APIC version 20
ACPI: LAPIC (acpi_id[0x02] lapic_id[0x01] enabled)
Processor #1 7:12 APIC version 20
WARNING: NR_CPUS limit of 1 reached. Processor ignored.
ACPI: LAPIC (acpi_id[0x03] lapic_id[0x82] disabled)
ACPI: LAPIC (acpi_id[0x04] lapic_id[0x83] disabled)
ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1])
ACPI: LAPIC_NMI (acpi_id[0x02] dfl dfl lint[0x1])
ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23
ACPI: INT_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/sda1
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.154 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: 503288k/515072k available (2108k kernel code, 10184k reserved,
823k data, 208k 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 : 0xc03e0000 - 0xc0414000 ( 208 kB)
.data : 0xc030f3f9 - 0xc03dd3d8 ( 823 kB)
.text : 0xc0100000 - 0xc030f3f9 (2108 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.13 BogoMIPS
(lpj=1597066)
Mount-cache hash table entries: 512
CPU: L1 I cache: 32K, L1 D cache: 24K
CPU: L2 cache: 512K
using mwait in idle threads.
Compat vDSO mapped to ffffe000.
CPU: Intel(R) Atom(TM) CPU 230 @ 1.60GHz stepping 02
Checking 'hlt' instruction... OK.
Freeing SMP alternatives: 0k freed
ACPI: Core revision 20070126
ENABLING IO-APIC IRQs
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
net_namespace: 540 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
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
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a
report
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
checking if image is initramfs... it is
Freeing initrd memory: 2349k freed
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, BIOS settings: hda:PIO, hdb:PIO
Probing IDE interface ide0...
Probing IDE interface ide0...
Probing IDE interface ide1...
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 1
NET: Registered protocol family 17
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
Using IPI Shortcut mode
Freeing unused kernel memory: 208k 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
kjournald starting. Commit interval 5 seconds
EXT3-fs: mounted filesystem with ordered data mode.
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...
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
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.
ACPI: PCI Interrupt 0000:00:1f.3[B] -> GSI 19 (level, low) -> IRQ 19
Real Time Clock Driver v1.12ac
iTCO_vendor_support: vendor-support=0
iTCO_wdt: Intel TCO WatchDog Timer Driver v1.02 (26-Jul-2007)
iTCO_wdt: Found a ICH7 or ICH7R TCO device (Version=2, TCOBASE=0x0460)
iTCO_wdt: initialized. heartbeat=30 sec (nowayout=0)
EXT3 FS on sda1, internal journal
natsemi dp8381x driver, version 2.1, Sept 11, 2006
originally by Donald Becker <becker@scyld.com>
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:
dm-devel@redhat.com
*r8169: eth0: link up*
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
warning: `dnsmasq' uses 32-bit capabilities (legacy support in use)
eth0: no IPv6 routers present
EXT3 FS on sda1, internal journal
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
[not found] <4861800B.90703@nscus.com>
@ 2008-06-25 21:31 ` Francois Romieu
2008-06-26 21:08 ` Michael Grollman
0 siblings, 1 reply; 25+ messages in thread
From: Francois Romieu @ 2008-06-25 21:31 UTC (permalink / raw)
To: Michael Grollman; +Cc: netdev
Michael Grollman <mgrollman@nscus.com> :
> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
No html please.
[...]
> Patch of <a class="moz-txt-link-freetext" href="http://lkml.org/lkml/2008/4/17/298">http://lkml.org/lkml/2008/4/17/298</a> seems to fix the boot-up
> modprobe crash related to r8169 Intermittent Issue With RTL8102E
> Chipset in Intel's New D945GCLF Atom Board. However, the r8169 still
> only seems to work with this motherboard / realtek combo a certain
> percentage of the time. I have found the best luck when unplugging the
> power supply for 5 minutes, and then bring it up cold, thought his was
> also not perfect. Warm boots, then r8169 driver will load, but not
> work correctly all the time.<br>
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-25 21:31 ` 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem) Francois Romieu
@ 2008-06-26 21:08 ` Michael Grollman
2008-06-26 21:59 ` Francois Romieu
0 siblings, 1 reply; 25+ messages in thread
From: Michael Grollman @ 2008-06-26 21:08 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev
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
Francois Romieu wrote:
>
>
> [...]
>
>> Patch of <a class="moz-txt-link-freetext" href="http://lkml.org/lkml/2008/4/17/298">http://lkml.org/lkml/2008/4/17/298</a> seems to fix the boot-up
>> modprobe crash related to r8169 Intermittent Issue With RTL8102E
>> Chipset in Intel's New D945GCLF Atom Board. However, the r8169 still
>> only seems to work with this motherboard / realtek combo a certain
>> percentage of the time. I have found the best luck when unplugging the
>> power supply for 5 minutes, and then bring it up cold, thought his was
>> also not perfect. Warm boots, then r8169 driver will load, but not
>> work correctly all the time.<br>
>>
>
> 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 ?
>
>
---------------------------------
_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 <becker@scyld.com>
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:
dm-devel@redhat.com
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-26 21:08 ` Michael Grollman
@ 2008-06-26 21:59 ` Francois Romieu
2008-06-26 22:27 ` Michael Grollman
` (2 more replies)
0 siblings, 3 replies; 25+ messages in thread
From: Francois Romieu @ 2008-06-26 21:59 UTC (permalink / raw)
To: Michael Grollman; +Cc: netdev, Kasper Sandberg, akpm, linux-pci
(linux-pci Cced)
Michael Grollman <mgrollman@nscus.com> :
[...]
> 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
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).
[...]
> Let me know if there is anything else I can do to collect information on
> this situation.
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-26 21:59 ` Francois Romieu
@ 2008-06-26 22:27 ` Michael Grollman
2008-06-27 2:35 ` Matthew Wilcox
2008-07-07 12:53 ` Kasper Sandberg
2 siblings, 0 replies; 25+ messages in thread
From: Michael Grollman @ 2008-06-26 22:27 UTC (permalink / raw)
To: Francois Romieu; +Cc: netdev, linux-pci
[-- Attachment #1: Type: text/plain, Size: 1679 bytes --]
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
Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
>
>> 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
>>
>
> 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).
>
> [...]
>
>> Let me know if there is anything else I can do to collect information on
>> this situation.
>>
>
> 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) ?
>
>
--
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
mgrollman@nscus.com
www.nsct.info
[-- Attachment #2: config.2.6.26r8.gz --]
[-- Type: application/x-gzip, Size: 16076 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-26 21:59 ` Francois Romieu
2008-06-26 22:27 ` Michael Grollman
@ 2008-06-27 2:35 ` Matthew Wilcox
2008-06-27 2:58 ` mgrollman
2008-07-07 12:53 ` Kasper Sandberg
2 siblings, 1 reply; 25+ messages in thread
From: Matthew Wilcox @ 2008-06-27 2:35 UTC (permalink / raw)
To: Francois Romieu
Cc: Michael Grollman, netdev, Kasper Sandberg, akpm, linux-pci
On Thu, Jun 26, 2008 at 11:59:18PM +0200, Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
> > 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
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."
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-27 2:35 ` Matthew Wilcox
@ 2008-06-27 2:58 ` mgrollman
2008-06-27 3:25 ` Mario_Limonciello
0 siblings, 1 reply; 25+ messages in thread
From: mgrollman @ 2008-06-27 2:58 UTC (permalink / raw)
To: 'Matthew Wilcox', 'Francois Romieu'
Cc: netdev, 'Kasper Sandberg', akpm, linux-pci
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:matthew@wil.cx]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; netdev@vger.kernel.org; Kasper Sandberg;
akpm@linux-foundation.org; linux-pci@vger.kernel.org
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in
Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another
Problem)
On Thu, Jun 26, 2008 at 11:59:18PM +0200, Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
> > 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
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."
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-27 2:58 ` mgrollman
@ 2008-06-27 3:25 ` Mario_Limonciello
2008-06-27 4:44 ` Michael Grollman
0 siblings, 1 reply; 25+ messages in thread
From: Mario_Limonciello @ 2008-06-27 3:25 UTC (permalink / raw)
To: mgrollman, matthew, romieu; +Cc: netdev, lkml, akpm, linux-pci
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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of mgrollman@nscus.com
Sent: Thursday, June 26, 2008 9:58 PM
To: 'Matthew Wilcox'; 'Francois Romieu'
Cc: netdev@vger.kernel.org; 'Kasper Sandberg';
akpm@linux-foundation.org; linux-pci@vger.kernel.org
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:matthew@wil.cx]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; netdev@vger.kernel.org; Kasper Sandberg;
akpm@linux-foundation.org; linux-pci@vger.kernel.org
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset
in
Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another
Problem)
On Thu, Jun 26, 2008 at 11:59:18PM +0200, Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
> > 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
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 majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 25+ messages in thread
* RE: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-27 3:25 ` Mario_Limonciello
@ 2008-06-27 4:44 ` Michael Grollman
0 siblings, 0 replies; 25+ messages in thread
From: Michael Grollman @ 2008-06-27 4:44 UTC (permalink / raw)
To: Mario_Limonciello, matthew, romieu; +Cc: netdev, lkml, akpm, linux-pci
[-- Attachment #1: Type: text/plain, Size: 3997 bytes --]
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: Mario_Limonciello@Dell.com [mailto:Mario_Limonciello@Dell.com]
Sent: Thursday, June 26, 2008 8:25 PM
To: mgrollman@nscus.com; matthew@wil.cx; romieu@fr.zoreil.com
Cc: netdev@vger.kernel.org; lkml@metanurb.dk; akpm@linux-foundation.org;
linux-pci@vger.kernel.org
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: netdev-owner@vger.kernel.org [mailto:netdev-owner@vger.kernel.org]
On Behalf Of mgrollman@nscus.com
Sent: Thursday, June 26, 2008 9:58 PM
To: 'Matthew Wilcox'; 'Francois Romieu'
Cc: netdev@vger.kernel.org; 'Kasper Sandberg'; akpm@linux-foundation.org;
linux-pci@vger.kernel.org
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:matthew@wil.cx]
Sent: Thursday, June 26, 2008 7:35 PM
To: Francois Romieu
Cc: Michael Grollman; netdev@vger.kernel.org; Kasper Sandberg;
akpm@linux-foundation.org; linux-pci@vger.kernel.org
Subject: Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in
Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another
Problem)
On Thu, Jun 26, 2008 at 11:59:18PM +0200, Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
> > 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
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 majordomo@vger.kernel.org More majordomo info at
http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: dmesg-2.6.26r8.realtek-working.gz --]
[-- Type: application/x-gzip, Size: 5117 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-06-26 21:59 ` Francois Romieu
2008-06-26 22:27 ` Michael Grollman
2008-06-27 2:35 ` Matthew Wilcox
@ 2008-07-07 12:53 ` Kasper Sandberg
2008-07-07 15:15 ` Mario Limonciello
2 siblings, 1 reply; 25+ messages in thread
From: Kasper Sandberg @ 2008-07-07 12:53 UTC (permalink / raw)
To: Francois Romieu; +Cc: Michael Grollman, netdev, akpm, linux-pci
On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
> (linux-pci Cced)
>
> Michael Grollman <mgrollman@nscus.com> :
> [...]
> > 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
>
> 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).
>
> [...]
> > Let me know if there is anything else I can do to collect information on
> > this situation.
>
> 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) ?
>
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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-07 12:53 ` Kasper Sandberg
@ 2008-07-07 15:15 ` Mario Limonciello
2008-07-09 17:05 ` Michael Grollman
2008-07-11 13:35 ` Kasper Sandberg
0 siblings, 2 replies; 25+ messages in thread
From: Mario Limonciello @ 2008-07-07 15:15 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Francois Romieu, Michael Grollman, netdev, akpm, linux-pci
[-- Attachment #1: Type: text/plain, Size: 1162 bytes --]
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
Kasper Sandberg wrote:
> On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
>
> 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
>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-07 15:15 ` Mario Limonciello
@ 2008-07-09 17:05 ` Michael Grollman
2008-07-09 17:31 ` Mario Limonciello
2008-07-11 13:35 ` Kasper Sandberg
1 sibling, 1 reply; 25+ messages in thread
From: Michael Grollman @ 2008-07-09 17:05 UTC (permalink / raw)
To: Mario Limonciello
Cc: Kasper Sandberg, Francois Romieu, netdev, akpm, linux-pci
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
Mario Limonciello wrote:
> 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
>
> Kasper Sandberg wrote:
>
>> On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
>>
>> 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
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>> the body of a message to majordomo@vger.kernel.org
>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>
>>
>
>
--
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
mgrollman@nscus.com
www.nsct.info
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-09 17:05 ` Michael Grollman
@ 2008-07-09 17:31 ` Mario Limonciello
2008-07-09 23:31 ` Michael Grollman
0 siblings, 1 reply; 25+ messages in thread
From: Mario Limonciello @ 2008-07-09 17:31 UTC (permalink / raw)
To: mgrollman; +Cc: Kasper Sandberg, Francois Romieu, netdev, akpm, linux-pci
[-- Attachment #1: Type: text/plain, Size: 2064 bytes --]
Hi Michael:
Sorry, I posted this to the list I received your message from
(netdev@vger.kernel.org). I don't believe it's been applied by anyone
as of yet.
Regards
Michael Grollman wrote:
> 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
>
> Mario Limonciello wrote:
>> 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
>>
>> Kasper Sandberg wrote:
>>
>>> On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
>>> 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
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
>
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-09 17:31 ` Mario Limonciello
@ 2008-07-09 23:31 ` Michael Grollman
0 siblings, 0 replies; 25+ messages in thread
From: Michael Grollman @ 2008-07-09 23:31 UTC (permalink / raw)
To: Mario Limonciello
Cc: Kasper Sandberg, Francois Romieu, netdev, akpm, linux-pci
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
netdev@vger.kernel.org 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
Mario Limonciello wrote:
> Hi Michael:
>
> Sorry, I posted this to the list I received your message from
> (netdev@vger.kernel.org). I don't believe it's been applied by anyone
> as of yet.
>
> Regards
>
> Michael Grollman wrote:
>
>> 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
>>
>> Mario Limonciello wrote:
>>
>>> 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
>>>
>>> Kasper Sandberg wrote:
>>>
>>>
>>>> On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
>>>> 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
>>>>
>>>> --
>>>> To unsubscribe from this list: send the line "unsubscribe netdev" in
>>>> the body of a message to majordomo@vger.kernel.org
>>>> More majordomo info at http://vger.kernel.org/majordomo-info.html
>>>>
>>>>
>>>
>>>
>
>
--
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
mgrollman@nscus.com
www.nsct.info
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-07 15:15 ` Mario Limonciello
2008-07-09 17:05 ` Michael Grollman
@ 2008-07-11 13:35 ` Kasper Sandberg
2008-07-11 15:26 ` Mario Limonciello
1 sibling, 1 reply; 25+ messages in thread
From: Kasper Sandberg @ 2008-07-11 13:35 UTC (permalink / raw)
To: Mario Limonciello
Cc: Francois Romieu, Michael Grollman, netdev, akpm, linux-pci
On Mon, 2008-07-07 at 10:15 -0500, Mario Limonciello wrote:
> 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.
Sorry, i am not subscribed to netdev or pci list, could you post here
aswell?
>
> Regards
>
> Kasper Sandberg wrote:
> > On Thu, 2008-06-26 at 23:59 +0200, Francois Romieu wrote:
> >
> > 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
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe netdev" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-11 13:35 ` Kasper Sandberg
@ 2008-07-11 15:26 ` Mario Limonciello
2008-07-14 16:21 ` Kasper Sandberg
0 siblings, 1 reply; 25+ messages in thread
From: Mario Limonciello @ 2008-07-11 15:26 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Francois Romieu, Michael Grollman, netdev, akpm, linux-pci
[-- Attachment #1: Type: text/plain, Size: 359 bytes --]
Kasper:
http://marc.info/?l=linux-netdev&m=121498012600793&w=2
Regards
Kasper Sandberg wrote:
> On Mon, 2008-07-07 at 10:15 -0500, Mario Limonciello wrote:
>
> Sorry, i am not subscribed to netdev or pci list, could you post here
> aswell?
>
>
>
>
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-11 15:26 ` Mario Limonciello
@ 2008-07-14 16:21 ` Kasper Sandberg
2008-07-14 19:52 ` Rolf Eike Beer
2008-09-22 17:20 ` Michael Grollman
0 siblings, 2 replies; 25+ messages in thread
From: Kasper Sandberg @ 2008-07-14 16:21 UTC (permalink / raw)
To: Mario Limonciello
Cc: Francois Romieu, Michael Grollman, netdev, akpm, linux-pci
On Fri, 2008-07-11 at 10:26 -0500, Mario Limonciello wrote:
> Kasper:
>
> http://marc.info/?l=linux-netdev&m=121498012600793&w=2
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?
>
> Regards
>
> Kasper Sandberg wrote:
> > On Mon, 2008-07-07 at 10:15 -0500, Mario Limonciello wrote:
> >
> > Sorry, i am not subscribed to netdev or pci list, could you post here
> > aswell?
> >
> >
> >
> >
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 16:21 ` Kasper Sandberg
@ 2008-07-14 19:52 ` Rolf Eike Beer
2008-07-14 20:00 ` Mario Limonciello
2008-07-15 18:58 ` Francois Romieu
2008-09-22 17:20 ` Michael Grollman
1 sibling, 2 replies; 25+ messages in thread
From: Rolf Eike Beer @ 2008-07-14 19:52 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Mario Limonciello, Francois Romieu, Michael Grollman, netdev,
akpm, linux-pci
[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]
Kasper Sandberg wrote:
> On Fri, 2008-07-11 at 10:26 -0500, Mario Limonciello wrote:
> > Kasper:
> >
> > http://marc.info/?l=linux-netdev&m=121498012600793&w=2
>
> 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.patc
>h 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.
Is there any chance this helps with the famous 8101 problems, e.g.
http://bugzilla.kernel.org/show_bug.cgi?id=6807 ?
> Now i can have both msi and apic on.. Thanks alot.
>
> Do you have plans to get this merged?
There is a typo in the description of 91ba1a976c214766b5ee8c6d17086903c10f6405
(serie should be series I think).
Greetings,
Eike
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 194 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 19:52 ` Rolf Eike Beer
@ 2008-07-14 20:00 ` Mario Limonciello
2008-07-14 20:45 ` Kasper Sandberg
2008-07-15 18:58 ` Francois Romieu
1 sibling, 1 reply; 25+ messages in thread
From: Mario Limonciello @ 2008-07-14 20:00 UTC (permalink / raw)
To: Rolf Eike Beer
Cc: Kasper Sandberg, Francois Romieu, Michael Grollman, netdev, akpm,
linux-pci
[-- Attachment #1: Type: text/plain, Size: 610 bytes --]
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
Rolf Eike Beer wrote:
> Kasper Sandberg wrote:
>
>
> 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
>
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 20:00 ` Mario Limonciello
@ 2008-07-14 20:45 ` Kasper Sandberg
2008-07-14 21:00 ` Mario Limonciello
0 siblings, 1 reply; 25+ messages in thread
From: Kasper Sandberg @ 2008-07-14 20:45 UTC (permalink / raw)
To: Mario Limonciello
Cc: Rolf Eike Beer, Francois Romieu, Michael Grollman, netdev, akpm,
linux-pci
On Mon, 2008-07-14 at 15:00 -0500, Mario Limonciello wrote:
> 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.
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?
>
> Regards
>
> Rolf Eike Beer wrote:
> > Kasper Sandberg wrote:
> >
> >
> > 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
> >
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 20:45 ` Kasper Sandberg
@ 2008-07-14 21:00 ` Mario Limonciello
2008-07-15 18:56 ` Francois Romieu
0 siblings, 1 reply; 25+ messages in thread
From: Mario Limonciello @ 2008-07-14 21:00 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Rolf Eike Beer, Francois Romieu, Michael Grollman, netdev, akpm,
linux-pci
[-- Attachment #1: Type: text/plain, Size: 7210 bytes --]
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
Kasper Sandberg wrote:
> On Mon, 2008-07-14 at 15:00 -0500, Mario Limonciello wrote:
>
>> 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.
>>
>
> 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?
>
>
>> Regards
>>
>> Rolf Eike Beer wrote:
>>
>>> Kasper Sandberg wrote:
>>>
>>>
>>> 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
>>>
>>>
>
>
--
Mario Limonciello
*Dell | Linux Engineering*
mario_limonciello@dell.com
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 252 bytes --]
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 21:00 ` Mario Limonciello
@ 2008-07-15 18:56 ` Francois Romieu
2008-07-16 15:03 ` Kasper Sandberg
0 siblings, 1 reply; 25+ messages in thread
From: Francois Romieu @ 2008-07-15 18:56 UTC (permalink / raw)
To: Mario Limonciello
Cc: Kasper Sandberg, Rolf Eike Beer, Marcus Sundberg,
Michael Grollman, netdev, akpm, linux-pci
Mario Limonciello <mario_limonciello@dell.com> :
[...]
> 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:
+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
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 19:52 ` Rolf Eike Beer
2008-07-14 20:00 ` Mario Limonciello
@ 2008-07-15 18:58 ` Francois Romieu
1 sibling, 0 replies; 25+ messages in thread
From: Francois Romieu @ 2008-07-15 18:58 UTC (permalink / raw)
To: Rolf Eike Beer
Cc: Kasper Sandberg, Mario Limonciello, Michael Grollman, netdev,
akpm
Rolf Eike Beer <eike-kernel@sf-tec.de> :
[...]
> Is there any chance this helps with the famous 8101 problems, e.g.
> http://bugzilla.kernel.org/show_bug.cgi?id=6807 ?
Yes, it is worth a try.
--
Ueimor
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-15 18:56 ` Francois Romieu
@ 2008-07-16 15:03 ` Kasper Sandberg
0 siblings, 0 replies; 25+ messages in thread
From: Kasper Sandberg @ 2008-07-16 15:03 UTC (permalink / raw)
To: Francois Romieu
Cc: Mario Limonciello, Rolf Eike Beer, Marcus Sundberg,
Michael Grollman, netdev, akpm, linux-pci
On Tue, 2008-07-15 at 20:56 +0200, Francois Romieu wrote:
> Mario Limonciello <mario_limonciello@dell.com> :
> [...]
> > 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:
>
> +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.
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
>
> Sorry for disturbing linux-pci.
>
^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem)
2008-07-14 16:21 ` Kasper Sandberg
2008-07-14 19:52 ` Rolf Eike Beer
@ 2008-09-22 17:20 ` Michael Grollman
1 sibling, 0 replies; 25+ messages in thread
From: Michael Grollman @ 2008-09-22 17:20 UTC (permalink / raw)
To: Kasper Sandberg
Cc: Mario Limonciello, Francois Romieu, netdev, akpm, linux-pci
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.
Kasper Sandberg wrote:
> On Fri, 2008-07-11 at 10:26 -0500, Mario Limonciello wrote:
>
>> Kasper:
>>
>> http://marc.info/?l=linux-netdev&m=121498012600793&w=2
>>
>
> 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?
>
>
>> Regards
>>
>> Kasper Sandberg wrote:
>>
>>> On Mon, 2008-07-07 at 10:15 -0500, Mario Limonciello wrote:
>>>
>>> Sorry, i am not subscribed to netdev or pci list, could you post here
>>> aswell?
>>>
>>>
>>>
>>>
>>>
>
>
--
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
mgrollman@nscus.com
www.nsct.info
^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2008-09-22 17:20 UTC | newest]
Thread overview: 25+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
[not found] <4861800B.90703@nscus.com>
2008-06-25 21:31 ` 8169 Intermittent ifup Failure Issue With RTL8102E Chipset in Intel's New D945GCLF Atom Board (Not the Initial Modprobe Crash, Another Problem) Francois Romieu
2008-06-26 21:08 ` Michael Grollman
2008-06-26 21:59 ` Francois Romieu
2008-06-26 22:27 ` Michael Grollman
2008-06-27 2:35 ` Matthew Wilcox
2008-06-27 2:58 ` mgrollman
2008-06-27 3:25 ` Mario_Limonciello
2008-06-27 4:44 ` Michael Grollman
2008-07-07 12:53 ` Kasper Sandberg
2008-07-07 15:15 ` Mario Limonciello
2008-07-09 17:05 ` Michael Grollman
2008-07-09 17:31 ` Mario Limonciello
2008-07-09 23:31 ` Michael Grollman
2008-07-11 13:35 ` Kasper Sandberg
2008-07-11 15:26 ` Mario Limonciello
2008-07-14 16:21 ` Kasper Sandberg
2008-07-14 19:52 ` Rolf Eike Beer
2008-07-14 20:00 ` Mario Limonciello
2008-07-14 20:45 ` Kasper Sandberg
2008-07-14 21:00 ` Mario Limonciello
2008-07-15 18:56 ` Francois Romieu
2008-07-16 15:03 ` Kasper Sandberg
2008-07-15 18:58 ` Francois Romieu
2008-09-22 17:20 ` Michael Grollman
2008-06-24 23:27 Michael Grollman
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).