Opened 10 years ago
Closed 9 years ago
#11410 closed bug (no change required)
media server no longer finds the soundcard
Reported by: | v.vill | Owned by: | korli |
---|---|---|---|
Priority: | normal | Milestone: | R1 |
Component: | Drivers/Audio/auich | Version: | R1/Development |
Keywords: | Cc: | ||
Blocked By: | Blocking: | ||
Platform: | x86 |
Description
Greetings,
after updating with pkgman (I'm not at hrev48210), the media server can't seem to find the soundcard. Restarting the server obviously doesn't help; the Deskbar applet displays "No audio output", and nothing appears in Media settings. (The PCI list still mentions "Intel 82801CA/CAM AC'97 Audio Controller").
All I'm getting on stderr is:
NodeManager::GetClone: couldn't GetDefaultNode, team 422, type 4 (AUDIO_OUTPUT)
Attachments (3)
Change History (10)
comment:1 by , 10 years ago
follow-up: 4 comment:2 by , 10 years ago
Well, it *used* to work when I did a clean install a couple of days ago using hrev48209. I'm not sure if it's a kernel regression or if something happened with the hardware (sound's still working fine under GNU Linux, though).
Anyway, comparing syslogs is instructive here (attached, I've even made a diff of the relevant parts). Syslog now says:
KERN: auich: init_hardware() KERN: auich: init_driver() KERN: pci_reserve_device(0, 31, 5, auich) KERN: auich: auich_setup(0xcdec07e0) KERN: auich: audio/hmulti/auich/1 deviceid = 0x2485 chiprev = 2 model = 1 enhanced at 0 KERN: auich: IO space not configured KERN: auich: Setup of auich 1 failed KERN: pci_unreserve_device(0, 31, 5, auich) KERN: auich: no cards KERN: auich: no suitable cards found
comment:3 by , 10 years ago
Component: | Servers → Drivers/Audio/auich |
---|---|
Owner: | changed from | to
follow-up: 5 comment:4 by , 10 years ago
Replying to v.vill:
KERN: auich: IO space not configured KERN: auich: Setup of auich 1 failed
This one, combined with the info in the attached diff, make this rather obvious. The PCI registers and interrupts are not set up by the firmware so the driver cannot access the device. This is therefore blocked by our oldest open tickets #3 and #4 and also one of those cases where #5 still would apply. This is a really old machine, so much so that it doesn't even provide a local APIC, which makes interrupt routing depend on the pci module. As suggested in #5, you could check if you have a "PnP OS Installed" or similar setting in the BIOS (if so try turning it off). Also if there's an option to enable APICs, by all means turn that one on.
Usually warm rebooting from another OS where PCI configuration is supported leaves the hardware in an initialized state, therefore allowing our drivers to pick it up from there. Maybe that's the reason why your fresh install works, presumably done from another OS and then rebooted, while cold booting directly into Haiku doesn't.
comment:5 by , 10 years ago
*facepalm* Oh yes, I've reset the BIOS options while trying to address a different issue with Haiku, and it set the PCI ressource assignment to "leave it to the OS" or something like that.
So, having restored the proper setting, now it works indeed (I probably should have mentioned that my only machine is a 1999 laptop, albeit heavily upgraded :-)
comment:6 by , 9 years ago
Since it depended on a hardware configuration and not an Haiku bug, is this ticket valid? Will wait some days before to close.
comment:7 by , 9 years ago
Resolution: | → no change required |
---|---|
Status: | new → closed |
Presumably it was found with previous revisions? Can you attach a syslog from a fresh boot on that system? Note also that the PCI list just shows devices that were discovered on the bus, which in no way implies a device driver is actually available to make use of them.