Bug 56736 - NIS/NFS/PCMCIA/APM don't cooperate nicely
Summary: NIS/NFS/PCMCIA/APM don't cooperate nicely
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: apmd   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Bernhard Rosenkraenzer
QA Contact: Aaron Brown
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-26 17:46 UTC by Adam Spiers
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-01-24 22:55:50 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Adam Spiers 2001-11-26 17:46:52 UTC
I use NIS and NFS on my laptop via a PCMCIA ethernet card.
This causes great difficulties:

Firstly, '/etc/rc.d/init.d/pcmcia start' gets run too late.
The default chkconfig startup priority is 45, but netfs'
is 25 and ypbind's is 27.  Obviously it needs to be run earlier,
so I changed it to 20 and rebuilt the symlinks with chkconfig.

But that doesn't work either!  When invoked with the argument
'start', /etc/rc.d/init.d/pcmcia finishes before cardmgr has
completed its work.  This means that '/etc/rc.d/init.d/netfs start'
gets run quick enough afterwards that eth0 is still not ready.
I added a 'sleep 10' to the end of /etc/rc.d/init.d/pcmcia startup,
but that's a nasty hack.  It would be better to make the script
wait until cardmgr is finished, just like
/etc/sysconfig/apm-scripts/apmscript does if the
PCMCIAWAIT option is enabled (except that doesn't work either,
see bug #56718).  In fact if you did this it would remove the 
need for the PCMCIAWAIT stuff which would fix that bug at the
same time.

Finally, when I do an APM suspend via 'apm -s',
correctly invokes /etc/rc.d/init.d/netfs stop, but it just
hangs on the 'umount -f -t nfs -a' bit.  This is really weird,
because if I run

  /etc/sysconfig/apm-scripts/apmscript suspend user

from the command-line, it all works fine.  The only difference
I can think of is that the former case happens after the kernel
apm has received a suspend signal, whereas in the latter case
the kernel doesn't receive one.  That suggests a kernel bug?
It happens all kernels I've tried since 2.4.14.  The stock
RedHat 2.4.7 kernel just hangs completely when I suspend.I compiled with
CONFIG_APM_ALLOW_INTS, but also tried with
options apm allow_ints=0 in /etc/modules.conf.
Would be really grateful for any suggestions.  All I want to
do is to be able to close my laptop's lid :-(

This is all on an IBM ThinkPad 390E, for what it's worth.

Comment 1 Adam Spiers 2001-11-26 21:11:00 UTC
Upon further investigation, the umount hangs because something
has already suspended all PCMCIA cards.  I have no idea what that
something is, or how to stop it suspending them.  Setting the
undocumented do_apm=0 option to pcmcia_core.o doesn't help, nor
does recompiling the userspace utilities (cardmgr etc.) with
CONFIG_PM=n, despite the documentation implying it might.  I quote:

  Whether or not APM is configured, you can use ``cardctl suspend''
  before suspending your laptop, and ``cardctl resume'' after resuming,
  to cleanly shut down and restart your PCMCIA cards.
I'm beginning to lose my mind over this ... %-(

Comment 2 Bernhard Rosenkraenzer 2002-02-26 17:53:19 UTC
 This should work better with 3.0.2-6 (still not perfect, pcmcia is still started after 
network because some people insist it's the correct thing to do). 

Note You need to log in before you can comment on or make changes to this bug.