All the task previous are killed after resumed from S3 on Santa Rosa with Crestline

[Kevin Wang]

This bug occured during testing Feisty update (i386 and x86_64 Desktop)
on Santa Rosa platform with the following specs:

Santa Rosa CRB
Crestline(B0) ICH8M(B0)
Merom(B1) 2.0GHz
EM64T 4M 667MHz
2048M DDR2 667
80G Sata

Steps:
 1. Run glxgears
 2. echo ‘mem’ > /sys/power/state
 3. After system suspended, press power button

Expected result:
 1.System suspends after the command,
 2.System resumes after power button pressed, display and keyboard/mouse works well

Actual result:
 1.System suspends after the command
 2.After power button pressed, system starts with new login window, all the task previous are killed.

[Henrik Nilsen Omma (henrik)]

Hi Kevin,

Please read this wiki page on ow to collect debugging information for suspend and resume problems: https://wiki.ubuntu.com/DebuggingKernelSuspend

Thanks.

Assigning to the kernel team.

[Kevin Wang (kevin-xuepu-wang)]

OK, I reprodued the issue following the information on the link, and got difference result from my testing.

My original testing is in the description.
the latest result is: I tried many times, and sometime it can resume successfully, most of time, it can not. for the failed scenario, I checked the dmesg, seems no special hint, I collected all the dmesg information during my testing, the dmesg.4.log is the one which resume successfully.
BTW, some times the linux can not startup by this resume trigger method, I have to re-install the GRUB.

[Henrik Nilsen Omma (henrik)]

Hm, the dmesg log doesn't seem to have been attached properly.

[Kevin Wang (kevin-xuepu-wang)]

sorry, attach it again

[Kevin Wang (kevin-xuepu-wang)]

Hi Omma,

I did the test again today, here is the steps:

1. test the resume by the command:
       sync
       echo 1 > /sys/power/pm_trace
       echo mem > /sys/power/state
    result: the system is suspended, then I try to push the power button to let it resume, a new login xwindow is prompted, all the privious task are disappeared, check the dmesg, there is no useful information.

2. test resume by the command:
       sync
       echo 1 > /sys/power/pm_trace
       /etc/acpi/sleep.sh force
       result: the system is suspended and resume normally, please see the log: dmesg.1.log

3. repeat the test (2)
       result: the system can not resume normally. in dmesg.2.log, there are:
            [ 67.282834] hash matches drivers/base/power/resume.c:46
            [ 67.282896] hash matches device 00:0a
       from the output of the lspci, I can not find 00:0a

4. repeat the test (2) again.
       result: the system can not resume normally, but can not find any hint in the dmesg.3.log

Thanks
Kevin

[Henrik Nilsen Omma (henrik)]

Thanks.

[Kyle McMartin (kyle)]

Could you please test with Gutsy tribe-2 to see if it is fixed there?

[Rolla Selbak (rolla-n-selbak)]

Kevin, this is confirmed as fixed in tribe-3 correct?

[Kevin Wang (kevin-xuepu-wang)]

Kyle,

Use the command ' echo "mem" > /sys/power/state' to go to S3, system can be back after that. but from menu, 'system -> Quit -> Suspend', the system can NOT come back after it suspend.
so I think the issue is still exist.

thanks
Kevin

[Kevin Wang (kevin-xuepu-wang)]

I verified it in Tribe 5,

- with our SDV machine, from menu, 'system -> Quit -> Suspend', the system still can NOT come back after it suspend.

- with Lenovo T61, do the same thing, seems the system can come back but with very weak screen output (almost can not see anything).

thanks
Kevin

[Henrik Nilsen Omma (henrik)]

Setting Gutsy Beta milestone. I also changed linux-source-2.6.20 -> linux-source-2.6.22.

[Matthew Garrett (mjg59)]

This appears to have turned into a collection of different bugs. For suspend related bugs, please open one bug per machine affected - the fact that they share a chipset does not mean that the bug is the same. Also, echoing to /sys/power/state will not result in functioning suspend/resume. Please ensure that the bug can be reproduced with the sleep menu item.

[Kyle McMartin (kyle)]

Indeed, I cannot reproduce a crash running glxgears and suspending via the menu item.

As for the backlight issues, adding "acpi_sleep=s3_bios" to the grub command line for the kernel will work around this.

[Kevin Wang (kevin-xuepu-wang)]

When I using the Santa Rosa SDV, from menu, 'system -> Quit -> Suspend', the system can NOT come back after it suspend, I try to collect the dmesg, but seems no useful information at there.
I think the issue 128194 is same as this one.

For the backlight issue, the system work fine after resume with the work around method.

[Kyle McMartin (kyle)]

Ok, so this only happens on the SDV?

Can you please attach the output of "ps aux" from before and after the attempted suspend? Also, could you please attach a copy of /var/log/Xorg.0.log and /var/log/Xorg.0.log.old from immediately after the crash?

[Kevin Wang (kevin-xuepu-wang)]

Yes, it only happens on the SDV.

It is difficult to get the log immediately after the crash, because it can not resume and the network is borken as well. so I get the log after reboot it when crash happens. anyway the log attached.

[Xiaoyang Yu (xiaoyang-yu)]

Kevin> with Lenovo T61, do the same thing, seems the system can come back but with very weak screen output (almost can not see anything).

I get the same result with T61, using the Sep 25 daily build desktop IA32e version.

[Xiaoyang Yu (xiaoyang-yu)]

This bug is not occurred on Lenovo Thinkpad T61 with Gutsy Alternate amd64 Oct 16th daily build. So I mark it as "Fix released".

[Launchpad Janitor (janitor)]

Per a decision made by the Ubuntu Kernel Team, bugs will longer be assigned to the ubuntu-kernel-team in Launchpad as part of the bug triage process. The ubuntu-kernel-team is being unassigned from this bug report. Refer to https://wiki.ubuntu.com/KernelTeamBugPolicies for more information. Thanks.