[patch] suspend: update warnings

[patch] suspend: update warnings

[Pavel Machek]

Update suspend documentation. Warnings were a bit overstated, and did
not point out important stuff.

---
commit 790df7223ac29afec81e7201adc879973311f27e
tree 97fa2017f8f5aded0c44cfc75ba4903fbdb7f0a4
parent 63393fcbf056a6fd68142a49ed4e1258560dce2c
author <pavel@amd.(none)> Mon, 22 Aug 2005 10:13:51 +0200
committer <pavel@amd.(none)> Mon, 22 Aug 2005 10:13:51 +0200

 Documentation/power/swsusp.txt |   60 ++++++++++++++++++++++++++++++++--------
 Documentation/power/video.txt  |    9 +++++-
 2 files changed, 56 insertions(+), 13 deletions(-)

diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
--- a/Documentation/power/swsusp.txt
+++ b/Documentation/power/swsusp.txt
@@ -1,22 +1,20 @@
-From kernel/suspend.c:
+Some warnings, first.
 
  * BIG FAT WARNING *********************************************************
  *
- * If you have unsupported (*) devices using DMA...
- *				...say goodbye to your data.
- *
  * If you touch anything on disk between suspend and resume...
  *				...kiss your data goodbye.
  *
- * If your disk driver does not support suspend... (IDE does)
- *				...you'd better find out how to get along
- *				   without your data.
- *
- * If you change kernel command line between suspend and resume...
- *			        ...prepare for nasty fsck or worse.
+ * If you do resume from initrd after your filesystems are mounted...
+ *				...bye bye root partition.
+ *			[this is actually same case as above]
  *
- * If you change your hardware while system is suspended...
- *			        ...well, it was not good idea.
+ * If you have unsupported (*) devices using DMA, you may have some
+ * problems. If your disk driver does not support suspend... (IDE does),
+ * it may cause some problems, too. If you change kernel command line 
+ * between suspend and resume, it may do something wrong. If you change 
+ * your hardware while system is suspended... well, it was not good idea;
+ * but it wil probably only crash.
  *
  * (*) suspend/resume support is needed to make it safe.
 

-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] suspend: update warnings

[Jiri Slaby]

Pavel Machek napsal(a):

>+ * but it wil probably only crash.
>  
>
... it will ... :)

>  *
>  * (*) suspend/resume support is needed to make it safe.
>  
>

Re: [patch] suspend: update warnings

[Nigel Cunningham]

Hi.

On Mon, 2005-08-22 at 18:15, Pavel Machek wrote:
> Update suspend documentation. Warnings were a bit overstated, and did
> not point out important stuff.
> 
> ---
> commit 790df7223ac29afec81e7201adc879973311f27e
> tree 97fa2017f8f5aded0c44cfc75ba4903fbdb7f0a4
> parent 63393fcbf056a6fd68142a49ed4e1258560dce2c
> author <pavel@amd.(none)> Mon, 22 Aug 2005 10:13:51 +0200
> committer <pavel@amd.(none)> Mon, 22 Aug 2005 10:13:51 +0200
> 
>  Documentation/power/swsusp.txt |   60 ++++++++++++++++++++++++++++++++--------
>  Documentation/power/video.txt  |    9 +++++-
>  2 files changed, 56 insertions(+), 13 deletions(-)
> 
> diff --git a/Documentation/power/swsusp.txt b/Documentation/power/swsusp.txt
> --- a/Documentation/power/swsusp.txt
> +++ b/Documentation/power/swsusp.txt
> @@ -1,22 +1,20 @@
> -From kernel/suspend.c:
> +Some warnings, first.
>  
>   * BIG FAT WARNING *********************************************************
>   *
> - * If you have unsupported (*) devices using DMA...
> - *				...say goodbye to your data.
> - *
>   * If you touch anything on disk between suspend and resume...
>   *				...kiss your data goodbye.
>   *
> - * If your disk driver does not support suspend... (IDE does)
> - *				...you'd better find out how to get along
> - *				   without your data.
> - *
> - * If you change kernel command line between suspend and resume...
> - *			        ...prepare for nasty fsck or worse.
> + * If you do resume from initrd after your filesystems are mounted...
> + *				...bye bye root partition.
> + *			[this is actually same case as above]
>   *
> - * If you change your hardware while system is suspended...
> - *			        ...well, it was not good idea.
> + * If you have unsupported (*) devices using DMA, you may have some
> + * problems. If your disk driver does not support suspend... (IDE does),
> + * it may cause some problems, too. If you change kernel command line 
> + * between suspend and resume, it may do something wrong. If you change 
> + * your hardware while system is suspended... well, it was not good idea;
> + * but it wil probably only crash.

The most common driver issues I see involve:
- USB being built in or as modules that are still loaded while
suspending (getting better, but not there yet)
- DRI being used in X where the drivers don't properly support
suspend/resume (NVidia esp)
- Firewire
- CPU Freq  (improving too)

It might be good to mention these areas too.

Perhaps the 'changing your hardware' could mention that replacing faulty
hardware may be safe.

Regards,

Nigel

>   *
>   * (*) suspend/resume support is needed to make it safe.
>  
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Re: [patch] suspend: update warnings

[Pavel Machek]

Hi!

> > + * If you have unsupported (*) devices using DMA, you may have some
> > + * problems. If your disk driver does not support suspend... (IDE does),
> > + * it may cause some problems, too. If you change kernel command line 
> > + * between suspend and resume, it may do something wrong. If you change 
> > + * your hardware while system is suspended... well, it was not good idea;
> > + * but it wil probably only crash.
> 
> The most common driver issues I see involve:
> - USB being built in or as modules that are still loaded while
> suspending (getting better, but not there yet)
> - DRI being used in X where the drivers don't properly support
> suspend/resume (NVidia esp)
> - Firewire
> - CPU Freq  (improving too)
> 
> It might be good to mention these areas too.

Well, right; but those 'only' cause system to crash during suspend. I
was talking about really dangerous stuff.

Both usb and cpufreq seems to work okay here.

I've added FAQ entry at the end:

Q: What information is usefull for debugging suspend-to-disk problems?

A: Well, last messages on the screen are always useful. If something
is broken, it is usually some kernel driver, therefore trying with as
little as possible modules loaded helps a lot. I also prefer people to
suspend from console, preferably without X running. Booting with
init=/bin/bash, then swapon and starting suspend sequence manually
usually does the trick. Then it is good idea to try with latest
vanilla kernel.

"Known problematic" modules are; be sure to unload them before
suspend:
- DRI being used in X where the drivers don't properly support
suspend/resume (NVidia esp)
- Firewire
- SCSI


> Perhaps the 'changing your hardware' could mention that replacing faulty
> hardware may be safe.

I do not want to encourage people to do that. Yep, its probably safe,
no, I do not want them to know.

									Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] suspend: update warnings

[Nigel Cunningham]

Hi.

On Tue, 2005-08-23 at 22:50, Pavel Machek wrote:
> Hi!
> 
> > > + * If you have unsupported (*) devices using DMA, you may have some
> > > + * problems. If your disk driver does not support suspend... (IDE does),
> > > + * it may cause some problems, too. If you change kernel command line 
> > > + * between suspend and resume, it may do something wrong. If you change 
> > > + * your hardware while system is suspended... well, it was not good idea;
> > > + * but it wil probably only crash.
> > 
> > The most common driver issues I see involve:
> > - USB being built in or as modules that are still loaded while
> > suspending (getting better, but not there yet)
> > - DRI being used in X where the drivers don't properly support
> > suspend/resume (NVidia esp)
> > - Firewire
> > - CPU Freq  (improving too)
> > 
> > It might be good to mention these areas too.
> 
> Well, right; but those 'only' cause system to crash during suspend. I
> was talking about really dangerous stuff.
> 
> Both usb and cpufreq seems to work okay here.

It depends on what you're using. I believe one of the usb root hub
drivers is okay, the others aren't. Similar for cpufreq. USB certainly
accounts for a high percentage of the failures I see.

> I've added FAQ entry at the end:
> 
> Q: What information is usefull for debugging suspend-to-disk problems?
> 
> A: Well, last messages on the screen are always useful. If something
> is broken, it is usually some kernel driver, therefore trying with as
> little as possible modules loaded helps a lot. I also prefer people to
> suspend from console, preferably without X running. Booting with
> init=/bin/bash, then swapon and starting suspend sequence manually
> usually does the trick. Then it is good idea to try with latest
> vanilla kernel.
> 
> "Known problematic" modules are; be sure to unload them before
> suspend:
> - DRI being used in X where the drivers don't properly support
> suspend/resume (NVidia esp)
> - Firewire
> - SCSI
> 
> 
> > Perhaps the 'changing your hardware' could mention that replacing faulty
> > hardware may be safe.
> 
> I do not want to encourage people to do that. Yep, its probably safe,
> no, I do not want them to know.

:>

Thanks

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Re: [patch] suspend: update warnings

[Pavel Machek]

Hi!

> > > > + * If you have unsupported (*) devices using DMA, you may have some
> > > > + * problems. If your disk driver does not support suspend... (IDE does),
> > > > + * it may cause some problems, too. If you change kernel command line 
> > > > + * between suspend and resume, it may do something wrong. If you change 
> > > > + * your hardware while system is suspended... well, it was not good idea;
> > > > + * but it wil probably only crash.
> > > 
> > > The most common driver issues I see involve:
> > > - USB being built in or as modules that are still loaded while
> > > suspending (getting better, but not there yet)
> > > - DRI being used in X where the drivers don't properly support
> > > suspend/resume (NVidia esp)
> > > - Firewire
> > > - CPU Freq  (improving too)
> > > 
> > > It might be good to mention these areas too.
> > 
> > Well, right; but those 'only' cause system to crash during suspend. I
> > was talking about really dangerous stuff.
> > 
> > Both usb and cpufreq seems to work okay here.
> 
> It depends on what you're using. I believe one of the usb root hub
> drivers is okay, the others aren't. Similar for cpufreq. USB certainly
> accounts for a high percentage of the failures I see.

Do you remember which one is it? I have UHCI here, and it seems to
work okay. powernow-k8 and cpufreq-centrino also seems to behave ok.

								Pavel
-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] suspend: update warnings

[Dave Jones]

On Tue, Aug 23, 2005 at 10:53:16PM +1000, Nigel Cunningham wrote:

 > > > - CPU Freq  (improving too)
 > > > It might be good to mention these areas too.
 > > Well, right; but those 'only' cause system to crash during suspend. I
 > > was talking about really dangerous stuff.
 > > Both usb and cpufreq seems to work okay here.
 > It depends on what you're using. I believe one of the usb root hub
 > drivers is okay, the others aren't. Similar for cpufreq.

If you know a specific cpufreq driver which has problems, I'm all ears.

		Dave

Re: [patch] suspend: update warnings

[Nigel Cunningham]

Hi Dave.

On Wed, 2005-08-24 at 01:05, Dave Jones wrote:
> On Tue, Aug 23, 2005 at 10:53:16PM +1000, Nigel Cunningham wrote:
> 
>  > > > - CPU Freq  (improving too)
>  > > > It might be good to mention these areas too.
>  > > Well, right; but those 'only' cause system to crash during suspend. I
>  > > was talking about really dangerous stuff.
>  > > Both usb and cpufreq seems to work okay here.
>  > It depends on what you're using. I believe one of the usb root hub
>  > drivers is okay, the others aren't. Similar for cpufreq.
> 
> If you know a specific cpufreq driver which has problems, I'm all ears.

Here's the report from a user that I'm thinking of:

http://lists.suspend2.net/lurker/message/20050822.140001.6bf4abfe.en.html

Regards,

Nigel
-- 
Evolution.
Enumerate the requirements.
Consider the interdependencies.
Calculate the probabilities.

Re: [patch] suspend: update warnings

[Dave Jones]

On Wed, Aug 24, 2005 at 06:53:49AM +1000, Nigel Cunningham wrote:

 > > > > > - CPU Freq  (improving too)
 > > > > > It might be good to mention these areas too.
 > > > > Well, right; but those 'only' cause system to crash during suspend. I
 > > > > was talking about really dangerous stuff.
 > > > > Both usb and cpufreq seems to work okay here.
 > > > It depends on what you're using. I believe one of the usb root hub
 > > > drivers is okay, the others aren't. Similar for cpufreq.
 > > 
 > > If you know a specific cpufreq driver which has problems, I'm all ears.
 > 
 > Here's the report from a user that I'm thinking of:
 > 
 > http://lists.suspend2.net/lurker/message/20050822.140001.6bf4abfe.en.html

Tainted oopses are completely uninteresting to me.  I see nothing there
at all to go on to investigate any problem in the centrino driver.
That the cpufreq driver & some binary module doesn't play together nicely
isn't news btw, I've heard reports of both of the common binary 3d drivers
locking up when CPU scaling is used, and there is *nothing* we can do to
fix that. If those drivers are making assumptions that the cpu speed
will remain static, they're broken, and unfixable by us.

We have enough problems getting suspend working for users without
binary junk loaded, so as far as I'm concerned.. CLOSED->NOTABUG.

		Dave

Re: [patch] suspend: update warnings

[Christoph Hellwig]

On Tue, Aug 23, 2005 at 02:50:17PM +0200, Pavel Machek wrote:
> - DRI being used in X where the drivers don't properly support
> suspend/resume (NVidia esp)

NVidias driver is not support and a copyright violation of the
copyrights of many of use.  It's never supported so please don't
mention it.

Re: [patch] suspend: update warnings

[Pavel Machek]

Hi!

> > - DRI being used in X where the drivers don't properly support
> > suspend/resume (NVidia esp)
> 
> NVidias driver is not support and a copyright violation of the
> copyrights of many of use.  It's never supported so please don't
> mention it.

Unfortunately, it is quite common out there. I need to somehow keep
those bug reports off my mailbox.

Okay, this should be enough:

Q: What information is usefull for debugging suspend-to-disk problems?

A: Well, last messages on the screen are always useful. If something
is broken, it is usually some kernel driver, therefore trying with as
little as possible modules loaded helps a lot. I also prefer people to
suspend from console, preferably without X running. Booting with
init=/bin/bash, then swapon and starting suspend sequence manually
usually does the trick. Then it is good idea to try with latest
vanilla kernel.

"Known problematic" modules are; be sure to unload them before
suspend:
- DRI being used (3D acceleration)
- Firewire
- SCSI



-- 
if you have sharp zaurus hardware you don't need... you know my address

Re: [patch] suspend: update warnings

[Christoph Hellwig]

On Tue, Aug 23, 2005 at 03:00:50PM +0200, Pavel Machek wrote:
> Hi!
> 
> > > - DRI being used in X where the drivers don't properly support
> > > suspend/resume (NVidia esp)
> > 
> > NVidias driver is not support and a copyright violation of the
> > copyrights of many of use.  It's never supported so please don't
> > mention it.
> 
> Unfortunately, it is quite common out there. I need to somehow keep
> those bug reports off my mailbox.

I think we made it pretty clear that people with binary modules should
sodd off.  Feel free to use banner for a big "sod off as usual" warning
for all binary module user idiots.

Re: [patch] suspend: update warnings

[Stefan Seyfried]

Pavel Machek wrote:

> "Known problematic" modules are; be sure to unload them before
> suspend:
> - DRI being used (3D acceleration)

sometimes, not always. Also, this equals "reboot instead of suspend,
please" since if i have to restart X i'd rather reboot instead.
Many people are successfull in using DRI with suspend, even running 3D
Apps while suspend works now. Of course, for troubleshooting it is ok to
keep DRI off the picture, but usually suspend works fine with DRI

> - Firewire
> - SCSI
-- 
Stefan Seyfried                  \ "I didn't want to write for pay. I
QA / R&D Team Mobile Devices      \ wanted to be paid for what I write."
SUSE LINUX Products GmbH, Nürnberg \                    -- Leonard Cohen