it’s nice that the maintenance releases are slowing down a lil
—-
well the pace of 2.6 revisions are significantly more than 2.4. also folding in changes incrementally unless they are very disruptive and post poning 2.7 while using -mm tree as a “unstable” branch is the current development model. so slowing down is not really required
Should 2.6.9 break less things than 2.6.8? In my experience, 2.6.8 borked a number of things on my system, namely CD writing and the splashscreen. I’d like to keep up with the latest kernel version, but aren’t into patching things that *used* to work..
I found this site when looking how to get 2 psx pads to work when hooked up via lpt port. gamecon only supported one. I found this site http://rufus.hackish.org/wiki/gamecon and he said it’s now included in 2.6.9 and submitted by Vojtech Pavlik but I don’t see mention of it in the changelogs. Anyone know if it is or not?
I am glad they are working on USB fixes. My Sarotech external HDD box doesn’t work with FC2 and 3t2 (and other 2.6 distros), while it works with FC1 and Windows.
Should 2.6.9 break less things than 2.6.8? In my experience, 2.6.8 borked a number of things on my system, namely CD writing and the splashscreen. I’d like to keep up with the latest kernel version, but aren’t into patching things that *used* to work..
Blame the new policy.
Anyway, you can fix CD writing by SUID your executable (cdrecord, I guess). I heard that the change that made it “broken” is now permanent…
Well, I can’t get the official nvidia drivers to install. The installer insists that the “kernel module was built using the wrong source”, even though in the log everything seems to be pointing to the right source folder.
if you scroll down to a post named “Incompatible” by Con kolivas you will see a link there…download that diff file…
you will need to patch the diff, but since the diff file is for rc3 and not rc4 it doesn’t work…you’ll have to do it manually…go into /usr/src/linux/arch/i386/mm (sorry at work can’t remember the entire path)…there’s a init.c file there…line 44 needs to be added – check out the diff file, it shows it pretty clearly…add that, save the init.c file…then recompile the kernel:
make bzImage
then
make modules
then
make modules_install
copy across the System.map file and bzImage files to /boot, rename them accordingly and reboot…then run the .run file from nvidia, should work, tested it this morning against rc-4…
Anyway, you can fix CD writing by SUID your executable (cdrecord, I guess). I heard that the change that made it “broken” is now permanent…”
yeah well…the kernel developers are getting lazy in their old ages and don’t really care about us “grunts”, all they now care about is the big corporate $$$, so if things like cd recording and nvidia modules break it’s tough shit. As far as Andrew Morton is concerned the distros should be making the kernels stable, not the kernel developers, a total joke…
i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users.
Well, got a kernel compiled from my 2.6.8 config (plus a few changes, as necessary). Anybody having an issue with the vfat driver not working?
I can’t mount a FAT32 partition as type vfat. It’ll come right up as msdos, but mount gives me a bad superblock issue otherwise. It could just be me being stupid, but I changed no options concerning vfat between the two kernels, so it failing to work raised my eyebrows.
I’m running a custom compiled 2.6.5, it works but its kind of unstable because of my VIA chipset, which had problems with 2.6.5. So it locks up unless there is activity on the USB bus. The 2.6.8 kernel seems to have fixed this problem but completely breaks my USB mouse (everything is confused, clicks move the mouse pointer right and moving the mouse sends scroll events), and 2.6.9 doesn’t contain the pwc module for my webcam..
So I’ve got a choice between unstable, no mouse, and no webcam. Damnit I’m starting to really get pissed off at the 2.6 line. I should move back to 2.4
You have some really weird and esoteric issues. My 2nd system is running gentoo 2.6.8.1 with a logitec USB mouse and a an older via chipset and has no issue at all sir. I am however using the CK sources and perhaps that makes a difference.
It was my understanding that http://saillard.org/pwc/ would go into 2.6.9. I am currently using pwc-10.0.4.tar.bz2 with 2.6.8, and it was VERY easy to get working – didn’t even have to touch my kernel sources. Now I wonder why Nemosoft didn’t do it this way
You know how you set permissions with chmod and a set of 3 digits? Those are actually the 2nd, 3rd, and 4th digits; the first one is ignored if not set. That first digit sets set user ID with 4, set group ID with 2, and sticky with 1.
So 4555 would set r-sr-wr-w, where the s represents suid and would run the executable as root. I imagine 2555 would be r-wr-sr-w, but I haven’t had a need to do this yet. You’ll probably want to do this according to what the permissions already are.
You should probably read chmod’s man page if you aren’t familiar. I seem to recall cdrecord not liking being suid, but either way it didn’t work for me.
Yeah, it used to be fine, Kernel 2.6.5 was the first one that has been unstable for me.. Others have had the same problems with the VIA chipset.
As for the mouse issues, I have no idea what causes that. Moving from 2.6.3 to 2.6.5 I had to change the mouse entry in my XF86Config from ImPS/2 to ExplorerPS/2 but in 2.6.8 it doesn’t work with either setting. It’s a logitech wireless optical, part of the elite duo set of kb/mouse.
@Mike
Thanks for the heads up, that would be great if 2.6.9 includes pwc. Then I can give it a go.
I’m running -rc3 with the Nvidia driver and it’s absolutely fine. But -rc4 crashes a lot; the driver loads and runs, but I get regular lockups when running 3D apps. I wonder if the final 2.6.9 will be OK again?
FWIW, I’ve found everything since 2.6.7 to run great with no problems besides this; 2.6.6 was a complete turkey for some reason.
I compiled my first kernel a couple of weeks back because of the troubles with 2.6.8.1. I’m now using 2.6.7-mm7 on my via-mainboard and also using the nvidia-3d-drivers. It seems everything is runnign quite nicely. Accept from some strange problem(s) which my be triggered/caused by other programs … everything seems extremy well and stable. I’m very happy about its stability. I leave my system running complete days (ok it isn’t so long), but it doesn’t crash at all, even with the nvidia-drivers. So, unless there where security-updates, I’m very hesitant to update … I’ll see what the new policy(?) that ditros should make it stable really has.
So, to be sure it’s stable I’ll wait some moments to see if 2.6.9 is really stable and now sudden problems arise.
The next time I’ll also try to add the inotify-patch and maybe some things from the ck-patchset, like the isochronuous scheduling(?) when else something would need root access …
I’m nto sure who is providing the inotify-patches, but ti can be found on the dashboard – beagle(?) – mailinglists It hought, …
Does anyone know if theres any performance/desktop responsiveness gain in this kernel over the 2.6.8 kernel
Not much. Andrew Morton is testing some low latency patches in his -mm tree, but thats it. you should try con kolivas’ performance patches, -ck1 is out for 2.6.9 and its quite stable. And I am sure you will notice the difference.
Quote: David Pastern
Quote: “Blame the new policy.
yeah well…the kernel developers are getting lazy in their old ages and don’t really care about us “grunts”, all they now care about is the big corporate $$$, so if things like cd recording and nvidia modules break it’s tough shit. As far as Andrew Morton is concerned the distros should be making the kernels stable, not the kernel developers, a total joke…
i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users.
Dave
This new policy is really only opposed by the big corporate $$$, but as usual, linus and the kernel dev’s do what THEY like…
They dont want to take the NVIDIA drivers into account (in spite of all the big $$$ pushing) because they are proprietary software (in linus’ vision they should be included in the kernel). And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code.
do your homework before you rant.
Quote: Newbie
Hi,
What’s the -mm tree?
Andrew morton’s set of kernel patches, in which most exciting & possibly dangerous development takes place now, instead of in a 2.6.7 tree (this is the ‘new policy’)
Quote: Anonymous
Should the new patch be applied to the 2.6.8 or 2.6.8.1 codebase?
I seem to remember reading it would be from 2.6.8, but can’t find the details the now.
copy across the System.map file and bzImage files to /boot….
what is the purpose of this? I haven’t been doing this, and its always worked fine?
The bzImage file is your new kernel. You have to move it to /boot to have it available for booting. I’m not entirely sure what the System.map is, but I suspect it’s part of the booting process as well.
You may have been using your original kernel all this time, if you never moved bzImages to /boot.
I’m not sure, my experience with how different distros handle kernels is rather limited.
System.map is a list of the various symbols of the kernel and what location they physically occupy in memory. I’m not really sure what its used for commonly, probably debugging. I used it to upgrade a module to 2.6 from 2.4, since the module required access to a data structure that 2.6 wouldn’t allow access too I was able to have it access the address in memory directly. Which is probably a Bad Thing to do.
Who cares about the current Nvidia binary? Its the binary appling to the kernel -not the other way around. A fixed driver is probaly out in this week anyway.
Yes, system.map is for debugging. Your system will run fine with no system.map or a broken one, but if you try and debug your kernel with the wrong system.map it will make no sense.
<quote>
Dave
This new policy is really only opposed by the big corporate $$$, but as usual, linus and the kernel dev’s do what THEY like…
They dont want to take the NVIDIA drivers into account (in spite of all the big $$$ pushing) because they are proprietary software (in linus’ vision they should be included in the kernel). And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code.
do your homework before you rant.
</quote>
It’s not about the $$$, but this new policy is a bad thing. It’s resulting in a 2.6 that’s basically as stable as 2.5 was. Every 2.6 version I’ve tried has had major issues on my system. And yes, the scsi emulation may have been ugly, but it *worked*, wheras the replacements don’t. It was deprecated before there was a stable alternative, basically by executive order because linus doesn’t like the code, which is why cdrecord didn’t switch. Expecting the distribution developers to stabilise the kernel is nonsense, how is for example slackware supposed to do this? I’m not switching to 2.6 until it ceases to be a development branch (i.e. when 2.7 is started) which is what it is at the moment. And if the kernel developers are refusing to make a stable kernel, then I think, and I don’t say this lightly, we need a fork. There are many people who want a stable, useable operating system which will work on their hardware, and expect to be able to use the kernel.org sources as part of this. They don’t deserve this. OK, we haven’t paid them for it, but people rely on linux and the kernel developers. They shouldn’t let us down.
Are you guys criticizing Linus “The God” Torvalds?! Shame on you!
“OK, we haven’t paid them for it, but people rely on linux and the kernel developers. They shouldn’t let us down.”
Let who down? There are many people who think the new kernel development system is great (like me for starters), because this way Linux is developed even faster than before. I haven’t had any problems with 2.6 kernels, only improvements. However, I had dozens of problems with 2.4 kernels, so I’m more than happy to see that the new developing system is making my life easier.
If you think that 2.6 kernels suck, don’t just sit there complaining. Fix it, for Torvald’s sake! Fix it! Or start using Mandrake. I’m sure many Mandrake users are happy with the new kernels.
kernel source is available to be modified and to be hacked. The problem with some of comments is they forgot that they are free to modify the kernel as they want and they can submit one of these solutions to the kernel developers.
I think the broken softwares issue give more reason of the other developers to improve their code like Nvidia did with the inclusion of 4stacks support, issue that was caused by Red Hat kernel 2.6.5.
I compiled the kernel on the release day… and followed-suit with a compile of the nvidia drivers….
The driver compiled fine, and it works.
For anyone interested in a more comprehensive, experimental kernel… i recommend the Nitro-sources… (do a google search)… it comes pre-patched w/ just about everything you could want, and its system/desktop-responsiveness is snappy.
The problem with some of comments is they forgot that they are free to modify the kernel as they want and they can submit one of these solutions to the kernel developers.
Perhaps you got lost on your way to the kernel mailing list. I’m sure there are plenty of people here (Me included) that don’t have the slightest inclination to try digging around in the Linux kernel to fix things. The kernel devs are getting PAID to fix it, I see no reason I should try and fix things for free.
Let who down? There are many people who think the new kernel development system is great (like me for starters), because this way Linux is developed even faster than before. I haven’t had any problems with 2.6 kernels, only improvements. However, I had dozens of problems with 2.4 kernels, so I’m more than happy to see that the new developing system is making my life easier.
I guess you’re not a developer or a distro maintener. Most distros don’t have the ressources or the manpower to hack the kernel. Furthermore, it will inevitably lead to an huge amount of duplicate code by people trying to fix the mess.
Early 2.4 was somewhat problematic but many people will agree that it was launched far too early. I remember downloading and trying 2.4.0 at its launch day… and how it pitifully failed on my computer.
2.6 is changing at an incredibly fast pace. The upshot is, a lot of new, good, and interesting things are going into the kernel. The bad side is, a lot also breaks.
The “breakage” of cd-burning in 2.6.8 was intentional; otherwise, a _user_ with _read_ permission could overwrite firmware. It was annoyingly sudden, admittedly.
No one is forced to use Linux, or the 2.6 kernels. 2.4 seems to have stabalised by now; 2.2 is still available. You upgrade to the absolute latest dot release of a non-maintanence kernel at your own risk.
Linus’ policy on things like testing has been clear; “If it compiles, it is good, if it boots up it is perfect.”
If you want to just use linux, use your distro’s kernel. If you want to use someone’s patchset, or a kernel.org kernel, or upgrade to the latest point version, good luck; they all have some advantages, but they’re also riskier.
At present, you could argue the situations sucks. If you believe so – I’ve got one foot in that camp myself – just don’t upgrade every time osnews mentions a new dot release.
If you need to upgrade for something like hardware support, or because of a security hole, none of the above is particularily consoling. Hopefully things will start to settle down a little more; as many have pointed out, Linux still is quite lacking in many regards. This is irritating to novelty-seeking end-users, or those who want to avoid the shortcomings of older kernels; it’s just not an entirely bleak situation.
Sense the beginning of the 2.6 kernel series and subsequent releases, we have had inclusions for 4kb stacks, scheduling domains, reverse object based vm, cfq i/o schedular and udev (hotplug system in the kernel allowing for udev) etc.
All notable improvements, good stuff not to be sat on. No major breakage most of the stuff included has gone unnoticed.
I have not had one problem with any 2.6 release, personally.
No one is forced to use Linux, or the 2.6 kernels. 2.4 seems to have stabalised by now; 2.2 is still available. You upgrade to the absolute latest dot release of a non-maintanence kernel at your own risk.
Linus’ policy on things like testing has been clear; “If it compiles, it is good, if it boots up it is perfect.”
If you want to just use linux, use your distro’s kernel. If you want to use someone’s patchset, or a kernel.org kernel, or upgrade to the latest point version, good luck; they all have some advantages, but they’re also riskier.
I understand. However, the less stable the vanilla kernel is, the more problems we will have in the future… Like I said above, distro mainteners won’t be able to catch everything. And I know that Linus is not particularily fond of binary modules but he will have to live with it: hardware manufacturers won’t give their trade secrets (and possibly some secret they have bought) just for him.
“i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users. ”
Your grand-standing is such a joke, as to be laugable. Please, go back to Windows. PLEASE.
Quote: “And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code. ”
I’ll suggest you do your own homework – the problems with burning in 2.6.8 & 2.6.8.1 were due to changes in the kernel due to proposed security issues (I can find a post by Alan Cox himself on it if you’d like). There were some instances where I believe cdrecord had to be patched, as well as k3b. But the main thing was the kernel was changed and knowingly so, in that it would break things like cd burning by a normal user. That it was knowingly done, and released is bad enough.
The large corporations have the money and manpower to hire kernel developers to ‘stabilise’ them. The smaller distros (which are generally much better quality imho) don’t. This will lead to fragmentation of the kernel between different vendors, it will cause issues with 3rd party applications working with some distros (that have specific features improved/changed in the kernel due to vendor applied fixes), and not working with others. Not good. Compare a Redhat kernel to a standard public kernel and you’ll see what I mean.
Quote: “I have not had one problem with any 2.6 release, personally.”
You must not ever want to burn CDs…go out and try 2.6.8 or 2.6.8.1 and see if you can burn CDs…go on. I didn’t touch the 2.6 series until 2.6.5 was released, but it’s been plagued with breakages, it’s incredibly unstable in terms of morphing and breakage of things. And, despite all the hoolah, i’ve seen *nada* improvement in response from the 2.6 kernel. I’d suspect that an older p2 333 laptop with only 128mb of RAM would see some noticeable improvement from 2.4 to 2.6 due to the supposed improvements to latency, but nada.
Sure, I don’t have to use the 2.6 series – I could use 2.4 – but since 2.4 is in feature freeze, only serious bugs/security issues will now be fixed. If I need new features i’m forced to go to 2.6. I would personally say that 2.6 was release way too early, it still even now shouldn’t be a stable kernel release. And yes, I know 2.4 was a bitch on release for some time, I remember downloading, compiling and using a 2.4.0 kernel thanks.
Joe – what if you’re using a distro with 2.4.18. You need a feature for your PC that is not included in this kernel, in fact only the 2.6 series kernels have it. Your distro says they won’t support 2.6 kernels. So you go to http://www.kernel.org and download and compile a kernel and have all sorts of reliabiltiy issues/breakages etc. How impressed would you be? The whole idea of 2.0, 2.2, 2.4 & 2.6 even release kernels was that they were the “stable” branch. odd numbers being developmental…we still haven’t seen an official 2.7 branch released yet, 8 months or more after the release of 2.6. We’re seeing items that should be in the unstable branch development tree introduced into the stable branch. The whole kernel development process has been turned upside down.
To say that it’s up to the distros to stabilise kernels is a joke. The smaller distros will die, only the larger distros will survive. There goes true competition. I’ve used Redhat, Suse, Mandrake and they’re crap imho. Debian is the best out of the big ones, I’ve never tried Gentoo. I’m currently using Libranet GNU/Linux and it’s fantastic. A small company. A smaller distro, but much better quality than the big competitors. Under this new system these guys will slowly be eradicated. It’s an exceptionally bad decision by Linus & Andrew, and many kernel developers agreed with the new changes/ideas on kernel development.
There are other alternatives to Linux. The windows kernel isn’t actually that bad, it’s the rest of the shit that sits on top of it that has the problems. OS X is nice as well, but costly. BSDs are ‘free’, but I disagree with the BSD style license for a variety of moralistic reasons. If you don’t believe me, if the Linux kernel had been released under a BSD license it would have long since been taken over and used by a large corporation. Linus himself has said that that was his reason de etre for releasing Linux under the GPL.
I mostly agree with you David, but there’s nothing stopping someone from maintaining a patch set to stabilize the kernel for individuals and smaller distributions. I agree it shouldn’t be necessary, but I don’t think it’s THAT big a deal. Besides, if worse comes to worse it can always be forked.
Or maybe this will promote some Ubuntu:Debian like relationships in the kernel. As in, an array of Linux based kernels which take a step beyond what we already see in patch sets. If that would be a good thing or not, I’m not really sure.
Sweet… it’s nice that the maintenance releases are slowing down a lil…. (usually indicative of increasing stability/maturation)….
Anyway… If you’re using 2.6.9-RC4, and it works, don’t bother upgrading…
it’s nice that the maintenance releases are slowing down a lil
—-
well the pace of 2.6 revisions are significantly more than 2.4. also folding in changes incrementally unless they are very disruptive and post poning 2.7 while using -mm tree as a “unstable” branch is the current development model. so slowing down is not really required
Anyone know how much of Ingo’s latency reduction work has made its way in this release?
Should 2.6.9 break less things than 2.6.8? In my experience, 2.6.8 borked a number of things on my system, namely CD writing and the splashscreen. I’d like to keep up with the latest kernel version, but aren’t into patching things that *used* to work..
How about linking to the mirrors page ( http://www.kernel.org/mirrors/ ) and not the tar.gz.
I know kernel.org has oodles of bandwidth, but lets leave it available for the mirrors
Does anyone know if theres any performance/desktop responsiveness gain in this kernel over the 2.6.8 kernel
I found this site when looking how to get 2 psx pads to work when hooked up via lpt port. gamecon only supported one. I found this site http://rufus.hackish.org/wiki/gamecon and he said it’s now included in 2.6.9 and submitted by Vojtech Pavlik but I don’t see mention of it in the changelogs. Anyone know if it is or not?
I am glad they are working on USB fixes. My Sarotech external HDD box doesn’t work with FC2 and 3t2 (and other 2.6 distros), while it works with FC1 and Windows.
Should 2.6.9 break less things than 2.6.8? In my experience, 2.6.8 borked a number of things on my system, namely CD writing and the splashscreen. I’d like to keep up with the latest kernel version, but aren’t into patching things that *used* to work..
Blame the new policy.
Anyway, you can fix CD writing by SUID your executable (cdrecord, I guess). I heard that the change that made it “broken” is now permanent…
When will it reach the mainline kernel?
Well, I can’t get the official nvidia drivers to install. The installer insists that the “kernel module was built using the wrong source”, even though in the log everything seems to be pointing to the right source folder.
Reddazz – 2.6.9 once again breaks the Nvidia drivers…see here:
http://kerneltrap.org/node/view/3992#comment
if you scroll down to a post named “Incompatible” by Con kolivas you will see a link there…download that diff file…
you will need to patch the diff, but since the diff file is for rc3 and not rc4 it doesn’t work…you’ll have to do it manually…go into /usr/src/linux/arch/i386/mm (sorry at work can’t remember the entire path)…there’s a init.c file there…line 44 needs to be added – check out the diff file, it shows it pretty clearly…add that, save the init.c file…then recompile the kernel:
make bzImage
then
make modules
then
make modules_install
copy across the System.map file and bzImage files to /boot, rename them accordingly and reboot…then run the .run file from nvidia, should work, tested it this morning against rc-4…
Dave
Quote: “Blame the new policy.
Anyway, you can fix CD writing by SUID your executable (cdrecord, I guess). I heard that the change that made it “broken” is now permanent…”
yeah well…the kernel developers are getting lazy in their old ages and don’t really care about us “grunts”, all they now care about is the big corporate $$$, so if things like cd recording and nvidia modules break it’s tough shit. As far as Andrew Morton is concerned the distros should be making the kernels stable, not the kernel developers, a total joke…
i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users.
Dave
Ok thanks a lot for the tip, works like a charm.
Well, got a kernel compiled from my 2.6.8 config (plus a few changes, as necessary). Anybody having an issue with the vfat driver not working?
I can’t mount a FAT32 partition as type vfat. It’ll come right up as msdos, but mount gives me a bad superblock issue otherwise. It could just be me being stupid, but I changed no options concerning vfat between the two kernels, so it failing to work raised my eyebrows.
I’m running a custom compiled 2.6.5, it works but its kind of unstable because of my VIA chipset, which had problems with 2.6.5. So it locks up unless there is activity on the USB bus. The 2.6.8 kernel seems to have fixed this problem but completely breaks my USB mouse (everything is confused, clicks move the mouse pointer right and moving the mouse sends scroll events), and 2.6.9 doesn’t contain the pwc module for my webcam..
So I’ve got a choice between unstable, no mouse, and no webcam. Damnit I’m starting to really get pissed off at the 2.6 line. I should move back to 2.4
Hello Leo,
You have some really weird and esoteric issues. My 2nd system is running gentoo 2.6.8.1 with a logitec USB mouse and a an older via chipset and has no issue at all sir. I am however using the CK sources and perhaps that makes a difference.
Good Luck.
It was my understanding that http://saillard.org/pwc/ would go into 2.6.9. I am currently using pwc-10.0.4.tar.bz2 with 2.6.8, and it was VERY easy to get working – didn’t even have to touch my kernel sources. Now I wonder why Nemosoft didn’t do it this way
Hi,
What’s the -mm tree?
Sorry to sound dumb, but how do you SUID cdrecord binary?
on Debian:
dpkg-reconfigure cdrecord 😉
Mike, thanks for that pwc link. Didn’t know it existed! Will try it out asap.
You know how you set permissions with chmod and a set of 3 digits? Those are actually the 2nd, 3rd, and 4th digits; the first one is ignored if not set. That first digit sets set user ID with 4, set group ID with 2, and sticky with 1.
So 4555 would set r-sr-wr-w, where the s represents suid and would run the executable as root. I imagine 2555 would be r-wr-sr-w, but I haven’t had a need to do this yet. You’ll probably want to do this according to what the permissions already are.
You should probably read chmod’s man page if you aren’t familiar. I seem to recall cdrecord not liking being suid, but either way it didn’t work for me.
@Rhyotte
Yeah, it used to be fine, Kernel 2.6.5 was the first one that has been unstable for me.. Others have had the same problems with the VIA chipset.
As for the mouse issues, I have no idea what causes that. Moving from 2.6.3 to 2.6.5 I had to change the mouse entry in my XF86Config from ImPS/2 to ExplorerPS/2 but in 2.6.8 it doesn’t work with either setting. It’s a logitech wireless optical, part of the elite duo set of kb/mouse.
@Mike
Thanks for the heads up, that would be great if 2.6.9 includes pwc. Then I can give it a go.
Have you tried setting the protocol to ‘auto’? Sometimes a protocol will mostly work even though it’s not the right one.
Thanks everyone i’ll give it a try when i get home
I’m running -rc3 with the Nvidia driver and it’s absolutely fine. But -rc4 crashes a lot; the driver loads and runs, but I get regular lockups when running 3D apps. I wonder if the final 2.6.9 will be OK again?
FWIW, I’ve found everything since 2.6.7 to run great with no problems besides this; 2.6.6 was a complete turkey for some reason.
Should the new patch be applied to the 2.6.8 or 2.6.8.1 codebase?
I seem to remember reading it would be from 2.6.8, but can’t find the details the now.
Thanks
On my system uname -a gives:Linux firebird 2.6.9-final #1 Sun Oct 17 17:15:47 CEST 2004 i686 GNU/Linux.
With kernel 2.6.5 up to 2.6.8.1-k7 i had some obstacles with
a “broken” cdrecord,however the latest nvidia-driver ran smoothly.Now with kernel-2.6.9 the only thing that doesn’t
work is the nvidia driver.Not that it isn’i a big issue for me
since you don’t need to have it installed in order to watch
some dvd’s with xine,performance is equivalent with or without
the driver .
Is inotify ready for the mainline kernel yet?
I couldn’t find a trace of it in the changelog.
Appearently it already got vendor-support, and is essential to the ‘desktop revolution’ happening at the moment
Heya,
I compiled my first kernel a couple of weeks back because of the troubles with 2.6.8.1. I’m now using 2.6.7-mm7 on my via-mainboard and also using the nvidia-3d-drivers. It seems everything is runnign quite nicely. Accept from some strange problem(s) which my be triggered/caused by other programs … everything seems extremy well and stable. I’m very happy about its stability. I leave my system running complete days (ok it isn’t so long), but it doesn’t crash at all, even with the nvidia-drivers. So, unless there where security-updates, I’m very hesitant to update … I’ll see what the new policy(?) that ditros should make it stable really has.
So, to be sure it’s stable I’ll wait some moments to see if 2.6.9 is really stable and now sudden problems arise.
The next time I’ll also try to add the inotify-patch and maybe some things from the ck-patchset, like the isochronuous scheduling(?) when else something would need root access …
I’m nto sure who is providing the inotify-patches, but ti can be found on the dashboard – beagle(?) – mailinglists It hought, …
Quote Johnny Q:
Does anyone know if theres any performance/desktop responsiveness gain in this kernel over the 2.6.8 kernel
Not much. Andrew Morton is testing some low latency patches in his -mm tree, but thats it. you should try con kolivas’ performance patches, -ck1 is out for 2.6.9 and its quite stable. And I am sure you will notice the difference.
Quote: David Pastern
Quote: “Blame the new policy.
yeah well…the kernel developers are getting lazy in their old ages and don’t really care about us “grunts”, all they now care about is the big corporate $$$, so if things like cd recording and nvidia modules break it’s tough shit. As far as Andrew Morton is concerned the distros should be making the kernels stable, not the kernel developers, a total joke…
i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users.
Dave
This new policy is really only opposed by the big corporate $$$, but as usual, linus and the kernel dev’s do what THEY like…
They dont want to take the NVIDIA drivers into account (in spite of all the big $$$ pushing) because they are proprietary software (in linus’ vision they should be included in the kernel). And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code.
do your homework before you rant.
Quote: Newbie
Hi,
What’s the -mm tree?
Andrew morton’s set of kernel patches, in which most exciting & possibly dangerous development takes place now, instead of in a 2.6.7 tree (this is the ‘new policy’)
Quote: Anonymous
Should the new patch be applied to the 2.6.8 or 2.6.8.1 codebase?
I seem to remember reading it would be from 2.6.8, but can’t find the details the now.
Thanks
2.6.8
copy across the System.map file and bzImage files to /boot….
what is the purpose of this? I haven’t been doing this, and its always worked fine?
copy across the System.map file and bzImage files to /boot….
what is the purpose of this? I haven’t been doing this, and its always worked fine?
The bzImage file is your new kernel. You have to move it to /boot to have it available for booting. I’m not entirely sure what the System.map is, but I suspect it’s part of the booting process as well.
You may have been using your original kernel all this time, if you never moved bzImages to /boot.
I’m not sure, my experience with how different distros handle kernels is rather limited.
It is really no surprise about the cdrecord being broken, Linus was on record a while ago about what a stupid system it was using.
k3b is doing a good job documenting the current state of cd recording in Linux:
http://k3b.plainblack.com/index.pl/news2
System.map is a list of the various symbols of the kernel and what location they physically occupy in memory. I’m not really sure what its used for commonly, probably debugging. I used it to upgrade a module to 2.6 from 2.4, since the module required access to a data structure that 2.6 wouldn’t allow access too I was able to have it access the address in memory directly. Which is probably a Bad Thing to do.
Who cares about the current Nvidia binary? Its the binary appling to the kernel -not the other way around. A fixed driver is probaly out in this week anyway.
Yes, system.map is for debugging. Your system will run fine with no system.map or a broken one, but if you try and debug your kernel with the wrong system.map it will make no sense.
<quote>
Dave
This new policy is really only opposed by the big corporate $$$, but as usual, linus and the kernel dev’s do what THEY like…
They dont want to take the NVIDIA drivers into account (in spite of all the big $$$ pushing) because they are proprietary software (in linus’ vision they should be included in the kernel). And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code.
do your homework before you rant.
</quote>
It’s not about the $$$, but this new policy is a bad thing. It’s resulting in a 2.6 that’s basically as stable as 2.5 was. Every 2.6 version I’ve tried has had major issues on my system. And yes, the scsi emulation may have been ugly, but it *worked*, wheras the replacements don’t. It was deprecated before there was a stable alternative, basically by executive order because linus doesn’t like the code, which is why cdrecord didn’t switch. Expecting the distribution developers to stabilise the kernel is nonsense, how is for example slackware supposed to do this? I’m not switching to 2.6 until it ceases to be a development branch (i.e. when 2.7 is started) which is what it is at the moment. And if the kernel developers are refusing to make a stable kernel, then I think, and I don’t say this lightly, we need a fork. There are many people who want a stable, useable operating system which will work on their hardware, and expect to be able to use the kernel.org sources as part of this. They don’t deserve this. OK, we haven’t paid them for it, but people rely on linux and the kernel developers. They shouldn’t let us down.
Got nvidia working.uname -a now gives:Linux firebird 2.6.9-ck1 #2 Tue Oct 19 20:55:11 CEST 2004 i686 GNU/Linux.This one works
with the latest nvidia driver.While compiling i kept my old
2.6.9 config and only changed the option support for nvidia
chipsets.I thought while my motherboard is a VIA one
i skipped this option.While compiling the ck-patched kernel i thought what the heck maybe it’s sinnfull.
Are you guys criticizing Linus “The God” Torvalds?! Shame on you!
“OK, we haven’t paid them for it, but people rely on linux and the kernel developers. They shouldn’t let us down.”
Let who down? There are many people who think the new kernel development system is great (like me for starters), because this way Linux is developed even faster than before. I haven’t had any problems with 2.6 kernels, only improvements. However, I had dozens of problems with 2.4 kernels, so I’m more than happy to see that the new developing system is making my life easier.
If you think that 2.6 kernels suck, don’t just sit there complaining. Fix it, for Torvald’s sake! Fix it! Or start using Mandrake. I’m sure many Mandrake users are happy with the new kernels.
kernel source is available to be modified and to be hacked. The problem with some of comments is they forgot that they are free to modify the kernel as they want and they can submit one of these solutions to the kernel developers.
I think the broken softwares issue give more reason of the other developers to improve their code like Nvidia did with the inclusion of 4stacks support, issue that was caused by Red Hat kernel 2.6.5.
I compiled the kernel on the release day… and followed-suit with a compile of the nvidia drivers….
The driver compiled fine, and it works.
For anyone interested in a more comprehensive, experimental kernel… i recommend the Nitro-sources… (do a google search)… it comes pre-patched w/ just about everything you could want, and its system/desktop-responsiveness is snappy.
The problem with some of comments is they forgot that they are free to modify the kernel as they want and they can submit one of these solutions to the kernel developers.
Perhaps you got lost on your way to the kernel mailing list. I’m sure there are plenty of people here (Me included) that don’t have the slightest inclination to try digging around in the Linux kernel to fix things. The kernel devs are getting PAID to fix it, I see no reason I should try and fix things for free.
I did not talk about developers. I talk about users who want customize their own kernels.
Let who down? There are many people who think the new kernel development system is great (like me for starters), because this way Linux is developed even faster than before. I haven’t had any problems with 2.6 kernels, only improvements. However, I had dozens of problems with 2.4 kernels, so I’m more than happy to see that the new developing system is making my life easier.
I guess you’re not a developer or a distro maintener. Most distros don’t have the ressources or the manpower to hack the kernel. Furthermore, it will inevitably lead to an huge amount of duplicate code by people trying to fix the mess.
Early 2.4 was somewhat problematic but many people will agree that it was launched far too early. I remember downloading and trying 2.4.0 at its launch day… and how it pitifully failed on my computer.
2.6 is changing at an incredibly fast pace. The upshot is, a lot of new, good, and interesting things are going into the kernel. The bad side is, a lot also breaks.
The “breakage” of cd-burning in 2.6.8 was intentional; otherwise, a _user_ with _read_ permission could overwrite firmware. It was annoyingly sudden, admittedly.
No one is forced to use Linux, or the 2.6 kernels. 2.4 seems to have stabalised by now; 2.2 is still available. You upgrade to the absolute latest dot release of a non-maintanence kernel at your own risk.
Linus’ policy on things like testing has been clear; “If it compiles, it is good, if it boots up it is perfect.”
If you want to just use linux, use your distro’s kernel. If you want to use someone’s patchset, or a kernel.org kernel, or upgrade to the latest point version, good luck; they all have some advantages, but they’re also riskier.
At present, you could argue the situations sucks. If you believe so – I’ve got one foot in that camp myself – just don’t upgrade every time osnews mentions a new dot release.
If you need to upgrade for something like hardware support, or because of a security hole, none of the above is particularily consoling. Hopefully things will start to settle down a little more; as many have pointed out, Linux still is quite lacking in many regards. This is irritating to novelty-seeking end-users, or those who want to avoid the shortcomings of older kernels; it’s just not an entirely bleak situation.
Sense the beginning of the 2.6 kernel series and subsequent releases, we have had inclusions for 4kb stacks, scheduling domains, reverse object based vm, cfq i/o schedular and udev (hotplug system in the kernel allowing for udev) etc.
All notable improvements, good stuff not to be sat on. No major breakage most of the stuff included has gone unnoticed.
I have not had one problem with any 2.6 release, personally.
No one is forced to use Linux, or the 2.6 kernels. 2.4 seems to have stabalised by now; 2.2 is still available. You upgrade to the absolute latest dot release of a non-maintanence kernel at your own risk.
Linus’ policy on things like testing has been clear; “If it compiles, it is good, if it boots up it is perfect.”
If you want to just use linux, use your distro’s kernel. If you want to use someone’s patchset, or a kernel.org kernel, or upgrade to the latest point version, good luck; they all have some advantages, but they’re also riskier.
I understand. However, the less stable the vanilla kernel is, the more problems we will have in the future… Like I said above, distro mainteners won’t be able to catch everything. And I know that Linus is not particularily fond of binary modules but he will have to live with it: hardware manufacturers won’t give their trade secrets (and possibly some secret they have bought) just for him.
“i’m going to see how this new policy pans out, and in all honesty if it leaves shit kernels at http://www.kernel.org then i’ll either move to freebsd or back to Windows. Linus is not listening to the masses now, but the corporates and it’s going to cost Linux a lot of users. ”
Your grand-standing is such a joke, as to be laugable. Please, go back to Windows. PLEASE.
Quote: “And CD-Record still relied on old scsi emulation, which was depricated for a long time, until they didnt want to wait any longer and removed the (ugly) code. ”
I’ll suggest you do your own homework – the problems with burning in 2.6.8 & 2.6.8.1 were due to changes in the kernel due to proposed security issues (I can find a post by Alan Cox himself on it if you’d like). There were some instances where I believe cdrecord had to be patched, as well as k3b. But the main thing was the kernel was changed and knowingly so, in that it would break things like cd burning by a normal user. That it was knowingly done, and released is bad enough.
The large corporations have the money and manpower to hire kernel developers to ‘stabilise’ them. The smaller distros (which are generally much better quality imho) don’t. This will lead to fragmentation of the kernel between different vendors, it will cause issues with 3rd party applications working with some distros (that have specific features improved/changed in the kernel due to vendor applied fixes), and not working with others. Not good. Compare a Redhat kernel to a standard public kernel and you’ll see what I mean.
Dave
Quote: “I have not had one problem with any 2.6 release, personally.”
You must not ever want to burn CDs…go out and try 2.6.8 or 2.6.8.1 and see if you can burn CDs…go on. I didn’t touch the 2.6 series until 2.6.5 was released, but it’s been plagued with breakages, it’s incredibly unstable in terms of morphing and breakage of things. And, despite all the hoolah, i’ve seen *nada* improvement in response from the 2.6 kernel. I’d suspect that an older p2 333 laptop with only 128mb of RAM would see some noticeable improvement from 2.4 to 2.6 due to the supposed improvements to latency, but nada.
Sure, I don’t have to use the 2.6 series – I could use 2.4 – but since 2.4 is in feature freeze, only serious bugs/security issues will now be fixed. If I need new features i’m forced to go to 2.6. I would personally say that 2.6 was release way too early, it still even now shouldn’t be a stable kernel release. And yes, I know 2.4 was a bitch on release for some time, I remember downloading, compiling and using a 2.4.0 kernel thanks.
Dave
Joe – what if you’re using a distro with 2.4.18. You need a feature for your PC that is not included in this kernel, in fact only the 2.6 series kernels have it. Your distro says they won’t support 2.6 kernels. So you go to http://www.kernel.org and download and compile a kernel and have all sorts of reliabiltiy issues/breakages etc. How impressed would you be? The whole idea of 2.0, 2.2, 2.4 & 2.6 even release kernels was that they were the “stable” branch. odd numbers being developmental…we still haven’t seen an official 2.7 branch released yet, 8 months or more after the release of 2.6. We’re seeing items that should be in the unstable branch development tree introduced into the stable branch. The whole kernel development process has been turned upside down.
To say that it’s up to the distros to stabilise kernels is a joke. The smaller distros will die, only the larger distros will survive. There goes true competition. I’ve used Redhat, Suse, Mandrake and they’re crap imho. Debian is the best out of the big ones, I’ve never tried Gentoo. I’m currently using Libranet GNU/Linux and it’s fantastic. A small company. A smaller distro, but much better quality than the big competitors. Under this new system these guys will slowly be eradicated. It’s an exceptionally bad decision by Linus & Andrew, and many kernel developers agreed with the new changes/ideas on kernel development.
There are other alternatives to Linux. The windows kernel isn’t actually that bad, it’s the rest of the shit that sits on top of it that has the problems. OS X is nice as well, but costly. BSDs are ‘free’, but I disagree with the BSD style license for a variety of moralistic reasons. If you don’t believe me, if the Linux kernel had been released under a BSD license it would have long since been taken over and used by a large corporation. Linus himself has said that that was his reason de etre for releasing Linux under the GPL.
There’s always GNU/Hurd!
Dave
I mostly agree with you David, but there’s nothing stopping someone from maintaining a patch set to stabilize the kernel for individuals and smaller distributions. I agree it shouldn’t be necessary, but I don’t think it’s THAT big a deal. Besides, if worse comes to worse it can always be forked.
Or maybe this will promote some Ubuntu:Debian like relationships in the kernel. As in, an array of Linux based kernels which take a step beyond what we already see in patch sets. If that would be a good thing or not, I’m not really sure.
Here’s how I’ve been burning CDs using the 2.6 kernel series:
/usr/bin/cdrecord -v speed=10 dev=/dev/hdc the.iso
Where /dev/hdc is my CD-RW drive (notice the lack of [fake] SCSI targetting).
The cdrecord version which I use is the one present in Slackware-current.