Re: Strange ACPI bug after resume

[Andreas Mohr]

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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/