Yu, Luming wrote:

>>I've been spending a few days trying to get suspend-to-ram to 
>>work on my 
>>new HP NX7010 laptop. Haven't had much success though so I thought I 
>>might get some help from the more experienced.
>>
>>    
>>
>
>Can you post the detailed HW info, as well as BIOS vendor/version?
>
>  
>
I've attached dmidecode, lspci -vv and lsusb -vv. That should include 
all the information you need.
The short summary is that it has a Pentium M 1.6GHz, intel 82801 
chipset, IPW2200BG wlan, CSR bluetooth, ati radeon mobility 9200 (M9), 
via firewire controller and rtl8139 network.
The bios seems to be HP's own. If it's made by someone else then they've 
hidden it properly. It's the latest version F.34 but the problem was 
identical with F.33, which the laptop was delivered with. The DSDT:s are 
also identical.

>>I'm running FC2 with linux 2.6.6. S3 has been tested using vanilla 
>>kernel and with the patch from acpi.sf.net. I've also included a patch 
>>    
>>
>>from the ACPI bugzilla to be able to control which devices can 
>  
>
>>wake the 
>>unit. The behaviour has been the same for all tests.
>>
>>    
>>
>
>What about S4?
>
>  
>
S4 works fine. But with X running it's too slow to be useful. A normal 
shutdown/startup is faster. S4bios is also available but I don't know 
what partition it wants so I haven't tried it.

>>I don't think the unit actually gets all the way into S3 though. If I 
>>turn on ACPI debug in the kernel I can see a debug message that says 
>>'Entering S3' but the laptop doesn't power down anything. After this 
>>point the only way to get control of the machine again is to hold down 
>>the power button for a couple of seconds, bypassing the OS. Also, for 
>>some strange reason I have to do this twice because the machine hangs 
>>during POST after the first reset (after a failed suspend-to-ram that 
>>is, works fine otherwise).
>>
>>    
>>
>
>This is unusual. Now, the most S3 failure focus on resuming from ram.
>Can you track down which driver might causes the problem?
>
>  
>
Don't really know how. I was hoping I could find where it stalls and 
using the DSDT to figure out which device was causing the problem. Since 
everything is integrated it's difficult to yank stuff out to eliminate 
sources of problem. If you have any ideas on how to isolate drivers I'll 
gladly try them out.

>>I've started looking in the ACPI spec. since I suspect the bug 
>>might be 
>>in the DSDT. I doesn't even compile cleanly with Intel's 
>>    
>>
>
>Did you find error message from ACPI?  
>
>You know, AML interpreter is capable of catching AML bug. Although,
>sometimes, we have to fix interpreter , rather than AML code. :)
>  
>
The error comes from when I try to compile with Intels compiler. The 
error is:

dsdt.2.dsl  2515:                     Field (C13B, AnyAcc, Lock, Preserve)
Error    1048 -                                 ^ Host Operation Region 
requires ByteAcc access

But I found a page stating that solving this problem (by replacing 
AnyAcc with ByteAcc) doesn't get suspend-to-ram working so I haven't 
bothered trying. The page in question is 
http://personal.eunet.fi/pp/joakim/nx7010.html.

As for getting output from the interpreter, I'm still trying to find a 
good balance for the acpi debug_level. I tried setting it to 0x7ffffff, 
which I figure gives me everything, wasn't very helpful since the screen 
filled up rather quickly. I did note however that some commands after 
"Entering state [S3]". These did not show when using a lower level 
(0xff). Since the machine hangs after this it is difficult to get a dump 
of the data.

Rgds
Pierre