[alsa-devel] Issues w/ Creative Labs [SB X-Fi Xtreme Audio] CA0110-IBG
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote:
At Tue, 24 Feb 2015 23:55:25 -0800, Alnie wrote:
[ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on slot(3): already powering off [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on slot(3): already powering on
pciehp reacted power off and on here, and...
[ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 [ 2620.876426] pci 0000:05:00.0: supports D1 D2 [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-0c] (conflicts with (null) [bus 05-0c])
.... and something failed here for the PCI bridge device.
[ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] [ 2620.877203] pci 0000:06:00.0: supports D1 D2 [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
[ 2620.877492] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
[ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem 0xf4300000-0xf43fffff] [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
[ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
[ 2620.877630] pci 0000:05:00.0: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
[ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem 0xf4300000-0xf7efffff] [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000
-> 0002)
[ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized
What if you once unload snd-hda-intel module and reload again while keeping the card plugged? I guess it still doesn't work, but just to be sure...
Overall, this look more like a problem of PCI core stuff. Better to toss the issue to PCI people.
Takashi
I did alsa force-reload and the same error comes up. Do you know of a good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
-Alnie
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote:
At Tue, 24 Feb 2015 23:55:25 -0800, Alnie wrote:
[ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on slot(3): already powering off [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on slot(3): already powering on
pciehp reacted power off and on here, and...
[ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 [ 2620.876426] pci 0000:05:00.0: supports D1 D2 [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-0c] (conflicts with (null) [bus 05-0c])
.... and something failed here for the PCI bridge device.
[ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] [ 2620.877203] pci 0000:06:00.0: supports D1 D2 [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
[ 2620.877492] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
[ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem 0xf4300000-0xf43fffff] [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
[ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
[ 2620.877630] pci 0000:05:00.0: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
[ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem 0xf4300000-0xf7efffff] [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000
-> 0002)
[ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized
What if you once unload snd-hda-intel module and reload again while keeping the card plugged? I guess it still doesn't work, but just to be sure...
Overall, this look more like a problem of PCI core stuff. Better to toss the issue to PCI people.
Takashi
I did alsa force-reload and the same error comes up. Do you know of a good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote:
At Tue, 24 Feb 2015 23:55:25 -0800, Alnie wrote:
[ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on slot(3): already powering off [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on slot(3): already powering on
pciehp reacted power off and on here, and...
[ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 [ 2620.876426] pci 0000:05:00.0: supports D1 D2 [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-0c] (conflicts with (null) [bus 05-0c])
.... and something failed here for the PCI bridge device.
[ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] [ 2620.877203] pci 0000:06:00.0: supports D1 D2 [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
[ 2620.877492] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
[ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem 0xf4300000-0xf43fffff] [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
[ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
[ 2620.877630] pci 0000:05:00.0: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
[ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem 0xf4300000-0xf7efffff] [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000
-> 0002)
[ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized
What if you once unload snd-hda-intel module and reload again while keeping the card plugged? I guess it still doesn't work, but just to be sure...
Overall, this look more like a problem of PCI core stuff. Better to toss the issue to PCI people.
Takashi
I did alsa force-reload and the same error comes up. Do you know of a good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
-Alnie
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote:
At Tue, 24 Feb 2015 23:55:25 -0800, Alnie wrote:
[ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on slot(3): already powering off [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on slot(3): already powering on
pciehp reacted power off and on here, and...
[ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 [ 2620.876426] pci 0000:05:00.0: supports D1 D2 [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus 00-00]), reconfiguring [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] under [bus 05-0c] (conflicts with (null) [bus 05-0c])
.... and something failed here for the PCI bridge device.
[ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] [ 2620.877203] pci 0000:06:00.0: supports D1 D2 [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
[ 2620.877492] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff 64bit pref] [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
[ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem 0xf4300000-0xf43fffff] [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
[ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
[ 2620.877630] pci 0000:05:00.0: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
[ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem 0xf4300000-0xf7efffff] [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem 0xf4000000-0xf40fffff 64bit pref] [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000
-> 0002)
[ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized
What if you once unload snd-hda-intel module and reload again while keeping the card plugged? I guess it still doesn't work, but just to be sure...
Overall, this look more like a problem of PCI core stuff. Better to toss the issue to PCI people.
Takashi
I did alsa force-reload and the same error comes up. Do you know of a good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
On 03/02/2015 11:48 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote:
At Tue, 24 Feb 2015 23:55:25 -0800, Alnie wrote: > > [ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) > [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event > [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on > slot(3): already powering off > [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released > [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) > [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event > [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on > slot(3): already powering on
pciehp reacted power off and on here, and...
> [ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 > [ 2620.876426] pci 0000:05:00.0: supports D1 D2 > [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus > 00-00]), reconfiguring > [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] > under [bus 05-0c] (conflicts with (null) [bus 05-0c])
.... and something failed here for the PCI bridge device.
> [ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 > [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] > [ 2620.877203] pci 0000:06:00.0: supports D1 D2 > [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] > [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] > [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
> [ 2620.877492] pci 0000:05:00.0: bridge window [mem > 0x00000000-0x000fffff 64bit pref] > [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
> [ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem > 0xf4300000-0xf43fffff] > [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem > 0xf4000000-0xf40fffff 64bit pref] > [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] > [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
> [ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] > [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] > [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
> [ 2620.877630] pci 0000:05:00.0: bridge window [mem > 0xf4000000-0xf40fffff 64bit pref] > [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] > [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
> [ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem > 0xf4300000-0xf7efffff] > [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem > 0xf4000000-0xf40fffff 64bit pref] > [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) > [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000
-> 0002)
> [ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed > [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; > disabling it... > [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found > [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized
What if you once unload snd-hda-intel module and reload again while keeping the card plugged? I guess it still doesn't work, but just to be sure...
Overall, this look more like a problem of PCI core stuff. Better to toss the issue to PCI people.
Takashi
I did alsa force-reload and the same error comes up. Do you know of a good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
is alsa force-reload sufficient?
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
Bjorn asked this question I'm not sure if you ever saw it...
On Thu, Feb 26, 2015 at 09:20:59AM +0100, Takashi Iwai wrote:
FYI, during the previous debug sessions, we found that the sound driver gets only 0xff for mapped register accesses, so I suggested to report to PCI devs. IIRC, the non-hotplug board with this chip worked in the past.
I skimmed the previous emails but I missed this part. Did you add instrumentation to the driver, or is it just obvious from the way the driver behaves that we're getting 0xff?
Bjorn
Also, in regards to debug prints and azx read write values. How do I do this? I have searched around I can't find anything.
-Alnie
On 03/03/2015 01:21 AM, Alnie wrote:
On 03/02/2015 11:48 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote:
On 02/25/2015 12:06 AM, Takashi Iwai wrote: > At Tue, 24 Feb 2015 23:55:25 -0800, > Alnie wrote: >> >> [ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present
on Slot(3)
>> [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link
Down event
>> [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event
ignored on
>> slot(3): already powering off >> [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is
released
>> [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on
Slot(3)
>> [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up
event
>> [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event
ignored on
>> slot(3): already powering on > > pciehp reacted power off and on here, and... > >> [ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class
0x060400
>> [ 2620.876426] pci 0000:05:00.0: supports D1 D2 >> [ 2620.876719] pci 0000:05:00.0: bridge configuration
invalid ([bus
>> 00-00]), reconfiguring >> [ 2620.876928] pci_bus 0000:06: busn_res: can not insert
[bus 06-ff]
>> under [bus 05-0c] (conflicts with (null) [bus 05-0c]) > > .... and something failed here for the PCI bridge device. > >> [ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class
0x040300
>> [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem
0x00000000-0x00003fff]
>> [ 2620.877203] pci 0000:06:00.0: supports D1 D2 >> [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] >> [ 2620.877462] pci 0000:05:00.0: bridge window [io
0x0000-0x0fff]
>> [ 2620.877474] pci 0000:05:00.0: bridge window [mem
0x00000000-0x000fffff]
>> [ 2620.877492] pci 0000:05:00.0: bridge window [mem >> 0x00000000-0x000fffff 64bit pref] >> [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is
updated to 06
>> [ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem >> 0xf4300000-0xf43fffff] >> [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem >> 0xf4000000-0xf40fffff 64bit pref] >> [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io
0x2000-0x2fff]
>> [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem
0xf4300000-0xf4303fff]
>> [ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] >> [ 2620.877603] pci 0000:05:00.0: bridge window [io
0x2000-0x2fff]
>> [ 2620.877618] pci 0000:05:00.0: bridge window [mem
0xf4300000-0xf43fffff]
>> [ 2620.877630] pci 0000:05:00.0: bridge window [mem >> 0xf4000000-0xf40fffff 64bit pref] >> [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus
05-0c]
>> [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io
0x2000-0x2fff]
>> [ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem >> 0xf4300000-0xf7efffff] >> [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem >> 0xf4000000-0xf40fffff 64bit pref] >> [ 2620.877990] pci 0000:05:00.0: enabling device (0000 ->
>> [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device
(0000 -> 0002)
>> [ 2620.882747] azx_single_wait_for_response: 108 callbacks
suppressed
>> [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe
error;
>> disabling it... >> [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG
node found
>> [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs
initialized
> > What if you once unload snd-hda-intel module and reload
again while
> keeping the card plugged? I guess it still doesn't work,
but just to
> be sure... > > Overall, this look more like a problem of PCI core stuff.
Better to
> toss the issue to PCI people. > > > Takashi >
I did alsa force-reload and the same error comes up. Do you
know of a
good starting point for presenting PCI issues?
Ask on linux-pci at vger.kernel.org ?
Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
is alsa force-reload sufficient?
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
Bjorn asked this question I'm not sure if you ever saw it...
On Thu, Feb 26, 2015 at 09:20:59AM +0100, Takashi Iwai wrote:
FYI, during the previous debug sessions, we found that the sound driver gets only 0xff for mapped register accesses, so I suggested to report to PCI devs. IIRC, the non-hotplug board with this chip worked in the past.
I skimmed the previous emails but I missed this part. Did you add instrumentation to the driver, or is it just obvious from the way the driver behaves that we're getting 0xff?
Bjorn
Also, in regards to debug prints and azx read write values. How do I do this? I have searched around I can't find anything.
Please bear with me. Much of this is very new to me. I compiled a new kernel with the following debug settings enabled. Am I moving in the right direction?
CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_PCI_DEBUG=y
Here is the dmesg (i also do a force-reload)... http://pastebin.com/giRsPCUe More output, but not sure if it has the information you are looking for. and this... http://www.alsa-project.org/db/?f=c69bc32b2795cc9cee2aa3cf205c8dab7583638d
-Alnie
On 03/03/2015 01:51 PM, Alnie wrote:
On 03/03/2015 01:21 AM, Alnie wrote:
On 03/02/2015 11:48 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote: > > > > On 02/25/2015 12:06 AM, Takashi Iwai wrote: > > At Tue, 24 Feb 2015 23:55:25 -0800, > > Alnie wrote: > >> > >> [ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) > >> [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event > >> [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on > >> slot(3): already powering off > >> [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released > >> [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) > >> [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event > >> [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on > >> slot(3): already powering on > > > > pciehp reacted power off and on here, and... > > > >> [ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 > >> [ 2620.876426] pci 0000:05:00.0: supports D1 D2 > >> [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus > >> 00-00]), reconfiguring > >> [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] > >> under [bus 05-0c] (conflicts with (null) [bus 05-0c]) > > > > .... and something failed here for the PCI bridge device. > > > >> [ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 > >> [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] > >> [ 2620.877203] pci 0000:06:00.0: supports D1 D2 > >> [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] > >> [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] > >> [ 2620.877474] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff] > >> [ 2620.877492] pci 0000:05:00.0: bridge window [mem > >> 0x00000000-0x000fffff 64bit pref] > >> [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06 > >> [ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem > >> 0xf4300000-0xf43fffff] > >> [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] > >> [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem 0xf4300000-0xf4303fff] > >> [ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] > >> [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] > >> [ 2620.877618] pci 0000:05:00.0: bridge window [mem 0xf4300000-0xf43fffff] > >> [ 2620.877630] pci 0000:05:00.0: bridge window [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] > >> [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io 0x2000-0x2fff] > >> [ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem > >> 0xf4300000-0xf7efffff] > >> [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) > >> [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) > >> [ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed > >> [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; > >> disabling it... > >> [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found > >> [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized > > > > What if you once unload snd-hda-intel module and reload again while > > keeping the card plugged? I guess it still doesn't work, but just to > > be sure... > > > > Overall, this look more like a problem of PCI core stuff. Better to > > toss the issue to PCI people. > > > > > > Takashi > > > > I did alsa force-reload and the same error comes up. Do you know of a > good starting point for presenting PCI issues? > >Ask on linux-pci at vger.kernel.org ? > > >Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
is alsa force-reload sufficient?
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
Bjorn asked this question I'm not sure if you ever saw it...
On Thu, Feb 26, 2015 at 09:20:59AM +0100, Takashi Iwai wrote:
FYI, during the previous debug sessions, we found that the sound driver gets only 0xff for mapped register accesses, so I suggested to report to PCI devs. IIRC, the non-hotplug board with this chip
worked
in the past.
I skimmed the previous emails but I missed this part. Did you add instrumentation to the driver, or is it just obvious from the way the driver behaves that we're getting 0xff?
Bjorn
Also, in regards to debug prints and azx read write values. How do I do this? I have searched around I can't find anything.
Please bear with me. Much of this is very new to me. I compiled a new kernel with the following debug settings enabled. Am I moving in the right direction?
CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_PCI_DEBUG=y
Here is the dmesg (i also do a force-reload)... http://pastebin.com/giRsPCUe More output, but not sure if it has the information you are looking for. and this... http://www.alsa-project.org/db/?f=c69bc32b2795cc9cee2aa3cf205c8dab7583638d
Also, just re-inserted the card and did a force-reload and same issue comes up.
At Tue, 03 Mar 2015 13:51:24 -0800, Alnie wrote:
On 03/03/2015 01:21 AM, Alnie wrote:
On 03/02/2015 11:48 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote:
At Wed, 25 Feb 2015 00:21:15 -0800, Alnie wrote: > > > > On 02/25/2015 12:06 AM, Takashi Iwai wrote: > > At Tue, 24 Feb 2015 23:55:25 -0800, > > Alnie wrote: > >> > >> [ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present on Slot(3) > >> [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link Down event > >> [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event ignored on > >> slot(3): already powering off > >> [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is released > >> [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on Slot(3) > >> [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up event > >> [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event ignored on > >> slot(3): already powering on > > > > pciehp reacted power off and on here, and... > > > >> [ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class 0x060400 > >> [ 2620.876426] pci 0000:05:00.0: supports D1 D2 > >> [ 2620.876719] pci 0000:05:00.0: bridge configuration invalid ([bus > >> 00-00]), reconfiguring > >> [ 2620.876928] pci_bus 0000:06: busn_res: can not insert [bus 06-ff] > >> under [bus 05-0c] (conflicts with (null) [bus 05-0c]) > > > > .... and something failed here for the PCI bridge device. > > > >> [ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class 0x040300 > >> [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem 0x00000000-0x00003fff] > >> [ 2620.877203] pci 0000:06:00.0: supports D1 D2 > >> [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] > >> [ 2620.877462] pci 0000:05:00.0: bridge window [io 0x0000-0x0fff] > >> [ 2620.877474] pci 0000:05:00.0: bridge window [mem 0x00000000-0x000fffff] > >> [ 2620.877492] pci 0000:05:00.0: bridge window [mem > >> 0x00000000-0x000fffff 64bit pref] > >> [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is updated to 06 > >> [ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem > >> 0xf4300000-0xf43fffff] > >> [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io 0x2000-0x2fff] > >> [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem 0xf4300000-0xf4303fff] > >> [ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] > >> [ 2620.877603] pci 0000:05:00.0: bridge window [io 0x2000-0x2fff] > >> [ 2620.877618] pci 0000:05:00.0: bridge window [mem 0xf4300000-0xf43fffff] > >> [ 2620.877630] pci 0000:05:00.0: bridge window [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus 05-0c] > >> [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io 0x2000-0x2fff] > >> [ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem > >> 0xf4300000-0xf7efffff] > >> [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem > >> 0xf4000000-0xf40fffff 64bit pref] > >> [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> 0003) > >> [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) > >> [ 2620.882747] azx_single_wait_for_response: 108 callbacks suppressed > >> [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe error; > >> disabling it... > >> [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found > >> [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs initialized > > > > What if you once unload snd-hda-intel module and reload again while > > keeping the card plugged? I guess it still doesn't work, but just to > > be sure... > > > > Overall, this look more like a problem of PCI core stuff. Better to > > toss the issue to PCI people. > > > > > > Takashi > > > > I did alsa force-reload and the same error comes up. Do you know of a > good starting point for presenting PCI issues? > >Ask on linux-pci at vger.kernel.org ? > > >Takashi
Bjorn has suggested it is not a PCI issue... http://article.gmane.org/gmane.linux.kernel.pci/39492 Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
is alsa force-reload sufficient?
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
Bjorn asked this question I'm not sure if you ever saw it...
On Thu, Feb 26, 2015 at 09:20:59AM +0100, Takashi Iwai wrote:
FYI, during the previous debug sessions, we found that the sound driver gets only 0xff for mapped register accesses, so I suggested to report to PCI devs. IIRC, the non-hotplug board with this chip worked in the past.
I skimmed the previous emails but I missed this part. Did you add instrumentation to the driver, or is it just obvious from the way the driver behaves that we're getting 0xff?
Bjorn
Also, in regards to debug prints and azx read write values. How do I do this? I have searched around I can't find anything.
Please bear with me. Much of this is very new to me. I compiled a new kernel with the following debug settings enabled. Am I moving in the right direction?
CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_PCI_DEBUG=y
Here is the dmesg (i also do a force-reload)... http://pastebin.com/giRsPCUe More output, but not sure if it has the information you are looking for. and this... http://www.alsa-project.org/db/?f=c69bc32b2795cc9cee2aa3cf205c8dab7583638d
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
On 03/03/2015 02:07 PM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 13:51:24 -0800, Alnie wrote:
On 03/03/2015 01:21 AM, Alnie wrote:
On 03/02/2015 11:48 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 23:22:52 -0800, Alnie wrote:
On 03/02/2015 10:10 PM, Takashi Iwai wrote:
At Mon, 02 Mar 2015 19:37:12 -0800, Alnie wrote: > > At Wed, 25 Feb 2015 00:21:15 -0800, > Alnie wrote: > > > > > > > > On 02/25/2015 12:06 AM, Takashi Iwai wrote: > > > At Tue, 24 Feb 2015 23:55:25 -0800, > > > Alnie wrote: > > >> > > >> [ 2619.199658] pciehp 0000:00:1c.3:pcie04: Card not present > on Slot(3) > > >> [ 2619.199666] pciehp 0000:00:1c.3:pcie04: slot(3): Link > Down event > > >> [ 2619.199674] pciehp 0000:00:1c.3:pcie04: Link Down event > ignored on > > >> slot(3): already powering off > > >> [ 2619.199911] pci_bus 0000:06: busn_res: [bus 06-0c] is > released > > >> [ 2620.757928] pciehp 0000:00:1c.3:pcie04: Card present on > Slot(3) > > >> [ 2620.767950] pciehp 0000:00:1c.3:pcie04: slot(3): Link Up > event > > >> [ 2620.767985] pciehp 0000:00:1c.3:pcie04: Link Up event > ignored on > > >> slot(3): already powering on > > > > > > pciehp reacted power off and on here, and... > > > > > >> [ 2620.876160] pci 0000:05:00.0: [1102:7006] type 01 class > 0x060400 > > >> [ 2620.876426] pci 0000:05:00.0: supports D1 D2 > > >> [ 2620.876719] pci 0000:05:00.0: bridge configuration > invalid ([bus > > >> 00-00]), reconfiguring > > >> [ 2620.876928] pci_bus 0000:06: busn_res: can not insert > [bus 06-ff] > > >> under [bus 05-0c] (conflicts with (null) [bus 05-0c]) > > > > > > .... and something failed here for the PCI bridge device. > > > > > >> [ 2620.876967] pci 0000:06:00.0: [1102:0009] type 00 class > 0x040300 > > >> [ 2620.877013] pci 0000:06:00.0: reg 0x10: [mem > 0x00000000-0x00003fff] > > >> [ 2620.877203] pci 0000:06:00.0: supports D1 D2 > > >> [ 2620.877443] pci 0000:05:00.0: PCI bridge to [bus 06-ff] > > >> [ 2620.877462] pci 0000:05:00.0: bridge window [io > 0x0000-0x0fff] > > >> [ 2620.877474] pci 0000:05:00.0: bridge window [mem > 0x00000000-0x000fffff] > > >> [ 2620.877492] pci 0000:05:00.0: bridge window [mem > > >> 0x00000000-0x000fffff 64bit pref] > > >> [ 2620.877500] pci_bus 0000:06: busn_res: [bus 06-ff] end is > updated to 06 > > >> [ 2620.877559] pci 0000:05:00.0: BAR 14: assigned [mem > > >> 0xf4300000-0xf43fffff] > > >> [ 2620.877568] pci 0000:05:00.0: BAR 15: assigned [mem > > >> 0xf4000000-0xf40fffff 64bit pref] > > >> [ 2620.877574] pci 0000:05:00.0: BAR 13: assigned [io > 0x2000-0x2fff] > > >> [ 2620.877582] pci 0000:06:00.0: BAR 0: assigned [mem > 0xf4300000-0xf4303fff] > > >> [ 2620.877595] pci 0000:05:00.0: PCI bridge to [bus 06] > > >> [ 2620.877603] pci 0000:05:00.0: bridge window [io > 0x2000-0x2fff] > > >> [ 2620.877618] pci 0000:05:00.0: bridge window [mem > 0xf4300000-0xf43fffff] > > >> [ 2620.877630] pci 0000:05:00.0: bridge window [mem > > >> 0xf4000000-0xf40fffff 64bit pref] > > >> [ 2620.877647] pcieport 0000:00:1c.3: PCI bridge to [bus > 05-0c] > > >> [ 2620.877655] pcieport 0000:00:1c.3: bridge window [io > 0x2000-0x2fff] > > >> [ 2620.877667] pcieport 0000:00:1c.3: bridge window [mem > > >> 0xf4300000-0xf7efffff] > > >> [ 2620.877677] pcieport 0000:00:1c.3: bridge window [mem > > >> 0xf4000000-0xf40fffff 64bit pref] > > >> [ 2620.877990] pci 0000:05:00.0: enabling device (0000 -> > 0003) > > >> [ 2620.878013] snd_hda_intel 0000:06:00.0: enabling device > (0000 > -> 0002) > > >> [ 2620.882747] azx_single_wait_for_response: 108 callbacks > suppressed > > >> [ 2620.882753] snd_hda_intel 0000:06:00.0: Codec #1 probe > error; > > >> disabling it... > > >> [ 2620.887052] snd_hda_intel 0000:06:00.0: no AFG or MFG > node found > > >> [ 2620.887058] snd_hda_intel 0000:06:00.0: no codecs > initialized > > > > > > What if you once unload snd-hda-intel module and reload > again while > > > keeping the card plugged? I guess it still doesn't work, > but just to > > > be sure... > > > > > > Overall, this look more like a problem of PCI core stuff. > Better to > > > toss the issue to PCI people. > > > > > > > > > Takashi > > > > > > > I did alsa force-reload and the same error comes up. Do you > know of a > > good starting point for presenting PCI issues? > > > >Ask on linux-pci at vger.kernel.org ? > > > > > >Takashi > > > Bjorn has suggested it is not a PCI issue... > http://article.gmane.org/gmane.linux.kernel.pci/39492 > Any other ideas in regards to this?
After re-inserting the card, try to reload the driver module again.
Takashi
Okay, booted with card not inserted and with hda-intel driver blacklisted. Inserted card & loaded driver and same complaint came up... here is dmesg output http://pastebin.com/myBT23G1
I meant reloading the module again without reinserting the device. Though, I don't expect this would work, but just to be sure.
is alsa force-reload sufficient?
Other than that, I have no much clue. You might put some delay in each probe procedure and debug prints. Check the values of azx_read*() and azx_write*(). Especially if azx_read*() reads 0xff, it means that the mapped PCI registers are wrong, which usually indicates still some PCI errors (e.g. the device isn't powered up properly).
Takashi
Bjorn asked this question I'm not sure if you ever saw it...
On Thu, Feb 26, 2015 at 09:20:59AM +0100, Takashi Iwai wrote:
FYI, during the previous debug sessions, we found that the sound driver gets only 0xff for mapped register accesses, so I suggested to report to PCI devs. IIRC, the non-hotplug board with this chip worked in the past.
I skimmed the previous emails but I missed this part. Did you add instrumentation to the driver, or is it just obvious from the way the driver behaves that we're getting 0xff?
Bjorn
Also, in regards to debug prints and azx read write values. How do I do this? I have searched around I can't find anything.
Please bear with me. Much of this is very new to me. I compiled a new kernel with the following debug settings enabled. Am I moving in the right direction?
CONFIG_SND_VERBOSE_PRINTK=y CONFIG_SND_DEBUG=y CONFIG_SND_DEBUG_VERBOSE=y
CONFIG_PCI_DEBUG=y
Here is the dmesg (i also do a force-reload)... http://pastebin.com/giRsPCUe More output, but not sure if it has the information you are looking for. and this... http://www.alsa-project.org/db/?f=c69bc32b2795cc9cee2aa3cf205c8dab7583638d
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
Take this for example...
/* receive a response */ static int azx_single_wait_for_response(struct azx *chip, unsigned int addr) { int timeout = 50;
while (timeout--) { /* check IRV busy bit */ if (azx_readw(chip, IRS) & ICH6_IRS_VALID) { /* reuse rirb.res as the response return value */ chip->rirb.res[addr] = azx_readl(chip, IR); return 0; } udelay(1); } if (printk_ratelimit()) snd_printd(SFX "%s: get_response timeout: IRS=0x%x\n", pci_name(chip->pci), azx_readw(chip, IRS)); chip->rirb.res[addr] = -1; return -EIO; }
can you please show me how to insert the printk command without breaking things?
-Alnie
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
-Alnie
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
These are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); pr_info_ratelimited("XXX writel %p %x\n", addr, val); return val; }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); pr_info_ratelimited("XXX writew %p %x\n", addr, val); return val; }
static u16 pci_azx_readw(u16 __iomem *addr) { return readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); pr_info_ratelimited("XXX writeb %p %x\n", addr, val); return val; }
static u8 pci_azx_readb(u8 __iomem *addr) { return readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
But I am getting errors for each pci_azx value...
In file included from include/linux/kernel.h:13:0, from include/linux/delay.h:10, from sound/pci/hda/hda_intel.c:37: sound/pci/hda/hda_intel.c: In function ‘pci_azx_writel’: sound/pci/hda/hda_intel.c:1701:50: error: ‘val’ undeclared (first use in this function) pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ include/linux/printk.h:361:17: note: in definition of macro ‘printk_ratelimited’ printk(fmt, ##__VA_ARGS__); \ ^ sound/pci/hda/hda_intel.c:1701:2: note: in expansion of macro ‘pr_info_ratelimited’ pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ sound/pci/hda/hda_intel.c:1701:50: note: each undeclared identifier is reported only once for each function it appears in pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ include/linux/printk.h:361:17: note: in definition of macro ‘printk_ratelimited’ printk(fmt, ##__VA_ARGS__); \ ^ sound/pci/hda/hda_intel.c:1701:2: note: in expansion of macro ‘pr_info_ratelimited’ pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ sound/pci/hda/hda_intel.c:1702:2: warning: ‘return’ with a value, in function returning void [enabled by default] return val; ^
-Alnie
On 03/06/2015 02:38 PM, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
These are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); pr_info_ratelimited("XXX writel %p %x\n", addr, val); return val; }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); pr_info_ratelimited("XXX writew %p %x\n", addr, val); return val; }
static u16 pci_azx_readw(u16 __iomem *addr) { return readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); pr_info_ratelimited("XXX writeb %p %x\n", addr, val); return val; }
static u8 pci_azx_readb(u8 __iomem *addr) { return readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
But I am getting errors for each pci_azx value...
In file included from include/linux/kernel.h:13:0, from include/linux/delay.h:10, from sound/pci/hda/hda_intel.c:37: sound/pci/hda/hda_intel.c: In function ‘pci_azx_writel’: sound/pci/hda/hda_intel.c:1701:50: error: ‘val’ undeclared (first use in this function) pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ include/linux/printk.h:361:17: note: in definition of macro ‘printk_ratelimited’ printk(fmt, ##__VA_ARGS__); \ ^ sound/pci/hda/hda_intel.c:1701:2: note: in expansion of macro ‘pr_info_ratelimited’ pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ sound/pci/hda/hda_intel.c:1701:50: note: each undeclared identifier is reported only once for each function it appears in pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ include/linux/printk.h:361:17: note: in definition of macro ‘printk_ratelimited’ printk(fmt, ##__VA_ARGS__); \ ^ sound/pci/hda/hda_intel.c:1701:2: note: in expansion of macro ‘pr_info_ratelimited’ pr_info_ratelimited("XXX writel %p %x\n", addr, val); ^ sound/pci/hda/hda_intel.c:1702:2: warning: ‘return’ with a value, in function returning void [enabled by default] return val; ^
Ack! Premature post. Already seeing where I made mistakes. Sorry, very unfamiliar with C :(
-Alnie
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401 [ 4.662466] XXX readl ffffc90004f30008 1 [ 4.662468] XXX readb ffffc90004f30008 1 [ 4.662609] XXX readw ffffc90004f70000 3300 [ 4.662631] XXX readl ffffc90004f70008 0 [ 4.662635] XXX readb ffffc90004f70008 0 [ 4.663483] XXX readb ffffc90004f30008 0 [ 4.663492] XXX readb ffffc90004f70008 0 [ 4.663496] XXX readb ffffc90004f70008 0 [ 4.664138] XXX readb ffffc90004f30008 0 [ 4.664142] XXX readb ffffc90004f30008 0 [ 4.664150] XXX readb ffffc90004f70008 1 [ 4.665173] XXX readb ffffc90004f30008 1 [ 4.665368] XXX readb ffffc90004f70008 1 [ 4.665372] XXX readw ffffc90004f7000e 2 [ 4.665378] XXX readl ffffc90004f70020 0 [ 4.666389] XXX readw ffffc90004f3000e 1 [ 4.666394] XXX readl ffffc90004f30020 0 [ 4.668203] XXX readw ffffc90004f70068 0 [ 4.668209] XXX readw ffffc90004f70068 0 [ 4.668213] XXX readw ffffc90004f70068 0 [ 4.668216] XXX readw ffffc90004f70068 0 [ 4.668221] XXX readw ffffc90004f70068 0 [ 4.668226] XXX readw ffffc90004f70068 0 [ 4.668412] XXX readl ffffc90004f70020 c0000000 [ 4.668420] XXX readl ffffc90004f70008 1 [ 4.671683] XXX readl ffffc90004f70020 0 [ 4.674569] XXX readl ffffc90004f30064 14f15051 [ 4.674608] XXX readl ffffc90004f30064 14f15051 [ 4.674651] XXX readl ffffc90004f30064 0 [ 5.624194] IPv6: ADDRCONF(NETDEV_UP): eth0: link is not ready [ 7.297049] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready [ 15.003841] pci_azx_readl: 160 callbacks suppressed [ 15.003845] XXX readl ffffc90004f30024 0 [ 15.003911] XXX readl ffffc90004f30024 0 [ 16.334821] pci_azx_readb: 12 callbacks suppressed [ 16.334826] XXX readb ffffc90004f30080 0 [ 16.334829] XXX readb ffffc90004f30080 0 [ 16.334834] XXX readb ffffc90004f30080 1 [ 16.334839] XXX readb ffffc90004f30080 0 [ 16.334844] XXX readb ffffc90004f30080 0 [ 16.334846] XXX readl ffffc90004f30080 40000 [ 16.334849] XXX readl ffffc90004f30070 31303000 [ 16.334852] XXX readl ffffc90004f30080 140000 [ 16.334857] pci_azx_readw: 3599 callbacks suppressed [ 16.334858] XXX readw ffffc90004f30068 2 [ 16.334860] XXX readw ffffc90004f30068 2 [ 16.334862] XXX readw ffffc90004f30068 0 [ 16.334864] XXX readw ffffc90004f30068 1 [ 16.334868] XXX readw ffffc90004f30068 1 [ 16.334871] XXX readw ffffc90004f30068 1 [ 16.334874] XXX readw ffffc90004f30068 1 [ 16.334877] XXX readw ffffc90004f30068 1 [ 16.334880] XXX readw ffffc90004f30068 1 [ 16.334884] XXX readw ffffc90004f30068 1 [ 16.334902] XXX readl ffffc90004f30064 0 [ 16.334943] XXX readl ffffc90004f30064 0 [ 16.334985] XXX readl ffffc90004f30064 11 [ 16.340093] XXX readl ffffc90004f30064 0 [ 16.340115] XXX readb ffffc90004f30080 1c [ 16.340118] XXX readb ffffc90004f30080 0 [ 16.340123] XXX readb ffffc90004f30080 1 [ 16.340128] XXX readb ffffc90004f30080 0 [ 16.340132] XXX readb ffffc90004f30080 0 [ 16.340134] XXX readl ffffc90004f30080 40000 [ 20.018443] pci_azx_readl: 148 callbacks suppressed [ 20.018448] XXX readl ffffc90004f30030 15f6582b [ 20.018709] XXX readl ffffc90004f30030 15f6715a [ 20.018716] XXX readl ffffc90004f30030 15f67203 [ 20.370026] XXX readl ffffc90004f30030 16770835 [ 20.370737] XXX readl ffffc90004f30030 16774b57 [ 20.370752] XXX readl ffffc90004f30030 16774cd3 [ 20.721866] XXX readl ffffc90004f30030 16f7d0db [ 20.722577] XXX readl ffffc90004f30030 16f813de [ 20.722592] XXX readl ffffc90004f30030 16f81544 [ 21.073497] XXX readl ffffc90004f30030 17788616 [ 21.447607] pci_azx_readb: 75 callbacks suppressed [ 21.447617] XXX readb ffffc90004f30100 1e [ 21.447624] XXX readb ffffc90004f30100 2 [ 21.447629] XXX readb ffffc90004f30100 2 [ 21.447633] XXX readb ffffc90004f30100 2 [ 21.447637] XXX readb ffffc90004f30100 0 [ 21.879992] XXX readb ffffc90004f30100 0 [ 21.879998] XXX readb ffffc90004f30100 0 [ 21.880032] XXX readb ffffc90004f30100 1 [ 21.880039] XXX readb ffffc90004f30100 0 [ 21.880043] XXX readb ffffc90004f30100 0 [ 21.880051] pci_azx_readw: 855 callbacks suppressed [ 21.880052] XXX readw ffffc90004f30110 bf [ 21.880075] XXX readw ffffc90004f30110 bf [ 25.032271] pci_azx_readl: 896 callbacks suppressed [ 25.032281] XXX readl ffffc90004f30030 1d218b30 [ 25.033006] XXX readl ffffc90004f30030 1d21d08e [ 25.033021] XXX readl ffffc90004f30030 1d21d1f9 [ 25.393756] XXX readl ffffc90004f30030 1da5db6d [ 25.394488] XXX readl ffffc90004f30030 1da62083 [ 25.394503] XXX readl ffffc90004f30030 1da62206 [ 25.755381] XXX readl ffffc90004f30030 1e2a394b [ 25.755746] XXX readl ffffc90004f30030 1e2a5bab [ 25.755754] XXX readl ffffc90004f30030 1e2a5c65 [ 26.116985] XXX readl ffffc90004f30030 1eae9483 [ 29.677529] pci_azx_readb: 11 callbacks suppressed [ 29.677540] XXX readb ffffc90004f30100 1e [ 29.677547] XXX readb ffffc90004f30100 2 [ 29.677551] XXX readb ffffc90004f30100 2 [ 29.677556] XXX readb ffffc90004f30100 2 [ 29.677560] XXX readb ffffc90004f30100 2 [ 29.677565] XXX readb ffffc90004f30100 0
-Alnie
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
My suggestion isn't about a compile option but that you add some debug printk() calls manually around some codes. We need to know the value written and read by azx_write*() and azx_read*() calls. Especially the value read in pci_azx_read*() is more interesting. You can try to modify sound/pci/hda/hda_intel.c and add a printk() to each pci_azx_read*() function for printing the value to be returned. Beware that this will likely flood many messages, so just try once.
Takashi
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote:
> My suggestion isn't about a compile option but that you add some debug > printk() calls manually around some codes. We need to know the value > written and read by azx_write*() and azx_read*() calls. Especially > the value read in pci_azx_read*() is more interesting. You can try to > modify sound/pci/hda/hda_intel.c and add a printk() to each > pci_azx_read*() function for printing the value to be returned. > Beware that this will likely flood many messages, so just try once. > > > Takashi >
I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0 [ 37.729774] XXX readb ffffc90005188008 0 [ 37.730803] XXX readb ffffc90005188008 0 [ 37.730812] XXX readb ffffc90005188008 0 [ 37.731839] XXX readb ffffc90005188008 1 [ 37.733060] XXX readb ffffc90005188008 1 [ 37.733065] XXX readl ffffc90005188008 1 [ 37.733069] XXX readw ffffc9000518800e 2 [ 37.733075] XXX readl ffffc90005188020 0 [ 37.733081] XXX readw ffffc9000518804a 0 [ 37.733086] XXX readw ffffc9000518804a 0 [ 37.733090] XXX readw ffffc9000518804a 0 [ 37.733095] XXX readw ffffc9000518804a 0 [ 37.733099] XXX readw ffffc9000518804a 0 [ 37.733104] XXX readw ffffc9000518804a 0 [ 37.733108] XXX readw ffffc9000518804a 0 [ 37.733113] XXX readw ffffc9000518804a 0 [ 37.736839] XXX readl ffffc90005188024 c0000000 [ 37.736844] XXX readb ffffc9000518805d 1 [ 38.740103] XXX readb ffffc90005188080 0 [ 38.740110] XXX readb ffffc900051880a0 0 [ 38.740116] XXX readb ffffc900051880c0 0 [ 38.740122] XXX readb ffffc900051880e0 0 [ 38.740134] XXX readl ffffc90005188020 c0000000 [ 38.740144] XXX readl ffffc90005188008 101 [ 38.743555] XXX readl ffffc90005188008 1 [ 38.743567] XXX readl ffffc90005188020 0 [ 38.747380] XXX readl ffffc90005188024 c0000000 [ 39.752132] XXX readl ffffc90005188024 c0000000 [ 42.768069] XXX readw ffffc90005188048 4 [ 42.768073] XXX readw ffffc9000518804a 4 [ 42.768113] XXX readl ffffc90005188024 c0000000 [ 42.768119] XXX readb ffffc9000518805d 1 [ 42.768201] XXX readw ffffc90005188058 0
-Alnie
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote:
At Tue, 03 Mar 2015 18:12:31 -0800, Alnie wrote: > >> My suggestion isn't about a compile option but that you add some debug >> printk() calls manually around some codes. We need to know the value >> written and read by azx_write*() and azx_read*() calls. Especially >> the value read in pci_azx_read*() is more interesting. You can try to >> modify sound/pci/hda/hda_intel.c and add a printk() to each >> pci_azx_read*() function for printing the value to be returned. >> Beware that this will likely flood many messages, so just try once. >> >> >> Takashi >> > > I can not find any reference to pci_azx_read in hda_intel.c
You must be using a too old kernel, then. Please use the latest kernel for debugging.
Takashi
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback) + if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
On 03/07/2015 08:32 AM, Takashi Iwai wrote:
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote:
On 03/04/2015 12:00 AM, Takashi Iwai wrote: > At Tue, 03 Mar 2015 18:12:31 -0800, > Alnie wrote: >> >>> My suggestion isn't about a compile option but that you add some debug >>> printk() calls manually around some codes. We need to know the value >>> written and read by azx_write*() and azx_read*() calls. Especially >>> the value read in pci_azx_read*() is more interesting. You can try to >>> modify sound/pci/hda/hda_intel.c and add a printk() to each >>> pci_azx_read*() function for printing the value to be returned. >>> Beware that this will likely flood many messages, so just try once. >>> >>> >>> Takashi >>> >> >> I can not find any reference to pci_azx_read in hda_intel.c > > You must be using a too old kernel, then. Please use the latest > kernel for debugging. > > > Takashi >
Ok. I now have latest kernel.
Here is a small portion...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { return readl(addr); }
Can you show me how I can properly place printk without breaking things and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback)
if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
I believe I applied the patch correctly... if you would like to double check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
Same complaint comes up, after reinsert and force-reload as well...
[ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
-Alnie
On 03/07/2015 10:06 AM, Alnie wrote:
On 03/07/2015 08:32 AM, Takashi Iwai wrote:
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote:
At Wed, 04 Mar 2015 01:01:32 -0800, Alnie wrote: > > > > On 03/04/2015 12:00 AM, Takashi Iwai wrote: >> At Tue, 03 Mar 2015 18:12:31 -0800, >> Alnie wrote: >>> >>>> My suggestion isn't about a compile option but that you add >>>> some debug >>>> printk() calls manually around some codes. We need to know >>>> the value >>>> written and read by azx_write*() and azx_read*() calls. >>>> Especially >>>> the value read in pci_azx_read*() is more interesting. You can >>>> try to >>>> modify sound/pci/hda/hda_intel.c and add a printk() to each >>>> pci_azx_read*() function for printing the value to be returned. >>>> Beware that this will likely flood many messages, so just try >>>> once. >>>> >>>> >>>> Takashi >>>> >>> >>> I can not find any reference to pci_azx_read in hda_intel.c >> >> You must be using a too old kernel, then. Please use the latest >> kernel for debugging. >> >> >> Takashi >> > > Ok. I now have latest kernel. > > Here is a small portion... > > /* PCI register access. */ > static void pci_azx_writel(u32 value, u32 __iomem *addr) > { > writel(value, addr); > } > > static u32 pci_azx_readl(u32 __iomem *addr) > { > return readl(addr); > } > > Can you show me how I can properly place printk without breaking > things > and produce relevant messages?
Something like:
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info("XXX readl %p %x\n", addr, val); return val; }
But since there are quite lots of accesses, it might be safer to use the ratelimited version. Use like the following: pr_info_ratelimited("XXX readl %p %x\n", addr, val);
Also there are variants pci_azx_readw() and _readb().
Takashi
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback)
if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
I believe I applied the patch correctly... if you would like to double check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
Same complaint comes up, after reinsert and force-reload as well...
[ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
I'm assuming we've exhausted our options for now. It seems probable this model card (ExpressCard/54) never worked in Linux to begin with. I looked over the forum posts from those claiming they had it operational (in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate your assistance with this. Thank you.
-Alnie
At Mon, 09 Mar 2015 08:22:34 -0700, Alnie wrote:
On 03/07/2015 10:06 AM, Alnie wrote:
On 03/07/2015 08:32 AM, Takashi Iwai wrote:
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote:
On 03/04/2015 01:35 AM, Takashi Iwai wrote: > At Wed, 04 Mar 2015 01:01:32 -0800, > Alnie wrote: >> >> >> >> On 03/04/2015 12:00 AM, Takashi Iwai wrote: >>> At Tue, 03 Mar 2015 18:12:31 -0800, >>> Alnie wrote: >>>> >>>>> My suggestion isn't about a compile option but that you add >>>>> some debug >>>>> printk() calls manually around some codes. We need to know >>>>> the value >>>>> written and read by azx_write*() and azx_read*() calls. >>>>> Especially >>>>> the value read in pci_azx_read*() is more interesting. You can >>>>> try to >>>>> modify sound/pci/hda/hda_intel.c and add a printk() to each >>>>> pci_azx_read*() function for printing the value to be returned. >>>>> Beware that this will likely flood many messages, so just try >>>>> once. >>>>> >>>>> >>>>> Takashi >>>>> >>>> >>>> I can not find any reference to pci_azx_read in hda_intel.c >>> >>> You must be using a too old kernel, then. Please use the latest >>> kernel for debugging. >>> >>> >>> Takashi >>> >> >> Ok. I now have latest kernel. >> >> Here is a small portion... >> >> /* PCI register access. */ >> static void pci_azx_writel(u32 value, u32 __iomem *addr) >> { >> writel(value, addr); >> } >> >> static u32 pci_azx_readl(u32 __iomem *addr) >> { >> return readl(addr); >> } >> >> Can you show me how I can properly place printk without breaking >> things >> and produce relevant messages? > > Something like: > > static u32 pci_azx_readl(u32 __iomem *addr) > { > u32 val = readl(addr); > pr_info("XXX readl %p %x\n", addr, val); > return val; > } > > But since there are quite lots of accesses, it might be safer to use > the ratelimited version. Use like the following: > pr_info_ratelimited("XXX readl %p %x\n", addr, val); > > Also there are variants pci_azx_readw() and _readb(). > > > Takashi >
Ok, I was only able to guess through the code for the read values. If you need write information too please show me how. here are the mods I made...
/* PCI register access. */ static void pci_azx_writel(u32 value, u32 __iomem *addr) { writel(value, addr); }
static u32 pci_azx_readl(u32 __iomem *addr) { u32 val = readl(addr); pr_info_ratelimited("XXX readl %p %x\n", addr, val); return val; }
static void pci_azx_writew(u16 value, u16 __iomem *addr) { writew(value, addr); }
static u16 pci_azx_readw(u16 __iomem *addr) { u16 val = readw(addr); pr_info_ratelimited("XXX readw %p %x\n", addr, val); return val; }
static void pci_azx_writeb(u8 value, u8 __iomem *addr) { writeb(value, addr); }
static u8 pci_azx_readb(u8 __iomem *addr) { u8 val = readb(addr); pr_info_ratelimited("XXX readb %p %x\n", addr, val); return val; }
and i was able to produce this...
dmesg | grep -i read [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to read a pcr value [ 0.769674] Write protecting the kernel read-only data: 12288k [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly filesystem [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback)
if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
I believe I applied the patch correctly... if you would like to double check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
Same complaint comes up, after reinsert and force-reload as well...
[ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
I'm assuming we've exhausted our options for now. It seems probable this model card (ExpressCard/54) never worked in Linux to begin with. I looked over the forum posts from those claiming they had it operational (in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate your assistance with this. Thank you.
Yes, some PCI-e version has worked, I personally tested it once. But yours is apparently a different one, and we finally go back to the starting point again.
What you need to do from now on is to analyze why the codec probe fails. It failed even with single_cmd mode. This is strange, but it might be that the board is never 100% compliant, so it might not support that mode.
There are some workarounds done specific to the Creative devices. For example, azx_init_cmd_io() in hda_controller.c has a special handling to set RIRB interrupt count to 0xc0. I guess this needs to be set normally. That is, disable the following if () check, and run always azx_writew(chip, RINTCNT, 1) instead:
if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND) azx_writew(chip, RINTCNT, 0xc0); else azx_writew(chip, RINTCNT, 1);
There is another workaround in azx_pcm_prepare() for the capture streams, but this is irrelevant as of now -- we're concentrating only on the codec probe issue.
If modifying above still doesn't work, you may try to force continuing the probe by removing -EIO return from probe_codec() in hda_controller.c. That is, remove the following line from that function:
if (res == -1) return -EIO;
Of course, it doesn't mean this would work, but we can see whether the board reacts somehow better.
Takashi
On 03/09/2015 09:00 AM, Takashi Iwai wrote:
At Mon, 09 Mar 2015 08:22:34 -0700, Alnie wrote:
On 03/07/2015 10:06 AM, Alnie wrote:
On 03/07/2015 08:32 AM, Takashi Iwai wrote:
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote:
At Fri, 06 Mar 2015 15:31:32 -0800, Alnie wrote: > > On 03/04/2015 01:35 AM, Takashi Iwai wrote: >> At Wed, 04 Mar 2015 01:01:32 -0800, >> Alnie wrote: >>> >>> >>> >>> On 03/04/2015 12:00 AM, Takashi Iwai wrote: >>>> At Tue, 03 Mar 2015 18:12:31 -0800, >>>> Alnie wrote: >>>>> >>>>>> My suggestion isn't about a compile option but that you add >>>>>> some debug >>>>>> printk() calls manually around some codes. We need to know >>>>>> the value >>>>>> written and read by azx_write*() and azx_read*() calls. >>>>>> Especially >>>>>> the value read in pci_azx_read*() is more interesting. You can >>>>>> try to >>>>>> modify sound/pci/hda/hda_intel.c and add a printk() to each >>>>>> pci_azx_read*() function for printing the value to be returned. >>>>>> Beware that this will likely flood many messages, so just try >>>>>> once. >>>>>> >>>>>> >>>>>> Takashi >>>>>> >>>>> >>>>> I can not find any reference to pci_azx_read in hda_intel.c >>>> >>>> You must be using a too old kernel, then. Please use the latest >>>> kernel for debugging. >>>> >>>> >>>> Takashi >>>> >>> >>> Ok. I now have latest kernel. >>> >>> Here is a small portion... >>> >>> /* PCI register access. */ >>> static void pci_azx_writel(u32 value, u32 __iomem *addr) >>> { >>> writel(value, addr); >>> } >>> >>> static u32 pci_azx_readl(u32 __iomem *addr) >>> { >>> return readl(addr); >>> } >>> >>> Can you show me how I can properly place printk without breaking >>> things >>> and produce relevant messages? >> >> Something like: >> >> static u32 pci_azx_readl(u32 __iomem *addr) >> { >> u32 val = readl(addr); >> pr_info("XXX readl %p %x\n", addr, val); >> return val; >> } >> >> But since there are quite lots of accesses, it might be safer to use >> the ratelimited version. Use like the following: >> pr_info_ratelimited("XXX readl %p %x\n", addr, val); >> >> Also there are variants pci_azx_readw() and _readb(). >> >> >> Takashi >> > > > Ok, I was only able to guess through the code for the read values. If > you need write information too please show me how. > here are the mods I made... > > /* PCI register access. */ > static void pci_azx_writel(u32 value, u32 __iomem *addr) > { > writel(value, addr); > } > > static u32 pci_azx_readl(u32 __iomem *addr) > { > u32 val = readl(addr); > pr_info_ratelimited("XXX readl %p %x\n", addr, val); > return val; > } > > static void pci_azx_writew(u16 value, u16 __iomem *addr) > { > writew(value, addr); > } > > static u16 pci_azx_readw(u16 __iomem *addr) > { > u16 val = readw(addr); > pr_info_ratelimited("XXX readw %p %x\n", addr, val); > return val; > } > > static void pci_azx_writeb(u8 value, u8 __iomem *addr) > { > writeb(value, addr); > } > > static u8 pci_azx_readb(u8 __iomem *addr) > { > u8 val = readb(addr); > pr_info_ratelimited("XXX readb %p %x\n", addr, val); > return val; > } > > and i was able to produce this... > > dmesg | grep -i read > [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to > read a pcr value > [ 0.769674] Write protecting the kernel read-only data: 12288k > [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: > enabled, doesn't support DPO or FUA > [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly > filesystem > [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs > [ 4.662442] XXX readw ffffc90004f30000 4401
This reads good, but I thought you have two sound devices (onboard and Creative)? If so, disable the onboard one via enable=0 option (if the onboard one is assigned first). Otherwise the all good and bad results are mixed up.
Takashi
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback)
if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
I believe I applied the patch correctly... if you would like to double check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
Same complaint comes up, after reinsert and force-reload as well...
[ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
I'm assuming we've exhausted our options for now. It seems probable this model card (ExpressCard/54) never worked in Linux to begin with. I looked over the forum posts from those claiming they had it operational (in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate your assistance with this. Thank you.
Yes, some PCI-e version has worked, I personally tested it once. But yours is apparently a different one, and we finally go back to the starting point again.
What you need to do from now on is to analyze why the codec probe fails. It failed even with single_cmd mode. This is strange, but it might be that the board is never 100% compliant, so it might not support that mode.
There are some workarounds done specific to the Creative devices. For example, azx_init_cmd_io() in hda_controller.c has a special handling to set RIRB interrupt count to 0xc0. I guess this needs to be set normally. That is, disable the following if () check, and run always azx_writew(chip, RINTCNT, 1) instead:
if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND) azx_writew(chip, RINTCNT, 0xc0); else azx_writew(chip, RINTCNT, 1);
This modification alone produced the same complaint. These are the edits I made...
/* set N=1, get RIRB response interrupt for new entry */ //if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND) //azx_writew(chip, RINTCNT, 0xc0); //else azx_writew(chip, RINTCNT, 1);
There is another workaround in azx_pcm_prepare() for the capture streams, but this is irrelevant as of now -- we're concentrating only on the codec probe issue.
If modifying above still doesn't work, you may try to force continuing the probe by removing -EIO return from probe_codec() in hda_controller.c. That is, remove the following line from that function:
if (res == -1) return -EIO;
This is the edit I made...
mutex_unlock(&chip->bus->cmd_mutex); //if (res == -1) //return -EIO; dev_dbg(chip->card->dev, "codec #%d probed OK\n", addr);
I assume I did this correctly, but here is the full hda_controller.c I compiled if you would like to double check http://pastebin.com/fvVVA1Ew
Of course, it doesn't mean this would work, but we can see whether the board reacts somehow better.
Same complaint comes up.
[ 7.600051] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 9.608050] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 9.609976] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 9.611023] snd_hda_intel 0000:06:00.0: no codecs initialized [ 10.776445] init: alsa-restore main process (1461) terminated with status 19
At Wed, 11 Mar 2015 20:59:58 -0700, Alnie wrote:
On 03/09/2015 09:00 AM, Takashi Iwai wrote:
At Mon, 09 Mar 2015 08:22:34 -0700, Alnie wrote:
On 03/07/2015 10:06 AM, Alnie wrote:
On 03/07/2015 08:32 AM, Takashi Iwai wrote:
At Sat, 07 Mar 2015 08:28:29 -0800, Alnie wrote:
On 03/06/2015 11:56 PM, Takashi Iwai wrote: > At Fri, 06 Mar 2015 15:31:32 -0800, > Alnie wrote: >> >> On 03/04/2015 01:35 AM, Takashi Iwai wrote: >>> At Wed, 04 Mar 2015 01:01:32 -0800, >>> Alnie wrote: >>>> >>>> >>>> >>>> On 03/04/2015 12:00 AM, Takashi Iwai wrote: >>>>> At Tue, 03 Mar 2015 18:12:31 -0800, >>>>> Alnie wrote: >>>>>> >>>>>>> My suggestion isn't about a compile option but that you add >>>>>>> some debug >>>>>>> printk() calls manually around some codes. We need to know >>>>>>> the value >>>>>>> written and read by azx_write*() and azx_read*() calls. >>>>>>> Especially >>>>>>> the value read in pci_azx_read*() is more interesting. You can >>>>>>> try to >>>>>>> modify sound/pci/hda/hda_intel.c and add a printk() to each >>>>>>> pci_azx_read*() function for printing the value to be returned. >>>>>>> Beware that this will likely flood many messages, so just try >>>>>>> once. >>>>>>> >>>>>>> >>>>>>> Takashi >>>>>>> >>>>>> >>>>>> I can not find any reference to pci_azx_read in hda_intel.c >>>>> >>>>> You must be using a too old kernel, then. Please use the latest >>>>> kernel for debugging. >>>>> >>>>> >>>>> Takashi >>>>> >>>> >>>> Ok. I now have latest kernel. >>>> >>>> Here is a small portion... >>>> >>>> /* PCI register access. */ >>>> static void pci_azx_writel(u32 value, u32 __iomem *addr) >>>> { >>>> writel(value, addr); >>>> } >>>> >>>> static u32 pci_azx_readl(u32 __iomem *addr) >>>> { >>>> return readl(addr); >>>> } >>>> >>>> Can you show me how I can properly place printk without breaking >>>> things >>>> and produce relevant messages? >>> >>> Something like: >>> >>> static u32 pci_azx_readl(u32 __iomem *addr) >>> { >>> u32 val = readl(addr); >>> pr_info("XXX readl %p %x\n", addr, val); >>> return val; >>> } >>> >>> But since there are quite lots of accesses, it might be safer to use >>> the ratelimited version. Use like the following: >>> pr_info_ratelimited("XXX readl %p %x\n", addr, val); >>> >>> Also there are variants pci_azx_readw() and _readb(). >>> >>> >>> Takashi >>> >> >> >> Ok, I was only able to guess through the code for the read values. If >> you need write information too please show me how. >> here are the mods I made... >> >> /* PCI register access. */ >> static void pci_azx_writel(u32 value, u32 __iomem *addr) >> { >> writel(value, addr); >> } >> >> static u32 pci_azx_readl(u32 __iomem *addr) >> { >> u32 val = readl(addr); >> pr_info_ratelimited("XXX readl %p %x\n", addr, val); >> return val; >> } >> >> static void pci_azx_writew(u16 value, u16 __iomem *addr) >> { >> writew(value, addr); >> } >> >> static u16 pci_azx_readw(u16 __iomem *addr) >> { >> u16 val = readw(addr); >> pr_info_ratelimited("XXX readw %p %x\n", addr, val); >> return val; >> } >> >> static void pci_azx_writeb(u8 value, u8 __iomem *addr) >> { >> writeb(value, addr); >> } >> >> static u8 pci_azx_readb(u8 __iomem *addr) >> { >> u8 val = readb(addr); >> pr_info_ratelimited("XXX readb %p %x\n", addr, val); >> return val; >> } >> >> and i was able to produce this... >> >> dmesg | grep -i read >> [ 0.764102] tpm_tis 00:05: A TPM error (7) occurred attempting to >> read a pcr value >> [ 0.769674] Write protecting the kernel read-only data: 12288k >> [ 1.729952] sd 0:0:0:0: [sda] Write cache: enabled, read cache: >> enabled, doesn't support DPO or FUA >> [ 2.071100] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: >> enabled, doesn't support DPO or FUA >> [ 2.778875] EXT4-fs (sda5): INFO: recovery required on readonly >> filesystem >> [ 2.817982] EXT4-fs (sda5): orphan cleanup on readonly fs >> [ 4.662442] XXX readw ffffc90004f30000 4401 > > This reads good, but I thought you have two sound devices (onboard and > Creative)? If so, disable the onboard one via enable=0 option (if the > onboard one is assigned first). Otherwise the all good and bad > results are mixed up. > > > Takashi >
I included options snd-hda-intel enable=0 index=0
This is dmesg output (1b is onboard)... dmesg | grep -i hda [ 3.700213] snd_hda_intel: probe of 0000:00:1b.0 failed with error -2 [ 37.729507] snd_hda_intel 0000:06:00.0: enabling device (0000 -> 0002) [ 37.729703] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 37.736026] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 38.740090] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 38.747292] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 43.776089] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 43.776111] snd_hda_intel 0000:06:00.0: no codecs initialized
dmesg | grep -i XXX [ 37.729723] XXX readw ffffc90005188000 3300 [ 37.729768] XXX readl ffffc90005188008 0
OK, so all read look fine. Right now we saw a bug report with git bisection showing a bad commit in HD-audio controller code. This might be your issue, too. Could you try the following oneliner?
thanks,
Takashi
diff --git a/sound/pci/hda/hda_controller.c b/sound/pci/hda/hda_controller.c index 7b4377265b25..57c4575fac26 100644 --- a/sound/pci/hda/hda_controller.c +++ b/sound/pci/hda/hda_controller.c @@ -1194,7 +1194,7 @@ static unsigned int azx_rirb_get_response(struct hda_bus *bus, } }
- if (!bus->no_response_fallback)
if (bus->no_response_fallback) return -1;
if (!chip->polling_mode && chip->poll_count < 2) {
I believe I applied the patch correctly... if you would like to double check here is the hda_controller.c file (http://pastebin.com/NA7AV2n1)
Same complaint comes up, after reinsert and force-reload as well...
[ 419.344572] snd_hda_intel 0000:06:00.0: enabling bus mastering [ 419.350967] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 422.360107] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 423.364094] snd_hda_intel 0000:06:00.0: Codec #1 probe error; disabling it... [ 423.371128] snd_hda_intel 0000:06:00.0: CORB reset timeout#1, CORBRP = 0 [ 424.376098] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 424.377052] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 424.377067] snd_hda_intel 0000:06:00.0: no codecs initialized
I'm assuming we've exhausted our options for now. It seems probable this model card (ExpressCard/54) never worked in Linux to begin with. I looked over the forum posts from those claiming they had it operational (in 2.6 kernel), but it was for the PCI-E version. I greatly appreciate your assistance with this. Thank you.
Yes, some PCI-e version has worked, I personally tested it once. But yours is apparently a different one, and we finally go back to the starting point again.
What you need to do from now on is to analyze why the codec probe fails. It failed even with single_cmd mode. This is strange, but it might be that the board is never 100% compliant, so it might not support that mode.
There are some workarounds done specific to the Creative devices. For example, azx_init_cmd_io() in hda_controller.c has a special handling to set RIRB interrupt count to 0xc0. I guess this needs to be set normally. That is, disable the following if () check, and run always azx_writew(chip, RINTCNT, 1) instead:
if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND) azx_writew(chip, RINTCNT, 0xc0); else azx_writew(chip, RINTCNT, 1);
This modification alone produced the same complaint. These are the edits I made...
/* set N=1, get RIRB response interrupt for new entry */ //if (chip->driver_caps & AZX_DCAPS_CTX_WORKAROUND) //azx_writew(chip, RINTCNT, 0xc0); //else azx_writew(chip, RINTCNT, 1);
There is another workaround in azx_pcm_prepare() for the capture streams, but this is irrelevant as of now -- we're concentrating only on the codec probe issue.
If modifying above still doesn't work, you may try to force continuing the probe by removing -EIO return from probe_codec() in hda_controller.c. That is, remove the following line from that function:
if (res == -1) return -EIO;
This is the edit I made...
mutex_unlock(&chip->bus->cmd_mutex); //if (res == -1) //return -EIO; dev_dbg(chip->card->dev, "codec #%d probed OK\n", addr);
I assume I did this correctly, but here is the full hda_controller.c I compiled if you would like to double check http://pastebin.com/fvVVA1Ew
Of course, it doesn't mean this would work, but we can see whether the board reacts somehow better.
Same complaint comes up.
[ 7.600051] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to polling mode: last cmd=0x100f0000 [ 9.608050] snd_hda_intel 0000:06:00.0: azx_get_response timeout, switching to single_cmd mode: last cmd=0x100f0000 [ 9.609976] snd_hda_intel 0000:06:00.0: no AFG or MFG node found [ 9.611023] snd_hda_intel 0000:06:00.0: no codecs initialized [ 10.776445] init: alsa-restore main process (1461) terminated with status 19
Then there is little hope at this point. We can analyze more, but it's difficult without the hardware locally, or you'll need to have a deeper knowledge of HD-audio.
Takashi
Then there is little hope at this point. We can analyze more, but it's difficult without the hardware locally, or you'll need to have a deeper knowledge of HD-audio.
Takashi
This card is fairly inexpensive (30 US dollars... http://amzn.com/B000QRV3NU). I could put down money towards new hardware that works, or if someone here has an ExpressCard/54 slot available, I would be happy to send one of these cards to you or someone else if they think it's worth a shot. I would also be willing to make an additional donation as well for time spent looking at it. I'm not expecting any guarantees, but it would be nice to know if this card can function under Linux.
-Alnie
participants (2)
-
Alnie -
Takashi Iwai