From: Arioch <the_Arioch-SYPjacQAEmk@public.gmane.org>
To: linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.org
Subject: potential pitfall? changing configuration while PC in hibernate
Date: Mon, 21 Mar 2005 11:02:04 +0300 [thread overview]
Message-ID: <d1lutv$iuj$1@sea.gmane.org> (raw)
[-- Attachment #1: Type: text/plain, Size: 2120 bytes --]
AS: where it counts, by hibernate i mean Suspend-to-disk, not
suspend-to-RAM.
I wonder, if hardware configuration asked for changes when resuming from
hibernate ?
I have a notebook with USB1 keyboard-and-hub (Cherry) and an USB2 Flash
drive.
Keyboard reports it can give 100 mA of current per-port.
USB disk reports it consumes 200 mA.
So de jure this disk is not to be turned on, or at least Linux is to ask
user if he wants to run this device, even he understands it is risky.
Ok, this question is not for Power-Management forum.
But i remember a couple of pitfalls i met on Windows and do not want to
see them in Linux.
When i plug this USB dirve into keyboard when Win2003 is running,
Windows rejects the device since it requests too much power.
But if i put Windows to hibernate, then plug the USB Drive and then
resume Windows - it forgets to check for power requirements and tunrs
device on (which is useful, but which is a bug :-) )
So i wonder if there are (planned) some measures to test for hardware
changes, why PC was hibernated.
Another pitfall was with Win2000 and old notebook (iP266MMX, 64 MB RAM).
I put Win2000 into hibernate.
Then i went to service and upgraded memory.
There was 32Mb onboard + 32Mb as SO-DIMM.
So i changed that module for 128Mb one, and tried to resume Windows
(yes, a dumb idea and i had to think beforehand - but what if i did not?)
And what i've got was a blocker.
When i resume Windows it usually allows me to enter Advanced options and
choose to kill hibernated session and to do a cold boot.
This time i just got an error message that RAM amount changed and resume
is not possible. If i did not try to resume Windows at the service
center, where i could ask my RAM back to shutdown windows - i would be
in a very hard situation :-)
IMHO correct behaviour then would be at least to allow user to make a
cold boot, and the most correct would be giving warning, but them
resuming and using only 64 MB of total new 160Mb RAM, untill reboot.
Yes, both this examples are quite perverted, but i hope Linux would be
able to couple even such pitfalls :-)
[-- Attachment #2: Type: text/plain, Size: 0 bytes --]
next reply other threads:[~2005-03-21 8:02 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2005-03-21 8:02 Arioch [this message]
2005-03-21 9:52 ` potential pitfall? changing configuration while PC in hibernate Pavel Machek
[not found] ` <20050321095229.GA28507-I/5MKhXcvmPrBKCeMvbIDA@public.gmane.org>
2005-03-21 10:49 ` Arioch
2005-03-21 18:22 ` David Brownell
2005-03-21 15:29 ` Alan Stern
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='d1lutv$iuj$1@sea.gmane.org' \
--to=the_arioch-sypjacqaemk@public.gmane.org \
--cc=linux-pm-qjLDD68F18O7TbgM5vRIOg@public.gmane.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