Tyan S2923-E suspend to ram fails to resume

Tyan S2923-E suspend to ram fails to resume

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 516 bytes --]

My system (Tyan S2923-E, dmesg attached) suspends ok in all pm_test modes, but it 
won't resume with pm_test "none".

[    6.423515] mem full: hash matches

When I press the power button, the port 80 display shows:
 FF D0 23 01 D0 ... DE
(and again each time I press it)

If I force it to turn off, then on again:
 FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5 D6 <normal boot>

Any ideas? (onboard SAS is disabled, watchdog is disabled, everything else is 
enabled, PCI-E graphics card)

-- 
Simon Arlott

[-- Attachment #2: dmesg2.bz2 --]
[-- Type: application/x-bzip, Size: 29106 bytes --]

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Pavel Machek]

On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
> My system (Tyan S2923-E, dmesg attached) suspends ok in 
> all pm_test modes, but it won't resume with pm_test 
> "none".
> 
> [    6.423515] mem full: hash matches
> 
> When I press the power button, the port 80 display shows:
> FF D0 23 01 D0 ... DE
> (and again each time I press it)
> 
> If I force it to turn off, then on again:
> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5 
> D6 <normal boot>
> 
> Any ideas? (onboard SAS is disabled, watchdog is 
> disabled, everything else is enabled, PCI-E graphics 
> card)

Try verifying if it reaches assembly code under realmode/ ...


-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Simon Arlott]

On Fri, August 8, 2008 08:14, Pavel Machek wrote:
> On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
>> My system (Tyan S2923-E, dmesg attached) suspends ok in
>> all pm_test modes, but it won't resume with pm_test
>> "none".
>>
>> [    6.423515] mem full: hash matches
>>
>> When I press the power button, the port 80 display shows:
>> FF D0 23 01 D0 ... DE
>> (and again each time I press it)
>>
>> If I force it to turn off, then on again:
>> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5
>> D6 <normal boot>
>>
>> Any ideas? (onboard SAS is disabled, watchdog is
>> disabled, everything else is enabled, PCI-E graphics
>> card)
>
> Try verifying if it reaches assembly code under realmode/ ...

I was looking at the acpi code last night but I couldn't figure
out where the last code before the actual suspend is or where it
starts executing again.

I'm also not sure how to do it, could you provide a quick patch
that immediately writes something to port 80 before doing
anything else?


-- 
Simon Arlott

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Simon Arlott]

On 08/08/08 12:20, Simon Arlott wrote:
> On Fri, August 8, 2008 08:14, Pavel Machek wrote:
>> On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
>>> My system (Tyan S2923-E, dmesg attached) suspends ok in
>>> all pm_test modes, but it won't resume with pm_test
>>> "none".
>>>
>>> [    6.423515] mem full: hash matches
>>>
>>> When I press the power button, the port 80 display shows:
>>> FF D0 23 01 D0 ... DE
>>> (and again each time I press it)
>>>
>>> If I force it to turn off, then on again:
>>> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5
>>> D6 <normal boot>
>>>
>>> Any ideas? (onboard SAS is disabled, watchdog is
>>> disabled, everything else is enabled, PCI-E graphics
>>> card)
>>
>> Try verifying if it reaches assembly code under realmode/ ...

I've tried acpi_sleep=s3_beep, and this:

diff --git a/arch/x86/kernel/acpi/realmode/wakeup.S b/arch/x86/kernel/acpi/realmode/wakeup.S
index 3355973..50e50df 100644
--- a/arch/x86/kernel/acpi/realmode/wakeup.S
+++ b/arch/x86/kernel/acpi/realmode/wakeup.S
@@ -37,6 +37,11 @@ signature:	.long	0x51ee1111
	.code16
wakeup_code:
_start:
+	movb $0xC1, %al
+	outb %al, $0x80
+	cli
+	hlt
+
	cli
	cld


Which doesn't work either.

-- 
Simon Arlott

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Pavel Machek]

On Sat 2008-08-09 15:42:22, Simon Arlott wrote:
> On 08/08/08 12:20, Simon Arlott wrote:
>> On Fri, August 8, 2008 08:14, Pavel Machek wrote:
>>> On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
>>>> My system (Tyan S2923-E, dmesg attached) suspends ok in
>>>> all pm_test modes, but it won't resume with pm_test
>>>> "none".
>>>>
>>>> [    6.423515] mem full: hash matches
>>>>
>>>> When I press the power button, the port 80 display shows:
>>>> FF D0 23 01 D0 ... DE
>>>> (and again each time I press it)
>>>>
>>>> If I force it to turn off, then on again:
>>>> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5
>>>> D6 <normal boot>
>>>>
>>>> Any ideas? (onboard SAS is disabled, watchdog is
>>>> disabled, everything else is enabled, PCI-E graphics
>>>> card)
>>>
>>> Try verifying if it reaches assembly code under realmode/ ...
>
> I've tried acpi_sleep=s3_beep, and this:
>
> diff --git a/arch/x86/kernel/acpi/realmode/wakeup.S b/arch/x86/kernel/acpi/realmode/wakeup.S
> index 3355973..50e50df 100644
> --- a/arch/x86/kernel/acpi/realmode/wakeup.S
> +++ b/arch/x86/kernel/acpi/realmode/wakeup.S
> @@ -37,6 +37,11 @@ signature:	.long	0x51ee1111
> 	.code16
> wakeup_code:
> _start:
> +	movb $0xC1, %al
> +	outb %al, $0x80
> +	cli
> +	hlt
> +
> 	cli
> 	cld
>
>
> Which doesn't work either.

Yep, that should work. When it does not, it means BIOS is not
returning to our real mode code :-(. You may want to try disabling
APIC and similar stuff, in hope of working around BIOS bug you are
hitting, but ...
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Simon Arlott]

[-- Attachment #1: Type: text/plain, Size: 4506 bytes --]

On 12/08/08 11:31, Pavel Machek wrote:
> On Sat 2008-08-09 15:42:22, Simon Arlott wrote:
>> On 08/08/08 12:20, Simon Arlott wrote:
>>> On Fri, August 8, 2008 08:14, Pavel Machek wrote:
>>>> On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
>>>>> My system (Tyan S2923-E, dmesg attached) suspends ok in
>>>>> all pm_test modes, but it won't resume with pm_test
>>>>> "none".
>>>>>
>>>>> [    6.423515] mem full: hash matches
>>>>>
>>>>> When I press the power button, the port 80 display shows:
>>>>> FF D0 23 01 D0 ... DE
>>>>> (and again each time I press it)
>>>>>
>>>>> If I force it to turn off, then on again:
>>>>> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5
>>>>> D6 <normal boot>
>>>>>
>>>>> Any ideas? (onboard SAS is disabled, watchdog is
>>>>> disabled, everything else is enabled, PCI-E graphics
>>>>> card)
>>>>
>>>> Try verifying if it reaches assembly code under realmode/ ...
>>
>> I've tried acpi_sleep=s3_beep, and this:
>> diff --git a/arch/x86/kernel/acpi/realmode/wakeup.S b/arch/x86/kernel/acpi/realmode/wakeup.S
>> Which doesn't work either.
> 
> Yep, that should work. When it does not, it means BIOS is not
> returning to our real mode code :-(. You may want to try disabling
> APIC and similar stuff, in hope of working around BIOS bug you are
> hitting, but ...

I've tried the simplest possible 32-bit UP kernel I could come up 
with (.config attached) and it still doesn't work.

(I modified post_init() to call pm_suspend(PM_SUSPEND_MEM).)

Disassembly of the BIOS shows that DE is indeed part of 0xDEAD, 
but I haven't been able to tell what it's doing between D0 and 
there... not all of the port 80 codes that are displayed are 
easily visible.

I've tried disabling all the CPU options in the BIOS, e.g. microcode 
update, VM, NMI but it doesn't help. I'm wondering if D0 is the right 
start point for the system - there's a DC code for S3 resume:

AMI Checkpoint & Beep Code List 1.71:
> The Bootblock initialization code sets up the chipset, memory and other components
> before system memory is available. The following table describes the type of
> checkpoints that may occur during the bootblock initialization portion of the BIOS:
>
> Before D0: If boot block debugger is enabled, CPU cache-as-RAM functionality is
> enabled at this point. Stack will be enabled from this point.
>
> D0: Early Boot Strap Processor (BSP) initialization like microcode update,
> frequency and other CPU critical initialization. Early chipset initialization is
> done.
>
> D1: Early super I/O initialization is done including RTC and keyboard controller.
> Serial port is enabled at this point if needed for debugging. NMI is disabled.
> Perform keyboard controller BAT test. Save power-on CPUID value in scratch
> CMOS. Go to flat mode with 4GB limit and GA20 enabled.
>
> D2: Verify the boot block checksum. System will hang here if checksum is bad.
>
> D3: Disable CACHE before memory detection. Execute full memory sizing
> module. If memory sizing module not executed, start memory refresh and
> do memory sizing in Boot block code. Do additional chipset initialization.
> Re-enable CACHE. Verify that flat mode is enabled.
>
> D4: Test base 512KB memory. Adjust policies and cache first 8MB. Set stack.
>
> D5: Bootblock code is copied from ROM to lower system memory and control is
> given to it. BIOS now executes out of RAM. Copies compressed boot block
> code to memory in right segments. Copies BIOS from ROM to RAM for faster
> access. Performs main BIOS checksum and updates recovery status
> accordingly.
>
> D6: Both key sequence and OEM specific method is checked to determine if BIOS
> recovery is forced. If BIOS recovery is necessary, control flows to
> checkpoint E0. See Bootblock Recovery Code Checkpoints section of
> document for more information.
>
> D7: Restore CPUID value back into register. The Bootblock-Runtime interface
> module is moved to system memory and control is given to it. Determine
> whether to execute serial flash.
>
> D8: The Runtime module is uncompressed into memory. CPUID information is
> stored in memory.
>
> D9: Store the Uncompressed pointer for future use in PMM. Copying Main BIOS
> into memory. Leaves all RAM below 1MB Read-Write including E000 and
> F000 shadow areas but closing SMRAM.
>
> DA: Restore CPUID value back into register. Give control to BIOS POST
> (ExecutePOSTKernel). See POST Code Checkpoints section of document for
> more information.
>
> DC: System is waking from ACPI S3 state

-- 
Simon Arlott


[-- Attachment #2: config.bz2 --]
[-- Type: application/x-bzip, Size: 3351 bytes --]

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Pavel Machek]

On Sat 2008-08-23 17:47:10, Simon Arlott wrote:
> On 12/08/08 11:31, Pavel Machek wrote:
>> On Sat 2008-08-09 15:42:22, Simon Arlott wrote:
>>> On 08/08/08 12:20, Simon Arlott wrote:
>>>> On Fri, August 8, 2008 08:14, Pavel Machek wrote:
>>>>> On Mon 2008-08-04 22:56:07, Simon Arlott wrote:
>>>>>> My system (Tyan S2923-E, dmesg attached) suspends ok in
>>>>>> all pm_test modes, but it won't resume with pm_test
>>>>>> "none".
>>>>>>
>>>>>> [    6.423515] mem full: hash matches
>>>>>>
>>>>>> When I press the power button, the port 80 display shows:
>>>>>> FF D0 23 01 D0 ... DE
>>>>>> (and again each time I press it)
>>>>>>
>>>>>> If I force it to turn off, then on again:
>>>>>> FF D0 23 01 D0 ... FF D0 23 01 D0 ... (D2?) D3 00 01 D5
>>>>>> D6 <normal boot>
>>>>>>
>>>>>> Any ideas? (onboard SAS is disabled, watchdog is
>>>>>> disabled, everything else is enabled, PCI-E graphics
>>>>>> card)
>>>>>
>>>>> Try verifying if it reaches assembly code under realmode/ ...
>>>
>>> I've tried acpi_sleep=s3_beep, and this:
>>> diff --git a/arch/x86/kernel/acpi/realmode/wakeup.S b/arch/x86/kernel/acpi/realmode/wakeup.S
>>> Which doesn't work either.
>>
>> Yep, that should work. When it does not, it means BIOS is not
>> returning to our real mode code :-(. You may want to try disabling
>> APIC and similar stuff, in hope of working around BIOS bug you are
>> hitting, but ...
>
> I've tried the simplest possible 32-bit UP kernel I could come up with 
> (.config attached) and it still doesn't work.
>
> (I modified post_init() to call pm_suspend(PM_SUSPEND_MEM).)
>
> Disassembly of the BIOS shows that DE is indeed part of 0xDEAD, but I 
> haven't been able to tell what it's doing between D0 and there... not all 
> of the port 80 codes that are displayed are easily visible.
>
> I've tried disabling all the CPU options in the BIOS, e.g. microcode 
> update, VM, NMI but it doesn't help. I'm wondering if D0 is the right start 
> point for the system - there's a DC code for S3 resume:

...you did a lot of work, but these issues are hard.

Do Windows suspend/resume on same hardware? BSD?
									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html

Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

[Simon Arlott]

On Tue, September 2, 2008 09:07, Pavel Machek wrote:
> On Sat 2008-08-23 17:47:10, Simon Arlott wrote:
>> On 12/08/08 11:31, Pavel Machek wrote:
>>> Yep, that should work. When it does not, it means BIOS is not
>>> returning to our real mode code :-(. You may want to try disabling
>>> APIC and similar stuff, in hope of working around BIOS bug you are
>>> hitting, but ...
>>
>> I've tried the simplest possible 32-bit UP kernel I could come up with
>> (.config attached) and it still doesn't work.
>>
>> (I modified post_init() to call pm_suspend(PM_SUSPEND_MEM).)
>>
>> Disassembly of the BIOS shows that DE is indeed part of 0xDEAD, but I
>> haven't been able to tell what it's doing between D0 and there... not all
>> of the port 80 codes that are displayed are easily visible.
>>
>> I've tried disabling all the CPU options in the BIOS, e.g. microcode
>> update, VM, NMI but it doesn't help. I'm wondering if D0 is the right start
>> point for the system - there's a DC code for S3 resume:
>
> ...you did a lot of work, but these issues are hard.
>
> Do Windows suspend/resume on same hardware? BSD?

Tyan is going to look into it based them being able to use a common Linux
system (Knoppix 5.1.1) that fails to resume for me.

I've tried Windows XP 64-bit SP2C, that will only go to S1.
Vista Ultimate 64-bit will only go to S1 too.

I've yet to try a BSD, but it'll be a couple of weeks before I can do
that.

-- 
Simon Arlott