cardmgr and hotplug interplay
First a great thank you for doing a big effort to make my favorite operation system workable in the field. I know that I might be balancing on the wrong side of the line with respect to netiquette. However, after I been through both the documentation for pcmcia-cs and for linux-hotplug, I'm still confused about what to expect about them working together. So though this is not about developing either of the packages, I hope that asking the developers of both packages (thus the cross-posting) might help me get it straight. If that seems offensive to anybody, I apologize for abusing the lists.
My situation is as follows: I have a laptop where I so far have been using it with a wireless LAN card which is administrated by pcmcia-cs (cardmgr). I have just brought an ieee1394 (firewire) cardbus card and using that with the laptop I became aware of hotplug.
When I insert the ieee1394 is correctly detected by the hotplug system which uses /etc/hotplug/pci.agent to load the kernel modules (ohci1394 and ieee1394) for the ieee1394 (well, actually it loads all pci-modules due to the restrictions of /usr/bin/pcimodules. This is reflected as follow in the syslog
Sep 27 17:15:58 pan kernel: cs: cb_alloc(bus 7): vendor 0x104c, device 0x8019 Sep 27 17:15:58 pan kernel: PCI: Enabling device 07:00.0 (0000 -> 0002) Sep 27 17:15:58 pan kernel: PCI: Setting latency timer of device 07:00.0 to 64 Sep 27 17:15:58 pan kernel: ohci1394_2: OHCI-1394 1.0 (PCI): IRQ=[11] MMIO=[f50 00000-f5000800] Max Packet=[2048] Sep 27 17:15:58 pan /etc/hotplug/pci.agent: pcimodules is scanning more than .. . Sep 27 17:15:58 pan /etc/hotplug/pci.agent: Setup ohci1394 3c59x i810_audio usb- uhci for PCI slot 07:00.0 Sep 27 17:15:58 pan /etc/hotplug/pci.agent: ... blacklisted module: usb-uhci
cardmgr recognizes that card is inserted by writing
socket 1: CardBus hotplug device
on the console, but it never executes the script /etc/pcmcia/ieee1394 though I would expect if from the following parts of the /etc/pcmcia/config file
...
device "ohci1394_cb"
class "ieee1394" module "ohci1394"
...
card "Cherri IEEE-1394"
pci 0x104c, 0x8019
bind "ohci1394_cb"...
I presume this behavior is what is meant by the last sentence of ``Likewise, Cardbus/PCI configuration may sometimes be handled by pcmcia_cs tools; current versions pcmcia tools defer to PCI hotplug agents.'' from the PCI page of linux-hotplug's webspace.
When I remove the card, it is again hotplug's PCI system that take of the removal, though not very gracefully:
Sep 27 17:23:54 pan kernel: cs: cb_free(bus 7) Sep 27 17:23:54 pan /etc/hotplug/pci.agent: PCI remove event not supported
so basically nothing is done (as one would also expect from /etc/hotplug/pci.agent). I don't get any messages from cardmgr. To complete the picture ohci1394 also generates some error messages, but I take that it just a bug/feature of the driver not prepared for losing it's hardware.
Sep 27 17:23:53 pan kernel: ohci1394_2: Unrecoverable error, shutting down card! Sep 27 17:23:53 pan kernel: ohci1394_2: Runaway loop while stopping context... Sep 27 17:23:53 pan kernel: Attempt to kill tasklet from interrupt Sep 27 17:23:53 pan kernel: ohci1394_2: Runaway loop while stopping context... Sep 27 17:23:53 pan kernel: ohci1394_2: Runaway loop while stopping context... Sep 27 17:23:53 pan kernel: Attempt to kill tasklet from interrupt
So at this point I have two questions concerning how these packages are supposed to work together:
1) Is the above behavior indeed correct, i.e., that since hotplug knows the device, cardmgr steps down and does nothing.
2) I have all respect for the work that the hotplug developers has put into the hotplug system. But it appears that cardmgr still provides a better handling of the cardbus cards (I haven't tried, but I assume that it would be capable of removing the driver afterwards). Is there a way letting it not try to handle cardbus cards?
I appreciate any feedback.
Peter
Signature · 14 lines
http://www.linearity.org/turtle/contact.html ``When you have had all the experiences, met all the famous people, made some money, toured the world and got all the acclaim you still think--is that it? Some might be satisfied--but I wasn't'' -- G. Harrison ------------------------------------------------------- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf _______________________________________________ Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net [email protected] https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Hi,
Quoted 3 lines
However, after I been through both the documentation for pcmcia-cs and for linux-hotplug, I'm still confused about what to expect about them working together. ...
The last time this came up, the expectation was that for 2.4 'cardmgr' would handle the ISA style cards (non-PCI), and hotplugging would handle CardBus ones (standard PCI hotplugging).
Plus, someone threatened to teach the kernel how to hotplug those non-PCI devices. As of 2.5.39 that might come almost for free when they get merged into the driver model framework, but I don't know how much of that has gotten started (or what happens then with cardmgr and related tools).
Quoted 10 lines
My situation is as follows: I have a laptop where I so far have been using it with a wireless LAN card which is administrated by pcmcia-cs (cardmgr). I have just brought an ieee1394 (firewire) cardbus card and using that with the laptop I became aware of hotplug.
When I insert the ieee1394 is correctly detected by the hotplug system which uses
/etc/hotplug/pci.agentto load the kernel modules (ohci1394 and ieee1394) for the ieee1394 (well, actually it loads all pci-modules due to the restrictions of/usr/bin/pcimodules. This is reflected as follow in the syslog
You can disable 'pcimodules' (mv !$ !$-) if that bothers you, but you'd need to plug things in again after boot to have everything take notice. Of course a patch to 'pcimodules' would be good too ... :)
Quoted 5 lines
cardmgr recognizes that card is inserted by writing
socket 1: CardBus hotplug device
on the console, but it never executes the script
/etc/pcmcia/ieee1394
Right: normal PCI hotplugging is used, so instead the script /etc/hotplug/pci/ieee1394 gets run (if it's present).
Quoted 5 lines
When I remove the card, it is again hotplug's PCI system that take of the removal, though not very gracefully:
Sep 27 17:23:54 pan kernel: cs: cb_free(bus 7) Sep 27 17:23:54 pan /etc/hotplug/pci.agent: PCI remove event not supported
Right, there's this little problem where there's no reliable way to know when a module is really no longer needed. The kernel module system doesn't pay attention to whether or not the driver is bound to a device ... only whether it's got a nonzero refcount, and that usually happens only when some application opens a file to access that driver. Since modutils will happily remove drivers for devices you haven't yet opened, it's really not practical to ask it to ever remove drivers.
As I recall things, cardmgr is tracking this issue for the (one or two...) PCMCIA drivers it loads. Some of the module changes in 2.5 should IMO include fixes so that driver unload can work reasonably ... it's not quite clear to me what's happening there.
Quoted 5 lines
so basically nothing is done (as one would also expect from
/etc/hotplug/pci.agent). I don't get any messages from cardmgr. To complete the picture ohci1394 also generates some error messages, but I take that it just a bug/feature of the driver not prepared for losing it's hardware.
Yes. I had to teach the EHCI driver about that. It turns out that it's almost guaranteed that if the hardware gets removed, PCI reads will return all-ones. So every place that firewire driver accesses the device registers, it should check ... and be prepared to clean up. You have all the equipment you need to generate a patch for that!
Quoted 4 lines
So at this point I have two questions concerning how these packages are supposed to work together:
1) Is the above behavior indeed correct, i.e., that since hotplug knows the device, cardmgr steps down and does nothing.
That's certainly what I expect to happen.
Quoted 6 lines
2) I have all respect for the work that the hotplug developers has put into the hotplug system. But it appears that cardmgr still provides a better handling of the cardbus cards (I haven't tried, but I assume that it would be capable of removing the driver afterwards). Is there a way letting it not try to handle cardbus cards?
I wouldn't know, but keep in mind that if you go that route you're suddenly in the business of maintaining lots of entries in that /etc/pcmcia/config file that are exactly in sync with all the MODULE_DEVICE_TABLE entries in the PCI drivers ... most of which are part of the kernel distribution, not the pcmcia package. That doesn't sound very much "better"! :)
I believe that once the module remove issues go away, hotplug can make the 'rmmod' calls it currently avoids making. Meanwhile, the cost of having such modules around is pretty minor, and you can always 'rmmod' by hand ... you've got to be smarter than rmmod about whether all the driver's hardware is really gone!
- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel
Quoted 8 lines · David Brownell
Quoted 4 lines
However, after I been through both the documentation for pcmcia-cs and for linux-hotplug, I'm still confused about what to expect about them working together. ...
The last time this came up, the expectation was that for 2.4 'cardmgr' would handle the ISA style cards (non-PCI), and hotplugging would handle CardBus ones (standard PCI hotplugging).
That is correct.
Quoted 4 lines
As I recall things, cardmgr is tracking this issue for the (one or two...) PCMCIA drivers it loads. Some of the module changes in 2.5 should IMO include fixes so that driver unload can work reasonably ... it's not quite clear to me what's happening there.
Yes, the PCMCIA subsystem (and cardmgr) keep track of the number of devices bound to a driver, so drivers are unloaded when there are no longer any bound devices.
Quoted 7 lines
Quoted 6 lines
2) I have all respect for the work that the hotplug developers has put into the hotplug system. But it appears that cardmgr still provides a better handling of the cardbus cards (I haven't tried, but I assume that it would be capable of removing the driver afterwards). Is there a way letting it not try to handle cardbus cards?
Quoted 6 lines
I wouldn't know, but keep in mind that if you go that route you're suddenly in the business of maintaining lots of entries in that
/etc/pcmcia/configfile that are exactly in sync with all theMODULE_DEVICE_TABLEentries in the PCI drivers ... most of which are part of the kernel distribution, not the pcmcia package. That doesn't sound very much "better"! :)
It also isn't better (won't work) because cardmgr really only knows how to manage drivers properly if they use the PCMCIA driver API. It will try to load other modules if you tell it to, but when those modules don't register themselves as PCMCIA drivers, it gets confused.
-- Dave
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
Linux-hotplug-devel mailing list http://linux-hotplug.sourceforge.net
[email protected]
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel