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 damaged? > >> 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 empty. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/20100704183334.gk12...@yun.yagibdah.de