Soren Schmidt wrote:
> It seems Soren Schmidt wrote:
> > > I actually used this:
> > > 
> > > CFLAGS          ?= -O -pipe -mcpu=i686 -march=i686
> > > COPTFLAGS       ?= -O -pipe -mcpu=i686 -march=i686
> > >
> > > All the diffs in sys/ on the box I built this kernel on are at
> > >  One possibly notabl
> > > patch I had forgotten about is the fix to forward_signal() to lock with
> > > sched_lock.  I've just committed that though.
> > 
> > OK, I have installed those patches and will try out a kernel build on
> > that asap....
> Hmm, now we are getting somewhere, it ran through a make world with
> that patch installed!
> I'll test some more, maybe you should get it all committed it seems to
> make a hell of a difference....

Hmm.  with the mp_machdep.c fix committed, that leaves the only other
significant difference being the re-enable of HLT when a cpu goes idle
in i386/i386/machdep.c.

The refcount.[ch] stuff is not relevant to this problem.

The kern/subr_prf.c change doesn't *appear* to be a likely candidate,
unless you are printing lots of console messages during the buildworld..

The kern/vfs_aio.c are not relevant as VFS_AIO is not in GENERIC.

The rest are comments, mtx_assert()'s or DDB activation related.

Soren, can you retest a buildworld with the currently committed kernel
with no other changes?  Let us see if the forward_signal() stuff is the
culprit, and if not, try adding just the i386/i386/machdep.c patch to HLT
the idle CPU.  (if *that* makes a difference then we have got trouble!)

"All of this is for nothing if we don't go to the stars" - JMS/B5

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to