Regression: Sound card doesn't work

[drcouzelis]

My sound card does not work in Haiku. It previously worked in Haiku. I tested nightly builds until I found when it stopped working:

hrev41505 (2011-05-14) Sound card is recognized and works correctly.

hrev41539 (2011-05-18) Sound card is not recognized and sound does not play, "Could not find the mixer".

lspci output: "Audio device: Advanced Micro Devices [AMD] nee ATI SBx00 Azalia (Intel HDA)" Which is on a GIGABYTE GA-MA770-DS3 motherboard: ​http://www.newegg.com/Product/Product.aspx?Item=N82E16813128081

Please let me know if I can provide more information. Thank you.

[umccullough]

It seems there were a bunch of changes during that commit range dealing with interrupt handling and IO-APIC stuff which perhaps broke your particular setup?

You might try flipping some of the debug settings in the boot menu to see if anything changes the behavior.

[drcouzelis]

I'm not really sure what to test... Here's what I tried:

I installed the latest nightly build (hrev44182, 2012-05-18). I selected the boot option for "Disable IO-APIC". It had no effect.

After booting Haiku, I killed the media server. I then started the media server from a Terminal window, which had this output:

AddOnManager::_RegisterAddOn(): trying to load "/boot/system/add-ons/media/plugins/ffmpeg"
AddOnManager::_RegisterReader, name ffmpeg
AddOnManager::_RegisterDecoder, name ffmpeg
FireWireCard opening /dev/bus/fw/0
BMediaRoster::InstantiateDormantNode: addon-id 4, flavor_id 0, flags 0x0
QueryPort: write_port failed, msgcode 0x52, port -444: Bad port ID
### BMediaRosterEx::LoadNodeConfiguration should load addon-id 4, flavor-id 0 config NOW!
BMediaEventLooper: SchedulingLatency is 750
!!! BMediaRosterEx::InstantiateDormantNode assigning team 289 as creator of node 2
Failed to open /dev/audio/hmulti/hda/0: No such device
fSettings       BMessage(0x0) {
}
started node 0
BMediaEventLooper: SchedulingLatency is 750
BMediaEventLooper: SchedulingLatency is 750
AddOnManager::_RegisterWriter, name ffmpeg
AddOnManager::_RegisterEncoder, name ffmpeg
AddOnManager::_RegisterAddOn(): trying to load "/boot/system/add-ons/media/plugins/raw_decoder"
AddOnManager::_RegisterDecoder, name raw_decoder

I will try anything else you recommend. Thank you.

[ttcoder]

I think umccullough is recommending to investigate more in low-level (kernel, interrupts..) areas since there were changes (and thus potential regressions) in there, by opposed to lack of changes in media_server...

Apart from looking at Media Prefs/settings/audio-input & output in both revisions, you could especially...

• try a fully "Safe" boot (i.e. select "Safe mode" boot, which will tick all the options, IO-APIC and others included), using 41539
• retrieve a syslog in 41539, and a syslog in 41505, to see what differs inbetween and confirm that e.g. the interrupt is correctly allocated in the older rev but fails in the newer rev (see Wiki for directions if not familiar with the syslog).

Good luck!

[drcouzelis]

syslog from a working system (hrev41373):

​http://pastebin.com/swL46Zs8

syslog from a non-working system (hrev44214):

​http://pastebin.com/cvNhLgyQ

Searching for "audio" and "Audio" will show the places in the syslogs where it loads / fails to load the sound card.

Thank you.

[ttcoder]

The (older) working rev says this:

KERN: HDA: Detected controller @ PCI:0:20:2, IRQ:5, type 1002/4383 (1458/a002)
(...)
KERN: hda: HDA v1.0, O:4/I:4/B:0, #SDO:1, 64bit:yes
KERN: Codec 3 Vendor: 10ec Product: 0888, Revision: 1.0.0.1

Whereas the (newer) rev fails like thus:

KERN: HDA: Detected controller @ PCI:0:20:2, IRQ:16, type 1002/4383 (1458/a002)
(...)
KERN: hda: HDA v1.0, O:4/I:4/B:0, #SDO:1, 64bit:yes
KERN: hda: Failed to get vendor and revision parameters

KERN: hda: no active codec

So the IRQs are allocated very differently. I suppose this explains the "failed to get vendor/rev parameters" message and subsequent failures (?).. Someone more knowledgable will have to chime in..

In the past I read here about a temporary workaround for such problems: removing drivers for devices that are active (and eating up an IRQ each) until finding the "sweet spot".. Maybe a new driver was introduced between revs, reorganizing your IRQs.. Or just the IO-APIC interrupt allocation algorithm..

This could help to then wait until a real (final) fix is found.

HTH

[diver]

Would be nice if you could compile Haiku yourself and find the exact revision when it happened.

[anevilyak]

Replying to ttcoder:

In the past I read here about a temporary workaround for such problems: removing drivers for devices that are active (and eating up an IRQ each) until finding the "sweet spot".. Maybe a new driver was introduced between revs, reorganizing your IRQs.. Or just the IO-APIC interrupt allocation algorithm..

Drivers make no difference, interrupt allocation is decided at one of two points: 1) at power-up by the BIOS, or 2) very early in the boot process during IO-APIC configuration, well before any driver's loaded. The drivers simply take what they're given. That having been said, IRQ16 is an IO-APIC interrupt, so the most likely cause for the issue here is the addition of IO-APIC support. Would be interesting to know if the card works properly with the latter disabled in the boot menu options.

[drcouzelis]

Drivers make no difference

Oh, thank goodness. I was trying to "disable" some drivers. All I accomplished was to make Haiku crash. :P

Would be interesting to know if the card works properly with IO-APIC support disabled

It doesn't make a difference. :(

Would be nice if you could compile Haiku yourself and find the exact revision when it happened.

If that will help then I'll do it. :) Unfortunately, it will take away from the precious time I have to work on my Haiku application. :/

[anevilyak]

Replying to drcouzelis:

If that will help then I'll do it. :) Unfortunately, it will take away from the precious time I have to work on my Haiku application. :/

With a range of only 34 revisions, it actually shouldn't take much to find it, git bisect will help you do it via binary search, which means it should only take log2(34) =~ 5 tests to find the culprit. Most of the changes in that range that seem possibly relevant are IO-APIC related though there also some SBx00-related bugfixes that might be causing it as well in your case.

[drcouzelis]

As was suggested, I started building hrev versions inbetween the official nightly builds where the bug was created. I'm afraid every build I tried (I tried four of them) failed with this error:

In file included from /BeDrive/haiku/headers/build/os/storage/NodeInfo.h:17,
                 from /BeDrive/haiku/headers/build/os/storage/AppFileInfo.h:12,
                 from /BeDrive/haiku/src/build/libbe/storage/mime/UpdateMimeInfoThread.cpp:17:
/BeDrive/haiku/headers/build/os/storage/Mime.h:34: `const uint32 B_MIME_STRING_TYPE' redeclared as different kind of symbol
/boot/develop/headers/os/support/TypeConstants.h:64: previous declaration of `enum {anonymous} B_MIME_STRING_TYPE'

I need to sleep now so I'll look into it more later. I'm posting the error here in case any of you recognize it and know why it's happening. ;)

More information:

I'm attempting to build Haiku from inside Haiku using these commands:

git tag hrev41520 # First build I tried
# The configure script was complaining about me having GCC 2.95.3-haiku-111122 instead of 100818, so I modified the configure script to accept 111122
./configure
jam -q @alpha-anyboot

The jam fails and the error above is displayed.

Thank you.

[drcouzelis]

Thanks to help from Oliver, I successfully built older versions until I found the build that caused the regression.

hrev41512 - Sound card works, shutdown works

hrev41513 - Sound card doesn't work, computer doesn't shutdown correctly

I'd be happy to test anything that you give me, either a modification to hrev41512 or the currently nightly build. This change appears to be related to ticket #8589. Thank you.

About building older versions of Haiku: For reference, here is what I did:

Get the Haiku source code:

git clone git://git.haiku-os.org/haiku

Change to the version, you want to compile. I compiled versions between hrev41505 and hrev41539.

git checkout hrev41505

Fix the "configure" script so it uses the version of GCC that comes with the latest nightly of Haiku.

haikuRequiredLegacyGCCVersion="2.95.3-haiku-111122"

Fix a bug in "headers/build/os/storage/Mime.h" by removing a duplicate declaration.

//static const uint32 B_MIME_STRING_TYPE    = 'MIMS';

Add special git tags in order to get the old "determine_haiku_revision" script to work correctly.

git tag -a -m dummy haiku/master.base hrev10
git tag -a -m dummy haiku/master.tip master

Configure and build Haiku.

./configure
jam -q haiku-cd

"haiku-cd.iso" will be created in the "generated" directory.

[drcouzelis]

I have a patch that will "fix" this bug.

I did a checkout with the latest Haiku source code, undid the changes from hrev41513, compiled, and tested it. Many issues were fixed:

• The sound card now works
• The shutdown error in ticket #8589 is now fixed
• A nasty boot bug is gone, where Haiku would only successfully finish booting about 25% of the time

The comment for the original change says it "Shouldn't matter much but maybe it helps on some chipsets to avoid interrupt storms during handover". Was the code before hrev41513 actually causing problems? Or, was this change only precautionary?

Of course, I would like hrev41513 to be reverted. ;) But, if you think it would be better to solve this bug another way then I can continue using my patched version of Haiku for now.

Anyway, I will attach the patch I made. It is VERY simple: It is the opposite of hrev41513.

Thank you.

[anevilyak]

Replying to drcouzelis:

The comment for the original change says it "Shouldn't matter much but maybe it helps on some chipsets to avoid interrupt storms during handover". Was the code before hrev41513 actually causing problems? Or, was this change only precautionary?

In short, yes. On some systems with a similar USB chipset, at the point of handover (aka handing control of the USB controller from the BIOS to Haiku), an interrupt storm (and consequently, system hang) would occur unless interrupts were disabled in the correct order, which is what this changeset was addressing. In your particular case this appears to have the opposite effect so this is likely a case where chipset-specific quirks will need to be used. It's unfortunately not quite as simple as reverting it since that will simply break it again for other people.

[tqh]

(In #8589) Same problem as #8588.

[tqh]

This problem is also causing shutdown to fail see duplicate in #8589.

[x-ist]

drcouzelis, the patch in #8987 is meant as a compromise between avoiding interrupt storms while enabling successful handover from SMM as described in the ticket. It could potentially resolve multiple tickets.

So, could you please test the patch (or the binary in ohci.zip) attached to #8987 and see if it works for you? Thanks is advance!

[drcouzelis]

I checked out the latest Haiku code (2012-10-05) and cleanly applied the patch you provided. The soundcard still didn't work. :(

...BUT then I tried the "ohci" file you provided. Then the soundcard DID work. :) Also, the ohci file you provided and my ohci file had really different sizes...

So, I think this is a good patch. I'll try compiling it again and report back with my results.

[drcouzelis]

Ok, I cleaned my Haiku sources, reapplied the patch, and rebuilt and your patch works fine. Sound works and power off works correctly. If your patch from #8987 is applied to Haiku then I would consider this bug and the power off bug to be resolved.

For your information, your compiled ohci file is 1215171 bytes and my ohci file is 92876 bytes.

Thank you so much for your work on Haiku!

[x-ist]

Replying to drcouzelis:

Ok, I cleaned my Haiku sources, reapplied the patch, and rebuilt and your patch works fine.

Yeah, that makes sense now, since the driver binary was compiled from the patch.

For your information, your compiled ohci file is 1215171 bytes and my ohci file is 92876 bytes.

My binary is a debug-built one, it contains additional debug information and more syslog traces. Your binary is a release-built one like from the nightlies. Hence the difference.

Thank you so much for your work on Haiku!

Thank you for testing! Hopefully other people can benefit from that too.

[korli]

Please check with hrev44689 or later.