Hi!
> > > > > It's doubly bad, because that idiocy has also infected s2ram. Again,
> > > > > another thing that really makes no sense at all - and we do it not
> > > > > just for snapshotting, but for s2ram too. Can you tell me *why*?
> > > >
> > > > Why we freeze tasks at all or why we freeze kernel threads?
> > >
> > > In many ways, "at all".
> > >
> > > I _do_ realize the IO request queue issues, and that we cannot actually
> > > do s2ram with some devices in the middle of a DMA. So we want to be able
> > > to avoid *that*, there's no question about that. And I suspect that
> > > stopping user threads and then waiting for a sync is practically one of
> > > the easier ways to do so.
> > >
> <snip>
>
> Apparently I *CANNOT* wrap my head around this - if just because my laptop,
> running a vendor 2.6.17 kernel does s2ram perfectly, at least, it does when
> using the "Upstart" init system rather than the classical SysV init system. I
> have tried it with the classical init and the suspend isn't triggered by the
> buttons that used to do it. I didn't try 'echo ram > /sys/power/state', but I
> have a feeling that would have worked as well. I have problems with s2disk,
> but thats because I keep my swap partition small - I try to keep it at or
> around 256M when I have more than half a gig of Ram in a system. Perhaps one
> of these days I'll grab a multi-gig flash disk, set it up as a swap partition
> and try it again. (every time I've tried s2disk I wind up running out of disk
> space - and this is with nothing but X running. Any kind of progress meter
> for when the system is doing s2disk would be nice - every time I've tried it
> all I see for the nearly 2 minutes before the s2disk attempt ends is a black
> screen. I say 2 minutes because thats how long it takes for it to learn that
> there isn't enough space on the swap-partition to save the image)
Just turn up console loglevel to see the messages.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
