Slashdot Mirror
Linux Kernel 2.6.11 Released
Xpilot writes "Linus Torvalds has just announced the availability of the newest Linux kernel release, 2.6.11. The newest addition to Linux that's stirring up some excitement is the inclusion of Infiniband support. You can get it from the usual mirrors at http://kernel.org/mirrors."
And beyond!
does that mean it goes PAST 11?
Looks like Knoppix jumped the gun by including the 2.6 kernel in the new distro. If they had just waited a few hours...
InfiniBand, which is derived from its underlying concept of "infinite bandwidth,"...
Umm... I don't know about you... but that description didn't help me much... infinite bandwidth? What is this? How is this? How does linux get past physical hardware limitations that other os's can't?
---
Programming is like sex... Make one mistake and support it the rest of your life.
...before the site is slashdotted...
The Linux world is bracing for the final release of the new Linux 2.6.11 kernel, which will include a long list of driver updates and patches, with InfiniBand support perhaps being one of most interesting new additions.
Late last night, Linux creator Linus Torvalds issued the fifth release candidate for the 2.6.11 kernel. The first 2.6.11 RC was issued on Jan. 12; the second on Jan 21; the third on Feb. 2; and the fourth on Feb. 12.
In the RC5 posting, Torvalds indicated that it was likely the last RC before the final release.
"Hey, I hoped -- rc4 was the last one, but we had some laptop resource conflicts, various ppc TLB flush issues, some possible stack overflows in networking and a number of other details warranting a quick -- rc5 before the final 2.6.11," Torvalds wrote.
"This time it's really supposed to be a quickie, so people who can, please check it out, and we'll make the real 2.6.11 asap."
The long list of updates in the 2.6.11 kernel includes architecture updates for x86-64, ia64, ppc, arm and mips, as well as updates to ACPI (define), DRI (Direct Rendering Infrastructure, which permits direct access to graphics hardware for X Window System users), ALSA (Advanced Linux Sound Architecture, which provides MIDI and audio functionality to the Linux), SCSI (define) and the XFS high-performance journaling filesystem.
The 2.6.11 kernel will also be significant in that it includes driver support for the InfiniBand (define) interconnect architecture. InfiniBand, which is derived from its underlying concept of "infinite bandwidth," is a switched fabric interconnect technology for high-performance network devices that is common in a number of supercomputer clusters.
The upcoming inclusion of InfiniBand support in the Linux kernel is a major step according to the InfiniBand Trade Association.
"The inclusion of InfiniBand drivers in the upstream Linux kernel is a significant milestone," Ross Schibler, CTO of InfiniBand vendor Topspin Communications, told internetnews.com.
InfiniBand support was available previously in various Linux distributions, but it wasn't part of the mainstream kernel.org Linux.
"This now means that anyone that downloads a kernel will have automatic access to the software," explained Schibler. "It also means that any upcoming distributions (Red Hat, SUSE, etc.) will have the software included on their CDs. Previously SUSE had it on a distribution, but only in the 'unsupported' directory."
Schibler sees the inclusion of InfiniBand as a testament to the maturation of the technology.
"Now that the technology has matured to such a point that Linus has accepted it into the kernel, the way is paved for greater distribution of the code and accelerated deployment of the technology," Schibler said.
The previous Linux kernel.org release, version 2.6.10 was issued on Dec. 24 after two release candidates. Linux distribution began including the 2.6.10 thereafter with Red Hat's Fedora Project being one of the first.
Fedora Core 3 initially shipped with the 2.6.9 kernel and then upgraded to the 2.6.10 kernel on Jan 13. Mandrakelinux's 10.2 Beta 3 also includes the 2.6.10 release. SUSE Linux 9.2 currently includes the 2.6.8 kernel.
Including the most recent kernel into a distribution is not a particularly easy task. The upcoming Debian, code-named Sarge, will only ship with the 2.6.8 kernel. In a release update e-mail, Debian Sarge release manager Andreas Barth related that a meeting was recently held to review the status of which kernel they would include.
"The team leads involved eventually decided to stay with kernel 2.6.8 and 2.4.27, rather than bumping the 2.6 kernel to 2.6.10," Barth wrote. "This decision was made upon review of the known bugs in each of the 2.6 kernel versions; despite some significant bugs in the Debian 2.6.8 kernel tree, these bugs were weighed against the additional delays that a kernel version bump would introduce in t
And G4 laptops with an ATI finally get sleep support thanks to BenH's work!
(I know, "why would you want to run Linux on a Mac". Don't bother asking).
blah
I'm running 2.6.10 and the NVidia X Driver won't compile against it ... someone tell NVidia to keep up with this!
The UK mirror isn't showing 2.6.11 yet, perhaps it might be best to wait a little bit so they catch up instead of hitting kernel.org
However, Con Kolivas maintains a patchset for desktop users which incorporates a fix that allows the nVidia drivers to work at his kernel patch page. If you don't want the other stuff and just the nVidia fix, you can find the patch split out, and instructions on which patches to apply in his announcement of his patchset release. Check out the -ck patch though, it has a lot of cool stuff.
(yay, I actually got a story submission in...hi mom!)
"Backups are for wimps. Real men upload their data to an FTP site and have everyone else mirror it." -- Linus Torvalds
Does ACPI suspend work on more laptops? Inability to suspend is a major problem with Linux on laptops right now, as there are more and more ACPI-only laptops. The situation is considerably worse compared to APM, in my experience.
I like the serial and usb2 fixes. Looks like it's tested as a pretty stable revision. If anyone gets this installed before I do, post some impressions if you would.
Kernel junkies of the world unite! Your next fix has arrived!
# urpmi --test magict ic-develi magick
The following packages contain magic:
libmagic1
libmagic1-devel
libmagic1-sta
magicdev
magicpoint
mirrormagic
php-
php-mime_magic
Never confuse volume with power.
So it's now _officially_ all bug-free.
Torvalds, you scoundrel you!
Next you'll be telling us the kernel was made by the toothfairy for a lower TCO than windows...
Oh wait..
May the Maths Be with you!
zanders at nvForums has posted patches to improve performance with 2.6.x kernels. Here's the thread:4 6676
t achmentid=10558
http://www.nvnews.net/vbulletin/showthread.php?t=
This is the cumulative patch:
http://www.nvnews.net/vbulletin/attachment.php?at
>InfiniBand, which is derived from its underlying concept of "infinite bandwidth," is a switched fabric interconnect technology for high-performance network devices that is common in a number of supercomputer clusters.
So that works only for supercomputer clusters ?.Interestingly, the ChangeLog has some very small number of entries. The one I found most fun was:-
I mean, other wise they would end up as "-1" or "0" (when you assume in code that "0" or "1" for 1 -bit fields). How did a sign-extension in the IDE (must be heavily used) be missed till version 2.6 ??. Typically, this looks like the average release - some bug fixes and a couple of big features which nobody (well almost nobody) would use on their boxes.Quidquid latine dictum sit, altum videtur
Infiniband welcomes careful drivers.
:-D
Are you local? There's nothing for you here!
Linux 2.6.11 SCO 0 Better luck next time
From http://en.wikipedia.org/wiki/Operating_system:
In general, the operating system is the first layer of software loaded into computer memory when it starts up. As the first software layer, all other software that gets loaded after it depends on this software to provide them with various common core services. These common core services include, but are not limited to: disk access, memory management, task scheduling, and user interfacing. Since these basic common services are assumed to be provided by the OS, there is no need to re-implement those same functions over and over again in every other piece of software that you may use. The portion of code that performs these core services is called the "kernel" of the operating system. Operating system kernels had been evolved from libraries that provided the core services into unending programs that control system resources because of the early needs of accounting for computer usage and then protecting those records.
So that is the OS and the kernel. A new kernel version is new drivers and updated system services, which is a good thing. This is not the same as upgrading Win2000 to winXP or changing Linux distros as those involve many many more programs, libraries, & systems as compared (what is collectively known as an Operating System) to a kernel.
For those of you that are unaware, since the poster doesn't explain at all what Infiniband is, I will explain it for you.
Infiniband is a high-speed, low-latency interconnect used heavily with beowulf clusters (currently). Infiniband, like Myrinet, addressed many of the problems that are inherent with using interconnects like ethernet.
The biggest problem with any TCP/IP based transport, in the world of supercomputing, is latency. The amount of error checking that is involved creates latencies that bring fine-grained (lots of memory reads/writes/swaps) calculations to their knees. As many clusters use MPI (Message Passing Interface) for sharing memory between nodes, a low-latency interconnect was needed to replace ethernet and TCP/IP. People have worked on reducing latencies over ethernet by designing raw transport stacks, relying on the switch and the quality/brevity of the ethernet connections (using short, shielded cables proved useful), to ensure accurate data transport, but none of these methods have proven viable.
Infiniband has also been used as an interconnect for network storage devices as there are obvious advantages to this; eliminating much of that latency makes reads and writes to a device much simpler thus reducing overhead and improving overall throughput.
More information on Infiniband can be found here at the Infiniband sourceforge page. This should give a sufficiently technical overview of what it does without any of the marketing talk.
Does anyone know if any work is being done on the rather irritating problem I (and a fair few others) get with the 2.6 input system? Every time I use a mouse that goes through a KVM switch or a USB->PS2 adapter, the mouse would spazz around crazily and syslog would fill up with:
:(
lost synchronisation, throwing [1|2|3] bytes away
Adding psmouse.proto=imps made the problem go away for most usage, but it still occurs under very heavy load, which makes mplaying UT impossible
Moderation Total: -1 Troll, +3 Goat
... update your SCO licenses! /rimshot
cyn, free software and *nix operating systems enthusiast.
You can use Infiniband as a LAN, for storage, or maybe for within a box. You could say that Infiniband starts where Hypertransport leaves off.
For the short-haul usage, Infiniband is kind of big in terms of chip real estate. You can't cram it into a corner of a little FPGA like you can with RapidIO. For the long-haul usage, 1 gig or 10 gig Ethernet might be a better choice.
Note that Intel, originally the primary sponsor behind Infiniband, no longer gives a damn. But hey, if you have money to burn...
Who had been running 2.6.9 or earlier and just finished making a 2.6.10 kernel for the first time (e.g. because they suddenly needed new hardware support).
*rhand* *grouse*
cyn, free software and *nix operating systems enthusiast.
Since reiser4 is in beta, I doubt it will be in the mainstream kernel particularly soon. It's going to be tough to use experimental filesystems without using experimental patches. I don't think anyone sane is storing important data on reiser4 partitions without doing extensive backups.
I have seen the future, and it is inconvenient.
The linked changelog is only the changes between 2.6.11-RC5 and the final version, that's why it's so short. Is there a complete changelog available somewhere?
Also, does anyone know what the status of inotify support is? I think a lot of people would be glad to see it merged, as apps like Beagle require it and the new Gamin daemon (a FAM replacement) should work much better with it.
It's like deja vu all over again.
There doesn't appear to be a full changelog yet, but I have been following the release candidates, and it appears that Parallel ATA (AKA "Ultra ATA") Hard disk support is still not in the kernel.
This is frustrating. I had purchased an Ultra ATA Hard disk drive (which came bundled with a Serial/Parallel ATA controller), and I had it working fine under SUSE Linux 9.0. What I didn't realize at the time was, Promise made proprietary drivers for SuSE Linux, and no other distro.
I have wanted to switch over to Fedora Linux for some time now, but although it is able to detect my SATA card and load drivers for it just fine, It does not recognise the PATA connector, and does not locate my hard drive, as a result.
There does appear to be a patch available for this, but it is still officially "in development", and I am concerned that it will not make it into the mainstream kernel in time now for Fedora Core 4 to be able to recognize my hard drive, and install to it.
This is so frustrating. What is the holdup? PATA support appears to have been discussed for almost a year now and it is still not in the kernel. There appear to be a lot of Ultra ATA hard disks on the market; I can't be the only one encountering the frustration of not being able to install a modern version of Linux due to lack of driver support.
anyone know if the X series of thinkpad IBM laptops will suspend properly now? mine doesn't return from sleep, and won't even begin to suspend to disk properly. (thinkpad x30)
then again, X goofs up for me with the bios 'hybernation' feature too. though I think that's independent, as it still "works" - just with screen garbage on resume.
~/ssh slashdot.org ssh: connect to host slashdot.org port 22: too many beers
I have to patch the vanilla kernel in the following way so that cdrecord works for non-root users.
...' with no password:
/usr/bin/cdrecord
Perhaps I'm being dense, but why go through the trouble of patching the kernel? Why not just set up sudo? Something like the following would allow anyone in the cdrom group to run 'sudo cdrecord
%cdrom ALL=NOPASSWD:
You could even set up an alias like this: alias cdrecord='sudo cdrecord' so that you don't have to remember the sudo bit.
Call me crazy, but patching your kernel every time just to be able to record CDRs seems silly. I can understand not wanting to be root to use cdrecord, though.
And actually, the more I think about it, why can't you just change the permissions on the devices(s) to be group-writable by some group (e.g. cdrom) and make your users part of that group? I feel like I must be missing something.
I dunno. Seems like there are two very easy solutions to your issue, but maybe I don't understand the scope of the problem.
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
Here's mine. It allows all users to run CD-burning apps as root via sudo:
/usr/bin/cdrecord
ALL ALL=NOPASSWD:/usr/bin/xcdroast,
There are more to the issues than device permissions. The main part of it is that cdrecord needs to lock some of its buffers into non-swappable memory. This is a priveledged operation in an unpatched kernel.
I believe the patches allow trusted(?) applications to lock small amounts of this memory without requiring root.
Something like that, I follow along enough to know what's going on, but don't understand everything to it.
Hmm... I haven't heard anything about this, but my gut response is bafflement. What's wrong with setuid or sudo? Why reinvent the wheel? (no pun intended)
A host is a host from coast to coast...
Unless it's down, or slow, or fails to POST!
Google knows all.
:)
err...actually, google knows all who know all
Find a job you like and you will never work a day in your life.
"I am sick and tired of the next Kernel announcement talking about its support for some esoteric system or system that most of us don't use."
Two things have really bothered me, one was the fact that framebuffer console support for ATI Radeon cards was horribly broken in kernel releases that were supposed to be "stable, tested, for production". This went on forever. It started working again in 2.6.8, I think. It should have been flagged as experimental, if it didn't work. Without the framebuffer device, I can't use the system at all; it's essential to me. In fact, it's on the short list of things Linux will do, that Solaris, FreeBSD, and Windows will not do.
The other thing that bothered me, has to do with CD Writing. It seems that in kernel developer land, more people have SCSI CD Writers, and IDE CD Writers are unusual. But in the real world, IDE CD writers are far more common, and SCSI CD Writers are prohibitively expensive. But the whole CD Writing support treats IDE CD Writers like some kind of odd hardware from the top to the bottom, and the developer of the cdrecord client has been totally unprofessional about the whole thing.
-fb Everything not expressly forbidden is now mandatory.
VIA's support for Linux on EPIA boards is crap and I can't compile accelerated framebuffer for CLE266 and vesafb doesn't work for EPIA.
X11 driver works, but I need terminal emulation on framebuffer and also directFB should be quite a bit faster than X11.
VIA is offering source, but that source doesn't compile on 2.6.10 or 2.6.11.
It seems that there were quite some changes in fbdev in that time and I can't make that source to work with 2.6.11.
Palm pilots, iPods et al. are not really in the domain of the kernel developers - they are all strictly userland issues. So it would be up to distro makers and people writing KDE/Gnome programs to interface with things like palm pilots or iPods.
USB 'plug and play' (USB hotplug) has been supported and has been working for years. I've never had a problem with USB devices where there's been a program to use them (or a driver, for example USB mass storage).
Oolite: Elite-like game. For Mac, Linux and Windows
The other thing that bothered me, has to do with CD Writing. It seems that in kernel developer land, more people have SCSI CD Writers, and IDE CD Writers are unusual. But in the real world, IDE CD writers are far more common, and SCSI CD Writers are prohibitively expensive.
;)
But the whole CD Writing support treats IDE CD Writers like some kind of odd hardware from the top to the bottom,
because they are
Modern IDE ATAPI CD/DVD writers use the 'SCSI-3 mmc' command set. So basically they are SCSI Writers in IDE disguise. But internally they are not full SCSI devices, as they only support a small subset of all SCSI commands.
As a kernel hacker, what would you do?
1): write a SCSI Emulation layer that makes those IDE ATAPI devices act as full, real SCSI devices (from the software point of view). No redundant code, easier to maintain if done correctly.
2): write a specific IDE ATAPI driver and one specific driver for SCSI devices. Some redundant code, but more 'optimised' for each type of device
Linux has both.
1) was not maintained for quite a while, and obviously was badly written at first, thus nobody wanted to clean it up and it was maked 'deprecated'. But it still offers more features than 2).
OTOH 2) has DMA support which makes it attractive for many people, but is quite new and some app developers are afraid to support it, since the API might still change.
and the developer of the cdrecord client has been totally unprofessional about the whole thing.
Nobody has to love Joerg Schilling, and I often don't like his attitude either. However everybody is entitled to have his/her opinion, and in his case he thinks that everything except the SCSI way sucks (he loves Solaris and FreeBSD because they have good SCSI support). So naturally he despises 2), whereas the rest of the linux developer try to make it the default.
He produces the best CD/DVD writing application for linux, and he knows more that most other people when it comes to CD/DVD writing. And he has a point when he says that you should still use the ide-scsi driver whenever possible, because ide-cd driver is NOT complete and still lacks important features. The problem is that since he is quite a SCSI fanatic many people are not taking him seriously.
It should work fine, provided that:
/dev/cdrom
- You are using a recent kernel (2.6.11 includes a fix for the command filter, please upgrade...)
- You have write access to
- You are using cdrecord -dev=/dev/cdrom (using dev=ATAPI will *not* work)
- You are using a recent cdrecord
- You have an MMC-compliant cd writer. (Some of the less common ones which follow non-standard command sets will inevitably have problems at this point in time)
- cdrecord must not setuid root (I think this problem may be fixed in the latest version, but make sure it is not setuid just to be sure)
If you are really getting problems after confirming that you are running a sane setup, then you should check the "dmesg" output. For any command that Linux rejects, it will print out a message the first time it rejects it. This will be in the form of something like: Unknown opcode 4d
Once you have that opcode, maybe someone will be kind enough to look it up in the SCSI specs for you and see if it can safely be permitted in the kernel command filter.