Date: Tue, 13 Apr 2010 14:38:33 +0930 From: Malcolm Kay <malcolm.kay@internode.on.net> To: freebsd-questions@freebsd.org Subject: Re: ACPI? problem with release 8.0 Message-ID: <201004131438.33389.malcolm.kay@internode.on.net> In-Reply-To: <20100413030659.R52200@sola.nimnet.asn.au> References: <20100412114656.90F9210656E7@hub.freebsd.org> <20100413030659.R52200@sola.nimnet.asn.au>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 13 Apr 2010 04:03 am, Ian Smith wrote: > In freebsd-questions Digest, Vol 306, Issue 1, Message: 18 > > On Mon, 12 Apr 2010 15:31:33 +0930 Malcolm Kay <malcolm.kay@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. Yes, I have now realised this; but now somewhat reticent to move there now and be criticised for cross-posting > > > 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? Probably not; I have considered it. But the manufacturer's site warns not to upgrade unless you have identifyable problems (or something similar). And since earlier release work well I'm not anxious to open a new can of worms. If I become sufficiently desparate I'll try it. > > > 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. Looks as though it might be useful, but I'm starting to believe acpi itself may not be the problem > > > 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? No, this is run with acpi as default configured. Boot | login as root | sysctl -a > sysctl.dump | shutdown -p now (Get out before crash so that I don't get into trouble with fsck on reboot, yes it runs in the background but takes forever.) Rebooting in FreeBSD 7.0 I can now mount the 8.0 partitions and look at the dump in my own time -- and also prepare these emails. (Fsck also runs under 7.0 on the 8.0 partitions if 8.0 was allowed to crash.) > If so, showing hw.acpi > and debug.acpi with everything enabled might provide more > clues. OK > > > 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? I think this should be my next task. I have on hand another machine (not mine) running realease 8.0 but using an Intel Core i7 processor. This shows machdep.idle: acpi machdep.idle_available: spin, mwait, mwait_hlt, hlt, acpi, > > > 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. See my response to Adam. > > > > 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 guess so but wondered whether 'all' meant all the individually selectables but still leaving some essential parts of acpi active. > > > > 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 I'll report (for posterity) if changing machdep.idle: works. Thanks for your attention and thoughts, Malcolm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004131438.33389.malcolm.kay>