Red Hat Bugzilla – Full Text Bug Listing
|Summary:||Load PNP stuff during boot|
|Product:||[Fedora] Fedora||Reporter:||Pierre Ossman <pierre-bugzilla>|
|Component:||udev||Assignee:||Harald Hoyer <harald>|
|Status:||CLOSED RAWHIDE||QA Contact:|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2007-01-29 09:42:07 EST||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Pierre Ossman 2005-01-27 17:03:10 EST
Since the new policy (with FC3) seems to be that all required modules should be loaded at startup and not as needed (which I suppose is a problem with udev), then it would be nice if all required modules are actually loaded =) What is missing is the PNP stuff. The id:s can be extracted from /sys/bus/pnp/devices/*/id and converted into a string that associates with a module. Since a lot of hardware still only can be found using PNP (ACPI PNP primarly on laptops with lots of LPC connected devices), this is a greatly missed function.
Comment 1 Bill Nottingham 2005-01-27 23:34:40 EST
Got a brief example of such a driver?
Comment 2 Pierre Ossman 2005-01-28 02:26:44 EST
The problem in my case is my own driver :) It is a SD/MMC card reader connected to the LPC bus. Currently there exists only two ways to detect this chip: 1. Scan for the chip by issuing commands to ports it should be located on and see if you get expected results. 2. Trigger on the PNP info in the ACPI DSDT. So solution 2 is the one that "just works". The first requires that the user has some idea about what hardware he has (which rarely is specified) and knows what driver to use. The driver in question is 'wbsd' and is included in 2.6.10 and forward. PNP support isn't added to the main line yet, but will be as soon as I'm confident that all the bugs are out. This is only one example. From what I can tell, the parallell port needs a similar solution and probably also serial ports. Basically anything connected to the LPC bus.
Comment 3 Bill Nottingham 2005-01-28 02:42:34 EST
Hm... those sorts of PNP ids aren't exported by modules anywhere, so there's no way to know what to load. Unless I'm missing something.
Comment 4 Pierre Ossman 2005-01-28 03:16:33 EST
Actually they are. The device here has id WEC0517. This gets generated by the kernel build system to an alias pnp:dWEC0517* which can be modprobe:d. On your system you can do a 'modinfo parport_pc' and observe the PNP aliases at the two last entries.
Comment 5 Bill Nottingham 2005-01-28 16:58:26 EST
That *should* already get picked up, then. Hm. The kernel wouldn't have happend to have changed what fields the devices in /sys/devices/pnpX/XX.X export, would it?
Comment 6 Pierre Ossman 2005-01-28 18:56:21 EST
It contains the same information, i.e. a file 'id' with the PNP id. Should this be picked up by kmodule then or by some other part of the system?
Comment 7 Bill Nottingham 2005-01-28 23:05:35 EST
OK, the code is currently set up for ISA PNP. Which has different fields. I suppose I need to find a box that has both.
Comment 8 Pierre Ossman 2005-05-10 08:52:24 EDT
Could you give some pointers to which pieces of code are of interest here. That way I could look deeper into it myself. Currently I haven't got a clue how the magic works. :)
Comment 9 Bill Nottingham 2005-05-10 12:29:43 EDT
kudzu/isapnp.c is the code in question.
Comment 10 Pierre Ossman 2005-05-10 16:01:24 EDT
Problem solved. ACPIPNP does not have the card abstraction that ISAPNP has. So it would seem that devices get placed (in ACPIPNP) where cards would be places with ISAPNP. I.e. /sys/devices/pnp0/* in ACPIPNP is equivalent to /sys/devices/pnp0/*/* in ISAPNP. This means that the name and card_id fields can be empty in the kudzu device. I hope all software can handle this.
Comment 11 Pierre Ossman 2005-05-10 16:05:10 EDT
Created attachment 114223 [details] ACPIPNP patch This patch makes the probe function first check if there is an 'id' file in the device root. If so then that id is used to create a kudzu device. Otherwise normal ISAPNP probing continues. This should be backwards compatible, but I don't have an ISAPNP machine to test it on. It makes kmodule find my parallell port and SD card reader so it solves my problem.
Comment 12 Bill Nottingham 2005-05-10 16:13:09 EDT
Unfortunately, I don't have my isapnp test box any more either. :/ What's the output of 'kudzu -p -b isapnp' with this patch for you?
Comment 13 Pierre Ossman 2005-05-10 16:35:37 EDT
Created attachment 114224 [details] kudzu -p -b isapnp With an unpatched kudzu there is no output. The attached file contains the output of the patched kudzu.
Comment 14 Bill Nottingham 2005-05-10 16:43:41 EDT
Ugh, 'compat' is a multi-line string there for one device? That's bound to break something.
Comment 15 Pierre Ossman 2005-05-10 16:54:55 EDT
Is that really something new? Or is ISAPNP restricted to one compatible id? Anyway, it's here now so it needs to be handled. Just keeping the first row is probably not a good approach since it will lose data. compat probably needs to be changed into an array. Since kudzu is statically linked, not dynamically, this shouldn't cause that much breakage. Any applications dependent on old structures will be found during the next recompile.
Comment 16 Bill Nottingham 2005-05-11 17:47:40 EDT
Created attachment 114261 [details] patch that fixes multi-line compat Here's an updated patch that should handle the multi-line compat - does it work for you on your box still? (I had to hack the kernel driver to get a device with multiple compat entries. :) )
Comment 17 Pierre Ossman 2005-05-11 17:59:38 EDT
Works fine. The compat field is now a comma-separated list: class: UNSPEC bus: ISAPNP detached: 0 driver: unknown desc: "SYN0107" deviceId: SYN0107 compat: SYN0100,SYN0002,PNP0f13 The synaptic touchpad is in a lot of laptops so it shouldn't be that difficult to find a machine with this "feature" :)
Comment 18 Bill Nottingham 2005-05-11 18:02:20 EDT
Heh, just apparently not thinkpads. The paranoid person in me thinks this should probably be left for post-FC4; will apply then.
Comment 19 Pierre Ossman 2005-05-11 18:08:46 EDT
Just not too much after. I try to keep in sync with rawhide so it would be nice if it shows up there as soon as possible. :)
Comment 20 Bill Nottingham 2005-05-17 10:51:38 EDT
Added in CVS, will be in 0.1.117-1.
Comment 21 Bill Nottingham 2005-05-17 11:28:57 EDT
Comment 22 Pierre Ossman 2005-08-11 08:31:59 EDT
How about a rebuild of initscripts so that this change actually has an effect? ;)
Comment 23 Bill Nottingham 2005-08-19 02:15:29 EDT
Heh, thanks for the reminder. Will get to it in the next week or so.
Comment 24 Pierre Ossman 2006-01-07 14:17:54 EST
This is broken again. Since kmodule seems to be retired in favor of udev I guess it's a udev bug now.
Comment 25 Bill Nottingham 2006-01-09 13:28:18 EST
Yeah, popping over there. Is this stuff exporting modalias files? If not, this gets bumped to the kernel.
Comment 26 Pierre Ossman 2006-01-10 04:03:39 EST
Yup. I can find it in modules.isapnp: parport_pc 0xffff 0xffff 0x00000000 0xd041 0x0004 parport_pc 0xffff 0xffff 0x00000000 0xd041 0x0104 wbsd 0xffff 0xffff 0x00000000 0xa35c 0x1705 wbsd 0xffff 0xffff 0x00000000 0xa35c 0x1805 (wbsd is the one I really want loaded, it's for my card reader).
Comment 27 Bill Nottingham 2006-01-10 12:53:32 EST
That may not be the same thing ... does /sys/bus/pnp/devices/<whatever> have a modalias file?
Comment 28 Pierre Ossman 2006-01-10 13:54:51 EST
Not sure what you're referring to. The modules are present in modules.alias at least. And the mapping algorithm was discussed in previous comments in this bug.
Comment 29 Bill Nottingham 2006-01-10 14:11:36 EST
udev, at boot, looks for uevent files in sysfs, and uses those to retrigger device add events. If these events have a 'modalias', they should cause the modules to get loaded. Unless we don't have a rule for PNP addition of devices.... which we don't. Harald, perhaps we just need a generic: ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="/sbin/modprobe $modalias" to catch all subsystems? Pierre, if you add that udev rule, does it start working?
Comment 30 Pierre Ossman 2006-01-10 15:28:46 EST
Afraid not. To debug it I added the following: ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="/usr/bin/logger $modalias" But when I echoed 'add' to the relevant uevent file, nothing happened. So there might be a problem with the uevent triggering in the pnp layer.
Comment 31 Harald Hoyer 2006-01-11 10:32:12 EST
> does /sys/bus/pnp/devices/<whatever> have a modalias file? $ find /sys/bus/pnp/devices/ -name modalias
Comment 32 Pierre Ossman 2006-01-11 11:04:11 EST
~ [drzeus@poseidon]$ find /sys/bus/pnp/devices/ -name modalias ~ [drzeus@poseidon]$ OTOH: ~ [drzeus@poseidon]$ find /sys/bus/ -name modalias ~ [drzeus@poseidon]$ But 'find /sys/ -name modalias' finds some entries. None for PNP though.
Comment 33 Dave Jones 2006-02-27 02:47:39 EST
This is likely going to need quite a bit of work on the pnp layer, which should really happen upstream (firstname.lastname@example.org) by those familiar with it (and with the hardware to test).
Comment 34 Pierre Ossman 2006-03-12 13:11:18 EST
That route doesn't seem to be the correct one (according to Kay Sievers at least). Search LKML for "[PATCH] [PNP] 'modalias' sysfs export" if you want to see the entire thread. His final suggestion was to add this to the udev rules: SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id; done < /sys$devpath/id'" Reopening and moving to udev.
Comment 35 Pierre Ossman 2006-05-05 08:40:15 EDT
Ping! Any comment on Kay's suggestion?
Comment 36 Bill Nottingham 2006-05-05 11:13:45 EDT
IIRC, we tried that in <some other bug that I forget the name of> and it didn't work for those cases.
Comment 37 Bill Nottingham 2006-11-03 12:21:18 EST
So, in the short term, that suggestion would work for things like serial ports and parallel ports. It won't work for soundcards, though.
Comment 38 Pierre Ossman 2006-11-03 13:55:56 EST
That's still better than today where it doesn't work for anything.
Comment 39 Pierre Ossman 2007-01-29 09:57:29 EST
What was the applied solution and in which version of which package?
Comment 40 Harald Hoyer 2007-01-29 10:11:01 EST
ACTION=="add", SUBSYSTEM=="*", MODALIAS=="*", RUN+="modprobe $modalias" and SUBSYSTEM=="pnp", RUN+="/bin/sh -c 'while read id; do /sbin/modprobe pnp:d$$id; done < /sys$devpath/id'" since FC-6