Bug 94021 - VIA VT8237A/VT8251 not recognized by ALSA
Summary: VIA VT8237A/VT8251 not recognized by ALSA
Status: RESOLVED CODE_FIX
Alias: None
Product: Drivers
Classification: Unclassified
Component: Sound(ALSA) (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Takashi Iwai
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-02-28 22:20 UTC by neapub
Modified: 2016-05-10 18:57 UTC (History)
4 users (show)

See Also:
Kernel Version: 3.11.0+
Tree: Mainline
Regression: Yes


Attachments
alsa-info (9.09 KB, text/plain)
2015-02-28 22:20 UTC, neapub
Details
dmesg (80.75 KB, text/plain)
2015-02-28 22:20 UTC, neapub
Details
lspci (35.43 KB, text/plain)
2015-02-28 22:21 UTC, neapub
Details
alsa-info (pci=realloc) (6.82 KB, text/plain)
2015-03-03 22:29 UTC, neapub
Details
dmesg (pci=realloc) (83.90 KB, text/plain)
2015-03-03 22:29 UTC, neapub
Details
lspci -vvv (pci=realloc) (35.51 KB, text/plain)
2015-03-03 22:30 UTC, neapub
Details
git bisect log (3.49 KB, text/plain)
2015-03-07 14:39 UTC, neapub
Details

Description neapub 2015-02-28 22:20:34 UTC
Created attachment 168471 [details]
alsa-info

Internal sound card is not getting recognized by ALSA due to a ioremap error while loading snd_intel_hda.

Mainboard containing this chip is a MSI MS-7318 used by some MEDION PCs.

This bug was also already reported on Launchpad before:
https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1301708

Using pci=use_crs in boot args does not fix this problem.

The following kernel was used (running Lubuntu 14.10):
Linux version 3.19.0-031900-generic (kernel@tangerine) (gcc version 4.6.3 (Ubuntu/Linaro 4.6.3-1ubuntu5) ) #201502091451 SMP Mon Feb 9 14:52:52 UTC 2015

However, this problems exists for a quite some time now (don't know exactly since which specific kernel version).

Here's the error output at system startup (more logs in the Attachment):

[   20.368734] snd_hda_intel 0000:02:00.1: Handle VGA-switcheroo audio client
[   20.368818] snd_hda_intel 0000:02:00.1: PCI: Disallowing DAC for device
[   20.368889] ------------[ cut here ]------------
[   20.368899] WARNING: CPU: 1 PID: 139 at /home/kernel/COD/linux/drivers/pci/pci.c:131 pci_ioremap_bar+0x71/0x80()
[   20.368955] CPU: 1 PID: 139 Comm: kworker/1:2 Tainted: G            E  3.19.0-031900-generic #201502091451
[   20.368957] Hardware name: MEDIONPC MS-7318/MS-7318, BIOS 6.00 PG 03/23/2010
[   20.368967] Workqueue: events azx_probe_work [snd_hda_intel]
[   20.368969]  0000000000000083 ffff88003677bcf8 ffffffff817c4c00 0000000000000007
[   20.368972]  0000000000000000 ffff88003677bd38 ffffffff81076e87 ffff8800bfa93e40
[   20.368974]  ffff8800b89aa000 ffff8800bbaf9000 ffff8800bbaf9000 ffff8800b89ab800
[   20.368977] Call Trace:
[   20.368983]  [<ffffffff817c4c00>] dump_stack+0x45/0x57
[   20.368988]  [<ffffffff81076e87>] warn_slowpath_common+0x97/0xe0
[   20.368990]  [<ffffffff81076eea>] warn_slowpath_null+0x1a/0x20
[   20.368993]  [<ffffffff813edf31>] pci_ioremap_bar+0x71/0x80
[   20.368997]  [<ffffffffc05a05ba>] azx_first_init+0x5a/0x530 [snd_hda_intel]
[   20.369002]  [<ffffffff8101358e>] ? __switch_to+0xbe/0x5b0
[   20.369007]  [<ffffffffc05a0aeb>] azx_probe_continue+0x5b/0x280 [snd_hda_intel]
[   20.369011]  [<ffffffffc05a0d25>] azx_probe_work+0x15/0x20 [snd_hda_intel]
[   20.369016]  [<ffffffff8108f76d>] process_one_work+0x14d/0x460
[   20.369019]  [<ffffffff8109014b>] worker_thread+0x11b/0x3f0
[   20.369021]  [<ffffffff81090030>] ? create_worker+0x1e0/0x1e0
[   20.369024]  [<ffffffff81095d59>] kthread+0xc9/0xe0
[   20.369027]  [<ffffffff81095c90>] ? flush_kthread_worker+0x90/0x90
[   20.369031]  [<ffffffff817d1e7c>] ret_from_fork+0x7c/0xb0
[   20.369034]  [<ffffffff81095c90>] ? flush_kthread_worker+0x90/0x90
[   20.369035] ---[ end trace cea57c38689c56f2 ]---
[   20.369038] snd_hda_intel 0000:04:01.0: ioremap error
[   21.380047] snd_hda_intel 0000:02:00.1: Codec #0 probe error; disabling it...
Comment 1 neapub 2015-02-28 22:20:52 UTC
Created attachment 168481 [details]
dmesg
Comment 2 neapub 2015-02-28 22:21:13 UTC
Created attachment 168491 [details]
lspci
Comment 3 Takashi Iwai 2015-03-01 08:13:10 UTC
Looks like rather a PCI core problem.
Comment 4 Raymond 2015-03-02 16:12:54 UTC
04:00.0 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=04, secondary=05, subordinate=05, sec-latency=0
	I/O behind bridge: 00009000-00009fff
	Memory behind bridge: df900000-df9fffff
	Prefetchable memory behind bridge: df700000-df7fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0
			ExtTag- RBE-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 256 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #1, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [68] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [70] MSI: Enable+ Count=1/1 Maskable+ 64bit+
		Address: 00000000fee0300c  Data: 41e1
		Masking: 00000001  Pending: 00000000
	Capabilities: [88] HyperTransport: MSI Mapping Enable- Fixed+
	Capabilities: [90] Subsystem: Device 0002:0000
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed+ WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending+ InProgress-
		VC1:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable- ID=1 ArbSelect=Fixed TC/VC=00
			Status:	NegoPending- InProgress-
	Capabilities: [180 v1] Root Complex Link
		Desc:	PortNumber=01 ComponentID=02 EltType=Config
		Link0:	Desc:	TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
			Addr:	00000000f0000000
	Kernel driver in use: pcieport

04:00.1 PCI bridge: VIA Technologies, Inc. VT8251 PCIE Root Port (prog-if 00 [Normal decode])
	Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Latency: 0
	Bus: primary=04, secondary=06, subordinate=06, sec-latency=0
	I/O behind bridge: 00008000-00008fff
	Memory behind bridge: df800000-df8fffff
	Prefetchable memory behind bridge: df600000-df6fffff
	Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
	BridgeCtl: Parity- SERR- NoISA+ VGA- MAbort- >Reset- FastB2B-
		PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
	Capabilities: [40] Express (v1) Root Port (Slot-), MSI 00
		DevCap:	MaxPayload 256 bytes, PhantFunc 0
			ExtTag- RBE-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 256 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
		LnkCap:	Port #2, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit Latency L0s <128ns, L1 <1us
			ClockPM- Surprise- LLActRep- BwNot-
		LnkCtl:	ASPM Disabled; RCB 64 bytes Disabled- CommClk-
			ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
		LnkSta:	Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk- DLActive- BWMgmt- ABWMgmt-
		RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
		RootCap: CRSVisible-
		RootSta: PME ReqID 0000, PMEStatus- PMEPending-
	Capabilities: [68] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [70] MSI: Enable+ Count=1/1 Maskable+ 64bit+
		Address: 00000000fee0300c  Data: 4142
		Masking: 00000001  Pending: 00000000
	Capabilities: [88] HyperTransport: MSI Mapping Enable- Fixed+
	Capabilities: [90] Subsystem: Device 0004:0000
	Capabilities: [100 v1] Advanced Error Reporting
		UESta:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UEMsk:	DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
		UESvrt:	DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
		CESta:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		CEMsk:	RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
		AERCap:	First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
	Capabilities: [140 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed+ WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending+ InProgress-
		VC1:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable- ID=1 ArbSelect=Fixed TC/VC=00
			Status:	NegoPending- InProgress-
	Capabilities: [180 v1] Root Complex Link
		Desc:	PortNumber=02 ComponentID=02 EltType=Config
		Link0:	Desc:	TargetPort=00 TargetComponent=02 AssocRCRB- LinkType=MemMapped LinkValid+
			Addr:	00000000f0000000
	Kernel driver in use: pcieport

04:01.0 Audio device: VIA Technologies, Inc. VT8237A/VT8251 HDA Controller
	Subsystem: Micro-Star International Co., Ltd. [MSI] Device 7318
	Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
	Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
	Interrupt: pin A routed to IRQ 17
	Capabilities: [50] Power Management version 2
		Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA PME(D0+,D1-,D2-,D3hot+,D3cold+)
		Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
	Capabilities: [60] MSI: Enable- Count=1/1 Maskable- 64bit-
		Address: 00000000  Data: 0000
	Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00
		DevCap:	MaxPayload 128 bytes, PhantFunc 0
			ExtTag- RBE-
		DevCtl:	Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
			RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
			MaxPayload 128 bytes, MaxReadReq 128 bytes
		DevSta:	CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
	Capabilities: [100 v1] Virtual Channel
		Caps:	LPEVC=0 RefClk=100ns PATEntryBits=1
		Arb:	Fixed- WRR32- WRR64- WRR128-
		Ctrl:	ArbSelect=Fixed
		Status:	InProgress-
		VC0:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable+ ID=0 ArbSelect=Fixed TC/VC=ff
			Status:	NegoPending- InProgress-
		VC1:	Caps:	PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
			Arb:	Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
			Ctrl:	Enable- ID=1 ArbSelect=Fixed TC/VC=00
			Status:	NegoPending- InProgress-
	Capabilities: [130 v1] Root Complex Link
		Desc:	PortNumber=03 ComponentID=01 EltType=Config
		Link0:	Desc:	TargetPort=00 TargetComponent=01 AssocRCRB- LinkType=MemMapped LinkValid+
			Addr:	00000000f0000000
	Kernel driver in use: snd_hda_intel




[    0.136329] pci 0000:04:00.0: [1106:287c] type 01 class 0x060400
[    0.136429] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[    0.136463] pci 0000:04:00.0: System wakeup disabled by ACPI
[    0.136514] pci 0000:04:00.1: [1106:287d] type 01 class 0x060400
[    0.136614] pci 0000:04:00.1: PME# supported from D0 D3hot D3cold
[    0.136644] pci 0000:04:00.1: System wakeup disabled by ACPI
[    0.136693] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
[    0.136709] pci 0000:04:01.0: [1106:3288] type 00 class 0x040300
[    0.136721] pci 0000:04:01.0: reg 0x10: [mem 0x00000000-0x00003fff]
[    0.136805] pci 0000:04:01.0: PME# supported from D0 D3hot D3cold
[    0.136830] pci 0000:04:01.0: System wakeup disabled by ACPI
[    0.136871] pci 0000:04:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
Comment 5 Bjorn Helgaas 2015-03-03 19:47:00 UTC
This is not the same problem as https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1301708 .  I do not see a PCI core issue in 1301708.  But *this* problem does seem to be a PCI core problem. 

There are three devices on bus 04: two bridges (VT8251 PCIE Root Ports) and one audio device (VT8237A/VT8251 HDA).  The Root Ports take up all the MMIO space that is routed to bus 04 by the bridge at 00:13.0:

  pci 0000:00:13.0: PCI bridge to [bus 04-06]
  pci 0000:00:13.0:   bridge window [mem 0xdf800000-0xdf9fffff]
  pci 0000:00:13.0:   bridge window [mem 0xdf600000-0xdf7fffff 64bit pref]
  pci 0000:04:00.0: PCI bridge to [bus 05]
  pci 0000:04:00.0:   bridge window [mem 0xdf900000-0xdf9fffff]
  pci 0000:04:00.0:   bridge window [mem 0xdf700000-0xdf7fffff pref]
  pci 0000:04:00.1: PCI bridge to [bus 06]
  pci 0000:04:00.1:   bridge window [mem 0xdf800000-0xdf8fffff]
  pci 0000:04:00.1:   bridge window [mem 0xdf600000-0xdf6fffff pref]
  pci 0000:04:01.0: [1106:3288] type 00 class 0x040300
  pci 0000:04:01.0: reg 0x10: [mem 0x00000000-0x00003fff]
  pci 0000:04:01.0: BAR 0: no space for [mem size 0x00004000]
  pci 0000:04:01.0: BAR 0: failed to assign [mem size 0x00004000]

This leaves no space available for the audio device.  Normally a BIOS would assign resources to all the devices, so we wouldn't see this configuration.  So it's possible that a BIOS update would work around the problem.

But Linux should be able to fix this by itself.  Does it help if you boot with "pci=realloc"?  That should make Linux try harder to assign resources by enlarging the 00:13.0 bridge windows.
Comment 6 neapub 2015-03-03 22:29:08 UTC
Okay, I added pci=realloc to the boot command line and the ioremap error is gone (so no PCI bug?) , however audio's still missing and now I'm getting some CORB reset timeouts:

[   20.156110] [drm] Initialized radeon 2.40.0 20080528 for 0000:02:00.0 on minor 0
[   20.157344] snd_hda_intel 0000:02:00.1: Handle VGA-switcheroo audio client
[   20.157458] snd_hda_intel 0000:02:00.1: PCI: Disallowing DAC for device
[   20.157504] snd_hda_intel 0000:04:01.0: enabling device (0000 -> 0002)
[   20.163881] snd_hda_intel 0000:04:01.0: CORB reset timeout#1, CORBRP = 0
[   20.300541] Request for unknown module key 'Magrathea: Glacier signing key: 007271576a09d86ef244371b0633e47abb75b89d' err -11
--
[   21.154184] Request for unknown module key 'Magrathea: Glacier signing key: 007271576a09d86ef244371b0633e47abb75b89d' err -11
[   21.160031] snd_hda_intel 0000:02:00.1: Codec #0 probe error; disabling it...
[   21.176009] snd_hda_intel 0000:04:01.0: Codec #0 probe error; disabling it...
[   21.181662] snd_hda_intel 0000:04:01.0: CORB reset timeout#1, CORBRP = 0
[   21.238593] Request for unknown module key 'Magrathea: Glacier signing key: 007271576a09d86ef244371b0633e47abb75b89d' err -11
--
[   23.785045] Request for unknown module key 'Magrathea: Glacier signing key: 007271576a09d86ef244371b0633e47abb75b89d' err -11
[   23.785454] saa7134 ALSA driver for DMA sound loaded
[   23.785490] saa7133[0]/alsa: saa7133[0] at 0xdf5ff000 irq 16 registered as card -2
--
[   26.024046] tda1004x: found firmware revision 26 -- ok
[   26.188088] snd_hda_intel 0000:02:00.1: no AFG or MFG node found
[   26.188106] snd_hda_intel 0000:02:00.1: no codecs initialized
[   26.204034] snd_hda_intel 0000:04:01.0: no AFG or MFG node found
[   26.204050] snd_hda_intel 0000:04:01.0: no codecs initialized
[   27.409550] r8169 0000:07:0b.0 eth1: link up



I'll attach new logs with pci=realloc set.
Comment 7 neapub 2015-03-03 22:29:40 UTC
Created attachment 168761 [details]
alsa-info (pci=realloc)
Comment 8 neapub 2015-03-03 22:29:58 UTC
Created attachment 168771 [details]
dmesg (pci=realloc)
Comment 9 neapub 2015-03-03 22:30:28 UTC
Created attachment 168781 [details]
lspci -vvv (pci=realloc)
Comment 10 Bjorn Helgaas 2015-03-04 15:25:27 UTC
A user should not have to specify "pci=realloc", so I consider that a workaround, not a bug fix.  So I think it's a bug that PCI doesn't do the reassignment automatically.

But it looks like PCI did a valid reassignment.  The "CORB reset timeout" problem looks like a separate issue, possibly the same one as https://bugs.launchpad.net/ubuntu/+source/alsa-driver/+bug/1301708 .

I don't have any theories about that, but I suspect a snd_hda_intel driver problem.  The 1301708 report suggests that the device does work in some pre-13.x Ubuntu versions.

Bisection is a possible way to investigate this.
Comment 11 Raymond 2015-03-04 15:40:52 UTC
you have three errors

https://bugzilla.kernel.org/show_bug.cgi?id=92981


[   20.157344] snd_hda_intel 0000:02:00.1: Handle VGA-switcheroo audio client
[   20.157458] snd_hda_intel 0000:02:00.1: PCI: Disallowing DAC for device

these error belong to  your hdmi audio controller


[   20.157504] snd_hda_intel 0000:04:01.0: enabling device (0000 -> 0002)
[   20.163881] snd_hda_intel 0000:04:01.0: CORB reset timeout#1, CORBRP = 0

these error belong to via hda controller
Comment 12 neapub 2015-03-04 18:33:33 UTC
12.10 is the last version where audio works, beginning from 13.04 the VIA controller is missing in ALSA.
I tried updating Ubuntu 12.10's kernel up to 3.10 mainline from the Ubuntu mainline kernel builds, but audio is still working, even though Ubuntu 13.04's kernel bases on 3.8.8? Or do I need to update another component to check if the VIA HDA controller stops working at some point?


Could it be that the PCI bug is triggered by having 4GB installed even though the BIOS/board only supports 3GB because of missing Memory Remapping or is it something else?
Comment 13 Bjorn Helgaas 2015-03-04 20:07:13 UTC
The PCI bug is that we don't automatically try to reallocate things when we don't have space for a device.  This is a generic known issue, not related to how much memory you have installed.

This looks like an issue in the kernel or driver, so I don't think you need to worry about other components.

If you're comfortable building upstream kernels, I would start by testing plain v3.19.  If that works, then it's probably something introduced by Ubuntu or Lubuntu.  If upstream v3.19 fails, then try v3.10 and (assuming v3.10 works), bisect between v3.10 and v3.19.
Comment 14 neapub 2015-03-04 22:09:26 UTC
Breaks somewhere between v3.10 (works) and v3.11 (doesn't work) upstream.

Will try to bisect it and post the results here.
Comment 15 neapub 2015-03-07 14:36:39 UTC
Here we go:
63e51fd708f511a5989da04c669647993bc1a512 is the first bad commit
commit 63e51fd708f511a5989da04c669647993bc1a512
Author: Takashi Iwai <tiwai@suse.de>
Date:   Thu Jun 6 14:20:19 2013 +0200

    ALSA: hda - Don't take unresponsive D3 transition too serious
    
    When a codec is powered off, some systems don't respond properly after
    D3 FG transition, while the driver still expects the response and
    tries to fall back to different modes (polling and single-cmd).  When
    the fallback happens, the driver stays in that mode, and falling back
    to the single-cmd mode means it'll loose the unsol event handling,
    too.
    
    The unresponsiveness at D3 isn't too serious, thus this fallback is
    mostly superfluous.  We can gracefully ignore the error there so that
    the driver keeps the normal operation mode.
    
    This patch adds a new bit flag for codec read/write, set in the power
    transition stage, which is notified to the controller driver via a new
    bus->no_response_fallback flag.
    
    Signed-off-by: Takashi Iwai <tiwai@suse.de>

:040000 040000 617e82c75dc8ab1b654639b4e0ef163e5154e6a6 b31f0bde4a55fbd19edfd8d483cd690a959a9516 M	sound


I'm putting this bug back to ALSA. I'm also attaching the bisect log.
Comment 16 neapub 2015-03-07 14:39:13 UTC
Created attachment 169631 [details]
git bisect log
Comment 17 Takashi Iwai 2015-03-07 15:52:56 UTC
OK, this is indeed a stupid bug in the commit.  The bug appears only when a HD-audio controller doesn't respond properly, i.e. an unstable controller chip. Most of chips worked fine (that's why the bug has exited for such long time) but apparently it hits on yours by some reason.

The fix would be just removing "!" from the check of bus->no_response_fallback in azx_rirb_get_response().  Below is the patch to the recent kernel.  The function is found in sound/pci/hda/hda_controller.c in the recent kernel (3.14+) while it's in sound/pci/hda/hda_intel.c in 3.11, so for the older kernel, just try modifying the code manuall.

--- a/sound/pci/hda/hda_controller.c
+++ b/sound/pci/hda/hda_controller.c
@@ -1164,7 +1164,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) {

Let me know if this cures the problem.
Comment 18 neapub 2015-03-07 18:35:01 UTC
Yes, removing the "!" fixes the problem:

neapub@MS-7318:~$ uname -a
Linux MS-7318 4.0.0-rc2-hdapatch #1 SMP Sat Mar 7 18:16:55 CET 2015 x86_64 x86_64 x86_64 GNU/Linux
neapub@MS-7318:~$ aplay -l
**** Liste der Hardware-Geräte (PLAYBACK) ****
Karte 0: HDMI [HDA ATI HDMI], Gerät 3: HDMI 0 [HDMI 0]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: VT82xx [HDA VIA VT82xx], Gerät 0: ALC888 Analog [ALC888 Analog]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Karte 1: VT82xx [HDA VIA VT82xx], Gerät 1: ALC888 Digital [ALC888 Digital]
  Sub-Geräte: 1/1
  Sub-Gerät #0: subdevice #0
Comment 19 Takashi Iwai 2015-03-08 17:29:17 UTC
Thanks for a quick test, I'll queue the fix patch.  It's too late for 4.0-rc3 now, but it'll be included for 4.0-rc4, then backported to stable branches.
Comment 20 Mike Scott 2016-04-27 08:32:58 UTC
Was this bug really fixed in 4.0-rc4? 
I'm still getting this problem on my MedionPC using Ubuntu 16.04 LTS (Kernel 4.4.0-21-generic).
Sorry for my ignorance, but how can I verify whether the patch is present?
Comment 21 Takashi Iwai 2016-04-28 13:00:38 UTC
(In reply to Mike Scott from comment #20)
> Was this bug really fixed in 4.0-rc4? 
> I'm still getting this problem on my MedionPC using Ubuntu 16.04 LTS (Kernel
> 4.4.0-21-generic).
> Sorry for my ignorance, but how can I verify whether the patch is present?

Your problem may be different from the bug here.
Comment 22 Mike Scott 2016-04-28 13:18:02 UTC
(In reply to Takashi Iwai from comment #21)
> (In reply to Mike Scott from comment #20)
> > Was this bug really fixed in 4.0-rc4? 
> > I'm still getting this problem on my MedionPC using Ubuntu 16.04 LTS
> (Kernel
> > 4.4.0-21-generic).
> > Sorry for my ignorance, but how can I verify whether the patch is present?
> 
> Your problem may be different from the bug here.

Takashi, I appreciate that my case may differ, but this built-in soundcard still works when I boot Windows on this dual-boot machine and used to work with Ubuntu many releases ago. It stopped working after I upgraded to a new Ubuntu release several years ago and I have been waiting for a fix ever since. 
If you can confirm that the fix is present on 4.4.0-21, I will open a new case for this bug.
Comment 23 neapub 2016-04-28 13:34:46 UTC
My system with which I reported the bug is currently running Arch Linux with the LTS kernel (which is on 4.4.8-1) and audio is working for me with the remap option (haven't tested it without) mentioned at the beginning of this thread.
Comment 24 Mike Scott 2016-04-28 14:21:39 UTC
Thanks for the info. By "remap option" do you mean the boot option "pci=realloc"?
Comment 25 neapub 2016-04-28 14:24:47 UTC
Yes, what's what I meant. Sorry, used the wrong term.
Comment 26 Bjorn Helgaas 2016-04-28 14:42:31 UTC
Just to be clear, I consider it a PCI defect if a user must boot with "pci=realloc", so if that's the case, please open a defect report.  I can't promise it will be fixed quickly because we have several complicated problems in that area, but I would still like to know about it.  Complete dmesg logs from (a) old kernel that works without "pci=realloc", (b) new kernel that works with "pci=realloc", and (c) new kernel that fails without "pci=realloc" would be useful.
Comment 27 neapub 2016-04-28 14:59:36 UTC
Booting without pci=realloc does indeed break audio (ioremap error). Never noticed that after the other bug was fixed because I saved "pci=realloc" in my GRUB config and never cared about it since then.

I'll open a new report later with the logs.
Comment 28 Mike Scott 2016-04-28 15:44:53 UTC
Thanks to both of you for your help. 
I just tried rebooting with pci=realloc option. Unfortunately no improvement to sound - still no sound and only "Dummy device" displayed. I can see in dmesg that pci=realloc was specified on kernel options, so i need to compare other dmesg details etc with your other info. above to see if my detail symptoms match.
Comment 29 Mike Scott 2016-05-10 08:20:28 UTC
Sorry for my late reply, I was too busy with other stuff to get back to Ubuntu. In the meantime, my Ubuntu 16.04 has updated itself from kernel version 4.4.0-21.37 to 4.4.0-22.23 and that change has fixed the problem:

Using boot-option pci=use_crs the sound card gets detected by the 4.4.0-22.23  and I get sound on the speakers, but if I boot from 4.4.0-21.37 I see only the "Dummy Output" sound device and get no sound. 

Thanks for your help - sometimes it clearly does help just to talk about some problems!
Comment 30 Bjorn Helgaas 2016-05-10 16:33:59 UTC
Mike, sorry to trouble you again, but it sounds like you still need to use "pci=use_crs" on 4.4.0-22.23 to make your sound card work.  That's a bug -- we should be able to make it work even without the boot parameter.

If you have a chance, could you open a new bugzilla (I think it's a different problem than was initially reported here).  Please attach the complete dmesg logs from 4.4.0-22.23, both with and without "pci=use_crs".

It would be really awesome if you could try a vanilla upstream kernel, e.g., v4.5, too.  That would tell us whether the problem is specific to Ubuntu or not.
Comment 31 Mike Scott 2016-05-10 18:34:52 UTC
Hi Bjorn,
i just edited out the "pci=use_crs" option from my boot parameters and rebooted. The sound is still ok. I checked the dmesg output to make sure that the option was really no longer there and I can confirm that I still have sound without the "pci=use_crs" parameter.
I think the pci=use_crs Grub option was recommended long ago by the Alsa team  if your soundcard was not being detected, but it never worked for me so I am happy now that I don't need it.
Comment 32 Bjorn Helgaas 2016-05-10 18:57:04 UTC
Great, that's what I want to hear.  Thanks for checking that, Mike!

Note You need to log in before you can comment on or make changes to this bug.