Bug 218918

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.