Re: suspend to disk unreliable?
On Sat, 03 Jul 2010 16:11:03 +0200, lee wrote:
> On Thu, Jul 01, 2010 at 07:10:58PM +0000, Camaleón wrote:
>>
>> So... when something goes wrong, you need to debug it, whatever it is
>> (hibernation or something else). And debugging usually requires some
>> "sacrifices" >:-) (meaning, trial and error tests).
>
> Insofar such testing involves eventually losing data, doing such testing
> isn't really an option.
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.
>> But by following a "do-nothing" path you are losing some nice features
>> that hibernation provides and the worst here is that the problem your
>> are facing most sure could be easily bypassed by following a little
>> steps and requesting further info. BTS (Debian bug tracking system) is
>> your friend :-).
>
> Losing features like corrupting your filesystems? Filing bug reports
> doesn't seem to achieve anything these days.
Filling bug reports is the only way to go if you want to get hibernation
working with your current hardware and setup.
If developers are not aware of your situation, they cannot correct the
bugs neither giving you some tips to properly configure hibernation and/
or suspend in your machine. Doing nothing will keep the error in a
perpetual state, and only if you are lucky, it will be corrected in the
next release.
>> > There's the dealers selling the hardware and warranty on the
>> > hardware.
>>
>> No, sir. You maybe meesed Windows with Debian ;-)
>
> No, you're doing that. It's just hardware, and if it doesn't work, I
> return it. It's that simple.
No, it's not "just" hardware.
It's kernel, drivers, firmwares, and all the abstraction software that is
needed to handle power management (dbus, packagekit, DE tools et al...).
Power management is a compendium of many tools (besides the hardware
part) and all that tools has to syncronize nicely to get the system
hibernating and restoring without glitches or errors.
Is not that easy. In the event one of these elements fail to hibernate,
you will get problems. And as I already said, there are many pieces in
the puzzle.
Unless you bought a computer (a complete system) that is currently
certified for your concrete version of Debian, the manufacturer cannot
assure you a thing, it's all about trial and error, and not only for
hibernation :-/
Want kind of guarantee are you expecting from the manufacturer?
>> > Do you expect to behave a car as described above just because you buy
>> > it as is? Do you buy cars certified by the manufacturer to work
>> > reliably and to play nice with your specific using conditions?
>>
>> Sure, and if not, I will make some debug on the car ;-)
>
> 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!
Any piece of the car has been tested for performing in many types of
scenarios. In that way, you cannot go across mountains or under extreme
drive conditions with a non-SUV because is quite possible that you get
stuck in the middle of the road >:-)
> And who would buy a car that comes with a
> certificate that only the ppl named in the certificate are allowed to
> use it and that otherwise the car might break down and any warranty is
> forfeited?
Anyone here will :-)
>> I wish I had the same flexibility with a car than I currently have with
>> my computer systems... A car is a "turn-key" piece of hardware: as long
>> as you make any change you void the guarantee.
>
> The difference is that I bought my "car" in parts and put them together
> myself. When a part doesn't work, I return it under warranty.
I think you are getting how hibernation works wrong. There is no just
"one" piece of hardware that fails, but many. And it cannot be a hardware
failure but a software error. Again, it's not that easy. Hibernation is a
process which involves many things.
> You could do the same with cars --- it might involve some more trial
> and error testing, but I'm sure you won't mind that, all the less since
> it would give you all the flexibility you desire ;)
I wouldn't drive a car that has not been tested and certified by the
required "auctoritas" ;-)
But the sad fact is that there is no such "auctoritas" for hibernation,
so the only thing one can do when something is going wrong is testing and
report.
>> >> 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
>:-)
>> For instance, it's quite normal to lose the network connection after
>> resuming, so a hook for restarting networkmanager is sometimes
>> required.
>
> I have disabled starting networkmanager. It doesn't seem to have any use
> but rather seemed to mess around with network settings, or it spawned
> lots of processes, I don't remember. Obviously, it's not needed.
That service is not needed at all, but you still need the network service
and this one can be also get lost after restoring.
Greetings,
--
Camaleón
Reply to: