Bug 94021
| Summary: | VIA VT8237A/VT8251 not recognized by ALSA | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | neapub |
| Component: | Sound(ALSA) | Assignee: | Takashi Iwai (tiwai) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | bjorn, mscott, superquad.vortex2, tiwai |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 3.11.0+ | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: |
alsa-info
dmesg lspci alsa-info (pci=realloc) dmesg (pci=realloc) lspci -vvv (pci=realloc) git bisect log |
||
|
Description
neapub
2015-02-28 22:20:34 UTC
Created attachment 168481 [details]
dmesg
Created attachment 168491 [details]
lspci
Looks like rather a PCI core problem. 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' 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. 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. Created attachment 168761 [details]
alsa-info (pci=realloc)
Created attachment 168771 [details]
dmesg (pci=realloc)
Created attachment 168781 [details]
lspci -vvv (pci=realloc)
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. 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 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? 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. Breaks somewhere between v3.10 (works) and v3.11 (doesn't work) upstream. Will try to bisect it and post the results here. 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. Created attachment 169631 [details]
git bisect log
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.
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 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. 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? (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. (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. 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. Thanks for the info. By "remap option" do you mean the boot option "pci=realloc"? Yes, what's what I meant. Sorry, used the wrong term. 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. 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. 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. 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! 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. 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. Great, that's what I want to hear. Thanks for checking that, Mike! |