pcspkr loaded, but no bell
Hi, if I turn on the computer, the PC buzzer does beep one time, so it does work for the POST, but the terminal (ROXTerm, with audible bell enabled) is silent, it doesn't beep anymore after using the Arch install from my old PC with my new PC. [rocketmouse@archlinux ~]$ lsmod | grep pcspkr pcspkr 16384 0 [rocketmouse@archlinux ~]$ printf "\abeep! \n" beep! The module is loaded, but nothing, no audible bell. I'm out of ideas. Maybe I'm unable to see the forest for the trees, I still suffer from the after-effects of a COVID infection I had a few days back. Is this a known issue with some new mobos? Am I missing something? Regards, Ralf
if I turn on the computer, the PC buzzer does beep one time, so it does work for the POST, but the terminal (ROXTerm, with audible bell enabled) is silent, it doesn't beep anymore after using the Arch install from my old PC with my new PC. […] For testing purposes instal the beep package and run `beep` from it.
On Wed, 2023-03-29 at 06:25 +0200, mpan wrote:
For testing purposes instal the beep package and run `beep` from it.
Hi, neither running beep as user, nor as root does produce audible sound. [rocketmouse@archlinux ~]$ beep beep: Error: Could not open any device [rocketmouse@archlinux ~]$ echo $? 1 [rocketmouse@archlinux ~]$ su Password: [root@archlinux rocketmouse]# beep [root@archlinux rocketmouse]# echo $? 0 [root@archlinux rocketmouse]# lsmod | grep pcspkr pcspkr 16384 0 In the meantime I noticed that the PC buzzer doesn't always work for the power-on self-test. I already sent two requests to esupport.gigabyte.com Germany. One request related to the PC buzzer issue and another, since activating CSM doesn't work. I'll report back. Regards, Ralf
PS: Still no sound: [rocketmouse@archlinux ~]$ beep -l300 -f750 --verbose --debug beep: Verbose: evdev: driver_detect 0x562c898210c0 (nil) beep: Verbose: lib: could not open(2) /dev/input/by-path/platform-pcspkr-event-spkr: Permission denied beep: Verbose: console: driver_detect 0x562c89820e60 (nil) beep: Verbose: lib: could not open(2) /dev/tty0: Permission denied beep: Verbose: lib: could not stat(2) /dev/vc/0: No such file or directory beep: Error: Could not open any device [rocketmouse@archlinux ~]$ sudo beep -l300 -f750 --verbose --debug [sudo] password for rocketmouse: beep: Error: Running as root under sudo, which is not supported for security reasons. beep: Error: Set up permissions for the pcspkr evdev device file and run as non-root user instead. [rocketmouse@archlinux ~]$ su Password: [root@archlinux rocketmouse]# beep -l300 -f750 --verbose --debug beep: Verbose: evdev: driver_detect 0x5629ee7cd0c0 (nil) beep: Verbose: lib: opened /dev/input/by-path/platform-pcspkr-event-spkr as fd=3 beep: Verbose: main: using evdev driver (fd=3, dev=/dev/input/by-path/platform-pcspkr-event-spkr) beep: Verbose: main: 1 times 300 ms beeps (100 ms delay between, 0 ms delay after) @ 750 Hz beep: Verbose: evdev: driver_begin_tone 0x5629ee7cd0c0 750 beep: Verbose: evdev: driver_end_tone 0x5629ee7cd0c0 beep: Verbose: evdev: driver_end_tone 0x5629ee7cd0c0 beep: Verbose: evdev: driver_fini 0x5629ee7cd0c0
Hi Ralf,
[rocketmouse@archlinux ~]$ beep -l300 -f750 --verbose --debug beep: Verbose: evdev: driver_detect 0x562c898210c0 (nil) beep: Verbose: lib: could not open(2) /dev/input/by-path/platform-pcspkr-event-spkr: Permission denied
As an aside, https://wiki.archlinux.org/title/PC_speaker#Installation says how to fix this.
[root@archlinux rocketmouse]# beep -l300 -f750 --verbose --debug beep: Verbose: evdev: driver_detect 0x5629ee7cd0c0 (nil) beep: Verbose: lib: opened /dev/input/by-path/platform-pcspkr-event-spkr as fd=3 beep: Verbose: main: using evdev driver (fd=3, dev=/dev/input/by-path/platform-pcspkr-event-spkr) beep: Verbose: main: 1 times 300 ms beeps (100 ms delay between, 0 ms delay after) @ 750 Hz beep: Verbose: evdev: driver_begin_tone 0x5629ee7cd0c0 750 beep: Verbose: evdev: driver_end_tone 0x5629ee7cd0c0 beep: Verbose: evdev: driver_end_tone 0x5629ee7cd0c0 beep: Verbose: evdev: driver_fini 0x5629ee7cd0c0
Is your sound system, e.g. ALSA, muting the speaker? See the above wiki link. -- Cheers, Ralph.
Hi Ralph, the Arch Linux install was used with a Gigabyte GA-B85M-D3H motherboard. Now the same install, on the same SSD is used by a Gigabyte B760 DS3H DDR4 (1.0) motherboard. Since 2015 I'm using the same alsa-base.conf: [rocketmouse@archlinux ~]$ /bin/ls -hl /etc/modprobe.d/alsa-base.conf; cat /etc/modprobe.d/alsa-base.conf -rw-r--r-- 1 root root 76 May 2 2015 /etc/modprobe.d/alsa-base.conf # ALSA module ordering options snd slots=snd_hdspm,snd_ice1712,snd_ice1712 My desktop is the window manager openbox, without a desktop environment. I'm either using plain alsa or jackd with the alsa backend. The snd_hdspm isn't plugged into the new mobo yet and no snd_ice1712 will be used with the new mobo at all. IOW at the moment only the crappy on-board audio device is available. After migrating from the old to the new mobo only one audio related file was edited: [rocketmouse@archlinux ~]$ cat .asoundrc; echo "# # # #"; cat .asoundrc_old defaults.pcm.card 3 defaults.pcm.device 3 # # # # defaults.pcm.card 3 defaults.pcm.device 7 [rocketmouse@archlinux ~]$ aplay -l | grep -e Analog -e HDMI\ 0 card 3: PCH [HDA Intel PCH], device 0: ALC897 Analog [ALC897 Analog] card 3: PCH [HDA Intel PCH], device 3: HDMI 0 [EV2450] If I launch [rocketmouse@archlinux ~]$ firefox https://www.youtube.com/watch?v=jC2ZY2loo74 >/dev/null 2>&1 I can listen to the music by my EIZO monitor's speakers using plain alsa. If I launch /usr/bin/jackd -dalsa -dhw:3,3 -r48000 -p256 -n2 or /usr/bin/jackd -dalsa -dhw:3,0 -r48000 -p256 -n2 by qjackctl, before I launch firefox, I can listen by the EIZO's speakers or by the computer's front panel headphones via jackd, with the alsa backend. If I run [rocketmouse@archlinux ~]$ alsamixer -Dhw:3 I cannot see anything related to the PC-Buzzer. There's an option named "Auto-Mut", likely for "Auto-Mute". It was enabled, but I disabled it. There's still no sound when (as root) running [root@archlinux rocketmouse]# printf "\a" [root@archlinux rocketmouse]# [root@archlinux rocketmouse]# beep -l300 -f750 --verbose --debug beep: Verbose: evdev: driver_detect 0x562bdb5890c0 (nil) beep: Verbose: lib: opened /dev/input/by-path/platform-pcspkr-event-spkr as fd=3 beep: Verbose: main: using evdev driver (fd=3, dev=/dev/input/by-path/platform-pcspkr-event-spkr) beep: Verbose: main: 1 times 300 ms beeps (100 ms delay between, 0 ms delay after) @ 750 Hz beep: Verbose: evdev: driver_begin_tone 0x562bdb5890c0 750 beep: Verbose: evdev: driver_end_tone 0x562bdb5890c0 beep: Verbose: evdev: driver_end_tone 0x562bdb5890c0 beep: Verbose: evdev: driver_fini 0x562bdb5890c0 With the old mobo " printf "\a" " always worked, independent from any alsamixer audio settings. The pcspkr module was and is always loaded. I'm using another kernel, than I used with the old mobo, but I seriously doubt that it's the culprit. I didn't get a final answer by Gigabyte support related to the beep issue. Meanwhile I noticed that the PC- Buzzer also fails often during the POST. I replied to a reply of the support with the following (translated from German to English (US) by https://www.deepl.com/de/translator : "Hello,yes I have tested with 3 different buzzers. All 3 buzzers work on power-on self-test (POST) with the old Gigabyte GA-B85M-D3H motherboard. POST has nothing at all to do with my Linux installations, it is a test done by your BIOS before anything else. If I plug the same buzzers one after the other into the new Gigabyte B760 DS3H DDR4 (1.0), a beep usually doesn't work. If I press the remove key after powering on to go into BIOS, then the beep usually works for that moment. Whenever it beeps, it does so only once, as it should. There are also no other problems during operation, the hardware seems to be ok.Kind regardsRalf Mardorf" "Remove key", a funny translation :D. I guess there is an issue with the motherboard's firmware, that is up-to-date. Only two releases are available, https://www.gigabyte.com/de/Motherboard/B760M-DS3H-DDR4-rev-10/support#suppo... . It was delivered with F1 from 2022.10.12. I didn't test the PC-Buzzer with this version. I updated to F3 from 2023.03.10, before I tested the PC-Buzzer. Regards, Ralf
On Wed, 2023-03-29 at 10:27 +0100, Ralph Corderoy wrote:
"More recent motherboard models omit the POST beep in favor of rapidly booting into the OS." I'll take a look at the used "boot speed". This mobo has got several options. I don't remember what option I selected. However, maybe there is a kind of "random speed" option, that let the Buzzer sometimes beep and sometimes not and in addition the pcspkr module might be obsolete. Maybe the Buzzer only can be used for the POST, but not by Linux anymore. Since CSM depends on the used GPU nothing seems to be too absurd to be impossible.
On Wed, 2023-03-29 at 21:31 +0200, Ralf Mardorf wrote:
On Wed, 2023-03-29 at 10:27 +0100, Ralph Corderoy wrote:
"More recent motherboard models omit the POST beep in favor of rapidly booting into the OS."
I'll take a look at the used "boot speed". This mobo has got several options. I don't remember what option I selected. However, maybe there is a kind of "random speed" option, that let the Buzzer sometimes beep and sometimes not and in addition the pcspkr module might be obsolete. Maybe the Buzzer only can be used for the POST, but not by Linux anymore. Since CSM depends on the used GPU nothing seems to be too absurd to be impossible.
Update: The BIOS provides an option named "Fast Boot". It provides 3 values, "Disable Link", "Enable" and "Ultra Fast". When the beep sometimes worked, but often didn't work, the selected value was "Enabled". After changing this value to "Disable Link" the beep seems to work always. The POST part of the issue is seemingly solved. The terminal part of the issue still isn't solved. There's still no sound when running " printf "\a" " as user or root. Running " beep " as root is also silent.
participants (3)
-
mpan
-
Ralf Mardorf
-
Ralph Corderoy