cardmgr and hotplug interplay

cardmgr and hotplug interplay

[Peter Møller Neergaard]

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
-- 
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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: cardmgr and hotplug interplay

[David Brownell]

Hi,

> 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).


> 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

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 ... :)


> 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).

> 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.


> 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!


> 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.


> 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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel

Re: cardmgr and hotplug interplay

[dhinds]

On Sat, Sep 28, 2002 at 06:29:57PM -0700, David Brownell wrote:
> 
> >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.

> 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.

> >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"!  :)

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
Linux-hotplug-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-hotplug-devel