acer tm100 ACPI woes: "nobody cared" again & strange battery events

DISCUSSION Fionn Behrens 1 participant 2 messages Nov 5, 2004 – Nov 9, 2004 ACPI

Share & tools

Fionn Behrens

author

2004-11-05 13:47 UTC #0 lore raw

Hello all,

I am about to try to get my wife's slightly aged Acer tm100 to run with 2.6.9 and ACPI. Everything is smooth so far except for two things: One real show stopper and one annoyance.

1) the show stopper:
Below you see the tm100 irq layout right after bootup:

root@samt:~# cat /proc/interrupts
           CPU0
  0:      36199          XT-PIC  timer
  1:          8          XT-PIC  i8042
  2:          0          XT-PIC  cascade
  3:        255          XT-PIC  eth1
  8:          1          XT-PIC  rtc
  9:          0          XT-PIC  acpi
 10:         11          XT-PIC  yenta, yenta, uhci_hcd, ohci1394, eth0
 11:          0          XT-PIC  Intel 440MX, Intel 440MX Modem
 12:         90          XT-PIC  i8042
 14:       2191          XT-PIC  ide0
NMI:          0
ERR:          3

As you can see, acpi is using IRQ 9. When I suspend (S3) and wakeup I get the following messages:

Nov  5 12:49:00 samt kernel: PM: Preparing system for suspend
Nov  5 12:49:00 samt kernel: Stopping tasks: =======================================|
Nov  5 12:49:00 samt kernel: PM: Entering state.
Nov  5 12:49:00 samt kernel: Back to C!
Nov  5 12:49:00 samt kernel: irq 9: nobody cared!
Nov  5 12:49:00 samt kernel:  [<c010724a>] __report_bad_irq+0x2a/0x90
Nov  5 12:49:00 samt kernel:  [<c0107340>] note_interrupt+0x70/0xb0
Nov  5 12:49:00 samt kernel:  [<c01075f0>] do_IRQ+0x120/0x130
Nov  5 12:49:00 samt kernel:  [<c01053c8>] common_interrupt+0x18/0x20
Nov  5 12:49:00 samt kernel:  [<c013007b>] unqueue_me+0x3b/0xb0
Nov  5 12:49:00 samt kernel:  [<c012046e>] __do_softirq+0x2e/0x90
Nov  5 12:49:00 samt kernel:  [<c01204f7>] do_softirq+0x27/0x30
Nov  5 12:49:00 samt kernel:  [<c01075ca>] do_IRQ+0xfa/0x130
Nov  5 12:49:00 samt kernel:  [<c01053c8>] common_interrupt+0x18/0x20
Nov  5 12:49:00 samt kernel:  [<c0134ca8>] suspend_enter+0x38/0x50
Nov  5 12:49:00 samt kernel:  [<c0134d84>] enter_state+0x64/0xb0
Nov  5 12:49:00 samt kernel:  [<c02020c9>] acpi_suspend+0x3e/0x4d
Nov  5 12:49:00 samt kernel:  [<c0202478>] acpi_system_write_sleep+0x60/0x8b
Nov  5 12:49:00 samt kernel:  [<c020248d>] acpi_system_write_sleep+0x75/0x8b
Nov  5 12:49:00 samt kernel:  [<c0155a68>] vfs_write+0xb8/0x130
Nov  5 12:49:00 samt kernel:  [<c0154f99>] filp_close+0x59/0x90
Nov  5 12:49:00 samt cardmgr[1467]: executing: './network suspend eth1'
Nov  5 12:49:00 samt kernel:  [<c0155bb1>] sys_write+0x51/0x80
Nov  5 12:49:00 samt kernel:  [<c010525b>] syscall_call+0x7/0xb
Nov  5 12:49:00 samt kernel: handlers:
Nov  5 12:49:00 samt kernel: [<c01eb827>] (acpi_irq+0x0/0x16)
Nov  5 12:49:00 samt kernel: Disabling IRQ #9
Nov  5 12:49:00 samt kernel: PM: Finishing up.
Nov  5 12:49:00 samt kernel: ACPI: PCI interrupt 0000:00:00.1[B] -> GSI 11 (level, low) -> IRQ 11
Nov  5 12:49:00 samt kernel: PCI: Setting latency timer of device 0000:00:00.1 to 64
Nov  5 12:49:00 samt kernel: ACPI: PCI interrupt 0000:00:00.2[B] -> GSI 11 (level, low) -> IRQ 11
Nov  5 12:49:00 samt kernel: PCI: Setting latency timer of device 0000:00:00.2 to 64
Nov  5 12:49:00 samt kernel: eth0: link down
Nov  5 12:49:00 samt kernel: ACPI: PCI interrupt 0000:00:05.0[A] -> GSI 10 (level, low) -> IRQ 10
Nov  5 12:49:00 samt kernel: hub 1-0:1.0: reactivate --> -22
Nov  5 12:49:00 samt kernel: Restarting tasks... done

As you can see, IRQ 9 gets lost here and consequently, the next ACPI event (e.g. lid button) causes a system freeze. I dug the ML and found the "irq routing after s3 ssuspend patch by Nathan Bryant but it seems to be in 2.6.9 already. I also tried the "pci device resume" patch from Stefan Dösinger, with no effect. Last but not least I tried various (but probably not all) kernel options like noapic, lapic and even acpi_sci - no luck.

I'd appreciate any hint on what I could try to circumvent this problem. I guess mangling the DSDT could be helpful but I have no idea how to begin with that. So I you have an idea or patch for me to try, please dont hesitate to write a note.

---------------

2) the annoyance: The tm100, as opposed to any other laptop I know, begins to emit lots of acpi battery events when the battery module is loaded. At least once every SECOND events like this show up in the logs:

[Thu Oct 28 20:57:55] BEGIN HANDLER MESSAGES
[Thu Oct 28 20:57:55] END HANDLER MESSAGES
[Thu Oct 28 20:57:55] action exited with status 0
[Thu Oct 28 20:57:55] completed event "battery BAT0 00000080 00000001"
[Thu Oct 28 20:57:55] received event "battery BAT0 00000080 00000001"
[Thu Oct 28 20:57:55] executing action "/etc/acpi/actions/lm_battery.sh battery BAT0 00000080 00000001"
[Thu Oct 28 20:57:55] BEGIN HANDLER MESSAGES
[Thu Oct 28 20:57:55] END HANDLER MESSAGES
[Thu Oct 28 20:57:55] action exited with status 0
[Thu Oct 28 20:57:55] completed event "battery BAT0 00000080 00000001"
[Thu Oct 28 20:57:56] received event "battery BAT0 00000080 00000001"
[Thu Oct 28 20:57:56] executing action "/etc/acpi/actions/lm_battery.sh battery BAT0 00000080 00000001"

Is this a bug in the acpi code or in the laptop? Any idea how this could be toned down to a sensible amount of events?

---------------

I'll glady provide any extra information you might ask for. Thanks to you all for doing such a great job with Linux-ACPI.

br,
Fionn

-------------------------------------------------------
This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE LinuxWorld Reader's Choice Award Winner for best database on Linux.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click

Fionn Behrens

author

2004-11-09 17:46 UTC #1 lore raw

Fionn Behrens wrote:

and nobody cared indeed :-/

looks like another round of apm kernels then.