Messages in this thread | | | Date | Fri, 26 Mar 2004 18:21:20 +0800 | From | "Michael Frank" <> | Subject | Re: swsusp is not reliable. Face it. [was Re: [Swsusp-devel] Re: swsusp problems] |
| |
On Fri, 26 Mar 2004 10:59:29 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> Hi! > > On Pá 26-03-04 13:59:55, Michael Frank wrote: >> On Thu, 25 Mar 2004 23:13:48 +0100, Pavel Machek <pavel@ucw.cz> wrote: >> >>Suspend is a mechanism to suspend the system transparently and >> >>_NOT_EVER_ impairing the system. There can be NO_COMPROMISE and >> >>NO_EXCUSE. I walk out of my office suspending the machine and resuming it >> >>in front of my client it can't ever fail, or am I an idiot to advocate >> >>linux? >> >> >> >>If I would be willing to accept failure I would not spend my time here and >> >>utilize M$'s incarnation of an architectural idiocy. >> > >> >You are wrong. >> > >> >swsusp1 fails your test, swsusp2 fails your test, and pmdisk fails it, >> >too. If half of memory is used by kmalloc(), there's no sane way to >> >make suspend-to-disk working. And swsusp[12] does not. Granted, half >> >of memory kmalloc-ed is unusual situation, but it can theoreticaly >> >happen. Try mem=8M or something. >> >> No, I am not! >> >> mem=8M won't boot into a usable system. mem=~11M will not suspend and >> swsusp2 will exit gracefully and this is tested. >> >> So swsusp2 does _not_ fail. You still have a usable system instead of a >> paniced system you seem to like to accept. > > If swsusp1 panics system, that's a bug. I'm not accepting that one.
OK,
> > Refusing to suspend (I'd call it "fail to suspend") is bad but is not > a bug.
Right, and in case of swsusp2, it generally can be avoided by proper sizing of swap.
> Do we understand each other now?
Yes
Michael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |