Regression in -current?

Richard Todd rmtodd at
Sun Jan 24 05:45:53 UTC 2010

Alexander Logvinov <avl at> writes:

> Hello!
> On 24.01.2010 10:43 Dima Panov wrote:
>> I see a strange regression since Friday's kernel, may be it's a kqueue-related.
>> While building ports, now I never see 100% load of cpu, and portupgrade -fa
>> takes ~7 hours for ~40 ports. Updating to current state (~3am VLAT) doesn't help.
>> KDB and WITNESS/INVARIANTS disablen in kernel config

>  I have a similar problem with r202904 amd64 kernel with interesting CPU
> statistic:
> top output:
> last pid:  1885;  load averages:  2.89,  1.56,  0.66    up 0+00:02:47
> 09:31:44
> 72 processes:  3 running, 69 sleeping
> _CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  0.0% idle_
> Mem: 120M Active, 39M Inact, 153M Wired, 6968K Cache, 65M Buf, 3565M Free
> Swap: 8192M Total, 8192M Free

Yeah, I saw the same thing on my core2duo system (running in amd64 mode,
dunno if that makes a difference.)  Caused the system to go *really* slow when
powerd started and decided that since CPU usage was 0.00% it could safely 
throttle the CPU all the way down midway thru all the rc.d/* stuff
executing. :-)  

As near as I can tell, the culprit is this rev (and the SVN #s you quote
are consistent with this being the case):

  SVN rev 202387 on 2010-01-15 16:04:30Z by attilio
  Handling all the three clocks (hardclock, softclock, profclock) with the
  LAPIC may lead to aliasing for softclock and profclock because frequencies
  are sized in order to fit mainly hardclock.
  atrtc used to take care of the softclock and profclock and it does still
  do, if the LAPIC can't handle the clocks properly.
  Revert the change when the LAPIC started taking charge of all three of
  them and let atrtc handle softclock and profclock if not explicitly
  requested. Such request can be made setting != 0 the new tunable
  machdep.lapic_allclocks or if the new device ATPIC is not present
  within the i386 kernel config (atrtc is linked to atpic presence).

As a check, my current post-rev-202387 kernel has working clock if I boot with


in loader.conf, and doesn't if I leave that out, so that pretty conclusively
points to those changes.

More information about the freebsd-current mailing list