Date: Tue, 13 Apr 2010 13:53:49 +0930 From: Malcolm Kay <malcolm.kay@internode.on.net> To: freebsd-questions@freebsd.org Subject: Re: ACPI? problem with release 8.0 Message-ID: <201004131353.49879.malcolm.kay@internode.on.net> In-Reply-To: <g2r6201873e1004120010ge93f4c58rbfce10b223f784e6@mail.gmail.com> References: <201004101722.43972.malcolm.kay@internode.on.net> <201004121531.33276.malcolm.kay@internode.on.net> <g2r6201873e1004120010ge93f4c58rbfce10b223f784e6@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 12 Apr 2010 04:40 pm, Adam Vande More wrote: > On Mon, Apr 12, 2010 at 1:01 AM, Malcolm Kay > > <malcolm.kay@internode.on.net>wrote: > > I desperately need to make some progress on this issue. > > > > Is it likely that the issue is real rather than hardware > > or disk corruption? Earlier releases are operating OK on the > > same machine. > > > > 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. > > > > 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 > > hw.acpi.disable_on_reboot: 0 > > hw.acpi.handle_reboot: 0 > > hw.acpi.reset_video: 0 > > hw.acpi.cpu.cx_lowest: C1 > > 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. > > > > My thought is to change this to > > machdep.idle: hlt > > or even > > machdep.idle: acpi > > > > Any comments or ideas please! > > > > Thank you for your attention. > > Is there anything in /var/log/messages which indicates the > cause? Can you monitor cpu temp? No clues in messages -- seems to just power down without any warning. I don't seem to have any thermal monitoring readily available except in the BIOS screens -- which seem to indicate everything is fine. But I guess this is not really indicative of what is happening with a running system. But the same machine has run earlier versions of FreeBSD staying up months at a time and only going down on power failures or on odd occassions I might want to look at BIOS settings or some such, so I feel fairly confident it is not a thermal issue. Hmm, I think there might be a BIOS setting to switch on health reporting which I expect would show up under sysctl. Thanks for the contribution. The more I think about it the more I believe the issue is connected with machdep.idle: amdc1e I am going to try changing this. Thanks and regards, Malcolm
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201004131353.49879.malcolm.kay>