hda_intel (sigmatel) defunct in mmotm 2008-09-13-03-09
Subsystems (5)
Hi,
I've found my sound defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
My debug shows:
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: setting latency timer to 64 azx_codec_create (1232): t=0, max=4, def=3, mask=4, probe_mask=ffffffff snd_hda_codec_new A: ffff88007b6988f8patch_stac927x A: 0stac92xx_parse_auto_config Astac92xx_parse_auto_config Bstac92xx_parse_auto_config Estac92xx_parse_auto_config Fstac92xx_parse_auto_config Gstac92xx_parse_auto_config Hstac92xx_parse_auto_config L: 0stac92xx_parse_auto_config M: 0stac92xx_parse_auto_config Ostac92xx_parse_auto_config Pstac92xx_parse_auto_config Q stac92xx_auto_create_spdif_mux_ctls: num_cons=5 patch_stac927x B: -22snd_hda_codec_new E: -22azx_codec_create (1239): c=2, err=-22azx_codec_create (1251): cod=0, acod=0
hda-intel: no codecs initialized
HDA Intel 0000:00:1b.0: PCI INT A disabled
The problem lays in the newly added function:stac92xx_auto_create_spdif_mux_ctls
The count (=5) is out of bounds.
The device is:
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
Subsystem: Intel Corporation Optiplex 755
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
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=55mAPME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1
<1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency
L0 <64ns, L1 <1us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk-
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Virtual Channel <?>
Capabilities: [130] Root Complex Link <?>
Kernel driver in use: HDA Intel
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 0a 01 00 00
codec output from OK kernel:
Codec: SigmaTel STAC9274D
Address: 2
Vendor Id: 0x83847621
Subsystem Id: 0x100
Revision Id: 0x100201
No Modem Function Group found
Default PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x1]: PCMDefault Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0
Node 0x02 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x49 0x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x03 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x49 0x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x04 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x49 0x46]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x05 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x49 0x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node 0x06 [Audio Output] wcaps 0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0xff 0xff]
Converter: stream=0, channel=0
Power: setting=D3, actual=D3
Delay: 13 samples
Node 0x07 [Audio Input] wcaps 0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 1
0x1b
Processing caps: benign=0, ncoeff=0
Node 0x08 [Audio Input] wcaps 0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 1
0x1c
Processing caps: benign=0, ncoeff=0
Node 0x09 [Audio Input] wcaps 0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 1
0x1d
Processing caps: benign=0, ncoeff=0
Node 0x0a [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x02214020: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
DefAssociation = 0x2, Sequence = 0x0
Pin-ctls: 0xc0: OUT HP VREF_HIZ
Unsolicited: tag=30, enabled=1
Connection: 3
0x02* 0x03 0x06
Node 0x0b [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x02a19080: [Jack] Mic at Ext Front
Conn = 1/8, Color = Pink
DefAssociation = 0x8, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
Connection: 3
0x02* 0x03 0x06
Node 0x0c [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x0181304e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
DefAssociation = 0x4, Sequence = 0xe
Pin-ctls: 0x20: IN VREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 1
0x03
Node 0x0d [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
DefAssociation = 0x1, Sequence = 0x0
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 1
0x02
Node 0x0e [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x01a19040: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
DefAssociation = 0x4, Sequence = 0x0
Pin-ctls: 0x24: IN VREF_80
Unsolicited: tag=00, enabled=0
Connection: 1
0x04
Node 0x0f [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default 0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
DefAssociation = 0x1, Sequence = 0x2
Pin-ctls: 0x40: OUT VREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 1
0x05
Node 0x10 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect Trigger ImpSense Pin Default 0x01016011: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Orange
DefAssociation = 0x1, Sequence = 0x1
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x04
Node 0x11 [Pin Complex] wcaps 0x400181: Stereo
Pincap 0x0837: IN OUT Detect Trigger ImpSense Pin Default 0x01012014: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Grey
DefAssociation = 0x1, Sequence = 0x4
Pin-ctls: 0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 1
0x03
Node 0x12 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x503301f0: [N/A] CD at Int N/A
Conn = ATAPI, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Node 0x13 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Node 0x14 [Pin Complex] wcaps 0x400001: Stereo
Pincap 0x0820: IN
Pin Default 0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation = 0xf, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x00:
Node 0x15 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x16 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x17 [Audio Selector] wcaps 0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x00 0x00]
Connection: 9
0x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11
Node 0x18 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x15
Node 0x19 [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x16
Node 0x1a [Audio Selector] wcaps 0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x00 0x00]
Connection: 1
0x17
Node 0x1b [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x00 0x00]
Connection: 3
0x18* 0x13 0x14
Node 0x1c [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80]
Connection: 3
0x19* 0x13 0x14
Node 0x1d [Audio Selector] wcaps 0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x80 0x80]
Connection: 3
0x1a* 0x13 0x14
Node 0x1e [Audio Output] wcaps 0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category: 0x0
PCM:
rates [0x7e0]: 44100 48000 88200 96000 176400 192000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3 Delay: 4 samples
Node 0x1f [Vendor Defined Widget] wcaps 0xf30201: Stereo Digital
Delay: 3 samples
Node 0x20 [Audio Input] wcaps 0x140311: Stereo Digital
Converter: stream=0, channel=0
SDI-Select: 0
Digital:
Digital category: 0x0
PCM:
rates [0x160]: 44100 48000 96000
bits [0xe]: 16 20 24
formats [0x5]: PCM AC3
Delay: 4 samples
Connection: 1
0x22Node 0x21 [Pin Complex] wcaps 0x400301: Stereo Digital
Pincap 0x0810: OUT
Pin Default 0x01442170: [Jack] SPDIF Out at Ext Rear
Conn = RCA, Color = Grey
DefAssociation = 0x7, Sequence = 0x0
Misc = NO_PRESENCE
Pin-ctls: 0x40: OUT
Connection: 5
0x1e* 0x1f 0x1b 0x1c 0x1d
Node 0x22 [Pin Complex] wcaps 0x430681: Stereo Digital
Pincap 0x0810024: IN EAPD Detect
EAPD 0x0:
Pin Default 0x81c42090: [Fixed] SPDIF In at Ext Rear
Conn = RCA, Color = Grey
DefAssociation = 0x9, Sequence = 0x0
Pin-ctls: 0x20: IN
Unsolicited: tag=00, enabled=0
Power: setting=D0, actual=D0
Delay: 3 samples
Node 0x23 [Beep Generator Widget] wcaps 0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00]
Node 0x24 [Volume Knob Widget] wcaps 0x600000: Mono
Volume-Knob: delta=1, steps=127, direct=1, val=127
Connection: 5
0x02* 0x03 0x04 0x05 0x06
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Hello Jiri,
Yeah the problem is my bounds checking isn't correct, submitting a patch upstream shortly.
Thanks,
Matt Ranostay
Quoted 345 lines · Jiri Slaby
Hi,
I've found my sound defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
My debug shows:
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: setting latency timer to 64azx_codec_create(1232): t=0, max=4, def=3, mask=4, probe_mask=ffffffffsnd_hda_codec_newA:ffff88007b6988f8patch_stac927xA: 0stac92xx_parse_auto_configAstac92xx_parse_auto_configBstac92xx_parse_auto_configEstac92xx_parse_auto_configFstac92xx_parse_auto_configGstac92xx_parse_auto_configHstac92xx_parse_auto_configL: 0stac92xx_parse_auto_configM: 0stac92xx_parse_auto_configOstac92xx_parse_auto_configPstac92xx_parse_auto_configQstac92xx_auto_create_spdif_mux_ctls: num_cons=5patch_stac927xB: -22snd_hda_codec_newE: -22azx_codec_create(1239): c=2, err=-22azx_codec_create(1251): cod=0, acod=0
hda-intel: no codecs initialized
HDA Intel 0000:00:1b.0: PCI INT A disabledThe problem lays in the newly added function:
stac92xx_auto_create_spdif_mux_ctls
The count (=5) is out of bounds.The device is:
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
Subsystem: Intel Corporation Optiplex 755
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory atffa70000(64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mAPME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1
<1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency
L0 <64ns, L1 <1us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk-
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Virtual Channel <?>
Capabilities: [130] Root Complex Link <?>
Kernel driver in use: HDA Intel
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 0a 01 00 00codec output from OK kernel:
Codec: SigmaTel STAC9274D
Address: 2
Vendor Id:0x83847621
Subsystem Id:0x100
Revision Id:0x100201
No Modem Function Group found
Default PCM:rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCMDefault Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0
Node0x02[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x03[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x04[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x46]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x05[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x06[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0xff0xff]
Converter: stream=0, channel=0
Power: setting=D3, actual=D3
Delay: 13 samples
Node0x07[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1bProcessing caps: benign=0, ncoeff=0
Node0x08[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1cProcessing caps: benign=0, ncoeff=0
Node0x09[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1dProcessing caps: benign=0, ncoeff=0
Node0x0a[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x02214020: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
DefAssociation =0x2, Sequence =0x0
Pin-ctls:0xc0: OUT HPVREF_HIZ
Unsolicited: tag=30, enabled=1
Connection: 30x02* 0x03 0x06Node
0x0b[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x02a19080: [Jack] Mic at Ext Front
Conn = 1/8, Color = Pink
DefAssociation =0x8, Sequence =0x0
Pin-ctls:0x24: INVREF_80
Unsolicited: tag=00, enabled=0
Connection: 30x02* 0x03 0x06Node
0x0c[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x0181304e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
DefAssociation =0x4, Sequence =0xe
Pin-ctls:0x20: INVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x03Node
0x0d[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
DefAssociation =0x1, Sequence =0x0
Pin-ctls:0x40: OUTVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x02Node
0x0e[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01a19040: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
DefAssociation =0x4, Sequence =0x0
Pin-ctls:0x24: INVREF_80
Unsolicited: tag=00, enabled=0
Connection: 10x04Node
0x0f[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
DefAssociation =0x1, Sequence =0x2
Pin-ctls:0x40: OUTVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x05Node
0x10[Pin Complex] wcaps0x400181: Stereo
Pincap0x0837: IN OUT Detect Trigger ImpSense Pin Default0x01016011: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Orange
DefAssociation =0x1, Sequence =0x1
Pin-ctls:0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 10x04Node
0x11[Pin Complex] wcaps0x400181: Stereo
Pincap0x0837: IN OUT Detect Trigger ImpSense Pin Default0x01012014: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Grey
DefAssociation =0x1, Sequence =0x4
Pin-ctls:0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 10x03Node
0x12[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x503301f0: [N/A] CD at Int N/A
Conn = ATAPI, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x13[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x14[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x15[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x16[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x17[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x18[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x15Node
0x19[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x16Node
0x1a[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x17Node
0x1b[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x000x00]
Connection: 30x18* 0x13 0x14Node
0x1c[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x800x80]
Connection: 30x19* 0x13 0x14Node
0x1d[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x800x80]
Connection: 30x1a* 0x13 0x14Node
0x1e[Audio Output] wcaps0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category:0x0
PCM:rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3Delay: 4 samples
Node0x1f[Vendor Defined Widget] wcaps0xf30201: Stereo Digital
Delay: 3 samples
Node0x20[Audio Input] wcaps0x140311: Stereo Digital
Converter: stream=0, channel=0
SDI-Select: 0
Digital:
Digital category:0x0
PCM:rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Delay: 4 samples Connection: 1 0x22Node
0x21[Pin Complex] wcaps0x400301: Stereo Digital
Pincap0x0810: OUT
Pin Default0x01442170: [Jack] SPDIF Out at Ext Rear
Conn = RCA, Color = Grey
DefAssociation =0x7, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x40: OUT
Connection: 50x1e* 0x1f 0x1b 0x1c 0x1dNode
0x22[Pin Complex] wcaps0x430681: Stereo Digital
Pincap0x0810024: IN EAPD Detect
EAPD0x0:
Pin Default0x81c42090: [Fixed] SPDIF In at Ext Rear
Conn = RCA, Color = Grey
DefAssociation =0x9, Sequence =0x0
Pin-ctls:0x20: IN
Unsolicited: tag=00, enabled=0
Power: setting=D0, actual=D0
Delay: 3 samples
Node0x23[Beep Generator Widget] wcaps0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00]
Node0x24[Volume Knob Widget] wcaps0x600000: Mono
Volume-Knob: delta=1, steps=127, direct=1, val=127
Connection: 5
Quoted 2 lines
0x02* 0x03 0x04 0x05 0x06
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjObi8ACgkQ7s2wy7nhBHW4FgCdEHD/SGJYCArw8pIdsdFiXruT piIAn13101Q+dkQnP6bcrLzSqRUUsNw4
=61nc
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Bug fix patch at:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010767.html
Thanks,
Matt Ranostay
Quoted 345 lines · Jiri Slaby
Hi,
I've found my sound defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
My debug shows:
HDA Intel 0000:00:1b.0: PCI INT A -> GSI 22 (level, low) -> IRQ 22 HDA Intel 0000:00:1b.0: setting latency timer to 64azx_codec_create(1232): t=0, max=4, def=3, mask=4, probe_mask=ffffffffsnd_hda_codec_newA:ffff88007b6988f8patch_stac927xA: 0stac92xx_parse_auto_configAstac92xx_parse_auto_configBstac92xx_parse_auto_configEstac92xx_parse_auto_configFstac92xx_parse_auto_configGstac92xx_parse_auto_configHstac92xx_parse_auto_configL: 0stac92xx_parse_auto_configM: 0stac92xx_parse_auto_configOstac92xx_parse_auto_configPstac92xx_parse_auto_configQstac92xx_auto_create_spdif_mux_ctls: num_cons=5patch_stac927xB: -22snd_hda_codec_newE: -22azx_codec_create(1239): c=2, err=-22azx_codec_create(1251): cod=0, acod=0
hda-intel: no codecs initialized
HDA Intel 0000:00:1b.0: PCI INT A disabledThe problem lays in the newly added function:
stac92xx_auto_create_spdif_mux_ctls
The count (=5) is out of bounds.The device is:
00:1b.0 Audio device: Intel Corporation 82801I (ICH9 Family) HD Audio Controller (rev 02)
Subsystem: Intel Corporation Optiplex 755
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 32 bytes
Interrupt: pin A routed to IRQ 22
Region 0: Memory atffa70000(64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mAPME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] Message Signalled Interrupts: Mask- 64bit+ Count=1/1
Enable-
Address: 0000000000000000 Data: 0000
Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s <64ns, L1
<1us
ExtTag- RBE- FLReset+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop+ MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #0, Speed unknown, Width x0, ASPM unknown, Latency
L0 <64ns, L1 <1us
ClockPM- Suprise- LLActRep- BwNot-
LnkCtl: ASPM Disabled; Disabled- Retrain- CommClk-
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed unknown, Width x0, TrErr- Train- SlotClk-
DLActive- BWMgmt- ABWMgmt-
Capabilities: [100] Virtual Channel <?>
Capabilities: [130] Root Complex Link <?>
Kernel driver in use: HDA Intel
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 0a 01 00 00codec output from OK kernel:
Codec: SigmaTel STAC9274D
Address: 2
Vendor Id:0x83847621
Subsystem Id:0x100
Revision Id:0x100201
No Modem Function Group found
Default PCM:rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x1]: PCMDefault Amp-In caps: ofs=0x00, nsteps=0x0e, stepsize=0x05, mute=0 Default Amp-Out caps: ofs=0x7f, nsteps=0x7f, stepsize=0x02, mute=1
GPIO: io=3, o=0, i=0, unsolicited=1, wake=1
IO[0]: enable=1, dir=1, wake=0, sticky=0, data=1 IO[1]: enable=0, dir=0, wake=0, sticky=0, data=0 IO[2]: enable=0, dir=0, wake=0, sticky=0, data=0
Node0x02[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x03[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x04[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x46]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x05[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0x490x49]
Converter: stream=5, channel=0
Power: setting=D0, actual=D0
Delay: 13 samples
Node0x06[Audio Output] wcaps0xd0c05: Stereo Amp-Out R/L
Amp-Out caps: N/A
Amp-Out vals: [0xff0xff]
Converter: stream=0, channel=0
Power: setting=D3, actual=D3
Delay: 13 samples
Node0x07[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1bProcessing caps: benign=0, ncoeff=0
Node0x08[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1cProcessing caps: benign=0, ncoeff=0
Node0x09[Audio Input] wcaps0x1d0541: Stereo
Converter: stream=0, channel=0
SDI-Select: 0
Power: setting=D0, actual=D0
Delay: 13 samples
Connection: 10x1dProcessing caps: benign=0, ncoeff=0
Node0x0a[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x02214020: [Jack] HP Out at Ext Front
Conn = 1/8, Color = Green
DefAssociation =0x2, Sequence =0x0
Pin-ctls:0xc0: OUT HPVREF_HIZ
Unsolicited: tag=30, enabled=1
Connection: 30x02* 0x03 0x06Node
0x0b[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x02a19080: [Jack] Mic at Ext Front
Conn = 1/8, Color = Pink
DefAssociation =0x8, Sequence =0x0
Pin-ctls:0x24: INVREF_80
Unsolicited: tag=00, enabled=0
Connection: 30x02* 0x03 0x06Node
0x0c[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x0181304e: [Jack] Line In at Ext Rear
Conn = 1/8, Color = Blue
DefAssociation =0x4, Sequence =0xe
Pin-ctls:0x20: INVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x03Node
0x0d[Pin Complex] wcaps0x400181: Stereo
Pincap0x08173f: IN OUT HP Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01014010: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Green
DefAssociation =0x1, Sequence =0x0
Pin-ctls:0x40: OUTVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x02Node
0x0e[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01a19040: [Jack] Mic at Ext Rear
Conn = 1/8, Color = Pink
DefAssociation =0x4, Sequence =0x0
Pin-ctls:0x24: INVREF_80
Unsolicited: tag=00, enabled=0
Connection: 10x04Node
0x0f[Pin Complex] wcaps0x400181: Stereo
Pincap0x081737: IN OUT Detect Trigger ImpSense
Vref caps: HIZ 50 GRD 80
Pin Default0x01011012: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Black
DefAssociation =0x1, Sequence =0x2
Pin-ctls:0x40: OUTVREF_HIZ
Unsolicited: tag=00, enabled=0
Connection: 10x05Node
0x10[Pin Complex] wcaps0x400181: Stereo
Pincap0x0837: IN OUT Detect Trigger ImpSense Pin Default0x01016011: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Orange
DefAssociation =0x1, Sequence =0x1
Pin-ctls:0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 10x04Node
0x11[Pin Complex] wcaps0x400181: Stereo
Pincap0x0837: IN OUT Detect Trigger ImpSense Pin Default0x01012014: [Jack] Line Out at Ext Rear
Conn = 1/8, Color = Grey
DefAssociation =0x1, Sequence =0x4
Pin-ctls:0x40: OUT
Unsolicited: tag=00, enabled=0
Connection: 10x03Node
0x12[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x503301f0: [N/A] CD at Int N/A
Conn = ATAPI, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x13[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x14[Pin Complex] wcaps0x400001: Stereo
Pincap0x0820: IN
Pin Default0x50a001f0: [N/A] Mic at Int N/A
Conn = Unknown, Color = Unknown
DefAssociation =0xf, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x00:
Node0x15[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x16[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x17[Audio Selector] wcaps0x30010d: Stereo Amp-Out
Amp-Out caps: ofs=0x00, nsteps=0x04, stepsize=0x27, mute=0 Amp-Out vals: [0x000x00]
Connection: 90x0e* 0x12 0x0f 0x0b 0x0c 0x0d 0x0a 0x10 0x11Node
0x18[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x15Node
0x19[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x16Node
0x1a[Audio Selector] wcaps0x300103: Stereo Amp-In
Amp-In caps: N/A
Amp-In vals: [0x000x00]
Connection: 10x17Node
0x1b[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x000x00]
Connection: 30x18* 0x13 0x14Node
0x1c[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x800x80]
Connection: 30x19* 0x13 0x14Node
0x1d[Audio Selector] wcaps0x30090d: Stereo Amp-Out R/L
Amp-Out caps: ofs=0x00, nsteps=0x00, stepsize=0x00, mute=1 Amp-Out vals: [0x800x80]
Connection: 30x1a* 0x13 0x14Node
0x1e[Audio Output] wcaps0x40211: Stereo Digital
Converter: stream=0, channel=0
Digital:
Digital category:0x0
PCM:rates [0x7e0]: 44100 48000 88200 96000 176400 192000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3Delay: 4 samples
Node0x1f[Vendor Defined Widget] wcaps0xf30201: Stereo Digital
Delay: 3 samples
Node0x20[Audio Input] wcaps0x140311: Stereo Digital
Converter: stream=0, channel=0
SDI-Select: 0
Digital:
Digital category:0x0
PCM:rates [0x160]: 44100 48000 96000 bits [0xe]: 16 20 24 formats [0x5]: PCM AC3 Delay: 4 samples Connection: 1 0x22Node
0x21[Pin Complex] wcaps0x400301: Stereo Digital
Pincap0x0810: OUT
Pin Default0x01442170: [Jack] SPDIF Out at Ext Rear
Conn = RCA, Color = Grey
DefAssociation =0x7, Sequence =0x0
Misc =NO_PRESENCE
Pin-ctls:0x40: OUT
Connection: 50x1e* 0x1f 0x1b 0x1c 0x1dNode
0x22[Pin Complex] wcaps0x430681: Stereo Digital
Pincap0x0810024: IN EAPD Detect
EAPD0x0:
Pin Default0x81c42090: [Fixed] SPDIF In at Ext Rear
Conn = RCA, Color = Grey
DefAssociation =0x9, Sequence =0x0
Pin-ctls:0x20: IN
Unsolicited: tag=00, enabled=0
Power: setting=D0, actual=D0
Delay: 3 samples
Node0x23[Beep Generator Widget] wcaps0x70000c: Mono Amp-Out
Amp-Out caps: ofs=0x03, nsteps=0x03, stepsize=0x17, mute=0 Amp-Out vals: [0x00]
Node0x24[Volume Knob Widget] wcaps0x600000: Mono
Volume-Knob: delta=1, steps=127, direct=1, val=127
Connection: 5
Quoted 2 lines
0x02* 0x03 0x04 0x05 0x06
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjPxgAACgkQ7s2wy7nhBHULRQCeM0uqdR/rIPRHl+YhMKuZqIg7 NxEAoKQDzb2zw05UyY+i48Y2G65KZkoA
=CQnT
-----END PGP SIGNATURE-----
Quoted 3 lines · Matthew Ranostay
Bug fix patch at:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010767.html
It works, thanks.
Another problem is when I switch IEC958 in alsamixer, I get:
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffffa0057d8a>] snd_hda_spdif_out_switch_put+0xca/0x170 [snd_hda_intel] PGD 7a3ea067 PUD 7a378067 PMD 0 Oops: 0000 [1] SMP
last sysfs file: /sys/devices/virtual/net/tun0/type Dumping ftrace buffer:
(ftrace buffer empty)
CPU 0
Modules linked in: arc4 ecb cryptomgr aead crypto_blkcipher crypto_algapi ath5k mac80211 hid_microsoft led_class usbhid rtc_cmos snd_hda_intel hid ohci1394 ieee1394 evdev cfg80211 ff_memless [last unloaded: freq_table] Pid: 3831, comm: alsamixer Tainted: G W 2.6.27-rc6-mm1_64 #452 RIP: 0010:[<ffffffffa0057d8a>] [<ffffffffa0057d8a>] snd_hda_spdif_out_switch_put+0xca/0x170 [snd_hda_intel] RSP: 0018:ffff88007a3d5c68 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000f RDX: ffff88007b410be0 RSI: 0000000000070d1e RDI: ffff88007bda9bb0 RBP: ffff88007a3d5ca8 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff8049083f R11: ffff880078cd4240 R12: ffff88007bd2f398 R13: 0000000000000001 R14: 0000000000000001 R15: 000000000000001e FS: 00007fb6b40476f0(0000) GS:ffffffff806f2400(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007a3cc000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process alsamixer (pid: 3831, threadinfo ffff88007a3d4000, task ffff88007a35b300) Stack: 0000000101e33400 ffff88007bd2f568 001e88007a3d5cc8 ffff88007b51d1f0 ffff880078cd4240 ffff88007bd2d5a0 ffff88007bd2d708 ffff88007b7720c8 ffff88007a3d5cc8 ffffffff80493097 ffff88007b51d1f0 ffff880078cd4240 Call Trace: [<ffffffff80493097>] slave_put_val+0x37/0xc0 [<ffffffff804933bc>] slave_put+0x5c/0x70 [<ffffffff8048fdf9>] snd_ctl_elem_write+0x119/0x160 [<ffffffff804908a5>] snd_ctl_ioctl+0x295/0x940 [<ffffffff80258934>] ? up+0x34/0x50 [<ffffffff80254502>] ? remove_wait_queue+0x52/0x60 [<ffffffff803a198c>] ? read_chan+0x3ac/0x8b0 [<ffffffff8023193e>] ? __wake_up+0x4e/0x70 [<ffffffff80242b32>] ? current_fs_time+0x22/0x30 [<ffffffff802c9d01>] vfs_ioctl+0x31/0xa0 [<ffffffff802c9ff3>] do_vfs_ioctl+0x283/0x2f0 [<ffffffff802ca0aa>] sys_ioctl+0x4a/0x80 [<ffffffff8020c4cb>] system_call_fastpath+0x16/0x1b Code: 00 4c 89 e7 0f b7 c9 44 0f b7 7d d6 44 0f b6 e9 89 4d c4 45 89 e8 b9 0d 07
00 00 44 89 fe e8 8e f6 ff ff 49 8b 9c 24 f8 01 00 00 <0f> b7 03 66 85 c0 74 27 66 0f 1f 44 00 00 31 d2 48 83 c3 02 0f
RIP [<ffffffffa0057d8a>] snd_hda_spdif_out_switch_put+0xca/0x170 [snd_hda_intel]
RSP <ffff88007a3d5c68>
CR2: 0000000000000000
---[ end trace 4eaa2a86a8e2da22 ]---
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Quoted 9 lines · Jiri Slaby
Quoted 3 lines · Matthew Ranostay
Bug fix patch at:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010767.html
It works, thanks.
Another problem is when I switch IEC958 in alsamixer, I get:
Ok, the problem was that codec->slave_dig_outs getting a dereference when NULL. This has been already fixed in Takashi's sound-2.6.git tree, with the commit id 06efc354f735d5dbbdf4653fc6a8acd489ac5a18.
Thanks,
Matt Ranostay
- ---
# git log pci/hda/hda_codec.c ... commit 06efc354f735d5dbbdf4653fc6a8acd489ac5a18 Author: Herton Ronaldo Krzesinski <[email protected]> Date: Sat Sep 13 16:44:29 2008 +0200
ALSA: hda: fix oopses in snd-hda-intel after digital slave support additions
Many places fail to check if codec has slave_dig_outs entries (the most common case is not having any entry), leading to various possible oopses in hda_codec code.
...
# git diff af41e1693fdaa7a3e25cc8dd1ff3180f83487e5a 06efc354f735d5dbbdf4653fc6a8acd489ac5a18 pci/hda/hda_codec.c
sound/pci/hda/hda_codec.c +0 -0
- --- a/sound/pci/hda/hda_codec.c
+++ b/sound/pci/hda/hda_codec.c
@@ -1457,14 +1457,15 @@ static int snd_hda_spdif_default_put(struct snd_kcontrol *kcontrol,
AC_VERB_SET_DIGI_CONVERT_2,
val >> 8);
- - for (d = codec->slave_dig_outs; *d; d++) {
- - snd_hda_codec_write_cache(codec, *d, 0,
+ if (codec->slave_dig_outs)
+ for (d = codec->slave_dig_outs; *d; d++) {
+ snd_hda_codec_write_cache(codec, *d, 0,
AC_VERB_SET_DIGI_CONVERT_1, val & 0xff);
- - snd_hda_codec_write_cache(codec, *d, 0,
+ snd_hda_codec_write_cache(codec, *d, 0,
AC_VERB_SET_DIGI_CONVERT_2, val >> 8);
- - }
+ }
}
mutex_unlock(&codec->spdif_mutex);
@@ -1502,8 +1503,9 @@ static int snd_hda_spdif_out_switch_put(struct snd_kcontrol *kcontrol,
AC_VERB_SET_DIGI_CONVERT_1,
val & 0xff);
- - for (d = codec->slave_dig_outs; *d; d++)
- - snd_hda_codec_write_cache(codec, *d, 0,
+ if (codec->slave_dig_outs)
+ for (d = codec->slave_dig_outs; *d; d++)
+ snd_hda_codec_write_cache(codec, *d, 0,
AC_VERB_SET_DIGI_CONVERT_1,
val & 0xff);
/* unmute amp switch (if any) */
@@ -1659,8 +1661,9 @@ static int snd_hda_spdif_in_switch_put(struct snd_kcontrol *kcontrol,
snd_hda_codec_write_cache(codec, nid, 0,
AC_VERB_SET_DIGI_CONVERT_1, val);
- - for (d = codec->slave_dig_outs; *d; d++)
- - snd_hda_codec_write_cache(codec, *d, 0,
+ if (codec->slave_dig_outs)
+ for (d = codec->slave_dig_outs; *d; d++)
+ snd_hda_codec_write_cache(codec, *d, 0,
AC_VERB_SET_DIGI_CONVERT_1, val);
}
mutex_unlock(&codec->spdif_mutex);
@@ -2610,9 +2613,10 @@ static void setup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid,
snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_DIGI_CONVERT_1,
codec->spdif_ctls & ~AC_DIG1_ENABLE & 0xff);
- - for (d = codec->slave_dig_outs; *d; d++)
- - snd_hda_codec_write(codec, *d, 0,
- - AC_VERB_SET_DIGI_CONVERT_1,
+ if (codec->slave_dig_outs)
+ for (d = codec->slave_dig_outs; *d; d++)
+ snd_hda_codec_write(codec, *d, 0,
+ AC_VERB_SET_DIGI_CONVERT_1,
codec->spdif_ctls & ~AC_DIG1_ENABLE & 0xff);
}
snd_hda_codec_setup_stream(codec, nid, stream_tag, 0, format);
@@ -2621,9 +2625,10 @@ static void setup_dig_out_stream(struct hda_codec *codec, hda_nid_t nid,
snd_hda_codec_write(codec, nid, 0, AC_VERB_SET_DIGI_CONVERT_1,
codec->spdif_ctls & 0xff);
- - for (d = codec->slave_dig_outs; *d; d++)
- - snd_hda_codec_write(codec, *d, 0,
- - AC_VERB_SET_DIGI_CONVERT_1,
+ if (codec->slave_dig_outs)
+ for (d = codec->slave_dig_outs; *d; d++)
+ snd_hda_codec_write(codec, *d, 0,
+ AC_VERB_SET_DIGI_CONVERT_1,
codec->spdif_ctls & 0xff);
}
Quoted 44 lines
BUG: unable to handle kernel NULL pointer dereference at 0000000000000000 IP: [<ffffffffa0057d8a>] snd_hda_spdif_out_switch_put+0xca/0x170 [snd_hda_intel] PGD 7a3ea067 PUD 7a378067 PMD 0 Oops: 0000 [1] SMPlast sysfs file:
/sys/devices/virtual/net/tun0/typeDumping ftrace buffer:
(ftrace buffer empty)
CPU 0Modules linked in: arc4 ecb cryptomgr aead crypto_blkcipher crypto_algapi ath5k mac80211 hid_microsoft led_class usbhid rtc_cmos snd_hda_intel hid ohci1394 ieee1394 evdev cfg80211 ff_memless [last unloaded: freq_table] Pid: 3831, comm: alsamixer Tainted: G W 2.6.27-rc6-mm1_64 #452 RIP: 0010:[<ffffffffa0057d8a>] [<ffffffffa0057d8a>] snd_hda_spdif_out_switch_put+0xca/0x170 [snd_hda_intel] RSP: 0018:ffff88007a3d5c68 EFLAGS: 00010202 RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000000f RDX: ffff88007b410be0 RSI: 0000000000070d1e RDI: ffff88007bda9bb0 RBP: ffff88007a3d5ca8 R08: 0000000000000001 R09: 0000000000000001 R10: ffffffff8049083f R11: ffff880078cd4240 R12: ffff88007bd2f398 R13: 0000000000000001 R14: 0000000000000001 R15: 000000000000001e FS: 00007fb6b40476f0(0000) GS:ffffffff806f2400(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 0000000000000000 CR3: 000000007a3cc000 CR4: 00000000000006e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Process alsamixer (pid: 3831, threadinfo ffff88007a3d4000, task ffff88007a35b300) Stack: 0000000101e33400 ffff88007bd2f568 001e88007a3d5cc8 ffff88007b51d1f0 ffff880078cd4240 ffff88007bd2d5a0 ffff88007bd2d708 ffff88007b7720c8 ffff88007a3d5cc8 ffffffff80493097 ffff88007b51d1f0 ffff880078cd4240 Call Trace: [<ffffffff80493097>] slave_put_val+0x37/0xc0 [<ffffffff804933bc>] slave_put+0x5c/0x70 [<ffffffff8048fdf9>] snd_ctl_elem_write+0x119/0x160 [<ffffffff804908a5>] snd_ctl_ioctl+0x295/0x940 [<ffffffff80258934>] ? up+0x34/0x50 [<ffffffff80254502>] ? remove_wait_queue+0x52/0x60 [<ffffffff803a198c>] ? read_chan+0x3ac/0x8b0 [<ffffffff8023193e>] ? __wake_up+0x4e/0x70 [<ffffffff80242b32>] ? current_fs_time+0x22/0x30 [<ffffffff802c9d01>] vfs_ioctl+0x31/0xa0 [<ffffffff802c9ff3>] do_vfs_ioctl+0x283/0x2f0 [<ffffffff802ca0aa>] sys_ioctl+0x4a/0x80 [<ffffffff8020c4cb>] system_call_fastpath+0x16/0x1b Code: 00 4c 89 e7 0f b7 c9 44 0f b7 7d d6 44 0f b6 e9 89 4d c4 45 89 e8 b9 0d 07
Quoted 8 lines
00 00 44 89 fe e8 8e f6 ff ff 49 8b 9c 24 f8 01 00 00 <0f> b7 03 66 85 c0 74 27 66 0f 1f 44 00 00 31 d2 48 83 c3 02 0f
RIP [<ffffffffa0057d8a>]snd_hda_spdif_out_switch_put+0xca/0x170[snd_hda_intel]
RSP <ffff88007a3d5c68>
CR2: 0000000000000000---[ end trace 4eaa2a86a8e2da22 ]---
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Darwin)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAkjRD48ACgkQ7s2wy7nhBHWlwwCgn3aWMATxTWYnMnnAhAE8NjzE sEoAn0GIFSiv2Y0RugBFyi00MVYHNmu5
=DLwd
-----END PGP SIGNATURE-----
Quoted 5 lines · Matthew Ranostay
Quoted 4 lines · Jiri Slaby
Quoted 3 lines · Matthew Ranostay
Bug fix patch at:
http://mailman.alsa-project.org/pipermail/alsa-devel/2008-September/010767.html
Quoted 8 lines
Quoted 3 lines
It works, thanks.
Another problem is when I switch IEC958 in alsamixer, I get:
Ok, the problem was that
codec->slave_dig_outsgetting a dereference when NULL. This has been already fixed in Takashi's sound-2.6.git tree, with the commit id06efc354f735d5dbbdf4653fc6a8acd489ac5a18.
ACKing this. Thanks.
suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyHi,
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Dmesg says:
uhci_hcd 0000:00:1d.1: PCI INT B disabled pci_legacy_suspend(): usb_hcd_pci_suspend+0x0/0x3e0 returns -16 pm_op(): pci_pm_suspend+0x0/0xd0 returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspend
$ ls -l /sys/bus/pci/devices/0000:00:1d.1/usb7/ -rw-r--r-- 1 root root 4096 17. zář 18.43 authorized -rw-r--r-- 1 root root 4096 17. zář 18.43 authorized_default -r--r--r-- 1 root root 4096 17. zář 10.51 bcdDevice -rw-r--r-- 1 root root 4096 17. zář 10.51 bConfigurationValue -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceClass -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceProtocol -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceSubClass -r--r--r-- 1 root root 4096 17. zář 10.51 bmAttributes -r--r--r-- 1 root root 4096 17. zář 18.43 bMaxPacketSize0 -r--r--r-- 1 root root 4096 17. zář 10.51 bMaxPower -r--r--r-- 1 root root 4096 17. zář 10.51 bNumConfigurations -r--r--r-- 1 root root 4096 17. zář 10.51 bNumInterfaces -r--r--r-- 1 root root 4096 17. zář 18.43 busnum -r--r--r-- 1 root root 4096 17. zář 10.51 configuration -r--r--r-- 1 root root 65553 17. zář 18.43 descriptors -r--r--r-- 1 root root 4096 17. zář 18.43 dev -r--r--r-- 1 root root 4096 17. zář 10.51 devnum lrwxrwxrwx 1 root root 0 17. zář 10.51 driver -> ../../../../bus/usb/drivers/usb lrwxrwxrwx 1 root root 0 17. zář 18.43 ep_00 -> usb_endpoint/usbdev7.1_ep00 -r--r--r-- 1 root root 4096 17. zář 10.51 idProduct -r--r--r-- 1 root root 4096 17. zář 10.51 idVendor -r--r--r-- 1 root root 4096 17. zář 18.43 manufacturer -r--r--r-- 1 root root 4096 17. zář 10.51 maxchild drwxr-xr-x 2 root root 0 17. zář 18.43 power -r--r--r-- 1 root root 4096 17. zář 18.43 product -r--r--r-- 1 root root 4096 17. zář 18.43 quirks -r--r--r-- 1 root root 4096 17. zář 10.51 serial -r--r--r-- 1 root root 4096 17. zář 10.51 speed lrwxrwxrwx 1 root root 0 17. zář 10.51 subsystem -> ../../../../bus/usb -rw-r--r-- 1 root root 4096 17. zář 10.51 uevent -r--r--r-- 1 root root 4096 17. zář 18.43 urbnum drwxr-xr-x 3 root root 0 17. zář 10.51 usb_endpoint -r--r--r-- 1 root root 4096 17. zář 10.51 version drwxr-xr-x 4 root root 0 17. zář 10.51 7-0:1.0
$ lsusb -s 7:1 Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
_______________________________________________
linux-pm mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/linux-pm
suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyHi,
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Dmesg says:
uhci_hcd 0000:00:1d.1: PCI INT B disabled pci_legacy_suspend(): usb_hcd_pci_suspend+0x0/0x3e0 returns -16 pm_op(): pci_pm_suspend+0x0/0xd0 returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspend
$ ls -l /sys/bus/pci/devices/0000:00:1d.1/usb7/ -rw-r--r-- 1 root root 4096 17. zář 18.43 authorized -rw-r--r-- 1 root root 4096 17. zář 18.43 authorized_default -r--r--r-- 1 root root 4096 17. zář 10.51 bcdDevice -rw-r--r-- 1 root root 4096 17. zář 10.51 bConfigurationValue -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceClass -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceProtocol -r--r--r-- 1 root root 4096 17. zář 10.51 bDeviceSubClass -r--r--r-- 1 root root 4096 17. zář 10.51 bmAttributes -r--r--r-- 1 root root 4096 17. zář 18.43 bMaxPacketSize0 -r--r--r-- 1 root root 4096 17. zář 10.51 bMaxPower -r--r--r-- 1 root root 4096 17. zář 10.51 bNumConfigurations -r--r--r-- 1 root root 4096 17. zář 10.51 bNumInterfaces -r--r--r-- 1 root root 4096 17. zář 18.43 busnum -r--r--r-- 1 root root 4096 17. zář 10.51 configuration -r--r--r-- 1 root root 65553 17. zář 18.43 descriptors -r--r--r-- 1 root root 4096 17. zář 18.43 dev -r--r--r-- 1 root root 4096 17. zář 10.51 devnum lrwxrwxrwx 1 root root 0 17. zář 10.51 driver -> ../../../../bus/usb/drivers/usb lrwxrwxrwx 1 root root 0 17. zář 18.43 ep_00 -> usb_endpoint/usbdev7.1_ep00 -r--r--r-- 1 root root 4096 17. zář 10.51 idProduct -r--r--r-- 1 root root 4096 17. zář 10.51 idVendor -r--r--r-- 1 root root 4096 17. zář 18.43 manufacturer -r--r--r-- 1 root root 4096 17. zář 10.51 maxchild drwxr-xr-x 2 root root 0 17. zář 18.43 power -r--r--r-- 1 root root 4096 17. zář 18.43 product -r--r--r-- 1 root root 4096 17. zář 18.43 quirks -r--r--r-- 1 root root 4096 17. zář 10.51 serial -r--r--r-- 1 root root 4096 17. zář 10.51 speed lrwxrwxrwx 1 root root 0 17. zář 10.51 subsystem -> ../../../../bus/usb -rw-r--r-- 1 root root 4096 17. zář 10.51 uevent -r--r--r-- 1 root root 4096 17. zář 18.43 urbnum drwxr-xr-x 3 root root 0 17. zář 10.51 usb_endpoint -r--r--r-- 1 root root 4096 17. zář 10.51 version drwxr-xr-x 4 root root 0 17. zář 10.51 7-0:1.0
$ lsusb -s 7:1 Bus 007 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 5 lines · Jiri Slaby
Hi,
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Quoted 7 lines
Dmesg says:
uhci_hcd0000:00:1d.1: PCI INT B disabledpci_legacy_suspend():usb_hcd_pci_suspend+0x0/0x3e0returns -16pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspend
The reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
Two days ago I ran 2.6.27-rc6 plus gregkh-all-2.6.27-rc6.patch from
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
on my laptop, and it suspended with no problem. Can you try the same kernel?
If you still run into problems, post more of the dmesg log (with CONFIG_USB_DEBUG enabled, of course!).
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyQuoted 5 lines · Jiri Slaby
Hi,
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Quoted 7 lines
Dmesg says:
uhci_hcd0000:00:1d.1: PCI INT B disabledpci_legacy_suspend():usb_hcd_pci_suspend+0x0/0x3e0returns -16pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspend
The reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
Two days ago I ran 2.6.27-rc6 plus gregkh-all-2.6.27-rc6.patch from
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
on my laptop, and it suspended with no problem. Can you try the same kernel?
If you still run into problems, post more of the dmesg log (with CONFIG_USB_DEBUG enabled, of course!).
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 6 lines · Alan Stern
Quoted 5 lines · Jiri Slaby
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Dmesg says:
Quoted 8 lines
Quoted 5 lines
uhci_hcd0000:00:1d.1: PCI INT B disabledpci_legacy_suspend():usb_hcd_pci_suspend+0x0/0x3e0returns -16pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <----
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480MQuoted 9 lines
Two days ago I ran 2.6.27-rc6 plus gregkh-all-2.6.27-rc6.patch from
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
on my laptop, and it suspended with no problem. Can you try the same kernel?
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).
Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Alan SternQuoted 6 lines · Alan Stern
Quoted 5 lines · Jiri Slaby
I've found suspend on my desktop defunct in mmotm 2008-09-13-03-09 (opposing to 2008-09-10-19-39).
Dmesg says:
Quoted 8 lines
Quoted 5 lines
uhci_hcd0000:00:1d.1: PCI INT B disabledpci_legacy_suspend():usb_hcd_pci_suspend+0x0/0x3e0returns -16pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M <----
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480MQuoted 9 lines
Two days ago I ran 2.6.27-rc6 plus gregkh-all-2.6.27-rc6.patch from
http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/
on my laptop, and it suspended with no problem. Can you try the same kernel?
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).
Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 9 lines · Jiri Slaby
Quoted 6 lines
Quoted 3 lines
pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
Quoted 7 lines
Quoted 2 lines
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcd
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyQuoted 9 lines · Jiri Slaby
Quoted 6 lines
Quoted 3 lines
pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
Quoted 7 lines
Quoted 2 lines
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcd
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 11 lines · Alan Stern
Quoted 9 lines · Jiri Slaby
Quoted 5 lines
Quoted 3 lines
pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
Quoted 2 lines
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).
Quoted 7 lines
Quoted 4 lines
Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcdIn fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Alan SternQuoted 11 lines · Alan Stern
Quoted 9 lines · Jiri Slaby
Quoted 5 lines
Quoted 3 lines
pm_op():pci_pm_suspend+0x0/0xd0returns -16
PM: Device 0000:00:1d.0 failed to suspend: error -16
PM: Some devices failed to suspendThe reason for this error is that the root hub wasn't already suspended. Was there a USB device plugged into that controller?
No:
Quoted 2 lines
If you still run into problems, post more of the dmesg log (with
CONFIG_USB_DEBUGenabled, of course!).
Quoted 7 lines
Quoted 4 lines
Hm, it doesn't work. 2 dmesgs from mmotm 2008-09-10-19-39 (without usb debug) [ok] and -rc6+gkh-all (with usb debug) [fail]:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
http://decibel.fi.muni.cz/~xslaby/dmesg_ok.hcdIn fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 9 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Still no debugging messages. It's because you have CONFIG_DYNAMIC_PRINTK_DEBUG enabled.
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyQuoted 9 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Still no debugging messages. It's because you have CONFIG_DYNAMIC_PRINTK_DEBUG enabled.
Alan Stern
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 12 lines · Alan Stern
Quoted 9 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Quoted 2 lines
Still no debugging messages. It's because you have
CONFIG_DYNAMIC_PRINTK_DEBUGenabled.
If you have that enabled, you can turn on debugging "on the fly" by writing to the debugfs file as described in the documentation for that option.
thanks,
greg k-h
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Alan SternQuoted 12 lines · Alan Stern
Quoted 9 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Quoted 2 lines
Still no debugging messages. It's because you have
CONFIG_DYNAMIC_PRINTK_DEBUGenabled.
If you have that enabled, you can turn on debugging "on the fly" by writing to the debugfs file as described in the documentation for that option.
thanks,
greg k-h
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 11 lines · Greg KH
Quoted 10 lines · Alan Stern
Quoted 8 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Quoted 6 lines
Quoted 2 lines
Still no debugging messages. It's because you have
CONFIG_DYNAMIC_PRINTK_DEBUGenabled.If you have that enabled, you can turn on debugging "on the fly" by writing to the debugfs file as described in the documentation for that option.
I see, I need to boot to that kernel anyway, with dynamic_printk param this time.
Thanks.
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Greg KHQuoted 11 lines · Greg KH
Quoted 10 lines · Alan Stern
Quoted 8 lines · Jiri Slaby
Quoted 2 lines
In fact neither of those logs includes USB debugging messages. Maybe you omitted a mkinitrd step.
I don't think so. I don't use neither vanilla nor initrd so this must be the kernel. Anyway I recompiled with .config linked in and did
# dmesg >dmesg_config.hcd # zcat /proc/config.gz >>dmesg_config.hcd in the built kernel. The file is here: http://decibel.fi.muni.cz/~xslaby/dmesg_config.hcd
Quoted 6 lines
Quoted 2 lines
Still no debugging messages. It's because you have
CONFIG_DYNAMIC_PRINTK_DEBUGenabled.If you have that enabled, you can turn on debugging "on the fly" by writing to the debugfs file as described in the documentation for that option.
I see, I need to boot to that kernel anyway, with dynamic_printk param this time.
Thanks.
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 1 line · Jiri Slaby
I see, I need to boot to that kernel anyway, with
dynamic_printkparam this time.
It didn't work as I expected, nevermind, here comes updated dmesg:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
I seem to overlooked the pci identification before. There are my mouse and kbd connected to that hub behind another hub.
Attaching lsusb -tv again:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480MFull lsusb -vvv version at:
http://decibel.fi.muni.cz/~xslaby/lsusb.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyQuoted 1 line · Jiri Slaby
I see, I need to boot to that kernel anyway, with
dynamic_printkparam this time.
It didn't work as I expected, nevermind, here comes updated dmesg:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
I seem to overlooked the pci identification before. There are my mouse and kbd connected to that hub behind another hub.
Attaching lsusb -tv again:
/: Bus 08.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 07.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 06.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
|__ Port 1: Dev 2, If 0, Class=hub, Driver=hub/3p, 12M
|__ Port 1: Dev 3, If 0, Class=HID, Driver=usbhid, 12M
|__ Port 1: Dev 3, If 1, Class=HID, Driver=usbhid, 12M
|__ Port 2: Dev 4, If 0, Class=HID, Driver=usbhid, 1.5M
/: Bus 05.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 04.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 03.Port 1: Dev 1, Class=root_hub, Driver=uhci_hcd/2p, 12M
/: Bus 02.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480M
/: Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci_hcd/6p, 480MFull lsusb -vvv version at:
http://decibel.fi.muni.cz/~xslaby/lsusb.hcd
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Quoted 5 lines · Jiri Slaby
Quoted 1 line · Jiri Slaby
I see, I need to boot to that kernel anyway, with
dynamic_printkparam this time.It didn't work as I expected, nevermind, here comes updated dmesg:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
Got it. I found the problem, and there is a patch below for you to test.
Rafael, since the type now has a complete pm_ops structure, is there any reason we shouldn't use its suspend/resume methods along with the bus's and the class's? When writing the USB updates I assumed that would be the case -- and as a result we now have a regression which this patch should fix.
(Also, is there any reason why the pm_dev_dbg() shouldn't go inside pm_op()? It precedes every call of that routine.)
If everyone is okay with it, I'll submit the patch with a proper Changelog and Signed-off-by.
Alan Stern
drivers/base/power/main.c +16 -2
@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );
@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Jiri SlabyQuoted 5 lines · Jiri Slaby
Quoted 1 line · Jiri Slaby
I see, I need to boot to that kernel anyway, with
dynamic_printkparam this time.It didn't work as I expected, nevermind, here comes updated dmesg:
http://decibel.fi.muni.cz/~xslaby/dmesg_fail.hcd
Got it. I found the problem, and there is a patch below for you to test.
Rafael, since the type now has a complete pm_ops structure, is there any reason we shouldn't use its suspend/resume methods along with the bus's and the class's? When writing the USB updates I assumed that would be the case -- and as a result we now have a regression which this patch should fix.
(Also, is there any reason why the pm_dev_dbg() shouldn't go inside pm_op()? It precedes every call of that routine.)
If everyone is okay with it, I'll submit the patch with a proper Changelog and Signed-off-by.
Alan Stern
drivers/base/power/main.c +16 -2
@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );
@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
Alan Stern napsal(a):
Quoted 2 lines
If everyone is okay with it, I'll submit the patch with a proper Changelog and Signed-off-by.
Confirming, it works now!
Re: suspend (uhci_hcd) defunct in mmotm 2008-09-13-03-09
In reply to Alan SternAlan Stern napsal(a):
Quoted 2 lines
If everyone is okay with it, I'll submit the patch with a proper Changelog and Signed-off-by.
Confirming, it works now!
PATCH 1/1 PM: use pm_op methods for device types
This patch (as1141) adds code to use the device type's pm_op methods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.
The patch also fixes a couple of spelling errors.
---
This should be merged before 2.6.27 is released, if possible. Otherwise people will find their systems refuse to suspend when any USB devices are attached.
drivers/base/power/main.c +16 -2
@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );
@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );
PATCH 1/1 PM: use pm_op methods for device types
In reply to Jiri SlabyThis patch (as1141) adds code to use the device type's pm_op methods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.
The patch also fixes a couple of spelling errors.
---
This should be merged before 2.6.27 is released, if possible. Otherwise people will find their systems refuse to suspend when any USB devices are attached.
drivers/base/power/main.c +16 -2
@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out.
@@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );
@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );
Re: [PATCH] PM: use pm_op methods for device types
Quoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
It might be better to find that patch and drop it instead, IMO.
Quoted 64 lines
Signed-off-by Alan Stern <[email protected]>Tested-by Jiri Slaby <[email protected]>---
This should be merged before 2.6.27 is released, if possible. Otherwise people will find their systems refuse to suspend when any USB devices are attached.
Index:
usb-2.6/drivers/base/power/main.c
===================================================================drivers/base/power/main.c +16
-2@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out. @@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out. @@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );
Re: [PATCH] PM: use pm_op methods for device types
Quoted 8 lines · Rafael J. Wysocki
Quoted 7 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.
Quoted 6 lines
Quoted 1 line
The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
greg k-h
Re: [PATCH] PM: use pm_op methods for device types
In reply to Rafael J. WysockiQuoted 8 lines · Rafael J. Wysocki
Quoted 7 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.
Quoted 6 lines
Quoted 1 line
The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
greg k-h
Re: [PATCH] PM: use pm_op methods for device types
Quoted 14 lines · Greg KH
Quoted 13 lines · Rafael J. Wysocki
Quoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
Quoted 6 lines
Quoted 1 line
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct device_type are unused. It may be true that the legacy suspend/resume methods are unused, but the new pm_ops methods definitely are used.
Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Alan Stern
Re: [PATCH] PM: use pm_op methods for device types
In reply to Greg KHQuoted 14 lines · Greg KH
Quoted 13 lines · Rafael J. Wysocki
Quoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
Quoted 6 lines
Quoted 1 line
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct device_type are unused. It may be true that the legacy suspend/resume methods are unused, but the new pm_ops methods definitely are used.
Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Alan Stern
Re: [PATCH] PM: use pm_op methods for device types
Quoted 26 lines · Alan Stern
Quoted 14 lines · Greg KH
Quoted 13 lines · Rafael J. Wysocki
Quoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
Quoted 6 lines
Quoted 1 line
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
Quoted 8 lines
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct
device_typeare unused. It may be true that the legacy suspend/resume methods are unused, but the newpm_opsmethods definitely are used.Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Ah, ick.
Hannes, care to respin this patch based on this information?
thanks,
greg k-h
Re: [PATCH] PM: use pm_op methods for device types
In reply to Alan SternQuoted 26 lines · Alan Stern
Quoted 14 lines · Greg KH
Quoted 13 lines · Rafael J. Wysocki
Quoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
Quoted 6 lines
Quoted 1 line
It might be better to find that patch and drop it instead, IMO.
I agree, I think we would have seen more bugs if mainline can't suspend with a USB device attached, right?
confused,
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
Quoted 8 lines
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct
device_typeare unused. It may be true that the legacy suspend/resume methods are unused, but the newpm_opsmethods definitely are used.Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Ah, ick.
Hannes, care to respin this patch based on this information?
thanks,
greg k-h
Re: [PATCH] PM: use pm_op methods for device types
Quoted 10 lines
Quoted 10 lines
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct
device_typeare unused. It may be true that the legacy suspend/resume methods are unused, but the newpm_opsmethods definitely are used.
Quoted 6 lines
Quoted 2 lines
Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Ah, ick.
Hannes, care to respin this patch based on this information?
I guess Hannes patch shoud simply be dropped....
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] PM: use pm_op methods for device types
In reply to Greg KHQuoted 10 lines
Quoted 10 lines
Okay, I was confused too. Looking more closely, it's apparent that mainline is okay and the problem was introduced by Hannes Reinecke's
driver-core-remove-suspend-resume-callbacks-for-device-type.patch
which states that the suspend/resume callbacks in struct
device_typeare unused. It may be true that the legacy suspend/resume methods are unused, but the newpm_opsmethods definitely are used.
Quoted 6 lines
Quoted 2 lines
Therefore part or all of Hannes patch should be reverted. And the mainline is okay as it stands.
Ah, ick.
Hannes, care to respin this patch based on this information?
I guess Hannes patch shoud simply be dropped....
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
Re: [PATCH] PM: use pm_op methods for device types
In reply to Alan SternQuoted 8 lines · Alan Stern
This patch (as1141) adds code to use the device type's
pm_opmethods, if they are defined. It fixes a regression in the USB PM code; the various suspend and resume methods are defined in the device type rather than in the bus, because USB devices have to be handled differently from USB interfaces. Without the patch, those methods never get called.The patch also fixes a couple of spelling errors.
Hm, these changes are not needed in the current mainline, so there's a patch in -next that removes the code added by this patch.
It might be better to find that patch and drop it instead, IMO.
Quoted 64 lines
Signed-off-by Alan Stern <[email protected]>Tested-by Jiri Slaby <[email protected]>---
This should be merged before 2.6.27 is released, if possible. Otherwise people will find their systems refuse to suspend when any USB devices are attached.
Index:
usb-2.6/drivers/base/power/main.c
===================================================================drivers/base/power/main.c +16
-2@@ -107,7 +107,7 @@ void device_pm_remove(struct device *dev }/** -* pm_op - execute the PM operation appropiate for given PM event +* pm_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out. @@ -166,7 +166,7 @@ static int pm_op(struct device *dev, str }/** -* pm_noirq_op - execute the PM operation appropiate for given PM event +* pm_noirq_op - execute the PM operation appropriate for given PM event * @dev: Device. * @ops: PM operations to choose from. * @state: PM transition of the system being carried out. @@ -363,6 +363,13 @@ static int resume_device(struct device * goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->class) {if (dev->class->pm) {pm_dev_dbg (dev, state,"class " );@@ -596,6 +603,13 @@ static int suspend_device(struct device goto End; } +if (dev->type && dev->type->pm) { +pm_dev_dbg (dev, state,"type " ); + error =pm_op (dev, dev->type->pm, state); +if (error) + goto End; + } +if (dev->bus) {if (dev->bus->pm) {pm_dev_dbg (dev, state,"" );