Bug 6058 - S3: no wake - HP nc4010
S3: no wake - HP nc4010
Status: CLOSED DOCUMENTED
Product: ACPI
Classification: Unclassified
Component: Power-Sleep-Wake
i386 Linux
: P2 normal
Assigned To: Shaohua
:
: 12773 (view as bug list)
Depends on:
Blocks: 7216
  Show dependency treegraph
 
Reported: 2006-02-12 06:30 UTC by Carey O'Shea
Modified: 2009-12-29 02:57 UTC (History)
7 users (show)

See Also:
Kernel Version: 2.6.29rc5
Tree: Mainline
Regression: No


Attachments
aoo suffix stands for the acpi_sleep=old_ordering (41.30 KB, application/x-gzip)
2009-03-04 21:37 UTC, Aljaz Prusnik
Details
try the custom DSDT (215.97 KB, patch)
2009-03-18 00:43 UTC, ykzhao
Details | Diff
before message with custom dsdt (33.67 KB, application/octet-stream)
2009-03-24 14:04 UTC, Aljaz Prusnik
Details
dmesg before without X (33.48 KB, application/octet-stream)
2009-03-26 18:31 UTC, Aljaz Prusnik
Details
dmesg after without X (41.98 KB, application/octet-stream)
2009-03-26 18:32 UTC, Aljaz Prusnik
Details
dmesg before with X (33.58 KB, application/octet-stream)
2009-03-26 18:33 UTC, Aljaz Prusnik
Details
acpidump before (116.06 KB, application/octet-stream)
2009-03-27 21:52 UTC, Aljaz Prusnik
Details
acpidump after (116.06 KB, application/octet-stream)
2009-03-27 21:56 UTC, Aljaz Prusnik
Details
dmesg after - no X, BT&Wireless off (122.19 KB, application/octet-stream)
2009-03-31 18:27 UTC, Aljaz Prusnik
Details
acpi before's with 2.6.31 rc3 kernel (31.60 KB, application/x-gzip)
2009-07-22 19:36 UTC, Aljaz Prusnik
Details

Description Carey O'Shea 2006-02-12 06:30:10 UTC
Distribution: Ubuntu Breezy
Hardware Environment: HP nc4010 laptop
Problem Description: Machine will not resume after suspending to ram (S3). When
resuming, the fan/hdd/etc starts up, but no screen and machine won't respond to
ping or anything.

Steps to reproduce: Suspend machine. Wake.

dmidecode: http://users.on.net/~lncoshea/carey/dmidecode
lspci -vv: http://users.on.net/~lncoshea/carey/lspci-vv
cat /proc/interrupts: http://users.on.net/~lncoshea/carey/interrupts
dmesg -s40000: http://users.on.net/~lncoshea/carey/dmesg-s40000
acpidump: http://users.on.net/~lncoshea/carey/acpidump
Comment 1 Shaohua 2006-02-13 17:53:10 UTC
Did it (S3) ever work before? If yes, can you please identify which version 
breaks it? Thanks!
Comment 2 Carey O'Shea 2006-02-14 03:57:02 UTC
Not that I am aware of, I have only used 2.6.12 and 2.6.15 kernels on this
machine. So it's possible that it has worked before, but I am unable to say for
sure.

Does this mean it is unlikely to get fixed, or?

Do you need any more information other than what I have provided? I am happy to
do anything that may be required.

Comment 3 Shaohua 2006-03-14 18:03:10 UTC
Did you use wireless? Somebody said wireless configuration will break s3. If 
you have, please try unload wireless driver.
Comment 4 Matthew Garrett 2006-09-15 03:53:57 UTC
I've looked into this in the past. By testing with a serial console, we were
able to get an nc4000 (almost identical to the 4010 - same chipset) to resume if
we did so *immediately* after a suspend, but there was evidence of memory
corruption - the kernel would tend to crash in odd ways. The longer the period
of time between suspend and resume, the less likely a resume attempt was to
succeed. The obvious suggestion was that the RAM wasn't being put into
self-refresh mode, but there's no documentation available from ATI.
Comment 5 Rafael J. Wysocki 2007-06-04 10:48:00 UTC
Can anyone please tell me what the status of this bug is?
Comment 6 Matthew Garrett 2007-06-04 10:54:06 UTC
Unresolved.
Comment 7 Rafael J. Wysocki 2007-08-20 10:37:46 UTC
A lot of suspend-related changes have gone in since the last September.  Have anyone checked if that issue is still present or if the symptoms have changed?
Comment 8 Len Brown 2007-09-06 14:55:21 UTC
Please re-open if this is still a problem in linux-2.6.22.stable or later.
Comment 9 Guðlaugur Jóhannesson 2007-11-15 19:32:54 UTC
Using 2.6.22.12-0.1-default in an opensuse distribution, I can confirm that this does not work on a nc4010.  Using the s2ram utility with the f flag and various combination of other flags always resulted in a black screen during resume and blinking num-lock and caps-lock lights.

output from lspci
00:00.0 Host bridge: ATI Technologies Inc RS200/RS200M AGP Bridge [IGP 340M] (rev 02)
00:01.0 PCI bridge: ATI Technologies Inc PCI Bridge [IGP 340M]
00:06.0 Multimedia audio controller: ALi Corporation M5451 PCI AC-Link Controller Audio Device (rev 02)
00:07.0 ISA bridge: ALi Corporation M1533/M1535 PCI to ISA Bridge [Aladdin IV/V/V+]
00:08.0 Modem: ALi Corporation M5457 AC'97 Modem Controller
00:0b.0 CardBus bridge: O2 Micro, Inc. OZ711M1/MC1 4-in-1 MemoryCardBus Controller (rev 20)
00:0b.1 CardBus bridge: O2 Micro, Inc. OZ711M1/MC1 4-in-1 MemoryCardBus Controller (rev 20)
00:0b.2 System peripheral: O2 Micro, Inc. OZ711Mx 4-in-1 MemoryCardBus Accelerator
00:10.0 IDE interface: ALi Corporation M5229 IDE (rev c4)
00:11.0 Bridge: ALi Corporation M7101 Power Management Controller [PMU]
00:12.0 USB Controller: NEC Corporation USB (rev 43)
00:12.1 USB Controller: NEC Corporation USB (rev 43)
00:12.2 USB Controller: NEC Corporation USB 2.0 (rev 04)
00:13.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5705M Gigabit Ethernet (rev 03)
01:05.0 VGA compatible controller: ATI Technologies Inc Radeon IGP 330M/340M/350M
02:00.0 Network controller: Broadcom Corporation BCM4306 802.11b/g Wireless LAN Controller (rev 02)

and lsmod
iptable_filter          6912  0
ip_tables              16324  1 iptable_filter
ip6table_filter         6784  0
ip6_tables             17476  1 ip6table_filter
x_tables               18308  2 ip_tables,ip6_tables
af_packet              29064  2
ipv6                  268280  12
snd_pcm_oss            50432  0
snd_mixer_oss          20096  1 snd_pcm_oss
snd_seq                54452  0
snd_seq_device         12172  1 snd_seq
radeon                116228  1
drm                    79636  2 radeon
apparmor               40736  0
dm_crypt               16904  0
loop                   21636  0
dm_mod                 56880  1 dm_crypt
fuse                   45460  1
ndiswrapper           174328  0
snd_ali5451            26252  1
pcmcia                 41076  0
snd_ac97_codec         97060  1 snd_ali5451
firmware_class         13568  1 pcmcia
i2c_ali1535            11012  0
ac97_bus                6272  1 snd_ac97_codec
snd_pcm                82564  3 snd_pcm_oss,snd_ali5451,snd_ac97_codec
snd_timer              26756  2 snd_seq,snd_pcm
i2c_ali15x3            11652  0
i2c_core               27520  2 i2c_ali1535,i2c_ali15x3
snd                    58164  10 snd_pcm_oss,snd_mixer_oss,snd_seq,snd_seq_device,snd_ali5451,snd_ac97_codec,snd_pcm,snd_timer
soundcore              11460  1 snd
yenta_socket           28684  3
ati_agp                12684  1
snd_page_alloc         14472  1 snd_pcm
tg3                   104068  0
agpgart                35764  2 drm,ati_agp
rsrc_nonstatic         15872  1 yenta_socket
rtc_cmos               12064  0
rtc_core               23048  1 rtc_cmos
rtc_lib                 7040  1 rtc_core
shpchp                 35092  0
pci_hotplug            33216  1 shpchp
serio_raw              10756  0
pcmcia_core            40852  3 pcmcia,yenta_socket,rsrc_nonstatic
joydev                 13632  0
sg                     37036  0
ehci_hcd               34956  0
ohci_hcd               23684  0
usbcore               123756  4 ndiswrapper,ehci_hcd,ohci_hcd
sd_mod                 31104  4
alim15x3               14988  0 [permanent]
ide_core              122948  1 alim15x3
edd                    12996  0
reiserfs              233140  2
pata_ali               14336  3
libata                137032  1 pata_ali
scsi_mod              140376  3 sg,sd_mod,libata
Comment 10 Tarek Loubani 2007-11-20 05:22:18 UTC
I just tested, and this is true in 2.6.20 and 2.6.22 on Ubuntu Feisty and Ubuntu Gutsy. With S3_bios, the numlock doesn't flash. With S3_Mode, it does.

tarek : )
Comment 11 Zhang Rui 2007-11-20 21:39:44 UTC
Tarek,
Your laptop probably has a different issue.
Please open another bug report and attach the dmesg, acpidump and /proc/interrupts.
Comment 12 Aljaz Prusnik 2009-02-22 01:25:57 UTC
Since this is the only bug I found for this model, I'll give it a go. I've compiled 2.6.29-rc5 to see if it wakes (after these long years of resisting) but it still doesn't. The symptoms are the same as in the first post (running fresh install of Debian Lenny).

It works without problems on WinXP.

So what should I provide now?
Comment 13 Zhang Rui 2009-02-24 17:11:32 UTC
*** Bug 12773 has been marked as a duplicate of this bug. ***
Comment 14 ykzhao 2009-03-04 17:59:13 UTC
Hi, Aljaz
    Will you please add the boot option of "acpi_sleep=old_ordering" and do the following test?
    a. dmesg > dmesg_before; echo mem > /sys/power/state; dmesg >dmesg_after; sync; reboot;
    b. press the power button and see whether the box can be resumed.

    If it can't be resumed, please reboot the box and see whether there exists the file of dmesg_after.
    
    It will be great if you don't add the boot option of "acpi_sleep=old_ordering" and do the same test(step a & b).
    Thanks.
   
    
Comment 15 Aljaz Prusnik 2009-03-04 21:37:47 UTC
Created attachment 20434 [details]
aoo suffix stands for the acpi_sleep=old_ordering

I did so. Both times the computer didn't wake, but the vent was up which I don't remember before. The keyboard didn't respond, hard reset did. Without acpi option (normal boot) both caps lock and num lock after a while of waking up started flashing. That's the only difference between both cases.
Comment 16 ykzhao 2009-03-18 00:13:01 UTC
Hi, Aljaz
    Thanks for the test.
    From the log in comment #15 it seems that the box can be resumed from S3. But the remaing issue is that:
    a. keyboard can't be used if the acpi_sleep=old_ordering is added. But it can be used without acpi boot option
    b. the screen remains black (This should be related with ATI graphicis driver).
    
Does any ATI guy look at this issue? The box can be resumed but there is no screen after resume.

   Thanks.
    
   
Comment 17 ykzhao 2009-03-18 00:43:49 UTC
Created attachment 20581 [details]
try the custom DSDT

Hi, 
   It seems that there exists the following warning message after suspend/resume.
   >ACPI Error (psargs-0359): [_ksy] Namespace lookup failure, AE_NOT_FOUND
   It is very interesting.
   But from the ACPIdump we know that no _ksy object is called in the object of \_TZ_.C1F3._STA
   
    Will you please try the custom DSDT and do the test as mentioned in comment #14?(The boot option of "acpi_sleep=old_ordering" is not needed).
    How to use the custom DSDT can be found in (http://www.lesswatts.org/projects/acpi/faq.php)
   Thanks.
Comment 18 Aljaz Prusnik 2009-03-20 15:35:05 UTC
Problems:
1) I cannot compile the iasl tool:

42: undefined reference to `AcpiGbl_GlobalList'
/home/aljaz/temp/acpica-unix-20090320/tools/acpiexec/../../utilities/uttrack.c:242: undefined reference to `AcpiGbl_GlobalList'
../../utilities/uttrack.o:/home/aljaz/temp/acpica-unix-20090320/tools/acpiexec/../../utilities/uttrack.c:243: more undefined references to `AcpiGbl_GlobalList' follow
collect2: ld returned 1 exit status
make: *** [acpiexec] Error 1

2) with the debian lenny version I get this:
~/temp$ sudo acpidump > acpidump.out
~/temp$ sudo acpixtract DSDT acpidump > DSDT.dat
~/temp$ sudo iasl -d DSDT.dat

Intel ACPI Component Architecture
AML Disassembler version 20061109 [May 18 2007]
Copyright (C) 2000 - 2006 Intel Corporation
Supports ACPI Specification Revision 3.0a

Loading Acpi table from file DSDT.dat
Could not read the table header
Could not get table from the file
Comment 19 Lin Ming 2009-03-22 18:29:41 UTC
1) compile iasl and acpiexec:
   cd acpica-unix-20090320/compiler
   make clean
   make
   cd acpica-unix-20090320/tools/acpiexec
   make clean
   make

2) acpixtract -sDSDT acpidump 
   iasl -d DSDT.dat
Comment 20 ykzhao 2009-03-22 19:55:22 UTC
Hi, Aljaz
    Sorry that I don't make it very clear about how to use the custom DSDT.
    In fact the file of DSDT.hex is attached. In such case the previous four steps can be skipped. You can start from the step 5.
    Thanks.
Comment 21 Aljaz Prusnik 2009-03-24 14:04:05 UTC
Created attachment 20661 [details]
before message with custom dsdt

Now it's even weirder. I compiled now the released kernel with the custom DSDT and there is no after message anymore. The computer goes to sleep but never wakes up. The disk won't even bother to wake nor the fans as before. I tried it several times. After a while of waking up the num and caps lock leds start to flash but not everytime.
I'm only attaching the before message.
I tried with or without gdm running.
Comment 22 ykzhao 2009-03-24 17:48:55 UTC
Hi, Aljaz
    The test results seems weird. Before the custom DSDT is used, the box can be resumed from S3(in comment #15). But after using the custom DSDT, the box can't be resumed any more.

    From the test log it seems that the custom DSDT is tried on the 2.6.29-stable kernel. Right?
    Will you please try the custom DSDT on the 2.6.29-rc6 kernel?  It will be great if you can confirm whether the box can be resumed from S3 on the 2.6.29-rc6 kernel again.
    Thanks. 
Comment 23 Aljaz Prusnik 2009-03-26 18:31:49 UTC
Created attachment 20691 [details]
dmesg before without X

Adding 3 attachments:
- 2 of before and after when X was stopped
- just one "before" when X was running

This was now on 2.6.29-rc6 with the attached DSDT.
Comment 24 Aljaz Prusnik 2009-03-26 18:32:29 UTC
Created attachment 20692 [details]
dmesg after without X
Comment 25 Aljaz Prusnik 2009-03-26 18:33:06 UTC
Created attachment 20693 [details]
dmesg before with X
Comment 26 Aljaz Prusnik 2009-03-26 18:35:19 UTC
In the scenario when there was an "after" file, there was nothing happening during wake-up but after a while both caps and num lock started flashing.
Comment 27 ykzhao 2009-03-27 02:08:17 UTC
Hi, Aljaz
    Thanks for the test.
    It seems that the box can be resumed on the 2.6.29-rc6 kernel after using the custom DSDT. 
    And after the custom DSDT is used, the following message won't be complained again:
    >ACPI Error (psargs-0359): [_ksy] Namespace lookup failure, AE_NOT_FOUND
    >ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.C1F3._STA] (Node f7017348), AE_NOT_FOUND

    It seems that the content of DSDT table is changed by BIOS in course of suspend/resume, which causes that some ACPI objects can't be evaluated correctly.(When the custom DSDT is used, its content is in the kernel meory region. And it won't be changed by BIOS).

    Will you please do the following test on the 2.6.29-rc6 kernel and confirm whether the content of DSDT table is changed by BIOS? 
    a. acpidump >acpidump_before; 
    c. echo mem > /sys/power/state; acpidump >acpidump_after; dmesg >dmesg_after; sync;
    d. press the power button and reboot the system.
    e. after the box is rebooted, please attach the output of acpidump_before/after.

     thanks.
Comment 28 Aljaz Prusnik 2009-03-27 21:52:49 UTC
Created attachment 20712 [details]
acpidump before
Comment 29 Aljaz Prusnik 2009-03-27 21:56:33 UTC
Created attachment 20713 [details]
acpidump after

I have struggled now to get to this after file, since it needed quite some reboots to finally get one. It seems that every sleep try is somewhat a new experince.
I have also done the same with the non-dsts kernel and the result seems to be the same - both files are, according to meld (file compare tool) identical.
This indeed seems to be a very weird piece of hardware.
Comment 30 ykzhao 2009-03-30 03:38:52 UTC
Hi, Aljas
    Thanks for the test. The test result is weird. The content of DSDT table is not changed in the course of suspned/resume. 
    From the log in comment #15 it seems that there exists the following warning message:
   >ACPI Error (psargs-0359): [_ksy] Namespace lookup failure, AE_NOT_FOUND
   >ACPI Error (psparse-0537): Method parse/execution failed [\_TZ_.C1F3._STA] (Node f7017348), AE_NOT_FOUND

    But from the acpidump we know that no _ksy object will be called in the \_TZ.C1F3._STA. 
   >PowerResource (C1F3, 0x00, 0x0000)
        {
            Method (_STA, 0, NotSerialized)
            {
                Return (C1EB (0x02, 0xA0))
            }
   
    If so, the above message is caused by that the content of DSDT table is changed. But unfortunately there is no change in the DSDT table. 

    At the same time when the custom DSDT is used, there is no above warning message.
    Now I can't understand why this happens.
Comment 31 Aljaz Prusnik 2009-03-31 18:27:56 UTC
Created attachment 20762 [details]
dmesg after - no X, BT&Wireless off

This time I tried stock Debian Lenny kernel (2.6.26-something) and it produced a bit more info on wake-up. I hope it's more helpful than previous attempts.

ACPI dumps remain the same before and after in this case as well (also the same under vanilla 2.6.29 kernel).
Comment 32 Matthew Garrett 2009-03-31 18:32:01 UTC
Aljaz,

How long are you leaving the system before resuming? My experiments with an nc4010 in the past suggested that the memory self refresh wasn't being enabled, leading to memory corruption and the system only resuming if tested within a few seconds of suspend. If that's the case, can you try leaving the machine for longer and check that you get the same results as you've already posted?
Comment 33 Aljaz Prusnik 2009-03-31 19:40:20 UTC
Even worse. I tried now the same exercise with all the kernels and the result was the same after 3-5 minute pause: no after files at all! This consistent behaviour didn't happen before where I got to an after file here and there.

It's really strange since suspend and wake work flawlessly under windows xp regardless of the pause in between.
Comment 34 Damir Syabitov 2009-04-25 10:24:29 UTC
Hi all. Sorry for my english at first. My new HP HDX18 laptop doesn't wake up to. After resume it can't find any hard drives. This can be reproduced in all kernels and distributions, what i try (ubuntu 8.10 (amd64, x86), Gentoo 2008 (x86_64), Fedora 10 (x86, x86_64)). All distributions have 2.6.27 kernel. On Gentoo i try kernel 2.6.29 - nothing change. When i try to boot from usb hdd and get all kernel logs. Here they are: http://unitedchat.ru/pub/hwinfo_and_logs.tar.gz .
If need more info - contact me, please dsyabitov at gmail.com
Comment 35 Damir Syabitov 2009-04-25 10:34:32 UTC
Ooops. Sorry, i'ts my mistake with many tabs opened.
Comment 36 ykzhao 2009-07-20 05:36:18 UTC
Hi, Damir
    It seems that your box is different with Aljas's. Maybe it is a different bug.
    Will you please try the latest kernel and see whether the issue still exists? If it exists, please open a new bug and attach the output of acpidump, lspci -vxxx.
    Thanks.
Comment 37 ykzhao 2009-07-20 08:21:22 UTC
Hi, Aljaz
    Sorry for the late response.
    From the comment #33 it seems that there is no file of dmesg_after. 
    Will you please double check it again?

Thanks.
Comment 38 Aljaz Prusnik 2009-07-20 08:41:02 UTC
With what kernel version (currently running 2.6.30.1)?
Comment 39 Damir Syabitov 2009-07-20 16:14:43 UTC
Hi, ykzhao! It was my mistake posting here - it's 12276 bug and now it fixed (by updating bios).
Comment 40 ykzhao 2009-07-21 00:25:59 UTC
it will be better if you can try the 2.6.31-rc3 kernel or the latest linus git tree.
Thanks.
Comment 41 Aljaz Prusnik 2009-07-22 19:36:28 UTC
Created attachment 22452 [details]
acpi before's with 2.6.31 rc3 kernel

No, no changes. It goes into sleep, then when I turn it on it just suspiciously silent, disk spins after a while but the vent and display are not in action. I have to power boot to start again and I have no after files again this time.

File's legend:
- no suffix: 2.6.31 rc3 normal kernel
- DSDT:      2.6.31 rc3 custom dsdt kernel
- DSDT2:     2.6.31 rc3 custom dsdt kernel with BT/wireless turned off.
Comment 42 Aljaz Prusnik 2009-07-22 19:36:56 UTC
GDM was stopped before trying in all three cases.
Comment 43 ykzhao 2009-07-23 01:53:54 UTC
Hi, Aljaz
    Thanks for the test.
    From the test in comment #41 it seems that there is no file of dmesg_after, which indicates that it is not resumed. But from the test in comment #24/31 it seems that the box can be resumed from S3. It is weird.
    Will you please enable "CONFIG_PM_DEBUG" in kernel configuration and do the following test?
    a. kill the process using /proc/acpi/event (use the command of "lsof /proc/acpi/event" to get the process ID)
    b. echo devices > /sys/power/pm_test
    c. echo mem > /sys/power/state; dmesg >dmesg_after_device
    d. wait for five seconds and see whether it can be resumed.
    e. If it can be resumed, please echo "platform/cpu/core" > /sys/power/pm_test on by one and repeat the step c/d.

   Thanks.
Comment 44 Matthew Garrett 2009-07-23 01:55:53 UTC
Yukai,

whether or not the system resumes will typically depend on how long it's suspended for. An immediate resume may result in a dmesg_out. As noted in comment 4, it seems as if the memory becomes corrupted over time.
Comment 45 ykzhao 2009-07-23 02:03:55 UTC
thanks for pointing out this issue.
If so, we have no way to fix this issue unless no document is available from ATI.

Suspend/resume can work well on windows XP. Maybe the memory refresh mode is handled correctly on windows XP. 

Thanks.

Note You need to log in before you can comment on or make changes to this bug.