Bug 249124 - pcspkr module not loaded automatically anymore with >= 2.6.22 kernel
pcspkr module not loaded automatically anymore with >= 2.6.22 kernel
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
: 251205 (view as bug list)
Depends On:
  Show dependency treegraph
Reported: 2007-07-20 22:04 EDT by Andre Robatino
Modified: 2007-12-21 16:50 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2007-12-21 16:50:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Andre Robatino 2007-07-20 22:04:31 EDT
Description of problem:
  Upon booting with the new kernel-, the pcspkr module is not
automatically loaded at boot time, though it can be loaded manually afterwards
with "modprobe pcspkr".

Version-Release number of selected component (if applicable):

How reproducible:
Comment 1 Andre Robatino 2007-07-22 05:11:46 EDT
  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.
Comment 2 Andre Robatino 2007-07-27 05:03:57 EDT
  Still not loaded automatically with kernel-  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).
Comment 3 Andre Robatino 2007-07-31 23:12:38 EDT
  No change with kernel-
Comment 4 David 2007-08-01 20:21:25 EDT
Agree completely.  Its something that was introduced in all the 2.6.22 kernels
as its stopped since they were out.
Comment 5 Andre Robatino 2007-08-07 20:46:44 EDT
  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?
Comment 6 James Bannon 2007-08-22 14:56:07 EDT
*** Bug 251205 has been marked as a duplicate of this bug. ***
Comment 7 James Bannon 2007-08-26 08:24:58 EDT
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.
Comment 8 Andre Robatino 2007-08-26 08:39:34 EDT
  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

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

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.
Comment 9 James Bannon 2007-08-26 09:02:15 EDT
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:*-*k*14A,*r*", ENV{ID_

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.
Comment 10 Andre Robatino 2007-08-26 09:14:43 EDT
  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

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

and later "yum update" to get back to the original state.
Comment 11 James Bannon 2007-08-26 09:28:39 EDT
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

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.
Comment 12 Andre Robatino 2007-08-26 09:35:35 EDT
  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.
Comment 13 Andre Robatino 2007-09-13 06:36:35 EDT
  Still broken with

Comment 14 Andre Robatino 2007-09-14 13:50:41 EDT
  The bug still exists in F8t2.  Should the bug version be changed from F7 to devel?
Comment 15 David 2007-09-15 02:31:53 EDT
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.
Comment 16 Andre Robatino 2007-09-15 08:23:32 EDT
  Filed bug #292031 under devel.
Comment 17 James Bannon 2007-09-15 15:46:20 EDT
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
Comment 18 Andre Robatino 2007-09-15 18:19:45 EDT
  I've also filed it as bug #292221 for FC6.
Comment 19 David 2007-09-15 18:23:53 EDT
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.
Comment 20 Andre Robatino 2007-09-15 18:29:14 EDT
  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.
Comment 21 Andre Robatino 2007-09-28 02:11:20 EDT
  Still broken with

Comment 22 Andre Robatino 2007-10-29 19:37:05 EDT
  Still broken with

Comment 23 Andre Robatino 2007-11-05 15:40:22 EST
  Still broken with

Comment 24 Chuck Ebbert 2007-11-05 15:52:47 EST
Upstream commit 43cc71eed1250755986da4c0f9898f9a635cb3bf should fix this; will
merge in the next update cycle
Comment 25 Chuck Ebbert 2007-11-13 17:17:46 EST
Comment 26 James Bannon 2007-11-26 10:28:27 EST
Works in FC8 (32-bit x86) with kernel version & udev version
Comment 27 Andre Robatino 2007-11-26 11:11:00 EST
  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.
Comment 28 Andre Robatino 2007-11-28 13:53:15 EST
  Rebooting with my manual "modprobe pcspkr" disabled verifies that this is
fixed in a fully updated 32-bit F8.
Comment 29 James Bannon 2007-12-09 20:06:07 EST
Works in kernel version (x86 32-bit) with udev 116-3.fc8.
Comment 30 James Bannon 2007-12-21 16:31:52 EST
Works in kernel version (x86 32-bit) with udev 116-3.fc8 

Note You need to log in before you can comment on or make changes to this bug.