Bug 6049

Summary: no acpi interrupt with IOAPIC and pci=noacpi, unless ec_intr=0 - MSI S260
Product: ACPI Reporter: Gerhard Schrenk (deb.gschrenk)
Component: Config-InterruptsAssignee: Len Brown (lenb)
Status: CLOSED PATCH_ALREADY_AVAILABLE    
Severity: normal CC: acpi-bugzilla, deb.gschrenk
Priority: P2    
Hardware: i386   
OS: Linux   
Kernel Version: v2.6.16-rc2 commit 53f11d4ff8797bcceaf014e62bd39f16ce84baec Subsystem:
Regression: --- Bisected commit-id:

Description Gerhard Schrenk 2006-02-09 19:16:37 UTC
* 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
Comment 1 Len Brown 2006-02-12 22:51:13 UTC
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?


Comment 2 Gerhard Schrenk 2006-02-14 09:43:19 UTC
> 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?
Comment 3 Len Brown 2006-07-25 21:22:14 UTC
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?