Messages in this thread Patch in this message | | | Date | 7 Aug 2000 06:01:57 -0000 | From | Brian Warner <> | Subject | VAIO lockup solved [PATCH] (nm256_audio, eepro100) |
| |
Howdy all.. I don't know if anyone else has been having this problem, but I finally tracked it down and wanted to share the fix.
First off, the hardware: a sony Vaio Z505R laptop, which uses the nm256 sound driver, eepro100 on-board ethernet, an i82365-compatible PCMCIA controller, and a usb-uhci USB controller. I build eepro100 into the kernel, and make modules out of nm256_audio, the pcmcia code, and the USB drivers.
I've been tracking 2.3.XX for a while now. A few months ago, I noticed that using sound had a tendency to cause the laptop to lockup. It seemed related to APM suspend/resume. Sometimes doing too much with pcmcia cards or playing with USB could cause the same problem. I couldn't figure out the cause, so I just remembered not to use sound at all.
Last week I finally got annoyed and walked through a few dozen kernel revisions to identify where the problem first appeared. The fatal patch turned out to be drivers/pci/pci.c in 2.3.99-pre7, in which code was added to call a set of (struct pci_driver) .suspend and .resume elements that were previously unused. These functions were called for each known PCI device at every suspend and resume event.
It turns out that the eepro100.c .suspend and .resume functions are indeed buggy as advertised in the source code. The problem is that they were getting called anyway (even without CONFIG_EEPRO100_PM, which is marked as experimental). It appears that eepro100_resume() puts the chip in a state which wedges irq 9, causing it to spew out interrupts forever. If any other PCI device on the vaio is active (all PCI interrupts use irq 9), then the system will lock up because of all the interrupts. The problem wouldn't appear until one APM resume had occurred *and* some PCI-using driver was activated. PCMCIA had the interesting effect of fixing the problem: if loaded after the irq got stuck, it would complain about "irq 9 appears wedged" and drop into a polling mode instead.
The eepro100 driver seems to handle suspend/resume fairly well without the explicit support. The first transmit after a resume notices that the chip appears dead and reinitializes it after about 10 seconds. Removing those function pointers makes everything work great:
--- linux-2.4.0-test5/drivers/net/eepro100.c~ Tue Jul 11 11:12:23 2000 +++ linux-2.4.0-test5/drivers/net/eepro100.c Tue Aug 1 18:30:48 2000 @@ -2252,8 +2252,8 @@ id_table: eepro100_pci_tbl, probe: eepro100_init_one, remove: eepro100_remove_one, - suspend: eepro100_suspend, - resume: eepro100_resume, + // suspend: eepro100_suspend, + // resume: eepro100_resume, }; #if LINUX_VERSION_CODE < KERNEL_VERSION(2,3,48) With this patch I can use sound, usb, pcmcia, APM, and eth0, all without problems. (note: a better patch would probably be to put suspend: and resume: under CONFIG_EEPRO100_PM, since that's where they logically belong).
Hope somebody finds this useful,
-Brian
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |