[prev in list] [next in list] [prev in thread] [next in thread] 

List:       swsusp-devel
Subject:    R =?ISO-8859-1?Q?=E9p_:_R=E9?= p : Re: [swsusp] swsusp for 2.5.1
From:       "Jose' Manuel Pereira" <jmp () asterix ! ist ! utl ! pt>
Date:       2001-12-28 18:51:43
[Download RAW message or body]

"fc" == fchabaud  <fchabaud@free.fr> writes:


  fc> And it didn't smash them, only the root inode. But fsck does it on
  fc> reboot.

A lost root inode probably means a fscked superblock...

  fc> All the kernels I used were ext2 and ext3 enabled. The rescue system was
  fc> a 2.4.16 unpatched kernel. The only difference was that the partitions
  fc> were marked as ext2 in the fstab file. But this should not be a problem
  fc> since an ext3 partition can be mounted as ext2, isn't it ?

It can. BUT: always use fsck -j nevertheless!!! (to replay the journal) Or else...
Well, you saw what can happen :-}

  fc> I agree with you. The discussion with Pavel suggests however that the
  fc> bug may be elsewhere and revealed by suspension patch (and perhaps even
  fc> with higher probability of occurence with ext3)

If you didn't use "-j", it's not a bug, it's a documented possibility (see
e2fsprogs docs). (Alright, personally, I have done that a couple of times, only
I've been lucky...)

  fc> And what about initrd ? This would be a good mean to have a stable root
  fc> from which to resume. By the way, what kind of linux loading is used by
  fc> testers ? This could give hint in searching the bug if initrd users
  fc> never experience problem suspending.

Excellent idea! I stand corrected: an initrd root IS the safest way.

I never used initrd, but seems the best to test this kind of reboots. Also, I
suggest mounting only a scratch partition containing a minimal installation,
to prevent losing important files (yes, I know everyone keeps excellent
backups ;-) But).

  fc> For myself DMA was disabled for the disk. There is also a kernel option
  fc> to disable DMA.

There are other devices that do DMA. Agreed that the disk is the most
interesting. Perhaps the suspend process could include ensuring that DMA is
off before starting the freezing.

  fc> For myself apmd daemon stops problematic daemons. I however disagree
  fc> with you concerning timeout because this is not a solution. A timeout
  fc> scheduled for an architecture may be unsufficient in another
  fc> configuration.

Well, for "reasonable" I meant an immensely exaggerated time, like 1 sec. or
so... Should work on any of the archs linux was already ported to, I think :-)

Ok, is 3 secs enough? Please note that we're going to switch off the damn
thing, so blindingly fast speed is not that important...

  >> Having done all above, the resuming process is quite >easy. Even when you
  >> havejournalling fs's replaying, >you'll be safe, since replaying is
  >> monotonic(replaying >twice is harmless).

  fc> This is what everyone think. But is that implemented this way (see
  fc> discussion with Pavel) ? It would worth to check that also...

Yes, Pavel even has included code to prevent that for reiserfs. But I don't
agree that's needed. NB: I haven't delved into reiserfs&ext3 or other jfs's
replay code. But, by definition of journalling, I wouldn't expect to find
anything in contrary.

Hope you can recover your system,

-- 
 Jose' Pereira		(CIIST sysadm)			Tel. +351.21.841 7526
 Centro de Informatica
 Instituto Superior Tecnico - Technical University of Lisboa
 Av. Rovisco Pais - 1049-001 Lisboa - Portugal

_______________________________________________
swsusp maillist  -  swsusp@lister.fornax.hu
http://lister.fornax.hu/mailman/listinfo/swsusp
[prev in list] [next in list] [prev in thread] [next in thread]