Messages in this thread | | | Date | Fri, 1 Mar 2002 10:59:07 +0100 | From | Pavel Machek <> | Subject | Re: 2.2.18/swsusp bugs |
| |
Hi!
> >> Alright, but provided that trying to resume from a non-suspend swap > >> doesn't crash anything... > > PM> Do you stop all user processes before doing resume, for example? > > (Different subject, hey?-). No, I don't. At the point I do (and recommend to) > swapon is during early init processing. There are no user processes at that > point. If they are, they disappear in thin air at that point... > > But I already gave up, I agree w/your method. But remember that people will > boot resume=/bla even when they have no swap to resume from. Just a lilo thing, > unavoidable. > > PM> But that might be problem at resume. Imagine uhci has buffers at > PM> 0x12345678, but in image being resumed, /bin/bash is at 0x12345678. Then > PM> you have a problem. > > Nope, that can't happen. uhci and bash had their pages neatly restored... > Wait! Are you saying you start uhci/netdrivers/enable interrupts BEFORE > resuming?? Nonono! Forbidden! Disk corruption, or your computer may > explode!
But you were running uhci/netdrivers before resuming, too, right?
How I'm going to solve this is to introduce "stop" callback to all device drivers. NOte: I have to enable DMA/interrupts BEFORE resuming -- I acutally need interrupts for reading from disk, and I *may* need uhci/DMA for resuming, too. (I actually did resume=/dev/zip_drive_on_usb. Worked at one point.)
> PM> [swsusp list no longer works, doing cc to l-k.] > > So it seems. It didn't bounce yesterday, but didn't get a response. OTOH, l-k > isn't too busy a place to discuss swsusp? How about the ACPI list?
Okay, if you prefer. Pavel -- Casualities in World Trade Center: ~3k dead inside the building, cryptography in U.S.A. and free speech in Czech Republic. - 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/
| |