Date: Wed, 31 May 2006 08:30:12 -0700 From: Nate Lawson <nate@root.org> To: Yar Tikhiy <yar@comp.chem.msu.su> Cc: freebsd-current@freebsd.org Subject: Re: Freeze due to performance_cx_lowest=LOW Message-ID: <447DB684.7060503@root.org> In-Reply-To: <20060531073145.GA30802@comp.chem.msu.su> References: <20060528142039.GA80613@comp.chem.msu.su> <447B551F.8000904@root.org> <20060531073145.GA30802@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote: > 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. > It appears that may be a different problem. On systems with the lapic issue, it seems both C2/C3 are unusable. However, it seems C3 is unusable on some other systems for a different reason. If you could look into the datasheet errata for your chipset, you might find something about this. I already have specially called out a few chipsets in acpi_cpu.c to not use C3. Oh and do you have usb compiled in? C3 won't be used on systems that have usb compiled in due to the constant bus master activity when usb polls ports. Anyone interested in helping with this? It basically involves adding a timeout to usb to run every 1 second or so that pokes usb to check for new devices and then disables it again. (global suspend function I think). -- Nate
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?447DB684.7060503>