Suspend powers off machine

Nate Lawson nate at root.org
Tue Apr 12 12:07:00 PDT 2005


Eric Anderson wrote:
> Nate Lawson wrote:
> 
>> Eric Anderson wrote:
>>
>>> I'm going to have some time on my hands next week, and I'd like to 
>>> hunt down an issue with my laptop.  When attempting to go into S3, 
>>> instead of going into S3, it powers off (uncleanly).  Can anyone tell 
>>> me where this might be happening in the code, so I can start the 
>>> printf debugging process? 
>>
>> It's nearly 100% certain it happens in AcpiEnterSleepState at the 
>> write to PM1A.  This is in sys/contrib/dev/acpica/hwsleep.c
> 
> You're right - it happens here:
> Status = AcpiHwRegisterWrite (ACPI_MTX_DO_NOT_LOCK, 
> ACPI_REGISTER_PM1A_CONTROL, PM1AControl);
> In that subroutine..

If you have access to a bus analyzer, the next step would be to monitor 
the SLP_S3#, SLP_S4#, and SLP_S5# pins on the ICH.

>> In thinking about it, my best theory is that the southbridge 
>> interprets this write as an S4/S5 transition.  Perhaps the ASL gives 
>> the wrong value to write?  Perhaps the chipset is not being prepared 
>> for S3 correctly.  In any case, better chipset specs would probably 
>> help diagnose this.
> 
> Not sure what to look for in the ASL for the valid/invalid values.  What 
> chipset info do you need?

Check the two 8 bit values returned by \_S3 against the ones for \_S4 
and \_S5.  Are they different?  Check that the value being written for 
S3 is actually what the ASL reports.  Then compare against the 
appropriate S3 definitions in the ICH-4M or whatever spec.

>> Other possibilities are that the setting of SLP_EN should be done at 
>> the same time as the write with the SLP_TYP value (i.e. write 
>> SLP_TYPE_S3|SLP_EN instead of splitting the write into two phases).  
>> It also may be that the previous steps like disabling BM ctrl are not 
>> appropriate for some chipsets.
>>
>> If you can get more info, I can refine this theory.
> 
> I'm going to keep doing some printf's in the hwregs.c file to see if I 
> can track down anything closer.

I'm not sure how productive this will be.

-- 
Nate


More information about the freebsd-acpi mailing list