linux-hotplug.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: "Peter Møller Neergaard" <peter@mollerneergaard.net>
To: linux-hotplug@vger.kernel.org
Subject: cardmgr and hotplug interplay
Date: Fri, 27 Sep 2002 21:49:46 +0000	[thread overview]
Message-ID: <marc-linux-hotplug-103316376119993@msgid-missing> (raw)

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

             reply	other threads:[~2002-09-27 21:49 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-09-27 21:49 Peter Møller Neergaard [this message]
2002-09-29  1:29 ` cardmgr and hotplug interplay David Brownell
2002-09-30 17:15 ` dhinds

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-hotplug-103316376119993@msgid-missing \
    --to=peter@mollerneergaard.net \
    --cc=linux-hotplug@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).