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