Realtek RTL8111/8168B IRQ clash with IDE driver?

madbrad · 02-09-2008, 07:23 PM

Hi. I've got a brand-new system with a Gigabyte P35-DS4 motherboard, which has an embedded Realtek RTL8111/8168B gigabit network controller. I'm running Linux 2.6.23.14, freshly fetched from kernel.org a couple of weeks ago.

The system was running perfectly ... until I decided to start using the network. With both the Linux kernel's r8169 module and the r8168 driver from realtek.com.tw - separately loaded, one at a time - I have the same problem - the driver loads properly, the eth0 interface configures properly, all the networking functions operate correctly ... but when I receive packets at the full 100Mbit/s rate from another machine (both my eth0 and the other machine auto-negotiated to 100Mb/sec full duplex) I see various errors suddenly pop up in the syslog:

sshd[4685]: error: channel 0: chan_read_failed for istate 1
sshd[4685]: error: channel 0: chan_read_failed for istate 3
last message repeated 20 times
kernel: hda: cdrom_pc_intr: The drive appears confused (ireason = 0x01). Trying to recover by ending request.
last message repeated 3 times
kernel: ide: failed opcode was: unknown
kernel: hda: drive not ready for command
kernel: hda: status error: status=0x58 { DriveReady SeekComplete DataRequest }

And so forth.

When either of the r8169/r8168 modules are loaded they report as follows in the log (this example is the regular Linux (kernel.org) r8169 module):

kernel: 8169 Gigabit Ethernet driver 2.2LK loaded
kernel: ACPI: PCI Interrupt 0000:04:00.0[A] -> GSI 17 (level, low) -> IRQ 17
kernel: eth0: RTL8168b/8111b at 0xf8d1c000, 00:1a:4d:58:a3:54, XID 38000000 IRQ 17

A look at the IRQ 17 line in /proc/interrupts shows that the IDE driver and the Realtek driver are both sharing IRQ 17:

# fgrep eth /proc/interrupts
17: 58077 4 98999 129160 IO-APIC-fasteoi ide0, eth0

Given the kernel messages about 'hda' - which is my sole IDE disk device on the system, the DVD-ROM drive (all my hard disk drives are SATA/AHCI) - it seems to me that the realtek driver is losing interrupts, or the IDE driver is picking up the interrupts destined for the ethernet device. But it's been a loooong time since I had to play with PC hardware and interrupts ... I don't have a clue how IRQs are (automatically?) assigned on a PCI bus these days, nor how to change things.

Output of 'lspci' for just those two devices is:

03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02)
04:00.0 Ethernet controller: Realtek Semiconductor co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)

How can I 'move' the Realtek device to another interrupt? Is there a general 'what to do with messy interrupt conflicts on PCI busses' HOWTO out there for a hardware novice?

My Award Bios on this new machine (version F7, BIOS date 09/07/2007) doesn't seem to have any 'plug and play' or 'IRQ' options that might help. In a 'PnP/PCI Configuration' menu there are just two options to set/unset:

PCI1 IRQ assignment
PCI2 IRQ assignment

Both are set to 'auto'. Changing them to specific different values - in a desperate/naive attempt to do something 'new' - didn't change any of the kernel's IRQ assignments at all.

I've tried a few kernel boot options - 'pci=routeirq', 'pci=noacpi' - in trying to get the ide0 driver and Realtek driver to use different IRQs, but they stubbornly keep using the same one. The 'pci=routeirq' option made them *both* shift from IRQ 17 to IRQ 20. I've got no idea how Linux assigns/reads these IRQs for PCI hardware so I'm just shooting in the dark. I don't even know if there's a way to tell the Realtek controller - when I modprobe r8169.ko - to just go and use something else. Things have changed a lot since I had to manually go and change ISA IRQ values in the old days!

Can anyone point me to how I can bootstrap myself into understanding what part of the Linux kernel assigns IRQ values? Whether they can be changed? How I can get the 'ide0' driver to use a different IRQ than the Realtek r8169 module?

Many thanks,

Brad

H_TeXMeX_H · 02-10-2008, 01:56 PM

It could be an IRQ conflict, see here:
http://tldp.org/HOWTO/Plug-and-Play-HOWTO-10.html

I have a similar board, it also has the (infamous) 'JMicron' IDE and SATA controller, and an 'RTL8111/8168B' ethernet chipset, and it seems that they too may be using the same IRQ, I'll have to look into this tomorrow a bit and try to understand it. However, my problems are somewhat different, sometimes eth0 goes down and refuses to come back up no matter what (except restart).

Did you try disabling APIC with kernel parameter 'noapic' and possibly also 'noioapic' and 'nolapic'.

Now, I have had some success with kernel 2.6.23.1 in that this happens much more rarely, but it still does happen.

madbrad · 02-10-2008, 04:48 PM

Quote:

Originally Posted by H_TeXMeX_H

It could be an IRQ conflict, see here:
http://tldp.org/HOWTO/Plug-and-Play-HOWTO-10.html

It definitely is, I think; I've tried those various APIC kernel boot options, which sometimes makes both the 'ide0' and 'eth0' drivers get allocated a different interrupt - IRQ 15 rather than IRQ 17. But the kernel has them both sharing the same one, still, and the problem still happens.

I compiled a new kernel with the IDE driver taken out completely - IDE=n - and the 'eth0' driver ended up sharing with a 'libata' driver (I think that's the SATA driver; don't know why it doesn't show up at all in /proc/interrupts when IDE is configured in). But the problem disappeared when eth0 was sharing with 'libata'.

That HOWTO you pointed me to has the crucial line:

When a shared interrupt is issued, the CPU runs all interrupt service routines sequentially for all devices using that interrupt. The first thing such a service routine does is to check its device's registers to see if an interrupt actually happened for its device. If it finds that its device didn't issue an interrupt (a false alarm) then it likely will immediately exit and the next service routine begins for the second device which uses that same interrupt.

It really does seem that the IDE driver is picking up on the interrupts from the increased network traffic and trying to do something with it. In addition to the 'confused' and other messages about something happening on the IDE DVD-ROM device (hda) after a few seconds a KDE window will pop up telling me that someone has inserted a music CD, do I want to play it? It's *almost* funny ... :-(

Quote:

I have a similar board, it also has the (infamous) 'JMicron' IDE and SATA controller, and an 'RTL8111/8168B' ethernet chipset, and it seems that they too may be using the same IRQ, I'll have to look into this tomorrow a bit and try to understand it.

I thought I'd done my homework on this chipset before I bought the machine, I really did :-(.

It would be VERY useful if you could give me a listing of your /proc/interrupts. Although (a) you've also got a (different) problem, and (b) I wouldn't know why your kernel got its different IRQ routing anyway, I guess.

Quote:

Did you try disabling APIC with kernel parameter 'noapic' and possibly also 'noioapic' and 'nolapic'.

Yes, thanks. I couldn't see 'noioapic' documented in /usr/src/linux/Documentation/kernel-parameters.txt but still tried it; no effect. 'noapic' changes the /proc/interrupts settings from 'IO-APIC-fasteoi' to 'XT-PIC-XT' and moves all the IRQs down from high numbers to interrupts in the 0 - 15 range - like the good old days I remember a decade ago! - but the 'ide0' and 'eth0' still share the same IRQ, IRQ 15, and the problem persists.

'nolapic' hangs the kernel on boot, right after it loads the ide driver - 'hda: lost interrupt'.

Thanks for your help. It seems to me that either (a) I've got to find a way to 'toughen' up the IDE driver, stop it to process network interrupts as its own; or (b) try and find a way to stop the 'eth0' driver from sharing with the 'ide0' driver. I know nothing about modern PC hardware but it seems that the kernel can do jazzy things in it's 'IRQ routing', move interrupts around ... is there a way to tell it to move the network driver's IRQ away from the IDE driver? *sigh*

Regards,

Brad

H_TeXMeX_H · 02-11-2008, 04:19 AM

Here's the data from my computer that has a 'GA-P35-DS3'. Your's is a 'P35-DS4' one version higher, but I think it's similar enough, in fact almost identical.

/sbin/lspci -vv

Code:

00:00.0 Host bridge: Intel Corporation DRAM Controller (rev 02)
	Subsystem: Giga-byte Technology Unknown device 5000
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort+ >SERR- <PERR-
	Latency: 0
	Capabilities: <access denied>

00:01.0 PCI bridge: Intel Corporation PCI Express Root Port (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
	I/O behind bridge: 0000b000-0000bfff
	Memory behind bridge: f4000000-f7ffffff
	Prefetchable memory behind bridge: 00000000e0000000-00000000efffffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-
	Capabilities: <access denied>

00:1a.0 USB Controller: Intel Corporation USB UHCI Controller #4 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 4: I/O ports at e100 [size=32]
	Capabilities: <access denied>

00:1a.1 USB Controller: Intel Corporation USB UHCI Controller #5 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 18
	Region 4: I/O ports at e200 [size=32]
	Capabilities: <access denied>

00:1a.2 USB Controller: Intel Corporation USB UHCI Controller #6 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin C routed to IRQ 19
	Region 4: I/O ports at e000 [size=32]
	Capabilities: <access denied>

00:1a.7 USB Controller: Intel Corporation USB2 EHCI Controller #2 (rev 02) (prog-if 20 [EHCI])
	Subsystem: Giga-byte Technology Unknown device 5006
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at fa104000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>

00:1b.0 Audio device: Intel Corporation HD Audio Controller (rev 02)
	Subsystem: Giga-byte Technology Unknown device a002
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 21
	Region 0: Memory at fa100000 (64-bit, non-prefetchable) [size=16K]
	Capabilities: <access denied>

00:1c.0 PCI bridge: Intel Corporation PCI Express Port 1 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
	I/O behind bridge: 0000a000-0000afff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: <access denied>

00:1c.3 PCI bridge: Intel Corporation PCI Express Port 4 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
	I/O behind bridge: 0000c000-0000cfff
	Memory behind bridge: fa000000-fa0fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: <access denied>

00:1c.4 PCI bridge: Intel Corporation PCI Express Port 5 (rev 02) (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Bus: primary=00, secondary=04, subordinate=04, sec-latency=0
	I/O behind bridge: 0000d000-0000dfff
	Memory behind bridge: f8000000-f9ffffff
	Prefetchable memory behind bridge: 0000000040000000-00000000400fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: <access denied>

00:1d.0 USB Controller: Intel Corporation USB UHCI Controller #1 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 20
	Region 4: I/O ports at e300 [size=32]
	Capabilities: <access denied>

00:1d.1 USB Controller: Intel Corporation USB UHCI Controller #2 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 17
	Region 4: I/O ports at e400 [size=32]
	Capabilities: <access denied>

00:1d.2 USB Controller: Intel Corporation USB UHCI Controller #3 (rev 02) (prog-if 00 [UHCI])
	Subsystem: Giga-byte Technology Unknown device 5004
	Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin C routed to IRQ 19
	Region 4: I/O ports at e500 [size=32]
	Capabilities: <access denied>

00:1d.7 USB Controller: Intel Corporation USB2 EHCI Controller #1 (rev 02) (prog-if 20 [EHCI])
	Subsystem: Giga-byte Technology Unknown device 5006
	Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 20
	Region 0: Memory at fa105000 (32-bit, non-prefetchable) [size=1K]
	Capabilities: <access denied>

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01 [Subtractive decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Bus: primary=00, secondary=05, subordinate=05, sec-latency=32
	I/O behind bridge: 00009000-00009fff
	Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort+ <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
	Capabilities: <access denied>

00:1f.0 ISA bridge: Intel Corporation LPC Interface Controller (rev 02)
	Subsystem: Giga-byte Technology Unknown device 5001
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Capabilities: <access denied>

00:1f.2 SATA controller: Intel Corporation 4 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Giga-byte Technology Unknown device b005
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin B routed to IRQ 17
	Region 0: I/O ports at e600 [size=8]
	Region 1: I/O ports at e700 [size=4]
	Region 2: I/O ports at e800 [size=8]
	Region 3: I/O ports at e900 [size=4]
	Region 4: I/O ports at ea00 [size=32]
	Region 5: Memory at fa106000 (32-bit, non-prefetchable) [size=2K]
	Capabilities: <access denied>

00:1f.3 SMBus: Intel Corporation SMBus Controller (rev 02)
	Subsystem: Giga-byte Technology Unknown device 5001
	Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Interrupt: pin C routed to IRQ 19
	Region 0: Memory at fa107000 (64-bit, non-prefetchable) [size=256]
	Region 4: I/O ports at 0500 [size=32]

01:00.0 VGA compatible controller: nVidia Corporation G80 [GeForce 8800 GTS] (rev a2) (prog-if 00 [VGA])
	Subsystem: nVidia Corporation Unknown device 0420
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0
	Interrupt: pin A routed to IRQ 16
	Region 0: Memory at f6000000 (32-bit, non-prefetchable) [size=16M]
	Region 1: Memory at e0000000 (64-bit, prefetchable) [size=256M]
	Region 3: Memory at f4000000 (64-bit, non-prefetchable) [size=32M]
	Region 5: I/O ports at b000 [size=128]
	[virtual] Expansion ROM at f7000000 [disabled] [size=128K]
	Capabilities: <access denied>

03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
	Subsystem: Giga-byte Technology Unknown device b000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 17
	Region 5: Memory at fa000000 (32-bit, non-prefetchable) [size=8K]
	Capabilities: <access denied>

03:00.1 IDE interface: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) (prog-if 85 [Master SecO PriO])
	Subsystem: Giga-byte Technology Unknown device b000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin B routed to IRQ 16
	Region 0: I/O ports at c000 [size=8]
	Region 1: I/O ports at c100 [size=4]
	Region 2: I/O ports at c200 [size=8]
	Region 3: I/O ports at c300 [size=4]
	Region 4: I/O ports at c400 [size=16]
	Capabilities: <access denied>

04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 01)
	Subsystem: Giga-byte Technology Unknown device e000
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR-
	Latency: 0, Cache Line Size: 32 bytes
	Interrupt: pin A routed to IRQ 16
	Region 0: I/O ports at d000 [size=256]
	Region 2: Memory at f9000000 (64-bit, non-prefetchable) [size=4K]
	[virtual] Expansion ROM at 40000000 [disabled] [size=128K]
	Capabilities: <access denied>

cat /proc/interrupts

Code:

           CPU0       CPU1       CPU2       CPU3       
  0:        402          0          1          0   IO-APIC-edge      timer
  1:          1          0          1          0   IO-APIC-edge      i8042
  7:          0          0          0          0   IO-APIC-edge      parport0
  8:          1          2          0          0   IO-APIC-edge      rtc
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          2          2          0          0   IO-APIC-edge      i8042
 16:     151884          1          0          0   IO-APIC-fasteoi   uhci_hcd:usb1, libata, eth0, nvidia
 17:      30051          7          6          6   IO-APIC-fasteoi   ahci, ahci, uhci_hcd:usb5
 18:     303694          1          0          0   IO-APIC-fasteoi   uhci_hcd:usb2
 19:        619          1          0          0   IO-APIC-fasteoi   uhci_hcd:usb3, uhci_hcd:usb6, ehci_hcd:usb7
 20:          0          0          0          0   IO-APIC-fasteoi   uhci_hcd:usb4, ehci_hcd:usb8
 21:        175          1          0          0   IO-APIC-fasteoi   HDA Intel
NMI:          0          0          0          0 
LOC:     480779     399788     273418     205637 
ERR:          0
MIS:          0

/sbin/ifconfig

Code:

eth0      Link encap:Ethernet  HWaddr 00:1A:4D:49:6D:54  
          inet addr:192.168.1.1  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::21a:4dff:fe49:6d54/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:3238 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2945 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:471159 (460.1 KiB)  TX bytes:2374991 (2.2 MiB)
          Interrupt:16 Base address:0x8000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:2 errors:0 dropped:0 overruns:0 frame:0
          TX packets:2 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:100 (100.0 b)  TX bytes:100 (100.0 b)

ppp0      Link encap:Point-to-Point Protocol  
          inet addr:89.40.140.12  P-t-P:172.22.255.253  Mask:255.255.255.255
          UP POINTOPOINT RUNNING NOARP MULTICAST  MTU:1500  Metric:1
          RX packets:71028 errors:24 dropped:0 overruns:0 frame:0
          TX packets:46926 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:3 
          RX bytes:101602002 (96.8 MiB)  TX bytes:3026522 (2.8 MiB)

Also the HDD I have is a Seagate SATA II, and in the BIOS I have it set to use SATA and AHCI. I built a custom kernel for it, and actually now that I think about it I disabled IDE support because I don't need it, nothing I have uses IDE. If you want I'll post my kernel config options.

Electro · 02-11-2008, 02:58 PM

I have no problems using Realtek NIC 8169. I use the r8169 module from the kernel. Though this chip is behind Hint Technologies PCI-PCI Bridge and my motherboard is Abit TH7II-RAID.

There is a BIOS update that might fix your problem. The latest version (F11) updates super I/O which might fix your problem.

Everybody has problems with modules from Realtek. The kernel developers revised the code and include it in the kernel. I recommend remove the modules from Realtek and use the modules from the kernel.

Try turning off or disabling ACPI by doing acpi=off or noacpi.

madbrad · 02-11-2008, 05:17 PM

Quote:

Originally Posted by H_TeXMeX_H

Also the HDD I have is a Seagate SATA II, and in the BIOS I have it set to use SATA and AHCI. I built a custom kernel for it, and actually now that I think about it I disabled IDE support because I don't need it, nothing I have uses IDE.

Disabling IDE is what did the trick, I think; I did the same here and the problem went away. The 'eth0' driver ended up sharing an interrupt with 'libata', which wasn't a problem at all. My problem only evidences when 'eth0' shares with 'ide0'.

As a side-issue I wonder where 'libata' goes when I've got IDE compiled in? It seems to only appear in /proc/interrupts if I've disabled IDE support in the kernel.

Quote:

Originally Posted by electro

There is a BIOS update that might fix your problem. The latest version (F11) updates super I/O which might fix your problem.

Can you tell me what 'super I/O' actually is? I'm loath to apply bios updates to my just-brand-new PC if it doesn't need it, and 'super I/O' doesn't sound close to what I need to change interrupts for devices.

Quote:

Everybody has problems with modules from Realtek. The kernel developers revised the code and include it in the kernel. I recommend remove the modules from Realtek and use the modules from the kernel.

I've been mainly doing that; I downloaded the one from Realtek just to see if it worked (it didn't). I've gone back to testing things with the kernel's r8169.ko.

Quote:

Try turning off or disabling ACPI by doing acpi=off or noacpi.

I've tried all those various options; no matter what I do 'ide0' ends up sharing the same interrupt (which changes with various kernel boot options) with 'eth0' ... and that appears to be at the root of my problem.

Electro · 02-11-2008, 06:23 PM

Super I/O is Gigabyte's way of handling all the input and output data. A new motherboard does not mean that it has the latest firmware or BIOS. If you still have problems, it could be the power supply that is making these problems.

Recompile the kernel without libata and use the try and true IDE (older) option. I use it and works with out any problems.

If nothing fixes your problems, return the motherboard and get a new motherboard that does not use Intel chipsets. Select an ATI chipset for Intel processors instead of using Intel chipsets.

madbrad · 02-11-2008, 07:38 PM

Quote:

Originally Posted by Electro

Recompile the kernel without libata and use the try and true IDE (older) option. I use it and works with out any problems.

Can I ask you, as a sub-topic, a question about 'libata'? I'm a little confused as to what it does. My machines has SATA II hard disks and just the DVD-ROM on the gigabyte/JMicron IDE port.

With both SATA and IDE compiled into the kernel when I list /proc/interrupts I see that both 'eth0' (for the Realtek r8169 driver) and 'ide0' are sharing the same IRQ. There's no mention anywhere in /proc/interrupts of 'libata'.

But when I compile a new kernel with just one (big) change - IDE completely disabled - a listing of /proc/interrupts shows that 'libata' has materialised and is sharing the IRQ with 'eth0'. My networking/ide problem goes away when I run this IDE-disabled kernel; if the libata driver is picking up and processing the interrupts that come with network traffic it seems to be doing it properly. I gather that *all* device drivers that share an interrupt have their interrupt handlers called when a shared interrupt comes in? My theory is that the IDE driver is simply buggy and thinks that the interrupts from network traffic are for it; hence the 'confused' messages it outputs.

Anyway, my question is about 'libata'. If it's present in both kernels, why do I only see it in /proc/interrupts when IDE is disabled? Is it present in the first, IDE-enabled kernel, but for some reason not listed in /proc/interrupts?

I'm just curious about this point ... I haven't much of an idea as to what 'libata' actually does. I grepped all the Kconfig files in the kernel source and it's mentioned a couple of times, but in no great detail.

I just thought I'd ask since you mentioned 'libata'.

Using the older IDE driver is a good idea, if only to prove that it's the newer IDE driver which is buggy. I'll give that a shot, thanks.

Thanks for your advice and time,

Brad

H_TeXMeX_H · 02-12-2008, 06:02 AM

Here's what Super I/O is:
http://en.wikipedia.org/wiki/Super_io
and a nice schematic:
http://upload.wikimedia.org/wikipedi...rd_diagram.png

I believe the Super I/O has nothing to due with this issue.

I don't recommend getting anything from ATI, they make very low quality crap. I think Intel has absolutely nothing to do with this issue, if anything it's the damn JMicron SATA and IDE (AHCI) controller, they are known to be badly designed and also not to work well on Linux, unfortunately. Technically it is said that newer kernels fix many issues caused by these controllers, but I think they don't fix all of them. Maybe if you try the latest kernel the issue may have been fixed ?

libata found here:
http://linux-ata.org/features.html
provides drivers for ATA, ATAPI, SATA, and PATA controllers. However, in the kernel config there are two separate drivers and options:
1) ATA/ATAPI/MFM/RLL support which is actually the module called ide and provides support for IDE, these drivers are older
2) Serial ATA (prod) and Parallel ATA (experimental) drivers which are newer and experimental and support SATA and PATA, these have different names such as 'pata_jmicron' which is the one used in this case.
I think both of these drivers need libata in order to function properly.

madbrad · 02-23-2008, 11:43 PM

Just posting a summation of what I've found out to solve my problem, in case anyone else ever does a search.

First up, from a few recent posts in the linux kernel mailing list, it looks like the interrupt handler for the ide-cd has been - or is in the process - of being rewritten. The message I saw (dated 14/2/08) said that the release candidate 2.6.25-rc1 kernel should have the fix. However I loaded up 2.6.25-rc2 today and the bug was still there. Still, the mention of the relevant change in the code - changing 'cdrom_pc_intr' to 'cdrom_newpc_intr' - suggests that my problem with conflicting interrupts between the Realtek and the CD-Rom will hopefully be fixed soon.

In the meantime I've found a workaround, the same one used by Ubuntu I think, which works out of the box. I've disabled IDE entirely on my machine, and enabled the sr_mod module (CONFIG_BLK_DEV_SR). The sr_mod module apparently sits above the 'cdrom' driver and presents a scsi device - /dev/sr0 or /dev/scd0 - to the system. I think this was the only way to use a CD-ROM back a few years before the ide-cd driver comes out.

Anyway, with IDE totally turned off in my kernel and sr_mod loaded I can use the DVD even though the 'libata' driver (rather than the 'ide0' driver) is still sharing the same IRQ as the Realtek device. Luckily the only IDE device in my system is the DVD drive so this workaround is sufficient until hopefully a new kernel fixes the bug.

I've realised I have several questions about how the kernel works out of all this ... for example, what does the Ubuntu kernel do if there are IDE devices (other than the DVD/CD) in the system? Is there another workaround? I tried various kernel boot parameters to try and keep the IDE driver enabled while telling it to 'ignore' the DVD drive - 'hda=scsi', 'hda=ide-scsi' - but nothing worked. Why is it that, when IDE is compiled in, a listing of /proc/interrupts shows that 'ide0' is using IRQ 17 with the network driver ... but when IDE is disabled 'libata' appears in its place? How does the kernel juggle the IDE and libata drivers around?

And, finally, what with all the various boot parameters to turn ACPI off, on and sideways, or otherwise meddle with the boot-time 'IRQ balancing' and such ... surely there would be a way to tell the kernel to move things around so that the IDE driver had its own unique IRQ? I thought IDEPCI_SHARE_IRQ would do it, but no.

Thanks for the help, Brad.

Electro · 02-24-2008, 01:47 AM

madbrad, if you have not done so, update the BIOS. You and others are wrong about the sr module. The sr module actually provides write access to an IDE CD/DVD recordable drive. If you remove it, the drive will not write. In the past I had to make sure the sr_mod is loaded or else I will not be able to write to a DVD or CD disc. In recent kernels, probably the kernel developers decided to dump the CD disk code in the sr_mod to stop the confusion.

It seems every build release of the 2.6 kernel, changes the whole kernel and how it functions. I suggest be careful upgrading the kernel or else you may have other problems besides this one.

Quote:

Originally Posted by H_TeXMeX_H

I believe the Super I/O has nothing to due with this issue.

I don't recommend getting anything from ATI, they make very low quality crap. I think Intel has absolutely nothing to do with this issue, if anything it's the damn JMicron SATA and IDE (AHCI) controller, they are known to be badly designed and also not to work well on Linux, unfortunately. Technically it is said that newer kernels fix many issues caused by these controllers, but I think they don't fix all of them. Maybe if you try the latest kernel the issue may have been fixed ?

If madbrad have not update his BIOS and problems still exist, it actually might be a Super I/O problem since Gigabyte has fix some unknown issues.

A lot of people do not understand that good software and good hardware go together well while lacking in one area will make the other seem poor. The kernel developers have provided a lot of workarounds to fix hardware issues in Intel chipsets and few others. People should not assume that bad software from a company does not mean that the hardware is also bad. I have an ATI Radeon 64 VIVO. It crashes a lot in Windows because the software was bad, but in Linux it ran well. I was using the radeon driver from the open source community. The hardware from ATI is better than you think with good software. I do not recommend running ATI products in Windows, but Linux will run it just fine and probably better than other brands. I have problems with Intel 965 chipset.

madbrad · 03-02-2008, 05:18 AM

Quote:

Originally Posted by Electro

madbrad, if you have not done so, update the BIOS. You and others are wrong about the sr module. The sr module actually provides write access to an IDE CD/DVD recordable drive. If you remove it, the drive will not write.

With IDE taken out of the kernel and just the 'sr_mod' module loaded on top of the 'cdrom' module I can both read and write DVD discs (I haven't tried CD-ROM discs, but I'd assume they'd work).

Since that's working for me I don't intend to unload the module; if I did, I agree, with IDE disabled I would have no other way to access the DVD drive.

One other note - it was suggested to me that I use the kernel boot parameter 'hda=noprobe' with an IDE-enabled kernel to force it NOT to allocate the ide driver to the DVD-ROM drive. Unfortunately that option didn't work for me ... the output from the kernel at boot seemed to indicate that it wasn't parse correctly (?). I don't know why; if the sr_mod workaround wasn't available I would have looked into that in more detail.

H_TeXMeX_H · 04-12-2008, 08:29 AM

I just noticed something very odd, at least to me. I'm not an expert, so I don't understand it. If you look above at the output of 'lspci' that I posted a while ago you'll notice:

Quote:

00:1f.2 SATA controller: Intel Corporation 4 port SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])

03:00.0 SATA controller: JMicron Technologies, Inc. JMicron 20360/20363 AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])

Does this mean I have 2 SATA controllers on this board ? If so, why ?

madbrad · 04-12-2008, 08:55 AM

Quote:

Originally Posted by H_TeXMeX_H

Does this mean I have 2 SATA controllers on this board ? If so, why ?

Yes, you do. Your machine is a P35-something, like my P35-DS4, isn't it?

From what I recall (it's now been a few months since I researched all this buying my P35-DS4 machine):

The intel P35 chipset has a P35 chipset as its north bridge and an Intel ICH9R south bridge. The north bridge handles the processor and memory. The ICH9R south bridge has six SATA ports that you can configure as RAID or 'normal' SATA2, plus supports the two standard PCI slots that I have, the USB ports and the like.

But the Intel ICH9R doesn't have any IDE ports. I remember reading a few articles where the reviewers scratched their heads, wondering why Intel made the decision to get rid of IDE entirely, as many folk still need it for DVD-ROM and the like.

So most of the motherboard manufacturers have integrated another I/O controller, in order to provide IDE. Most, like Gigabyte, use a 'JMicron' chip which has the required IDE port (which can control two IDE devices, master/slave) but which also comes with two more SATA ports. So we get the extra SATA ports as a side-effect, as it were, of the manufacturers filling the need for IDE connectivity.

I've got two 500GB disks in my system and prefer to use Linux software RAID rather than the hardware RAID that comes with either ICH9R or JMicron SATA controllers. So I've got one disk on an ICH9R port and the other on the JMicron, thus distributing disk I/O across the two controllers. I doubt if it makes much of a difference performance-wise, since SATA is so fast and I've only got one disk on each controller, but maybe makes sense from a robustness point of view.

Looking up the Gigabyte site I can see that your P35-DS3 differs from my -DS4 in that your south bridge is an Intel ICH9, which has four non-RAID SATA ports; my south bridge is the ICH9R, which has six SATA ports which can be configured for hardware RAID. But I think we both have the same JMicron chip with an IDE port and two hardware-RAID enabled SATA ports.

Brad

H_TeXMeX_H · 04-12-2008, 10:58 AM

Thanks for the explanation, it makes sense now. But, then how do I know which device is using which controller ? I'm not sure it makes too much difference performance-wise.