lkml.org 
[lkml]   [2000]   [Aug]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
Patch in this message
/
Date
From
SubjectVAIO 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/

\
 
 \ /
  Last update: 2005-03-22 13:58    [W:0.022 / U:0.260 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site