* acpi/suspend - irq 9: nobody cared
@ 2009-05-07 10:58 Bob Copeland
2009-05-08 1:53 ` yakui_zhao
0 siblings, 1 reply; 14+ messages in thread
From: Bob Copeland @ 2009-05-07 10:58 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-acpi
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
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpi/suspend - irq 9: nobody cared
2009-05-07 10:58 acpi/suspend - irq 9: nobody cared Bob Copeland
@ 2009-05-08 1:53 ` yakui_zhao
2009-05-12 19:01 ` Bjorn Helgaas
0 siblings, 1 reply; 14+ messages in thread
From: yakui_zhao @ 2009-05-08 1:53 UTC (permalink / raw)
To: Bob Copeland; +Cc: linux-kernel, linux-acpi
On Thu, 2009-05-07 at 18:58 +0800, Bob Copeland wrote:
> 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.
>
> (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
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpi/suspend - irq 9: nobody cared
2009-05-08 1:53 ` yakui_zhao
@ 2009-05-12 19:01 ` Bjorn Helgaas
2009-05-12 19:26 ` Bob Copeland
2009-05-13 4:05 ` [BISECTED] Was " Bob Copeland
0 siblings, 2 replies; 14+ messages in thread
From: Bjorn Helgaas @ 2009-05-12 19:01 UTC (permalink / raw)
To: yakui_zhao; +Cc: Bob Copeland, linux-kernel, linux-acpi, Rafael J. Wysocki
On Thursday 07 May 2009 07:53:54 pm yakui_zhao wrote:
> On Thu, 2009-05-07 at 18:58 +0800, Bob Copeland wrote:
> > 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
> > (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
> >
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpi/suspend - irq 9: nobody cared
2009-05-12 19:01 ` Bjorn Helgaas
@ 2009-05-12 19:26 ` Bob Copeland
2009-05-13 4:05 ` [BISECTED] Was " Bob Copeland
1 sibling, 0 replies; 14+ messages in thread
From: Bob Copeland @ 2009-05-12 19:26 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: yakui_zhao, linux-kernel, linux-acpi, Rafael J. Wysocki
On Tue, May 12, 2009 at 3:01 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> 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.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: acpi/suspend - irq 9: nobody cared
@ 2009-05-12 19:26 ` Bob Copeland
0 siblings, 0 replies; 14+ messages in thread
From: Bob Copeland @ 2009-05-12 19:26 UTC (permalink / raw)
To: Bjorn Helgaas; +Cc: yakui_zhao, linux-kernel, linux-acpi, Rafael J. Wysocki
On Tue, May 12, 2009 at 3:01 PM, Bjorn Helgaas <bjorn.helgaas@hp.com> wrote:
> 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.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
2009-05-12 19:01 ` Bjorn Helgaas
2009-05-12 19:26 ` Bob Copeland
@ 2009-05-13 4:05 ` Bob Copeland
[not found] ` <d3f22a0905122245h15786220g31ad0dcb8caa3a38@mail.gmail.com>
1 sibling, 1 reply; 14+ messages in thread
From: Bob Copeland @ 2009-05-13 4:05 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: yakui_zhao, linux-kernel, linux-acpi, Rafael J. Wysocki, robert.moore
On Tue, May 12, 2009 at 01:01:06PM -0600, Bjorn Helgaas wrote:
> 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 <robert.moore@intel.com>
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 <robert.moore@intel.com>
Signed-off-by: Lin Ming <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 18a8d96..f01e155 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -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
diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
index fd7abe2..6117362 100644
--- a/drivers/acpi/acpica/hwregs.c
+++ b/drivers/acpi/acpica/hwregs.c
@@ -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
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
[not found] ` <d3f22a0905122245h15786220g31ad0dcb8caa3a38@mail.gmail.com>
@ 2009-05-13 5:36 ` Lin Ming
2009-05-13 8:15 ` Rafael J. Wysocki
0 siblings, 1 reply; 14+ messages in thread
From: Lin Ming @ 2009-05-13 5:36 UTC (permalink / raw)
To: Bob Copeland
Cc: Bjorn Helgaas, yakui_zhao, linux-kernel, linux-acpi,
Rafael J. Wysocki, Moore, Robert
> From: Bob Copeland <me@bobcopeland.com>
> Date: Wed, May 13, 2009 at 12:05 PM
> Subject: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
> To: Bjorn Helgaas <bjorn.helgaas@hp.com>
> Cc: yakui_zhao <yakui.zhao@intel.com>, "linux-kernel@vger.kernel.org"
> <linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
> <linux-acpi@vger.kernel.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
> robert.moore@intel.com
>
>
> On Tue, May 12, 2009 at 01:01:06PM -0600, Bjorn Helgaas wrote:
> > 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.
>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?
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 772ee5c..3d082bb 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -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
>
> commit 20869dcfde204e1c21b642608d708d82472fee2b
> Author: Bob Moore <robert.moore@intel.com>
> 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 <robert.moore@intel.com>
> Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> Signed-off-by: Len Brown <len.brown@intel.com>
>
> diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
> index 18a8d96..f01e155 100644
> --- a/drivers/acpi/acpica/aclocal.h
> +++ b/drivers/acpi/acpica/aclocal.h
> @@ -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
> diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
> index fd7abe2..6117362 100644
> --- a/drivers/acpi/acpica/hwregs.c
> +++ b/drivers/acpi/acpica/hwregs.c
> @@ -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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related [flat|nested] 14+ messages in thread
* Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
2009-05-13 5:36 ` Lin Ming
@ 2009-05-13 8:15 ` Rafael J. Wysocki
2009-05-13 15:30 ` Bob Copeland
0 siblings, 1 reply; 14+ messages in thread
From: Rafael J. Wysocki @ 2009-05-13 8:15 UTC (permalink / raw)
To: Lin Ming, Bob Copeland
Cc: Bjorn Helgaas, yakui_zhao, linux-kernel, linux-acpi, Moore, Robert
On Wednesday 13 May 2009, Lin Ming wrote:
>
> > From: Bob Copeland <me@bobcopeland.com>
> > Date: Wed, May 13, 2009 at 12:05 PM
> > Subject: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
> > To: Bjorn Helgaas <bjorn.helgaas@hp.com>
> > Cc: yakui_zhao <yakui.zhao@intel.com>, "linux-kernel@vger.kernel.org"
> > <linux-kernel@vger.kernel.org>, "linux-acpi@vger.kernel.org"
> > <linux-acpi@vger.kernel.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
> > robert.moore@intel.com
> >
> >
> > On Tue, May 12, 2009 at 01:01:06PM -0600, Bjorn Helgaas wrote:
> > > 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.
>
> >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.
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
> Anyway, would you please try below patch to see if the bug is caused by
> SCI_EN bit preserved?
>
> diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
> index 772ee5c..3d082bb 100644
> --- a/drivers/acpi/acpica/aclocal.h
> +++ b/drivers/acpi/acpica/aclocal.h
> @@ -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
>
> >
> > commit 20869dcfde204e1c21b642608d708d82472fee2b
> > Author: Bob Moore <robert.moore@intel.com>
> > 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 <robert.moore@intel.com>
> > Signed-off-by: Lin Ming <ming.m.lin@intel.com>
> > Signed-off-by: Len Brown <len.brown@intel.com>
> >
> > diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
> > index 18a8d96..f01e155 100644
> > --- a/drivers/acpi/acpica/aclocal.h
> > +++ b/drivers/acpi/acpica/aclocal.h
> > @@ -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
> > diff --git a/drivers/acpi/acpica/hwregs.c b/drivers/acpi/acpica/hwregs.c
> > index fd7abe2..6117362 100644
> > --- a/drivers/acpi/acpica/hwregs.c
> > +++ b/drivers/acpi/acpica/hwregs.c
> > @@ -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 majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
>
--
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
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
2009-05-13 8:15 ` Rafael J. Wysocki
@ 2009-05-13 15:30 ` Bob Copeland
0 siblings, 0 replies; 14+ messages in thread
From: Bob Copeland @ 2009-05-13 15:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Lin Ming, Bjorn Helgaas, yakui_zhao, linux-kernel, linux-acpi,
Moore, Robert
2009/5/13 Rafael J. Wysocki <rjw@sisk.pl>:
>> 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.
--
Bob Copeland %% www.bobcopeland.com
--
To unsubscribe from this list: send the line "unsubscribe linux-acpi" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: [BISECTED] Was Re: acpi/suspend - irq 9: nobody cared
@ 2009-05-13 15:30 ` Bob Copeland
0 siblings, 0 replies; 14+ messages in thread
From: Bob Copeland @ 2009-05-13 15:30 UTC (permalink / raw)
To: Rafael J. Wysocki
Cc: Lin Ming, Bjorn Helgaas, yakui_zhao, linux-kernel, linux-acpi,
Moore, Robert
2009/5/13 Rafael J. Wysocki <rjw@sisk.pl>:
>> 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.
--
Bob Copeland %% www.bobcopeland.com
^ permalink raw reply [flat|nested] 14+ messages in thread
* [PATCH] ACPI: resume: re-enable SCI-enable workaround
2009-05-13 15:30 ` Bob Copeland
(?)
@ 2009-05-16 2:34 ` Len Brown
2009-05-16 3:30 ` Moore, Robert
-1 siblings, 1 reply; 14+ messages in thread
From: Len Brown @ 2009-05-16 2:34 UTC (permalink / raw)
To: Bob Copeland
Cc: Rafael J. Wysocki, Lin Ming, Bjorn Helgaas, yakui_zhao,
linux-kernel, linux-acpi, Moore, Robert
From: Lin Ming <ming.m.lin@intel.com>
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 <ming.m.lin@intel.com>
Signed-off-by: Len Brown <len.brown@intel.com>
---
as-applied.
thanks,
-Len
drivers/acpi/acpica/aclocal.h | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
index 772ee5c..2ec394a 100644
--- a/drivers/acpi/acpica/aclocal.h
+++ b/drivers/acpi/acpica/aclocal.h
@@ -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)
--
1.6.3.1.9.g95405b
^ permalink raw reply related [flat|nested] 14+ messages in thread
* RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround
2009-05-16 2:34 ` [PATCH] ACPI: resume: re-enable SCI-enable workaround Len Brown
@ 2009-05-16 3:30 ` Moore, Robert
2009-05-16 5:49 ` Len Brown
0 siblings, 1 reply; 14+ messages in thread
From: Moore, Robert @ 2009-05-16 3:30 UTC (permalink / raw)
To: Len Brown, Bob Copeland
Cc: Rafael J. Wysocki, Lin, Ming M, Bjorn Helgaas, Zhao, Yakui,
linux-kernel, linux-acpi
>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.
>-----Original Message-----
>From: Len Brown [mailto:lenb@kernel.org]
>Sent: Friday, May 15, 2009 7:34 PM
>To: Bob Copeland
>Cc: Rafael J. Wysocki; Lin, Ming M; Bjorn Helgaas; Zhao, Yakui; linux-
>kernel@vger.kernel.org; linux-acpi@vger.kernel.org; Moore, Robert
>Subject: [PATCH] ACPI: resume: re-enable SCI-enable workaround
>
>From: Lin Ming <ming.m.lin@intel.com>
>
>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 <ming.m.lin@intel.com>
>Signed-off-by: Len Brown <len.brown@intel.com>
>---
>
>as-applied.
>thanks,
>-Len
>
> drivers/acpi/acpica/aclocal.h | 7 ++++++-
> 1 files changed, 6 insertions(+), 1 deletions(-)
>
>diff --git a/drivers/acpi/acpica/aclocal.h b/drivers/acpi/acpica/aclocal.h
>index 772ee5c..2ec394a 100644
>--- a/drivers/acpi/acpica/aclocal.h
>+++ b/drivers/acpi/acpica/aclocal.h
>@@ -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)
>--
>1.6.3.1.9.g95405b
>
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround
2009-05-16 3:30 ` Moore, Robert
@ 2009-05-16 5:49 ` Len Brown
2009-05-16 6:50 ` Moore, Robert
0 siblings, 1 reply; 14+ messages in thread
From: Len Brown @ 2009-05-16 5:49 UTC (permalink / raw)
To: Moore, Robert
Cc: Bob Copeland, Rafael J. Wysocki, Lin, Ming M, Bjorn Helgaas,
Zhao, Yakui, linux-kernel, linux-acpi
> >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
^ permalink raw reply [flat|nested] 14+ messages in thread
* RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround
2009-05-16 5:49 ` Len Brown
@ 2009-05-16 6:50 ` Moore, Robert
0 siblings, 0 replies; 14+ messages in thread
From: Moore, Robert @ 2009-05-16 6:50 UTC (permalink / raw)
To: Len Brown
Cc: Bob Copeland, Rafael J. Wysocki, Lin, Ming M, Bjorn Helgaas,
Zhao, Yakui, linux-kernel, linux-acpi
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)
>-----Original Message-----
>From: Len Brown [mailto:lenb@kernel.org]
>Sent: Friday, May 15, 2009 10:50 PM
>To: Moore, Robert
>Cc: Bob Copeland; Rafael J. Wysocki; Lin, Ming M; Bjorn Helgaas; Zhao,
>Yakui; linux-kernel@vger.kernel.org; linux-acpi@vger.kernel.org
>Subject: RE: [PATCH] ACPI: resume: re-enable SCI-enable workaround
>
>
>> >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
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2009-05-16 6:50 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-05-07 10:58 acpi/suspend - irq 9: nobody cared Bob Copeland
2009-05-08 1:53 ` yakui_zhao
2009-05-12 19:01 ` Bjorn Helgaas
2009-05-12 19:26 ` Bob Copeland
2009-05-12 19:26 ` Bob Copeland
2009-05-13 4:05 ` [BISECTED] Was " Bob Copeland
[not found] ` <d3f22a0905122245h15786220g31ad0dcb8caa3a38@mail.gmail.com>
2009-05-13 5:36 ` Lin Ming
2009-05-13 8:15 ` Rafael J. Wysocki
2009-05-13 15:30 ` Bob Copeland
2009-05-13 15:30 ` Bob Copeland
2009-05-16 2:34 ` [PATCH] ACPI: resume: re-enable SCI-enable workaround Len Brown
2009-05-16 3:30 ` Moore, Robert
2009-05-16 5:49 ` Len Brown
2009-05-16 6:50 ` Moore, Robert
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.