Opened 17 months ago

Last modified 17 months ago

#9165 in-progress bug

HDA VIA VT1708/A no longer works

Reported by: Ziusudra Owned by: mmlr
Priority: normal Milestone: R1
Component: Drivers/Audio/HDA Version: R1/alpha4.1
Keywords: Cc:
Blocked By: Blocking:
Has a Patch: no Platform: x86

Description

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.

Attachments (7)

r36953syslog.txt (96.3 KB) - added by Ziusudra 17 months ago.
4_1syslog.txt (115.1 KB) - added by Ziusudra 17 months ago.
listdev.txt (3.2 KB) - added by Ziusudra 17 months ago.
listimage.txt (1.5 KB) - added by Ziusudra 17 months ago.
disabledIOAPICsyslog.txt (125.9 KB) - added by Ziusudra 17 months ago.
acpinamespace.txt (23.6 KB) - added by Ziusudra 17 months ago.
PRT-FLOW-syslog.txt (129.1 KB) - added by Ziusudra 17 months ago.

Download all attachments as: .zip

Change History (21)

Changed 17 months ago by Ziusudra

Changed 17 months ago by Ziusudra

Changed 17 months ago by Ziusudra

Changed 17 months ago by Ziusudra

comment:1 Changed 17 months ago by Ziusudra

Between hrev41539 and hrev42421. That is as narrow as I can get with nightlies due to a two month gap during the Alpha3 release..

Last edited 17 months ago by Ziusudra (previous) (diff)

comment:2 Changed 17 months ago by 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...

comment:3 Changed 17 months ago by 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.

comment:4 Changed 17 months ago by 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/

comment:5 Changed 17 months ago by Ziusudra

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

comment:6 Changed 17 months ago by korli

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

comment:7 Changed 17 months ago by 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.

Changed 17 months ago by Ziusudra

comment:8 follow-up: Changed 17 months ago by 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.

comment:9 in reply to: ↑ 8 Changed 17 months ago by 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.

comment:10 follow-up: Changed 17 months ago by 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.

comment:11 in reply to: ↑ 10 Changed 17 months ago by 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.

Changed 17 months ago by Ziusudra

comment:12 Changed 17 months ago by 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.

comment:13 Changed 17 months ago by 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.

Changed 17 months ago by Ziusudra

comment:14 Changed 17 months ago by mmlr

  • Owner changed from korli to mmlr
  • Status changed from new to in-progress

Please also see my comment in #9180.

Note: See TracTickets for help on using tickets.