>> We can do bisection in EC0.UPDT to find out which statement cause
>> hang?
>
>Yes, though see below for why I don't think it'll help no
>matter what we
>find there.
Please don't give up . :-)
I need to know which statement in EC0.UPDT that could trigger the
problem.
That is very important to understand the problem correctly.
If we cannot find out that statement , then, I will dout the testing
results that guiding us to here.
>
>> My assumption is that since Windows works well, then these BIOS code
>> should have been tested ok. The only possible excuse for BIOS is that
>> Linux is using unnecessary/untested code path for
>Suspend/resume. So,
>> Eventually, we need to disable unnecessary BIOS call for
>> suspend/resume
>
>Maybe we're not collecting the right data in that case. We know that
>commenting out the call to UPDT in THM0.TMP fixes the hang.
>But it does
>not follow that the osl suspend code should avoid running UPDT.
This is still my assumption that some AML code needed to be avoided
in suspend/resume, I need data support. So, we need to dig more in
EC0.UPDT.
>
>The hang may work like this: Between boot and sleep, calling
>UPDT messes
>up something in the ec [which is why it takes >1 sleep to
>cause a hang].
>When the system tries to sleep, that something triggers and the ec
>hangs. But it may hang somewhere else than UPDT, and avoiding UPDT
>during sleep will not fix it.
If BIOS behaviors NOT correctly , then everything can happen.
>
>However, we do have one more piece of data. When it hangs, it hangs in
>\_SI._SST, because I see that line on successful sleeps (as the last
I don't know this. I always assume the hang is at _PTS.SMPI
>method before the beep) but not when it hangs (and then I also don't
>hear a beep). There are lots of calls to EC0.XXX, including to
>EC0.BEEP, within _SST, which isn't surprising if the EC is the problem.
It could be. But there should have something that trigger it.
>So perhaps I should bisect in _SST and put in the debug lines there?
>
>Here's another idea, which is a terrible hack. But there are lots of
>lines in the DSDT like
> If (LOr (SPS, WNTF))
>which I imagine is saying "If something or if WinNT". So,
>what if Linux
>pretends to be WinNT (or W98F -- which is another common
>test), at least
>for the 600x? Maybe those code paths are known to work.
>
Yes, you can try that.
Thanks,
Luming
> Please don't give up . :-)
I haven't!
> I need to know which statement in EC0.UPDT that could trigger the
> problem. That is very important to understand the problem
> correctly.
> This is still my assumption that some AML code needed to be avoided
> in suspend/resume, I need data support. So, we need to dig more in
> EC0.UPDT.
You've convinced me!
> If we cannot find out that statement , then, I will dout the testing
> results that guiding us to here.
Yes, the testing is often frustrating and unreliable because the bug
is not 100% reproducible, which is why I think it's more than 1 bug
(one reliable bug, related to THM0, and one or more flakey ones).
>> However, we do have one more piece of data. When it hangs, it hangs in
>> \_SI._SST, because I see that line on successful sleeps (as the last
> I don't know this. I always assume the hang is at _PTS.SMPI
Oh, I think you're right. Robert Moore's comment at the bugzilla
entry agrees with what you say. I was (I don't know why) assuming
that the ACPI system printed "Execute Method ..." after it finished
executing the method. In which case, seeing the PTS but not the SST
made me think that PTS worked but SST failed. However, what you say
is consistent with ACPI printing "Execute Method" as it begins a
method -- in which case seeing the PTS but not the SST means it fails
in PTS (and in PTS.SMPI).
-Sanjoy
`Never underestimate the evil of which men of power are capable.'
--Bertrand Russell, _War Crimes in Vietnam_, chapter 1.
http://bugzilla.kernel.org/show_bug.cgi?id=5989
------- Additional Comments From [email protected] 2006-02-06 14:46
You are stuck in the loop in the method below. I would guess that the
code is
waiting for a response from the SMI bios and it never happens.
Method (SMPI, 1, NotSerialized)
{
Store (S_AX, Local0)
Store (0x81, APMD)
While (LEqual (S_AH, 0xA6))
{
Sleep (0x64)
Store (Local0, S_AX)
Store (0x81, APMD)
}
}
OperationRegion (MNVS, SystemMemory, 0x23FDF000, 0x1000)
Field (MNVS, DWordAcc, NoLock, Preserve)
{
Offset (0xFC0),
S_AX, 16,
OperationRegion (APMC, SystemIO, 0xB2, 0x01)
Field (APMC, ByteAcc, NoLock, Preserve)
{
APMD, 8
Store (Local0, S_AX)
exregion-0182 [29] ex_system_memory_space: system_memory 0 (32 width)
Address=0000000023FDFFC0
Store (0x81, APMD)
exregion-0287 [30] ex_system_io_space_han: system_iO 1 (8 width)
Address=00000000000000B2
>> So perhaps I should bisect in _SST and put in the debug lines there?
>> Here's another idea, which is a terrible hack. But there are lots of
>> lines in the DSDT like
>> If (LOr (SPS, WNTF))
>> which I imagine is saying "If something or if WinNT". So,
>> what if Linux
>> pretends to be WinNT (or W98F -- which is another common
>> test), at least
>> for the 600x? Maybe those code paths are known to work.
>>
> Yes, you can try that.
I tried the patch below.
It went to sleep fine. It wouldn't wake up with the Fn key or
closing/opening the lid (both methods wake up Linux sleep). But the
power switch did the trick, and it made it through most of the wakeup.
But the screen came back toofull of garbage and not taking keyboard
input (at least not to X), and it might have been stuck in PCI0._INI.
That was the last Execute Method on the serial console, and after that
line it was just printing dots one at a time: .......
So I had to power it down (by holding the power switch until it turned
off) and could never try the second sleep.
-Sanjoy
summary: Pretend to be Windows 98 in DSDT.
diff -r bf1b330b9a7f -r 8109ef6f6d19 dsdt/600x.dsl
--- a/dsdt/600x.dsl Tue Mar 21 12:11:19 2006 -0500
+++ b/dsdt/600x.dsl Thu Mar 23 19:49:10 2006 -0500
@@ -1090,7 +1090,7 @@ DefinitionBlock ("DSDT.aml", "DSDT", 1,
})
Method (_INI, 0, NotSerialized)
{
- If (LEqual (SCMP (\_OS, "Microsoft Windows"), Zero))
+ If (One) /* LEqual (SCMP (\_OS, "Microsoft Windows"), Zero)) */
{
Store (One, W98F)
}