----- Original Message ----- 
From: Freminlins
To: Ted Mittelstaedt
Cc: freebsd-questions@freebsd.org
Sent: Thursday, February 15, 2007 11:14 AM
Subject: Re: serious performance problems with 6.2 Release


>Please sort out your formatting. It looks horrible.

funny how nobody else that quoted it seemed to have a problem.

>I've snipped your assumption that this is a hardware problem
> because it is misleading at this stage. It could well be a configuraiton
issue.

I'll quote then from the OP's post:

...This is a supermicro superserver 6022c dual 2.0 Xeon with 2GB RAM.
 These CPUs do support hyperthreading....
...If we disable hyperthreading in the bios and have it disabled in the OS
then FreeBSD sees one physical and one logical processor (from dmesg)
and only uses processor 0....

Disabling or enabling hyperthreading on a dual-Xeon BIOS has nothing to
do with the number of physical CPU's FreeBSD sees.  If there are 2 physical
CPU's on the motherboard and both CPU's are "enabled" (regardless of
whether hyperthreading is turned on or off in BIOS) then FreeBSD should
be seeing 2 physical CPUs.  The fact that it is not is a kernel bug that is
very related to hardware.

I don't know where your getting the impression that I said this was a
hardware
bug.  Clearly it is not a hardware bug if -other- operating systems are
seeing and
using both CPUs.  The hardware is operating as it was designed to do.  The
problem is that FreeBSD has a defect in that it cannot properly detect and
setup
for this hardware.  If you object to the use of the word "defect" then
substitute
"lack of code" instead.

I never siad that the OP's SuperMicro motherboard adhered to any industry
"standard" for SMP systems.  I myself have had mixed luck with SuperMicro
motherboards back in the early days of FreeBSD SMP, both uniprocessor
and SMP boards.

Unfortunately, these problems are usually only fixed by getting a sample of
the motherbord in the hands of a developer.  I assume this particular board
is
no longer in production, so most likely the OP won't ultimately be able to
get it fixed unless he parts with one of his machines - although a number of
folks
with hardware/software problems like this have been able to get developers
to fix them by putting their hardware online and giving the developer remote
access.

Ted

_______________________________________________
freebsd-questions@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Reply via email to