Bug 249124

  I noticed that in the new kernel update announcement is the following, which I
don't understand.  Is this a bug in the kernel or in another package?

* Thu Jul 12 2007 Dave Jones <davej redhat com>
- Replace the pcspkr private PIT lock by the global PIT lock to
  serialize the PIT access all over the place.

  Still not loaded automatically with kernel-2.6.22.1-33.fc7.  I verified
earlier that it was loaded when booting kernel-2.6.21-1.3228.fc7, so no other
package update is responsible.  Also noticed that there is no explicit pcspkr
section in /etc/sysconfig/hwconf when booting 2.6.22 anymore, like there was in
2.6.21 (though as mentioned earlier, manually loading it still works).

  No change with kernel-2.6.22.1-41.fc7.

Agree completely.  Its something that was introduced in all the 2.6.22 kernels
as its stopped since they were out.

  This bug also exists in F8test1 (running off the Gnome LiveCD), with exactly
the same behavior, in kernel-2.6.23-0.61.rc1.git9.fc8.  Should it be reported as
a separate bug, or should this one be reclassified?

*** Bug 251205 has been marked as a duplicate of this bug. ***

Some additional info:
Updating the kernel separately by executing 'yum install kmod-nvidia', which
pulls in the new kernel and initrd as dependencies, leaves the pcspkr
functionality intact. However executing 'yum update udev' results in the file
/etc/sysconfig/modules/udev-stw.modules being overwritten and pcspkr no longer
loads on boot. The problem therefore appears to be in udev rather than in the
kernel proper.

  I don't understand - I tried downgrading to the original udev-106-4.fc7 and
rebooting, and the problem persists.  The contents of the original
/etc/sysconfig/modules/udev-stw.modules are

#!/bin/sh
for i in loop nvram floppy parport lp snd-powermac sonypi;do
        modprobe $i >/dev/null 2>&1
done

which appear not to have anything to do with pcspkr.  Can you explain in more
detail, since I don't understand how udev works at all?  If you are correct,
I'll reassign to udev.

It must be something to do with the the udev rules. I have not checked these as
generally I don't mess about too much in there as it's a bit dangerous. I just
reported some experimentation to try an refine where the problem is. 

In /etc/udev/rules.d/ the only rules file that mentions pcspkr is
60-persistent-input-rules and the relevant section is:

# other devices
DRIVERS=="pcspkr", ENV{ID_CLASS}="spkr"
DRIVERS=="atkbd", ENV{ID_CLASS}="kbd"
DRIVERS=="psmouse", ENV{ID_CLASS}="mouse"
ATTRS{name}=="*dvb*|*DVB*|* IR *", ENV{ID_CLASS}="ir"
ATTRS{modalias}=="input:*-*a[068],*|input:*-*a*,[68],*m*",
ATTRS{modalias}!="input:*-*k*14A,*r*", ENV{ID_
CLASS}="joystick"

But looking further it appears as if there is no link or path to pcspkr. There
is certainly no symlink or path defined in 50-udev.rules where nvram etc are
defined. I am rather reluctant to downgrade udev to the earlier release as I'm
afraid I might break something else.

  I still can't say I'm convinced, since when I first experienced the problem,
it happened when booting 2.6.22 but not 2.6.21 (which I no longer have, though
it would be possible to install the original kernel-2.6.21-1.3194.fc7).  And
there WAS that reference to a change in the kernel involving pcspkr in comment 1
above.  I haven't manually customized any of the udev files so for me, it was a
simple

rpm -Uvh --oldpackage udev-106-4.fc7.i386.rpm

and later "yum update" to get back to the original state.

I don't know Andre. I was merely reporting what I did. We know that 'modprobe -a
pcspkr' works fine and that if we force a probe in
/etc/sysconfig/modules/udev-stw.modules then the module loads correctly. That
means that the kernel hooks for the device must be present otherwise it would
not work at all. The relevant part of the modprobe man page states

Note that this version of modprobe does not do anything to the module itself:
the  work of resolving symbols and understanding parameters is done inside the
kernel. So module failure is sometimes accompanied by a kernel message: see
dmesg(8).

If I look in dmesg it reports pcspkr as being loaded successfully rather than
indicating an error.

In view of this I think the problem is elsewhere rather than in the kernel itself.

  OK, I'm changing the component to udev.  I know that udev has caused a number
of problems recently and that some of them were at first mistakenly thought to
be kernel-related.  There has been no response so far from the kernel
maintainer, so if the udev maintainer wants to bounce it back that would at
least give some feedback as to where the problem is.

  Still broken with

kernel-2.6.22.5-76.fc7
udev-113-12.fc7

  The bug still exists in F8t2.  Should the bug version be changed from F7 to devel?

No as it still exists in F7 and that was what this bug was lodged for.  To
change it to devel simply means it no longer exists in F7 which is not true. 
File a second devel bug with reference to this bug.

  Filed bug #292031 under devel.

We still don't even know if any of the developers have accepted this as a bug
yet. Is there anything more they need from us? Admittedly it is low priority and
an easy workaround is available but it would be nice to get at least some
confirmation.

  I've also filed it as bug #292221 for FC6.

I still think it needs to be changed back to the kernel.  Regardless of what
udev version, how come you load an old kernel and the pc speaker works?

There have been so many issues with the new kernel.  Firstly all manner of usb
initialisation issues that all occurred.

All the issues seem resolved in the kernel now except for the pcspeaker.

  I agree, the udev in FC6 was last updated 15-Jan-2007 so must not have had any
of the F7 issues, and the same behavior of working in the older kernels and not
the new ones is observed.  I'll change all 3 bugs back to the kernel.

  Still broken with

kernel-2.6.22.7-85.fc7
udev-113-12.fc7

  Still broken with

kernel-2.6.23.1-10.fc7
udev-113-12.fc7

  Still broken with

kernel-2.6.23.1-21.fc7
udev-113-12.fc7

Upstream commit 43cc71eed1250755986da4c0f9898f9a635cb3bf should fix this; will
merge in the next update cycle

In 2.6.23.1-28

Works in FC8 (32-bit x86) with kernel version 2.6.23.1-49.fc8 & udev version
116-3.fc8.

  I still have my script to load the pcspkr module manually and neglected to
test it with the latest kernel.  I disabled it and will check at reboot to make
sure, but based on where the PC speaker message appears in dmesg, it appears you
are probably right and it loaded automatically this time with my fully updated
32-bit F8.

  Rebooting with my manual "modprobe pcspkr" disabled verifies that this is
fixed in a fully updated 32-bit F8.

Works in kernel version 2.6.23.8-63.fc8 (x86 32-bit) with udev 116-3.fc8.

Works in kernel version 2.6.23.9-85.fc8 (x86 32-bit) with udev 116-3.fc8