From owner-freebsd-questions@FreeBSD.ORG Fri Apr 16 18:03:42 2010 Return-Path: Delivered-To: freebsd-questions@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id 56A3B106564A for ; Fri, 16 Apr 2010 18:03:42 +0000 (UTC) (envelope-from smithi@nimnet.asn.au) Received: from sola.nimnet.asn.au (paqi.nimnet.asn.au [115.70.110.159]) by mx1.freebsd.org (Postfix) with ESMTP id 9B5968FC22 for ; Fri, 16 Apr 2010 18:03:41 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by sola.nimnet.asn.au (8.14.2/8.14.2) with ESMTP id o3GI3drO099925; Sat, 17 Apr 2010 04:03:39 +1000 (EST) (envelope-from smithi@nimnet.asn.au) Date: Sat, 17 Apr 2010 04:03:39 +1000 (EST) From: Ian Smith To: Malcolm Kay In-Reply-To: <201004161713.48344.malcolm.kay@internode.on.net> Message-ID: <20100417020817.W14495@sola.nimnet.asn.au> References: <20100412114656.90F9210656E7@hub.freebsd.org> <20100413030659.R52200@sola.nimnet.asn.au> <201004131438.33389.malcolm.kay@internode.on.net> <201004161713.48344.malcolm.kay@internode.on.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Cc: Adam Vande More , freebsd-questions@freebsd.org Subject: Re: ACPI? problem with release 8.0 | Perhaps solved? X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 16 Apr 2010 18:03:42 -0000 On Fri, 16 Apr 2010 17:13:48 +0930, Malcolm Kay wrote: > 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. Sounds promising .. > I tried setting machdep.idle to acpi and then to hlt without > success. But I now have set machdep.idle=spin. Wow, ok. I only have a vague idea of how these work, but having to change this definitely indicates a bug somewhere; whether your BIOS settings or ACPI implementation or kernel or what else, I've no idea. > 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: Don't presume too easily .. acpi.ko gets loaded really early, it's needed fired up even before scanning busses and initialising most devices. A verbose dmesg.boot should give some indication to anyone familiar with what should be. An acpidump may be useful too. Can you put files up anywhere to fetch? If not, you can mail me them, they're each too big to attach to -questions. The usual deal on acpi@ is to put up URL(s) to such files; I'd be happy to host them here. But you really should take this afresh to acpi@ .. they don't bite, the worst that can happen is they'll ignore you :) and with a new message with the concise story to date, I'd expect someone to take an interest; maybe just to say 'turn this off|on' or or 'that was fixed in -stable last month' or 'try this patch' or 'show us your [whatever]' .. > #!/bin/sh > echo "setting machdep.idle=spin" > /sbin/sysctl machdep.idle=spin > in /etc/rc.local Ok. dmesg.boot then will show what happens before that gets switched. If you enable console.log in syslog.conf that change will show up there after boot messages, maybe other useful stuff, but at least show dmesg. > 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. sysctl -ao is likely Way Too Much Information, though I suppose diffs between them might show something useful changing over time. 'sysctl hw dev acpi' is probably plenty to chew on. > 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. We're not talking about idle in the sense top shows you - this is about the kernel having nothing to do for perhaps hundreds of microseconds so entering a microsleep state. The old 386s just had the HLT instruction which had the CPU wait for an interrupt (to save power). These days there are multiple C-states with varying levels of power reduction with different latencies, ie times to wake up, usually managed by ACPI. I suspect 'spin' just loops awaiting an interrupt, staying busy? C1E is one such newer state. I know nothing about it, but that's what your system thought it should use the amdc1e cpufreq? driver for, so your problem definitely seems related to that. This clearly is within the ambit of the acpi@ list, and most of those folks seem rarely to have the sort of spare time needed to follow -questions. Also at least check the change log between your BIOS and the latest; if there's anything related to C states or similar, you should try it; they always say not to do it unless you need to - you might need to, and that might be all you need to do. > I'll try removing the cronjob. > > Thanks again for your attention, > Regards, > > Malcolm Kay Thanks for cc'ing me, I read -digests which can take half a day and make replying a bit tedious, not to mention breaking list threading. cheers, Ian [..]