lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Sat, 23 Aug 2008 17:47:10 +0100
From:	Simon Arlott <simon@...e.lp0.eu>
To:	Pavel Machek <pavel@...e.cz>
CC:	linux-pm@...ts.linux-foundation.org,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [linux-pm] Tyan S2923-E suspend to ram fails to resume

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


Download attachment "config.bz2" of type "application/x-bzip" (3351 bytes)

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ