Opened 4 years ago
Closed 4 years ago
#16325 closed bug (duplicate)
[hda] no sound (regression)
Reported by: | kim1963 | Owned by: | mmlr |
---|---|---|---|
Priority: | normal | Milestone: | Unscheduled |
Component: | Drivers/Audio/HDA | Version: | R1/beta2 |
Keywords: | Cc: | korli | |
Blocked By: | #16222 | Blocking: | |
Platform: | All |
Description (last modified by )
Attachments (2)
Change History (20)
comment:1 by , 4 years ago
Component: | Audio & Video → Drivers/Audio/HDA |
---|---|
Description: | modified (diff) |
Summary: | 64 bit HDA driver broken. No sound → [hda] no sound (regression) |
comment:3 by , 4 years ago
Cc: | added |
---|
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?
comment:4 by , 4 years ago
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.
comment:6 by , 4 years ago
Component: | Drivers/Audio/HDA → Drivers |
---|---|
Owner: | changed from | to
Status: | new → assigned |
No, we indeed discovered multiple problems in the PCI bus that may be the actual culprit here. mmlr is working on them.
comment:9 by , 4 years ago
Try waiting a few minutes before you play any audio and see if it then works.
comment:12 by , 4 years ago
Component: | Drivers → Drivers/Audio/HDA |
---|
by , 4 years ago
comment:13 by , 4 years ago
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)
by , 4 years ago
Attachment: | syslogbeta2 added |
---|
comment:14 by , 4 years ago
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! :-)
comment:15 by , 4 years ago
the sound turns on itself on revisions 54454 and 54459 after 10 -28 minutes .. the exact time could not be established
comment:16 by , 4 years ago
Blocked By: | 16222 added |
---|
comment:17 by , 4 years ago
hrev54459 - The sound turned on spontaneously 23 minutes 30 seconds after the start of the operating system.
comment:18 by , 4 years ago
Resolution: | → duplicate |
---|---|
Status: | assigned → closed |
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.
Can be related to hrev54298 (HDA: Fix mapping 64-bit PCI addresses.).