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
Affects Status Importance Assigned to Milestone
linux-source-2.6.22 (Ubuntu)

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

 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:


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:
       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:
       echo 1 > /sys/power/pm_trace
       /etc/acpi/ 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


Henrik Nilsen Omma (henrik) wrote :


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 :


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.


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).


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 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