Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.
Bug 249124
Summary: | pcspkr module not loaded automatically anymore with >= 2.6.22 kernel | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | Andre Robatino <robatino> |
Component: | kernel | Assignee: | Kernel Maintainer List <kernel-maint> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | low | Docs Contact: | |
Priority: | low | ||
Version: | 7 | CC: | cebbert, davej, goeran, hanpingtian, jamesbannon008, webmaster |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2007-12-21 21:50:03 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Andre Robatino
2007-07-21 02:04:31 UTC
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 |