On 7/25/2011 11:19 PM, Bob Proulx wrote: > Frank McCormick wrote: >> Bob Proulx wrote: >>> You early adopter you. I haven't rebooted my machine to the new >>> kernel today yet. :-) > > And since then I have rebooted. All good here. :-) But not a PAE > kernel here since I am using 64-bits.
I don't believe CONFIG_X86_PAE is the cause of Frank's problem. I believe it lies in two or more other config options. It just happens that he's using a pre-compiled canned Debian kernel that seems to have other features turned on that are causing his problem. See below. >>> I assume that you could select the previous kernel and boot okay? It >>> would be a good thing to double blind test. That would be a good A-B >>> comparison test. Because it is possible that the old kernel fails to >>> boot now. >> >> Yes, 2.6.38 and 2.6.39 have been booting for months now (and >> still boots) without a problem. It was only when PAE was introduced >> I started having the no-boot problem > > Sounds like a kernel bug. I think it justifies a bug report against > the kernel. But loss of HT would not be of extreme consequence in my > mind. Just a normal bug and not anything more severe. I don't believe so. I doubt Frank is the only person on the planet using a Northwood C series uni-core Pentium with HyperThreading hardware and CONFIG_X86_PAE enabled. He may be one of the few attempting to use a canned kernel with PAE, SMP, and multi-core enabled in his kernel, on a CPU that only supports 1 of the 3. >> That's what I thought but the more mysterious thing is why the PAE >> kernel boots fine with hyper-threading turned off. > > It is an important clue. But I don't know the answer. The answer is very simple. Intel engineered its HT circuitry in a way that standard SMP code will see two CPUs instead of one. The code that is enabled by CONFIG_X86_HT=y wasn't written until after these HT CPUs hit the market. Linux with standard SMP support worked fine on such uni-socket HT CPUs. But, for obvious reasons, the standard SMP scheduler did not perform well in this scenario. The CONFIG_X86_HT=y code does proper scheduling on HT CPUs. >>> Did you *really* have a dual-core? Or did you have a single-core >>> with HT enabled? I think probably the latter based upon your >>> description so far. >> >> 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 pbe pebs >> bts cid xtpr >> ... >> What do you make of that ?? Looks like a single-core to me ? As I mentioned it is a single core CPU, 8 years old at that. > The process definitely displays the "ht" flag and should therefore > support hyperthreading. Unless you see two sockets and two cpus then > I think you actually have a single core cpu with hyperthreading > enabled producing the second fake cpu. In which case losing > hyperthreading, while still not good, isn't a huge big deal. He does, as I mentioned above and in my addendum to his Debian bug report. I don't believe Frank is hitting a Linux kernel bug, or a Debian bug. I simply believe he's using the wrong canned kernel for his Northwood C Pentium IV. If this is the only Debian x86 kernel going forward, then Frank should simply forgo using HT, or roll his own kernel. For close to a decade I've been rolling my own kernels from vanilla source to avoid problems such as this, and for other reasons. Given that Frank didn't know he had an HT, but not dual core, CPU, and has probably never heard of CONFIG_X86_SMP or CONFIG_X86_HT, he's probably not a candidate for rolling his own kernels. :( -- Stan -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: http://lists.debian.org/4e2e7fa3.2050...@hardwarefreak.com
