Does anyone know of a repository (to add to Smart) which contains the latest stable kernel, 2.6.17? Currently, I am running kernel 2.6.16.21-0.13-default. Thanks, Rick -- Rick's Law: What cannot be imagined will be accomplished by a fool. PGP Key Id: 9E1125E0
On 9/11/06, Rick Friedman <rickfriedman@verizon.net> wrote:
Does anyone know of a repository (to add to Smart) which contains the latest stable kernel, 2.6.17? Currently, I am running kernel 2.6.16.21-0.13-default.
Thanks, Rick
Rick, I think they have already moved to the 2.6.18-rc series. See http://software.opensuse.org/download/Kernel/SUSE_Linux_10.1/i586/ A recent thread said you have to get a new version of udev userspace I believe if you want to run a .18 kernel. I'm not sure if that applies to everyone, or only udev users. ie. Are we all udev users now? Or is udev a feature like lvm, md, etc. that users have to enable. HTH Greg -- Greg Freemyer The Norcross Group Forensics for the 21st Century
Greg Freemyer wrote:
On 9/11/06, Rick Friedman <rickfriedman@verizon.net> wrote:
Does anyone know of a repository (to add to Smart) which contains the latest stable kernel, 2.6.17? Currently, I am running kernel 2.6.16.21-0.13-default.
Thanks, Rick
Rick,
I think they have already moved to the 2.6.18-rc series.
See http://software.opensuse.org/download/Kernel/SUSE_Linux_10.1/i586/
A recent thread said you have to get a new version of udev userspace I believe if you want to run a .18 kernel.
I'm not sure if that applies to everyone, or only udev users. ie. Are we all udev users now? Or is udev a feature like lvm, md, etc. that users have to enable.
HTH Greg I don't see any kernel-smp on that location, are they available somewhere else, or is it indeed a SMP enabled kernel ?
//Sylvester
* Sylvester Lykkehus <zly@solidonline.dk> [09-11-06 15:47]:
I don't see any kernel-smp on that location, are they available somewhere else, or is it indeed a SMP enabled kernel ?
*all* kernels are now smp enabled, at least 2.6.18*. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
On Mon, 2006-09-11 at 16:00 -0400, Patrick Shanahan wrote:
* Sylvester Lykkehus <zly@solidonline.dk> [09-11-06 15:47]:
I don't see any kernel-smp on that location, are they available somewhere else, or is it indeed a SMP enabled kernel ?
*all* kernels are now smp enabled, at least 2.6.18*.
I heard rumors a bit back that the kernel guys finally found the reason the kernel needed special compiling for smp vs. non-smp. Some dumb programming error that had been in the kernel for eons. The correction resulted in one kernel working on both smp and non-smp processors. So, maybe the rumor was true? -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
* Sylvester Lykkehus <zly@solidonline.dk> [09-11-06 15:47]:
I don't see any kernel-smp on that location, are they available somewhere else, or is it indeed a SMP enabled kernel ?
*all* kernels are now smp enabled, at least 2.6.18*.
I heard rumors a bit back that the kernel guys finally found the reason the kernel needed special compiling for smp vs. non-smp. Some dumb programming error that had been in the kernel for eons. The correction resulted in one kernel working on both smp and non-smp processors. So, maybe the rumor was true?
I'd rather say this: http://lwn.net/Articles/164121/ Jan Engelhardt --
On Tuesday 12 September 2006 00:01, Jan Engelhardt wrote:
* Sylvester Lykkehus <zly@solidonline.dk> [09-11-06 15:47]:
I don't see any kernel-smp on that location, are they available somewhere else, or is it indeed a SMP enabled kernel ?
*all* kernels are now smp enabled, at least 2.6.18*.
I heard rumors a bit back that the kernel guys finally found the reason the kernel needed special compiling for smp vs. non-smp. Some dumb programming error that had been in the kernel for eons. The correction resulted in one kernel working on both smp and non-smp processors. So, maybe the rumor was true?
I'd rather say this: http://lwn.net/Articles/164121/
Quoting:.... A more interesting - and more controversial - feature of this patch is that, when the kernel is converted between the SMP and uniprocessor mode, the overwritten instructions are remembered. At some point the the future, then, the alternatives code can reverse the change, switching the kernel back to the full SMP implementation. The code is then run whenever a CPU hotplug event happens, optimizing the kernel for the system's new configuration. A system can be initially booted with a single processor, and the alternatives code will edit out all of the SMP-related instructions. If another processor is added later on, the kernel will be automatically converted back into a fully SMP-capable mode. ---end-quote. I distinctly remember playing with BeOS on a dual processor system. They had an option to shut down (more likely simply fail to use) either processor. There was a button you could click and watch your load jump to the remaining processor and the clicked one fall to zero. I never found a valid use for this but it was cool to watch. -- _____________________________________ John Andersen
I distinctly remember playing with BeOS on a dual processor system. They had an option to shut down (more likely simply fail to use) either processor. There was a button you could click and watch your load jump to the remaining processor and the clicked one fall to zero.
I never found a valid use for this but it was cool to watch.
man taskset You can already do this today, even without shutting down a CPU on the kernel level. Jan Engelhardt --
On Tuesday 12 September 2006 00:19, Jan Engelhardt wrote:
I distinctly remember playing with BeOS on a dual processor system. They had an option to shut down (more likely simply fail to use) either processor. There was a button you could click and watch your load jump to the remaining processor and the clicked one fall to zero.
I never found a valid use for this but it was cool to watch.
man taskset
You can already do this today, even without shutting down a CPU on the kernel level.
I'm sure that's what they used in BeOS, but they had a utility that did this for every process. You would think that there would be a few that did not like their affinity changed for no good reason, but nothing seemed to complain. I remember the days when one had to set affinity or things would crash. -- _____________________________________ John Andersen
On Tue, 2006-09-12 at 10:19 +0200, Jan Engelhardt wrote:
I distinctly remember playing with BeOS on a dual processor system. They had an option to shut down (more likely simply fail to use) either processor. There was a button you could click and watch your load jump to the remaining processor and the clicked one fall to zero.
I never found a valid use for this but it was cool to watch.
man taskset
I learn something new every day. I know how to do this in C code. Never knew there was a command line tool. What I am trying to determine is, when I leave the kernel to its own devices, is it running my 2-thread app so that one thread runs in one core and the other in another. Both threads do lots of basically independent work on shared buffers. Is there a tool to see which cpu a thread is running in? I can't seem to see the threads in ps or top. Some brilliant tool is surely just waiting to tell all. Right? -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
On Monday 11 September 2006 23:54, Roger Oberholtzer wrote:
I heard rumors a bit back that the kernel guys finally found the reason the kernel needed special compiling for smp vs. non-smp. Some dumb programming error that had been in the kernel for eons. The correction resulted in one kernel working on both smp and non-smp processors. So, maybe the rumor was true?
I spoze its possible, but effectively using two processors (or cores) requires a lot more than compile option. Seems more likely, that with so many machines able to at least pretend to have two processors (hyper-threading), and since the penalty for running smp with only one processor actually working is small, it might just be that they decided the single processor kernel was no longer warranted. But I speculate, I don't know. -- _____________________________________ John Andersen
On Tue, 2006-09-12 at 00:04 -0800, John Andersen wrote:
On Monday 11 September 2006 23:54, Roger Oberholtzer wrote:
I heard rumors a bit back that the kernel guys finally found the reason the kernel needed special compiling for smp vs. non-smp. Some dumb programming error that had been in the kernel for eons. The correction resulted in one kernel working on both smp and non-smp processors. So, maybe the rumor was true?
I spoze its possible, but effectively using two processors (or cores) requires a lot more than compile option. Seems more likely, that with so many machines able to at least pretend to have two processors (hyper-threading), and since the penalty for running smp with only one processor actually working is small, it might just be that they decided the single processor kernel was no longer warranted.
Except that in earlier releases of the kernel, the SMP version often did not run on a non-SMP machine. Not a matter of different performance. More a matter of it just not running. There have been code improvements in the kernel of late that are allowing us to skip having two compiled versions. At least this is what I have been hearing. I don't run such an exotic thing yet. -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
On Tuesday 12 September 2006 00:16, Roger Oberholtzer wrote:
Except that in earlier releases of the kernel, the SMP version often did not run on a non-SMP machine. Not a matter of different performance. More a matter of it just not running. There have been code improvements in the kernel of late that are allowing us to skip having two compiled versions. At least this is what I have been hearing. I don't run such an exotic thing yet.
Well that would have been before I got into Linux. I got my hands on my first PII dual machine way back, and installed SMP kernels on it, and then had to send off for a replacement processor after a co-worker modded the hell out of one of the slot one packages. I was very happy when the machine still ran with only one CPU. I think that was SuSE 7.1 or slightly earlier. -- _____________________________________ John Andersen
On Tue, 2006-09-12 at 00:22 -0800, John Andersen wrote:
On Tuesday 12 September 2006 00:16, Roger Oberholtzer wrote:
Except that in earlier releases of the kernel, the SMP version often did not run on a non-SMP machine. Not a matter of different performance. More a matter of it just not running. There have been code improvements in the kernel of late that are allowing us to skip having two compiled versions. At least this is what I have been hearing. I don't run such an exotic thing yet.
Well that would have been before I got into Linux.
I got my hands on my first PII dual machine way back, and installed SMP kernels on it, and then had to send off for a replacement processor after a co-worker modded the hell out of one of the slot one packages. I was very happy when the machine still ran with only one CPU.
I think that was SuSE 7.1 or slightly earlier.
I think it depended on a number of hardware issues. Some device drivers that were correctly written could exercise the problem. I do not think it was an all-or-none thing. But in most all Linux installs, in the troubleshooting section, there is always the suggestion that one should always try the non-smp version of the kernel if there is any problem. I think this is becoming less and less a troubleshooting step. -- Roger Oberholtzer OPQ Systems AB Ramböll Sverige AB Kapellgränd 7 P.O. Box 4205 SE-102 65 Stockholm, Sweden Tel: Int +46 8-615 60 20 Fax: Int +46 8-31 42 23
Does anyone know of a repository (to add to Smart) which contains the latest stable kernel, 2.6.17? Currently, I am running kernel 2.6.16.21-0.13-default.
suser-jengelh has 2.6.17 and .18. Be sure to add corresponding Hold rules into your package manager and manually pick the 2.6.17.
A recent thread said you have to get a new version of udev userspace I believe if you want to run a .18 kernel.
Can't say. You definitely need udev >= 080 for >= 2.6.16. Jan Engelhardt --
* Jan Engelhardt <jengelh@linux01.gwdg.de> [09-11-06 16:47]:
suser-jengelh has 2.6.17 and .18. Be sure to add corresponding Hold rules into your package manager and manually pick the 2.6.17.
A recent thread said you have to get a new version of udev userspace I believe if you want to run a .18 kernel.
Can't say. You definitely need udev >= 080 for >= 2.6.16.
2.6.18.-rc5-1.1-default (smp) with udev-085-30.11, no problems. -- Patrick Shanahan Registered Linux User #207535 http://wahoo.no-ip.org @ http://counter.li.org HOG # US1244711 Photo Album: http://wahoo.no-ip.org/gallery2
participants (7)
-
Greg Freemyer -
Jan Engelhardt -
John Andersen -
Patrick Shanahan -
Rick Friedman -
Roger Oberholtzer -
Sylvester Lykkehus