linux-kernel - Re: I need some serious help to debug suspend to ram problem

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, 20 Sep 2008 18:10:44 +0200
From:	"Rafael J. Wysocki" <rjw@...k.pl>
To:	Maxim Levitsky <maximlevitsky@...il.com>
Cc:	linux-kernel@...r.kernel.org, linux-pm@...ts.linux-foundation.org,
	Alan Stern <stern@...land.harvard.edu>
Subject: Re: I need some serious help to debug suspend to ram problem

On Saturday, 20 of September 2008, Maxim Levitsky wrote:
> Hi,
> 
> I hit a dead end when trying to understand 
> why my notebook can't resume from suspend to ram
> if this is done two times a row.
> 
> Single suspend/resume cycle works almost perfectly 
> (beep that goes through the sound card is muted... 
> no morse code for me... :-(
> 
> )
> 
> I compiled a minimal kernel (absolutely nothing but disk drivers, all experimental option like nohz
> turned off)
> 
> But I had to turn SMP, since without it system won't resume first time I suspend it.
> (How could this affect suspend?)

It could if the system is 64-bit.  In which case please have a look at
http://bugzilla.kernel.org/show_bug.cgi?id=11237

> With SMP and minimal kernel (of course  no closed drivers), I get same behavior,
> first resume works second hangs.
> 
> I then added some debug code to real mode wakeup code, I put there in first
> place instructions, that will save some magic value to rtc (to alarm
> registers that I know are preserved during boot cycle), and I discovered   
> sad thing that first time bios does pass control to linux, but second time
> (when it hangs), it doesn't. 
> 
> 
> I tried to update bios, and I got same results.
> 
> Of course it does work with that @#$%^& OS

So we're doing something wrong.  Please try the appended patch.

> I then proceeded to test recently posted low memory corruption patch, and
> it did show that that @#$%^& BIOS does corrupt low memory 
> I then reserved all low memory, but system began to hand after first suspend,
> in exactly same way, but as expected I soon discovered, that that forces real
> mode page to be above 1M, ok, then I reserved almost all low memory except
> 100K window in the middle, so low allocations will work, but be placed in
> region bios less likely to corrupt, and still that didn't help, still same hang.   
>  
> You did face lot of such situations, so maybe you know about anything I can do.
> 

Actually, I didn't, but some people did.  Again,
http://bugzilla.kernel.org/show_bug.cgi?id=11237 is the place to look at.

Thanks,
Rafael

---
From: Rafael J. Wysocki <rjw@...k.pl>

ACPI suspend: Always use the 32-bit waking vector

According to the ACPI specification 2.0c and later, the 64-bit waking vector
should be cleared and the 32-bit waking vector should be used, unless we want
the wake-up code to be called by the BIOS in Protected Mode.  Moreover, some
systems (for example HP dv5-1004nr) are known to fail to resume if the 64-bit
waking vector is used.  Therefore, modify the code to clear the 64-bit waking
vector, for FACS version 1 or greater, and set the 32-bit one before suspend.

Signed-off-by: Rafael J. Wysocki <rjw@...k.pl>
---
 drivers/acpi/hardware/hwsleep.c |   37 +++++++++++--------------------------
 1 file changed, 11 insertions(+), 26 deletions(-)

Index: linux-2.6/drivers/acpi/hardware/hwsleep.c
===================================================================
--- linux-2.6.orig/drivers/acpi/hardware/hwsleep.c
+++ linux-2.6/drivers/acpi/hardware/hwsleep.c
@@ -78,19 +78,17 @@ acpi_set_firmware_waking_vector(acpi_phy
 		return_ACPI_STATUS(status);
 	}
 
-	/* Set the vector */
+	/*
+	 * According to the ACPI specification 2.0c and later, the 64-bit
+	 * waking vector should be cleared and the 32-bit waking vector should
+	 * be used, unless we want the wake-up code to be called by the BIOS in
+	 * Protected Mode.  Some systems (for example HP dv5-1004nr) are known
+	 * to fail to resume if the 64-bit vector is used.
+	 */
+	if (facs->version >= 1)
+		facs->xfirmware_waking_vector = 0;
 
-	if ((facs->length < 32) || (!(facs->xfirmware_waking_vector))) {
-		/*
-		 * ACPI 1.0 FACS or short table or optional X_ field is zero
-		 */
-		facs->firmware_waking_vector = (u32) physical_address;
-	} else {
-		/*
-		 * ACPI 2.0 FACS with valid X_ field
-		 */
-		facs->xfirmware_waking_vector = physical_address;
-	}
+	facs->firmware_waking_vector = (u32)physical_address;
 
 	return_ACPI_STATUS(AE_OK);
 }
@@ -134,20 +132,7 @@ acpi_get_firmware_waking_vector(acpi_phy
 	}
 
 	/* Get the vector */
-
-	if ((facs->length < 32) || (!(facs->xfirmware_waking_vector))) {
-		/*
-		 * ACPI 1.0 FACS or short table or optional X_ field is zero
-		 */
-		*physical_address =
-		    (acpi_physical_address) facs->firmware_waking_vector;
-	} else {
-		/*
-		 * ACPI 2.0 FACS with valid X_ field
-		 */
-		*physical_address =
-		    (acpi_physical_address) facs->xfirmware_waking_vector;
-	}
+	*physical_address = (acpi_physical_address)facs->firmware_waking_vector;
 
 	return_ACPI_STATUS(AE_OK);
 }
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/