Date: Fri, 16 Feb 2007 01:16:08 -0800 From: "Ted Mittelstaedt" <tedm@toybox.placo.com> To: "Freminlins" <freminlins@gmail.com> Cc: freebsd-questions@freebsd.org Subject: Re: serious performance problems with 6.2 Release Message-ID: <002601c751ab$18b39bf0$3c01a8c0@coolf89ea26645> References: <45D3A4D7.9000504@frii.com> <00ff01c7510e$7452e490$3c01a8c0@coolf89ea26645> <eeef1a4c0702150849q76fa6a4cke5e88477189be093@mail.gmail.com> <012a01c75128$4d3a5a40$3c01a8c0@coolf89ea26645> <eeef1a4c0702151114n57d822b6yf31a52355d35e3e2@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
----- 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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?002601c751ab$18b39bf0$3c01a8c0>