[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: suspend to disk unreliable?

On Sun, 04 Jul 2010 20:33:34 +0200, lee wrote:

> On Sun, Jul 04, 2010 at 04:42:46PM +0000, Camaleón wrote:

>> You cannot disconnect the main disk because hibernation saves the image
>> of the running system there (unless you manually change the location).
> Sure I can disconnect the disks. But as I said, I won't be able to test
> suspending to disk then.

How are you testing hibernation with hard disks turned-off?

>> But again, if you want to safely test hibernation on your system, go
>> with a LiveCD
> And save the image on the live CD when suspending to disk?

I tested that way (from Debian LiveCD) before installing Debian into the 
hard disk. As LiveCD loses any configuration after shutdown, I just 
hibernated the machine day by day... and, hey, you know what? It worked 
like a charm.
>> or install Debian into an old disk connected via USB. There you can
>> make any test you want without worring about losing your data.
> I don't have an old disk I could use for this. And what about the rest
> of the hardware? Disconnect or remove that as well so that it can't be
> damaged?

I am starting to think that you do not really want to have hibernation 
working on your machine :-/

>> > Still filing bug reports doesn't seem to achieve anything these days.
>> I think that is a bad attitude,
> It's only my experience. What would that have to do with attitude?

A bad attitude is saying: "It won't be fixed, I do not report". Do not 
care about the result, just do your job.
>> No sir. I'm afraid you still are not getting the inners of how
>> hibernation works.
> When hardware doesn't work and it's still under warranty, I return it.
> That doesn't have to do anything with suspending to disk.

So do I. I'm not following you here.

No one is saying your hardware is bad but that you have to put some 
interest in making things to work.

>> When testing hibernation you are not testing a piece of hardware
>> "separately" but a complete system (drivers, programs, hardware,
>> kernel, DE tools...). Hardware can perform and work nice but not
>> drivers, and the manufacturer has not provided you with any driver for
>> that hardware.
> It's still something that should work out of the box.

How? The manufacturer has tested the hardware under different conditions 
(windows OS, mainly) and you are not using a windows system, aren't you? 
Manufacturer cannot know (because the product is "windows certified") how 
the hardware behaves under that condition, I mean, running in a Linux 

>> Read on...
>> <http://www.google.com/webhp?hl=en#hl=en&q=car+warranty
> Where's your certificate showing that your car is certified to perform
> flawlessly under your particular driving conditions? And where are such
> certifactes of other car owners?

Yes, it is there. Read your own car's manual/guarantee policy and you'll 
>> > Yet you say there are no such tools.
>> No, I say that I dunno about any special tool for vga.
> See above, you said "There are no such tools.".

That is my understanding.

>> Just tell me where in the docs it says there are tools for graphic
>> cards, besides the hook scripts I told you before that are used in
>> hibernation/resume operations.
> see /usr/share/doc/uswsusp/README
> As sid before, the directories where the hook scripts would be are
> empty.

That "hooks" were the ones I told you... and there are none. Okay, so you 
have to write your own hooks or open a bug report for that package 
telling exactly that: there are no script hooks included in the package.



Reply to: