Date: Sat, 20 Mar 2004 15:02:33 +0100 (CET) From: Martin Blapp <mb@imp.ch> To: Scott Long <scottl@freebsd.org> Cc: current@freebsd.org Subject: Re: Disable HTT on Serverworks GC-HE chipset Message-ID: <20040320142809.S45059@cvs.imp.ch> In-Reply-To: <405C3582.2070208@freebsd.org> References: <20040320031651.I45059@cvs.imp.ch> <405C3582.2070208@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hi Scott, I have tried without HTT because someone on #bsdcode told me to do so (ket_). Maybe you know who he is :-) Not all revisions of the chipset seem to be buggy so far, but rev. 0 is for sure. http://www.plasma-online.de/bilder/identify/chips/serverworks/ss3_ws_nb6536_p01.jpg http://www.plasma-online.de/bilder/identify/chips/serverworks/nb6536_p02.gif Serversboards with this chipset are: - Dell PowerEdge 2650 - IBM xSeries - Supermicro E7500 CNB20-HE (NB6536 - ServerSet III HE Northbridge 2.0) [0008] CPU - PCI bridge [0013] CPU - PCI bridge [0009] CPU - PCI/AGP bridge [0009.cc_0600] CPU - PCI bridge (default) [0009.cc_0604] CPU - AGP bridge (when used with NB6555AGP CIOB) > <ket_> mbr - i've had a LOT of people tell me the GC-HE w/HTT causes unknown > lockups, unreproducible errors, memory errors, and strange bus errors. on > multiple operating systems. > <ket_> GC-HE itself is acknowledged to be a buggy chipset, they're up to something like rev8 on the silicon. >> Have you determined that the instability is solely due to HTT >> in particular and not SMP in general? In other words, do you >> have multiple CPUs in the system, or is it just a single CPU >> with HTT? Also, do you have the latest BIOS for your motherboard? >> What stepping are your CPUs? The box has 2 CPU's. Without HTT it is rocking stable. And yes, the X-Series 345 have the latest Bios available. This dmesg is without HTT. CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3059.98-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf27 Stepping = 7 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, SSE2,SS,HTT,TM,PBE> real memory = 2147397632 (2047 MB) avail memory = 2100260864 (2002 MB) ACPI APIC Table: <IBM SERONYXP> FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 6 ioapic2 <Version 1.1> irqs 32-47 on motherboard ioapic1 <Version 1.1> irqs 16-31 on motherboard ioapic0 <Version 1.1> irqs 0-15 on motherboard Pentium Pro MTRR support enabled On a other box with HTT still enable it looks like: CPU: Intel(R) Xeon(TM) CPU 3.06GHz (3059.98-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf29 Stepping = 9 Features=0xbfebfbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE, SSE2,SS,HTT,TM,PBE> Hyperthreading: 2 logical CPUs real memory = 2147397632 (2047 MB) avail memory = 2100260864 (2002 MB) ACPI APIC Table: <IBM SERONYXP> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 6 cpu3 (AP): APIC ID: 7 ioapic2 <Version 1.1> irqs 32-47 on motherboard ioapic1 <Version 1.1> irqs 16-31 on motherboard ioapic0 <Version 1.1> irqs 0-15 on motherboard Pentium Pro MTRR support enabled You can see the chipset here: pciconf -lv hostb0@pci0:0:0: class=0x060000 card=0x00000000 chip=0x00141166 rev=0x33 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CNB20-HE Host Bridge' class = bridge subclass = HOST-PCI hostb1@pci0:0:1: class=0x060000 card=0x00000000 chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CNB20-HE Host Bridge' class = bridge subclass = HOST-PCI hostb2@pci0:0:2: class=0x060000 card=0x00000000 chip=0x00141166 rev=0x00 hdr=0x00 vendor = 'ServerWorks (Was: Reliance Computer Corp)' device = 'CNB20-HE Host Bridge' class = bridge subclass = HOST-PCI While using google I found the GC-LE chipsets seems to have problems with write-coalescing: > ServerWorks LE chipsets have problems with write-combining + Don't allow it and leave room for other chipsets to be tagged Have we a workaround for this too in our source ? Martin
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040320142809.S45059>