"Also sprach Debian Bug Tracking System:"
> The script only has one purpose, and that is to load the bridge module
> (yenta_socket in this case). That's why it doesn't do anything if the module
> is
> already loaded. The "stop" action is not meaningful for this script.
>
> Come to think of it, this script should probably be removed anyway. It mostly
> exist for backwards-compatibility purposes.
>
> > FATAL: Module yenta_socket is in use.
> >
> > Probably some kernel threads. How does one close them down, then?
> >
> > |-2*[pccardd]
> >
> > A rmmod -f kills the threads happily.
>
> I think you can use "pccardctl eject" to free up the resources first.
It doesn't seem to stop the kernel threads.
Anyway, the following works for me as far as removing the modules via
pcmciautils stop goes. That means that a start reloads the wole system
and thereby finds my pcmcia cards, even without udev (no, I don't
particularly know why).
Of course this is far too dangerous to actually DO worldwide. But you
may want to at least try and get the kernel threads stopped somehow on
demand by registering a bug against something.
stop)
/sbin/pccardctl eject
sleep 1
while true; do
dep=`moddeps $PCIC` || break
[ -n "$dep" ] || break
/sbin/rmmod -f $dep || break
sleep 1
done
while true; do
dep=`moddeps pcmcia_core` || break
[ -n "$dep" ] || break
/sbin/modprobe -r $dep || break
sleep 1
done
;;
and
#
# print out ONE of the leaf dependent modules of the given module,
# if there are any at all to print out. Fail otherwise. Use in
# a loop with rmmod until no more to rmmod remain, at which point
# the target module and all that it was supporting will have been
# vamooshed from the kernel. This is a tail recursion so it could
# be redone as a loop. It's left, depth-first on the module tree
# traversal.
#
moddeps() {
local basemod="$1"
if ! /sbin/lsmod | grep -q ^"$basemod " ; then
return 1
fi
local deps=`/sbin/lsmod | grep ^"$basemod " | awk '{ print $4 }'`
if [ -z "$deps" ]; then
echo "$basemod"
return 0
fi
ifs="$IFS"
IFS=","
set -- $deps
IFS="$ifs"
basemod="$1"
moddeps "$basemod"
}
That really should be some kind of modprobe builtin functionality.
Maybe it is!
> > Would you mind tweaking this setup so it breaks nicely? It is NOT
> > acceptable to say "use udev", IMO. I don't. And I'm a person. I don't
> > take orders.
>
> You don't have to use udev, but you can't expect your configuration to be
> supported. As I said, the init script only loads the bridge module - you can
> simply put the module in /etc/modules to have it loaded at boot.
The problem is that without udev, apparently the whole pcmcia system
needs to be loaded "for a first time" in order to detect the pcmcia cards
and get to the point where an ident shows something. Otherwise one
just can go blue in the face with eject and insert with nothing ever
showing up, and no reason for it not showing up ever appearing.
The above modification to the pcmciautils init script at least gives
it a useful and expected functionality. In the first place, I expect
a script to undo whatever it did at start, when one runs stop. In
the second place I expect "restart" to really give me a fresh start
from a clean slate for the subsystem in question.
I agree that removing the script would satisfy my expectations :). But
it would remove a useful functionality too .. that of being able to
reinitialise the pcmcia system.
And if anyone could explain to me how pcmcia is supposed to work
nowadays, that would be great! I found a PCMCIA HOWTO for 2.6 kernels
on the net, and it is a start in the right direction. Certainly it
gives me a few ideas.
Thank you.
Peter
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
