Next: choose a kernel

Lobster has reported the non-SMP kernel works, so unless he gives an update that it crashed a bit later, it looks like we will have to stay with the uniprocessor kernel for Puppy. The problem is, I can't just provide an alternative SMP kernel, as all the modules have to be recompiled also -- so I would have to provide two ISO live-CD files to cater for both groups.

For now I am tending toward staying with the 2.6.25.x series, but the 2.6.26.x sure looks interesting:
http://kernelnewbies.org/LinuxChanges

---

Comments

"interesting"
Username: prehistoric1
I certainly agree with your assessment of 2.6.26, with a twist. Is ASPM anything like ACPI? Do we want to be paravirtualized? Are we ready to tackle 802.11s? We could add to the "ancient Chinese curse" "May you live in interesting times." the modern "May you debug interesting kernels."

Mesh
Username: lobster
"Mesh is not yet an issue . . . but its adoption is inevitable http://www.open-mesh.com/

crash-test 2.6.26
Username: tempestuous
"It was a good pickup to identify SMP as the tipping point of compatibility with older processors. Thanks should go to Lobster for doing the testing which so few other forum members are prepared to do. 2.6.26.2 is now stable. Hint. Paravirtualization is also in 2.6.25. It can't hurt when it's not enabled. Since Lobster's Athlon XP 2000+ is now the unofficial Puppy testbed, maybe a crash-test release with 2.6.26.2?

"interesting"
Username: dogone
"Old Barry just can't keep his nose out of the treats jar. Well, thank god for that. Someone has to pull Puppy along by it's collar ;-). Seriously, and this is important, there is absolutely no reason there can't be two breeds of Puppy - an aggressive hunter and a friendly, steady lag dog. The two Pups might better suit two groups of users and two groups of developers. It won't be long before the New Puppy community can adopt, feed and care for Puppy the lap dog. So if Barry wants to do some hunting, I'm all for it. Few others in the community are as well prepared for this sort of advanced R&D. I believe Puppy Linux needs to move forward on both these fronts. Barry can work "out there", exploring the bleeding edge and preparing the way for community development. It's a hand and glove arrangement that could prove the best thing for both "parties". Practically speaking, it's time to push a managable and stable 4.1 out the door. This will be the New Puppy community's first bone. That done, I say we drop Barry's leash and let the guy hunt. He's sure to bring something back for dinner.

Edging onward
Username: lobster
""maybe a crash-test release with 2.6.26.2?" I am up for it. I rather like the sound of extended webcam support . . . I came into Linux to be on the far side of cutting edge 4.00 is stable, usable, solid enough for a while . . . No rush with 4.1 - so time to try different kernels . . . "a good pickup to identify SMP" - agreed

SMP is needed
Username: Divisionmd
"Hello, SMP is needed and is the future for all PC´s. Dual and Quad core CPUS is more than a standard today. How common is this "unstable" problem with SMP processors? how many PC´s has this problem? Is it worth not using SMP to make a few "rare" PC´s work? Best regards, Johan

SMP and P4HT
Username: lwill
"I found SMP does not play well with P4 hyperthreading chips. Not sure if it has anything in common with Lobster's problem. Specificaly when used with IVTV (tuner card) X-out frame buffer driver it will hard lock the machine between instantly and several minutes later. This driver is now part of the kernel and still happens. Since HT chips were sort of a stop-gap fad, there seem to be no iterest in fixing it. Question for Lobster - did you try running the problem kernel with the "nosmp"(?) boot option? This is what I have do to disable the smp functions in Fedora to use the for-mentioned driver. Maybe a different kernel is not needed, just more boot options?

nosmp option
Username: pizzasgood
"If that does work, I would vote for a Puppy which had SMP compiled in, but had the nosmp option added to isolinux.cfg by default. Then people who want SMP could just remove that option - if you boot from CD it would require burning a new CD, but for all other people it would only require modifying your menu.lst or syslinux.cfg files and rebooting. Otherwise, my opinion is to go with uniprocessor. SMP would be cool and multi-core machines are becoming the norm, but Puppy still runs great on just one core, and it's not like we claim to be a fancy gaming distro or anything.

Careful
Username: Downsouth
"Please, no V8 billycarts. 'Just Works' is the go. I've just now got 4.00 going to my satisfaction. (Using Icewm fixed the Xsane image distortion). The optional SMP/No SMP bootup sounds good.

SMP Install
Username: Viking Sailor
"pizzasgood, That is a very good idea. To expand on your idea, I would like to suggest that a SMP/noSMP option be added to the HD install script. Thus, if someone wants to switch to a SMP kernel on a high end box, it will just happen. Paul

SMP, SMT, MC
Username: tempestuous
"Following up on Iwill's comment that SMP does not play well with P4 hyperthreading chips; I see that Puppy4.1a5's kernel config has this - Symmetric multi-processing support - ENABLED SMT (Hyperthreading) scheduler support - DISABLED Multi-core scheduler support - ENABLED This might explain the problem, and it seems that if SMP and MC are enabled there's no reason why SMT shouldn't be, too. But in general I agree with pizzasgood, there's no point placing too much emphasis on these settings when the Puppy kernel is still a long way off being considered "performace". For that you need High Resolution Timer Support and full preemption enabled.

Works
Username: lobster
"Question for Lobster - did you try running the problem kernel with the "nosmp"(?) boot option? eh - did not know about it till you mentioned it . . . and it was suggested as a test in a later blog entry I have done that and it works. I am not sure if chip type can be tested for early on in boot and then appropriate fork taken - if so I am sure it will be done . . .

kernel 2.6.27-rc2 ??
Username: Bosco Bearbank
"I'm finding that with Fedora 2.6.27-0.xxx kernels, the ath5k module is working for me. I realize this is way too bleeding edge for Puppy 4.1, but was wondering if anyone else was able to switch over from the madwifi drivers

SMP options
Username: prehistoric1
"Lobster wasn't the only one who missed the nosmp option. I didn't know about it either. I am not at all surprised to see smp without hyperthreading support, and predict we will find more combinations of smp options which don't make sense on particular machines. There is a danger of a combinatorial explosion of options or kernels here. I didn't get the problems Lobster did and suspect it has to do with AMD designs. I am currently rebuilding a machine with an AMD two core processor which will be yet another testbed, redressing my Intel/AMD balance. Here's hoping Puppy will do something reasonable about power consumption/dissipation when it isn't using both processors. On current dual-core laptops, this could give Puppy a substantial advantage in terms of battery life. Yet another example of how decisions multiply with processors.

mesh
Username: Raffy
"Wireless mesh (even a simple implementation of one-to-many) is surely an attraction in kernel 2.6.26 and up. There is also read-only symlinking - I wonder to what extent this can be used for RAM-based files? I also have an Athlon XP2100 in the office, but that seemed to have died after I tested it with 4.1alpha and it hung. Will try to troubleshoot...

lethal bug?
Username: prehistoric1
"Raffy, that sounds ominous. My Athlon XP 2500 died a predictable death when struck by lightning. Anyone else had lethal bugs? On the subject of kernels and innovation, I want to clarify my position, 4.1 was originally described as experimental. I judge the experiment a success. This is the point where development goes to the beta team, who will resist calls for added features and hang on like bulldogs when they get their teeth in a bug. We seem to be lacking this "bulldog" team. Barry is in a class by himself as an alpha developer. It is a waste of talent to use him for a full development cycle. Most people in this business like to think of themselves as innovators. Few are. Critics outnumber them. It is much easier to hire beta developers than people who can move things through the alpha stage at anything approaching the speed Barry can. I can speculate on what drives Barry, these experiments are fun. If he were facing deadlines, and bound by contracts signed when nobody really knew what was going on, I doubt development would be fun. (The term "deathmarch" comes to mind, based on experience.) I am not trying to change Barry, just to preserve the results of a successful experiment before they get lost in the next experiment. To my lasting chagrin, I am no longer competent to take on such work. (I do what little I can.) Is there anyone out there who can and will?

Tags: puppy