Date: Fri, 16 Apr 2010 17:13:48 +0930 From: Malcolm Kay <malcolm.kay@internode.on.net> To: freebsd-questions@freebsd.org Cc: Adam Vande More <amvandemore@gmail.com>, Ian Smith <smithi@nimnet.asn.au> Subject: Re: ACPI? problem with release 8.0 | Perhaps solved? Message-ID: <201004161713.48344.malcolm.kay@internode.on.net> In-Reply-To: <201004131438.33389.malcolm.kay@internode.on.net> References: <20100412114656.90F9210656E7@hub.freebsd.org> <20100413030659.R52200@sola.nimnet.asn.au> <201004131438.33389.malcolm.kay@internode.on.net>
next in thread | previous in thread | raw e-mail | index | archive | help
My RELEASE-8.0 has now been up for about 2hr, not long enough to be sure the difficulty is circumvented, but long enough to look promising. Previously RELEASE-8.0 has not stayed up more than about 4min. I tried setting machdep.idle to acpi and then to hlt without success. But I now have set machdep.idle=spin. Discovered there can be some problem in trying to set this too early -- in particular in loader.conf -- presumably because acpi.ko is not yet loaded. I ended up making sure everything was ready by putting: #!/bin/sh echo "setting machdep.idle=spin" /sbin/sysctl machdep.idle=spin in /etc/rc.local To check what is happening I've created /usr/local/bin/sysctldump.sh as: #!/bin/sh [ -f /tmp/sysctl.dump.4 ] && mv -f /tmp/sysctl.dump.4 /tmp/sysctl.dump.5 [ -f /tmp/sysctl.dump.3 ] && mv -f /tmp/sysctl.dump.3 /tmp/sysctl.dump.4 [ -f /tmp/sysctl.dump.2 ] && mv -f /tmp/sysctl.dump.2 /tmp/sysctl.dump.3 [ -f /tmp/sysctl.dump.1 ] && mv -f /tmp/sysctl.dump.1 /tmp/sysctl.dump.2 [ -f /tmp/sysctl.dump ] && mv -f /tmp/sysctl.dump /tmp/sysctl.dump.1 sysctl -ao > /tmp/sysctl.dump and adding: #sysctl dump 1-59/2 * * * * root /usr/local/bin/sysctldump.sh to /etc/crontab. I feel somewhat concerned that this cronjob may be sufficiently frequent to prevent the system looking for the idle state and thus circumventing the problem in same other way. So I'm not yet convinced that I have a real solution. I'll try removing the cronjob. Thanks again for your attention, Regards, Malcolm Kay On Tue, 13 Apr 2010 02:38 pm, Malcolm Kay wrote: > 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 > _______________________________________________ > freebsd-questions@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-questions > To unsubscribe, send any mail to > "freebsd-questions-unsubscribe@freebsd.org"
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004161713.48344.malcolm.kay>