uspend to Disk - Kernel 2.6.4 vs. r50p

uspend to Disk - Kernel 2.6.4 vs. r50p

[Hamie]

I have an r50p running debian unstable with kernel 2.6.4, compiled from scratch using the source from kernel.org, no patching (i.e. for swsusp etc).

Most things work fine (2.6.5 broke USB for me, so I'm still at 2.6.4), but I want suspend to disk (or suspend to RAM for that matter) to work.

But.

echo -n disk > /proc/power/state

results in the (Correct?) text screen that says it's going to do the suspend etc... But then just wakes straight up. here's the logs from kern.log
Apr 29 06:44:12 ballbreaker kernel: Stopping tasks: =======================================================================|
Apr 29 06:44:12 ballbreaker kernel: Freeing memory: .......................................|
Apr 29 06:44:12 ballbreaker kernel: hdc: start_power_step(step: 0)
Apr 29 06:44:12 ballbreaker kernel: hdc: completing PM request, suspend
Apr 29 06:44:12 ballbreaker kernel: hda: start_power_step(step: 0)
Apr 29 06:44:12 ballbreaker kernel: hda: start_power_step(step: 1)
Apr 29 06:44:12 ballbreaker kernel: hda: complete_power_step(step: 1, stat: 50, err: 0)
Apr 29 06:44:12 ballbreaker kernel: hda: completing PM request, suspend
Apr 29 06:44:12 ballbreaker kernel: PM: Attempting to suspend to disk.
Apr 29 06:44:12 ballbreaker kernel: PM: snapshotting memory.
Apr 29 06:44:12 ballbreaker kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
Apr 29 06:44:12 ballbreaker kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
Apr 29 06:44:12 ballbreaker kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
Apr 29 06:44:13 ballbreaker kernel: PCI: Setting latency timer of device 0000:00:1f.5 to 64
Apr 29 06:44:13 ballbreaker kernel: hda: Wakeup request inited, waiting for !BSY...
Apr 29 06:44:13 ballbreaker kernel: hda: start_power_step(step: 1000)
Apr 29 06:44:13 ballbreaker kernel: blk: queue de7f5df8, I/O limit 4095Mb (mask 0xffffffff)
Apr 29 06:44:13 ballbreaker kernel: hda: completing PM request, resume
Apr 29 06:44:13 ballbreaker kernel: hdc: Wakeup request inited, waiting for !BSY...
Apr 29 06:44:13 ballbreaker kernel: hdc: start_power_step(step: 1000)
Apr 29 06:44:13 ballbreaker kernel: hdc: completing PM request, resume
Apr 29 06:44:13 ballbreaker kernel: Restarting tasks... done


Anyone know why it doesn't actually power off? Info on this phenomenon seems to be a bit sparse, but there seems to be a few people reporting it on various laptops...

What is the story on suspend to disk anyway? Should we use the kernel code? swsusp patches & resume2? pmdisk patches?  Damnit I just want it to work... I'd even use straight FN-F4 except my video won't wake up afterwards... Currently I have to reboot several times a day (i.e. whenever I want to move my thinkpad from one place to another). very frustrating...

TIA
 hamish. 

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> echo -n disk > /proc/power/state

Use echo 4 > /proc/acpi/sleep, and vanilla kernels.

				Pavel
-- 
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms         

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Grzegorz Piotr Jaskiewicz]

Pavel Machek wrote:

>Hi!
>
>  
>
>>echo -n disk > /proc/power/state
>>    
>>
>
>Use echo 4 > /proc/acpi/sleep, and vanilla kernels.
>
>			
>
What If it happends that I have T22 Thinkpad, and it doesn't work with 
ACPI in 2.6 (causes problems with network cards for some reason, long 
and not yet fixed bug in ACPI), and I don't have /proc/acpi. How can I 
use swsusp than ?

--
GJ

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> >Use echo 4 > /proc/acpi/sleep, and vanilla kernels.
> >
> >			
> >
> What If it happends that I have T22 Thinkpad, and it doesn't work with 
> ACPI in 2.6 (causes problems with network cards for some reason, long 
> and not yet fixed bug in ACPI), and I don't have /proc/acpi. How can I 
> use swsusp than ?

I added entry to FAQ:

Q: My machine doesn't work with ACPI. How can I use swsusp than ?

A: Do reboot() syscall with right parameters. Warning: glibc gets in
its way, so check with strace:

reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)

Ouch, and when you code that trivial program, send me source, I lost
mine.
								Pavel
-- 
934a471f20d6580d5aad759bf0d97ddc

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Grzegorz Piotr Jaskiewicz]

Pavel Machek wrote:

>A: Do reboot() syscall with right parameters. Warning: glibc gets in
>its way, so check with strace:
>
>reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)
>
>Ouch, and when you code that trivial program, send me source, I lost
>mine.
>  
>
Wouldn't it be better to just add place in proc that triggers it ?

--
GJ

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> >A: Do reboot() syscall with right parameters. Warning: glibc gets in
> >its way, so check with strace:
> >
> >reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)
> >
> >Ouch, and when you code that trivial program, send me source, I lost
> >mine.
> > 
> >
> Wouldn't it be better to just add place in proc that triggers it ?

I'm not going to add *another* place in /proc. Plus, shutdown -z on
modern distributions should work too.
							Pavel

-- 
934a471f20d6580d5aad759bf0d97ddc

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Peter Osterlund]

Pavel Machek <pavel@ucw.cz> writes:

> Hi!
> 
> > >Use echo 4 > /proc/acpi/sleep, and vanilla kernels.
> > >
> > >			
> > >
> > What If it happends that I have T22 Thinkpad, and it doesn't work with 
> > ACPI in 2.6 (causes problems with network cards for some reason, long 
> > and not yet fixed bug in ACPI), and I don't have /proc/acpi. How can I 
> > use swsusp than ?
> 
> I added entry to FAQ:
> 
> Q: My machine doesn't work with ACPI. How can I use swsusp than ?
> 
> A: Do reboot() syscall with right parameters. Warning: glibc gets in
> its way, so check with strace:
> 
> reboot(LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2, 0xd000fce2)
> 
> Ouch, and when you code that trivial program, send me source, I lost
> mine.

#include <unistd.h>
#include <syscall.h>

#define	LINUX_REBOOT_MAGIC1	0xfee1dead
#define	LINUX_REBOOT_MAGIC2	672274793
#define	LINUX_REBOOT_CMD_SW_SUSPEND	0xD000FCE2

int main()
{
    syscall(SYS_reboot, LINUX_REBOOT_MAGIC1, LINUX_REBOOT_MAGIC2,
	    LINUX_REBOOT_CMD_SW_SUSPEND, 0);
    return 0;
}

-- 
Peter Osterlund - petero2@telia.com
http://w1.894.telia.com/~u89404340

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Rob Landley]

On Monday 03 May 2004 07:31, Pavel Machek wrote:
> Hi!
>
> > echo -n disk > /proc/power/state
>
> Use echo 4 > /proc/acpi/sleep, and vanilla kernels.
>
> 				Pavel

I'm one of the people for whom Patrick's suspend worked and yours didn't.  Now 
I've been busy with other things for a couple months (Penguicon 2.0 went 
quite well, by the way), and there's talk of yanking Patrick's suspend code 
from the kernel.  Right, so I've got to deal with this.  I can't say I'm 
thrilled, but I DO want to continue to be able to suspend my laptop.

What kind of debug info do I need to report to get your suspend code fixed, 
and who do I need to report it to?

I just tested 2.6.5, which went "boing" trying to suspend with some kind of 
debug message that gave me a hex number (not a panic, but I didn't have a pen 
handy, I can try again and write it down if you like.  Anything else I should 
do?)

I asked Nigel a few months ago, and he pointed me to an enormous flag day 
patch that will probably be integrated into the kernel when hell freezes 
over.  (I have no idea why it's so intrusive, by the way.  Isn't half the 
point of sysfs and the new 2.6 device infrastructure that finding all the 
devices that need to be shut up doesn't require the kind of insanity doing it 
under 2.4 did?

I read the docs and read through your code a bit, and every screenful or so it 
says "this code is guaranteed to eat your data if you look at it funny".  
I've been using Patrick's suspend code for something like eight months now, 
and it never ate any of my data.  Failed to resume a few times, but no worse 
than sync followed by yanking the power cord, fsck did its thing and life 
went on.  (Yes, I back up regularly.  But I've gotten the distinct impression 
that you have no faith whatsoever in your own work, and reinstalling and 
restoring from backups is a real pain, especially when you're on the road.)

Sigh.  I _really_ don't have time for this right now.  I wonder if it would be 
possible to just send Patrick some money?

Rob

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Romano Giannetti]

On Tue, May 04, 2004 at 08:18:23PM -0500, Rob Landley wrote:

> I'm one of the people for whom Patrick's suspend worked and yours didn't.  Now 
> I've been busy with other things for a couple months (Penguicon 2.0 went 
> quite well, by the way), and there's talk of yanking Patrick's suspend code 
> from the kernel.  Right, so I've got to deal with this.  I can't say I'm 
> thrilled, but I DO want to continue to be able to suspend my laptop.

Hi! 
    Just a couple of lines to tell you that I was convinced of the same (PM
    works, SWSUSP-vanilla no). But from 2.6.3 --- to which I am stuck, had
    no time to play, just to work, with my laptop till then --- swsusp works
    quite well (modulo pcmcia modem sometime getting stuck after resume and
    sometime no, misteries of life). Pavel told me that if PMDISK worked,
    SWSUSP (vanilla) should work, too, and he was right (tm). 

    The other way around is trying suspend2, given that Nigel is very
    responsive; it will be the first thing I'll try again when having a
    little time after IMTC04. It didn't work one month ago, but Nigel thinks
    he have fixed it. 

    By the way, I have a vaio FX701. 

                Romano     

-- 
Romano Giannetti             -  Univ. Pontificia Comillas (Madrid, Spain)
Electronic Engineer - phone +34 915 422 800 ext 2416  fax +34 915 596 569

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Rob Landley]

On Thursday 06 May 2004 10:43, Romano Giannetti wrote:
> On Tue, May 04, 2004 at 08:18:23PM -0500, Rob Landley wrote:
> > I'm one of the people for whom Patrick's suspend worked and yours didn't.
> >  Now I've been busy with other things for a couple months (Penguicon 2.0
> > went quite well, by the way), and there's talk of yanking Patrick's
> > suspend code from the kernel.  Right, so I've got to deal with this.  I
> > can't say I'm thrilled, but I DO want to continue to be able to suspend
> > my laptop.
>
> Hi!
>     Just a couple of lines to tell you that I was convinced of the same (PM
>     works, SWSUSP-vanilla no). But from 2.6.3 --- to which I am stuck, had
>     no time to play, just to work, with my laptop till then --- swsusp
> works quite well (modulo pcmcia modem sometime getting stuck after resume
> and sometime no, misteries of life). Pavel told me that if PMDISK worked,
> SWSUSP (vanilla) should work, too, and he was right (tm).
>
>     The other way around is trying suspend2, given that Nigel is very
>     responsive; it will be the first thing I'll try again when having a
>     little time after IMTC04. It didn't work one month ago, but Nigel
> thinks he have fixed it.
>
>     By the way, I have a vaio FX701.

Thinkpad iSeries of some kind here.  It didn't work in 2.6.5, but I'll give 
2.6.6 a try and report back then...

The last one I _know_ worked was 2.6.2, but then I skipped 3 and 4.  Too 
busy...

I'm happy to debug problems with stuff I actually use, modulo the whole "too 
busy" thing...

Rob

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> I'm one of the people for whom Patrick's suspend worked and yours didn't.  Now 
> I've been busy with other things for a couple months (Penguicon 2.0 went 
> quite well, by the way), and there's talk of yanking Patrick's suspend code 
> from the kernel.  Right, so I've got to deal with this.  I can't say I'm 
> thrilled, but I DO want to continue to be able to suspend my laptop.
> 
> What kind of debug info do I need to report to get your suspend code fixed, 
> and who do I need to report it to?
> 
> I just tested 2.6.5, which went "boing" trying to suspend with some kind of 
> debug message that gave me a hex number (not a panic, but I didn't have a pen 
> handy, I can try again and write it down if you like.  Anything else I should 
> do?)

Try it with minimal drivers from signle user mode...

> I asked Nigel a few months ago, and he pointed me to an enormous flag day 
> patch that will probably be integrated into the kernel when hell freezes 
> over.  (I have no idea why it's so intrusive, by the way.  Isn't half the 
> point of sysfs and the new 2.6 device infrastructure that finding all the 
> devices that need to be shut up doesn't require the kind of insanity doing it 
> under 2.4 did?

Nigel's refrigerator is way more elaborate and very intrusive, but he
seems to work *always*. Original refrigerator (shared by swsusp and
pmdisk) only tries a bit and eventually gives up if stopping system is
too hard. Hopefully Nigel's code can be simplified.

> I read the docs and read through your code a bit, and every screenful or so it 
> says "this code is guaranteed to eat your data if you look at it funny".  
> I've been using Patrick's suspend code for something like eight months now, 
> and it never ate any of my data.  Failed to resume a few times, but no worse 
> than sync followed by yanking the power cord, fsck did its thing and life 
> went on.  (Yes, I back up regularly.  But I've gotten the distinct impression 
> that you have no faith whatsoever in your own work, and reinstalling and 
> restoring from backups is a real pain, especially when you're on the
> road.)

It did not eat *my* data in last eight months.

If patrick does not warn you, its his problem. If you suspend, mount
your filesytems, do some work and then resume, you are probably going
to do some pretty nasty corruption. Just don't do that.

But this problem is shared by swsusp, swsusp2 *and* pmdisk.

> Sigh.  I _really_ don't have time for this right now.  I wonder if it would be 
> possible to just send Patrick some money?

He's out of time, so money is not likely to help. Sending some money
to Nigel might do the trick ;-).
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Rob Landley]

On Saturday 08 May 2004 17:54, Pavel Machek wrote:
> Hi!
>
> > I'm one of the people for whom Patrick's suspend worked and yours didn't.
> >  Now I've been busy with other things for a couple months (Penguicon 2.0
> > went quite well, by the way), and there's talk of yanking Patrick's
> > suspend code from the kernel.  Right, so I've got to deal with this.  I
> > can't say I'm thrilled, but I DO want to continue to be able to suspend
> > my laptop.
> >
> > What kind of debug info do I need to report to get your suspend code
> > fixed, and who do I need to report it to?
> >
> > I just tested 2.6.5, which went "boing" trying to suspend with some kind
> > of debug message that gave me a hex number (not a panic, but I didn't
> > have a pen handy, I can try again and write it down if you like. 
> > Anything else I should do?)
>
> Try it with minimal drivers from signle user mode...

I'll give it a whack...

> > I asked Nigel a few months ago, and he pointed me to an enormous flag day
> > patch that will probably be integrated into the kernel when hell freezes
> > over.  (I have no idea why it's so intrusive, by the way.  Isn't half the
> > point of sysfs and the new 2.6 device infrastructure that finding all the
> > devices that need to be shut up doesn't require the kind of insanity
> > doing it under 2.4 did?
>
> Nigel's refrigerator is way more elaborate and very intrusive, but he
> seems to work *always*. Original refrigerator (shared by swsusp and
> pmdisk) only tries a bit and eventually gives up if stopping system is
> too hard. Hopefully Nigel's code can be simplified.

I hope so too.  Software suspend is a really nice feature, and he seems to be 
the one putting in the most time on it.

> > I read the docs and read through your code a bit, and every screenful or
> > so it says "this code is guaranteed to eat your data if you look at it
> > funny". I've been using Patrick's suspend code for something like eight
> > months now, and it never ate any of my data.  Failed to resume a few
> > times, but no worse than sync followed by yanking the power cord, fsck
> > did its thing and life went on.  (Yes, I back up regularly.  But I've
> > gotten the distinct impression that you have no faith whatsoever in your
> > own work, and reinstalling and restoring from backups is a real pain,
> > especially when you're on the road.)
>
> It did not eat *my* data in last eight months.
>
> If patrick does not warn you, its his problem.

Yeah, but his code works for me. :)

> If you suspend, mount
> your filesytems, do some work and then resume, you are probably going
> to do some pretty nasty corruption. Just don't do that.
>
> But this problem is shared by swsusp, swsusp2 *and* pmdisk.

I know.  I also know that ext2 (and derivatives) have both "last mounted" and 
"last written to" datestamp fields (other filesystems probably do as well, 
but I don't use 'em) and it would be really nice to check those as matching 
what they were when you suspended, and abort the resume if they don't 
match...

> > Sigh.  I _really_ don't have time for this right now.  I wonder if it
> > would be possible to just send Patrick some money?
>
> He's out of time, so money is not likely to help. Sending some money
> to Nigel might do the trick ;-).
> 								Pavel

His code isn't the one I've gotten to work yet... :)

Rob

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> > If you suspend, mount
> > your filesytems, do some work and then resume, you are probably going
> > to do some pretty nasty corruption. Just don't do that.
> >
> > But this problem is shared by swsusp, swsusp2 *and* pmdisk.
> 
> I know.  I also know that ext2 (and derivatives) have both "last mounted" and 
> "last written to" datestamp fields (other filesystems probably do as well, 
> but I don't use 'em) and it would be really nice to check those as matching 
> what they were when you suspended, and abort the resume if they don't 
> match...

Well, feel free to code that, that will allow us to kill few
warnings... Or rather tone them down. It is still "dont do that"
situation.

> > > Sigh.  I _really_ don't have time for this right now.  I wonder if it
> > > would be possible to just send Patrick some money?
> >
> > He's out of time, so money is not likely to help. Sending some money
> > to Nigel might do the trick ;-).
> 
> His code isn't the one I've gotten to work yet... :)

2.4 version should be rather easy to get going...
									Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Nigel Cunningham]

Hi.

On Sun, 2004-05-09 at 08:54, Pavel Machek wrote:
> Nigel's refrigerator is way more elaborate and very intrusive, but he
> seems to work *always*. Original refrigerator (shared by swsusp and
> pmdisk) only tries a bit and eventually gives up if stopping system is
> too hard. Hopefully Nigel's code can be simplified.

It's actually pretty simple. I just need to explain it more clearly.
Semaphores and wait queues seem complicated to me :>

> He's out of time, so money is not likely to help. Sending some money
> to Nigel might do the trick ;-).

Sending money to me won't help either, except with getting support for
new hardware. I'm working on finding and blatting a little but
significant bug that's made its way in since 2.0. Then I'm only going to
be working on merging.

Rob, I would concentrate on figuring out what makes Pavel's version work
for you and the other two not work. Perhaps then we can adjust our
implementations to address the issue and make you a happy camper :>

Regards,

Nigel
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> > He's out of time, so money is not likely to help. Sending some money
> > to Nigel might do the trick ;-).
> 
> Sending money to me won't help either, except with getting support for
> new hardware. I'm working on finding and blatting a little but

Sorry, I figured you need it most. I probably could not take it
anyway, and Patrick probably has other problems...
								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> > Nigel's refrigerator is way more elaborate and very intrusive, but he
> > seems to work *always*. Original refrigerator (shared by swsusp and
> > pmdisk) only tries a bit and eventually gives up if stopping system is
> > too hard. Hopefully Nigel's code can be simplified.
> 
> It's actually pretty simple. I just need to explain it more clearly.

Well, anything that touches 10+ core kernel files is by definition
complex ;-).

> > He's out of time, so money is not likely to help. Sending some money
> > to Nigel might do the trick ;-).
> 
> Sending money to me won't help either, except with getting support for
> new hardware. I'm working on finding and blatting a little but
> significant bug that's made its way in since 2.0. Then I'm only going to
> be working on merging.
> 
> Rob, I would concentrate on figuring out what makes Pavel's version work
> for you and the other two not work. Perhaps then we can adjust our
> implementations to address the issue and make you a happy camper :>

Its actually Patrick's version that works for him... But my and
patrick's shoudl be pretty similar, so it should be rather easy to
compare.

Oh and if you will like Patrick's version more and will try to port
some cleanups from his version... Just try to send a patch.

								Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Nigel Cunningham]

Hi.

> > Rob, I would concentrate on figuring out what makes Pavel's version work
> > for you and the other two not work. Perhaps then we can adjust our
> > implementations to address the issue and make you a happy camper :>
> 
> Its actually Patrick's version that works for him... But my and

Err. My typo. I knew what I meant!

Nigel
-- 
Nigel & Michelle Cunningham
C/- Westminster Presbyterian Church Belconnen
61 Templeton Street, Cook, ACT 2614.
+61 (2) 6251 7727(wk); +61 (2) 6254 0216 (home)

Evolution (n): A hypothetical process whereby infinitely improbable events occur 
with alarming frequency, order arises from chaos, and no one is given credit.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Pavel Machek]

Hi!

> Sending money to me won't help either, except with getting support for
> new hardware. I'm working on finding and blatting a little but

Oh and btw theres SMP machine headed my way (actually its P4/HT), so
its possible that swsusp gets SMP support. ... if I can do it without
complicating code too much that is.
									Pavel
-- 
Horseback riding is like software...
...vgf orggre jura vgf serr.

Re: uspend to Disk - Kernel 2.6.4 vs. r50p

[Rob Landley]

On Sunday 09 May 2004 16:49, Pavel Machek wrote:
> Hi!
>
> > > If you suspend, mount
> > > your filesytems, do some work and then resume, you are probably going
> > > to do some pretty nasty corruption. Just don't do that.
> > >
> > > But this problem is shared by swsusp, swsusp2 *and* pmdisk.
> >
> > I know.  I also know that ext2 (and derivatives) have both "last mounted"
> > and "last written to" datestamp fields (other filesystems probably do as
> > well, but I don't use 'em) and it would be really nice to check those as
> > matching what they were when you suspended, and abort the resume if they
> > don't match...
>
> Well, feel free to code that, that will allow us to kill few
> warnings... Or rather tone them down. It is still "dont do that"
> situation.

I'll add it to my endless to-do pile, but don't hold your breath.

> > > > Sigh.  I _really_ don't have time for this right now.  I wonder if it
> > > > would be possible to just send Patrick some money?
> > >
> > > He's out of time, so money is not likely to help. Sending some money
> > > to Nigel might do the trick ;-).
> >
> > His code isn't the one I've gotten to work yet... :)
>
> 2.4 version should be rather easy to get going...
> 									Pavel

The last time I booted a 2.4 kernel was 2003.  Every time Nigel's code is 
mentioned, 2.4 is also mentioned.  I could also downgrade to 2.2 and debug a 
version written for that, too.  It makes about as much sense to me...

I'll try again when 2.6.6 comes out, as usual...

Rob