All of lore.kernel.org
 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.