When I try to beep the PC speaker with "echo -e '\a'" or beep command, I hear only clicking sound coming from the PC speaker. It happens after changing motherboard to MSI PRO B760M-A WiFi. Both modules pcspkr and snd_pcsp give the same result. There is no problems with the hardware because speaker beeps fine in: - BIOS when enabled beep on boot; - GRUB with 'play' command; - DOS. Reproducible: Always Steps to Reproduce: 1. modprobe pcspkr (or "modprobe snd_pcsp") 2. echo -e '\a' (or "beep") Actual Results: Clicking sound coming from the PC speaker. Expected Results: Beep sound coming from the PC speaker. Current kernel version: 6.8.10-300.fc40.x86_64
Is this reproducible in the Linux console? E.g. Ctrl + Alt + F2 -> login -> echo -e '\a' (Press Alt + F1 to return back to your Xorg/Wayland session).
Yes, this can be reproduced in both the Linux console and Xorg.
Please try this: sudo rmmod snd_pcsp echo -e '\a'
Oh, and make sure pcspkr is loaded: sudo lsmod | grep pcspkr
> Please try this: > sudo rmmod snd_pcsp > echo -e '\a' Predictably, no sound at all. > Oh, and make sure pcspkr is loaded: > sudo lsmod | grep pcspkr With pcspkr there is the same clicking sound as with snd_pcsp.
I'd make same additional tests. 1. I wrote a program for Linux and DOS to start infinite 1 kHz beep by directly programming of PIT2 ports (0x43, 0x42, 0x61). It makes infinite beep under DOS. But it makes only one click on start under Linux. 2. One more program for Linux and DOS reads current PIT2 value (port 0x42). It gets random values from 0 to 1193 under DOS, that is a correct behavior during playing 1 kHz sound. But under Linux every time it returns a value 8 less than the previous one. So, PIT2 doesn't work possibly due to the lack of a reference frequency at the timer input. 3. Finally, I wrote grub-efi module that starts infinite 1 kHz beep. When loading a kernel, the sound is turned off even if the kernel is loaded without initrd and modules. Something early in the kernel boot process disrupts the normal operation of the 8254 timer. Please advise how to determine the part of the kernel that is causing the problem.
Created attachment 306415 [details] grub module source
Created attachment 306416 [details] Compiled grub-efi module
how about adding a boot dmesg and a sudo lspci -vvv ? (and I assume cat /proc/ioports as root shows timer0 at 0040-0043 ?)
Just a few notes: 1. IIRC the "beep" code of snd-pcsp is a direct copy/paste from pcspkr.c, Therefore no differences are expected. 2. There is an "nforce_wa" module parameter of snd-pcsp. Enabling it unbinds the driver from PIT2 entirely, so worth a try. But that only works for digital sound, because of (1). I.e. beep code remains PIT2-based. 3. Since we don't use PIT0 and its IRQ, its really surprising that something in an early kernel boot could "break" PIT2 (which is the only PIT used in both drivers). The only theory I can come up with (with a very good portion of imagination), is that PIT2 is SMM-assisted on your HW, and linux does some (likely ACPI-based) hand-off procedure and that SMM module goes away. This is not so impossible, knowing that nforce chipsets were lacking most of PIT modes 20 years ago already. Maybe now the modes were re-added via some SMM helper?
That said, non-acpi boot might be worth a try.
Created attachment 306457 [details] dmesg
Created attachment 306458 [details] lspci -vvv
(In reply to Dr. David Alan Gilbert from comment #9) > how about adding a boot dmesg and a sudo lspci -vvv ? > > (and I assume cat /proc/ioports as root shows timer0 at 0040-0043 ?) Yes, timer0 is present. 0000-0cf7 : PCI Bus 0000:00 0000-001f : dma1 0020-0021 : pic1 0040-0043 : timer0 0050-0053 : timer1 0060-0060 : keyboard 0064-0064 : keyboard 0070-0071 : rtc_cmos 0070-0071 : rtc0 0080-008f : dma page reg 00a0-00a1 : pic2 00c0-00df : dma2 00f0-00ff : fpu 0400-041f : iTCO_wdt 0400-041f : iTCO_wdt 0680-069f : pnp 00:01 0a00-0a0f : pnp 00:00 0a10-0a1f : pnp 00:00 0a20-0a2f : pnp 00:00 0a24-0a27 : nct6683 0a24-0a27 : nct6683 0cf8-0cff : PCI conf1 0d00-ffff : PCI Bus 0000:00 164e-164f : pnp 00:01 1800-1803 : ACPI PM1a_EVT_BLK 1804-1805 : ACPI PM1a_CNT_BLK 1808-180b : ACPI PM_TMR 1850-1850 : ACPI PM2_CNT_BLK 1854-1857 : pnp 00:02 1860-187f : ACPI GPE0_BLK 2000-20fe : pnp 00:04 3000-3fff : PCI Bus 0000:03 3000-30ff : 0000:03:00.0 4000-4fff : PCI Bus 0000:02 5000-5fff : PCI Bus 0000:01 5000-507f : 0000:01:00.0 6020-603f : 0000:00:17.0 6020-603f : ahci 6040-6043 : 0000:00:17.0 6040-6043 : ahci 6050-6057 : 0000:00:17.0 6050-6057 : ahci efa0-efbf : 0000:00:1f.4 efa0-efbf : i801_smbus
(In reply to Stas Sergeev from comment #11) > That said, non-acpi boot might be worth a try. When I boot kernel with acpi=off, the PC speaker works fine. But other problems appear: xorg session does not start, the computer freezes when rebooting or shutting down.
Then you need to re-assign this to acpi and reach out to some acpi experts.
I suggest (besides reaching the ACPI experts via an ML, as this bugzilla is usually unhelpful) to change the beep code in snd-pcsp to use hrtimer instead of PIT2, just as it is done for "nforce_wa". This is a 20-minutes work that gives you a functional setup at least with 1 driver of 2.