I believe, that the R5.3 acpi driver is unable to turn power on after a certain amount of time passed by (just like 5.2-CURRENT-20040408). SuSE Linux was able to do so at least one year ago. I would prefer an acpi driver, that is able to order the power on procedure at the time specified in the BIOS... I am ready and able to test certain patches. Fix: ? How-To-Repeat: neo# sysctl dev.acpi dev.acpi.0.%desc: AMIINT VIA_K7 dev.acpi.0.%driver: acpi dev.acpi.0.%parent: nexus0 neo# sysctl hw.acpi hw.acpi.supported_sleep_state: S1 S4 S5 hw.acpi.power_button_state: S5 hw.acpi.sleep_button_state: S1 hw.acpi.lid_switch_state: NONE hw.acpi.standby_state: S1 hw.acpi.suspend_state: S3 hw.acpi.sleep_delay: 1 hw.acpi.s4bios: 0 hw.acpi.verbose: 0 hw.acpi.reset_video: 1 hw.acpi.cpu.throttle_max: 16 hw.acpi.cpu.throttle_state: 8 hw.acpi.cpu.cx_supported: C1/0 hw.acpi.cpu.cx_lowest: C1 hw.acpi.cpu.cx_usage: 100.00% neo# acpidump -d| head /* * Intel ACPI Component Architecture * AML Disassembler version 20040527 * * Disassembly of /tmp/acpidump.7VapkZ, Thu Nov 11 16:36:27 2004 */ DefinitionBlock ("DSDT.aml", "DSDT", 1, "VIA", "VIA_K7", 4096) { Name (APIC, 0x00) Method (\_PIC, 1, NotSerialized) [...]
Responsible Changed From-To: freebsd-bugs->freebsd-acpi Over to ACPI mailinglist
State Changed From-To: open->suspended Mark suspended awaiting patches.
State Changed From-To: suspended->closed The FreeBSD 5.x branch went EoL long ago. If this issue is still present in a supported branch, please submit a new PR. Thanks.
State Changed From-To: closed->open It seems that this issue is still present in more recent branches. That's why it should remain open. Thanks to Bruce Cran for pointing this out to me.
Can someone (Bruce?) explain to me in greater detail what this PR is about? I thought that the functionality of turning power on at certain time completely belonged to BIOS. How is acpi(4) driver expected to help? -- Andriy Gapon
on 06/09/2010 09:54 AW said the following: >> Can someone (Bruce?) explain to me in greater detail what this PR is about? >> > I believed that the box can boot at the specified time if Linux powers it down... > and that it cant, if FreeBSD does it... > >> I thought that the functionality of turning power on at certain time completely >> belonged to BIOS. How is acpi(4) driver expected to help? >> > i dont know... maybe the power down procedure offers some flag > (like "power down, but honor the BIOS settings about wake-up time" and > "power down and ignore BIOS settings about wake-up time")? > That LAN wake-up packet worked fine (WOL?) if FreeBSD powered the box down... > > Maybe i used a different/buggy BIOS when I found the problem? > Maybe Linux couldnt do it, too...? > > I dont use that box (mainboard: ECS K7VVM+ or so)/FreeBSD anymore, > but it should be easy for u to test it on contemporary hardware... Well, I am not aware of any OS assistance or control over this. If hardware and BIOS support this feature and it is properly configured, then power-on happens entirely in hardware and for OS it looks just like a normal boot. BTW, an interesting page: http://www.mythtv.org/wiki/ACPI_Wakeup It mentions that BIOS would disable wake up if hardware clock is modified later. We do that. -- Andriy Gapon
on 06/09/2010 12:45 Kostik Belousov said the following: > I think this is RTC wakeup event support. See, for instance, > 4.7.2.4 Real Time Clock Alarm in ACPI 4.0 spec. Well, possible. But, unfortunately, bug originator was vague enough. I am not sure what he mean by "power-on", I assumed going from S5 to S1, but maybe he meant wakeup e.g. from S3. -- Andriy Gapon
I guess this PR is about ACPI interface to the time-of-day clock that is provided on some systems. Perhaps we could implement this too (along with a userland utility for configuration). -- Andriy Gapon
For bugs matching the following criteria: Status: In Progress Changed: (is less than) 2014-06-01 Reset to default assignee and clear in-progress tags. Mail being skipped