I was also considering the possibility of hardware error, but if it works 100% reliably without HT/SMP, but virtually crashes at high load with Apache, that would pretty much rule out hardware error, unless the CPU's HT is buggy (highly unlikely).
> Well, its not that the kernel does not detect the ht, it does and quite > fine (shows lots of processors in the box and all). > > The problem is that apache is crashing under high load with a segfault. > Now, as i understand it, this can be a faulty hardware problem (bad > memory=segfault) or an actual software problem. > > Im not shure, but im having this problem as well with an HT server and > have not been able to rule out the possibility of a faulty hardware > thing. Nonetheless, this can also be, for example, an ugly module in > woodies php4 which are particluarly edgy (xslt for example) under high > load due to them being in beta stage by the time woody froze. > > El mar, 16-12-2003 a las 20:07, Theodore Knab escribi�: > > I am using the 2.4.20 kernel with SMP support on a Hyper-threading > > Intel. I remember having problems getting it work with SMP support > > initially. > > > > I think the kernel has to be perfect. ;-) > > > > Do you have high memory support compiled in ? > > High memory support above 4GB might cause problems. > > > > If you do not have more than 2GB of RAM you should make sure that High > > memory support is not enabled. > > > > Also did you enable hyper-threading in BIOS ? > > Auto-detect modes might cause problems. > > http://publib-b.boulder.ibm.com/Redbooks.nsf/RedbookAbstracts/tips0175.html?Open > > > > My system: > > > > Linux tedsdesk 2.4.20 #22 SMP Mon Jul 21 14:53:07 EDT 2003 i686 > > GNU/Linux > > > > [EMAIL PROTECTED]:cat /proc/cpuinfo > > processor : 0 > > vendor_id : GenuineIntel > > cpu family : 15 > > model : 1 > > model name : Intel(R) Pentium(R) 4 CPU 1.50GHz > > stepping : 2 > > cpu MHz : 1495.172 > > cache size : 256 KB > > fdiv_bug : no > > hlt_bug : no > > f00f_bug : no > > coma_bug : no > > fpu : yes > > fpu_exception : yes > > cpuid level : 2 > > wp : yes > > flags : 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 ht tm > > bogomips : 2981.88 > > > > The ht in the flags section tells me hyper threading is being recognized. > > > > On 16/12/03 23:23 +0800, Jason Lim wrote: > > > Hi All... > > > > > > Do you guys know anything about a problem with Intel Hyper-threading (eg. > > > on the Intel 2.4Ghz HT-enabled processor) that would cause the load > > > average to jump to over 200? > > > > > > Here is the log line: > > > > > > Dec 16 22:48:17 be watchdog[250]: loadavg 203 101 40 is higher than the > > > given threshold 200 150 100! > > > > > > (then it reboots) > > > > > > This happened on the 2.4.22 kernel, and now I tried it with the 2.4.23 > > > kernel, and it has the same problem. > > > > > > When the kernel is compiled WITHOUT SMP support, the kernel works fine, > > > and it can have uptimes of months without any problem. But when SMP is > > > compiled in, and the HT processor is correctly identified (and top can see > > > CPU0 and CPU1), then it only takes about an hour or two of operation > > > before the load average jumps like that. Note that this is with Debian > > > woody/stable, and with a clean kernel.org kernel. > > > > > > Do you guys know anything about this, or have any ideas where I should > > > look? Is there something in Woody that isn't friendly with SMP or perhaps > > > Hyper-Threading processors? > > > > > > Thanks in advance. > > > > > > Sincerely, > > > Jas > > > > > > > > > -- > > > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > > > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > > > > > -- > > ------------------------------------------ > > Ted Knab > > Chester, MD 21619 > > ------------------------------------------ > > 35570707f6274702478656021626f6c6964796f6e602f66602478656 > > 02e6164796f6e60237471647560216e6460276c6f62616c60257e696 > > 4797e2a0 > > > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > >
