potential pitfall? changing configuration while PC in hibernate

potential pitfall? changing configuration while PC in hibernate

[Arioch]

[-- 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 --]

Re: potential pitfall? changing configuration while PC in hibernate

[Pavel Machek]

[-- Attachment #1: Type: text/plain, Size: 511 bytes --]

On Po 21-03-05 11:02:04, Arioch wrote:
> 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 ?

Current position is "don't do this". You *will* be able to recover by
passing noresume, but if you change hw configuration, it may crash&burn.
									Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: potential pitfall? changing configuration while PC in hibernate

[Arioch]

[-- Attachment #1: Type: text/plain, Size: 356 bytes --]

Pavel Machek пишет:

> Current position is "don't do this".

:-(

It seems to be quite normal behaviour on notebooks with USB, PCMCIA, etc
I wish such scenarios be supported in the general design scheme, leaving 
it without certain implementing code maybe :-)

So that once someone will want to implement it, he will not need to 
re-design



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: potential pitfall? changing configuration while PC in hibernate

[Alan Stern]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1383 bytes --]

On Mon, 21 Mar 2005, Arioch wrote:

> 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.

This specific case -- plugging in a new USB device while the system is 
asleep -- will be handled correctly.  In fact, it will be handled exactly 
the same as if you had plugged in the device after waking up the system.

Alan Stern


[-- Attachment #2: Type: text/plain, Size: 0 bytes --]

Re: potential pitfall? changing configuration while PC in hibernate

[David Brownell]

[-- Attachment #1: Type: text/plain, Size: 706 bytes --]

On Monday 21 March 2005 1:52 am, Pavel Machek wrote:
> On Po 21-03-05 11:02:04, Arioch wrote:
> > 
> > I wonder, if hardware configuration asked for changes when resuming from 
> > hibernate ?
> 
> Current position is "don't do this". You *will* be able to recover by
> passing noresume, but if you change hw configuration, it may crash&burn.

That may be Pavel's position, but USB-wise we absolutely consider
it a bug if Linux misbehaves in the face of routine actions like
unplugging a device during suspend (or plugging in a new one).
Regardless of "noresume" etc.

I'd say that's true for all hotpluggable busses, in fact, but I
rarely submit patches for non-USB ones like PCMCIA or CardBus.

- Dave



[-- Attachment #2: Type: text/plain, Size: 0 bytes --]