Andre Robatino wrote:
Bob Chiodini wrote:I just verified that on my cleanly installed, fully updated, 32-bit SELinux-enabled i686 box, the kernel module is loaded automatically when booting kernel-2.6.21-1.3228.fc7, but not kernel-2.6.22.1-27.fc7. My father, who has a machine with the same properties but otherwise different hardware, has exactly the same problem. So there must be other people out there with the same problem and I'm at a loss as to why nobody else seems to have noticed it.Andre Robatino (arobatino) wrote:The pcspkr module is not automatically loaded anymore with the 2.6.22 module, though I can load it manually with "modprobe pcspkr". I filed the following as a kernel bug: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249124 [1] and noted that in the kernel update announcement was the following, which I don't understand:* Thu Jul 12 2007 Dave Jones - Replace the pcspkr private PIT lock by the global PIT lock toserialize the PIT access all over the place. Was the kernel the right component to file this under, or does some other package need to be modified to interact correctly with the kernel? Links: ------ [1] https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=249124Andre,PIT is programmable interval timer and is the clocking H/W that provides timing to the PC Speaker, among other things.I suspect that moving the code that locks the device for a specific user/use out of the pcspkr driver generalizes PIT locking for all users of the device not just the pcspkr driver. I doubt it had anything to do with the module not being loaded after the kernel update.What other packages were updated before you noticed the problem. Might be something to do with kudzu.Bob...
Andre,Check dmesg and /var/log/messages for errors related to the pcspkr module. Does /etc/sysconfig/hwconf reference pcspkr?
As a workaround put modprobe pcspkr in /etc/rc.modules. That is if F7 still supports rc.modules.
Bob...
