[REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Brecht Machiels]

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

Hi,

I recently installed (Arch x86_64) Linux with the 3.12.1 kernel on a Toshiba Satellite L300 laptop. After shutting down Linux, the laptop will spontaneously boot up after about five minutes. This seems to be consistent. There are no options in the BIOS for en/disabling or configuring the RTC wakeup alarm. After 'shudown --halt' and shutting down the laptop manually (pressing the power button for 3 seconds), it will not spontaneously boot up. I understand Linux is configuring the RTC alarm on shutdown? 

After finding some other reports of similar problems, I have built a custom 3.12.1 kernel after reverting commit 41c7f74 (rtc: Disable the alarm in the hardware (v2)) [1]. This seems to solve the problem for me.

Related discussions and bug reports:
* http://thread.gmane.org/gmane.linux.kernel/1527538
  refers to: https://bugzilla.novell.com/show_bug.cgi?id=812592
             https://bugzilla.novell.com/show_bug.cgi?id=805740
* http://thread.gmane.org/gmane.linux.kernel/1275165/focus=1388471
  refers to: http://bugs.debian.org/691902

Both LKML threads seem to have died without any action being taken.

Setting the RTC alarm time way in the future, as suggested in [2] didn't work for me.

Output of dmidecode is attached. Please let me know if any other information could be useful.

[1] https://github.com/torvalds/linux/commit/41c7f74
[2] https://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=256816

Best regards
-- 
Brecht Machiels

[-- Attachment #2: dmidecode_toshiba_pslb8e.log --]
[-- Type: text/plain, Size: 11483 bytes --]

# dmidecode 2.12
SMBIOS 2.4 present.
35 structures occupying 1491 bytes.
Table at 0x000E8150.

Handle 0x0000, DMI type 0, 24 bytes
BIOS Information
	Vendor: INSYDE
	Version: 2.20
	Release Date: 12/09/2009
	ROM Size: 1024 kB
	Characteristics:
		PCI is supported
		BIOS is upgradeable
		BIOS shadowing is allowed
		Boot from CD is supported
		Selectable boot is supported
		BIOS ROM is socketed
		EDD is supported
		Japanese floppy for NEC 9800 1.2 MB is supported (int 13h)
		Japanese floppy for Toshiba 1.2 MB is supported (int 13h)
		5.25"/360 kB floppy services are supported (int 13h)
		5.25"/1.2 MB floppy services are supported (int 13h)
		3.5"/720 kB floppy services are supported (int 13h)
		3.5"/2.88 MB floppy services are supported (int 13h)
		8042 keyboard services are supported (int 9h)
		CGA/mono video services are supported (int 10h)
		ACPI is supported
		USB legacy is supported
		Targeted content distribution is supported

Handle 0x0001, DMI type 1, 27 bytes
System Information
	Manufacturer: TOSHIBA
	Product Name: Satellite L300
	Version: PSLB8E-15P00DBT
	Serial Number: 99031030Q
	UUID: CF9C87E0-9691-11DE-BBA9-001E33F3CD6A
	Wake-up Type: Power Switch
	SKU Number: Montevina_Fab
	Family: Intel_Mobile

Handle 0x0002, DMI type 2, 16 bytes
Base Board Information
	Manufacturer: TOSHIBA
	Product Name: Portable PC
	Version: Base Board Version
	Serial Number: Base Board Serial Number
	Asset Tag: Base Board Asset Tag
	Features:
		Board is a hosting board
		Board is replaceable
	Location In Chassis: Base Board Chassis Location
	Chassis Handle: 0x0003
	Type: Motherboard
	Contained Object Handles: 0

Handle 0x0003, DMI type 3, 22 bytes
Chassis Information
	Manufacturer: Chassis Manufacturer
	Type: Notebook
	Lock: Not Present
	Version: Chassis Version
	Serial Number: Chassis Serial Number
	Asset Tag: No Asset Tag
	Boot-up State: Safe
	Power Supply State: Safe
	Thermal State: Safe
	Security Status: None
	OEM Information: 0x00000000
	Height: Unspecified
	Number Of Power Cords: 1
	Contained Elements: 0
	SKU Number: Not Specified

Handle 0x0004, DMI type 5, 20 bytes
Memory Controller Information
	Error Detecting Method: None
	Error Correcting Capabilities:
		None
	Supported Interleave: One-way Interleave
	Current Interleave: One-way Interleave
	Maximum Memory Module Size: 4096 MB
	Maximum Total Memory Size: 8192 MB
	Supported Speeds:
		Other
	Supported Memory Types:
		Other
	Memory Module Voltage: Unknown
	Associated Memory Slots: 2
		0x0000
		0x0000
	Enabled Error Correcting Capabilities:
		None

Handle 0x0005, DMI type 9, 13 bytes
System Slot Information
	Designation: J6B2
	Type: x16 PCI Express
	Current Usage: Available
	Length: Other
	ID: 0
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0006, DMI type 9, 13 bytes
System Slot Information
	Designation: J6B1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 0
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0007, DMI type 9, 13 bytes
System Slot Information
	Designation: J6C2
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 1
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0008, DMI type 9, 13 bytes
System Slot Information
	Designation: J7B1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 2
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x0009, DMI type 9, 13 bytes
System Slot Information
	Designation: J8B3
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 3
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x000A, DMI type 9, 13 bytes
System Slot Information
	Designation: J8D1
	Type: x1 PCI Express
	Current Usage: Available
	Length: Other
	ID: 4
	Characteristics:
		PME signal is supported
		Hot-plug devices are supported

Handle 0x000B, DMI type 11, 5 bytes
OEM Strings
	String 1: SSLB8E15P00DBT
	String 2:              
	String 3:              
	String 4:              
	String 5: SSLB8E15P00DBT

Handle 0x000C, DMI type 12, 5 bytes
System Configuration Options
	Option 1: NVR:00707002
	Option 2: DSN: 89I2SGQQS          
	Option 3: DSN:M4 70T5663EH3-CF7 6184D953 
	Option 4: DSN:4D0F3E37

Handle 0x000D, DMI type 15, 29 bytes
System Event Log
	Area Length: 32672 bytes
	Header Start Offset: 0x0000
	Data Start Offset: 0x0000
	Access Method: General-purpose non-volatile data functions
	Access Address: 0x0000
	Status: Valid, Not Full
	Change Token: 0x12345678
	Header Format: OEM-specific
	Supported Log Type Descriptors: 3
	Descriptor 1: POST memory resize
	Data Format 1: None
	Descriptor 2: POST error
	Data Format 2: POST results bitmap
	Descriptor 3: Log area reset/cleared
	Data Format 3: None

Handle 0x000E, DMI type 21, 7 bytes
Built-in Pointing Device
	Type: Touch Pad
	Interface: PS/2
	Buttons: 4

Handle 0x000F, DMI type 27, 14 bytes
Cooling Device
	Type: Fan
	Status: OK
	OEM-specific Information: 0x00000000
	Nominal Speed: 43690 rpm

Handle 0x0010, DMI type 32, 20 bytes
System Boot Information
	Status: No errors detected

Handle 0x0011, DMI type 39, 22 bytes
System Power Supply
	Location: OEM_Define0
	Name: OEM_Define1
	Manufacturer: OEM_Define2
	Serial Number: OEM_Define2
	Asset Tag: OEM_Define3
	Model Part Number: OEM_Define4
	Revision: OEM_Define5
	Max Power Capacity: 75 W
	Status: Present, OK
	Type: Regulator
	Input Voltage Range Switching: Auto-switch
	Plugged: No
	Hot Replaceable: No

Handle 0x0012, DMI type 129, 5 bytes
OEM-specific Type
	Header and Data:
		81 05 12 00 4F
	Strings:
		em Test 1
		Oem Test 2

Handle 0x0013, DMI type 16, 15 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 8 GB
	Error Information Handle: No Error
	Number Of Devices: 2

Handle 0x0014, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM0
	Bank Connections: 0 0
	Current Speed: 1 ns
	Type: None
	Installed Size: 2048 MB (Single-bank Connection)
	Enabled Size: 2048 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0015, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: 0x0016
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM0
	Bank Locator: BANK 0
	Type: DDR2
	Type Detail: Synchronous
	Speed: 800 MHz
	Manufacturer: Samsung
	Serial Number: 6184D9AF
	Asset Tag: Unknown
	Part Number: AFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAFAF

Handle 0x0016, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x0017, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0015
	Memory Array Mapped Address Handle: 0x001D
	Partition Row Position: Unknown
	Interleave Position: 1
	Interleaved Data Depth: 1

Handle 0x0018, DMI type 6, 12 bytes
Memory Module Information
	Socket Designation: DIMM2
	Bank Connections: 0 0
	Current Speed: 1 ns
	Type: None
	Installed Size: 2048 MB (Single-bank Connection)
	Enabled Size: 2048 MB (Single-bank Connection)
	Error Status: OK

Handle 0x0019, DMI type 17, 27 bytes
Memory Device
	Array Handle: 0x0013
	Error Information Handle: 0x001A
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 2048 MB
	Form Factor: SODIMM
	Set: None
	Locator: DIMM2
	Bank Locator: BANK 2
	Type: DDR2
	Type Detail: Synchronous
	Speed: 800 MHz
	Manufacturer: Samsung
	Serial Number: 7742A109
	Asset Tag: Unknown
	Part Number: 090909090909090909090909090909090909

Handle 0x001A, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x001B, DMI type 20, 19 bytes
Memory Device Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x0007FFFFFFF
	Range Size: 2 GB
	Physical Device Handle: 0x0019
	Memory Array Mapped Address Handle: 0x001D
	Partition Row Position: Unknown
	Interleave Position: 2
	Interleaved Data Depth: 1

Handle 0x001C, DMI type 18, 23 bytes
32-bit Memory Error Information
	Type: OK
	Granularity: Unknown
	Operation: Unknown
	Vendor Syndrome: Unknown
	Memory Array Address: Unknown
	Device Address: Unknown
	Resolution: Unknown

Handle 0x001D, DMI type 19, 15 bytes
Memory Array Mapped Address
	Starting Address: 0x00000000000
	Ending Address: 0x000FFFFFFFF
	Range Size: 4 GB
	Physical Array Handle: 0x0013
	Partition Width: 2

Handle 0x001E, DMI type 4, 35 bytes
Processor Information
	Socket Designation: CPU
	Type: Central Processor
	Family: Pentium M
	Manufacturer: Intel(R) Corporation
	ID: 7A 06 01 00 FF FB EB BF
	Signature: Type 0, Family 6, Model 23, Stepping 10
	Flags:
		FPU (Floating-point unit on-chip)
		VME (Virtual mode extension)
		DE (Debugging extension)
		PSE (Page size extension)
		TSC (Time stamp counter)
		MSR (Model specific registers)
		PAE (Physical address extension)
		MCE (Machine check exception)
		CX8 (CMPXCHG8 instruction supported)
		APIC (On-chip APIC hardware supported)
		SEP (Fast system call)
		MTRR (Memory type range registers)
		PGE (Page global enable)
		MCA (Machine check architecture)
		CMOV (Conditional move instruction supported)
		PAT (Page attribute table)
		PSE-36 (36-bit page size extension)
		CLFSH (CLFLUSH instruction supported)
		DS (Debug store)
		ACPI (ACPI supported)
		MMX (MMX technology supported)
		FXSR (FXSAVE and FXSTOR instructions supported)
		SSE (Streaming SIMD extensions)
		SSE2 (Streaming SIMD extensions 2)
		SS (Self-snoop)
		HTT (Multi-threading)
		TM (Thermal monitor supported)
		PBE (Pending break enabled)
	Version: Celeron(R) Dual-Core CPU       T3000  @ 1.80GHz
	Voltage: 1.6 V
	External Clock: 800 MHz
	Max Speed: 1800 MHz
	Current Speed: 1800 MHz
	Status: Populated, Enabled
	Upgrade: <OUT OF SPEC>
	L1 Cache Handle: 0x0021
	L2 Cache Handle: 0x001F
	L3 Cache Handle: Not Provided
	Serial Number: Not Specified
	Asset Tag: FFFF
	Part Number: Not Specified

Handle 0x001F, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 2
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 1024 kB
	Maximum Size: 1024 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Unified
	Associativity: 4-way Set-associative

Handle 0x0020, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Instruction
	Associativity: 8-way Set-associative

Handle 0x0021, DMI type 7, 19 bytes
Cache Information
	Socket Designation: Unknown
	Configuration: Enabled, Not Socketed, Level 1
	Operational Mode: Write Back
	Location: Internal
	Installed Size: 32 kB
	Maximum Size: 32 kB
	Supported SRAM Types:
		Synchronous
	Installed SRAM Type: Synchronous
	Speed: Unknown
	Error Correction Type: Single-bit ECC
	System Type: Data
	Associativity: 8-way Set-associative

Handle 0x0022, DMI type 127, 4 bytes
End Of Table

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[John Stultz]

On 12/01/2013 01:03 PM, Brecht Machiels wrote:
> Hi,
>
> I recently installed (Arch x86_64) Linux with the 3.12.1 kernel on a Toshiba Satellite L300 laptop. After shutting down Linux, the laptop will spontaneously boot up after about five minutes. This seems to be consistent. There are no options in the BIOS for en/disabling or configuring the RTC wakeup alarm. After 'shudown --halt' and shutting down the laptop manually (pressing the power button for 3 seconds), it will not spontaneously boot up. I understand Linux is configuring the RTC alarm on shutdown? 
>
> After finding some other reports of similar problems, I have built a custom 3.12.1 kernel after reverting commit 41c7f74 (rtc: Disable the alarm in the hardware (v2)) [1]. This seems to solve the problem for me.
>
> Related discussions and bug reports:
> * http://thread.gmane.org/gmane.linux.kernel/1527538
>   refers to: https://bugzilla.novell.com/show_bug.cgi?id=812592
>              https://bugzilla.novell.com/show_bug.cgi?id=805740
> * http://thread.gmane.org/gmane.linux.kernel/1275165/focus=1388471
>   refers to: http://bugs.debian.org/691902
>
> Both LKML threads seem to have died without any action being taken.
>
> Setting the RTC alarm time way in the future, as suggested in [2] didn't work for me.
>
> Output of dmidecode is attached. Please let me know if any other information could be useful.
>
> [1] https://github.com/torvalds/linux/commit/41c7f74
> [2] https://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=256816

Ok, sorry about this. I've been hoping we'd get some better insight into
what's actually happening on these strange BIOSes where disabling the
irq seems to cause it to scream (powering the system back on when its
shutdown), in the hopes of having a proper workaround. But despite
Borislav's efforts, he didn't seem to be able to root cause the issue.

So sadly at this point I guess having the dmi based quirk is the only
reasonable approach. The downside is it will end up killing alarm
functionality on the hardware.

Let me know if the following functions for you (I think I've added the
quirk properly for your system, but am not sure).

Borislav, could you double check this patch still works on your hardware
as well?

thanks
-john


>From 7dd7346bf06fbc4df626d7fc7e241d80165a40c4 Mon Sep 17 00:00:00 2001
From: Borislav Petkov <bp@alien8.de>
Date: Sat, 20 Jul 2013 19:00:23 +0200
Subject: [PATCH] rtc-cmos: Add an alarm disable quirk

41c7f7424259f ("rtc: Disable the alarm in the hardware (v2)") added the
functionality to disable the RTC wake alarm when shutting down the box.

However, there are at least two b0rked BIOSes we know about:

https://bugzilla.novell.com/show_bug.cgi?id=812592
https://bugzilla.novell.com/show_bug.cgi?id=805740

where, when wakeup alarm is enabled in the BIOS, the machine reboots
automatically right after shutdown, regardless of what wakeup time is
programmed.

Bisecting the issue lead to this patch so disable its functionality with
a DMI quirk only for those boxes.

Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: John Stultz <john.stultz@linaro.org>
Cc: Rabin Vincent <rabin.vincent@stericsson.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
[Changed variable name for clarity, added extra dmi entry]
Signed-off-by: John Stultz <john.stultz@linaro.org>
---
 drivers/rtc/rtc-cmos.c | 52 +++++++++++++++++++++++++++++++++++++++++++++++++-
 1 file changed, 51 insertions(+), 1 deletion(-)

diff --git a/drivers/rtc/rtc-cmos.c b/drivers/rtc/rtc-cmos.c
index f148762..a2325bc 100644
--- a/drivers/rtc/rtc-cmos.c
+++ b/drivers/rtc/rtc-cmos.c
@@ -34,11 +34,11 @@
 #include <linux/interrupt.h>
 #include <linux/spinlock.h>
 #include <linux/platform_device.h>
-#include <linux/mod_devicetable.h>
 #include <linux/log2.h>
 #include <linux/pm.h>
 #include <linux/of.h>
 #include <linux/of_platform.h>
+#include <linux/dmi.h>
 
 /* this is for "generic access to PC-style RTC" using CMOS_READ/CMOS_WRITE */
 #include <asm-generic/rtc.h>
@@ -377,6 +377,51 @@ static int cmos_set_alarm(struct device *dev, struct rtc_wkalrm *t)
 	return 0;
 }
 
+/*
+ * Do not disable RTC alarm on shutdown - workaround for b0rked BIOSes.
+ */
+static bool alarm_disable_quirk;
+
+static int __init set_alarm_disable_quirk(const struct dmi_system_id *id)
+{
+	alarm_disable_quirk = true;
+	pr_info("rtc-cmos: BIOS has alarm-disable quirk. ");
+	pr_info("RTC alarms disabled\n");
+	return 0;
+}
+
+static const struct dmi_system_id rtc_quirks[] __initconst = {
+	/* https://bugzilla.novell.com/show_bug.cgi?id=805740 */
+	{
+		.callback = set_alarm_disable_quirk,
+		.ident    = "IBM Truman",
+		.matches  = {
+			DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "4852570"),
+		},
+	},
+	/* https://bugzilla.novell.com/show_bug.cgi?id=812592 */
+	{
+		.callback = set_alarm_disable_quirk,
+		.ident    = "Gigabyte GA-990XA-UD3",
+		.matches  = {
+			DMI_MATCH(DMI_SYS_VENDOR,
+					"Gigabyte Technology Co., Ltd."),
+			DMI_MATCH(DMI_PRODUCT_NAME, "GA-990XA-UD3"),
+		},
+	},
+	/* http://permalink.gmane.org/gmane.linux.kernel/1604474 */
+	{
+		.callback = set_alarm_disable_quirk,
+		.ident    = "Toshiba Satellite L300",
+		.matches  = {
+			DMI_MATCH(DMI_SYS_VENDOR, "TOSHIBA"),
+			DMI_MATCH(DMI_PRODUCT_NAME, "Satellite L300"),
+		},
+	},
+	{}
+};
+
 static int cmos_alarm_irq_enable(struct device *dev, unsigned int enabled)
 {
 	struct cmos_rtc	*cmos = dev_get_drvdata(dev);
@@ -385,6 +430,9 @@ static int cmos_alarm_irq_enable(struct device *dev, unsigned int enabled)
 	if (!is_valid_irq(cmos->irq))
 		return -EINVAL;
 
+	if (alarm_disable_quirk)
+		return 0;
+
 	spin_lock_irqsave(&rtc_lock, flags);
 
 	if (enabled)
@@ -1157,6 +1205,8 @@ static int __init cmos_init(void)
 			platform_driver_registered = true;
 	}
 
+	dmi_check_system(rtc_quirks);
+
 	if (retval == 0)
 		return 0;
 
-- 
1.8.3.2

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Borislav Petkov]

On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote:
> Ok, sorry about this. I've been hoping we'd get some better insight
> into what's actually happening on these strange BIOSes where disabling
> the irq seems to cause it to scream (powering the system back on when
> its shutdown), in the hopes of having a proper workaround. But despite
> Borislav's efforts, he didn't seem to be able to root cause the issue.

Right, this bug is too nasty - you could generate good random numbers
just from how the hardware behaves. :) And I've been trying to make
sense of what happens but I failed, as you know. :(

I consider it a huge waste of time and efforts having to deal with such
b0rked hardware instead of throwing it out of the window into the poring
rain while it is still powered.

> Borislav, could you double check this patch still works on your
> hardware as well?

Well, we have the patch in SLES11:

http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11-SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a

and it passed testing.

>From what I see below, your version is equivalent to the one above
with the logic reversed so it should work. I'll still try to get that
affected box and run your version on it but it'll take a while.

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Brecht Machiels]

On Mon, 02 Dec 2013 22:19:58 +0100, Borislav Petkov wrote:

> On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote:
>> Ok, sorry about this. I've been hoping we'd get some better insight
>> into what's actually happening on these strange BIOSes where disabling
>> the irq seems to cause it to scream (powering the system back on when
>> its shutdown), in the hopes of having a proper workaround. But despite
>> Borislav's efforts, he didn't seem to be able to root cause the issue.
> 
> Right, this bug is too nasty - you could generate good random numbers
> just from how the hardware behaves. :) And I've been trying to make
> sense of what happens but I failed, as you know. :(
> 
> I consider it a huge waste of time and efforts having to deal with such
> b0rked hardware instead of throwing it out of the window into the poring
> rain while it is still powered.
> 
>> Borislav, could you double check this patch still works on your
>> hardware as well?
> 
> Well, we have the patch in SLES11:
> 
> http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11-
SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a
> 
> and it passed testing.
> 
> From what I see below, your version is equivalent to the one above with
> the logic reversed so it should work. I'll still try to get that
> affected box and run your version on it but it'll take a while.

Hello John and Boris,

Thank you for your quick response. And no need for an apology, I can 
understand your frustration with the way some hardware behaves.

I ran with John's patch for a couple of days, and it seems to work. 
Curiously, the laptop did spontaneously boot the first time that I shut 
it down with the patched kernel. I have no conclusive explanation for 
this, but I have noticed that a manual power down is necessary after 
booting with an unpatched kernel. Simply rebooting with a patched kernel 
is not enough to stop the spontaneous boots. As far as I can remember, I 
went directly from my custom kernel (with the v2 patch reverted) to a 
kernel with your patch applied, so I'm not 100% convinced everything is 
all right. I should say that I did experience some spontaneous boots when 
running only Windows XP in the past, so there may be occasions where 
drivers might not be able to help at all.

Thankfully, after other shutdowns/hibernates (about 6 in total) the 
laptop never booted spontaneously.

As for killing alarm functionality on the affected systems, I did some 
quick tests. With the patched kernel, I can set the RTC alarm by echoing 
to /sys/class/rtc/rtc0/wakealarm, and the machine will boot at the 
specified time. I have also tried setting the RTC alarm, and then 
disabling it again by echoing '0' to /sys/class/rtc/rtc0/wakealarm. While 
this sets the alrm_time to five minutes in the future, alarm_IRQ is set 
to 'no' and the machine does *not* boot spontaneously 5 minutes after 
shutting down. So, all seems well, as far as I can see. Unfortunately, I 
don't know enough about the RTC driver to draw any conclusions from this.

Best regards,
Brecht

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[John Stultz]

On 12/02/2013 12:47 PM, John Stultz wrote:
> On 12/01/2013 01:03 PM, Brecht Machiels wrote:
>> Hi,
>>
>> I recently installed (Arch x86_64) Linux with the 3.12.1 kernel on a Toshiba Satellite L300 laptop. After shutting down Linux, the laptop will spontaneously boot up after about five minutes. This seems to be consistent. There are no options in the BIOS for en/disabling or configuring the RTC wakeup alarm. After 'shudown --halt' and shutting down the laptop manually (pressing the power button for 3 seconds), it will not spontaneously boot up. I understand Linux is configuring the RTC alarm on shutdown? 
>>
>> After finding some other reports of similar problems, I have built a custom 3.12.1 kernel after reverting commit 41c7f74 (rtc: Disable the alarm in the hardware (v2)) [1]. This seems to solve the problem for me.
>>
>> Related discussions and bug reports:
>> * http://thread.gmane.org/gmane.linux.kernel/1527538
>>   refers to: https://bugzilla.novell.com/show_bug.cgi?id=812592
>>              https://bugzilla.novell.com/show_bug.cgi?id=805740
>> * http://thread.gmane.org/gmane.linux.kernel/1275165/focus=1388471
>>   refers to: http://bugs.debian.org/691902
>>
>> Both LKML threads seem to have died without any action being taken.
>>
>> Setting the RTC alarm time way in the future, as suggested in [2] didn't work for me.
>>
>> Output of dmidecode is attached. Please let me know if any other information could be useful.
>>
>> [1] https://github.com/torvalds/linux/commit/41c7f74
>> [2] https://forums.computers.toshiba-europe.com/forums/thread.jspa?messageID=256816
> Ok, sorry about this. I've been hoping we'd get some better insight into
> what's actually happening on these strange BIOSes where disabling the
> irq seems to cause it to scream (powering the system back on when its
> shutdown), in the hopes of having a proper workaround. But despite
> Borislav's efforts, he didn't seem to be able to root cause the issue.
>
> So sadly at this point I guess having the dmi based quirk is the only
> reasonable approach. The downside is it will end up killing alarm
> functionality on the hardware.
>
> Let me know if the following functions for you (I think I've added the
> quirk properly for your system, but am not sure).


Hey Brecht,
   Just wanted to follow up and see if you had a chance to try this patch?

thanks
-john

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[John Stultz]

On 12/05/2013 03:51 AM, Brecht Machiels wrote:
> On Mon, 02 Dec 2013 22:19:58 +0100, Borislav Petkov wrote:
>
>> On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote:
>>> Ok, sorry about this. I've been hoping we'd get some better insight
>>> into what's actually happening on these strange BIOSes where disabling
>>> the irq seems to cause it to scream (powering the system back on when
>>> its shutdown), in the hopes of having a proper workaround. But despite
>>> Borislav's efforts, he didn't seem to be able to root cause the issue.
>> Right, this bug is too nasty - you could generate good random numbers
>> just from how the hardware behaves. :) And I've been trying to make
>> sense of what happens but I failed, as you know. :(
>>
>> I consider it a huge waste of time and efforts having to deal with such
>> b0rked hardware instead of throwing it out of the window into the poring
>> rain while it is still powered.
>>
>>> Borislav, could you double check this patch still works on your
>>> hardware as well?
>> Well, we have the patch in SLES11:
>>
>> http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11-
> SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a
>> and it passed testing.
>>
>> From what I see below, your version is equivalent to the one above with
>> the logic reversed so it should work. I'll still try to get that
>> affected box and run your version on it but it'll take a while.
> Hello John and Boris,
>
> Thank you for your quick response. And no need for an apology, I can 
> understand your frustration with the way some hardware behaves.
>
> I ran with John's patch for a couple of days, and it seems to work. 
> Curiously, the laptop did spontaneously boot the first time that I shut 
> it down with the patched kernel. I have no conclusive explanation for 
> this, but I have noticed that a manual power down is necessary after 
> booting with an unpatched kernel. Simply rebooting with a patched kernel 
> is not enough to stop the spontaneous boots. As far as I can remember, I 
> went directly from my custom kernel (with the v2 patch reverted) to a 
> kernel with your patch applied, so I'm not 100% convinced everything is 
> all right. I should say that I did experience some spontaneous boots when 
> running only Windows XP in the past, so there may be occasions where 
> drivers might not be able to help at all.

Yea. It seems almost like the RTC_AIE bit is inverted in the hardware or
something.

> Thankfully, after other shutdowns/hibernates (about 6 in total) the 
> laptop never booted spontaneously.
>
> As for killing alarm functionality on the affected systems, I did some 
> quick tests. With the patched kernel, I can set the RTC alarm by echoing 
> to /sys/class/rtc/rtc0/wakealarm, and the machine will boot at the 
> specified time. I have also tried setting the RTC alarm, and then 
> disabling it again by echoing '0' to /sys/class/rtc/rtc0/wakealarm. While 
> this sets the alrm_time to five minutes in the future, alarm_IRQ is set 
> to 'no' and the machine does *not* boot spontaneously 5 minutes after 
> shutting down. So, all seems well, as far as I can see. Unfortunately, I 
> don't know enough about the RTC driver to draw any conclusions from this.

Ok. Sounds like the patch works fairly well then. I'll go ahead and
queue it for 3.14 and -stable.

thanks
-john

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[John Stultz]

On 12/12/2013 11:39 AM, John Stultz wrote:
> On 12/05/2013 03:51 AM, Brecht Machiels wrote:
>> On Mon, 02 Dec 2013 22:19:58 +0100, Borislav Petkov wrote:
>>
>>> On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote:
>>>> Ok, sorry about this. I've been hoping we'd get some better insight
>>>> into what's actually happening on these strange BIOSes where disabling
>>>> the irq seems to cause it to scream (powering the system back on when
>>>> its shutdown), in the hopes of having a proper workaround. But despite
>>>> Borislav's efforts, he didn't seem to be able to root cause the issue.
>>> Right, this bug is too nasty - you could generate good random numbers
>>> just from how the hardware behaves. :) And I've been trying to make
>>> sense of what happens but I failed, as you know. :(
>>>
>>> I consider it a huge waste of time and efforts having to deal with such
>>> b0rked hardware instead of throwing it out of the window into the poring
>>> rain while it is still powered.
>>>
>>>> Borislav, could you double check this patch still works on your
>>>> hardware as well?
>>> Well, we have the patch in SLES11:
>>>
>>> http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11-
>> SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a
>>> and it passed testing.
>>>
>>> From what I see below, your version is equivalent to the one above with
>>> the logic reversed so it should work. I'll still try to get that
>>> affected box and run your version on it but it'll take a while.
>> Hello John and Boris,
>>
>> Thank you for your quick response. And no need for an apology, I can 
>> understand your frustration with the way some hardware behaves.
>>
>> I ran with John's patch for a couple of days, and it seems to work. 
>> Curiously, the laptop did spontaneously boot the first time that I shut 
>> it down with the patched kernel. I have no conclusive explanation for 
>> this, but I have noticed that a manual power down is necessary after 
>> booting with an unpatched kernel. Simply rebooting with a patched kernel 
>> is not enough to stop the spontaneous boots. As far as I can remember, I 
>> went directly from my custom kernel (with the v2 patch reverted) to a 
>> kernel with your patch applied, so I'm not 100% convinced everything is 
>> all right. I should say that I did experience some spontaneous boots when 
>> running only Windows XP in the past, so there may be occasions where 
>> drivers might not be able to help at all.
> Yea. It seems almost like the RTC_AIE bit is inverted in the hardware or
> something.
>
>> Thankfully, after other shutdowns/hibernates (about 6 in total) the 
>> laptop never booted spontaneously.
>>
>> As for killing alarm functionality on the affected systems, I did some 
>> quick tests. With the patched kernel, I can set the RTC alarm by echoing 
>> to /sys/class/rtc/rtc0/wakealarm, and the machine will boot at the 
>> specified time. I have also tried setting the RTC alarm, and then 
>> disabling it again by echoing '0' to /sys/class/rtc/rtc0/wakealarm. While 
>> this sets the alrm_time to five minutes in the future, alarm_IRQ is set 
>> to 'no' and the machine does *not* boot spontaneously 5 minutes after 
>> shutting down. So, all seems well, as far as I can see. Unfortunately, I 
>> don't know enough about the RTC driver to draw any conclusions from this.
> Ok. Sounds like the patch works fairly well then. I'll go ahead and
> queue it for 3.14 and -stable.
Brecht: Is it OK if I add to the patch:
 Tested-by: Brecht Machiels <brecht@mos6581.org>

Borislav:  I'd like to add your tested by too, if you've had the chance.

thanks
-john

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Borislav Petkov]

On Thu, Dec 12, 2013 at 01:16:55PM -0800, John Stultz wrote:
> Borislav: I'd like to add your tested by too, if you've had the
> chance.

Sorry John, I still see you on the todo list but haven't had a chance due to
more pressing issues. :-\

Tell you what: I'll try to find some time over the weekend to reinstall
the box which has the issue and will give it a run. You could go ahead
and commit it but keep it on top of a branch in case it needs to be
reverted. :-)

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[John Stultz]

On 12/12/2013 01:24 PM, Borislav Petkov wrote:
> On Thu, Dec 12, 2013 at 01:16:55PM -0800, John Stultz wrote:
>> Borislav: I'd like to add your tested by too, if you've had the
>> chance.
> Sorry John, I still see you on the todo list but haven't had a chance due to
> more pressing issues. :-\

Understood. I don't mean to add extra pressure here, just want to make
sure your testing effort doesn't go unrecognized.

> Tell you what: I'll try to find some time over the weekend to reinstall
> the box which has the issue and will give it a run. You could go ahead
> and commit it but keep it on top of a branch in case it needs to be
> reverted. :-)

Will do. Thanks again, I appreciate your extra effort!

thanks
-john

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Brecht Machiels]

---- On Thu, 12 Dec 2013 22:16:55 +0100 John Stultz<john.stultz@linaro.org> wrote ---- 

 > On 12/12/2013 11:39 AM, John Stultz wrote: 
 > > On 12/05/2013 03:51 AM, Brecht Machiels wrote: 
 > >> On Mon, 02 Dec 2013 22:19:58 +0100, Borislav Petkov wrote: 
 > >> 
 > >>> On Mon, Dec 02, 2013 at 12:47:17PM -0800, John Stultz wrote: 
 > >>>> Ok, sorry about this. I've been hoping we'd get some better insight 
 > >>>> into what's actually happening on these strange BIOSes where disabling 
 > >>>> the irq seems to cause it to scream (powering the system back on when 
 > >>>> its shutdown), in the hopes of having a proper workaround. But despite 
 > >>>> Borislav's efforts, he didn't seem to be able to root cause the issue. 
 > >>> Right, this bug is too nasty - you could generate good random numbers 
 > >>> just from how the hardware behaves. :) And I've been trying to make 
 > >>> sense of what happens but I failed, as you know. :( 
 > >>> 
 > >>> I consider it a huge waste of time and efforts having to deal with such 
 > >>> b0rked hardware instead of throwing it out of the window into the poring 
 > >>> rain while it is still powered. 
 > >>> 
 > >>>> Borislav, could you double check this patch still works on your 
 > >>>> hardware as well? 
 > >>> Well, we have the patch in SLES11: 
 > >>> 
 > >>> http://kernel.opensuse.org/cgit/kernel/commit/?h=SLE11- 
 > >> SP3&id=835398eb94dca7d55acd1a2628372e602ae3252a 
 > >>> and it passed testing. 
 > >>> 
 > >>> From what I see below, your version is equivalent to the one above with 
 > >>> the logic reversed so it should work. I'll still try to get that 
 > >>> affected box and run your version on it but it'll take a while. 
 > >> Hello John and Boris, 
 > >> 
 > >> Thank you for your quick response. And no need for an apology, I can  
 > >> understand your frustration with the way some hardware behaves. 
 > >> 
 > >> I ran with John's patch for a couple of days, and it seems to work.  
 > >> Curiously, the laptop did spontaneously boot the first time that I shut  
 > >> it down with the patched kernel. I have no conclusive explanation for  
 > >> this, but I have noticed that a manual power down is necessary after  
 > >> booting with an unpatched kernel. Simply rebooting with a patched kernel  
 > >> is not enough to stop the spontaneous boots. As far as I can remember, I  
 > >> went directly from my custom kernel (with the v2 patch reverted) to a  
 > >> kernel with your patch applied, so I'm not 100% convinced everything is  
 > >> all right. I should say that I did experience some spontaneous boots when  
 > >> running only Windows XP in the past, so there may be occasions where  
 > >> drivers might not be able to help at all. 
 > > Yea. It seems almost like the RTC_AIE bit is inverted in the hardware or 
 > > something. 
 > > 
 > >> Thankfully, after other shutdowns/hibernates (about 6 in total) the  
 > >> laptop never booted spontaneously. 
 > >> 
 > >> As for killing alarm functionality on the affected systems, I did some  
 > >> quick tests. With the patched kernel, I can set the RTC alarm by echoing  
 > >> to /sys/class/rtc/rtc0/wakealarm, and the machine will boot at the  
 > >> specified time. I have also tried setting the RTC alarm, and then  
 > >> disabling it again by echoing '0' to /sys/class/rtc/rtc0/wakealarm. While  
 > >> this sets the alrm_time to five minutes in the future, alarm_IRQ is set  
 > >> to 'no' and the machine does *not* boot spontaneously 5 minutes after  
 > >> shutting down. So, all seems well, as far as I can see. Unfortunately, I  
 > >> don't know enough about the RTC driver to draw any conclusions from this. 
 > > Ok. Sounds like the patch works fairly well then. I'll go ahead and 
 > > queue it for 3.14 and -stable. 
 > Brecht: Is it OK if I add to the patch: 
 >  Tested-by: Brecht Machiels <brecht@mos6581.org> 

Sure.

Thanks,
Brecht

Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)

[Borislav Petkov]

On Thu, Dec 12, 2013 at 02:35:19PM -0800, John Stultz wrote:
> > Tell you what: I'll try to find some time over the weekend to
> > reinstall the box which has the issue and will give it a run. You
> > could go ahead and commit it but keep it on top of a branch in case
> > it needs to be reverted. :-)

Ok, looks good - just ran it on the box in question ontop of latest rc3+.

Btw, do we want to tag it for -stable, while we're at it?

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--