Messages in this thread | | | Date | Wed, 19 Apr 2006 17:41:06 +0200 | From | Andreas Mohr <> | Subject | Re: Strange ACPI bug after resume |
| |
Hi,
On Wed, Apr 19, 2006 at 04:27:01PM +0100, Luká?? Turek wrote: > I recently upgraded kernel on my Asus M6V notebook, and found a strange > problem: > If I do suspend to RAM and then suspend to disk (swsusp or suspend2), after > resume every proces which tries to read from /proc/acpi/* freezes, starts to > take 100% of CPU and can't be killed (even with kill -9). Repeated suspend to > ram or suspend to disk is OK, only this combination triggers it.
Please enable CONFIG_MAGIC_SYSRQ, go to a text console and press Alt-SysRq-T to see where exactly in the kernel code this process is trapped.
> It worked fine in 2.6.14. I used git-bisect and found commit > 89fbb69c4f285019ba5e029963dc11cc6beb078a. It is a 300kB patch, but luckily > most of it are drivers i don't use. And in drivers/pci/quirks.c my notebook > was directly mentioned: > > if (dev->device == PCI_DEVICE_ID_INTEL_82915GM_HB) { > switch (dev->subsystem_device) { > case 0x1882: /* M6V notebook */ > asus_hides_smbus = 1; > } > } > > When i simply changed it to "asus_hides_smbus = 0;" the problem goes away - > but it isn't a real solution, because hardware sensors obviously go away too. > The problem might be somewhere in SMBus - but it happens also when no I2C and > Hardware Monitoring modules are loaded at all!
Perhaps ASUS hides SMBus since they know that they have incomplete/buggy BIOS support for it, thus an activated SMBus would cause crashes during power management stuff? Just a horrible thought, but it might actually be true.
Andreas Mohr - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |