Date: Sat, 03 Jun 2006 08:10:56 -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: <4481A680.1070608@root.org> In-Reply-To: <20060601102014.GA58143@comp.chem.msu.su> References: <20060528142039.GA80613@comp.chem.msu.su> <447B551F.8000904@root.org> <20060531073145.GA30802@comp.chem.msu.su> <447DB684.7060503@root.org> <20060601102014.GA58143@comp.chem.msu.su>
next in thread | previous in thread | raw e-mail | index | archive | help
Yar Tikhiy wrote: > On Wed, May 31, 2006 at 08:30:12AM -0700, Nate Lawson wrote: >> Yar Tikhiy wrote: >>> 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. > > Alas, I've failed to find the errata. My m/b is Epox EP-8K3AE, > based on VIA KT333: > > http://www.epox.nl/products/view.php?product_id=388 Not pointing fingers, but I've had a lot of C3 problems on VIA southbridges. I don't know if it's something we're doing wrong or they are. >> 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). > > FWIW, my system backs off from C3 to C2 even with no usb stuff in > the kernel. Here I mean the case of no apic in the kernel either, > when my system can survive setting cx_lowest to C3 without freeze. It prints the "c3 unusable, backing off" message? That means that the system idle thread looped too many times immediately instead of pausing when C3 was used. I'm not sure there's anything we can do about th
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4481A680.1070608>