[hda] no sound (regression)

[kim1963]

hrev54298 broke sound for me.

device Multimedia controller (Audio device) [4|3|0]
  vendor 8086: Intel Corporation
  device a348: Cannon Lake PCH cAVS

Beta2 and hrev54280 - work fine.

[X512]

Can be related to hrev54298 (HDA: Fix mapping 64-bit PCI addresses.).

[waddlesplash]

The only functional difference in that commit for systems without a 64-bit address is the PCI_address_memory_32_mask, which most other things that use 64-bit PCI addresses conditionally use.

CC korli: is it possible that is actually incorrect and should not be done?

[waddlesplash]

Actually I think the PCI bus may already do this masking when it reads the base registers: ​https://xref.landonf.org/source/xref/haiku/src/add-ons/kernel/bus_managers/pci/pci.cpp#1190

So that mask may indeed be wrong in the case of "IO space", and unnecessary otherwise.

[kim1963]

Revert 54298 ?

[waddlesplash]

No, we indeed discovered multiple problems in the PCI bus that may be the actual culprit here. mmlr is working on them.

[waddlesplash]

Please retest after hrev54417.

[kim1963]

hrev54418 - no sound

[waddlesplash]

Try waiting a few minutes before you play any audio and see if it then works.

[kim1963]

Waiting 10 minutes. No sound!

[waddlesplash]

Please attach a syslog.

[ttcoder]

KERN: pci_reserve_device(0, 31, 3, hda)
KERN: HDA: Detected controller @ PCI:0:31:3, IRQ:16, type 8086/a348 (17aa/313d)
...
KERN: hda: Codec 0 Vendor: 10ec Product: 0274, Revision: 1.0.0.4 Quirks: 0700

I suppose it might help if you post a syslog from a working hrev (beta2 ?) and a dev would compare that old syslog side-by-side with the new non-working one.

(Though the differences in PCI or HDA behavior might not show up in the log, depending on the bug)

[ttcoder]

I can see no significant difference in the hda part..

To my untrained eye it seems the nightly differs from beta2 mainly in regards to dealing with the CPUs, if even that:

diff syslogbeta2 syslog

< KERN: Haiku revision: hrev54154+116, debug level: 1
---
> KERN: Haiku revision: hrev54418, debug level: 2

> KERN: CPU 0: features: ............ xsaveopt xsavec 

< KERN: arch_altcodepatch_replace found 31 altcodepatches
< KERN: arch_altcodepatch_replace found 291 altcodepatches
---
> KERN: arch_altcodepatch_replace found 31 altcodepatches for tag 1
> KERN: arch_altcodepatch_replace found 291 altcodepatches for tag 2
> KERN: arch_altcodepatch_replace found 2 altcodepatches for tag 3
> KERN: arch_altcodepatch_replace found 4 altcodepatches for tag 4
> KERN: enable XSAVEC 0x7 832

Call in the pros! :-)

[kim1963]

the sound turns on itself on revisions 54454 and 54459 after 10 -28 minutes .. the exact time could not be established

[ttcoder]

Ah, that would make this ticket a dupe of #16222 I guess.

Though I see there's been lots of HDA changes in hrev54459.. So try that upgrade "just in case"~~

EDIT: sorry, I see in your message that you've already tried 54459

[kim1963]

hrev54459 - The sound turned on spontaneously 23 minutes 30 seconds after the start of the operating system.

[mmlr]

This indeed is a duplicate then. I have a lead for a fix, the issue is with the times published to the TimeSource of the MultiAudioNode.