With no other changes but a kernel upgrade, the pcspkr driver
doesn't load automatically anymore. No changes to that driver
jump out, so where else could the problem be? Something to
do with the device class changes maybe?
Chuck Ebbert wrote:
> With no other changes but a kernel upgrade, the pcspkr driver
> doesn't load automatically anymore. No changes to that driver
> jump out, so where else could the problem be? Something to
> do with the device class changes maybe?
This has long been a problem for me on Fedora, long before 2.6.22. I
would never ever have the glorious system beeps, unless I built the
module into my kernel.
I would look into distro areas and see why it's not getting loaded.
Jeff
On 08/07/2007 04:43 PM, Jeff Garzik wrote:
> Chuck Ebbert wrote:
>> With no other changes but a kernel upgrade, the pcspkr driver
>> doesn't load automatically anymore. No changes to that driver
>> jump out, so where else could the problem be? Something to
>> do with the device class changes maybe?
>
> This has long been a problem for me on Fedora, long before 2.6.22. I
> would never ever have the glorious system beeps, unless I built the
> module into my kernel.
>
> I would look into distro areas and see why it's not getting loaded.
>
Seems to be some kind of udev / hal magic loading it. With 2.6.20/21
it worked for most people, now it seems totally broken. Maybe we should
just load it unconditionally.
On 8/7/07, Chuck Ebbert <[email protected]> wrote:
> On 08/07/2007 04:43 PM, Jeff Garzik wrote:
> > Chuck Ebbert wrote:
> >> With no other changes but a kernel upgrade, the pcspkr driver
> >> doesn't load automatically anymore. No changes to that driver
> >> jump out, so where else could the problem be? Something to
> >> do with the device class changes maybe?
> >
> > This has long been a problem for me on Fedora, long before 2.6.22. I
> > would never ever have the glorious system beeps, unless I built the
> > module into my kernel.
> >
> > I would look into distro areas and see why it's not getting loaded.
> >
>
> Seems to be some kind of udev / hal magic loading it. With 2.6.20/21
> it worked for most people, now it seems totally broken. Maybe we should
> just load it unconditionally.
It doesn't have any aliases, so seems it was never autoloaded.
It's like mousedev, and should probably just be built-in.
Kay
Kay Sievers ([email protected]) said:
> It doesn't have any aliases, so seems it was never autoloaded.
It was - prior kernels loaded it via the uevent generated from
/devices/platform/pcspkr. Newer kernels seem to never actually
trigger a uevent from that (tested with a combination of
udevmonitor and 'udevtrigger --subsystem-match=platform'.)
Bill
On Wed, 2007-08-08 at 15:32 -0400, Bill Nottingham wrote:
> Kay Sievers ([email protected]) said:
> > It doesn't have any aliases, so seems it was never autoloaded.
>
> It was - prior kernels loaded it via the uevent generated from
> /devices/platform/pcspkr. Newer kernels seem to never actually
> trigger a uevent from that (tested with a combination of
> udevmonitor and 'udevtrigger --subsystem-match=platform'.)
Ah, ok, makes sense. Yeah, that weird "platform devices loads itself by
the name" thing got disabled in the platform subsystem. It caused
modprobe loops for other devices.
The whole idea of issuing MODALIAS with plain module names instead of
aliases can't really work, but the platform maintainer didn't like to
use the usual aliases and the matches in the modules, for a reason I
didn't understand while we talked about the problem last time.
Kay
Kay Sievers ([email protected]) said:
> Ah, ok, makes sense. Yeah, that weird "platform devices loads itself by
> the name" thing got disabled in the platform subsystem. It caused
> modprobe loops for other devices.
>
> The whole idea of issuing MODALIAS with plain module names instead of
> aliases can't really work, but the platform maintainer didn't like to
> use the usual aliases and the matches in the modules, for a reason I
> didn't understand while we talked about the problem last time.
So, the solution is for the platform device to issue a random modalias
that pcskpr exports?
Bill
On Wed, 2007-08-08 at 18:22 -0400, Bill Nottingham wrote:
> Kay Sievers ([email protected]) said:
> > Ah, ok, makes sense. Yeah, that weird "platform devices loads itself by
> > the name" thing got disabled in the platform subsystem. It caused
> > modprobe loops for other devices.
> >
> > The whole idea of issuing MODALIAS with plain module names instead of
> > aliases can't really work, but the platform maintainer didn't like to
> > use the usual aliases and the matches in the modules, for a reason I
> > didn't understand while we talked about the problem last time.
>
> So, the solution is for the platform device to issue a random modalias
> that pcskpr exports?
I would still like to see "MODALIAS=platform:<string>" exported by the
bus, and matching aliases the modules, just like every other subsystem
does.
Like SCSI, with the "artificial" aliases for the modules it wants to
autoload:
$ /sbin/modinfo sd_mod
...
alias: scsi:t-0x0e*
alias: scsi:t-0x07*
alias: scsi:t-0x00*
...
$ cat /sys/devices/pci0000:00/0000:00:1f.2/host0/target0:0:0/0:0:0:0/modalias
scsi:t-0x00
That way you would get full control over the loading or blacklisting
with module-init-tools config files, which doesn't work with direct
module name requests, and no magic in the bus code or the drivers would
be needed.
Kay
Hi,
On Wednesday 08 August 2007 15:32, Bill Nottingham wrote:
> Kay Sievers ([email protected]) said:
> > It doesn't have any aliases, so seems it was never autoloaded.
>
> It was - prior kernels loaded it via the uevent generated from
> /devices/platform/pcspkr. Newer kernels seem to never actually
> trigger a uevent from that (tested with a combination of
> udevmonitor and 'udevtrigger --subsystem-match=platform'.)
>
The patch below should restore generation of uevents for pcspkr devices.
Since devices are not created in pcspkr module but rather in arch setup
code it is right (and safe) thing to do.
--
Dmitry
pcspkr: restore uevent generation
Make sure that we generate uevents when creating pcspkr devices
so that userspace will load pcspkr driver.
Signed-off-by: Dmitry Torokhov <[email protected]>
---
arch/alpha/kernel/setup.c | 2 ++
arch/mips/kernel/pcspeaker.c | 2 ++
arch/powerpc/kernel/setup-common.c | 2 ++
arch/x86/kernel/pcspeaker.c | 2 ++
4 files changed, 8 insertions(+)
Index: work/arch/alpha/kernel/setup.c
===================================================================
--- work.orig/arch/alpha/kernel/setup.c
+++ work/arch/alpha/kernel/setup.c
@@ -1501,6 +1501,8 @@ static __init int add_pcspkr(void)
if (!pd)
return -ENOMEM;
+ pd->dev.uevent_suppress = 0;
+
ret = platform_device_add(pd);
if (ret)
platform_device_put(pd);
Index: work/arch/mips/kernel/pcspeaker.c
===================================================================
--- work.orig/arch/mips/kernel/pcspeaker.c
+++ work/arch/mips/kernel/pcspeaker.c
@@ -19,6 +19,8 @@ static __init int add_pcspkr(void)
if (!pd)
return -ENOMEM;
+ pd->dev.uevent_suppress = 0;
+
ret = platform_device_add(pd);
if (ret)
platform_device_put(pd);
Index: work/arch/powerpc/kernel/setup-common.c
===================================================================
--- work.orig/arch/powerpc/kernel/setup-common.c
+++ work/arch/powerpc/kernel/setup-common.c
@@ -454,6 +454,8 @@ static __init int add_pcspkr(void)
if (!pd)
return -ENOMEM;
+ pd->dev.uevent_suppress = 0;
+
ret = platform_device_add(pd);
if (ret)
platform_device_put(pd);
Index: work/arch/x86/kernel/pcspeaker.c
===================================================================
--- work.orig/arch/x86/kernel/pcspeaker.c
+++ work/arch/x86/kernel/pcspeaker.c
@@ -11,6 +11,8 @@ static __init int add_pcspkr(void)
if (!pd)
return -ENOMEM;
+ pd->dev.uevent_suppress = 0;
+
ret = platform_device_add(pd);
if (ret)
platform_device_put(pd);
On Sun, 2007-11-04 at 01:20 -0400, Dmitry Torokhov wrote:
> On Wednesday 08 August 2007 15:32, Bill Nottingham wrote:
> > Kay Sievers ([email protected]) said:
> > > It doesn't have any aliases, so seems it was never autoloaded.
> >
> > It was - prior kernels loaded it via the uevent generated from
> > /devices/platform/pcspkr. Newer kernels seem to never actually
> > trigger a uevent from that (tested with a combination of
> > udevmonitor and 'udevtrigger --subsystem-match=platform'.)
> >
>
> The patch below should restore generation of uevents for pcspkr devices.
> Since devices are not created in pcspkr module but rather in arch setup
> code it is right (and safe) thing to do.
This is not needed. The global disablement of platform device creation
events has been reverted in 2.6.24, it broke more than pcsprkr, and
modules that should be auto-loaded just get an alias as usual:
http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=43cc71eed1250755986da4c0f9898f9a635cb3bf
Thanks,
Kay