Bug 6049

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?