RE: Linux 2.4.3-ac7

RE: Linux 2.4.3-ac7

[Grover, Andrew]

> From: Martin Hamilton [mailto:martin@net.lut.ac.uk]
> | ACPI is meant to abstract the OS from all the "magic 
> numbers". It's very
> | possible to do things in a platform-specific way, but if 
> you want to handle
> | all platforms, you'd end up with something ACPI-like.
> 
> This isn't me talking, but I think you know the objection from
> hardcore Linux folk is essentially that Linux is the only platform for
> which platform-specific stuff should go into the Linux kernel.  I
> don't really mind so long as suspend-to-disk and resume work... ;-)

I don't think I understand that first sentence. (Let me respond anyways ;-)
As of now, the Linux kernel is not so platform-specific that you need
different kernel images for different BIOS revisions, or different
motherboard layouts. When you start putting platform magic numbers in the
kernel config, this is the result, and this is the *worst* possible outcome.

ACPI lets the OS manage the platform by determining this stuff at run-time
(as opposed to compile-time) so one kernel can handle all platform
configurations.

> | We're working on this. The major issue now is device power 
> management. 
> 
> I was wondering whether the swsusp work might form a useful basis for 
> the eventual ACPI implementation of the to-disk hibernation stuff:

I (and others) have looked at it. It's a pretty cool patch, but it really
isn't the right way to do things.

Regards -- Andy

Re: Linux 2.4.3-ac7

[Alan Cox]

> > I was wondering whether the swsusp work might form a useful basis for 
> > the eventual ACPI implementation of the to-disk hibernation stuff:
> 
> I (and others) have looked at it. It's a pretty cool patch, but it really
> isn't the right way to do things.

swsusp is most definitely the right way to do things. It works on my laptop
which has non suspend to disk APM, it even works on my MVP3 board where
ACPI bombs totally (BIOS bug).

It might not be the right thing to do if ACPI suspend is present though.

Actually swsusp has one minor problem. Because of implementation bugs in some
of the journalled file systems like ext3 using swsusp with those file systems
can corrupt your disks (they write to disk even when told to mount read only
rather than replaying the log to disk when the mount goes r/w - which is
really antisocial, breaks if you are trying to recover from a failed disk and
wants fixing.)

Re: Linux 2.4.3-ac7

[Ookhoi]

> > > I was wondering whether the swsusp work might form a useful basis
> > > for the eventual ACPI implementation of the to-disk hibernation
> > > stuff:
> > 
> > I (and others) have looked at it. It's a pretty cool patch, but it
> > really isn't the right way to do things.
> 
> swsusp is most definitely the right way to do things. It works on my
> laptop which has non suspend to disk APM, it even works on my MVP3
> board where ACPI bombs totally (BIOS bug).
> 
> It might not be the right thing to do if ACPI suspend is present
> though.
> 
> Actually swsusp has one minor problem. Because of implementation bugs
> in some of the journalled file systems like ext3 using swsusp with
> those file systems can corrupt your disks (they write to disk even
> when told to mount read only rather than replaying the log to disk
> when the mount goes r/w - which is really antisocial, breaks if you
> are trying to recover from a failed disk and wants fixing.)

I tried swsusp on my vaio (also a c1ve :-) and it didn't work because it
(said it) couldn't stop [kreiserfsd]. :-(  It didn't do any harm also
afaics. 
I have zero experience with apm and acpi, but the thing I liked about
swsusp is that it works with a sysrq key combo. 

	Ookhoi

Re: Linux 2.4.3-ac7

[Martin Hamilton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

(cc'd to the acpi list, where people have also been talking about 
this recently...)

Ookhoi writes:

| I tried swsusp on my vaio (also a c1ve :-) and it didn't work because it
| (said it) couldn't stop [kreiserfsd]. :-(  It didn't do any harm also
| afaics. 

FWIW, I didn't have any luck with the 2.4.3 swsusp-v8pre3 patch - my
C1VE suspended to disk, but on re-reading the memory image from swap
space the machine reset and we were back to the LILO prompt & fsck.

I tried turning everything off at build time that I didn't need to
actually boot the machine, and with 'CONFIG_HWSTATE_RESTORE' both on
and off - to no avail.  Will do a bit more digging to see if I can
figure out the problem, since I was enjoying running the bleeding edge
kernels on this box...

On the other hand the swsusp-v7c patch worked against 2.2.19 with only
minor tweakings, and presumably out-of-the-box against 2.2.18, which
is what it was actually indended for.  Yay!

Just so you don't get your hopes up too high, with this patch (only
tried with CONFIG_HWSTATE_RESTORE off so far) I still had to restart
networking and X after powering up again.  Compared with a full reboot
(of RedHat 7.1!) that's a small price to pay ;-)

But as Alan Cox says, expected the unexpected if you use this in
conjunction with ext3 or ReiserFS at the minute... !

Cheers,

Martin



-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin

iD8DBQE63r9gVw+hz3xBJfQRAnVLAKCaKjSbR7wbRMGQIEFYMRXNDDM8tgCffGTO
MAC6PG1MyHCcaD7vsCvpdh4=
=7nBk
-----END PGP SIGNATURE-----

Re: [linux-power]Re: Linux 2.4.3-ac7

[Akos Maroy]

Martin Hamilton wrote:

> FWIW, I didn't have any luck with the 2.4.3 swsusp-v8pre3 patch - my
> C1VE suspended to disk, but on re-reading the memory image from swap
> space the machine reset and we were back to the LILO prompt & fsck.

I can confirm Martin's experience, I got the same results.

Akos

Re: Linux 2.4.3-ac7

[Martin Hamilton]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Content-Type: text/plain; charset=us-ascii

"Grover, Andrew" writes:

| I don't think I understand that first sentence. (Let me respond anyways ;-)

Doh!  Sorry, what I meant was that (if I'm understanding this right!)
the AML interpreter being embedded in the kernel in 2.4.x is Intel's
platform-independent solution to the problem of providing support for
ACPI under Unix, so that you don't have to code up ACPI stuff
independently for the vagaries of each Unix variant's kernel.

So, it's good for you, but not necessarily optimal for any particular 
Unix variant, right ?  e.g. this could perhaps be simplified 
somewhat..

  [root@porcupine acpi]# pwd
  /usr/src/linux-2.4.3-ac9-swsusp-jogutils/drivers/acpi
  [root@porcupine acpi]# wc -l `find . -type f` | grep total
    59435 total

My gripe is taken care of now, though - swsusp is working :-)

Cheers,

Martin




-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.4 (GNU/Linux)
Comment: Exmh version 2.1.1 10/15/1999 + martin

iD8DBQE63ryhVw+hz3xBJfQRAkzDAJ9eVSJUK7mPZqUyqpvl/yOJSkiAsQCeJjtN
153+/FDFzNKht/7iTKYSI0k=
=0C2p
-----END PGP SIGNATURE-----