suspend to disk (was Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means))
Hi! > >Stop spreading fud. Take powersave + suspend from > >suse10.2, and see > >if you can break it. > > > >sata_nv seems to have problem, that's it. and it > >triggered problem in > >reiserfs. Use ext3 if you care about your data, and yes > >your drivers > >need to support suspend/resume. > > > My Compaq laptop, a Presario 2200, has video lockups > using suspend to disk and a dead system everytime I use > it. I don't Try with vga=1 (no framebuffer) and minimum number of modules. > think its fud. I also conceed its not Linux's fault most > of the time. These vendors put Windows specific hardware suspend to ram is usually video bios problem; suspend to disk tends to be linux problem. Pavel -- Thanks for all the (sleeping) penguins. - 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/
suspend to disk (was Re: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means))
Hi! Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. My Compaq laptop, a Presario 2200, has video lockups using suspend to disk and a dead system everytime I use it. I don't Try with vga=1 (no framebuffer) and minimum number of modules. think its fud. I also conceed its not Linux's fault most of the time. These vendors put Windows specific hardware suspend to ram is usually video bios problem; suspend to disk tends to be linux problem. Pavel -- Thanks for all the (sleeping) penguins. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Pavel Machek wrote: On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel My Compaq laptop, a Presario 2200, has video lockups using suspend to disk and a dead system everytime I use it. I don't think its fud. I also conceed its not Linux's fault most of the time. These vendors put Windows specific hardware support into these systems. My laptop has a dozen strange keys that work only on Windows and if you push one of them in Linux, the system looses state with the keyboard and croaks ( have to reboot to recover). If I close the lid of my latop or do any other suspend to disk state, the video display is croaked. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
On Tue 12-12-06 23:45:27, Olivier Galibert wrote: > On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: > > When I said hibernate, I did mention it was to disk, not to ram. > > Suspend to disk is not trustable on Linux, and does not look like it > will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel -- Thanks for all the (sleeping) penguins. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel -- Thanks for all the (sleeping) penguins. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Pavel Machek wrote: On Tue 12-12-06 23:45:27, Olivier Galibert wrote: On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming Stop spreading fud. Take powersave + suspend from suse10.2, and see if you can break it. sata_nv seems to have problem, that's it. and it triggered problem in reiserfs. Use ext3 if you care about your data, and yes your drivers need to support suspend/resume. Pavel My Compaq laptop, a Presario 2200, has video lockups using suspend to disk and a dead system everytime I use it. I don't think its fud. I also conceed its not Linux's fault most of the time. These vendors put Windows specific hardware support into these systems. My laptop has a dozen strange keys that work only on Windows and if you push one of them in Linux, the system looses state with the keyboard and croaks ( have to reboot to recover). If I close the lid of my latop or do any other suspend to disk state, the video display is croaked. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. I woke my computer up from work remotely using wakeonlan. When the computer was responsive, I started getting I/O errors and when I saw my kernel log I saw file corruption problems with my "/dev/sda2" device (which is my root file system and is one of two, the other is the swap partition) sata_nv is just now receiving suspend/resume support in devel tree. 2.6.19 sata_nv doesn't have it and STD might have worked but I wouldn't be surprised if it doesn't work from time to time or gets broken due to unrelated changes in kernel. So, IO errors after STD are bad but kind of expected. I dunno what went wrong with your fs after such IO errors. Destroyed fs after some IO errors is pretty extreme tho. So, my 5 cents is... don't do hibernation till 2.6.20 is out. -- tejun - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. I woke my computer up from work remotely using wakeonlan. When the computer was responsive, I started getting I/O errors and when I saw my kernel log I saw file corruption problems with my /dev/sda2 device (which is my root file system and is one of two, the other is the swap partition) sata_nv is just now receiving suspend/resume support in devel tree. 2.6.19 sata_nv doesn't have it and STD might have worked but I wouldn't be surprised if it doesn't work from time to time or gets broken due to unrelated changes in kernel. So, IO errors after STD are bad but kind of expected. I dunno what went wrong with your fs after such IO errors. Destroyed fs after some IO errors is pretty extreme tho. So, my 5 cents is... don't do hibernation till 2.6.20 is out. -- tejun - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: > When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming reliable, but at that point is not ide/sata compatible, and X will keep making things hard. OG. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Phillip Susi wrote: If your comment here was in reply to my general comment about resierfs stability and not the specific hibernation issue the OP was having, please edit the quote down to just that portion instead of quoting the entire message, including the quotes it was replying to. I wonder what kernel version you are running. Since you mention rpms, I will assume you are running redhat, and likely are using a rather old kernel. The system I see these problems on is a Suse 10.0. I STORE RPM's on a Reiser FS system on this server as an ftp server. It's the server at ftp.soleranetworks.com. I run 2.6.18 and 2.6.19 for our development at present for our appliances, we do not ship Suse. Our appliances use RedHat ES4 and FC6. We were testing Suse out as an FTP server -- its not very stable. The Suse system with ReiserFS is running 2.6.13. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
No. I still see corruption on Suse with Reiser FS. It's always very subtle (like the last block of a file doesn;t get copied or gets corrupted. We have been running our ftp server on ReiserFS, and as soon as I can get it moved back to ext3, we are doing so. We have had a lot of issues with corrupted RPM files and builds on ReiserFS. If you can get the files copied to the FS ok, they seem to stay that way. moving a lot of data with recursive copies seems troublesome and some of the files seem to get the ends clipped off of them. If your comment here was in reply to my general comment about resierfs stability and not the specific hibernation issue the OP was having, please edit the quote down to just that portion instead of quoting the entire message, including the quotes it was replying to. I wonder what kernel version you are running. Since you mention rpms, I will assume you are running redhat, and likely are using a rather old kernel. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Phillip Susi wrote: Andrew Robinson wrote: Now I am confused on what may be the cause of the corruption. Could it have been just a ReiserFS problem (I will be using Ext3 or JSF on my next rebuild I think after reading some reviews on the ReiserFS and this recent experience). I have been running reiser on my home machine and a server at work for a year now without incident. There were some bugs a few years back but it seems to be in good working order these days. I'm not sure if it could be a SATA_NV driver problem, a hibernate problem, or a ReiserFS problem or a combination of the above. For hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my swap partition). I do not have suspend2 installed though, I have been relying on its fallback settings to ususpend or sysfs (not sure which one is actually executed). Sounds like your hibernation corrupted the disk, but without more specifics, this is just educated guesswork. No. I still see corruption on Suse with Reiser FS. It's always very subtle (like the last block of a file doesn;t get copied or gets corrupted. We have been running our ftp server on ReiserFS, and as soon as I can get it moved back to ext3, we are doing so. We have had a lot of issues with corrupted RPM files and builds on ReiserFS. If you can get the files copied to the FS ok, they seem to stay that way. moving a lot of data with recursive copies seems troublesome and some of the files seem to get the ends clipped off of them. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Andrew Robinson wrote: Now I am confused on what may be the cause of the corruption. Could it have been just a ReiserFS problem (I will be using Ext3 or JSF on my next rebuild I think after reading some reviews on the ReiserFS and this recent experience). I have been running reiser on my home machine and a server at work for a year now without incident. There were some bugs a few years back but it seems to be in good working order these days. I'm not sure if it could be a SATA_NV driver problem, a hibernate problem, or a ReiserFS problem or a combination of the above. For hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my swap partition). I do not have suspend2 installed though, I have been relying on its fallback settings to ususpend or sysfs (not sure which one is actually executed). Sounds like your hibernation corrupted the disk, but without more specifics, this is just educated guesswork. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Andrew Robinson wrote: Now I am confused on what may be the cause of the corruption. Could it have been just a ReiserFS problem (I will be using Ext3 or JSF on my next rebuild I think after reading some reviews on the ReiserFS and this recent experience). I have been running reiser on my home machine and a server at work for a year now without incident. There were some bugs a few years back but it seems to be in good working order these days. I'm not sure if it could be a SATA_NV driver problem, a hibernate problem, or a ReiserFS problem or a combination of the above. For hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my swap partition). I do not have suspend2 installed though, I have been relying on its fallback settings to ususpend or sysfs (not sure which one is actually executed). Sounds like your hibernation corrupted the disk, but without more specifics, this is just educated guesswork. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Phillip Susi wrote: Andrew Robinson wrote: Now I am confused on what may be the cause of the corruption. Could it have been just a ReiserFS problem (I will be using Ext3 or JSF on my next rebuild I think after reading some reviews on the ReiserFS and this recent experience). I have been running reiser on my home machine and a server at work for a year now without incident. There were some bugs a few years back but it seems to be in good working order these days. I'm not sure if it could be a SATA_NV driver problem, a hibernate problem, or a ReiserFS problem or a combination of the above. For hibernation, I had the resume2 kernel boot option set as /dev/sda1 (my swap partition). I do not have suspend2 installed though, I have been relying on its fallback settings to ususpend or sysfs (not sure which one is actually executed). Sounds like your hibernation corrupted the disk, but without more specifics, this is just educated guesswork. No. I still see corruption on Suse with Reiser FS. It's always very subtle (like the last block of a file doesn;t get copied or gets corrupted. We have been running our ftp server on ReiserFS, and as soon as I can get it moved back to ext3, we are doing so. We have had a lot of issues with corrupted RPM files and builds on ReiserFS. If you can get the files copied to the FS ok, they seem to stay that way. moving a lot of data with recursive copies seems troublesome and some of the files seem to get the ends clipped off of them. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
No. I still see corruption on Suse with Reiser FS. It's always very subtle (like the last block of a file doesn;t get copied or gets corrupted. We have been running our ftp server on ReiserFS, and as soon as I can get it moved back to ext3, we are doing so. We have had a lot of issues with corrupted RPM files and builds on ReiserFS. If you can get the files copied to the FS ok, they seem to stay that way. moving a lot of data with recursive copies seems troublesome and some of the files seem to get the ends clipped off of them. If your comment here was in reply to my general comment about resierfs stability and not the specific hibernation issue the OP was having, please edit the quote down to just that portion instead of quoting the entire message, including the quotes it was replying to. I wonder what kernel version you are running. Since you mention rpms, I will assume you are running redhat, and likely are using a rather old kernel. - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
Phillip Susi wrote: If your comment here was in reply to my general comment about resierfs stability and not the specific hibernation issue the OP was having, please edit the quote down to just that portion instead of quoting the entire message, including the quotes it was replying to. I wonder what kernel version you are running. Since you mention rpms, I will assume you are running redhat, and likely are using a rather old kernel. The system I see these problems on is a Suse 10.0. I STORE RPM's on a Reiser FS system on this server as an ftp server. It's the server at ftp.soleranetworks.com. I run 2.6.18 and 2.6.19 for our development at present for our appliances, we do not ship Suse. Our appliances use RedHat ES4 and FC6. We were testing Suse out as an FTP server -- its not very stable. The Suse system with ReiserFS is running 2.6.13. Jeff - 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: ReiserFS corruption with 2.6.19 (Was 2.6.19 is not stable with SATA and should not be used by any meansis not stable with SATA and should not be used by any means)
On Tue, Dec 12, 2006 at 11:44:18AM -0700, Andrew Robinson wrote: When I said hibernate, I did mention it was to disk, not to ram. Suspend to disk is not trustable on Linux, and does not look like it will be any time soon. Suspend to ram has a better chance of becoming reliable, but at that point is not ide/sata compatible, and X will keep making things hard. OG. - 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/
