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. :)
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...
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
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?]
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
> 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
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
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
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?]
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
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.
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
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?]
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
> > > > :-), 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
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...
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...
> 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!
:-)
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
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?
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.
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?]
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
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.