Date: Wed, 31 May 2006 11:31:45 +0400 From: Yar Tikhiy <yar@comp.chem.msu.su> To: Nate Lawson <nate@root.org> Cc: freebsd-current@freebsd.org Subject: Re: Freeze due to performance_cx_lowest=LOW Message-ID: <20060531073145.GA30802@comp.chem.msu.su> In-Reply-To: <447B551F.8000904@root.org> References: <20060528142039.GA80613@comp.chem.msu.su> <447B551F.8000904@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, May 29, 2006 at 01:10:07PM -0700, Nate Lawson wrote: > Yar Tikhiy wrote: > >Hi, > > > >A while ago I installed CURRENT on my new home PC and noticed that > >the system would hang hard at the boot time soon after setting > >cx_lowest to C3 according to the LOW setting in /etc/defaults/rc.conf. > >The last message on the console was each time: Mounting NFS file > >systems:. Setting performance_cx_lowest to HIGH made the problem > >go away. > > > >Now I've just tried again to return performance_cx_lowest to its > >modern default setting in a fresh CURRENT and found that the bug > >is still there. Is it due to my ACPI HW being broken? I'll be > >glad to show relevant debug output from my ACPI if told how to get > >it. Thanks. > > > > disable apic (hint.apic.0.disabled="1"). I isolated this a little while > ago to the change to enable LAPIC timer. However, there is currently no > easy way to disable the LAPIC timer with APIC enabled so you have to > disable APIC. jhb@ and I have been discussing how to do this better but > no easy answers apparently. Thank you for your reply! As I reported in <20060529085723.GA98288@comp.chem.msu.su>, this way of disabling apic didn't work in my case for some reason although I had triple checked the line in device.hints. The only mention of apic in the output from sysctl -a was there irrespective of the setting in device.hints: "hw.apic.enable_extint: 0". Perhaps my system has no apic at all? Nevertheless, removing "device apic" from the kernel changed things in a way, but C3 still was unusable and the system would go to C2 after detecting too many short sleeps by cpu0, which was described in the said message, too. -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060531073145.GA30802>