public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Shaohua Li <shaohua.li@intel.com>
To: stefandoesinger@gmx.at
Cc: acpi-dev <acpi-devel@lists.sourceforge.net>,
	Matthew Garrett <mjg59@srcf.ucam.org>,
	lkml <linux-kernel@vger.kernel.org>, Pavel Machek <pavel@ucw.cz>
Subject: S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM))
Date: Tue, 07 Jun 2005 14:23:30 +0800	[thread overview]
Message-ID: <1118125410.3828.12.camel@linux-hp.sh.intel.com> (raw)
In-Reply-To: <200506061531.41132.stefandoesinger@gmx.at>

On Mon, 2005-06-06 at 23:31 +0800, stefandoesinger@gmx.at wrote:
> Am Montag, 6. Juni 2005 11:06 schrieb Matthew Garrett: 
> > Whoops. May have been a bit too hasty there. I'm not sure why that 
> > doesn't reset it, but we've now got the following (really rather
> odd) 
> > serial output. Does anyone have any idea what might be triggering
> this? 
> > Shell builtins work fine, but anything else seems to explode very 
> > messily. Memory corruption of some description?
> 
> <snip> 
> So it does reach the kernel, right? I don't know if I remembered that
> call  
> correctly, but "lcall $0xffff,$0" should call the real mode BIOS
> reset  
> code... 
> Anyone else who can correct me here?
> 
> Perhaps the disk driver is going mad? Has anyone tried to boot a
> kernel  
> without any disk drivers with a minimal root system on an initrd?
For those who suffer from strange S3 resume problem such as resume hang,
could you please try this debug patch.
It uses machine_real_restart to switch to real mode, and soon jump to
the S3 wakeup address. So it simulates how BIOS resume a system from S3,
but completely bypasses BIOS. If the system lives after S3 with the
patch, at least we can know the suspend/resume code path is ok and it's
not a Linux driver issue.

Thanks,
Shaohua

--- a/drivers/acpi/hardware/hwsleep.c	2005-06-07 13:45:04.088273424 +0800
+++ b/drivers/acpi/hardware/hwsleep.c	2005-06-07 13:49:31.858566152 +0800
@@ -242,6 +242,19 @@ acpi_enter_sleep_state_prep (
  *              THIS FUNCTION MUST BE CALLED WITH INTERRUPTS DISABLED
  *
  ******************************************************************************/
+#define S3_DEBUG
+#ifdef S3_DEBUG
+#include <asm/io.h>
+extern void machine_real_restart(unsigned char *code, int length);
+static unsigned char jump_to_pm [] =
+{
+	0xea,
+	0x00,
+	0x00,
+	0x00,
+	0x00		/*    ljmp  $0x0000,$0x0000  */
+};
+#endif
 
 acpi_status asmlinkage
 acpi_enter_sleep_state (
@@ -315,6 +328,14 @@ acpi_enter_sleep_state (
 	PM1Acontrol |= (acpi_gbl_sleep_type_a << sleep_type_reg_info->bit_position);
 	PM1Bcontrol |= (acpi_gbl_sleep_type_b << sleep_type_reg_info->bit_position);
 
+#ifdef S3_DEBUG
+	if (sleep_state == ACPI_STATE_S3) {
+		*((short *)&jump_to_pm[3]) =
+			(short)(virt_to_phys((void *)acpi_wakeup_address)) >> 4;
+		/* Directly jump to acpi_wakeup_address */
+		machine_real_restart(jump_to_pm, sizeof(jump_to_pm));
+	}
+#endif
 	/*
 	 * We split the writes of SLP_TYP and SLP_EN to workaround
 	 * poorly implemented hardware.



  reply	other threads:[~2005-06-07  6:16 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <200506051456.44810.hugelmopf@web.de>
     [not found] ` <1117978635.6648.136.camel@tyrosine>
     [not found]   ` <200506051732.08854.stefandoesinger@gmx.at>
     [not found]     ` <1118053578.6648.142.camel@tyrosine>
2005-06-06 11:06       ` Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM) Matthew Garrett
2005-06-06 14:45         ` Pavel Machek
2005-06-06 14:54           ` Matthew Garrett
2005-06-06 15:09             ` Pavel Machek
2005-06-07 14:14               ` Martin Michlmayr
2005-06-06 15:31         ` Stefan Dösinger
2005-06-07  6:23           ` Shaohua Li [this message]
2005-06-07 12:07             ` S3 test tool (was : Re: Bizarre oops after suspend to RAM (was: Re: [ACPI] Resume from Suspend to RAM)) Martin Michlmayr
2005-06-14  7:25             ` dagit
2005-06-14  8:47               ` Matthew Garrett
2005-06-14 16:24                 ` dagit
2005-06-17 13:16                   ` Matthew Garrett
2005-06-14  9:06               ` Pavel Machek
2005-06-14 15:51                 ` dagit
2005-06-14 21:37                   ` Pavel Machek
2005-06-14 22:01                     ` dagit
2005-06-14 22:09                       ` Pavel Machek
2005-06-14 22:18                         ` dagit
2005-06-14 23:11                           ` Pavel Machek
2005-06-15  0:41                             ` dagit
2005-06-15  0:50                               ` dagit
2005-06-15 18:41                               ` Pavel Machek

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=1118125410.3828.12.camel@linux-hp.sh.intel.com \
    --to=shaohua.li@intel.com \
    --cc=acpi-devel@lists.sourceforge.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mjg59@srcf.ucam.org \
    --cc=pavel@ucw.cz \
    --cc=stefandoesinger@gmx.at \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox