* git-bisect identified 53f11d4ff8797bcceaf014e62bd39f16ce84baec as problematic patch: |53f11d4ff8797bcceaf014e62bd39f16ce84baec is first bad commit |diff-tree 53f11d4ff8797bcceaf014e62bd39f16ce84baec (from 02b28a33aae93a3b53068e0858d62f8bcaef60a3) |Author: Len Brown <len.brown@intel.com> |Date: Mon Dec 5 16:46:36 2005 -0500 | | [ACPI] Enable Embedded Controller (EC) interrupt mode by default | | "ec_intr=0" reverts to polling | "ec_burst=" no longer exists. | | Signed-off-by: Len Brown <len.brown@intel.com> | Acked-by: Luming Yu <luming.yu@intel.com> * Distribution: Debian etch (testing) * Hardware Environment: Centrino (dothan) notebook "MSI S260" branded as "Medion MD95600" * acpidump in http://lkml.org/lkml/2006/2/6/151 * Software Environment: acpid (1.0.4-3) * Problem Description: First diskussed on linux-kernel@vger.kernel.org in thread http://thread.gmane.org/gmane.linux.kernel/375756 No problems with ec_initr=0 nor $ git revert 53f11d4ff8797bcceaf014e62bd39f16ce84baec on newer kernels. With ec_initr=1 (and pci=noacpi) interrupt 9 "IO-APIC-edge acpi" in /proc/interrupts does not increase and acpid does not react on powerbutton or lid events. /proc/acpi/button/lid/LID0/state shows correct lid state. Whereas only for a few seconds after coming out of memory suspend there are no problems with acpi interrupt and acpid does recognize those events. the powerbutton or lid event. -- Gerhard
Why is pci=noacpi being used? As documented in bug 2742, you're lucky to get any ACPI interrupts at all in IOAPIC mode when you disable ACPI for interrupt configuration. This is because with ACPI not around to handle it, the interrupt source override in your MADT gets ignored: ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) Which says that the SCI should be HIGH LEVEL, but as your note on LKML showed, you're running with the SCI unconfigured, so it is still in legacy EDGE mode: 9: 1 IO-APIC-edge acpi I don't understand why ec_intr=0 works around this mis-configured system, but that isn't the real problem. The real problem is that this system is booted with pci=noacpi in IOAPIC mode. I expect if you boot with "pci=noacpi" and "noapic" together, then this system will work no matter how the EC is set up, yes?
> Why is pci=noacpi being used? My system booted for kernels <= v2.6.15 either with "acpi=off" or "noapic" or "pci=noacpi". Boot option "noapic" made problems with suspend-to-RAM, so I took "pci=noacpi". Now, I after much testing those problems turned out to be a simple missconfiguration of acpid's button/power event handler: When booting in IOAPIC mode either together with pci=nacpi or or not I did *not* get right after transition from suspend-to-RAM to On-power-state a "button/power" event. So I had no problem with the simple button/power-handler gps@medusa:~$ cat /etc/acpi/actions/my_powerbtn.sh #!/bin/sh echo mem > /sys/power/state But with "noapic" no matter if I have "pci=noacpi" or not I *do* get a "button/power" event right after resuming from supend-to-ram (by touching my powerbutton) and so my system got back in S3-State... No I use the improved better handler gps@medusa:~$ cat /etc/acpi/actions/my_powerbtn.sh #!/bin/sh # suspend to mem (S3, "mem") on button/power acpi event POWERBTN="/var/run/powerbtn.eid" suspend_to_mem() { echo $eid > $POWERBTN echo mem > /sys/power/state } # event arguments "%e" look like # button/power PWRF 00000080 0000002e eid=$(printf "%u\n" 0x${4}) # simple hexadecimal to integer conversion if [ -f "$POWERBTN" ] then # catch and ignore button/power event on transition to power-on state read oeid < "$POWERBTN" if [ $(($eid - $oeid )) -ne 1 ]; then suspend_to_mem fi else suspend_to_mem fi and all works fine with noapic. > I expect if you boot with "pci=noacpi" and "noapic" > together, then this system will work no matter > how the EC is set up, yes? You are right. System boots. Interrupt increases. button/power and button/lid events are all right. So no problem with EC for me any more. Thank you very much!!! But my system now works just with option "noapic" fine and video-console resumes better with "acpi_sleep=s3_bios". So I do not use ec_intr=0 or pci=noacpi any more. I think in general it' s better to use ACPI for IRQ routing, yes? I think this bug is resolved? But better you will decide that. Any chance that users won't have to experiment with incomprehensible boot options in the future?
yes, it is generally a bug if you need boot options. acpi_sleep=s3_bios for video restore is something we can't do much about, unless your video driver happens to get smart about suspend/resume. Do you still require "noapic", and you require this just to make S3 resume work?