Distribution: Ark Linux Hardware Environment: Asus Pundit-R, BIOS 1005 Software Environment: Ark Linux dockyard-devel Problem Description: Even if wake on RTC is disabled in the BIOS and /proc/acpi/alarm has not been used at all, Asus Pundit-R boxes keep turning themselves on at 00:00:00 every day if they've been shut down cleanly. Since this doesn't happen on any other hardware, but Asus insists the problem will go away if I "upgrade to Windows XP", I'm thinking their ACPI implementation is doing something weird M$ is working around - maybe everyone else sets the wake-on-RTC flag to off by default, Asus leaves the value uninitialized, M$ clears the flag and we don't? Steps to reproduce: Install Linux (2.6.12-mm2 or 2.6.13-rc1-mm3, no other kernels tested) on an Asus Pundit-R w/ BIOS 1005 (no other BIOS revisions tested), /sbin/poweroff, wait for 00:00:00.
*** Bug 4896 has been marked as a duplicate of this bug. ***
I've fixed this in userspace by running this before shutdown -- works for me now: #include <sys/io.h> #include <sys/stat.h> #include <sys/types.h> #include <stdio.h> #include <string.h> #include <fcntl.h> #include <stdint.h> #include <stdlib.h> #include <unistd.h> #include <time.h> static uint16_t acpi_base=0x1000; static uint8_t day_alrm=0x7e; static uint8_t mon_alrm=0x7f; inline void cli() { asm("cli"); } inline void sti() { asm("sti"); } void init() { int fd=open("/proc/acpi/fadt", O_RDONLY); if(fd>=0) { lseek(fd, 0x6a, SEEK_SET); read(fd, &day_alrm, 1); read(fd, &mon_alrm, 1); lseek(fd, 0x98, SEEK_SET); read(fd, &acpi_base, 2); close(fd); if(day_alrm == mon_alrm) { // BROKEN fadt day_alrm=0x7e; mon_alrm=0x7f; } } else fprintf(stderr, "Warning: Your ACPI BIOS fails to provide an FADT. Assuming default values:\nACPI base: %04x\nDay stored in %02x\nMonth stored in %02x\n", acpi_base, day_alrm, mon_alrm); } int main(int argc, char **argv) { init(); iopl(3); cli(); outb_p(0x34, acpi_base + 5); sti(); iopl(0); }
can you please print the value of 'acpi_base + 5)' out? Linux ACPI did clear the wake-on-RTC flag to me.
It's me from the duplicate bug 4896. I don't know what I'm doing. I made this change: 51c51 < outb_p(0x34, acpi_base + 5); --- > printf ("%u = %u\n", acpi_base + 5, inb_p(acpi_base + 5)); Run as root, I get: 2053 = 0
Checked more carefully about ACPI spec/ICH manual. If your chipset is ich, acpi_base + 5 is the ACPI PM1a_CNT block. it's not anything related with RTC. Writing '0x34' to the register means you want the system goes into sleep type 5, but ACPI shutdown mehtod will do the same thing later, it's strange writing the register helps you. Can you please provide the acpidmp out?
Created attachment 5514 [details] Output of acpidmp 1.2 on affected 865PE system The program from Bernhard Rosenkraenzer caused my PC to power off immediately when I ran it. The PC did not turn itself on at midnight, but it also did not POST when I turned it on in the morning. A press of the reset button brought it back. I am adding the output of acpidmp 1.2 as an attachment.
If you boot the machine with "acpi=off", and then power-off this system goes away?
Verified that booting with acpi=off and pressing the power button when shutdown gets to "Power down" avoids the problem. It is possible to work around with ACPI on by choosing reboot instead of halt and pressing the power button while on the POST screen. N.B., setting acpi=off appeared to sabotage the detection of two CPUs from hyperthreading. Not sure if this is a bug or expected behavior.
From your .config file follows you don't build either RTC or generic RTC drivers... Did you check if problem goes away then you build any?
Created attachment 6750 [details] Config for 2.6.13.4 Now running 2.6.13.4 with the attached config (CONFIG_RTC=y). Tested last night, and lo, the problem has gone away. In make menuconfig, CONFIG_RTC is Device Drivers-->Character devices-->Enhanced Real Time Clock Support. So internal kernel functionality required to perform a proper shutdown is buried under a character special device option. Probably this wants to be two options, one of which gets filed under ACPI with help text reading "Warning: Disabling this option may result in sleeplessness."
Closing this bug as INVALID. Please open bugs against documentation/configuration...
*** Bug 5694 has been marked as a duplicate of this bug. ***
Closing this bug as INVALID. Thanks.