From: Phillip Susi <psusi@cfl.rr.com>
To: Alan Stern <stern@rowland.harvard.edu>
Cc: Kyle Moffett <mrmacman_g4@mac.com>,
Alon Bar-Lev <alon.barlev@gmail.com>,
Kernel development list <linux-kernel@vger.kernel.org>
Subject: Re: Flames over -- Re: Which is simpler?
Date: Sun, 12 Feb 2006 22:52:30 -0500 [thread overview]
Message-ID: <43F0027E.2070207@cfl.rr.com> (raw)
In-Reply-To: <Pine.LNX.4.44L0.0602122104330.20351-100000@netrider.rowland.org>
Alan Stern wrote:
>
> It's not just semantics. There's a real difference between maintaining
> state in the hardware and maintaining it somewhere else. The biggest
> difference is that if the hardware retains suspend power, it is able to
> detect disconnections. When the system resumes, it _knows_ whether a
> device was attached the entire time, as opposed to being unplugged and
> replugged (or possibly a different device plugged in!) while the system
> was asleep. If the hardware is down completely, there is no way of
> telling for certain whether a device attached to some port is the same one
> that was there when the system got suspended.
>
During suspend the hardware is usually completely powered off, and in
either case, there is nothing running on the CPU to monitor device
insertion/removal. When the system is resumed the kernel decides if the
hardware has changed the same way for either system: it probes the
hardware to see if it is still there. There isn't anything special that
monitors device insertion/removal while suspended to ram.
>> This is not true. The USB bus is shut down either way, and provided
>> that you have not unplugged the disk, nothing will be screwed when you
>> resume from disk or ram.
>
> Have you actually tried it? I have.
If it doesn't work then you have found a bug and should file a report.
The state of the kernel after resuming from either suspend to disk, or
suspend to ram is the same. The filesystem is still mounted, and any
dirty pages in ram will be flushed just like normal. Whether the disk
is connected via SCSI, SATA, USB, or whatever does not matter.
>
> In any case, it is undeniably true that if the bus is shut down then all
> the USB connections are lost. When you resume it will be the same as if
> you had unplugged all the USB devices and then replugged them. Not a good
> thing to do when they contain mounted filesystems; all the memory mappings
> are invalidated.
>
The kernel knows that the same device is still there on the bus, and so
it picks up right where it left off. If it thinks the device has been
unplugged and reconnected, that is a bug.
> (Bear in mind that whether a USB bus gets shut down depends on the
> motherboard; some supply suspend power and some don't. It depends on the
> USB controller too; some support low-power states other than "completely
> off" and others don't.)
>
> Alan Stern
>
next prev parent reply other threads:[~2006-02-13 3:52 UTC|newest]
Thread overview: 78+ messages / expand[flat|nested] mbox.gz Atom feed top
2006-02-12 16:57 Flames over -- Re: Which is simpler? Alan Stern
2006-02-13 0:51 ` Phillip Susi
2006-02-13 2:19 ` Alan Stern
2006-02-13 3:52 ` Phillip Susi [this message]
2006-02-13 5:43 ` Kyle Moffett
2006-02-13 16:40 ` Phillip Susi
2006-02-13 16:31 ` Alan Stern
2006-02-13 17:14 ` Phillip Susi
2006-02-13 20:04 ` Alan Stern
2006-02-13 20:38 ` Phillip Susi
2006-02-13 21:24 ` Alan Stern
2006-02-13 22:27 ` Rafael J. Wysocki
2006-02-14 19:26 ` Alan Stern
2006-02-14 20:41 ` Rafael J. Wysocki
2006-02-14 21:08 ` Lee Revell
2006-02-15 15:56 ` Alan Stern
2006-02-13 22:51 ` J. Bruce Fields
2006-02-13 23:47 ` Phillip Susi
2006-02-14 0:50 ` Kyle Moffett
2006-02-14 2:09 ` Phillip Susi
2006-02-14 4:09 ` Kyle Moffett
2006-02-14 4:28 ` Alan Stern
2006-02-14 5:11 ` Kyle Moffett
2006-02-14 15:33 ` Alan Stern
2006-02-14 6:27 ` Phillip Susi
2006-02-14 16:23 ` Kyle Moffett
2006-02-14 18:39 ` Phillip Susi
2006-02-14 19:55 ` Kyle Moffett
2006-02-14 21:13 ` Phillip Susi
2006-02-14 23:32 ` Kyle Moffett
2006-02-15 3:08 ` Phillip Susi
2006-02-14 19:14 ` Olivier Galibert
2006-02-14 19:37 ` Phillip Susi
2006-02-17 21:04 ` Pavel Machek
2006-02-18 16:34 ` Phillip Susi
2006-02-18 17:29 ` Pavel Machek
2006-02-19 5:52 ` Phillip Susi
2006-02-19 9:02 ` Pavel Machek
2006-02-19 16:35 ` Phillip Susi
2006-02-19 16:41 ` Alan Stern
2006-02-19 19:17 ` Phillip Susi
2006-02-19 19:43 ` Pavel Machek
2006-02-20 0:56 ` Olivier Galibert
2006-02-20 1:01 ` Pavel Machek
2006-02-20 1:26 ` Olivier Galibert
2006-02-20 4:04 ` Alan Stern
2006-02-19 20:16 ` Bernd Eckenfels
2006-02-18 21:04 ` Alan Stern
2006-02-19 0:02 ` Andrew Morton
2006-02-19 6:02 ` Phillip Susi
2006-02-19 6:32 ` Andrew Morton
2006-02-19 16:39 ` Phillip Susi
2006-02-19 16:54 ` Alan Stern
2006-02-19 20:02 ` Andrew Morton
2006-02-19 20:44 ` Oliver Neukum
2006-02-19 21:02 ` Andrew Morton
2006-02-20 6:55 ` Oliver Neukum
2006-02-20 7:29 ` Andrew Morton
2006-02-20 7:57 ` Andrew Morton
2006-02-14 14:15 ` hackmiester / Hunter Fuller
2006-02-15 23:51 ` Pavel Machek
2006-02-13 2:25 ` Kyle Moffett
-- strict thread matches above, loose matches on Subject: below --
2006-02-13 19:16 David Brownell
2006-02-13 20:08 ` Phillip Susi
2006-02-14 3:10 ` David Brownell
2006-02-14 6:05 ` Phillip Susi
2006-02-14 17:04 ` David Brownell
2006-02-15 23:43 ` Pavel Machek
2006-02-18 20:51 ` David Brownell
2006-02-19 6:06 ` Phillip Susi
2006-02-20 5:50 ` David Brownell
2006-02-20 16:07 ` Phillip Susi
2006-02-20 16:51 ` Olivier Galibert
2006-02-20 18:20 ` Phillip Susi
2006-02-20 18:44 ` Olivier Galibert
2006-02-20 21:45 ` Phillip Susi
2006-02-21 16:19 ` David Brownell
2006-02-21 18:30 ` Phillip Susi
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=43F0027E.2070207@cfl.rr.com \
--to=psusi@cfl.rr.com \
--cc=alon.barlev@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mrmacman_g4@mac.com \
--cc=stern@rowland.harvard.edu \
/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