HDA VIA VT1708/A no longer works

[Ziusudra]

Will attempt binary search of nightlies to narrow down when this stopped working. It may take a while due to slow internet.

Note: audio still works fine in Windows.

[Ziusudra]

First bracket is between hrev41154 and hrev43643.

[ttcoder]

Your 4.1 syslog goes,

KERN: hda: HDA v1.0, O:4/I:4/B:0, #SDO:1, 64bit:yes
KERN: hda: Failed to get vendor and revision parameters: Operation timed out
KERN: hda: no active codec

whereas the other syslog looks normal.

Not sure how to access the old (pre-git) hrev range of revisions, but with a little luck there aren't too many HDA-related changes between 41539 and 42421 and the haiku devs will find the "get vendor & revision" regression without too much trouble...

[korli]

"get vendor & revision" is simply the first HDA request done. It usually means PCI config (irq, mmbar) isn't properly set or detected, so probably not a HDA regression. It could be related to MSI setup for instance.

[Ziusudra]

Indeed, there appear to have been no changes to HDA in that revision range: ​http://cgit.haiku-os.org/haiku/log/src/add-ons/kernel/drivers/audio/hda/

[Ziusudra]

Just tested Alpha 3 and it was not working then so that makes hrev42211 the earliest known bad revision.

[korli]

Did you try to disable local APIC or SMP at boot time?

[Ziusudra]

Disabling IO APIC does indeed allow the HDA to work. (As does disabling local APIC though that also disables SMP.)

When away from the computer I thought I should try this but failed to remember to ever try it. Anyway, I've disabled IO APIC in /boot/home/config/settings/kernel/drivers/kernel.

Syslog with IO APIC disabled attached in case anyone is interested.

[korli]

Is there a way for you to run linux or *BSD and get the debug output of them booting up (dmesg)? mmlr would be interested to see if they end up with the same routing table info.

[mmlr]

Replying to korli:

Is there a way for you to run linux or *BSD and get the debug output of them booting up (dmesg)? mmlr would be interested to see if they end up with the same routing table info.

Indeed that one would be interesting. Also as mentioned in #9180 the output of "cat /dev/acpi/namespace" would be interesting to see if there's more in ACPI that we might miss.

Your system has 2 IO-APICs of which the second isn't used at all. The PCI bus 128 (unusual for a PCI bus number but not invalid) where the HDA controller sits isn't enumerated at all by the interrupt routing code it seems. It's quite possible that devices on that bus should be mapped to the second IO-APIC, or maybe that one is reserved for add-on cards (as is the case in many servers). As ensure_all_functions_matched() in the interrupt setup code apparently ran through without panicking but still without actually matching the device on bus 128, I suspect a problem in the PCI enumeration in there though. I'm taking a longer look at that code for now with the info from your syslog.

If you build your image yourself, you could help me by enabling TRACE_PRT in src/system/kernel/arch/x86/irq_routing_table.cpp and attaching another syslog.

[mmlr]

Actually we are assigning the bus numbers and we start at 0. Looking at the PCI dump it becomes clear that this hasn't really worked out for the PCI Express bus the HDA controller is on. There's bus 0 (the root bus), then there's bus 1 behind the first bridge, then bus 2 behind the second bridge, then suddenly comes bus 128 instead of 3 and finally there's bus 3 behind the last bridge. Something's up with that, as bus 128 should indeed just be bus 3 and bus 3 should be bus 4.

Apparently the device is still generally accessible, as when disabling the IO-APIC, the HDA driver uses it as device 128:0:1. The interrupt routing code does probably fall victim of the root problem though and then simply can't match up the interrupt configuration anymore. A trace enabled PCI module would help if you build the images yourself.

[Ziusudra]

I can boot Ubuntu/Mint live ISOs but have to specify "noacpi noapic nomodeset" to do so. Would that still be usefull?

This motherboard is an ​ASRock 4CoreDual-SATA2. Although it is a revision with a Realtek 5.1 channel ALC662 codec (10ec/0662) rather than the 7.1 ALC888 (10ec/0888).

Output of "cat /dev/acpi/namespace" attached.

I do build Haiku images and will attempt one with those traces enabled.

[mmlr]

OK that clears up that anyway: There's a PCI Express node below the south bridge that holds a routing table and the HDA Controller. This one is completely ignored right now. This is because usually these aren't separate but part of the overall PCI bus, as that's where they are attached and enumerated. Adding support for that may fix this, but the issue of the wrong bus number remains curious.

That you have to boot with noacpi and noapic in Linux does not make me very hopeful though as that usually indicates something's broken with the ACPI tables. We might just get by, as we rely on ACPI less currently, but eventually this sounds problematic. With those two disabled the output of dmesg would be uninteresting indeed.

Have you checked if there's a firmware update available? Sometimes they fix up the ACPI tables afterwards.

[Ziusudra]

I am one BIOS version behind. I might try updating it mainly to see if it helps with Linux.

Attaching syslog with FLOW and TRACE_PRT enabled.

[mmlr]

Please also see my comment in #9180.

[pulkomandy]

Removing HDA audio tickets from Beta2 milestone, no one has worked on it and opensound is available at least as a stopgap.

[waddlesplash]

Please retest under a recent nightly.

[Ziusudra]

I saw the recent changes that might affect this - unfortunately, that box won't power on. I'm not sure why, and I don't hav a spare PSU to try. So, you can close this - if I ever get it working again I'll test it, and I can request to reopen if needed.

[waddlesplash]

Thanks for replying!