Re: ULE/SCHED_SMP diff for 7.0

From: Rene Ladan <r.c.ladan_at_gmail.com>
Date: Thu, 19 Jul 2007 01:22:10 +0200
Attilio Rao schreef:
> Rene Ladan wrote:
>> Jeff Roberson schreef:
>>> On Wed, 18 Jul 2007, Rene Ladan wrote:
>>>
>>>> Jeff Roberson schreef:
>>>>> http://people.freebsd.org/~jeff/ule.diff
>>>>>
>>>>> This patch is scheduled for inclusion in 7.0.  I would like anyone who
>>>>> cares to run it to validate that it does not create any stability or
>>>>> performance regression over the existing ULE.  This patch replaces ULE
>>>>> with SCHED_SMP, which will now no longer exist as a seperate fork of
>>>>> ULE.
>>>> [..]
>>>>
>>>> I cvsupped this evening at 19:34 UTC.  The new ULE scheduler works fine
>>>> in single-user mode (it survives "make kernel"), but when I go to
>>>> multi-user mode I get a "sched_add: trying to run inhibited thread"
>>>> panic (2 vmcores lost due to fsck :( )
>>> Can you get me a backtrace?  You can enable KDB and DDB in your kernel
>>> along with INVARIANTS.  Just type 'tr' and record the function names
>>>
>>
>> I found a file #165060 in /var/lost+found .  kgdb didn't eat it, but
>> strings
>> could still extract the attached backtrace.  In case you want to
>> recompile
>> the kernel, it is compiled with -O1 -pipe -march=prescott
>> -fno-strict-aliasing
> 
> Are you using libkse?
> I think this problem is linked to other KSE locking issue we are
> currently experiencing and that I'm trying to fix (a little bit time
> constrained now).

I guess not since /usr/lib/libpthread.{a|so} -> /usr/lib/libthr.{a|so}
libhtr.so.3 actually lives in /lib, libkse.{a|so.3} only lives in /usr/lib

grep -ri kse /etc/ didn't find anything suspicious either.

Regards,
Rene
-- 
GPG fingerprint = E738 5471 D185 7013 0EE0  4FC8 3C1D 6F83 12E1 84F6 (subkeys.pgp.net)

"It won't fit on the line."
		-- me, 2001
Received on Wed Jul 18 2007 - 21:22:29 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:14 UTC