Okay, I'm having a really bad day (or week) and I want to apologize
for the rantish email. I just went back into the configuration for the
new kernel, and I was wrong about the experimental state of the SATA,
but it appears the PATA state is experimental instead.
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).
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)
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).
My wor laptop (IBM/Lenova T43) has the same setup on 2.6.18.3 and I
have be suspending to RAM and to disk without issue for a while now.
The modules in use by my laptop:
libata 89556 2 ata_piix,ahci
scsi_mod 124296 5 sg,sr_mod,sd_mod,ahci,libata
Here is my relavant hardware and software once again:
EPoX 9npa + Ultra mother board (NVIDIA nForce4 + Ultra chipset)
SATA 2 Samsung drive
AMD 64 Dual Core X2 (I am on the i386 platform though as too many
programs were too much effort to configure on amd64 to bother with for
the little performance gain I'd get with what I normally do)
Kernel 2.6.19
Hibernate 1.94-2
ReiserFS
Debian Etch
What do you kernel experts think that could have been the issue (some
combination of 2.6.19, sata_nv, hibernate, ReiserFS)? After this I am
reluctant to go back to the *19 instead of *18 kernel.
BTW - the reason I hibernate is because I sometimes dual boot into
windows (for games that don't play well on cedega) and I prefer to not
use the electricity from running the computer 24x7 when I don't need
to, but I like to have my desktop state remain constant as I often
have multiple programs open for development.
Sorry for the first email format. Thanks again for any help on the issue
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.
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
> 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.
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
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.
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
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.
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
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.