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