Public bug reported: 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... ** Affects: ubuntu Importance: Undecided Status: New -- System beep broken in Karmic despite heroic efforts to fix it https://bugs.launchpad.net/bugs/486154 You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
