Lee,
I'm having some trouble with latest VP patches on my P4 HT/SMP box. The
trouble is that since Q5 that I can't get my machine to boot reliably,
if at all. It goes almost all through the init scripts to drop dead on
the beach, so to speak. It just freezes completely somewhere before the
login prompts.
This only happens if the kernel is configured for SMP/SMT
(HyperThreading). The very same kernel configured and built for UP
boots and runs fine. As I said before this was introduced on the Q5
patch, and the same showstopper is present on latest R6. Only with Q3
I'm still happy, altought only with softirq-preempt=0 AND
hardirq-preempt=0.
The "offending" box is a SUSE 9.1 based one, P4 2.80C HT on a ASUS
P4P800 mobo, 1GB DDR.
I posted the above report to LKML and cc'ed you and Ingo. None of the
LKML testers are reporting this problem, it sounds very similar to the
problems others have had with SMP/HT but those were thought to all be
solved.
Thanks. Yes I was pretty excited with those reports too (I've been lurking
on LKML :), but I just seem to be unlucky. That's why I've been trying one
by one of the patches, from Q5 to R6 and tweaking the available options as
much as I know and time permitted.
OK, could just someone with a P4 HT/SMP box hand me their woring kernel
.config file for me to try? That could be a good starting point, if not a
plain baseline.
Has any version worked with softirq or hardirq preemption enabled? What
are the symptoms if you boot Q3 with either of the above enabled?
On this box in question, softirq and hardirq-preempt options had NEVER
lead to a stable SMP/HT system, ever since my first rehearsal with VP,
which I think was around O3. UP is quite different, it works and always
worked, as advertised :) FWIW, R6 is pumping hard on my laptop :)
Q3-SMP doesn't pass the KDE 3.3 startup splash if I set softirq=1 or
hardirq=1. The system just hangs. I still keep softirq-preempt=0 and
hardirq-preempt=0 as my Q3-SMP kernel bootloader parameters though.
Hope this gets cleared out. All I can do is offering my best efforts to
dig this out, provided someone give me some hunch ;)
Thanks again.
--
rncbc aka Rui Nuno Capela
rncbc(a)rncbc.org