{"id":222,"date":"2008-05-01T12:04:48","date_gmt":"2008-05-01T18:04:48","guid":{"rendered":"http:\/\/www.ourada.org\/blog\/?p=222"},"modified":"2008-05-01T12:04:48","modified_gmt":"2008-05-01T18:04:48","slug":"my-sound-back","status":"publish","type":"post","link":"https:\/\/www.ourada.org\/blog\/archives\/222","title":{"rendered":"My sound back"},"content":{"rendered":"

When I made the switch on my main desktop machine from Windows to Linux (I mean, a Linux kernel-based operating environment solution incorporating elements from FSF projects as well as thousands of other contributors, including but not limited to: Apache Software Foundation, Sun Microsystems Incorporated, the GNOME Foundation… ah, I mean, Linux), I lost my sound. I got it back by finding the main ‘kernel’ line in my \/boot\/grub\/menu.lst and adding the following kernel parameters to the end of that line:
\nnoisapnp pnpbios=off pnpacpi=off<\/code>
\nSo the whole line now looks like this:
\nkernel \/boot\/vmlinuz-2.6.24-16-generic root=UUID=... ro quiet splash noisapnp pnpbios=off pnpacpi=off
\n<\/code><\/p>\n

(Don’t copy that line exactly, though, if you’re going to try this solution. Just add those extra arguments to the end. I removed my disk UUID from the line because it’s specific to my computer and wouldn’t work for anyone else.)<\/p>\n

In more detail: I’m running the newly-published Ubuntu 8.04 ‘Hardy Heron’ distribution, which is currently using Linux kernel 2.6.24 as a base. This version of the kernel doesn’t work well with some BIOSes that report probably-incorrect information about some motherboard resources (some kernel-list discussion<\/a> in which Torvalds’ primary argument is ‘x is crap’, a PnP-quirks patch<\/a>, and there are about a million pages about people having this problem if you look hard enough).<\/p>\n

The eventual diagnosis centered around this in the kernel output (using the dmesg command to view it):<\/p>\n

PCI: Unable to reserve mem region #1:4000@febf8000 for device 0000:00:1b.0
\nACPI: PCI interrupt for device 0000:00:1b.0 disabled
\nHDA Intel: probe of 0000:00:1b.0 failed with error -16 <\/code><\/p>\n

This region couldn’t be reserved because it was already reserved, as a message like this shows (I’m copying this from someone else’s description of the problem, but the idea’s the same):
\nsystem 00:08: iomem range 0xfebfa000-0xfebfac00 has been reserved <\/code><\/p>\n

I also used the contents of \/proc\/iomem to shore up the diagnosis. Here’s the indicative bits:
\n
\nfebf8000-febfbfff : 0000:00:1b.0
\n febfa000-febfac00 : pnp 00:07
\nfebfe000-febfec00 : pnp 00:07
\n<\/code><\/p>\n

The part that snd_intel_hda wants overlaps with what pnp has already claimed. It ought to look like
\n
\nfebf8000-febfbfff : 0000:00:1b.0
\n febf8000-febfbfff : ICH HD audio
\n<\/code><\/p>\n

This overlap problem was happening on my ASUS P5B-Plus board, with two different BIOS versions (1002 and either 0903 or 1001). This board uses an Intel 82801H (ICH8 Family) HD Audio controller sound solution.<\/p>\n

Rather than patching and building the kernel myself or trying to find some .debs out there with a newer version (the patch is included in 2.6.25), either of which is more work than I’d like to do for this problem, I just turned off all PnP. The last time I cared about PnP (a hacky system devised to make PC configuration easier back in the days of the ISA bus, and if you don’t know what an ISA bus is, you can probably just nod and forget it) was more than 5 years ago, so this is no loss for me.<\/p>\n","protected":false},"excerpt":{"rendered":"

When I made the switch on my main desktop machine from Windows to Linux (I mean, a Linux kernel-based operating environment solution incorporating elements from FSF projects as well as thousands of other contributors, including but not limited to: Apache Software Foundation, Sun Microsystems Incorporated, the GNOME Foundation… ah, I mean, Linux), I lost my […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[3],"tags":[],"class_list":["post-222","post","type-post","status-publish","format-standard","hentry","category-general","author-admin"],"_links":{"self":[{"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/posts\/222","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/comments?post=222"}],"version-history":[{"count":0,"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/posts\/222\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/media?parent=222"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/categories?post=222"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.ourada.org\/blog\/wp-json\/wp\/v2\/tags?post=222"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}