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

Re: suspend to disk unreliable?

On Sun, Jul 04, 2010 at 04:42:46PM +0000, Camaleón wrote:
> On Sun, 04 Jul 2010 18:02:47 +0200, lee wrote:
> > On Sat, Jul 03, 2010 at 04:00:57PM +0000, Camaleón wrote:
> >> Then you can setup a chrooted environment and make the tests in there.
> >> Or you can try with a LiveCD to avoid data loss. Nowadays you have many
> >> choices to test hibernation in a safe environment.
> > 
> > There's nothing save about turning off and on the hardware many times
> > consecutively. I could disconnect the disks to minimize the risks, but
> > then it won't be possible to test suspend to disk.
> 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.

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

> 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

> >> If developers are not aware of your situation, they cannot correct the
> >> bugs
> > 
> > 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?

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

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

> >> > No manufacturer or dealer is going to give you a certificate that the
> >> > car in question will perform as desired under your particular
> >> > driving/using conditions.
> >> 
> >> Sure they do!
> > 
> > They don't --- or can you show me the certificate you got for your car
> > and a number of others other ppl got?
> Read on...
> <http://www.google.com/webhp?hl=en#hl=en&q=car+warranty+voided&fp=849006b7ea50a009>

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?

> >> >> >> What "required tools" are you referring to?
> >> >> > 
> >> >> > the tools needed for graphics cards
> >> >> 
> >> >> There no such tools. What you usually have to do when the graphics
> >> >> card driver (or any other driver) has problems to resume from
> >> >> hibernating is creating a hook to load/unload the required driver,
> >> >> that should be all.
> >> > 
> >> > The documentation says that there are. Perhaps what you're describing
> >> > is what these tools do ...
> >> 
> >> If the docs say that "there are", it will also say "where to get" them
> >> >:-)
> > 
> > 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.".

> 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

Reply to: