[REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)
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 # dmidecode 2.12 SMBIOS 2.4 present. 35 structures occupying 1491 bytes. Table at 0x000E8150. Handle 0x, 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: 0x 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 0x 0x 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 sign
Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)
On Thu, 12 Dec 2013 22:16:55 +0100 John Stultz 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 Sure. Thanks, Brecht -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [REGRESSION] 41c7f74 rtc: Disable the alarm in the hardware (v2)
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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
