ACPI? problem with release 8.0

Ian Smith smithi at nimnet.asn.au
Mon Apr 12 18:33:58 UTC 2010


In freebsd-questions Digest, Vol 306, Issue 1, Message: 18
On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay <malcolm.kay at internode.on.net> wrote:

 > I desperately need to make some progress on this issue.

Then I suggest taking it to freebsd-acpi@ without passing go .. maybe 
with a bit more data to hand, as outlined in the ACPI debugging section 
of the handbook.

 > Is it likely that the issue is real rather than hardware
 > or disk corruption? Earlier releases are operating OK on the same 
 > machine.

Sounds like a real issue, but I don't know the hardware.  Does it have 
the latest available BIOS update?  If not, that's step one.  Will it 
stay up long enough to get a verbose dmesg off it?  Do you have a 
verbose dmesg from an earlier working release for comparison?

 > I have now confirmed that:
 >  debug.acpi.disabled=acad button cpu lid thermal timer video
 > still leaves the system crashing and powering down when idle for 
 > a while. And the more extensive:
 >  debug.acpi.disabled=acad bus children button cmbat cpu ec isa
 >  lid pci pci_link sysresource thermal timer video
 > does the same.
 >
 > I don't really need power management but with acpi disabled the
 > disks are not visible to the system.

ACPI needs to work on modern hardware, no question.

 > Are there sysctl variables that can influence this behaviour?
 > Currently I believe we have:
 > 
 > 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: NONE
 > hw.acpi.sleep_delay: 1
 > hw.acpi.s4bios: 0
 > hw.acpi.verbose: 0

May help to set hw.acpi.verbose=1 in /boot/loader.conf while debugging;
especially useful after verbose boot for detail in dmesg and messages.

 > hw.acpi.disable_on_reboot: 0
 > hw.acpi.handle_reboot: 0
 > hw.acpi.reset_video: 0
 > hw.acpi.cpu.cx_lowest: C1

Is that with acpi.thermal disabled?  If so, showing hw.acpi and 
debug.acpi with everything enabled might provide more clues.
 
 > machdep.idle: amdc1e
 > machdep.idle_available: spin, amdc1e, hlt, acpi,
 > 
 > However on the earlier RELEASEs that work I note we do not have 
 > machdep.idle or machdep.idle_available. Instead I find:
 > machdep.cpu_idle_hlt: 1
 > machdep.hlt_cpus: 0
 > 
 > Although I've not been able to relate this directly to my problem 
 > from Googling it seems that there some issues with amdc1e under
 > BSD, Linux and perhaps Windows. But all the references seem to 
 > amd c1e are related to systems in 64 bit mode while I am running 
 > (or trying to run) i386 so I wonder why I have:
 >   machdep.idle: amdc1e
 > 
 > Maybe my problem is not acpi as such but this idle mode.

Could well be.  Someone on acpi@ will know about amdc1e, I don't, 
but any BIOS setting re C1E could be relevant to this.

 > My thought is to change this to
 >   machdep.idle: hlt
 > or even
 >   machdep.idle: acpi

Maybe try setting it to acpi first (without any disabled parts) and try?
Can't do any worse than crash the same?

 > Any comments or ideas please!
 > 
 > Thank you for your attention.
 > 
 > Malcolm Kay
 >
 > On Sat, 10 Apr 2010 05:22 pm, Malcolm Kay wrote:
 > > My machine had two SATA 300GB drives
 > > (WDC WD3200KS-00PFB0 21.00M21) one carrying FreeBSD
 > > RELEASE-6.3 and the other RELEASE-7.0 all of which worked OK.
 > >
 > > Recently added SATA 1TB (WDC WD10EADS-00P8B0 01.00A01) and
 > > installed RELEASE 8.0 thereon. When I boot to RELEASE 8.0
 > > I find after some time, few minutes to rather more minutes
 > > the system just powers down without warning or any obvious
 > > cause. It seems to mostly happen when the system is relatively
 > > quiet.

Adam's suggestion to check that esp. CPU temperature is within spec is 
worth checking; if you don't have any thermal zones in your ACPI I'd be 
surprised, and maybe concerned.  A finger on the heatsink is next best.

 > > Suspecting the ACPI I added:
 > >  hint.acpi.0.disabled=1
 > > to loader.conf.
 > > I then found RELEASE 8.0 would not boot -- or at least
 > > it was unable to mount root. I get a "mountroot>" prompt
 > > but this seemed not to accept anything I could think of,
 > > and "?" to list available targets yielded nothing. Rebooting
 > > and overriding this with option 2 (enable ACPI) in the boot
 > > menu took me back to a bootable but fragile system.
 > >
 > > Changing the loader.conf entry to:
 > >  debug.acpi.disabled=all
 > > had the same effect as the hint.acpi.0.disabled=1.

As it should.

 > > I then thought to be somewhat selective with
 > > debug.acpi.disabled and intended to try:
 > >  debug.acpi.disabled=acad button cpu lid thermal timer video
 > > only now as I write this I discover I actually entered:
 > >  debug.acpi.disabled=acadbutton cpu lid thermal timer video
 > >
 > > Now the RELEASE-8.0 booted but remained fragile.
 > >
 > > I've repaired this last entry and will proceed to try it.
 > > Meanwhile I feel I am fumbling about in the dark without
 > > sufficient (or any real) knowledge of the range of tasks
 > > performed by ACPI.
 > >
 > > Is my guess that I have an interaction problem between ACPI
 > > and RELEASE-8.0 a reasonable one? Where can I go from here?
 > >
 > > The system uses a Gigabyte GA-M55SLI-S4 mother board and the
 > > prcessor is AMD Athlon(tm) 64 X2 Dual Core Processor 5600+

The last para may hold the primary keys to the solution set ..

cheers, Ian


More information about the freebsd-questions mailing list