Re: broken suspend [Was: 2.6.24-rc2-mm1]

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote:
> On Wednesday, 14 of November 2007, Jiri Slaby wrote:
>> On 11/14/2007 02:59 AM, Andrew Morton wrote:
>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
>> Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64.
>> echo mem >/sys/power/state
>> causes shut down of disk(s) and blinking cursor on 1,1 position.
>> The last working was 2.6.23-rc8-mm2. I haven't tested
>> 2.6.23-mm1, since it didn't work for me.
> 
> Does the current mainline work?

Yes.

The offending -mm patch is
gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch

2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
the patch is applied.

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Greg KH]

On Fri, Nov 16, 2007 at 12:59:41AM +0100, Jiri Slaby wrote:
> On 11/14/2007 10:48 PM, Rafael J. Wysocki wrote:
> > On Wednesday, 14 of November 2007, Jiri Slaby wrote:
> >> On 11/14/2007 02:59 AM, Andrew Morton wrote:
> >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.24-rc2/2.6.24-rc2-mm1/
> >> Doesn't suspend for me (neither broken-out-2007-11-13-04-14 did) on x86_64.
> >> echo mem >/sys/power/state
> >> causes shut down of disk(s) and blinking cursor on 1,1 position.
> >> The last working was 2.6.23-rc8-mm2. I haven't tested
> >> 2.6.23-mm1, since it didn't work for me.
> > 
> > Does the current mainline work?
> 
> Yes.
> 
> The offending -mm patch is
> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> 
> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
> the patch is applied.

Thanks for tracking this down.  Alan, any thoughts?

thanks,

greg k-h

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Thu, 15 Nov 2007, Greg KH wrote:

> > The offending -mm patch is
> > gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> > 
> > 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
> > the patch is applied.
> 
> Thanks for tracking this down.  Alan, any thoughts?

It's a driver problem somewhere.  Probably not one of the most common 
drivers because I don't see the same problem here (but then I'm not 
testing -mm).

The thing to do is figure out which driver is causing the problem.
Jiri, try enabling CONFIG_DEBUG_DRIVER.  If there's also a config 
option to prevent the console from being suspended, set it as well.  
Then you should be able to tell which driver is making trouble.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/16/2007 05:10 PM, Alan Stern wrote:
> On Thu, 15 Nov 2007, Greg KH wrote:
> 
>>> The offending -mm patch is
>>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
>>>
>>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
>>> the patch is applied.
>> Thanks for tracking this down.  Alan, any thoughts?
> 
> It's a driver problem somewhere.  Probably not one of the most common 
> drivers because I don't see the same problem here (but then I'm not 
> testing -mm).
> 
> The thing to do is figure out which driver is causing the problem.
> Jiri, try enabling CONFIG_DEBUG_DRIVER.  

Sadly no output.

> If there's also a config 
> option to prevent the console from being suspended, set it as well.  

no_suspend_console kernel parameter has no effect (why?).

> Then you should be able to tell which driver is making trouble.

I think no unusual hardware inside:

00:00.0 Host bridge: Intel Corporation 82G33/G31/P35 Express DRAM Controller
(rev 02)
        Subsystem: Intel Corporation 82G33/G31/P35 Express DRAM Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort+ >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information
00: 86 80 c0 29 06 00 90 20 02 00 00 06 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c0 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:02.0 VGA compatible controller: Intel Corporation 82G33/G31 Express
Integrated Graphics Controller (rev 02) (prog-if 00 [VGA])
        Subsystem: Intel Corporation 82G33/G31 Express Integrated Graphics
Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at ffa80000 (32-bit, non-prefetchable) [size=512K]
        Region 1: I/O ports at ec00 [size=8]
        Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
        Region 3: Memory at ff900000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: [90] Message Signalled Interrupts: Mask- 64bit- Queue=0/0
Enable-
                Address: 00000000  Data: 0000
        Capabilities: [d0] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 c2 29 07 00 90 00 02 00 00 03 00 00 00 00
10: 00 00 a8 ff 01 ec 00 00 08 00 00 d0 00 00 90 ff
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c2 29
30: 00 00 00 00 90 00 00 00 00 00 00 00 0a 01 00 00

00:03.0 Communication controller: Intel Corporation 82G33/G31/P35 Express MEI
Controller (rev 02)
        Subsystem: Intel Corporation 82G33/G31/P35 Express MEI Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 10
        Region 0: Memory at ffa7bc00 (64-bit, non-prefetchable) [size=16]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [8c] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000
00: 86 80 c4 29 06 00 10 00 02 00 80 07 00 00 80 00
10: 04 bc a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c4 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:03.2 IDE interface: Intel Corporation 82G33/G31/P35 Express PT IDER
Controller (rev 02) (prog-if 85 [Master SecO PriO])
        Subsystem: Intel Corporation 82G33/G31/P35 Express PT IDER Controller
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 12
        Region 0: I/O ports at e880 [size=8]
        Region 1: I/O ports at e800 [size=4]
        Region 2: I/O ports at e480 [size=8]
        Region 3: I/O ports at e400 [size=4]
        Region 4: I/O ports at e080 [size=16]
        Capabilities: [c8] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000
00: 86 80 c6 29 05 00 b0 00 02 85 01 01 00 00 00 00
10: 81 e8 00 00 01 e8 00 00 81 e4 00 00 01 e4 00 00
20: 81 e0 00 00 00 00 00 00 00 00 00 00 86 80 c6 29
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0c 03 00 00

00:03.3 Serial controller: Intel Corporation 82G33/G31/P35 Express Serial KT
Controller (rev 02) (prog-if 02 [16550])
        Subsystem: Intel Corporation 82G33/G31/P35 Express Serial KT Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 17
        Region 0: I/O ports at e000 [size=8]
        Region 1: Memory at ffa7a000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [c8] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000
00: 86 80 c7 29 07 00 b0 00 02 02 00 07 00 00 00 00
10: 01 e0 00 00 00 a0 a7 ff 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 c7 29
30: 00 00 00 00 c8 00 00 00 00 00 00 00 05 02 00 00

00:19.0 Ethernet controller: Intel Corporation 82566DM-2 Gigabit Network
Connection (rev 02)
        Subsystem: Intel Corporation Unknown device 0000
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 318
        Region 0: Memory at ffa40000 (32-bit, non-prefetchable) [size=128K]
        Region 1: Memory at ffa79000 (32-bit, non-prefetchable) [size=4K]
        Region 2: I/O ports at dc00 [size=32]
        Capabilities: [c8] Power Management version 2
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=1 PME-
        Capabilities: [d0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable+
                Address: 00000000fee0300c  Data: 4191
        Capabilities: [e0] Vendor Specific Information
00: 86 80 bd 10 07 04 10 00 02 00 00 02 00 00 00 00
10: 00 00 a4 ff 00 90 a7 ff 01 dc 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 00 00
30: 00 00 00 00 c8 00 00 00 00 00 00 00 0f 01 00 00

00:1a.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #4 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #4
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 16
        Region 4: I/O ports at d880 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 37 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d8 00 00 00 00 00 00 00 00 00 00 86 80 37 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1a.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #5 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #5
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 21
        Region 4: I/O ports at d800 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 38 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d8 00 00 00 00 00 00 00 00 00 00 86 80 38 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0e 02 00 00

00:1a.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #6 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #6
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin C routed to IRQ 18
        Region 4: I/O ports at d480 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 39 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d4 00 00 00 00 00 00 00 00 00 00 86 80 39 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

00:1a.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #2 (rev 02) (prog-if 20 [EHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #2
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin D routed to IRQ 19
        Region 0: Memory at ffa7b400 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port
        Capabilities: [98] Vendor Specific Information
00: 86 80 3c 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b4 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3c 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 04 00 00

00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller
(rev 02)
        Subsystem: Intel Corporation 82801I (ICH9 Family) HD Audio Controller
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 22
        Region 0: Memory at ffa70000 (64-bit, non-prefetchable) [size=16K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0
Enable-
                Address: 0000000000000000  Data: 0000
        Capabilities: [70] Express Unknown type IRQ 0
                Device: Supported: MaxPayload 128 bytes, PhantFunc 0, ExtTag-
                Device: Latency L0s <64ns, L1 <1us
                Device: Errors: Correctable- Non-Fatal- Fatal- Unsupported-
                Device: RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+
                Device: MaxPayload 128 bytes, MaxReadReq 128 bytes
                Link: Supported Speed unknown, Width x0, ASPM unknown, Port 0
                Link: Latency L0s <64ns, L1 <1us
                Link: ASPM Disabled CommClk- ExtSynch-
                Link: Speed unknown, Width x0
        Capabilities: [100] Virtual Channel
        Capabilities: [130] Unknown (5)
00: 86 80 3e 29 06 00 10 00 02 00 03 04 08 00 00 00
10: 04 00 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3e 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 07 01 00 00

00:1d.0 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #1 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #1
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 23
        Region 4: I/O ports at d400 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 34 29 05 00 90 02 02 00 03 0c 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d4 00 00 00 00 00 00 00 00 00 00 86 80 34 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1d.1 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #2 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #2
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 4: I/O ports at d080 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 35 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 81 d0 00 00 00 00 00 00 00 00 00 00 86 80 35 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 03 02 00 00

00:1d.2 USB Controller: Intel Corporation 82801I (ICH9 Family) USB UHCI
Controller #3 (rev 02) (prog-if 00 [UHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB UHCI Controller #3
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin D routed to IRQ 16
        Region 4: I/O ports at d000 [size=32]
        Capabilities: [50] Vendor Specific Information
00: 86 80 36 29 05 00 90 02 02 00 03 0c 00 00 00 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 d0 00 00 00 00 00 00 00 00 00 00 86 80 36 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 04 00 00

00:1d.7 USB Controller: Intel Corporation 82801I (ICH9 Family) USB2 EHCI
Controller #1 (rev 02) (prog-if 20 [EHCI])
        Subsystem: Intel Corporation 82801I (ICH9 Family) USB2 EHCI Controller #1
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin A routed to IRQ 23
        Region 0: Memory at ffa7b000 (32-bit, non-prefetchable) [size=1K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [58] Debug port
        Capabilities: [98] Vendor Specific Information
00: 86 80 3a 29 06 00 90 02 02 20 03 0c 00 00 00 00
10: 00 b0 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 3a 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0a 01 00 00

00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev 92) (prog-if 01
[Subtractive decode])
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR+ FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=32
        Memory behind bridge: ff600000-ff6fffff
        Secondary status: 66MHz- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
        BridgeCtl: Parity- SERR+ NoISA- VGA- MAbort- >Reset- FastB2B-
        Capabilities: [50] Subsystem: Intel Corporation 82801 PCI Bridge
00: 86 80 4e 24 06 01 10 00 92 01 04 06 00 00 01 00
10: 00 00 00 00 00 00 00 00 00 01 01 20 f0 00 80 22
20: 60 ff 60 ff f1 ff 01 00 00 00 00 00 00 00 00 00
30: 00 00 00 00 50 00 00 00 00 00 00 00 ff 00 02 00

00:1f.0 ISA bridge: Intel Corporation Unknown device 2910 (rev 02)
        Subsystem: Intel Corporation Unknown device 2910
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [e0] Vendor Specific Information
00: 86 80 10 29 07 00 10 02 02 00 01 06 00 00 80 00
10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 10 29
30: 00 00 00 00 e0 00 00 00 00 00 00 00 00 00 00 00

00:1f.2 SATA controller: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port
SATA AHCI Controller (rev 02) (prog-if 01 [AHCI 1.0])
        Subsystem: Intel Corporation 82801IR/IO/IH (ICH9R/DO/DH) 6 port SATA
AHCI Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 319
        Region 0: I/O ports at cc00 [size=8]
        Region 1: I/O ports at c880 [size=4]
        Region 2: I/O ports at c800 [size=8]
        Region 3: I/O ports at c480 [size=4]
        Region 4: I/O ports at c400 [size=32]
        Region 5: Memory at ffa78800 (32-bit, non-prefetchable) [size=2K]
        Capabilities: [80] Message Signalled Interrupts: Mask- 64bit- Queue=0/4
Enable+
                Address: fee0300c  Data: 4169
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [a8] #12 [0010]
        Capabilities: [b0] Vendor Specific Information
00: 86 80 22 29 07 04 b0 02 02 01 06 01 00 00 00 00
10: 01 cc 00 00 81 c8 00 00 01 c8 00 00 81 c4 00 00
20: 01 c4 00 00 00 88 a7 ff 00 00 00 00 86 80 22 29
30: 00 00 00 00 80 00 00 00 00 00 00 00 03 02 00 00

00:1f.3 SMBus: Intel Corporation 82801I (ICH9 Family) SMBus Controller (rev 02)
        Subsystem: Intel Corporation 82801I (ICH9 Family) SMBus Controller
        Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin C routed to IRQ 18
        Region 0: Memory at ffa7b800 (64-bit, non-prefetchable) [size=256]
        Region 4: I/O ports at 0400 [size=32]
00: 86 80 30 29 03 00 80 02 02 00 05 0c 00 00 00 00
10: 04 b8 a7 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 01 04 00 00 00 00 00 00 00 00 00 00 86 80 30 29
30: 00 00 00 00 00 00 00 00 00 00 00 00 03 03 00 00

00:1f.5 IDE interface: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE
Controller (rev 02) (prog-if 85 [Master SecO PriO])
        Subsystem: Intel Corporation 82801I (ICH9 Family) 2 port SATA IDE Controller
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Interrupt: pin B routed to IRQ 19
        Region 0: I/O ports at c000 [size=8]
        Region 1: I/O ports at bc00 [size=4]
        Region 2: I/O ports at b880 [size=8]
        Region 3: I/O ports at b800 [size=4]
        Region 4: I/O ports at b480 [size=16]
        Region 5: I/O ports at b400 [size=16]
        Capabilities: [70] Power Management version 3
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
        Capabilities: [b0] Vendor Specific Information
00: 86 80 26 29 07 00 b0 02 02 85 01 01 00 00 00 00
10: 01 c0 00 00 01 bc 00 00 81 b8 00 00 01 b8 00 00
20: 81 b4 00 00 01 b4 00 00 00 00 00 00 86 80 26 29
30: 00 00 00 00 70 00 00 00 00 00 00 00 03 02 00 00

00:1f.6 Signal processing controller: Intel Corporation 82801I (ICH9 Family)
Thermal Subsystem (rev 02)
        Subsystem: Intel Corporation 82801I (ICH9 Family) Thermal Subsystem
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR-
        Interrupt: pin C routed to IRQ 12
        Region 0: Memory at ffa6f000 (64-bit, non-prefetchable) [size=4K]
        Capabilities: [50] Power Management version 3
                Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 86 80 32 29 02 00 10 00 02 00 80 11 00 00 00 00
10: 04 f0 a6 ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 86 80 32 29
30: 00 00 00 00 50 00 00 00 00 00 00 00 0c 03 00 00

01:00.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)
        Subsystem: Wistron NeWeb Corp. CM9 Wireless a/b/g MiniPCI Adapter
        Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr-
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168 (2500ns min, 7000ns max), Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 21
        Region 0: Memory at ff6f0000 (32-bit, non-prefetchable) [size=64K]
        Capabilities: [44] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-
00: 8c 16 13 00 16 00 90 02 01 00 00 02 08 a8 00 00
10: 00 00 6f ff 00 00 00 00 00 00 00 00 00 00 00 00
20: 00 00 00 00 00 00 00 00 01 50 00 00 5f 18 12 10
30: 00 00 00 00 44 00 00 00 00 00 00 00 0e 01 0a 1c






Plugged usb devices:

Bus 004 Device 007: ID 045e:00f0 Microsoft Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               2.00
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x045e Microsoft Corp.
  idProduct          0x00f0
  bcdDevice            1.01
  iManufacturer           1 Microsoft Corporation
  iProduct                2 Microsoft � Laser Mouse 6000
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           34
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xa0
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.11
          bCountryCode           33 US
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      59
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0004  1x 4 bytes
        bInterval              10

Bus 004 Device 006: ID 0458:004c KYE Systems Corp. (Mouse Systems) Slimstar Pro
Keyboard
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            0 (Defined at Interface level)
  bDeviceSubClass         0
  bDeviceProtocol         0
  bMaxPacketSize0         8
  idVendor           0x0458 KYE Systems Corp. (Mouse Systems)
  idProduct          0x004c Slimstar Pro Keyboard
  bcdDevice            1.01
  iManufacturer           1 ABBHOME
  iProduct                2 USB Keyboard
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           59
    bNumInterfaces          2
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower               50mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      1 Keyboard
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength      65
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        1
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         3 Human Interface Devices
      bInterfaceSubClass      1 Boot Interface Subclass
      bInterfaceProtocol      2 Mouse
      iInterface              0
        HID Device Descriptor:
          bLength                 9
          bDescriptorType        33
          bcdHID               1.10
          bCountryCode            0 Not supported
          bNumDescriptors         1
          bDescriptorType        34 Report
          wDescriptorLength     104
         Report Descriptors:
           ** UNAVAILABLE **
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x82  EP 2 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0008  1x 8 bytes
        bInterval              10

Bus 004 Device 005: ID 04b4:2050 Cypress Semiconductor Corp.
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0 Full speed (or root) hub
  bMaxPacketSize0         8
  idVendor           0x04b4 Cypress Semiconductor Corp.
  idProduct          0x2050
  bcdDevice            0.01
  iManufacturer           1 Bella Corporation
  iProduct                2 GBella Corporation DV Keyboard
  iSerial                 0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower              100mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0 Full speed (or root) hub
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0001  1x 1 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             3
  wHubCharacteristic 0x000d
    Per-port power switching
    Compound device
    Per-port overcurrent protection
  bPwrOn2PwrGood       50 * 2 milli seconds
  bHubContrCurrent     25 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0x60
 Hub Port Status:
   Port 1: 0000.0103 power enable connect
   Port 2: 0000.0303 lowspeed power enable connect
   Port 3: 0000.0100 power

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/17/2007 04:08 PM, Jiri Slaby wrote:
> On 11/16/2007 05:10 PM, Alan Stern wrote:
>> If there's also a config 
>> option to prevent the console from being suspended, set it as well.  
> 
> no_suspend_console kernel parameter has no effect (why?).

Eh, no, this (/proc/cmdline):
ro root=/dev/md1 reboo1 vga=1 2 no_console_suspend

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Sat, 17 Nov 2007, Jiri Slaby wrote:

> > The thing to do is figure out which driver is causing the problem.
> > Jiri, try enabling CONFIG_DEBUG_DRIVER.  
> 
> Sadly no output.

Guess I'll have to try running 2.6.24-rc2-mm1 on my own system.  In the 
meantime, you can try adding some printk statements to 
drivers/base/power/main.c.  In particular, see whether 
lock_all_devices() gets called from device_suspend(), whether it 
returns, and how far dpm_suspend() manages to get.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Saturday, 17 of November 2007, Jiri Slaby wrote:
> On 11/16/2007 05:10 PM, Alan Stern wrote:
> > On Thu, 15 Nov 2007, Greg KH wrote:
> > 
> >>> The offending -mm patch is
> >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> >>>
> >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
> >>> the patch is applied.
> >> Thanks for tracking this down.  Alan, any thoughts?
> > 
> > It's a driver problem somewhere.  Probably not one of the most common 
> > drivers because I don't see the same problem here (but then I'm not 
> > testing -mm).
> > 
> > The thing to do is figure out which driver is causing the problem.
> > Jiri, try enabling CONFIG_DEBUG_DRIVER.  
> 
> Sadly no output.
> 
> > If there's also a config 
> > option to prevent the console from being suspended, set it as well.  
> 
> no_suspend_console kernel parameter has no effect (why?).

I'm not sure.

Please try to set CONFIG_PM_VERBOSE.

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Sat, 17 Nov 2007, Rafael J. Wysocki wrote:

> On Saturday, 17 of November 2007, Jiri Slaby wrote:
> > On 11/16/2007 05:10 PM, Alan Stern wrote:
> > > On Thu, 15 Nov 2007, Greg KH wrote:
> > > 
> > >>> The offending -mm patch is
> > >>> gregkh-driver-pm-acquire-device-locks-prior-to-suspending.patch
> > >>>
> > >>> 2.6.24-rc2-mm1 minus it works just fine; PROVE_LOCKING shows nothing new when
> > >>> the patch is applied.
> > >> Thanks for tracking this down.  Alan, any thoughts?
> > > 
> > > It's a driver problem somewhere.  Probably not one of the most common 
> > > drivers because I don't see the same problem here (but then I'm not 
> > > testing -mm).
> > > 
> > > The thing to do is figure out which driver is causing the problem.
> > > Jiri, try enabling CONFIG_DEBUG_DRIVER.  
> > 
> > Sadly no output.
> > 
> > > If there's also a config 
> > > option to prevent the console from being suspended, set it as well.  
> > 
> > no_suspend_console kernel parameter has no effect (why?).
> 
> I'm not sure.
> 
> Please try to set CONFIG_PM_VERBOSE.

I finally got 2.6.24-rc2-mm1 working.  Andrew, how come those two
recent patches from Greg and Kay (the ones changing alloc_disk_node()  
and system_bus_init()) aren't in your hot-fixes directory?

There's still a problem.  During bootup I get this:

	floppy0: Floppy io-port 0x03f2 in use

That's not supposed to happen; the floppy disk should be working 
perfectly.  Is this a known problem?

Back to the main topic...  My system hibernates and resumes with no
apparent problem.  Jiri, it looks like you'll have to do some debug
tracing of the routines in drivers/base/power/main.c.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

Alan Stern napsal(a):
> On Sat, 17 Nov 2007, Rafael J. Wysocki wrote:
>> On Saturday, 17 of November 2007, Jiri Slaby wrote:
>>> On 11/16/2007 05:10 PM, Alan Stern wrote:
>>>> The thing to do is figure out which driver is causing the problem.
>>>> Jiri, try enabling CONFIG_DEBUG_DRIVER.  
>>> Sadly no output.

Nice update scripts wiped kern.* from syslog config file out, hence no
output before.

> Back to the main topic...  My system hibernates and resumes with no
> apparent problem.  Jiri, it looks like you'll have to do some debug
> tracing of the routines in drivers/base/power/main.c.

Beside this two nothing strange:

dpm_suspend: b 00:06
WARNING: at /home/l/latest/bughunt/kernel/resource.c:185 __release_resource()

Call Trace:
 [<ffffffff8023f7b5>] release_resource+0xb5/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83

WARNING: at /home/l/latest/bughunt/kernel/resource.c:189 __release_resource()

Call Trace:
 [<ffffffff8023f7e0>] release_resource+0xe0/0xf0
 [<ffffffff8036cda0>] pnp_release_resources+0x70/0x130
 [<ffffffff8036db85>] pnp_stop_dev+0x45/0x90
 [<ffffffff8036c942>] pnp_bus_suspend+0x92/0xb0
 [<ffffffff803b9f73>] suspend_device+0x113/0x180
 [<ffffffff803ba330>] device_suspend+0x200/0x320
 [<ffffffff80266905>] suspend_devices_and_enter+0xa5/0x170
 [<ffffffff80266bd9>] enter_state+0x209/0x270
 [<ffffffff80266cef>] state_store+0xaf/0xf0
 [<ffffffff8032ca67>] kobj_attr_store+0x17/0x20
 [<ffffffff802e459e>] sysfs_write_file+0xce/0x140
 [<ffffffff80299cc7>] vfs_write+0xc7/0x170
 [<ffffffff8029a360>] sys_write+0x50/0x90
 [<ffffffff8020bcde>] system_call+0x7e/0x83
...
dpm_suspend: b 0000:00:1f.5
ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.SAT1.CHN0._GTM] (Node FFFF81007D000220), AE_NOT_FOUND
ACPI Error (psargs-0355): [FZHD] Namespace lookup failure, AE_NOT_FOUND
ACPI Error (psparse-0537): Method parse/execution failed
[\_SB_.PCI0.SAT1.CHN1._GTM] (Node FFFF81007D000360), AE_NOT_FOUND



It's stuck at _cpu_down (enter_state -> suspend_devices_and_enter ->
disable_nonboot_cpus -> _cpu_down) after calling raw_notifier_call_chain

        printk("%s: s\n", __func__);
        /* Wait for it to sleep (leaving idle task). */
        while (!idle_cpu(cpu))
                yield();

        printk("%s: t\n", __func__);
        /* This actually kills the CPU. */
        __cpu_die(cpu);

        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;

        printk("%s: v\n", __func__);


See shot of prints here:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

notifier_call_chain looks like:
        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                ret = nb->notifier_call(nb, val, v);
                if (unlikely(BUBAK && cnt < 20 && (ret != lastr ||
                                lastp != nb->notifier_call))) {
                        printk("%s: c %p %d\n", __func__, nb->notifier_call,
                                        ret);
                        lastr = ret;
                        lastp = nb->notifier_call;
                        cnt++;
                }

                if (nr_calls)
                        (*nr_calls)++;

                if ((ret & NOTIFY_STOP_MASK) == NOTIFY_STOP_MASK)
                        break;
                nb = next_nb;
                nr_to_call--;
        }

System.map is here if you are curoius what are the pointers from the snapshot:
http://www.fi.muni.cz/~xslaby/sklad/System.map

regards,
-- 
http://www.fi.muni.cz/~xslaby/            Jiri Slaby
faculty of informatics, masaryk university, brno, cz

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> See shot of prints here:
> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png

BTW output from that tree minus the patch:
_cpu_down: s
_cpu_down: t
CPU 1 is now offline
SMP alternatives: switching to UP code
_cpu_down: u
notifier_call_chain: c FFFFFFFF80232370 1
notifier_call_chain: c FFFFFFFF8026EF10 1
notifier_call_chain: c FFFFFFFF8024B8F0 1
notifier_call_chain: c FFFFFFFF802419E0 1
notifier_call_chain: c FFFFFFFF80255B50 1
notifier_call_chain: c FFFFFFFF80250C40 1
notifier_call_chain: c FFFFFFFF8028E8F0 1
notifier_call_chain: c FFFFFFFF802B59C0 1
notifier_call_chain: c FFFFFFFF80323460 1
notifier_call_chain: c FFFFFFFF80270990 0
notifier_call_chain: c FFFFFFFF8023D5D0 1
notifier_call_chain: c FFFFFFFF80266090 1
notifier_call_chain: c FFFFFFFF802320A0 1
notifier_call_chain: c FFFFFFFF80249DA0 1
notifier_call_chain: c FFFFFFFF80318440 1
notifier_call_chain: c FFFFFFFF8047BE80 1
notifier_call_chain: c FFFFFFFF80212F40 0
notifier_call_chain: c FFFFFFFF80216350 1
notifier_call_chain: c FFFFFFFF80217220 1
notifier_call_chain: c FFFFFFFF80218120 1
_cpu_down: v
_cpu_down: w
_cpu_down: x
_cpu_down: y
_cpu_down: z
disable_nonboot_cpus: 3 0

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> > See shot of prints here:
> > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
> 
> BTW output from that tree minus the patch:

Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.

Can you try to see what happens (with the patch applied) if
thermal_throttle_cpu_callback() is not registered?

> _cpu_down: s
> _cpu_down: t
> CPU 1 is now offline
> SMP alternatives: switching to UP code
> _cpu_down: u
> notifier_call_chain: c FFFFFFFF80232370 1
> notifier_call_chain: c FFFFFFFF8026EF10 1
> notifier_call_chain: c FFFFFFFF8024B8F0 1
> notifier_call_chain: c FFFFFFFF802419E0 1
> notifier_call_chain: c FFFFFFFF80255B50 1
> notifier_call_chain: c FFFFFFFF80250C40 1
> notifier_call_chain: c FFFFFFFF8028E8F0 1
> notifier_call_chain: c FFFFFFFF802B59C0 1
> notifier_call_chain: c FFFFFFFF80323460 1
> notifier_call_chain: c FFFFFFFF80270990 0
> notifier_call_chain: c FFFFFFFF8023D5D0 1
> notifier_call_chain: c FFFFFFFF80266090 1
> notifier_call_chain: c FFFFFFFF802320A0 1
> notifier_call_chain: c FFFFFFFF80249DA0 1
> notifier_call_chain: c FFFFFFFF80318440 1
> notifier_call_chain: c FFFFFFFF8047BE80 1
> notifier_call_chain: c FFFFFFFF80212F40 0
> notifier_call_chain: c FFFFFFFF80216350 1
> notifier_call_chain: c FFFFFFFF80217220 1
> notifier_call_chain: c FFFFFFFF80218120 1
> _cpu_down: v
> _cpu_down: w
> _cpu_down: x
> _cpu_down: y
> _cpu_down: z
> disable_nonboot_cpus: 3 0

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote:
> On Sunday, 18 of November 2007, Jiri Slaby wrote:
>> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
>>> See shot of prints here:
>>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
>> BTW output from that tree minus the patch:
> 
> Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.
> 
> Can you try to see what happens (with the patch applied) if
> thermal_throttle_cpu_callback() is not registered?

After commenting out
//device_initcall(thermal_throttle_init_device);
it looks like this:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> Can you also make the new System-map available, please?

Sure:
http://www.fi.muni.cz/~xslaby/sklad/System.map1

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 02:42 PM, Rafael J. Wysocki wrote:
> > On Sunday, 18 of November 2007, Jiri Slaby wrote:
> >> On 11/18/2007 01:42 PM, Jiri Slaby wrote:
> >>> See shot of prints here:
> >>> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png
> >> BTW output from that tree minus the patch:
> > 
> > Hm, it looks like one of the CPU hotplug notifiers is doing something wrong.
> > 
> > Can you try to see what happens (with the patch applied) if
> > thermal_throttle_cpu_callback() is not registered?
> 
> After commenting out
> //device_initcall(thermal_throttle_init_device);
> it looks like this:
> http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

Can you also make the new System-map available, please?

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 04:23 PM, Rafał J. Wysocki wrote:
> On Sunday, 18 of November 2007, Jiri Slaby wrote:
>> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
>>> Can you also make the new System-map available, please?
>> Sure:
>> http://www.fi.muni.cz/~xslaby/sklad/System.map1
> 
> The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png

Last... Note, that it's only first 20 invokations of notifiers, there are
bazillion of them when I remove the condition '< 20'.

> is apparently cpu_swap_callback() which is not called in
> http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
> 
> Can you verify that cpu_swap_callback() gets called if the patch is not
> applied?

Does this still apply?

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafał J. Wysocki]

On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> > Can you also make the new System-map available, please?
> 
> Sure:
> http://www.fi.muni.cz/~xslaby/sklad/System.map1

The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
is apparently cpu_swap_callback() which is not called in
http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .

Can you verify that cpu_swap_callback() gets called if the patch is not
applied?

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Sun, 18 Nov 2007, Jiri Slaby wrote:

> On 11/18/2007 04:23 PM, Rafał J. Wysocki wrote:
> > On Sunday, 18 of November 2007, Jiri Slaby wrote:
> >> On 11/18/2007 04:03 PM, Rafael J. Wysocki wrote:
> >>> Can you also make the new System-map available, please?
> >> Sure:
> >> http://www.fi.muni.cz/~xslaby/sklad/System.map1
> > 
> > The last notifier called in http://www.fi.muni.cz/~xslaby/sklad/susp_hang2.png
> 
> Last... Note, that it's only first 20 invokations of notifiers, there are
> bazillion of them when I remove the condition '< 20'.
> 
> > is apparently cpu_swap_callback() which is not called in
> > http://www.fi.muni.cz/~xslaby/sklad/susp_hang1.png .
> > 
> > Can you verify that cpu_swap_callback() gets called if the patch is not
> > applied?
> 
> Does this still apply?

You'll get more useful results if you redo your changes to 
notifier_call_chain().  Have it print out the address of the routine 
_before_ making the call, and don't limit it to 20.  That way you'll 
know exactly which notifier routine ends up hanging.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 06:07 PM, Alan Stern wrote:
> You'll get more useful results if you redo your changes to 
> notifier_call_chain().  Have it print out the address of the routine 
> _before_ making the call, and don't limit it to 20.  That way you'll 
> know exactly which notifier routine ends up hanging.

The problem is, that notifier_call_chain is called again and again zillion times
by somebody else...

Anyway you led me to another idea:
* _cpu_down
        printk("%s: u\n", __func__);
        BUBAK=1;
        /* CPU is completely dead: tell everyone.  Too late to complain. */
        if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,
                                    hcpu) == NOTIFY_BAD)
                BUG();
        BUBAK=0;
-----
* notifier_call_chain
        unsigned int a = val & 0x88000;
        unsigned int yes = a == 0x88000;

        nb = rcu_dereference(*nl);

        if (a && a != 0x88000)
                printk("Somebody calls with val: %lx\n", val);
        else
                val &= ~0x88000;

        while (nb && nr_to_call) {
                next_nb = rcu_dereference(nb->next);
                if (unlikely(BUBAK && yes))
                        printk("%s: %p\n", __func__, nb->notifier_call);
                ret = nb->notifier_call(nb, val, v);
-----
gives coretemp_cpu_callback -> coretemp_device_remove ->
platform_device_unregister, so coretemp seems to be what I have and you don't.

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote:
> You can use a global variable to switch the logging only before the CPU
> hotunplug done by the suspend code.  You just need to hack
> disable_nonboot_cpus() for that.

If I understand you correctly, that's what BUBAK variable is there for. But it
is still called again and again while the suspend code runs...

regards,
-- 
Jiri Slaby (jirislaby@gmail.com)
Faculty of Informatics, Masaryk University

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Jiri Slaby]

Aah, we probably should let coretemp people known.

Whole thread:
http://marc.info/?t=119507205800001&r=1&w=2

On 11/18/2007 08:09 PM, Jiri Slaby wrote:
> On 11/18/2007 06:07 PM, Alan Stern wrote:
>> You'll get more useful results if you redo your changes to 
>> notifier_call_chain().  Have it print out the address of the routine 
>> _before_ making the call, and don't limit it to 20.  That way you'll 
>> know exactly which notifier routine ends up hanging.
> 
> The problem is, that notifier_call_chain is called again and again zillion times
> by somebody else...
> 
> Anyway you led me to another idea:
> * _cpu_down
>         printk("%s: u\n", __func__);
>         BUBAK=1;
>         /* CPU is completely dead: tell everyone.  Too late to complain. */
>         if (raw_notifier_call_chain(&cpu_chain, CPU_DEAD | 0x88000 | mod,
>                                     hcpu) == NOTIFY_BAD)
>                 BUG();
>         BUBAK=0;
> -----
> * notifier_call_chain
>         unsigned int a = val & 0x88000;
>         unsigned int yes = a == 0x88000;
> 
>         nb = rcu_dereference(*nl);
> 
>         if (a && a != 0x88000)
>                 printk("Somebody calls with val: %lx\n", val);
>         else
>                 val &= ~0x88000;
> 
>         while (nb && nr_to_call) {
>                 next_nb = rcu_dereference(nb->next);
>                 if (unlikely(BUBAK && yes))
>                         printk("%s: %p\n", __func__, nb->notifier_call);
>                 ret = nb->notifier_call(nb, val, v);
> -----
> gives coretemp_cpu_callback -> coretemp_device_remove ->
> platform_device_unregister, so coretemp seems to be what I have and you don't.

Just in case you are curious:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.diff
produces:
http://www.fi.muni.cz/~xslaby/sklad/susp_hang3.png

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 06:07 PM, Alan Stern wrote:
> > You'll get more useful results if you redo your changes to 
> > notifier_call_chain().  Have it print out the address of the routine 
> > _before_ making the call, and don't limit it to 20.  That way you'll 
> > know exactly which notifier routine ends up hanging.
> 
> The problem is, that notifier_call_chain is called again and again zillion times
> by somebody else...

You can use a global variable to switch the logging only before the CPU
hotunplug done by the suspend code.  You just need to hack
disable_nonboot_cpus() for that.

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Sunday, 18 of November 2007, Jiri Slaby wrote:
> On 11/18/2007 11:27 PM, Rafael J. Wysocki wrote:
> > You can use a global variable to switch the logging only before the CPU
> > hotunplug done by the suspend code.  You just need to hack
> > disable_nonboot_cpus() for that.
> 
> If I understand you correctly, that's what BUBAK variable is there for.

Ah, yes.

-ETOOTIRED

> But it is still called again and again while the suspend code runs...

You can count the number of calls and then make it print the information for
the last, say, 20 of them.

Greetings,
Rafael

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Sun, 18 Nov 2007, Jiri Slaby wrote:

> > gives coretemp_cpu_callback -> coretemp_device_remove ->
> > platform_device_unregister, so coretemp seems to be what I have and you don't.

Yes.

For the coretemp developers: coretemp_cpu_callback() needs to be more 
careful about what it does.  During a system sleep transition (suspend, 
hibernate, resume) it isn't possible to register or unregister a 
device.  Attempts to register will fail and attempts to unregister will 
block until the system sleep is over -- and for this callback that 
means hanging.

It's not clear what the best way is to fix this.  Perhaps the CPU 
notification should be sent along with a special flag indicating that 
the CPU transition is part of a system sleep (although this seems 
racy).  Perhaps the driver should notice when a system sleep begins, 
and defer all CPU-change handling until after the sleep is over.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rudolf Marek]

Hello all,
>>> gives coretemp_cpu_callback -> coretemp_device_remove ->
>>> platform_device_unregister, so coretemp seems to be what I have and you don't.
> 
> Yes.
> 
> For the coretemp developers: coretemp_cpu_callback() needs to be more 
> careful about what it does.  During a system sleep transition (suspend, 
> hibernate, resume) it isn't possible to register or unregister a 
> device.  Attempts to register will fail and attempts to unregister will 
> block until the system sleep is over -- and for this callback that 
> means hanging.

Well I wrote the driver. Thanks for the clarification. If I recall correctly I 
looked how this part should be done from others drivers. Now while checking
what happened to the file, seems Rafael added something related.

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d

> It's not clear what the best way is to fix this.  Perhaps the CPU 
> notification should be sent along with a special flag indicating that 
> the CPU transition is part of a system sleep (although this seems 
> racy).  Perhaps the driver should notice when a system sleep begins, 
> and defer all CPU-change handling until after the sleep is over.

maybe it does exist?  CPU_DOWN_PREPARE ?

http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD

Unfortunately I'm not very familiar with this, calling the 
coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode 
driver, seems it just hide sysfs interface from user.

Thanks,
Rudolf

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Alan Stern]

On Mon, 19 Nov 2007, Rudolf Marek wrote:

> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you don't.
> > 
> > Yes.
> > 
> > For the coretemp developers: coretemp_cpu_callback() needs to be more 
> > careful about what it does.  During a system sleep transition (suspend, 
> > hibernate, resume) it isn't possible to register or unregister a 
> > device.  Attempts to register will fail and attempts to unregister will 
> > block until the system sleep is over -- and for this callback that 
> > means hanging.
> 
> Well I wrote the driver. Thanks for the clarification. If I recall correctly I 
> looked how this part should be done from others drivers. Now while checking
> what happened to the file, seems Rafael added something related.
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d

That does look like it was meant for exactly this sort of situation.

> > It's not clear what the best way is to fix this.  Perhaps the CPU 
> > notification should be sent along with a special flag indicating that 
> > the CPU transition is part of a system sleep (although this seems 
> > racy).  Perhaps the driver should notice when a system sleep begins, 
> > and defer all CPU-change handling until after the sleep is over.
> 
> maybe it does exist?  CPU_DOWN_PREPARE ?
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/cpu-hotplug.txt;hb=HEAD
> 
> Unfortunately I'm not very familiar with this, calling the 
> coretemp_device_remove from CPU_DOWN_PREPARE would help? Looking at microcode 
> driver, seems it just hide sysfs interface from user.

I'm not sure exactly what you want to do here.  But it seems like a 
waste to unregister the coretemp devices at the start of a system sleep 
and then register them back at the end.

Could you simply leave the devices registered throughout the entire
sleep?  Of course, at the end you would have to check that all the CPUs
really did come back up, and unregister the devices for the CPUs that
are still offline.

Alan Stern

Re: broken suspend [Was: 2.6.24-rc2-mm1]

[Rafael J. Wysocki]

On Monday, 19 of November 2007, Rudolf Marek wrote:
> Hello all,
> >>> gives coretemp_cpu_callback -> coretemp_device_remove ->
> >>> platform_device_unregister, so coretemp seems to be what I have and you don't.
> > 
> > Yes.
> > 
> > For the coretemp developers: coretemp_cpu_callback() needs to be more 
> > careful about what it does.  During a system sleep transition (suspend, 
> > hibernate, resume) it isn't possible to register or unregister a 
> > device.  Attempts to register will fail and attempts to unregister will 
> > block until the system sleep is over -- and for this callback that 
> > means hanging.
> 
> Well I wrote the driver. Thanks for the clarification. If I recall correctly I 
> looked how this part should be done from others drivers. Now while checking
> what happened to the file, seems Rafael added something related.
> 
> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commit;h=8bb7844286fb8c9fce6f65d8288aeb09d03a5e0d

Well, in principle you can use the observation that the _FROZEN versions
are used during suspend/hibernation.  Thus, if you only unregister the device
for CPU_DEAD, but you won't do that for CPU_DEAD_FROZEN, it will work as long
as the freezer is there.

> > It's not clear what the best way is to fix this.  Perhaps the CPU 
> > notification should be sent along with a special flag indicating that 
> > the CPU transition is part of a system sleep (although this seems 
> > racy).

In fact, it's already done that way and I don't think it's racy (see above).

Greetings,
Rafael