Re: [patch] suspend: update warnings
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 Team Mobile Devices \ wanted to be paid for what I write." SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 / RD Team Mobile Devices \ wanted to be paid for what I write. SUSE LINUX Products GmbH, Nürnberg \-- Leonard Cohen - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 <[EMAIL PROTECTED](none)> Mon, 22 Aug 2005 10:13:51 +0200 > committer <[EMAIL PROTECTED](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. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
Pavel Machek napsal(a): + * but it wil probably only crash. ... it will ... :) * * (*) suspend/resume support is needed to make it safe. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
Pavel Machek napsal(a): + * but it wil probably only crash. ... it will ... :) * * (*) suspend/resume support is needed to make it safe. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] suspend: update warnings
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 [EMAIL PROTECTED](none) Mon, 22 Aug 2005 10:13:51 +0200 committer [EMAIL PROTECTED](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. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
