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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
