Bug 12795
Summary: | ACPI interrupt storm - Sony Vaio VGN-TT11/LN | ||
---|---|---|---|
Product: | ACPI | Reporter: | Michael Wallner (mike) |
Component: | Config-Interrupts | Assignee: | Zhang Rui (rui.zhang) |
Status: | REJECTED INSUFFICIENT_DATA | ||
Severity: | normal | CC: | acpi-bugzilla, malattia |
Priority: | P1 | ||
Hardware: | All | ||
OS: | Linux | ||
Kernel Version: | 2.6.28.7 | Subsystem: | |
Regression: | No | Bisected commit-id: | |
Attachments: |
acpidump
dmesg grep . /sys/firmware/acpi/interrupts/* grep . /sys/firmware/acpi/interrupts/* lspci -vvxxx try the custom DSDT |
Description
Michael Wallner
2009-03-01 09:42:48 UTC
Created attachment 20398 [details]
acpidump
Created attachment 20399 [details]
dmesg
please attach the result of "grep . /sys/firmware/acpi/interrupts/*" Created attachment 20404 [details]
grep . /sys/firmware/acpi/interrupts/*
> 9: 22085708 21992064 IO-APIC-fasteoi acpi > /sys/firmware/acpi/interrupts/sci: 26 the ACPI interrupts info in comment #4 is got when there is no ACPI interrupt storm, isn't it? please re-attach this info when the interrupt storm occurs, e.g. kacpid(_notify) start to use 60-70% of CPU time. Uh right, sorry I didn't notice... Today I booted with AC not plugged in and kacpid keeps calm. I'll reboot as soon as I'm in the office. Rebooted with AC plugged in--still behaves nicely. Anything I can provide in the meantime? so the bug is hard to reproduce? hmm, please un/plug the ac adapter or battery, open/close the lid, etc. try to trigger as many kinds of ACPI event as possiblem, and check if the interrupt storm occurs. Okay, this is a bit strange, but I had hibernated MS Vista before booting Linux the first time today. After resuming Vista and really rebooting into Linux kacpid got back its power. Created attachment 20406 [details]
grep . /sys/firmware/acpi/interrupts/*
Okay, just repeated what I was explaining earlier. Rebooted into Vista and hibernated. Then booted Linux and kacpid shut up. does the problem still exist if you boot with "acpi_enforce_resources=strict"? Yes, the probelm persists with this boot option. Just tried again the Vista-hibernating approach, it reproducibly works. Shall I enable acpi debugging in my kernel, try a newer kernel, etc? then how about removing the sony-laptop driver? From the acpidump, Method (_L15, 0, NotSerialized) { Store (0x44, P80H) If (\_SB.PCI0.LPC.SNC.FSTS) { Store (0x55, P80H) Store (One, \_SB.PCI0.LPC.SNC.INTS) \_SB.PCI0.SBUS.SWRB (0x72, 0x86, Zero) \_SB.PCI0.LPC.SNC.SNNE (0x012F) } } we know that GPE15 handler does a lot of work related with ACPI sony-laptop driver and SMBUS driver. It would be good to know if there is any previous kernel release that this problem doesn't exist in. CC Mattia. Problem also occurs when sony-laptop is not loaded. how do you reproduce the bug? we know that the laptop works well if we enter windows and do a hibernation, then when the problem comes back again? after a Linux reboot? Exactly, after a cold boot or a reboot into Linux the problem occurs. When booting into Linux after hibernation of Windows, kacpid behaviour seems nice. From the comment #18 it seems that it can work well after hibernation on windows. Will you please do the hibernate/resume on linux and then see whether the kcapid can work well? Will you please also try the debug patch in http://bugzilla.kernel.org/show_bug.cgi?id=11857#C62? thanks. please attach the output of lspci -vvxxx (In reply to comment #21) > Please see http://bugzilla.kernel.org/show_bug.cgi?id=12816#c6 > no, this is the lspci -vx please attach the lspci -vvxxx instead. Sorry, here we go. Created attachment 20638 [details]
lspci -vvxxx
sudo lspci -vvxxx after hibernating Windows
Will you please do the test as required in comment #19 and then see whether the kacpid can work well? Thanks. how about not load i801_smbus driver? Since the _L15 method will use smbus, which might conflict with smbus driver. Created attachment 20684 [details] try the custom DSDT Will you please try the custom DSDT and see whether the issue still exists? How to use the custom DSDT can be found in : http://www.lesswatts.org/projects/acpi/faq.php As the DSDT.hex is attached, the first four steps can be skipped. After the test, please attach the output of "grep . /sys/firmware/acpi/interrupts/*". Thanks. ping Michael close this bug because there is no response from the bug reporter for more than 1 month. please re-open it if you can provide the info requested in the above comments. |