After upgrading from 2.6.13 (with devfs enabled) to 2.6.17.5, the network stopped working after a suspend. The problem is caused by the fact, that IRQ 5 is disabled during the supend. According to the dmesg output, it happens, while all tasks are stopped. IRQ is used by 3 drivers: * 8139too (eth0) * sis9000 (eth1) * ohci_hcd To suspend, I do the following: * shut down eth1 * rmmod ohci-hcd * rmmod sis9000 (I'm unloading some other drivers too, but they do not affect IRQ 5) * echo disk >/sys/power/state At resume time, I reload the modules again and configure eth1 again. eth0 is left configured all the time. As the IRQ 5 is disabled, eth0 and eth1 emit messages about transmit timed out. All USB ports were not used during the tests. To resolve the issue, I must remove the 3 drivers, which use IRQ 5. After reloading them, the network is working. This is a regression, as it is triggerd by booting the same system with 2.6.17.5 instead of 2.6.13. With 2.6.13, the system handled lots of suspends without any problems. With 2.6.17.5, the IRQ gets disabled during the first suspend. lspci: 0000:00:00.0 Host bridge: Silicon Integrated Systems [SiS] 735 Host (rev 01) 0000:00:01.0 PCI bridge: Silicon Integrated Systems [SiS] Virtual PCI-to-PCI bridge (AGP) 0000:00:02.0 ISA bridge: Silicon Integrated Systems [SiS] SiS85C503/5513 (LPC Bridge) 0000:00:02.1 SMBus: Silicon Integrated Systems [SiS]: Unknown device 0016 0000:00:02.2 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) 0000:00:02.3 USB Controller: Silicon Integrated Systems [SiS] USB 1.0 Controller (rev 07) 0000:00:02.5 IDE interface: Silicon Integrated Systems [SiS] 5513 [IDE] (rev d0) 0000:00:02.7 Multimedia audio controller: Silicon Integrated Systems [SiS] Sound Controller (rev a0) 0000:00:03.0 Ethernet controller: Silicon Integrated Systems [SiS] SiS900 PCI Fast Ethernet (rev 90) 0000:00:0b.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10) 0000:00:0d.0 SCSI storage controller: LSI Logic / Symbios Logic 53c810 (rev 23) 0000:00:0f.0 Multimedia audio controller: C-Media Electronics Inc CM8738 (rev 10) 0000:01:00.0 VGA compatible controller: nVidia Corporation NV5M64 [RIVA TNT2 Model 64/Model 64 Pro] (rev 15) cat /proc/interrupts: CPU0 0: 665475 XT-PIC timer 1: 10693 XT-PIC i8042 2: 0 XT-PIC cascade 4: 5 XT-PIC serial 5: 312032 XT-PIC eth0, eth1, ohci_hcd:usb2 8: 6 XT-PIC rtc 9: 1 XT-PIC acpi 11: 1 XT-PIC ohci_hcd:usb1 12: 60695 XT-PIC i8042 14: 27473 XT-PIC ide0 15: 23 XT-PIC ide1 NMI: 0 LOC: 0 ERR: 0 MIS: 0 dmesg: ohci_hcd 0000:00:02.3: remove, state 4 usb usb2: USB disconnect, address 1 ohci_hcd 0000:00:02.3: USB bus 2 deregistered ACPI: PCI interrupt for device 0000:00:02.3 disabled ohci_hcd 0000:00:02.2: remove, state 4 usb usb1: USB disconnect, address 1 ohci_hcd 0000:00:02.2: USB bus 1 deregistered ACPI: PCI interrupt for device 0000:00:02.2 disabled Stopping tasks: =================================================================| Shrinking memory... done (29995 pages freed) swsusp: Need to copy 24989 pages Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. irq 5: nobody cared (try booting with the "irqpoll" option) <c013f8c4> __report_bad_irq+0x24/0x80 <c013f9be> note_interrupt+0x6e/0xf0 <c013f3a3> __do_IRQ+0x93/0xb0 <c01052d9> do_IRQ+0x19/0x30 <c0103822> common_interrupt+0x1a/0x20 <c01219f0> __do_softirq+0x30/0x90 <c0121a76> do_softirq+0x26/0x30 <c01052de> do_IRQ+0x1e/0x30 <c0103822> common_interrupt+0x1a/0x20 <c015a4f4> cache_grow+0x84/0x140 <c035d85d> set_cursor+0x4d/0x60 <c015a6ce> cache_alloc_refill+0x11e/0x1a0 <c015a91d> kmem_cache_alloc+0x3d/0x40 <c0333105> acpi_os_acquire_object+0xb/0x36 <c03485fa> acpi_ut_create_generic_state+0xb/0x23 <c0340925> acpi_ns_evaluate_relative+0x41/0xc7 <c034485b> acpi_rs_set_srs_method_data+0x8f/0xb4 <c034b98d> acpi_pci_link_set+0x10b/0x18a <c034be19> irqrouter_resume+0x26/0x44 <c0371714> __sysdev_resume+0x74/0x80 <c03719cb> sysdev_resume+0x3b/0x6b <c0376325> device_power_up+0x5/0xa <c0136a36> swsusp_suspend+0x56/0xa0 <c0136c0f> pm_suspend_disk+0x4f/0x90 <c0135e4a> enter_state+0x7a/0x90 <c0135fa1> state_store+0x91/0x99 <c0135f10> state_store+0x0/0x99 <c0198428> subsys_attr_store+0x38/0x40 <c019869e> flush_write_buffer+0x2e/0x40 <c01986e7> sysfs_write_file+0x37/0x60 <c015d7c1> vfs_write+0xb1/0x160 <c015d937> sys_write+0x47/0x80 <c0102e57> syscall_call+0x7/0xb handlers: [<d0aeff50>] (rtl8139_interrupt+0x0/0x150 [8139too]) Disabling IRQ #5 PM: Writing back config space on device 0000:00:02.2 at offset 1 (was 2800117, writing 2800113) PM: Writing back config space on device 0000:00:02.3 at offset 1 (was 2800117, writing 2800113) ACPI: PCI Interrupt 0000:00:03.0[A] -> Link [LNKG] -> GSI 5 (level, low) -> IRQ 5 eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Restarting tasks... done ACPI: Power Button (FF) [PWRF] ACPI: Sleep Button (CM) [SLPB] parport0: PC-style at 0x378 (0x778) [PCSPP,TRISTATE] parport0: irq 7 detected ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt 0000:00:02.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11 ohci_hcd 0000:00:02.2: OHCI Host Controller ohci_hcd 0000:00:02.2: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:02.2: irq 11, io mem 0xcfffd000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 3 ports detected ACPI: PCI Interrupt 0000:00:02.3[A] -> Link [LNKH] -> GSI 5 (level, low) -> IRQ 5 ohci_hcd 0000:00:02.3: OHCI Host Controller ohci_hcd 0000:00:02.3: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:02.3: irq 5, io mem 0xcfffe000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 3 ports detected mfg Martin K
Created attachment 8604 [details] config-2.6.17.5
The problematic driver is probably 8139too. The issue seems to be triggered by the fact, that 8139too is left running, when the tasks are stopped. If debugging of the 8139too driver is enabled, dmesg is filled up with the following line (before the interrupt is disabled): rtl8139_interrupt: eth0: exiting interrupt, intr_status=0x0000
The behaviour happens to, if only the sis9000 driver is active during suspend. So it is not the 8139too driver. Shuting down both ethernet drivers before suspend is the only way to work around the problem.
Is the problem still there with 2.6.18 or later?