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


Posted on 7 Aug 2008, 20:42


Comments:

Posted on 7 Aug 2008, 21:48 by prehistoric1
"interesting"
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."


Posted on 7 Aug 2008, 21:56 by lobster
Mesh
Mesh is not yet an issue . . .
but its adoption is inevitable

http://www.open-mesh.com/



Posted on 7 Aug 2008, 21:57 by tempestuous
crash-test 2.6.26
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?


Posted on 7 Aug 2008, 23:19 by dogone
"interesting"
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.



Posted on 7 Aug 2008, 24:30 by lobster
Edging onward
"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


Posted on 7 Aug 2008, 24:41 by Divisionmd
SMP is needed
Hello,

SMP is needed and is the future for all PCs.

Dual and Quad core CPUS is more than a standard today.

How common is this "unstable" problem with SMP processors? how many PCs has this problem?

Is it worth not using SMP to make a few "rare" PCs work?

Best regards,
Johan


Posted on 8 Aug 2008, 5:24 by lwill
SMP and P4HT
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?


Posted on 8 Aug 2008, 6:29 by pizzasgood
nosmp option
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.


Posted on 8 Aug 2008, 7:37 by Downsouth
Careful
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.



Posted on 8 Aug 2008, 8:17 by Viking Sailor
SMP Install
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



Posted on 8 Aug 2008, 8:20 by tempestuous
SMP, SMT, MC
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.


Posted on 8 Aug 2008, 13:35 by lobster
Works
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 . . .



Posted on 8 Aug 2008, 20:03 by Bosco Bearbank
kernel 2.6.27-rc2 ??
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




Posted on 8 Aug 2008, 23:50 by prehistoric1
SMP options
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.


Posted on 8 Aug 2008, 24:02 by Raffy
mesh
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...



Posted on 9 Aug 2008, 20:46 by prehistoric1
lethal bug?
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?


Posted on 9 Aug 2008, 21:48 by linuxcbon
hobby
prehistoric1 puppy is a hobby, live with it.