Comment 0 for bug 486154

In a fully up-to-date AMD64 Karmic on an MSI MS-7511 aka a K9N2G Neo-FD motherboard
(2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:05:01 UTC 2009 x86_64 GNU/Linux):

I -know- my hardware works, but I cannot get the motherboard-based system beep to work at all. I also know that lots of effort was expended in Karmic to silence the motherboard beep, but it went overboard---it is now apparently broken completely, and some of us need it. (This machine almost never has any speakers plugged into it---I depend absolutely on the onboard system beep to work, so don't waste your breath if your advice is to "just" use the audio-out jack and externally-powered speakers---this is absolutely a regression!)

My test cases: both in and outside of X (e.g., booted normally, or booted directly into single-user mode): echo -e '\a' in bash, or echo -n '\007' in tcsh, or ^G in Emacs, or Rubout at an empty line in gnome-terminal and/or the X-less shell. Nothing.

I -know- this hardware works:
(a) Tried booting from a 6.06 LiveCD. All of the above tests work just fine.
(b) Installed "beep" with synaptic. Beep itself works (showing that my hardware is good -and- that the kernel can talk to it), although apparently event0 isn't where my internal speaker is---I have to use beep -e /dev/input/by-path/platform-pcspkr-event-spkr and -then- the command beeps. (That's actually a symlink to event5 for some reason on this motherboard.

Here are all the things I did to try to fix this; what's left? (This is not necessarily the exact order I tried things in, and there were multiple logouts and/or reboots to make sure old values weren't cached and that new values were sticking.)

Commented-out the blacklisting of pcskpr in /etc/modprobe.d/blacklist.conf and did modprobe pcspkr. lsmod shows pcspkr there, and a reboot shows it still there.

Went into alsamixer, raised Beep to 100%, and unmuted it.

Made sure that "Terminal bell" in the profile for my gnome-terminal is checked. (Also tried unchecking it, from a report elsewhere that claimed the checkbox worked backwards from appearances.)

Did xset q and noticed that the bell percent was 0. Did xset b 100 and now it's at 100.

Tried xset b 100 1000 100 to change the default pitch from 400 to 1000; no effect.

Did sudo gconf-editor and drilled down to desktop -> gnome -> peripherals -> keyboard and changed bell_mode from off to on.

(Jeez, how many different places did they stab at to try kill the bell?)

I've also read through about a dozen threads on launchpad where people were complaining about how to turn the bell -off-, as well as http://ubuntuforums.org/tags.php?tag=bell.

I'm suspicious that beep required an explicit path because event0 wasn't the bell---could this lead to any of these symptoms?

It's obvious (since it doesn't work in single-user mode either) that X or Gnome or gnome-terminal aren't implicated, but I'd tried all of those before just trying single-user. And, of course, the 6.06 LiveCD shows this is absolutely a regression---if a 3.5-year-old release works just fine on this 1-year-old hardware, I'd expect the current one to do so as well.

Alternatively---is there any way of forcing "beep -e /dev/...." to be called in all instances when the system would otherwise be trying to use the system bell, e.g., when backspacing to empty lines, when echo or Emacs want to emit ^G, etc etc? That would be a gross kluge, but at least it would leave me with a bell that worked in most of the cases I care about...