Patrick's Test9 suspend code.

Patrick's Test9 suspend code.

[Rob Landley]

So a few idiosyncrasies using patrick's suspend code (I.E. the one that 
actually works for me.  Mostly).

1) If you suspend a process (ctrl-z), suspend to disk, and the resume, the 
suspended process is unfrozen.  (Needless to say, this confuses bash job 
control a bit, since my shell is also unfrozen, so ctrl-c isn't doing 
anything here...)  Try it with a big make, it's fun. :)

2) "Snapshotting memory" is _really_slow_ for a CPU bound task on a 900 mhz 
celeron scanning the memory of a machine that has less than 200 megs of ram.  
My guess is that the "suspend all the hardware" phase accidentally put the 
CPU (or memory bus or some such) into a low-power state where it's still 
running, but at maybe 1/10th normal speed.

3) Suspend works about 90% of the time (echo -e "disk" > /sys/blah), but every 
once in a while I have one of two failure cases:

A) Either it panics (and then blanks the screen on my a few seconds later, yes 
I've tried switching that off with setterm -blank, if anything that made it 
happen faster after a panic.)

B) Or it resumes after the snapshot, booting back up to the desktop.  No 
"writing pages to disk" phase (that I've noticed).  Repeatedly telling it to 
suspend when it does this fails the same way, although I got it to suspend by 
exiting X afterwards and suspending from the console.  It's like there's an 
uninitialized variable on the stack that's getting crap in it, or something.  
(Nothing in the log about snapshotting having failed...)

This brings us to 2B) Snapshotting is way too opaque.  It sits there for 15 
seconds sometimes doing inscrutable things, with no progress indicator or 
anything, and then either suspends, panics, or fails and fires the desktop 
back up with no diagnostic message.

On the whole, this is really really cool, and if you have any suggestions how 
I could help, I'm all ears.  (I'm unlikely to poke into the code too 
extensively this week, converting the bzip compression-side code to C is 
still taking up my free time.  I may take a whack at it for kicks if there's 
some low hanging fruit, though.  But that tends to lead me down ratholes (see 
"bzip")...)

Rob

P.S.  Is there a mailing list to discuss this on?  I asked on the swsusp list 
and they said no, that was for discussing the work of nigel and pavel, and 
their stuff doesn't work for me.  I'm happy to be a guinea pig to test out 
new versions.  I backup my laptop regularly. :)

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> This brings us to 2B) Snapshotting is way too opaque.  It sits there for 15 
> seconds sometimes doing inscrutable things, with no progress indicator or 
> anything, and then either suspends, panics, or fails and fires the desktop 
> back up with no diagnostic message.
> 
> On the whole, this is really really cool, and if you have any suggestions how 
> I could help, I'm all ears.  (I'm unlikely to poke into the code too 

Try "my" swsusp code. It should not fail silently; it may
panic the box but at that point you at least have a message.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Thursday 13 November 2003 07:08, Pavel Machek wrote:
> Hi!
>
> > This brings us to 2B) Snapshotting is way too opaque.  It sits there for
> > 15 seconds sometimes doing inscrutable things, with no progress indicator
> > or anything, and then either suspends, panics, or fails and fires the
> > desktop back up with no diagnostic message.
> >
> > On the whole, this is really really cool, and if you have any suggestions
> > how I could help, I'm all ears.  (I'm unlikely to poke into the code too
>
> Try "my" swsusp code. It should not fail silently; it may
> panic the box but at that point you at least have a message.

I've had your swsusp hang, panic, go into a half-suspended state where I have 
to hold the power button ten seconds to actually power it off and reboot, and 
fail in a few other ways.  What I've never actually had your code do is 
successfully suspend something I could resume from.

90% of the time, patrick's code does that for me.  Yours has yet to do so even 
once for me.

I suppose I could give it another shot, though...

Rob

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > > This brings us to 2B) Snapshotting is way too opaque.  It sits there for
> > > 15 seconds sometimes doing inscrutable things, with no progress indicator
> > > or anything, and then either suspends, panics, or fails and fires the
> > > desktop back up with no diagnostic message.
> > >
> > > On the whole, this is really really cool, and if you have any suggestions
> > > how I could help, I'm all ears.  (I'm unlikely to poke into the code too
> >
> > Try "my" swsusp code. It should not fail silently; it may
> > panic the box but at that point you at least have a message.
> 
> I've had your swsusp hang, panic, go into a half-suspended state where I have 
> to hold the power button ten seconds to actually power it off and reboot, and 
> fail in a few other ways.  What I've never actually had your code do is 
> successfully suspend something I could resume from.
> 
> 90% of the time, patrick's code does that for me.  Yours has yet to do so even 
> once for me.
> 
> I suppose I could give it another shot, though...

Strange, they should be pretty much the same, functionality-wise.

Here are few tricks... OTOH if it works for you 90% of time, these
would take a lot of time to test :-(.

If you want to trick swsusp/S3 into working, you might want to try:

* go with minimal config, turn off drivers like USB, AGP you don't
really need

* use ext2. At least it has working fsck. [If something seemes to go
  wrong, force fsck when you have a chance]

* turn off modules

* use vga text console, shut down X

* try running as few processes as possible, preferably go from single
use mode

When you make it work, try to find out what exactly was it that broke
suspend, and preferably fix that.

								Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Sunday 16 November 2003 07:13, Pavel Machek wrote:
> Hi!
>
> > > > This brings us to 2B) Snapshotting is way too opaque.  It sits there
> > > > for 15 seconds sometimes doing inscrutable things, with no progress
> > > > indicator or anything, and then either suspends, panics, or fails and
> > > > fires the desktop back up with no diagnostic message.
> > > >
> > > > On the whole, this is really really cool, and if you have any
> > > > suggestions how I could help, I'm all ears.  (I'm unlikely to poke
> > > > into the code too
> > >
> > > Try "my" swsusp code. It should not fail silently; it may
> > > panic the box but at that point you at least have a message.
> >
> > I've had your swsusp hang, panic, go into a half-suspended state where I
> > have to hold the power button ten seconds to actually power it off and
> > reboot, and fail in a few other ways.  What I've never actually had your
> > code do is successfully suspend something I could resume from.
> >
> > 90% of the time, patrick's code does that for me.  Yours has yet to do so
> > even once for me.
> >
> > I suppose I could give it another shot, though...
>
> Strange, they should be pretty much the same, functionality-wise.

Well, I gave your code another try.  It blanked the screen during the 
"powering down devices" stage so I didn't see what it did after that, but a 
full minute later it had stopped accessing the hard drive for rather a long 
time, but the power was still on (except for the screen), so I switched it 
off.  On reboot, it didn't resume from swap (normal boot with fsck instead) 
but I had to do a mkswap to get my swap file back.

On the other hand, playing around with something else I accidentally overwrote 
my backup .config file with a bad one instead of the other way 'round, and 
I've been redoing it from scratch (and realising how badly horked menuconfig 
is.  (The pc speaker isn't under sound, it's under misc at the end of the 
input core, real obvious place for it...  USB isn't considered a bus, it's 
under the devices menu...  and even though USB has all USB devices under the 
usb menu (including USB ethernet), pcmcia doesn't have all pcmcia devices 
under the pcmcia menu, you have to enable pcmcia and then go into the network 
devices menu where PCMCIA wireless devices are mixed in with non-802.11 
wireless devices from the dawn of time...)

I miss my .config file.

Currently, patrick's code isn't working for me anymore either.  I think it's 
because I haven't figured out how I had ACPI set up last time (performance 
covernor, probably.  If I tell it to use the userspace governor, there's 
still nothing in /sys/devices/system/cpu/cpu0, the directory is empty.  Maybe 
the documentation isn't up to date anymore, I don't know...)  When I tried to 
suspend with it, it sort of worked but the writing to disk phase (which never 
caused a problem before) had a visible pause between each sector written, and 
writing out the 3000 sectors took over 5 minutes, and the end result wasn't 
something it could resume from anyway.  Sigh...

I would appear to have stirred up all the sediment in my configuration, and 
broken both suspend implementations with unrelated pokes to the rest of the 
kernel.  That said, you've replied to me more than once, and although I've 
been posting questions and comments about software suspend for a month now 
(ever since http://lists.insecure.org/lists/linux-kernel/2003/Oct/4175.html), 
and emailed patrick directly at least three times, I've never heard back from 
him.  I have at least heard back from you.

> Here are few tricks... OTOH if it works for you 90% of time, these
> would take a lot of time to test :-(.
>
> If you want to trick swsusp/S3 into working, you might want to try:
>
> * go with minimal config, turn off drivers like USB, AGP you don't
> really need

usb and agp were both compiled in to the kernel that worked (not modular).  It 
never seemed to be dying due to the HARDWARE, it always shut all the hardware 
down just fine...

> * use ext2. At least it has working fsck. [If something seemes to go
>   wrong, force fsck when you have a chance]

I use ext3, which fscks as ext2.  And yes, I force fsck whenver something 
really goes "boing".

> * turn off modules
>
> * use vga text console, shut down X
>
> * try running as few processes as possible, preferably go from single
> use mode

Every single time I've tried your code I've done so from the console of a 
freshly booted system, without ever having run X.

Patrick's code I almost always suspended from X, and it worked....

> When you make it work, try to find out what exactly was it that broke
> suspend, and preferably fix that.

I think what broke patrick's suspend is that I redid the ACPI options, 
possibly some other stuff.  If I have to shut down 2/3 of my system to have a 
chance of making your stuff work, I think I'll go back to thumping on 
patrick's.  Abandoned codebase or not, it still used to work for me the 
majority of the time in X, with my pcmcia wireless network card up and 
running and USB loaded and everything...

> 								Pavel

Rob

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > Strange, they should be pretty much the same, functionality-wise.
> 
> Well, I gave your code another try.  It blanked the screen during the 
> "powering down devices" stage so I didn't see what it did after that, but a 
> full minute later it had stopped accessing the hard drive for rather a long 
> time, but the power was still on (except for the screen), so I switched it 
> off.  On reboot, it didn't resume from swap (normal boot with fsck instead) 
> but I had to do a mkswap to get my swap file back.

If you had to re-mkswap, that means suspend was indeed
successfull. Did you pass right resume= option? What did
kernel say when it refused to resume?

> covernor, probably.  If I tell it to use the userspace governor, there's 
> still nothing in /sys/devices/system/cpu/cpu0, the directory is empty.  Maybe 
> the documentation isn't up to date anymore, I don't know...)  When I tried to 
> suspend with it, it sort of worked but the writing to disk phase (which never 
> caused a problem before) had a visible pause between each sector written, and 
> writing out the 3000 sectors took over 5 minutes, and the end result wasn't 
> something it could resume from anyway.  Sigh...

Hmm, I've seen something similar, but result was ok at the end.
It only took very long time.

> > * go with minimal config, turn off drivers like USB, AGP you don't
> > really need
> 
> usb and agp were both compiled in to the kernel that worked (not modular).  It 
> never seemed to be dying due to the HARDWARE, it always shut all the hardware 
> down just fine...

You really should try without AGP. It has no support => it
will happily crash your machine at unrelated point during
resume.
				Pavel
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Patrick's Test9 suspend code.

[Patrick Mochel]

> Currently, patrick's code isn't working for me anymore either.  I think it's 
> because I haven't figured out how I had ACPI set up last time (performance 
> covernor, probably.  If I tell it to use the userspace governor, there's 
> still nothing in /sys/devices/system/cpu/cpu0, the directory is empty.  Maybe 
> the documentation isn't up to date anymore, I don't know...)  When I tried to 
> suspend with it, it sort of worked but the writing to disk phase (which never 
> caused a problem before) had a visible pause between each sector written, and 
> writing out the 3000 sectors took over 5 minutes, and the end result wasn't 
> something it could resume from anyway.  Sigh...

Are you using preempt? There was a similar problem reported a while back 
that was solved by disabling it. Though it's not a true fix, it should at 
least get you going again.

Thanks,


	Pat

Re: Patrick's Test9 suspend code.

[Rob Landley]

You live!

Cool. :)

On Monday 17 November 2003 10:45, Patrick Mochel wrote:
> > Currently, patrick's code isn't working for me anymore either.  I think
> > it's because I haven't figured out how I had ACPI set up last time
> > (performance covernor, probably.  If I tell it to use the userspace
> > governor, there's still nothing in /sys/devices/system/cpu/cpu0, the
> > directory is empty.  Maybe the documentation isn't up to date anymore, I
> > don't know...)  When I tried to suspend with it, it sort of worked but
> > the writing to disk phase (which never caused a problem before) had a
> > visible pause between each sector written, and writing out the 3000
> > sectors took over 5 minutes, and the end result wasn't something it could
> > resume from anyway.  Sigh...
>
> Are you using preempt? There was a similar problem reported a while back
> that was solved by disabling it. Though it's not a true fix, it should at
> least get you going again.

That might explain some stuff.  I'm now getting messages from my orinoco card 
during the writing phase about negotiating to talk with the access point, 
which is interfering with the writing of the dots.  That didn't happen 
before.

Might it also be possible to just invent a new spinlock, grab it at the start 
of suspend, and release it at the end of resume?  (It's not like suspend 
really needs to be preempted.  I vaguely remember a "disable_preempt" call, 
but haven't a clue what it or its semantics might actually be.)

I have an appointment in half an hour but I'll give it a shot this evening. 

Thanks.

> Thanks,
>
>
> 	Pat

Rob

Re: Patrick's Test9 suspend code.

[Rob Landley]

[-- Attachment #1: Type: text/plain, Size: 2753 bytes --]

On Monday 17 November 2003 10:45, Patrick Mochel wrote:
> > Currently, patrick's code isn't working for me anymore either.  I think
> > it's because I haven't figured out how I had ACPI set up last time
> > (performance covernor, probably.  If I tell it to use the userspace
> > governor, there's still nothing in /sys/devices/system/cpu/cpu0, the
> > directory is empty.  Maybe the documentation isn't up to date anymore, I
> > don't know...)  When I tried to suspend with it, it sort of worked but
> > the writing to disk phase (which never caused a problem before) had a
> > visible pause between each sector written, and writing out the 3000
> > sectors took over 5 minutes, and the end result wasn't something it could
> > resume from anyway.  Sigh...
>
> Are you using preempt? There was a similar problem reported a while back
> that was solved by disabling it. Though it's not a true fix, it should at
> least get you going again.
>
> Thanks,
>
>
> 	Pat

Finally got it working again.  Disabling preempt didn't seem to fix anything, 
but I've left it off for now anyway.  Module unload support also wasn't 
selected, and that could have been causing problems too.  (It certainly 
confused cardbus and my shutdown scripts...)

The actual save part was slow because DMA was off (I had generic dma on, but 
on a laptop with an ALI M5229 IDE controller you need to enable ALI M15x9 
DMA.  Right.)  Writing out pages is AMAZINGLY slow in PIO mode, by the way.  
5 minutes vs 5 seconds kind of slow...

It then saved happily but didn't resume because I hadn't told it the default 
resume partition was /dev/hda2.  (I don't have to specify which partition to 
save to, why do I have to specify which one to resume from?  Oh well...)

And lo, I hath once again resumed!  (My copy of the suspend code still has a 
large number of printk statements in it, but at the moment I consider that a 
GOOD thing.)

On another note, here's a panic I managed to save when one of the suspend 
attempts decided to go "boing", yet dumped me back to a console that sort of 
worked for a bit until I tried to shutdown, where it hung shutting down 
pcmcia.  (Amazingly, it didn't seem to eat my filesystem when I sent dmesg to 
a file.  Go figure.)

I don't believe this has anything to do with the prink statements or config 
tweaks I was doing, this is one of those intermittent panics I mentioned 
earlier where it tries to save and bits wind up on the floor.  This is from a 
system that, right after it booted, I immediately logged in (text console 1) 
and ran my suspend script, which got as far as "sync; echo -n disk > 
/sys/power/state" and panicked trying to stop all the tasks.  X had not run.

Let me know if there's something more recent I should try...

Rob

[-- Attachment #2: out.txt --]
[-- Type: text/plain, Size: 9724 bytes --]

Linux version 2.6.0-test9-ook (root@localhost.localdomain) (gcc version 3.2.2 20030222 (Red Hat Linux 3.2.2-5)) #5 SMP Tue Nov 18 04:20:47 CST 2003
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000000b7e0000 (usable)
 BIOS-e820: 000000000b7e0000 - 000000000b7f0000 (reserved)
 BIOS-e820: 000000000b7f0000 - 000000000b7f8000 (ACPI data)
 BIOS-e820: 000000000b7f8000 - 000000000b800000 (ACPI NVS)
 BIOS-e820: 00000000ffff0000 - 0000000100000000 (reserved)
183MB LOWMEM available.
On node 0 totalpages: 47072
  DMA zone: 4096 pages, LIFO batch:1
  Normal zone: 42976 pages, LIFO batch:10
  HighMem zone: 0 pages, LIFO batch:1
DMI not present.
ACPI: RSDP (v000 IBM                                       ) @ 0x000eab70
ACPI: RSDT (v001 IBM    AXXXXXX4 0x00000001 IBM  0x00000000) @ 0x0b7f0000
ACPI: FADT (v001 IBM    AXXXXXX4 0x00000001 IBM  0x00000000) @ 0x0b7f008c
ACPI: BOOT (v001 IBM    AXXXXXX4 0x00000001 IBM  0x00000000) @ 0x0b7f0030
ACPI: DBGP (v001 IBM    AXXXXXX4 0x00000001 IBM  0x00000000) @ 0x0b7f0058
ACPI: DSDT (v001    IBM AXXXXXX4 0x00000001 MSFT 0x0100000c) @ 0x00000000
Building zonelist for node : 0
Kernel command line: ro root=/dev/hda1
Local APIC disabled by BIOS -- reenabling.
Could not enable APIC!
Initializing CPU#0
PID hash table entries: 1024 (order 10: 8192 bytes)
Detected 697.823 MHz processor.
Console: colour VGA+ 80x25
Memory: 181736k/188288k available (2205k kernel code, 5932k reserved, 978k data, 152k init, 0k highmem)
Calibrating delay loop... 1368.06 BogoMIPS
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Mount-cache hash table entries: 512 (order: 0, 4096 bytes)
checking if image is initramfs...it isn't (no cpio magic); looks like an initrd
Freeing initrd memory: 219k freed
CPU:     After generic identify, caps: 0383f9ff 00000000 00000000 00000000
CPU:     After vendor identify, caps: 0383f9ff 00000000 00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 128K
CPU:     After all inits, caps: 0383f9ff 00000000 00000000 00000040
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
CPU0: Intel Celeron (Coppermine) stepping 06
per-CPU timeslice cutoff: 365.89 usecs.
task migration cache decay timeout: 1 msecs.
SMP motherboard not detected.
Local APIC not detected. Using dummy APIC emulation.
Starting migration thread for cpu 0
CPUS done 8
NET: Registered protocol family 16
PCI: PCI BIOS revision 2.10 entry at 0xf0200, last bus=1
PCI: Using configuration type 1
mtrr: v2.0 (20020519)
ACPI: Subsystem revision 20031002
ACPI: IRQ 9 was Edge Triggered, setting to Level Triggerd
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Interrupt Link [PILA] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [PILB] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [PILC] (IRQs 1 3 4 5 *6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [PILD] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Interrupt Link [PILE] (IRQs 1 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [PILF] (IRQs 1 3 4 5 6 7 10 11 12 14 15)
ACPI: PCI Interrupt Link [PILG] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILH] (IRQs 1 3 4 5 6 7 10 *11 12 14 15)
ACPI: PCI Interrupt Link [PILI] (IRQs 1 3 4 5 6 7 *10 11 12 14 15)
ACPI: PCI Root Bridge [PCI0] (00:00)
PCI: Probing PCI hardware (bus 00)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: Embedded Controller [EC0] (gpe 34)
Linux Plug and Play Support v0.97 (c) Adam Belay
SCSI subsystem initialized
drivers/usb/core/usb.c: registered new driver usbfs
drivers/usb/core/usb.c: registered new driver hub
ACPI: PCI Interrupt Link [PILH] enabled at IRQ 11
ACPI: PCI Interrupt Link [PILC] enabled at IRQ 6
ACPI: No IRQ known for interrupt pin A of device 0000:00:10.0 - using IRQ 15
ACPI: PCI Interrupt Link [PILD] enabled at IRQ 10
ACPI: PCI Interrupt Link [PILI] enabled at IRQ 10
ACPI: PCI Interrupt Link [PILA] enabled at IRQ 10
PCI: Using ACPI for IRQ routing
PCI: if you experience problems, try using option 'pci=noacpi' or even 'acpi=off'
SBF: Simple Boot Flag extension found and enabled.
SBF: Setting boot flags 0x80
Machine check exception polling timer started.
Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
udf: registering filesystem
ACPI: AC Adapter [AC] (on-line)
ACPI: Battery Slot [BAT0] (battery present)
ACPI: Power Button (FF) [PWRF]
ACPI: Sleep Button (CM) [SLPB]
ACPI: Lid Switch [LID]
ACPI: Processor [CPU0] (supports C1 C2 C3)
ACPI: Thermal Zone [THR2] (54 C)
pty: 256 Unix98 ptys configured
request_module: failed /sbin/modprobe -- parport_lowlevel. error = -16
lp: driver loaded but no devices found
Linux agpgart interface v0.100 (c) Dave Jones
[drm:drm_init] *ERROR* Cannot initialize the agpgart module.
Serial: 8250/16550 driver $Revision: 1.90 $ 8 ports, IRQ sharing disabled
parport0: PC-style at 0x3bc [PCSPP(,...)]
lp0: using parport0 (polling).
Using anticipatory io scheduler
Floppy drive(s): fd0 is unknown type 12 (usb?)
floppy0: no floppy controllers found
loop: loaded (max 8 devices)
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
hda: IBM-DJSA-220, ATA DISK drive
hdc: UJDA330, ATAPI CD/DVD-ROM drive
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB) w/1874KiB Cache, CHS=38760/16/63
 hda: hda1 hda2 hda3
hdc: ATAPI 24X CD-ROM CD-R/RW drive, 2048kB Cache
Uniform CD-ROM driver Revision: 3.12
drivers/usb/host/uhci-hcd.c: USB Universal Host Controller Interface driver v2.1
drivers/usb/core/usb.c: registered new driver usblp
drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
Initializing USB Mass Storage driver...
drivers/usb/core/usb.c: registered new driver usb-storage
USB Mass Storage support registered.
drivers/usb/core/usb.c: registered new driver hid
drivers/usb/input/hid-core.c: v2.0:USB HID core driver
mice: PS/2 mouse device common for all mice
input: PS/2 Generic Mouse on isa0060/serio1
serio: i8042 AUX port at 0x60,0x64 irq 12
input: AT Translated Set 2 keyboard on isa0060/serio0
serio: i8042 KBD port at 0x60,0x64 irq 1
Advanced Linux Sound Architecture Driver Version 0.9.7 (Thu Sep 25 19:16:36 2003 UTC).
request_module: failed /sbin/modprobe -- snd-card-0. error = -16
ALSA device list:
  No soundcards found.
NET: Registered protocol family 2
IP: routing cache hash table of 1024 buckets, 8Kbytes
TCP: Hash tables configured (established 16384 bind 16384)
NET: Registered protocol family 1
NET: Registered protocol family 17
PM: Reading pmdisk image.
PM: Resume from disk failed.
ACPI: (supports S0 S1 S4 S5)
EXT3-fs: INFO: recovery required on readonly filesystem.
EXT3-fs: write access will be enabled during recovery.
kjournald starting.  Commit interval 5 seconds
EXT3-fs: recovery complete.
EXT3-fs: mounted filesystem with ordered data mode.
VFS: Mounted root (ext3 filesystem) readonly.
Freeing unused kernel memory: 152k freed
spurious 8259A interrupt: IRQ7.
EXT3 FS on hda1, internal journal
Unable to find swap-space signature
kjournald starting.  Commit interval 5 seconds
EXT3 FS on hda3, internal journal
EXT3-fs: mounted filesystem with ordered data mode.
Unable to find swap-space signature
pcmcia_core: falsely claims to have parameter  [8Áset_delay
Linux Kernel Card Services
  options:  [pci] [cardbus] [pm]
PCI: Enabling device 0000:00:0a.0 (0000 -> 0002)
Yenta: CardBus bridge found at 0000:00:0a.0 [12a3:ab01]
Yenta: Enabling burst memory read transactions
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta: ISA IRQ list 0000, PCI irq6
Socket status: 30000011
Yenta: CardBus bridge found at 0000:00:13.0 [1014:01a3]
Yenta: ISA IRQ list 0838, PCI irq10
Socket status: 30000007
cs: IO port probe 0x0c00-0x0cff: clean.
cs: IO port probe 0x0100-0x04ff: excluding 0x2c8-0x2cf 0x3c0-0x3df 0x408-0x40f 0x480-0x48f 0x4d0-0x4d7
cs: IO port probe 0x0a00-0x0aff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
Unable to handle kernel paging request at virtual address cc044120
 printing eip:
c0131bf3
*pde = 01276067
*pte = 00000000
Oops: 0002 [#1]
CPU:    0
EIP:    0060:[<c0131bf3>]    Not tainted
EFLAGS: 00010246
EIP is at module_unload_init+0xe/0x52
eax: cc044120   ebx: cc036df0   ecx: cc043c20   edx: 00000000
esi: cc039cef   edi: cc0436ff   ebp: c4e1ff28   esp: c4e1ff28
ds: 007b   es: 007b   ss: 0068
Process modprobe (pid: 920, threadinfo=c4e1e000 task=c4ba7310)
Stack: c4e1ff9c c0133364 cc043c20 00000000 000003e8 cb015da0 cc013000 00000000 
       cc043c20 00000000 00000000 00000000 00000000 00000000 00000008 00000012 
       00000010 0000000c 00000000 00000000 00000018 00000017 00000019 cc0393e0 
Call Trace:
 [<c0133364>] load_module+0x4d8/0x7f7
 [<c01336fa>] sys_init_module+0x77/0x234
 [<c0108f85>] sysenter_past_esp+0x52/0x71

Code: 89 81 00 05 00 00 89 81 04 05 00 00 89 c8 42 c7 80 00 01 00 
 Stopping tasks: ============================
 stopping tasks failed (1 tasks remaining)
Restarting tasks...<6> Strange, modprobe not stopped
 done

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> It then saved happily but didn't resume because I hadn't told it the default 
> resume partition was /dev/hda2.  (I don't have to specify which partition to 
> save to, why do I have to specify which one to resume from?  Oh
> well...)

Think again. How is kernel expected to find out partition which it
should resume from? Try all of them?

You did swapon before suspend, that's where you specified "which
partition". You need to tell it what to resume from...

> Unable to handle kernel paging request at virtual address cc044120
>  printing eip:
> c0131bf3
> *pde = 01276067
> *pte = 00000000
> Oops: 0002 [#1]
> CPU:    0
> EIP:    0060:[<c0131bf3>]    Not tainted
> EFLAGS: 00010246
> EIP is at module_unload_init+0xe/0x52
> eax: cc044120   ebx: cc036df0   ecx: cc043c20   edx: 00000000
> esi: cc039cef   edi: cc0436ff   ebp: c4e1ff28   esp: c4e1ff28
> ds: 007b   es: 007b   ss: 0068
> Process modprobe (pid: 920, threadinfo=c4e1e000 task=c4ba7310)
> Stack: c4e1ff9c c0133364 cc043c20 00000000 000003e8 cb015da0 cc013000 00000000 
>        cc043c20 00000000 00000000 00000000 00000000 00000000 00000008 00000012 
>        00000010 0000000c 00000000 00000000 00000018 00000017 00000019 cc0393e0 
> Call Trace:
>  [<c0133364>] load_module+0x4d8/0x7f7
>  [<c01336fa>] sys_init_module+0x77/0x234
>  [<c0108f85>] sysenter_past_esp+0x52/0x71
> 
> Code: 89 81 00 05 00 00 89 81 04 05 00 00 89 c8 42 c7 80 00 01 00 
>  Stopping tasks: ============================
>  stopping tasks failed (1 tasks remaining)
> Restarting tasks...<6> Strange, modprobe not stopped
>  done

Strange, it looks like you tried suspending in the middle of module
being [un]loaded?
								Pavel


-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Tuesday 18 November 2003 12:22, Pavel Machek wrote:
> Hi!
>
> > It then saved happily but didn't resume because I hadn't told it the
> > default resume partition was /dev/hda2.  (I don't have to specify which
> > partition to save to, why do I have to specify which one to resume from? 
> > Oh
> > well...)
>
> Think again. How is kernel expected to find out partition which it
> should resume from? Try all of them?
>
> You did swapon before suspend, that's where you specified "which
> partition". You need to tell it what to resume from...

I know.  Then again, if grub can read ext2... :)

Better would be the initramfs stuff, though.  If there's a way to trigger a 
resume that kills all running processes and loads userspace from the swap 
partition, then you could do that from initramfs _after_ finding /root a 
checking fstab, life is good.  (of course ext3 is brain-dead enough to always 
replay the journal even if it mounts read-only, so you'd have to mount it 
ext2 or something...  Hmmm...)

> > Unable to handle kernel paging request at virtual address cc044120
> >  printing eip:
> > c0131bf3
> > *pde = 01276067
> > *pte = 00000000
> > Oops: 0002 [#1]
> > CPU:    0
> > EIP:    0060:[<c0131bf3>]    Not tainted
> > EFLAGS: 00010246
> > EIP is at module_unload_init+0xe/0x52
> > eax: cc044120   ebx: cc036df0   ecx: cc043c20   edx: 00000000
> > esi: cc039cef   edi: cc0436ff   ebp: c4e1ff28   esp: c4e1ff28
> > ds: 007b   es: 007b   ss: 0068
> > Process modprobe (pid: 920, threadinfo=c4e1e000 task=c4ba7310)
> > Stack: c4e1ff9c c0133364 cc043c20 00000000 000003e8 cb015da0 cc013000
> > 00000000 cc043c20 00000000 00000000 00000000 00000000 00000000 00000008
> > 00000012 00000010 0000000c 00000000 00000000 00000018 00000017 00000019
> > cc0393e0 Call Trace:
> >  [<c0133364>] load_module+0x4d8/0x7f7
> >  [<c01336fa>] sys_init_module+0x77/0x234
> >  [<c0108f85>] sysenter_past_esp+0x52/0x71
> >
> > Code: 89 81 00 05 00 00 89 81 04 05 00 00 89 c8 42 c7 80 00 01 00
> >  Stopping tasks: ============================
> >  stopping tasks failed (1 tasks remaining)
> > Restarting tasks...<6> Strange, modprobe not stopped
> >  done
>
> Strange, it looks like you tried suspending in the middle of module
> being [un]loaded?

This was _right_ after the system booted up.  Possibly hotplug was still 
finding stuff, or the pcmcia wireless card had just decided it had found its 
access point, or some such...

These kinds of asynchronous module loads and unloads do happen.  The orinoco 
card driver is broken enough to sometimes decide that when it loses 
connection with the access point, instead of toggling the link status it 
decides the card has been unplugged!  (Real pain when that happens, by the 
way...)

So I can imagine modprobe was running, yeah.  But I hadn't done it personally.

> 								Pavel

Rob

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > > It then saved happily but didn't resume because I hadn't told it the
> > > default resume partition was /dev/hda2.  (I don't have to specify which
> > > partition to save to, why do I have to specify which one to resume from? 
> > > Oh
> > > well...)
> >
> > Think again. How is kernel expected to find out partition which it
> > should resume from? Try all of them?
> >
> > You did swapon before suspend, that's where you specified "which
> > partition". You need to tell it what to resume from...
> 
> I know.  Then again, if grub can read ext2... :)

:-), Okay, we could make grub read /etc/fstab... But again user can do
swapoff and swapon manually etc.

> Better would be the initramfs stuff, though.  If there's a way to trigger a 
> resume that kills all running processes and loads userspace from the swap 
> partition, then you could do that from initramfs _after_ finding /root a 
> checking fstab, life is good.  (of course ext3 is brain-dead enough to always 
> replay the journal even if it mounts read-only, so you'd have to mount it 
> ext2 or something...  Hmmm...)

Having sto stop userspace processes and bring hardware back to some
sane state would complicate swsusp (and its testing!) a lot. Maybe in
2.8 when it works perfectly in other cases....

> > Strange, it looks like you tried suspending in the middle of module
> > being [un]loaded?
> 
> This was _right_ after the system booted up.  Possibly hotplug was still 
> finding stuff, or the pcmcia wireless card had just decided it had found its 
> access point, or some such...
> 
> These kinds of asynchronous module loads and unloads do happen.  The orinoco 
> card driver is broken enough to sometimes decide that when it loses 
> connection with the access point, instead of toggling the link status it 
> decides the card has been unplugged!  (Real pain when that happens, by the 
> way...)
> 
> So I can imagine modprobe was running, yeah.  But I hadn't done it personally.

I'd attribute it to buggy module.  If you can reproduce it you can try
to fix it....

....but swsusp with modular kernels... I'm not sure if it can even
work. .. yes it can but you really should get it working monolithic, first.

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

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Tuesday 18 November 2003 17:21, Pavel Machek wrote:
> Hi!
>
> > > > It then saved happily but didn't resume because I hadn't told it the
> > > > default resume partition was /dev/hda2.  (I don't have to specify
> > > > which partition to save to, why do I have to specify which one to
> > > > resume from? Oh
> > > > well...)
> > >
> > > Think again. How is kernel expected to find out partition which it
> > > should resume from? Try all of them?
> > >
> > > You did swapon before suspend, that's where you specified "which
> > > partition". You need to tell it what to resume from...
> >
> > I know.  Then again, if grub can read ext2... :)
> >
> :-), Okay, we could make grub read /etc/fstab... But again user can do
>
> swapoff and swapon manually etc.

During resume?

> > Better would be the initramfs stuff, though.  If there's a way to trigger
> > a resume that kills all running processes and loads userspace from the
> > swap partition, then you could do that from initramfs _after_ finding
> > /root a checking fstab, life is good.  (of course ext3 is brain-dead
> > enough to always replay the journal even if it mounts read-only, so you'd
> > have to mount it ext2 or something...  Hmmm...)
>
> Having sto stop userspace processes and bring hardware back to some
> sane state would complicate swsusp (and its testing!) a lot. Maybe in
> 2.8 when it works perfectly in other cases....

If there's only one "init" style task running from initramfs, which simply 
looks at the partitions and gets the info it needs from disk labels or 
something without actually mounting a filesystem (or mounts it read only, no 
journal playback, and then unmounts it again afterwards...)  And then the 
system call/whatever it does is sematically "exit and resume from swap"...

There might have to be some way to plug the hotplug event queue, though.  I 
don't know enough about what's involved in the interaction between hotplug 
and suspend...

> > > Strange, it looks like you tried suspending in the middle of module
> > > being [un]loaded?
> >
> > This was _right_ after the system booted up.  Possibly hotplug was still
> > finding stuff, or the pcmcia wireless card had just decided it had found
> > its access point, or some such...
> >
> > These kinds of asynchronous module loads and unloads do happen.  The
> > orinoco card driver is broken enough to sometimes decide that when it
> > loses connection with the access point, instead of toggling the link
> > status it decides the card has been unplugged!  (Real pain when that
> > happens, by the way...)
> >
> > So I can imagine modprobe was running, yeah.  But I hadn't done it
> > personally.
>
> I'd attribute it to buggy module.  If you can reproduce it you can try
> to fix it....
>
> ....but swsusp with modular kernels... I'm not sure if it can even
> work. .. yes it can but you really should get it working monolithic, first.

Okay.  Tell me how to get hotplug devices (cardbus, usb) working 
monolithically, and I'm all for it.

They mostly work now.  I've currently got these loaded:

orinoco_cs 7432 1 - Live 0xcc072000
orinoco 37508 1 orinoco_cs, Live 0xcc07f000
hermes 7936 2 orinoco_cs,orinoco, Live 0xcc06f000
ds 11264 5 orinoco_cs, Live 0xcc06b000
yenta_socket 14080 1 - Live 0xcc050000
pcmcia_core 58624 3 orinoco_cs,ds,yenta_socket, Live 0xcc05b000

> 								Pavel

Rob

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > :-), Okay, we could make grub read /etc/fstab... But again user can do
> >
> > swapoff and swapon manually etc.
> 
> During resume?

No, imagine /dev/hda3 being set as swap in /etc/fstab, but user doing
swapoff /dev/hda3, swapon /dev/usb_zip_drive, then suspend.

/etc/mtab would be better choice, but swap does not appear there.

> > Having sto stop userspace processes and bring hardware back to some
> > sane state would complicate swsusp (and its testing!) a lot. Maybe in
> > 2.8 when it works perfectly in other cases....
> 
> If there's only one "init" style task running from initramfs, which simply 
> looks at the partitions and gets the info it needs from disk labels or 
> something without actually mounting a filesystem (or mounts it read only, no 
> journal playback, and then unmounts it again afterwards...)  And then the 
> system call/whatever it does is sematically "exit and resume from
> swap"...

Well, I'd hate to write docs for that system call.

"It is exit and resume from specified swap, you must not write any
disk before you call it, must not access (list) devices, must not
access any network."

> > ....but swsusp with modular kernels... I'm not sure if it can even
> > work. .. yes it can but you really should get it working monolithic, first.
> 
> Okay.  Tell me how to get hotplug devices (cardbus, usb) working 
> monolithically, and I'm all for it.

Well, just compile all the drivers you need in, and it just
works.... I'm using both cardbus and usb and no, I'm not using
modules.

							Pavel

-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Wednesday 19 November 2003 03:18, Pavel Machek wrote:
> Hi!
>
> > > :-), Okay, we could make grub read /etc/fstab... But again user can do
> > >
> > > swapoff and swapon manually etc.
> >
> > During resume?
>
> No, imagine /dev/hda3 being set as swap in /etc/fstab, but user doing
> swapoff /dev/hda3, swapon /dev/usb_zip_drive, then suspend.

A) Any scheme we come up with there will be a way the user can do something 
stupid enough to break it.  (Put the swap partition on a ramdisk living on 
the video card, or on a device require an initrd to load the driver to 
access...)

B) A heuristic that looks at the mounted block devices for things that smell 
like a resume partition would actually be more robust in that case.

> /etc/mtab would be better choice, but swap does not appear there.

Okay, so why is /etc/mtab not supposed to be a link to /proc/mounts again?  
(Especially since we're migrating to a per-process view of the mount tree...)

> > > Having sto stop userspace processes and bring hardware back to some
> > > sane state would complicate swsusp (and its testing!) a lot. Maybe in
> > > 2.8 when it works perfectly in other cases....
> >
> > If there's only one "init" style task running from initramfs, which
> > simply looks at the partitions and gets the info it needs from disk
> > labels or something without actually mounting a filesystem (or mounts it
> > read only, no journal playback, and then unmounts it again afterwards...)
> >  And then the system call/whatever it does is sematically "exit and
> > resume from swap"...
>
> Well, I'd hate to write docs for that system call.
>
> "It is exit and resume from specified swap, you must not write any
> disk before you call it, must not access (list) devices, must not
> access any network."

The alternative is putting a heuristic in either the kernel or grub that 
identifies your resume partition.  The grub hack might not be so bad if 
there's a symlink somewhere that points to the resume partition.  
/etc/resume, /dev/resume, /boot/resume...  Dunno.  Read only root partitions 
don't make this easy...

The objection's largely to having it hardwired into the kernel, but I suppose 
if you now have to specify the root on the kernel command line, having to 
specify resume isn't noticeably worse...

> > > ....but swsusp with modular kernels... I'm not sure if it can even
> > > work. .. yes it can but you really should get it working monolithic,
> > > first.
> >
> > Okay.  Tell me how to get hotplug devices (cardbus, usb) working
> > monolithically, and I'm all for it.
>
> Well, just compile all the drivers you need in, and it just
> works.... I'm using both cardbus and usb and no, I'm not using
> modules.

It was unhappy last time I tried it, but that was several months back.  Worth 
a shot...

> 							Pavel

Rob

Re: Patrick's Test9 suspend code.

[Nigel Cunningham]

Unfortunately, I don't :> I'm doing most of the development work on my
Omnibook XE3, which has a 10GB HDD. Nevertheless, I fully agree with
your point.

Regards,

Nigel

On Fri, 2003-11-21 at 19:46, Rob Landley wrote:
> On Thursday 20 November 2003 16:41, Nigel Cunningham wrote:
> 
> > Whenever I switch from testing a 2.4 kernel to testing 2.6, I do a clean
> > boot for precisely this reason. I'd love it if I could just suspend 2.4,
> > boot the new 2.6 kernel, see if it suspends properly (to a different
> > swap, of course) and then resume the original 2.4 kernel. But doing so
> > would only work if I mounted 2.6 entirely read only, which is not what
> > you seem to be planning.
> 
> You could of course have two completely different sets of root and swap 
> partitions, if you have the disk space.  (And either not sharing /home or 
> unmount it before suspending...)
> 
> Assuming you have the disk space, of course. :)
> 
> Rob
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

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

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Thursday 20 November 2003 16:41, Nigel Cunningham wrote:

> Whenever I switch from testing a 2.4 kernel to testing 2.6, I do a clean
> boot for precisely this reason. I'd love it if I could just suspend 2.4,
> boot the new 2.6 kernel, see if it suspends properly (to a different
> swap, of course) and then resume the original 2.4 kernel. But doing so
> would only work if I mounted 2.6 entirely read only, which is not what
> you seem to be planning.

You could of course have two completely different sets of root and swap 
partitions, if you have the disk space.  (And either not sharing /home or 
unmount it before suspending...)

Assuming you have the disk space, of course. :)

Rob

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > B) A heuristic that looks at the mounted block devices for things that smell 
> > like a resume partition would actually be more robust in that case.
> 
> How about a static signature followed by a timestamp? That way, maybe we could 
> have a resume menu like this:
> 
> /dev/hda3  (kernel 2.7.88, suspended on 01-04-2004 20:00:00)
> /dev/hda4  (kernel 2.8.99, suspended on 31-05-2005 20:00:00) ***
> Resume in 5..4..3..2..1..
> 
> with a 5 second countdown before it chooses the most recent? Or in Pavel's 
> examples:
> 
> Erk! Nowhere to resume from! 

If you select hda3 at this point, bye bye your data.

									Pavel
PS: And I mean it. This is not just your average "few more files in
lost+found" kind of corruption.
-- 
When do you have a heart between your knees?
[Johanka's followup: and *two* hearts?]

Re: Patrick's Test9 suspend code.

[Shaheed]

Nigel, Rob,

Thanks for the explanations.

Shaheed

Re: Patrick's Test9 suspend code.

[Nigel Cunningham]

Hi.

On Fri, 2003-11-21 at 11:33, Shaheed wrote:
> Understood. But by definition, there must be at least one page of data on the 
> filesystem whose location we know in order to do the resume. Why can't we 
> simply use one extra page to store this data?

Your reading of how the image is stored is correct, but it's not the
real issue, I'm afraid.

The question is more, why would you want this data. It doesn't make
sense to boot from one kernel, suspend, boot from another kernel,
suspend and then boot from the original kernel _unless_ in all of these
cases, all filesystems are mounted read-only. If they're not mounted
read-only, you'll get the cross linking and corruption Rob spoke of.

Whenever I switch from testing a 2.4 kernel to testing 2.6, I do a clean
boot for precisely this reason. I'd love it if I could just suspend 2.4,
boot the new 2.6 kernel, see if it suspends properly (to a different
swap, of course) and then resume the original 2.4 kernel. But doing so
would only work if I mounted 2.6 entirely read only, which is not what
you seem to be planning.

Regards,

Nigel
-- 
Nigel Cunningham
495 St Georges Road South, Hastings 4201, New Zealand

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

Re: Patrick's Test9 suspend code.

[Shaheed]

On Thursday 20 November 2003 19:39, Rob Landley wrote:
> When resuming from a writeable filesystem, the filesystem has to match the
> contents of suspended memory.  If you've TOUCHED the filesystem since
> suspending, the resume is going to shred it, cross-link the heck out of it,
> and generally be evil.  (There are open filehandles saved in there, page
> table entries to maped stuff...  Just don't go there.)

Understood. But by definition, there must be at least one page of data on the 
filesystem whose location we know in order to do the resume. Why can't we 
simply use one extra page to store this data?

At least in my reading of suspend/main.c we create a directory of pages which 
itself is stored on disk. Since we do that, can't we simply use an extra page 
for this signature?

Re: Patrick's Test9 suspend code.

[Rob Landley]

On Thursday 20 November 2003 11:26, Shaheed wrote:
> > B) A heuristic that looks at the mounted block devices for things that
> > smell like a resume partition would actually be more robust in that case.
>
> How about a static signature followed by a timestamp? That way, maybe we
> could have a resume menu like this:
>
> /dev/hda3  (kernel 2.7.88, suspended on 01-04-2004 20:00:00)
> /dev/hda4  (kernel 2.8.99, suspended on 31-05-2005 20:00:00) ***
> Resume in 5..4..3..2..1..
>
> with a 5 second countdown before it chooses the most recent? Or in Pavel's
> examples:
>
> Erk! Nowhere to resume from!
>
> :-)

When resuming from a writeable filesystem, the filesystem has to match the 
contents of suspended memory.  If you've TOUCHED the filesystem since 
suspending, the resume is going to shred it, cross-link the heck out of it, 
and generally be evil.  (There are open filehandles saved in there, page 
table entries to maped stuff...  Just don't go there.)

Rob

Re: Patrick's Test9 suspend code.

[Shaheed]

> B) A heuristic that looks at the mounted block devices for things that smell 
> like a resume partition would actually be more robust in that case.

How about a static signature followed by a timestamp? That way, maybe we could 
have a resume menu like this:

/dev/hda3  (kernel 2.7.88, suspended on 01-04-2004 20:00:00)
/dev/hda4  (kernel 2.8.99, suspended on 31-05-2005 20:00:00) ***
Resume in 5..4..3..2..1..

with a 5 second countdown before it chooses the most recent? Or in Pavel's 
examples:

Erk! Nowhere to resume from! 

:-)

Re: Patrick's Test9 suspend code.

[Pavel Machek]

Hi!

> > A) Any scheme we come up with there will be a way the user can do something 
> > stupid enough to break it.  (Put the swap partition on a ramdisk living on 
> > the video card, or on a device require an initrd to load the driver to 
> > access...)
> > 
> > B) A heuristic that looks at the mounted block devices for things that smell 
> > like a resume partition would actually be more robust in that case.
> 
> Really, what i think here is appropriate is a more fundamental approach.
> 
> We should reserve a new partition type in addition to three already
> existing, namely "linux"==0x83, "linux swap"==0x82 and "linux lvm"==0x8e.
> 
> And call it something like "linux suspend".
> And initialize it, if needed (i presume to write a signature etc), with
> something like "mksusp".

Yes and we should create separate partition type for root filesystem
and have separate mkfs.ext2.root.

NOT!

I see no advantages in mksusp; it only means you need to re-fdisk
your machine. Bad idea, and its way too late for 2.6 anyway.
-- 
				Pavel
Written on sharp zaurus, because my Velo1 broke. If you have Velo you don't need...

Re: Patrick's Test9 suspend code.

[Samium Gromoff]

> > > > :-), Okay, we could make grub read /etc/fstab... But again user can do
> > > >
> > > > swapoff and swapon manually etc.
> > >
> > > During resume?
> >
> > No, imagine /dev/hda3 being set as swap in /etc/fstab, but user doing
> > swapoff /dev/hda3, swapon /dev/usb_zip_drive, then suspend.
> 
> A) Any scheme we come up with there will be a way the user can do something 
> stupid enough to break it.  (Put the swap partition on a ramdisk living on 
> the video card, or on a device require an initrd to load the driver to 
> access...)
> 
> B) A heuristic that looks at the mounted block devices for things that smell 
> like a resume partition would actually be more robust in that case.

Really, what i think here is appropriate is a more fundamental approach.

We should reserve a new partition type in addition to three already
existing, namely "linux"==0x83, "linux swap"==0x82 and "linux lvm"==0x8e.

And call it something like "linux suspend".
And initialize it, if needed (i presume to write a signature etc), with
something like "mksusp".

regards, Samium Gromoff