Re: S3 testing, etc

[Marek Marczykowski <marmarek@invisiblethingslab.com>]

[-- Attachment #1.1.1: Type: text/plain, Size: 5098 bytes --]

On 10.04.2013 12:31, Ben Guthro wrote:
> I had an off-list discussion with George Dunlap yesterday, who
> suggested that it might be helpful to have an ability to test the S3
> functionality in a bit more of an end-to-end fashion, and possibly
> introduce an ability to do all of the S3 related things without
> actually putting the machine to sleep.
> 
> Attached is a very simple patch to xen that introduces a command line
> argument "fake_s3" that will do just that.
> 
> Also attached is a shell script that will put a system to sleep, and
> wake it back up after a number of seconds by programming the RTC.
> This does so at the kernel interface level, which is not as complete
> as the pm-utils functionality, but since different linux distros seem
> to vary in implementations of how to go into sleep, I used the sysfs
> interface directly. A more complete cli interface may be more
> appropriate for specific distros.
> 
> Finally, since this does require functionality not yet accepted into
> the mainline kernel, one of Konrad's acpi-s3-vX branches is necessary:
> I can vouch for the functionality in v9 - but there is also a newer v10:
> http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=devel/acpi-s3.v9
> http://git.kernel.org/cgit/linux/kernel/git/konrad/xen.git/log/?h=devel/acpi-s3.v10
> 
> The hope here is that this might be somehow worked into the automated
> testing to maybe catch regressions in S3 sooner.

I've used extended version of similar script, with PXE, compilation done on
separate machine and automatically collecting test results - suitable to use
with "git bisect run".

It mainly does:
1. xen-compile.sh compiles the hypervisor and place it in TFTP accessible
directory; then signal test machine to reboot (assuming there is autotest2.sh
script running).
2. Test machine starts from PXE (using above hypervisor), then automatically
(rc.local) launch autotest2.sh.
3. The script checks for testrun kernel parameter (if missing - abort test -
this is the way to easily get system to normal); then run test.sh to check
system state before suspend (just to be sure)
4. Then schedule wakeup using rtcwake (here Ben's method is simpler) and go
into sleep using pm-suspend util (can be also changed to direct sysfs write,
as in Ben's script)
5. After resume it check system state (test.sh again) and send result back to
compile host using netcat.
5a. If system rebooted during suspend/resume this is also detected by presence
of flag file, and also reported to compile host.
6. Test can be automatically repeated (eg. require 3 consecutive successful
suspend/resumes)
7. After the test (regardless of result) wait for next reboot signal to test
another revision.

Some unsolved problem is what to do if network isn't working after resume.
I've tried some workarounds like module reload, but it isn't always enough. I
was thinking about some other communication media like serial console, but
didn't implemented it.

Scripts are written for my setup, so some paths and parameters may needs
adjustment. I've already removed Qubes-specific parts (hope didn't break
anything). Attached files:
1. xen-compile.sh - script to use on compile host/PXE server; this script
should be called from xen working directory, can be directly used as bisect
run script.
2. xen-debug - PXE configuration, place in /var/lib/tftpboot/pxelinux.cfg/ (or
whatever location is used by TFTP server); you can either rename this file to
"default" to be used by all hosts, or make symlinks for individual machines
(my case - see below); you also need update kernel parameters there -
especially root=

3. autotest2.sh - place in /root/s3-debug on test hardware; add it to rc.local
4. test.sh - place in /root/s3-debug on test hardware - this script should
test after resume if everything is ok - most likely you need update this
script for currently investigated problem; attached version checks for
presence of C3 ACPI c-state (problem described in "High CPU temp, suspend
problem - xen 4.1.5-pre, linux 3.7.x" thread)

Additionally some files from syslinux are needed (pxelinux.0, mboot.32). And
of course DHCP and TFTP services set accordingly.

Some directory listings:
/var/lib/tftpboot/:
-rw-r--r--. 1 22961209 Mar 25 04:56 initramfs-3.7.4-3.pvops.qubes.x86_64.img
lrwxrwxrwx. 1       40 Mar 26 17:31 initrd.img ->
initramfs-3.7.4-3.pvops.qubes.x86_64.img
-rw-r--r--. 1    34396 Mar 24 00:36 mboot.c32
-rw-r--r--. 1    26460 Mar 24 00:35 pxelinux.0
drwxr-xr-x. 2     4096 Apr  2 01:30 pxelinux.cfg
lrwxrwxrwx. 1       34 Mar 26 17:31 vmlinuz -> vmlinuz-3.7.4-3.pvops.qubes.x86_64
-rw-r--r--. 1  3672928 Mar 22 20:58 vmlinuz-3.7.4-3.pvops.qubes.x86_64
-rw-r--r--. 1   756887 Apr  2 01:30 xen.gz

/var/lib/tftpboot/pxelinux.cfg/:
lrwxrwxrwx. 1   9 Mar 29 00:57 01-00-13-77-b7-eb-48 -> xen-debug
lrwxrwxrwx. 1   9 Mar 24 01:07 01-5c-26-0a-79-f6-7a -> xen-debug
-rw-r--r--. 1 438 Apr  2 01:30 xen-debug



-- 
Best Regards / Pozdrawiam,
Marek Marczykowski
Invisible Things Lab

[-- Attachment #1.1.2: autotest2.sh --]
[-- Type: application/x-sh, Size: 1192 bytes --]

[-- Attachment #1.1.3: xen-compile.sh --]
[-- Type: application/x-sh, Size: 778 bytes --]

[-- Attachment #1.1.4: xen-debug --]
[-- Type: text/plain, Size: 431 bytes --]

timeout 5
default start


label start
	kernel mboot.c32
	append xen.gz cpufreq=verbose loglvl=all guest_loglvl=all com1=115200,8n1  apic_verbosity=debug conswitch=b sync_console console=com1,vga --- vmlinuz root=/dev/mapper/qubes_test500-root_test ro rd.lvm.lv=qubes_test500/root_test rd.lvm.lv=qubes_test500/lv_swap rd.luks=0 rd.md.0 rd.dm=0 console=tty0 console=hvc0 no_console_suspend testrun=95be934 testcount=2 --- initrd.img

[-- Attachment #1.1.5: test.sh --]
[-- Type: application/x-sh, Size: 78 bytes --]

[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 553 bytes --]

[-- Attachment #2: Type: text/plain, Size: 126 bytes --]

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel