Skip to contentSkip to conversation

acpi/suspend - irq 9: nobody cared

PATCH In review Bob Copeland 7 participants 12 messages May 7, 2009 – May 16, 2009 1 message not in the archive

Subsystems (2)
ACPI ACPI component architecture (acpica)
lore
Share & tools
lore

Bob Copeland

author
#0 lore raw

Hi,

I have been seeing the following in 2.6.30 whenever I suspend to ram. The power button no longer works afterwards. I don't recall any problems with 2.6.29. Anyone have any ideas before I try bisecting?

(The previous W taint is something unrelated.)

[31263.940249] appletouch: Geyser mode initialized.
[31263.941375] usb 4-2: type resume
[31264.043112] usb 4-2: reset full speed USB device using uhci_hcd and address 2
[31264.183582] usb 5-1: type resume
[31264.283313] irq 9: nobody cared (try booting with the "irqpoll" option)
[31264.283318] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.283320] Call Trace:
[31264.283328]  [<c015a01a>] __report_bad_irq+0x33/0x74
[31264.283333]  [<c015a150>] note_interrupt+0xf5/0x14d
[31264.283337]  [<c015a6bf>] handle_fasteoi_irq+0x8c/0xb0
[31264.283342]  [<c0104601>] handle_irq+0x40/0x4b
[31264.283348]  [<c035a322>] do_IRQ+0x4a/0x8c
[31264.283352]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.283358]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.283362]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.283375]  [<f891c00f>] ? acpi_idle_enter_c1+0xad/0xb9 [processor]
[31264.283380]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.283384]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.283388]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.283394]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.283398]  [<c04df037>] __init_begin+0x37/0x3c
[31264.283400] handlers:
[31264.283402] [<c022cabc>] (acpi_irq+0x0/0x2e)
[31264.283408] Disabling IRQ #9
[31264.285035] usb 5-1: reset full speed USB device using uhci_hcd and address 2
[31264.383127] ------------[ cut here ]------------
[31264.383132] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x40/0x179()
[31264.383137] Hardware name: MacBook1,1
[31264.383140] BUG: IRQ handler called from non-hardirq context!Modules linked in: fuse i915 drm af_packet acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod arc4 ecb ath5k snd_hda_codec_idt snd_hda_intel hid_apple appletouch snd_hda_codec mac80211 usbhid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq ath snd_seq_device sky2 ohci1394 snd_pcm_oss snd_mixer_oss cfg80211 ieee1394 processor button snd_pcm snd_timer uhci_hcd ehci_hcd bitrev snd ac battery thermal snd_page_alloc crc32 sg joydev sr_mod applesmc input_polldev evdev cdrom unix [last unloaded: microcode]
[31264.383241] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.383245] Call Trace:
[31264.383254]  [<c012590f>] warn_slowpath+0x76/0xa5
[31264.383264]  [<c01473e5>] ? print_lock_contention_bug+0x14/0xd7
[31264.383272]  [<c013bb30>] ? sched_clock_cpu+0x92/0x2f1
[31264.383281]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.383290]  [<c035659a>] ? _spin_unlock_irqrestore+0x3b/0x5d
[31264.383298]  [<c0145473>] ? trace_hardirqs_on_caller+0x18/0x13d
[31264.383307]  [<c03565a6>] ? _spin_unlock_irqrestore+0x47/0x5d
[31264.383315]  [<c0159f0d>] ? try_one_irq+0x92/0xf7
[31264.383323]  [<c0158f31>] handle_IRQ_event+0x40/0x179
[31264.383331]  [<c0159f25>] try_one_irq+0xaa/0xf7
[31264.383340]  [<c0159fa1>] poll_all_shared_irqs+0x2f/0x44
[31264.383348]  [<c0159fc3>] poll_spurious_irqs+0xd/0x22
[31264.383356]  [<c012d860>] run_timer_softirq+0x196/0x20f
[31264.383363]  [<c012d7e1>] ? run_timer_softirq+0x117/0x20f
[31264.383372]  [<c0159fb6>] ? poll_spurious_irqs+0x0/0x22
[31264.383381]  [<c0129f91>] __do_softirq+0xb1/0x182
[31264.383390]  [<c012a092>] do_softirq+0x30/0x48
[31264.383397]  [<c012a20a>] irq_exit+0x3d/0x74
[31264.383405]  [<c035a34e>] do_IRQ+0x76/0x8c
[31264.383413]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.383422]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.383440]  [<f891c281>] ? acpi_idle_enter_bm+0x266/0x291 [processor]
[31264.383450]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.383458]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.383465]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.383482]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.383487]  [<c04df037>] __init_begin+0x37/0x3c
[31264.383489] ---[ end trace 576a96bb93c6d61f ]---
[31264.460510] ieee80211 phy0: legacy class resume
[31264.460589] drm card0: legacy class resume
[31264.460634] pci 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900003)
[31264.460661] pci 0000:00:02.0: setting latency timer to 64

bob@sludge wireless-testing]$ cat /proc/interrupts
CPU0 CPU1

  0:    1967552          0   IO-APIC-edge      timer
  8:         84          0   IO-APIC-edge      rtc0
  9:     138333     261669   IO-APIC-fasteoi   acpi
 14:     329504          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:       1918      84773   IO-APIC-fasteoi   uhci_hcd:usb5, eth0, i915@pci:0000:00:02.0
 17:     127320          0   IO-APIC-fasteoi   ath
 18:         69          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:       4230     117896   IO-APIC-fasteoi   ata_piix, uhci_hcd:usb3, ohci1394
 21:        744      79985   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 22:        268          0   IO-APIC-fasteoi   HDA Intel
NMI:          0          0   Non-maskable interrupts
LOC:     357130    1384924   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:     243366     162707   Rescheduling interrupts
CAL:        193        367   Function call interrupts
TLB:       2533       2519   TLB shootdowns
TRM:          0          0   Thermal event interrupts
ERR:          0
MIS:          0
Signature · 1 line
Bob Copeland %% www.bobcopeland.com
#1 lore raw
Quoted 6 lines · Bob Copeland

Hi,

I have been seeing the following in 2.6.30 whenever I suspend to ram. The power button no longer works afterwards. I don't recall any problems with 2.6.29. Anyone have any ideas before I try bisecting? From the description it seems that this is a regression.

Will you please use git-bisect to identify the commit which causes the regression?

Thanks.

Quoted 90 lines

(The previous W taint is something unrelated.)

[31263.940249] appletouch: Geyser mode initialized.
[31263.941375] usb 4-2: type resume
[31264.043112] usb 4-2: reset full speed USB device using uhci_hcd and address 2
[31264.183582] usb 5-1: type resume
[31264.283313] irq 9: nobody cared (try booting with the "irqpoll" option)
[31264.283318] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.283320] Call Trace:
[31264.283328]  [<c015a01a>] __report_bad_irq+0x33/0x74
[31264.283333]  [<c015a150>] note_interrupt+0xf5/0x14d
[31264.283337]  [<c015a6bf>] handle_fasteoi_irq+0x8c/0xb0
[31264.283342]  [<c0104601>] handle_irq+0x40/0x4b
[31264.283348]  [<c035a322>] do_IRQ+0x4a/0x8c
[31264.283352]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.283358]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.283362]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.283375]  [<f891c00f>] ? acpi_idle_enter_c1+0xad/0xb9 [processor]
[31264.283380]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.283384]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.283388]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.283394]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.283398]  [<c04df037>] __init_begin+0x37/0x3c
[31264.283400] handlers:
[31264.283402] [<c022cabc>] (acpi_irq+0x0/0x2e)
[31264.283408] Disabling IRQ #9
[31264.285035] usb 5-1: reset full speed USB device using uhci_hcd and address 2
[31264.383127] ------------[ cut here ]------------
[31264.383132] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x40/0x179()
[31264.383137] Hardware name: MacBook1,1
[31264.383140] BUG: IRQ handler called from non-hardirq context!Modules linked in: fuse i915 drm af_packet acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod arc4 ecb ath5k snd_hda_codec_idt snd_hda_intel hid_apple appletouch snd_hda_codec mac80211 usbhid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq ath snd_seq_device sky2 ohci1394 snd_pcm_oss snd_mixer_oss cfg80211 ieee1394 processor button snd_pcm snd_timer uhci_hcd ehci_hcd bitrev snd ac battery thermal snd_page_alloc crc32 sg joydev sr_mod applesmc input_polldev evdev cdrom unix [last unloaded: microcode]
[31264.383241] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.383245] Call Trace:
[31264.383254]  [<c012590f>] warn_slowpath+0x76/0xa5
[31264.383264]  [<c01473e5>] ? print_lock_contention_bug+0x14/0xd7
[31264.383272]  [<c013bb30>] ? sched_clock_cpu+0x92/0x2f1
[31264.383281]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.383290]  [<c035659a>] ? _spin_unlock_irqrestore+0x3b/0x5d
[31264.383298]  [<c0145473>] ? trace_hardirqs_on_caller+0x18/0x13d
[31264.383307]  [<c03565a6>] ? _spin_unlock_irqrestore+0x47/0x5d
[31264.383315]  [<c0159f0d>] ? try_one_irq+0x92/0xf7
[31264.383323]  [<c0158f31>] handle_IRQ_event+0x40/0x179
[31264.383331]  [<c0159f25>] try_one_irq+0xaa/0xf7
[31264.383340]  [<c0159fa1>] poll_all_shared_irqs+0x2f/0x44
[31264.383348]  [<c0159fc3>] poll_spurious_irqs+0xd/0x22
[31264.383356]  [<c012d860>] run_timer_softirq+0x196/0x20f
[31264.383363]  [<c012d7e1>] ? run_timer_softirq+0x117/0x20f
[31264.383372]  [<c0159fb6>] ? poll_spurious_irqs+0x0/0x22
[31264.383381]  [<c0129f91>] __do_softirq+0xb1/0x182
[31264.383390]  [<c012a092>] do_softirq+0x30/0x48
[31264.383397]  [<c012a20a>] irq_exit+0x3d/0x74
[31264.383405]  [<c035a34e>] do_IRQ+0x76/0x8c
[31264.383413]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.383422]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.383440]  [<f891c281>] ? acpi_idle_enter_bm+0x266/0x291 [processor]
[31264.383450]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.383458]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.383465]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.383482]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.383487]  [<c04df037>] __init_begin+0x37/0x3c
[31264.383489] ---[ end trace 576a96bb93c6d61f ]---
[31264.460510] ieee80211 phy0: legacy class resume
[31264.460589] drm card0: legacy class resume
[31264.460634] pci 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900003)
[31264.460661] pci 0000:00:02.0: setting latency timer to 64

bob@sludge wireless-testing]$ cat /proc/interrupts
CPU0 CPU1

  0:    1967552          0   IO-APIC-edge      timer
  8:         84          0   IO-APIC-edge      rtc0
  9:     138333     261669   IO-APIC-fasteoi   acpi
 14:     329504          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:       1918      84773   IO-APIC-fasteoi   uhci_hcd:usb5, eth0, i915@pci:0000:00:02.0
 17:     127320          0   IO-APIC-fasteoi   ath
 18:         69          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:       4230     117896   IO-APIC-fasteoi   ata_piix, uhci_hcd:usb3, ohci1394
 21:        744      79985   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 22:        268          0   IO-APIC-fasteoi   HDA Intel
NMI:          0          0   Non-maskable interrupts
LOC:     357130    1384924   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:     243366     162707   Rescheduling interrupts
CAL:        193        367   Function call interrupts
TLB:       2533       2519   TLB shootdowns
TRM:          0          0   Thermal event interrupts
ERR:          0
MIS:          0
#2 lore raw
Quoted 9 lines · yakui_zhao
Quoted 6 lines · Bob Copeland

Hi,

I have been seeing the following in 2.6.30 whenever I suspend to ram. The power button no longer works afterwards. I don't recall any problems with 2.6.29. Anyone have any ideas before I try bisecting? From the description it seems that this is a regression.

Will you please use git-bisect to identify the commit which causes the regression?

Even if you can't bisect this, can you please open a bugzilla at
http://bugzilla.kernel.org ? Also, if you can verify that it is really a regression since 2.6.29, please drop a note to Rafael, who tracks regressions. Plus, he knows all about suspend/resume, so maybe he can even fix it :)

Maybe we quit handling fixed hardware events or GPEs for some reason.

Bjorn

Quoted 96 lines
Quoted 80 lines

(The previous W taint is something unrelated.)

[31263.940249] appletouch: Geyser mode initialized.
[31263.941375] usb 4-2: type resume
[31264.043112] usb 4-2: reset full speed USB device using uhci_hcd and address 2
[31264.183582] usb 5-1: type resume
[31264.283313] irq 9: nobody cared (try booting with the "irqpoll" option)
[31264.283318] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.283320] Call Trace:
[31264.283328]  [<c015a01a>] __report_bad_irq+0x33/0x74
[31264.283333]  [<c015a150>] note_interrupt+0xf5/0x14d
[31264.283337]  [<c015a6bf>] handle_fasteoi_irq+0x8c/0xb0
[31264.283342]  [<c0104601>] handle_irq+0x40/0x4b
[31264.283348]  [<c035a322>] do_IRQ+0x4a/0x8c
[31264.283352]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.283358]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.283362]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.283375]  [<f891c00f>] ? acpi_idle_enter_c1+0xad/0xb9 [processor]
[31264.283380]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.283384]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.283388]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.283394]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.283398]  [<c04df037>] __init_begin+0x37/0x3c
[31264.283400] handlers:
[31264.283402] [<c022cabc>] (acpi_irq+0x0/0x2e)
[31264.283408] Disabling IRQ #9
[31264.285035] usb 5-1: reset full speed USB device using uhci_hcd and address 2
[31264.383127] ------------[ cut here ]------------
[31264.383132] WARNING: at kernel/irq/handle.c:366 handle_IRQ_event+0x40/0x179()
[31264.383137] Hardware name: MacBook1,1
[31264.383140] BUG: IRQ handler called from non-hardirq context!Modules linked in: fuse i915 drm af_packet acpi_cpufreq binfmt_misc dm_mirror dm_region_hash dm_log dm_multipath dm_mod arc4 ecb ath5k snd_hda_codec_idt snd_hda_intel hid_apple appletouch snd_hda_codec mac80211 usbhid snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq ath snd_seq_device sky2 ohci1394 snd_pcm_oss snd_mixer_oss cfg80211 ieee1394 processor button snd_pcm snd_timer uhci_hcd ehci_hcd bitrev snd ac battery thermal snd_page_alloc crc32 sg joydev sr_mod applesmc input_polldev evdev cdrom unix [last unloaded: microcode]
[31264.383241] Pid: 0, comm: swapper Tainted: G        W  2.6.30-rc4-wl #116
[31264.383245] Call Trace:
[31264.383254]  [<c012590f>] warn_slowpath+0x76/0xa5
[31264.383264]  [<c01473e5>] ? print_lock_contention_bug+0x14/0xd7
[31264.383272]  [<c013bb30>] ? sched_clock_cpu+0x92/0x2f1
[31264.383281]  [<c01455a3>] ? trace_hardirqs_on+0xb/0xd
[31264.383290]  [<c035659a>] ? _spin_unlock_irqrestore+0x3b/0x5d
[31264.383298]  [<c0145473>] ? trace_hardirqs_on_caller+0x18/0x13d
[31264.383307]  [<c03565a6>] ? _spin_unlock_irqrestore+0x47/0x5d
[31264.383315]  [<c0159f0d>] ? try_one_irq+0x92/0xf7
[31264.383323]  [<c0158f31>] handle_IRQ_event+0x40/0x179
[31264.383331]  [<c0159f25>] try_one_irq+0xaa/0xf7
[31264.383340]  [<c0159fa1>] poll_all_shared_irqs+0x2f/0x44
[31264.383348]  [<c0159fc3>] poll_spurious_irqs+0xd/0x22
[31264.383356]  [<c012d860>] run_timer_softirq+0x196/0x20f
[31264.383363]  [<c012d7e1>] ? run_timer_softirq+0x117/0x20f
[31264.383372]  [<c0159fb6>] ? poll_spurious_irqs+0x0/0x22
[31264.383381]  [<c0129f91>] __do_softirq+0xb1/0x182
[31264.383390]  [<c012a092>] do_softirq+0x30/0x48
[31264.383397]  [<c012a20a>] irq_exit+0x3d/0x74
[31264.383405]  [<c035a34e>] do_IRQ+0x76/0x8c
[31264.383413]  [<c010312e>] common_interrupt+0x2e/0x34
[31264.383422]  [<c014007b>] ? timer_list_show+0x1b3/0x939
[31264.383440]  [<f891c281>] ? acpi_idle_enter_bm+0x266/0x291 [processor]
[31264.383450]  [<c02d20ee>] cpuidle_idle_call+0x6a/0x9c
[31264.383458]  [<c0101cc8>] cpu_idle+0x53/0x87
[31264.383465]  [<c03467e0>] rest_init+0x6c/0x6e
[31264.383482]  [<c04df74d>] start_kernel+0x286/0x28b
[31264.383487]  [<c04df037>] __init_begin+0x37/0x3c
[31264.383489] ---[ end trace 576a96bb93c6d61f ]---
[31264.460510] ieee80211 phy0: legacy class resume
[31264.460589] drm card0: legacy class resume
[31264.460634] pci 0000:00:02.0: restoring config space at offset 0x1 (was 0x900007, writing 0x900003)
[31264.460661] pci 0000:00:02.0: setting latency timer to 64

bob@sludge wireless-testing]$ cat /proc/interrupts
CPU0 CPU1

  0:    1967552          0   IO-APIC-edge      timer
  8:         84          0   IO-APIC-edge      rtc0
  9:     138333     261669   IO-APIC-fasteoi   acpi
 14:     329504          0   IO-APIC-edge      ata_piix
 15:          0          0   IO-APIC-edge      ata_piix
 16:       1918      84773   IO-APIC-fasteoi   uhci_hcd:usb5, eth0, i915@pci:0000:00:02.0
 17:     127320          0   IO-APIC-fasteoi   ath
 18:         69          0   IO-APIC-fasteoi   uhci_hcd:usb4
 19:       4230     117896   IO-APIC-fasteoi   ata_piix, uhci_hcd:usb3, ohci1394
 21:        744      79985   IO-APIC-fasteoi   ehci_hcd:usb1, uhci_hcd:usb2
 22:        268          0   IO-APIC-fasteoi   HDA Intel
NMI:          0          0   Non-maskable interrupts
Quoted 9 lines
LOC:     357130    1384924   Local timer interrupts
SPU:          0          0   Spurious interrupts
RES:     243366     162707   Rescheduling interrupts
CAL:        193        367   Function call interrupts
TLB:       2533       2519   TLB shootdowns
TRM:          0          0   Thermal event interrupts
ERR:          0
MIS:          0

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

author
#3 lore raw
Quoted 5 lines · Bjorn Helgaas

Even if you can't bisect this, can you please open a bugzilla at
http://bugzilla.kernel.org ?  Also, if you can verify that it is really a regression since 2.6.29, please drop a note to Rafael, who tracks regressions.  Plus, he knows all about suspend/resume, so maybe he can even fix it :)

Yeah, I'll open a bug report for it. I'm in the process of bisecting but there's a boot hang somewhere in the window (2.6.29 <-> .30-rc2) so it's taking some time.

Signature · 5 lines
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
author
#4 lore raw

[BISECTED] Was Re: acpi/suspend - irq 9: nobody cared

In reply to Bjorn Helgaas
Quoted 2 lines · Bjorn Helgaas

Even if you can't bisect this, can you please open a bugzilla at
http://bugzilla.kernel.org?

Done: http://bugzilla.kernel.org/show_bug.cgi?id=13289

I have bisected it. I don't know if it's related, but I have a "MacBook 1,1" which in sleep.c has a quirk related to SCI_EN, and I see that this patch changed ACPI_PM1_CONTROL_PRESERVED_BITS to include SCI_EN. I have verified that reverting the patch on top of latest -rc prevents irq 9 from being disabled.

commit 20869dcfde204e1c21b642608d708d82472fee2b

Author: Bob Moore <[email protected]>
Date:   Fri Mar 13 09:10:46 2009 +0800

ACPICA: Preserve all PM control reserved and ignored bits

As per the ACPI specification, preserve (read/modify/write) all bits that are defined as either reserved or ignored (PM control control registers only.)

Signed-off-by Bob Moore <[email protected]>
Signed-off-by Lin Ming <[email protected]>
Signed-off-by Len Brown <[email protected]>
drivers/acpi/acpica/aclocal.h +9 -1
index 18a8d96..f01e155 100644
@@ -780,7 +780,15 @@ struct acpi_bit_register_info {
  * must be preserved.
  */
 #define ACPI_PM1_STATUS_PRESERVED_BITS          0x0800	/* Bit 11 */
-#define ACPI_PM1_CONTROL_PRESERVED_BITS         0x0200	/* Bit 9 (whatever) */
+
+/* For control registers, both ignored and reserved bits must be preserved */
+
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9, 0(SCI_EN) */
+#define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8	/* Bits 14-15, 3-8 */
+#define ACPI_PM1_CONTROL_PRESERVED_BITS \
+	       (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)
+
+#define ACPI_PM2_CONTROL_PRESERVED_BITS         0xFFFFFFFE	/* All except bit 0 */
 
 /*
  * Register IDs
drivers/acpi/acpica/hwregs.c +15 -0
index fd7abe2..6117362 100644
@@ -328,6 +328,21 @@ acpi_status acpi_hw_register_write(u32 register_id, u32 value)
 
 	case ACPI_REGISTER_PM2_CONTROL:	/* 8-bit access */
 
+		/*
+		 * For control registers, all reserved bits must be preserved,
+		 * as per the ACPI spec.
+		 */
+		status =
+		    acpi_read(&read_value, &acpi_gbl_FADT.xpm2_control_block);
+		if (ACPI_FAILURE(status)) {
+			goto exit;
+		}
+
+		/* Insert the bits to be preserved */
+
+		ACPI_INSERT_BITS(value, ACPI_PM2_CONTROL_PRESERVED_BITS,
+				 read_value);
+
 		status = acpi_write(value, &acpi_gbl_FADT.xpm2_control_block);
 		break;
Signature · 1 line
Bob Copeland %% www.bobcopeland.com

A message that is not in the archive (sent off-list or not yet received): [email protected]

#6 lore raw

Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared

Quoted 17 lines

From: Bob Copeland <[email protected]>
Date: Wed, May 13, 2009 at 12:05 PM
Subject: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
To: Bjorn Helgaas <[email protected]>
Cc: yakui_zhao <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Rafael J. Wysocki" <[email protected]>, [email protected]

Quoted 2 lines · Bjorn Helgaas

Even if you can't bisect this, can you please open a bugzilla at
http://bugzilla.kernel.org?

Done: http://bugzilla.kernel.org/show_bug.cgi?id=13289

Quoted 7 lines

I have bisected it. I don't know if it's related, but I have a "MacBook 1,1" which in sleep.c has a quirk related to SCI_EN, and I see that this patch changed ACPI_PM1_CONTROL_PRESERVED_BITS to include SCI_EN. I have verified that reverting the patch on top of latest -rc prevents irq 9 from being disabled.

From ACPI Spec 3.0a 4.7.3.2.1,

"SCI_EN: Selects the power management event to be either an SCI or SMI interrupt for the following events. When this bit is set, then power management events will generate an SCI interrupt. When this bit is reset power management events will generate an SMI interrupt. It is the responsibility of the hardware to set or reset this bit. OSPM always preserves this bit position."

So we preserve SCI_EN bit per spec.

Anyway, would you please try below patch to see if the bug is caused by SCI_EN bit preserved?

drivers/acpi/acpica/aclocal.h +1 -1
index 772ee5c..3d082bb 100644
@@ -787,7 +787,7 @@ struct acpi_bit_register_info {
 
 /* For control registers, both ignored and reserved bits must be preserved */
 
-#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9, 0(SCI_EN) */
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0200	/* Bits 9 */
 #define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8	/* Bits 14-15, 3-8 */
 #define ACPI_PM1_CONTROL_PRESERVED_BITS \
 	       (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)

---
Lin Ming

Quoted 73 lines

commit 20869dcfde204e1c21b642608d708d82472fee2b

Author: Bob Moore <[email protected]>
Date:   Fri Mar 13 09:10:46 2009 +0800

ACPICA: Preserve all PM control reserved and ignored bits

As per the ACPI specification, preserve (read/modify/write) all bits that are defined as either reserved or ignored (PM control control registers only.)

Signed-off-by Bob Moore <[email protected]>
Signed-off-by Lin Ming <[email protected]>
Signed-off-by Len Brown <[email protected]>
drivers/acpi/acpica/aclocal.h +9 -1
index 18a8d96..f01e155 100644
@@ -780,7 +780,15 @@ struct acpi_bit_register_info {
 * must be preserved.
 */
 #define ACPI_PM1_STATUS_PRESERVED_BITS          0x0800 /* Bit 11 */
-#define ACPI_PM1_CONTROL_PRESERVED_BITS         0x0200 /* Bit 9 (whatever) */
+
+/* For control registers, both ignored and reserved bits must be preserved */
+
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201 /* Bits 9, 0(SCI_EN) */
+#define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8 /* Bits 14-15, 3-8 */
+#define ACPI_PM1_CONTROL_PRESERVED_BITS \
+              (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)
+
+#define ACPI_PM2_CONTROL_PRESERVED_BITS         0xFFFFFFFE     /* All

except bit 0 */

/*
* Register IDs

drivers/acpi/acpica/hwregs.c +15 -1
index fd7abe2..6117362 100644
@@ -328,6 +328,21 @@ acpi_status acpi_hw_register_write(u32
 register_id, u32 value)
 
       case ACPI_REGISTER_PM2_CONTROL: /* 8-bit access */
 
+               /*
+                * For control registers, all reserved bits must be preserved,
+                * as per the ACPI spec.
+                */
+               status =
+                   acpi_read(&read_value, &acpi_gbl_FADT.xpm2_control_block);
+               if (ACPI_FAILURE(status)) {
+                       goto exit;
+               }
+
+               /* Insert the bits to be preserved */
+
+               ACPI_INSERT_BITS(value, ACPI_PM2_CONTROL_PRESERVED_BITS,
+                                read_value);
+
               status = acpi_write(value, &acpi_gbl_FADT.xpm2_control_block);
               break;
 
 
 
--

Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

#7 lore raw

Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared

Quoted 25 lines · Lin Ming
Quoted 17 lines

From: Bob Copeland <[email protected]>
Date: Wed, May 13, 2009 at 12:05 PM
Subject: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
To: Bjorn Helgaas <[email protected]>
Cc: yakui_zhao <[email protected]>, "[email protected]" <[email protected]>, "[email protected]" <[email protected]>, "Rafael J. Wysocki" <[email protected]>, [email protected]

Quoted 2 lines · Bjorn Helgaas

Even if you can't bisect this, can you please open a bugzilla at
http://bugzilla.kernel.org?

Done: http://bugzilla.kernel.org/show_bug.cgi?id=13289

Quoted 7 lines

I have bisected it. I don't know if it's related, but I have a "MacBook 1,1" which in sleep.c has a quirk related to SCI_EN, and I see that this patch changed ACPI_PM1_CONTROL_PRESERVED_BITS to include SCI_EN. I have verified that reverting the patch on top of latest -rc prevents irq 9 from being disabled.

From ACPI Spec 3.0a 4.7.3.2.1,

Quoted 8 lines

"SCI_EN: Selects the power management event to be either an SCI or SMI interrupt for the following events. When this bit is set, then power management events will generate an SCI interrupt. When this bit is reset power management events will generate an SMI interrupt. It is the responsibility of the hardware to set or reset this bit. OSPM always preserves this bit position."

So we preserve SCI_EN bit per spec.

In fact we do set SCI_EN directly in drivers/acpi/sleep.c in a couple of places exactly because the hardware is _known_ to wrong things here. So, we don't really preserve it, _exactly_ because at least some pieces of hardware out there don't follow the spec. Including Macs, IIRC.

Bob, can you please verify if the Lin Ming's patch helps?

Rafael

Quoted 96 lines

Anyway, would you please try below patch to see if the bug is caused by SCI_EN bit preserved?

drivers/acpi/acpica/aclocal.h +1 -2
index 772ee5c..3d082bb 100644
@@ -787,7 +787,7 @@ struct acpi_bit_register_info {
 
 /* For control registers, both ignored and reserved bits must be preserved */
 
-#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9, 0(SCI_EN) */
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0200	/* Bits 9 */
 #define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8	/* Bits 14-15, 3-8 */
 #define ACPI_PM1_CONTROL_PRESERVED_BITS \
 	       (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)
 
---

Lin Ming

Quoted 73 lines

commit 20869dcfde204e1c21b642608d708d82472fee2b

Author: Bob Moore <[email protected]>
Date:   Fri Mar 13 09:10:46 2009 +0800

ACPICA: Preserve all PM control reserved and ignored bits

As per the ACPI specification, preserve (read/modify/write) all bits that are defined as either reserved or ignored (PM control control registers only.)

Signed-off-by Bob Moore <[email protected]>
Signed-off-by Lin Ming <[email protected]>
Signed-off-by Len Brown <[email protected]>
drivers/acpi/acpica/aclocal.h +9 -1
index 18a8d96..f01e155 100644
@@ -780,7 +780,15 @@ struct acpi_bit_register_info {
 * must be preserved.
 */
 #define ACPI_PM1_STATUS_PRESERVED_BITS          0x0800 /* Bit 11 */
-#define ACPI_PM1_CONTROL_PRESERVED_BITS         0x0200 /* Bit 9 (whatever) */
+
+/* For control registers, both ignored and reserved bits must be preserved */
+
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201 /* Bits 9, 0(SCI_EN) */
+#define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8 /* Bits 14-15, 3-8 */
+#define ACPI_PM1_CONTROL_PRESERVED_BITS \
+              (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)
+
+#define ACPI_PM2_CONTROL_PRESERVED_BITS         0xFFFFFFFE     /* All

except bit 0 */

/*
* Register IDs

drivers/acpi/acpica/hwregs.c +15 -1
index fd7abe2..6117362 100644
@@ -328,6 +328,21 @@ acpi_status acpi_hw_register_write(u32
 register_id, u32 value)
 
       case ACPI_REGISTER_PM2_CONTROL: /* 8-bit access */
 
+               /*
+                * For control registers, all reserved bits must be preserved,
+                * as per the ACPI spec.
+                */
+               status =
+                   acpi_read(&read_value, &acpi_gbl_FADT.xpm2_control_block);
+               if (ACPI_FAILURE(status)) {
+                       goto exit;
+               }
+
+               /* Insert the bits to be preserved */
+
+               ACPI_INSERT_BITS(value, ACPI_PM2_CONTROL_PRESERVED_BITS,
+                                read_value);
+
               status = acpi_write(value, &acpi_gbl_FADT.xpm2_control_block);
               break;
 
 
 
--

Bob Copeland %% www.bobcopeland.com

--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html

Signature · 3 lines
Everyone knows that debugging is twice as hard as writing a program
in the first place.  So if you're as clever as you can be when you write it,
how will you ever debug it? --- Brian Kernighan
author
#8 lore raw

Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared

2009/5/13 Rafael J. Wysocki <[email protected]>:

Quoted 8 lines
Quoted 1 line

So we preserve SCI_EN bit per spec.

In fact we do set SCI_EN directly in drivers/acpi/sleep.c in a couple of places exactly because the hardware is _known_ to wrong things here.  So, we don't really preserve it, _exactly_ because at least some pieces of hardware out there don't follow the spec.  Including Macs, IIRC.

Bob, can you please verify if the Lin Ming's patch helps?

Yes, my laptop is one of those pieces of hardware. I can confirm that Lin Ming's patch works on my system.

Signature · 5 lines
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
reviewer
#9 lore raw

PATCH 1/1 ACPI: resume: re-enable SCI-enable workaround

From: Lin Ming <[email protected]>

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

(The BIOS is supposed to update SCI_EN, not the OS)

http://bugzilla.kernel.org/show_bug.cgi?id=13289

Signed-off-by Lin Ming <[email protected]>
Signed-off-by Len Brown <[email protected]>

---

as-applied.
thanks,
-Len

 drivers/acpi/acpica/aclocal.h |    7 ++++++-
 1 files changed, 6 insertions(+), 1 deletions(-)
drivers/acpi/acpica/aclocal.h +6 -1
index 772ee5c..2ec394a 100644
@@ -787,7 +787,12 @@ struct acpi_bit_register_info {
 
 /* For control registers, both ignored and reserved bits must be preserved */
 
-#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9, 0(SCI_EN) */
+/*
+ * The ACPI spec says to ignore PM1_CTL.SCI_EN (bit 0)
+ * but we need to be able to write ACPI_BITREG_SCI_ENABLE directly
+ * as a BIOS workaround on some machines.
+ */
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0200	/* Bits 9 */
 #define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8	/* Bits 14-15, 3-8 */
 #define ACPI_PM1_CONTROL_PRESERVED_BITS \
 	       (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)
Signature · 1 line
1.6.3.1.9.g95405b
#10 lore raw

RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround

Quoted 4 lines

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

Not exactly. ACPICA has always preserved the SCI_EN bit. Linux apparently has a "linux-only" patch to ACPICA that disables this.

The recent version of ACPICA change the #define enough such that the patch no longer works.

Quoted 54 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Friday, May 15, 2009 7:34 PM
To: Bob Copeland
Cc: Rafael J. Wysocki; Lin, Ming M; Bjorn Helgaas; Zhao, Yakui; linux- [email protected]; [email protected]; Moore, Robert
Subject: [PATCH] ACPI: resume: re-enable SCI-enable workaround

From: Lin Ming <[email protected]>

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

(The BIOS is supposed to update SCI_EN, not the OS)

http://bugzilla.kernel.org/show_bug.cgi?id=13289

Signed-off-by Lin Ming <[email protected]>
Signed-off-by Len Brown <[email protected]>

---

as-applied.
thanks,
-Len

drivers/acpi/acpica/aclocal.h | 7 ++++++-

1 files changed, 6 insertions(+), 1 deletions(-)
drivers/acpi/acpica/aclocal.h +0 -1
index 772ee5c..2ec394a 100644
@@ -787,7 +787,12 @@ struct acpi_bit_register_info {
 
 /* For control registers, both ignored and reserved bits must be preserved
 */
 
-#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201	/* Bits 9,

0(SCI_EN) */

drivers/acpi/acpica/aclocal.h +6 -0
+/*
+ * The ACPI spec says to ignore PM1_CTL.SCI_EN (bit 0)
+ * but we need to be able to write ACPI_BITREG_SCI_ENABLE directly
+ * as a BIOS workaround on some machines.
+ */
+#define ACPI_PM1_CONTROL_IGNORED_BITS           0x0200	/* Bits 9 */

#define ACPI_PM1_CONTROL_RESERVED_BITS 0xC1F8 /* Bits 14-15,
3-8 */
#define ACPI_PM1_CONTROL_PRESERVED_BITS \
(ACPI_PM1_CONTROL_IGNORED_BITS |
ACPI_PM1_CONTROL_RESERVED_BITS)
--
1.6.3.1.9.g95405b

reviewer
#11 lore raw

RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround

Quoted 8 lines
Quoted 4 lines

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

Not exactly. ACPICA has always preserved the SCI_EN bit. Linux apparently has a "linux-only" patch to ACPICA that disables this.

The recent version of ACPICA change the #define enough such that the patch no longer works.

"We" here means Linux, and thus the description is accurate.

The fact is that in 2.6.29 Linux had ACPI_PM1_CONTROL_PRESERVED_BITS 0x0200
and when "we" updated it to 0x201 via the ACPICA update, the workaround in the Linux resume code became a NOP.

-Len

#12 lore raw

RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround

ACPICA did not change the SCI_EN value. The #define associated with the control register has always been 0x0201 in ACPICA.

A linux patch changes the value from 0x0201 to 0x0200, and represents a divergence of linux from ACPICA.

What ACPICA did was to rename the #define, that is what broke the linux patch.

- #define ACPI_PM1_CONTROL_PRESERVED_BITS 0x0201 /* Bit 9, Bit 0 (SCI_EN) */

+ #define ACPI_PM1_CONTROL_IGNORED_BITS           0x0201  /* Bits 9, 0(SCI_EN) */
+ #define ACPI_PM1_CONTROL_RESERVED_BITS          0xC1F8  /* Bits 14-15, 3-8 */

+#define ACPI_PM1_CONTROL_PRESERVED_BITS \
+ (ACPI_PM1_CONTROL_IGNORED_BITS | ACPI_PM1_CONTROL_RESERVED_BITS)

Quoted 27 lines

-----Original Message-----
From: Len Brown [mailto:[email protected]]
Sent: Friday, May 15, 2009 10:50 PM
To: Moore, Robert
Cc: Bob Copeland; Rafael J. Wysocki; Lin, Ming M; Bjorn Helgaas; Zhao, Yakui; [email protected]; [email protected]
Subject: RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround

Quoted 5 lines
Quoted 3 lines

The BIOS bug workaround mistakenly got disabled when we followed the ACPI specification more closely by ignoring OS updates to that bit.

Not exactly. ACPICA has always preserved the SCI_EN bit. Linux apparently

has a "linux-only" patch to ACPICA that disables this.

Quoted 2 lines

The recent version of ACPICA change the #define enough such that the

patch no longer works.

"We" here means Linux, and thus the description is accurate.

The fact is that in 2.6.29 Linux had ACPI_PM1_CONTROL_PRESERVED_BITS 0x0200
and when "we" updated it to 0x201 via the ACPICA update, the workaround in the Linux resume code became a NOP.

-Len