Re: swsusp in 2.6.16: works fine w/o PSE...

Re: swsusp in 2.6.16: works fine w/o PSE...

[Luca]

Hu Michael,
I'm CC-ing the two swsusp gurus ;)

Michael Tokarev <mjt@tls.msk.ru> ha scritto:
> I was just feeling lucky and tried suspend-to-disk cycle
> on my VIA C3 machine, which lacks PSE which is marked as
> being required for swsusp to work.  After commenting out
> the PSE check in include/asm-i386/suspend.h and rebooting,
> I tried the whole cycle, several times, with real load
> (while running 3 kernel compile in parallel) and while
> IDLE... And surprizingly, it all worked flawlessly for
> me, without a single glitch...
> 
> So the question is: is PSE really needed nowadays?

Can't comment on this one, but this message may answer your question:
http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/2144.html

> Ok, "w/o a single glitch"...  Actually there are several
> of them so far, but I guess they're unrelated to PSE/C3:
> 
> o Suspend after clean boot is sloooow, it takes quite
>   alot of time to write all the stuff to the disk (the
>   percents are increasing by 1..2 in a sec).  After
>   resume, if I suspend again the whole process takes
>   only several secs.

Are you using the in-kernel image writer or the userspace one?
The userspace suspend tends to be faster than the kernel and you may
limit the image size in order to speed up the process (at the cost of
losing part of the page cache).
See http://suspend.sf.net/
 
> o There's a single 'failed' message, while *suspending*:
> 
> Stopping tasks: ===============================================|
> Shrinking memory... done (0 pages freed)
> pnp: Device 01:01.00 disabled.
> pnp: Device 00:09 disabled.
> pnp: Device 00:08 disabled.
> ACPI: PCI interrupt for device 0000:00:07.5 disabled
> ACPI: PCI interrupt for device 0000:00:07.3 disabled
> ACPI: PCI interrupt for device 0000:00:07.2 disabled
> swsusp: Need to copy 19322 pages
> PCI: Setting latency timer of device 0000:00:01.0 to 64
> PCI: VIA IRQ fixup for 0000:00:07.1, from 255 to 0
> ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
> PCI: VIA IRQ fixup for 0000:00:07.2, from 9 to 11
> usb usb1: root hub lost power or was reset
> ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
> PCI: VIA IRQ fixup for 0000:00:07.3, from 9 to 11
> usb usb2: root hub lost power or was reset
> ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 12 (level, low) -> IRQ 12
> ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 12 (level, low) -> IRQ 12
> eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> pnp: Device 00:08 activated.
> pnp: Device 00:09 activated.
> pnp: Failed to activate device 00:0b.   <========= this one
> pnp: Device 01:01.00 activated.
> 
>   This is all shown while *suspending*, so it looks like
>   the kernel is shutting down all the devices and brings
>   them up again for some reason.  PNP device 00:0b is my
>   keyboard.

This is expected. swsusp is carried on in 4 steps:

- stops the tasks 
- shutdown the devices in order to put the system into a quiescent
  state; this is done to prevent DMA to overwrite memory while we are
  copying
- take a snapshot of the memory
- resume the devices, now it's safe to do it because we have a "safe"
  copy of the memory; we need to reactivate the devices in order to
  write out the image
- actually write the image to disk  

> o There's the following sequence of messages in my dmesg:
> 
> Restarting tasks...<6>usb 1-1: USB disconnect, address 2
> done
> usb 1-1: new low speed USB device using uhci_hcd and address 3
> 
>   It looks like either the formatting is wrong (missing \n in some
>   printk() or something), or USB device(s) aren't shutting down/
>   powered up at the appropriate time, or the connect/powerup
>   event interferes with the stuff happening during "Restarting
>   tasks...done" time.  For the end-user this is just a cosmetic
>   glitch (improper formatting), but it as well may be some
>   more serious prob.

It's caused by one of the usb related threads that has been un-frozen;
the thread does the printk() asynchronously, so it's not easy (nor
desiderable) to stop it from writing its stuff.
I think that it's only cosmetic, though IIRC usb used to have problems
with swsusp (and preemption? note to self: try with preempt enabled).

Userspace swsusp supports splash screens, so you may want to look at
a nice progress bar instead of those usb messages ;)

> Note I never tried swsusp before, so I've no idea how it usually
> looks like, or should look like.  We've servers which never suspend,
> we've X terminals (no need to suspend, and it will not work anyway
> as the network connections will not be restored anyway), and this
> my VIA-C3-based machine, which never worked due to the PSE check.


Luca
-- 
Home: http://kronoz.cjb.net
Una donna sposa un uomo sperando che cambi, e lui non cambiera`. Un
uomo sposa una donna sperando che non cambi, e lei cambiera`.

Re: swsusp in 2.6.16: works fine w/o PSE...

[Rafael J. Wysocki]

Hi,

On Thursday 25 May 2006 01:05, Luca wrote:
> Hu Michael,
> I'm CC-ing the two swsusp gurus ;)
> 
> Michael Tokarev <mjt@tls.msk.ru> ha scritto:
> > I was just feeling lucky and tried suspend-to-disk cycle
> > on my VIA C3 machine, which lacks PSE which is marked as
> > being required for swsusp to work.  After commenting out
> > the PSE check in include/asm-i386/suspend.h and rebooting,
> > I tried the whole cycle, several times, with real load
> > (while running 3 kernel compile in parallel) and while
> > IDLE... And surprizingly, it all worked flawlessly for
> > me, without a single glitch...
> > 
> > So the question is: is PSE really needed nowadays?
> 
> Can't comment on this one, but this message may answer your question:
> http://www.ussg.iu.edu/hypermail/linux/kernel/0410.3/2144.html

Unfortunately I can't add anything here.

> > Ok, "w/o a single glitch"...  Actually there are several
> > of them so far, but I guess they're unrelated to PSE/C3:

No, they aren't.

> > o Suspend after clean boot is sloooow, it takes quite
> >   alot of time to write all the stuff to the disk (the
> >   percents are increasing by 1..2 in a sec).  After
> >   resume, if I suspend again the whole process takes
> >   only several secs.
> 
> Are you using the in-kernel image writer or the userspace one?
> The userspace suspend tends to be faster than the kernel and you may
> limit the image size in order to speed up the process (at the cost of
> losing part of the page cache).
> See http://suspend.sf.net/

Well, the userspace suspend will not work with the 2.6.16.x kernels.
Still you can control the image size using the /sys/power/image_size
attribute (0 for the minimal image).

> > o There's a single 'failed' message, while *suspending*:
> > 
> > Stopping tasks: ===============================================|
> > Shrinking memory... done (0 pages freed)
> > pnp: Device 01:01.00 disabled.
> > pnp: Device 00:09 disabled.
> > pnp: Device 00:08 disabled.
> > ACPI: PCI interrupt for device 0000:00:07.5 disabled
> > ACPI: PCI interrupt for device 0000:00:07.3 disabled
> > ACPI: PCI interrupt for device 0000:00:07.2 disabled
> > swsusp: Need to copy 19322 pages
> > PCI: Setting latency timer of device 0000:00:01.0 to 64
> > PCI: VIA IRQ fixup for 0000:00:07.1, from 255 to 0
> > ACPI: PCI Interrupt 0000:00:07.2[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
> > PCI: VIA IRQ fixup for 0000:00:07.2, from 9 to 11
> > usb usb1: root hub lost power or was reset
> > ACPI: PCI Interrupt 0000:00:07.3[D] -> Link [LNKD] -> GSI 11 (level, low) -> IRQ 11
> > PCI: VIA IRQ fixup for 0000:00:07.3, from 9 to 11
> > usb usb2: root hub lost power or was reset
> > ACPI: PCI Interrupt 0000:00:07.5[C] -> Link [LNKC] -> GSI 12 (level, low) -> IRQ 12
> > ACPI: PCI Interrupt 0000:00:0a.0[A] -> Link [LNKC] -> GSI 12 (level, low) -> IRQ 12
> > eth0: link up, 100Mbps, full-duplex, lpa 0x45E1
> > pnp: Device 00:08 activated.
> > pnp: Device 00:09 activated.
> > pnp: Failed to activate device 00:0b.   <========= this one
> > pnp: Device 01:01.00 activated.
> > 
> >   This is all shown while *suspending*, so it looks like
> >   the kernel is shutting down all the devices and brings
> >   them up again for some reason.  PNP device 00:0b is my
> >   keyboard.
> 
> This is expected. swsusp is carried on in 4 steps:
> 
> - stops the tasks 
> - shutdown the devices in order to put the system into a quiescent
>   state; this is done to prevent DMA to overwrite memory while we are
>   copying
> - take a snapshot of the memory
> - resume the devices, now it's safe to do it because we have a "safe"
>   copy of the memory; we need to reactivate the devices in order to
>   write out the image

Yes, and the activation of the device (keybard) fails here.  It probably is a
good idea to let the respective driver maintainer know about this.

> - actually write the image to disk  

> 
> > o There's the following sequence of messages in my dmesg:
> > 
> > Restarting tasks...<6>usb 1-1: USB disconnect, address 2
> > done
> > usb 1-1: new low speed USB device using uhci_hcd and address 3
> > 
> >   It looks like either the formatting is wrong (missing \n in some
> >   printk() or something), or USB device(s) aren't shutting down/
> >   powered up at the appropriate time, or the connect/powerup
> >   event interferes with the stuff happening during "Restarting
> >   tasks...done" time.

Probably the devices _are_ woken up at the proper time, but it takes time
for them to get ready and the messages they produce in the process interfere
with the swsusp's messages.  You can try to disable the USB's verbose debug
messages (if they are enabled) and see if that helps or to decrease the
console loglevel before suspend.

> >   For the end-user this is just a cosmetic 
> >   glitch (improper formatting), but it as well may be some
> >   more serious prob.
> 
> It's caused by one of the usb related threads that has been un-frozen;
> the thread does the printk() asynchronously, so it's not easy (nor
> desiderable) to stop it from writing its stuff.
> I think that it's only cosmetic, though IIRC usb used to have problems
> with swsusp (and preemption? note to self: try with preempt enabled).

Works for me. :-)

> Userspace swsusp supports splash screens, so you may want to look at
> a nice progress bar instead of those usb messages ;)

But requires a newer kernel.

Greetings,
Rafael

Re: swsusp in 2.6.16: works fine w/o PSE...

[Pavel Machek]

Hi!

> I'm CC-ing the two swsusp gurus ;)
> 
> > I was just feeling lucky and tried suspend-to-disk cycle
> > on my VIA C3 machine, which lacks PSE which is marked as
> > being required for swsusp to work.  After commenting out
> > the PSE check in include/asm-i386/suspend.h and rebooting,
> > I tried the whole cycle, several times, with real load
> > (while running 3 kernel compile in parallel) and while
> > IDLE... And surprizingly, it all worked flawlessly for
> > me, without a single glitch...
> > 
> > So the question is: is PSE really needed nowadays?

I think so. Or can you prove that pagetables are not going to be
overwritten in wrong order in !PSE case?

Look at x86-64 how !PSE case can be solved, but it is a bit of code.

								Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: swsusp in 2.6.16: works fine w/o PSE...

[Rafael J. Wysocki]

Hi,

On Thursday 25 May 2006 23:43, Pavel Machek wrote:
> > I'm CC-ing the two swsusp gurus ;)
> > 
> > > I was just feeling lucky and tried suspend-to-disk cycle
> > > on my VIA C3 machine, which lacks PSE which is marked as
> > > being required for swsusp to work.  After commenting out
> > > the PSE check in include/asm-i386/suspend.h and rebooting,
> > > I tried the whole cycle, several times, with real load
> > > (while running 3 kernel compile in parallel) and while
> > > IDLE... And surprizingly, it all worked flawlessly for
> > > me, without a single glitch...
> > > 
> > > So the question is: is PSE really needed nowadays?
> 
> I think so. Or can you prove that pagetables are not going to be
> overwritten in wrong order in !PSE case?
> 
> Look at x86-64 how !PSE case can be solved, but it is a bit of code.

Well, on i386 it'll have to be more complicated, because on x86_64 we use
2 MB pages for the temporary 1-1 mapping.

Greetings,
Rafael