The only change that I made to configuration, relative to when I configured the 2.6.35 kernel, was to disable the Big Kernel Lock (BKL) as this is supposed to be one of the significant improvements of this kernel.
I compiled the kernel with a full HD installation of Wary 5.0. After compiling, rebooted, and got this on the screen:
[Hardware Error]: No human readable MCE decoding support on this CPU type.
[Hardware Error]: Run the message through 'meclog --ascii' to decode.
Well, all previous kernels did not have that problem. The kernel log when booting my 184.108.40.206 kernel:
mce: CPU supports 4 MCE banks
...no error message.
A quick google showed that others have been getting this MCE error with the 2.6.36 kernel, for example:
Then it just hung. No error message, no kernel panic, kernel booting just stopped.
I pressed the Reset button on the PC, and this time it did boot. But, various mysterious things, like:
1. The USB drivers had loaded, but mouse simply did not work. No error messages, all messages look fine, including when Xorg starts, just that the mouse pointer doesn't move.
2. The core ALSA driver loaded, but the hardware-specific driver did not load. Again, no hint why not.
Oh dear, what have they done to the kernel!!!!
Comments:Posted on 7 Jan 2011, 7:52 by BarryK
Kernel MCE code
Well, it looks like this guy has rewritten the MCE (Machine Check Exception) handling code in the kernel:
Note, my PC has a very plain-vanilla Intel Celeron CPU. It is an ASUSTek motherboard, manufactured in 2006, with VIA support chips. This PC has been one of my workhorses, and has always worked fine with previous puppies.
As to the rest of the problems, I have no idea...
Posted on 7 Jan 2011, 8:13 by gcmartin
Recompile, I'm told
Barry, I'm certainly NO GURU on kernels BUT, my specialist tells me to tell you to recompile: leave in BKL and add LVM. Says you "should be good to go".
Hope this helps
Posted on 7 Jan 2011, 8:44 by ozsouth
Wary is so good with the 220.127.116.11 kernel. Seems kernels after 2.6.34x are all grunt & no safety.
Posted on 7 Jan 2011, 18:43 by Iguleder
For some reason 18.104.22.168 seems very good here, on a 2007 dual-core PC and my 2010 netbook.
I'm recompiling it for spup, it's patched with BFS and other goodies to make it uber-fast.
It seems modem drivers don't like this one ... and ndiswrapper needs to be patched to work with it.
I just bought www.iguleder.info, so if you want my kernel sources, they should be available in iguleder.info/sources once I'm done recompiling it :)
Posted on 7 Jan 2011, 19:07 by Iguleder
Barry, Woof does not support third-party repos: their package lists are not copied to /root/.packages.
Line 1026 in 3builddistro:
cp -f ../Packages-puppy-[0-9]-official rootfs-complete/root/.packages/
cp -f ../Packages-puppy-woof-official rootfs-complete/root/.packages/
Why don't you change to this?
cp -f ../Packages-*-official rootfs-complete/root/.packages/
You could also write a loop that copies just the lists for the repos available in PPM to save some space.
I wrote a browser installer that automatically finds the most appropriate PET according to the repos in DISTRO_PET_REPOS and it does not detect the packages under my repo because the package list is missing. That's how I found this so-called bug.
Posted on 8 Jan 2011, 7:39 by BarryK
Yeah, that package database copying code in Woof is messy, I need to rewrite it.
Patch for ndiswrapper? Do you know where I can get that patch?
Posted on 8 Jan 2011, 7:43 by Iguleder
I took a look at the Arch SVN repo. The patch didn't work for me, ndiswrapper 1.56 failed to compile so I tried the SVN and it worked.
Posted on 17 Apr 2011, 14:51 by Hagur
Take a Look on Last Question on
"I get "kernel hardware error no human readable mce decoding support on this cpu type"
they have a Patch for this bug.