Re: ULE status, invalid load, buildkernel times.

Jeff Roberson wrote:
> On Mon, 23 Jul 2007, Matt wrote:
> 
>> On 7/21/07, Jeff Roberson <jroberson_at_chesapeake.net> wrote:
>>> I have a patch available at:
>>>
>>> http://people.freebsd.org/~jeff/ulehtt.diff
>>>
>>> This resolves issues in the code that handles HTT enabled processors and
>>> also adds some ULE information to bootverbose on SMP systems.  Peter 
>>> Wemm
>>> has a seperate patch that fixes a bug where some amd64 cpus were still
>>> being misidentified as HTT.  Those of you with invalid loads either have
>>> Hyper-threading CPUs or misidentified amd cores.  You should expect
>>> slightly poorer performance as long as your cores are misidentified but
>>> the bad loads should be fixed.
>>>
>>> I also believe that the buildkernel/world times are now significantly
>>> improved.  If this is not the case for you please send a mail.  Any 
>>> other
>>> performance data is appreciated.
>>>
>>> Thanks,
>>> Jeff
>>> _______________________________________________
>>> freebsd-current_at_freebsd.org mailing list
>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>> To unsubscribe, send any mail to 
>>> "freebsd-current-unsubscribe_at_freebsd.org"
>>>
>>
>> -current system with sources update July 22 at approx. 3PM central
>> time with the ulehtt.diff patch applied experienced a panic this
>> afternoon while restarting a local Apache Tomcat server.  Backtrace
>> information is shown below.  Unclear to me whether or not the patch
>> and the panic are related.
> 
> I suspect that this is unrelated to my patch but I can't say for 
> certain. There have been some kse locking problems that Attilio has a 
> patch for.  I believe it went in today.  Hopefully he will comment.

This is exactly the same bug pav_at_ experienced on amd64 machines some 
weeks ago.
Basically, there is a race with ku_owner accesses which make it 
unconsistent in SMP / PREEMPTION systems.
I committed a fix for that, but since I broke buildkernel too with that 
commit I would suggest to wait until the fix for a correct kernel 
building won't be committed (it should be rather soon though) and than 
to CVSup again sources.

Thanks,
Attilio