From: Thomas Hood <jdthood@mail.com>
To: linux-kernel@vger.kernel.org
Subject: Re: USB not processing APM suspend event properly?
Date: Wed, 12 Dec 2001 18:40:26 -0500 [thread overview]
Message-ID: <1008200427.1134.29.camel@thanatos> (raw)
> This was caused by the PCMCIA network interface being
> off, and the apmd scripts trying to fuser -k and
> unmount an in-use NFS partition, which in turn wanted
> to generate NFS traffic to the server over the shut
> down PCMCIA network interface...
So your problem was that PCMCIA got shut down too early.
> Basically, I've changed the order that things happen on
> suspend, such that we always pass the event to apmd, and
> any other listeners on /dev/apm_bios. Once everyone has
> replied (subject to the rules of course), it then sends
> the PM_SUSPEND to the devices.
I suppose that the reason why it is presently coded as
it is is that the drivers can veto the suspend whereas
the "listeners" can't, and the apm driver wants to tell
the listeners about the event only if it isn't vetoed.
With your change, the apm driver really should ignore
a veto from the drivers since it has already told the
listeners about the event. Therefore, while your patch
is an improvement, it still isn't the whole solution.
One possible solution is for the apm driver first to _ask_
the device drivers whether a suspend is allowed; then
to tell the listeners; then to tell the device drivers
to suspend. This solution could be implemented by adding
the "ask" function to each driver with pm support. The
driver's opportunity to veto the suspend would be when
it is asked, not when it is told to suspend.
> The original code sent PM_SUSPEND on receiving the original
> request, and then multiple times each time a listener on
> /dev/apm_bios replied. Not good if apmd wants to unmount
> NFS, and your NFS mounts require traffic over your PCMCIA
> ether card!
Actually, it's not true that the original code sends PM_SUSPEND
each time a listener on /dev/apm_bios replies. The code
fragment is:
if (as->suspends_read > 0) {
as->suspends_read--;
as->suspends_pending--;
suspends_pending--;
} else if (!send_event(APM_USER_SUSPEND))
return -EAGAIN;
else
queue_event(APM_USER_SUSPEND, as);
This only calls send_event() if the ioctl(suspend) is NOT a
reply to a notification that was earlier read from the queue.
next reply other threads:[~2001-12-12 23:39 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-12-12 23:40 Thomas Hood [this message]
2001-12-12 23:49 ` USB not processing APM suspend event properly? Russell King
-- strict thread matches above, loose matches on Subject: below --
2001-12-13 1:03 Thomas Hood
2001-12-13 10:36 ` Russell King
2001-12-13 14:10 ` Thomas Hood
2001-12-12 22:15 Thomas Hood
2001-12-12 22:41 ` Alan Cox
2001-12-12 22:49 ` Russell King
2001-12-09 23:31 Thomas Hood
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=1008200427.1134.29.camel@thanatos \
--to=jdthood@mail.com \
--cc=linux-kernel@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