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

Bug #119976 reported by Kevin Wang on 2007-06-12
18
Affects Status Importance Assigned to Milestone
linux-source-2.6.22 (Ubuntu)
High
Unassigned

Bug Description

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) wrote :

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) wrote :

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) wrote :

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

Changed in linux-source-2.6.20:
status: Unconfirmed → Needs Info
Kevin Wang (kevin-xuepu-wang) wrote :

sorry, attach it again

Kevin Wang (kevin-xuepu-wang) wrote :

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) wrote :

Thanks.

Changed in linux-source-2.6.20:
status: Incomplete → Confirmed
Kyle McMartin (kyle) wrote :

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

Rolla Selbak (rolla-n-selbak) wrote :

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

Kevin Wang (kevin-xuepu-wang) wrote :

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) wrote :

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) wrote :

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

description: updated
Matthew Garrett (mjg59) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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) wrote :

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

Changed in linux-source-2.6.22:
status: Confirmed → Fix Released

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.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers