Date: Mon, 5 Jun 2006 14:23:01 +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: <20060605102301.GA21102@comp.chem.msu.su> In-Reply-To: <4481A680.1070608@root.org> 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> <4481A680.1070608@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Sat, Jun 03, 2006 at 08:10:56AM -0700, Nate Lawson wrote: > 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. <rant> It's rather probable that there are quirks and bugs in the VIA chip on my m/b. From observing the recent development of our drivers as complex as ACPI or ATA I've got an impression that modern chip manufacturers rarely want to, or have enough time to, pay attention to the quality of their silicon designs, prefering to work around h/w issues in their Windows drivers. Supporting such h/w in a free OS may be a real hell, as the manufacturers release a new chip with a different bug set each quarter for their marketing people to have something to brag of. I've just had a couple of funny experiences on the ATA side, one of them with VIA, too. </rant> The point of my original posting was mostly to see if other folks experienced similar problems. Now I seem to see the complexity of the issue. > >>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 If it could clarify anything, the message from the kernel read, "cpu0: too many short sleeps, backing off to C2". Nate, thank you for your efforts to tame the ACPI beast :-) -- Yar
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060605102301.GA21102>