Bug 97468
| Summary: | [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off) | ||
|---|---|---|---|
| Product: | Base System | Reporter: | Martin Birgmeier <martin> |
| Component: | i386 | Assignee: | freebsd-acpi (Nobody) <acpi> |
| Status: | Closed FIXED | ||
| Severity: | Affects Only Me | ||
| Priority: | Normal | ||
| Version: | 6.1-RELEASE | ||
| Hardware: | Any | ||
| OS: | Any | ||
|
Description
Martin Birgmeier
2006-05-18 20:10:15 UTC
I have one of these. It powers off just nicely using halt -p and reboot -p. It will hang or just reboot on power off when the BIOS alarm setting is set in the power settings. This is not specific to just this board, I have three other machines with ASUS motherboards (CUSL2, CUSL2-C, and P3B-F), which behave the same way. (Please note that the CUSL2, CUSL2-C, and P3B-F are Pentium III's while the A7V is an AMD Athalon). An IBM P4 system at work does not exhibit this problem when the alarm setting is set in the BIOS. I have another PII machine, which I cannot recall what it is as I need to disassemble it to see which motherboard it has (it's not an ASUS but has an Award BIOS), that exhibits the same problem when the alarm setting is set in the BIOS. Turning off that setting allows FreeBSD to power down the system. Unfortunately I need to power down the systems at a certain time of day through cron and power them back up at another time of day, but that should be in another PR. Check your BIOS settings. I bet that the alarm setting is set in your BIOS. -- Cheers, Cy Schubert <Cy.Schubert@komquats.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: http://www.FreeBSD.org e**(i*pi)+1=0 O.k., this makes me unhappy enough to post a follow-up after much fiddling with ACPI debugging flags, and not finding a clue... Notes: - The proposal by Cy Schubert does not work, as I've never set an alarm in the bios. I checked it multiple times, though, just to make sure. - Setting debug.acpi.max_threads=1 at the loader prompt does not help. - I fiddled with lots of debug.acpi.layer and debug.acpi.level settings, output for interesting combinations follows below. The method used was to boot with empty flags, and then set/reset them for one second via sysctl. I had to do this because some ACPI stuff is continuously running, totally clobbering my screen. Please respond by following up to this defect entry (http://www.freebsd.org/cgi/query-pr.cgi?pr=97468), the email address given is invalid. Regards, Martin ACPI_HARDWARE/ACPI_LV_VERBOSITY3: -- same as -- ACPI_ALL_COMPONENTS ACPI_ALL_DRVERS/ACPI_LV_VERBOSITY3: ======================================================= This is the continuously running stuff. Debugging output was turned on/off via sysctl. I located the loop and manually copied one sequence. hwregs-0359 [000c] [41] AcpiGetRegister : ----Entry hwregs-0590 [000c] [42] HwRegisterRead : ----Entry hwregs-0885 [000c] [42] HwLowLevelRead : Read: 411 width 16 from 0 e400 (SystemIO) hwregs-0680 [000c] [42] HwRegisterRead : ----Exit- AE_OK hwregs-0399 [000c] [41] AcpiGetRegister : Read value 1 regiser 1 hwregs-0402 [000c] [41] AcpiGetRegister : ----Exit- AE_OK hwregs-0432 [000c] [41] AcpiSetRegister : ----Entry 00000001 hwregs-0590 [000c] [42] HwRegisterRead : ----Entry hwregs-0885 [000c] [42] HwLowLevelRead : Read: 411 width 16 from 0 e400 (SystemIO) hwregs-0680 [000c] [42] HwRegisterRead : ----Exit- AE_OK hwregs-0708 [000c] [42] HwRegisterWrite : ----Entry hwregs-0966 [000c] [42] HwLowLevelWrite : Wrote: 10 width 16 to 0 e400 (SystemIO) hwregs-0805 [000c] [42] HwRegisterWrite : ----Exit- AE_OK hwregs-0559 [000c] [41] AcpiSetRegister : Set bits: 10 actual 0 register 1 hwregs-0560 [000c] [41] AcpiSetRegister : ----Exit- AE_OK I'd be happy if someone could tell me why this stuff is continuously running, and where it comes from. Interestingly, it's all just reads and writes, with no higher level acpi functions in between. ACPI_BUTTON ACPI_HARDWARE ACPI_POWER/ACPI_LV_FUNCTIONS: ======================================================= Here I just enabled the above setting (without the sleep 1 and disabling), then pressed the power button, waited until the screen stabilized, and copied the last 24 lines. The first few lines match the previous case, repeating forever until the "done", except for the missing ACPI_LV_IO (LowLevel) functions. hwregs-0590 [42] HwRegisterRead : ----Entry hwregs-0680 [42] HwRegisterRead : ----Exit- AE_OK hwregs-0402 [41] AcpiGetRegister : ----Exit- AE_OK hwregs-0432 [41] AcpiSetRegister : ----Entry 00000001 hwregs-0590 [42] HwRegisterRead : ----Entry hwregs-0680 [42] HwRegisterRead : ----Exit- AE_OK hwregs-0708 [42] HwRegisterWrite : ----Entry hwregs-0805 [42] HwRegisterWrite : ----Exit- AE_OK hwregs-0650 [41] AcpiSetRegister : ----Exit- AE_OK done All buffers synced. Uptime: 1m46s POWERRES-0510 [43] acpi_pwr_wake_enable : ----Entry POWERRES-0748 [44] acpi_pwr_find_consumer: ----Entry POWERRES-0756 [44] acpi_pwr_find_consumer: ----Exit- 0 POWERRES-0246 [44] acpi_pwr_register_cons: ----Entry POWERRES-0748 [45] acpi_pwr_find_consumer: ----Entry POWERRES-0756 [45] acpi_pwr_find_consumer: ----Exit- 0 POWERRES-0266 [44] acpi_pwr_register_cons: ----Exit- AE_OK POWERRES-0748 [44] acpi_pwr_find_consumer: ----Entry POWERRES-0756 [44] acpi_pwr_find_consumer: ----Exit- 0xc56bd8e0 hwsleep-0243 [42] AcpiEnterSleepStatePre: ----Entry hwregs-0222 [43] AcpiGetSleepTypeData : ----Entry hwregs-0300 [43] AcpiGetSleepTypeData : ----Exit- AE_OK ACPI_BUTTON ACPI_HARDWARE ACPI_POWER ACPI_NAMESPACE ACPI_PARSER/ ACPI_LV_FUNCTIONS: ================================================================ Again, I just enabled, and then pressed the power button. Now, as described in the intro above, something continues to rush by continuously, and I can barely make out a lot of namespace and parser functions (and I believe no others - but cannot be sure). So it seems that for whatever reason, the system enters some loop after the AcpiEnterSleepStatePrep. One more thing: The machine can successfully be powered down via ACPI under both Win98 and Suse Linux 10.0. Regards, Martin Responsible Changed From-To: freebsd-i386->freebsd-acpi ACPI issue (spotted by Astrodoy on IRC) Remko Lodder wrote: > Synopsis: [acpi] ACPI on ASUS A7V hangs on shutdown -p (power off) > > Responsible-Changed-From-To: freebsd-i386->freebsd-acpi > Responsible-Changed-By: remko > Responsible-Changed-When: Sun Jan 7 11:13:35 UTC 2007 > Responsible-Changed-Why: > ACPI issue (spotted by Astrodoy on IRC) > > http://www.freebsd.org/cgi/query-pr.cgi?pr=97468 I ment Astrodog ofcourse :) -- Kind regards, Remko Lodder ** remko@elvandar.org FreeBSD ** remko@FreeBSD.org /* Quis custodiet ipsos custodes */ njl 2007-06-24 20:35:59 UTC
FreeBSD src repository
Modified files:
sys/modules/i2c/controllers/alpm Makefile
sys/modules/i2c/controllers/viapm Makefile
Log:
The viapm module build had what appear to be some debugging CFLAGS left
around to force the IO port to a fixed address. They were only turned
on in the module build and were present since the original import. This
breaks soft power-off on the Asus A7V since it reprograms the SMBus base
address to a different one than the BIOS expects. A similar issue was
found in the alpm(4) module build.
PR: kern/113986, i386/97468
MFC after: 3 days
Approved by: re
Revision Changes Path
1.2 +0 -1 src/sys/modules/i2c/controllers/alpm/Makefile
1.3 +0 -1 src/sys/modules/i2c/controllers/viapm/Makefile
_______________________________________________
cvs-all@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/cvs-all
To unsubscribe, send any mail to "cvs-all-unsubscribe@freebsd.org"
State Changed From-To: open->closed Fix committed, thank you very much for your debugging effort. |
