login
Header Space

 
 

Linux: 2.6.0 Released; "The beaver is out of detox"

December 18, 2003 - 1:08am
Submitted by Jeremy on December 18, 2003 - 1:08am.
Linux

Linus Torvalds announced the final release of the 2.6.0 kernel, beginning a new stable kernel branch. His announcement on the Linux Kernel mailing list begins, "this should not be a big surprise to anybody on the list any more, since we've been building up to it for a long time now, and for the last few weeks I haven't accepted any patches except for what amounts to fairly obvious one-liners." Referring to the 11kB patch from 2.6.0-test11 [story], he says "It's not the totally empty patch I was hoping for, but judging by the bugs I worked on personally, things are looking pretty good."

Read on for the complete changelog. Linus notes that we can expect a posting soon from the 2.6 maintainer Andrew Morton [interview] containing some caveats and pointers to information highlighting many of the changes between the 2.4.x kernels [forum] and the 2.6.x kernels [forum]. Those interested in upgrading from 2.4 to 2.6 may find this KernelTrap article useful. Linus acknowledges that there are a few known issues remaining, though none severe enough to be considered release-critical. Of those, some have probable fixes already merged in Andrew's -mm tree. Going forward, Linus explains:

"NOTE! I'll continue to keep track of the 2.6 BK tree until we're closer to the time when we literally split it for 2.7.x, because both Andrew and I are pretty comfortable with our respective toolchains. But Andrew is the stable tree maintainer, so everything should be approved by him at this point. Think of the -mm tree as the staging area, and mine as a release tree. We'll work together, but Andrew is boss."


From: Linus Torvalds [email blocked]
To: Kernel Mailing List [email blocked]
Subject: Linux 2.6.0
Date: Wed, 17 Dec 2003 20:14:06 -0800 (PST)


				"The beaver is out of detox"
						- Anon

This should not be a big surprise to anybody on the list any more, since
we've been building up to it for a long time now, and for the last few
weeks I haven't accepted any patches except for what amounts to fairly
obvious one-liners.

Anyway, 2.6.0 is out there now, and the patch from -test11 is a swelte 
11kB in size. It's not the totally empty patch I was hoping for, but 
judging by the bugs I worked on personally, things are looking pretty 
good. 

To give you an example, one of the nastier bugs that we chased for the 
last five weeks was a bug that could only be reproduced reliably on a 
16- or 32-way system, and only when the system had flaky disks. Putting in 
known-good disks made the problem disappear. Similarly, compiling the 
kernel with another compiler made the problem disappear.

It turned out to be a really subtle bug wrt SMP ordering and stack
allocation, and lots of thanks to Ram Pai for gathering all the
information that eventually led to it being fixed. The fix was a one-liner
and a big comment - but my point is that the quality of bugs has been
pretty high lately, and we feel that we're in pretty good shape.

Andrew has written up some caveats and pointers to information about 2.4.x
vs 2.6.x changes, and I'll let him post that. Some known issues were not
considered to be release-critical and a number of them have pending fixes
in the -mm queue. Generally they just didn't have the kind of verification
yet where I was willing to take them in order to make sure a fair 2.6.0
release.

NOTE! I'll continue to keep track of the 2.6 BK tree until we're closer to
the time when we literally split it for 2.7.x, because both Andrew and I
are pretty comfortable with our respective toolchains. But Andrew is the
stable tree maintainer, so everything should be approved by him at this
point. Think of the -mm tree as the staging area, and mine as a release
tree. We'll work together, but Andrew is boss.

(BK merging will have to go through some approval format, we'll see how
that works out exactly).

		Linus

---

Summary of changes from v2.6.0-test11 to v2.6.0
============================================

Alan Stern:
  o USB: fix bug not setting device state following usb_device_reset()

Andrey Borzenkov:
  o USB: prevent catch-all USB aliases in modules.alias

Arnaldo Carvalho de Melo:
  o [IPV6]: Fix TCP socket leak

David Brownell:
  o USB: fix remove device after set_configuration

David S. Miller:
  o [NETFILTER]: In conntrack, do not fragment TSO packets by accident
  o [PKT_SCHED]: Do not dereference the special pointer value 'HTB_DIRECT'

Greg Kroah-Hartman:
  o USB: register usb-serial ports in the proper place in sysfs
  o USB: fix race with hub devices disconnecting while stuff is still
    happening to them
  o USB: fix bug for multiple opens on ttyUSB devices
  o kobject: fix bug where a parent could be deleted before a child
    device

Harald Welte:
  o [NETFILTER]: Sanitize ip_ct_tcp_timeout_close_wait value, from 2.4.x

Herbert Xu:
  o USB: Fix connect/disconnect race

Hideaki Yoshifuji:
  o [IPV6]: Fix ipv4 mapped address calculation in udpv6_sendmsg()

Hirofumi Ogawa:
  o Missing initialization of /proc/net/tcp seq_file

Ingo Molnar:
  o Fix lost wakeups problem
  o Fix /proc access to dead thread group list oops

James McMechan:
  o tmpfs oops fix

Jean Delvare:
  o I2C: fix i2c_smbus_write_byte() for i2c-nforce2

Jeff Garzik:
  o fix use-after-free in libata
  o fix oops on unload in pcnet32
  o remove manual driver poisoning of net_device
  o wireless airo oops fix

Jens Axboe:
  o fix broken x86_64 rdtscll
  o scsi_ioctl memcpy'ing user address
  o no bio unmap on cdb copy failure
  o Fix IDE bus reset and DMA disable when reading blank DVD-R
  o CDROM_SEND_PACKET bug

Jes Sorensen:
  o qla1280 crash fix in error handling

Julian Anastasov:
  o [BRIDGE]: Provide correct TOS value to IPv4 routing

Linus Torvalds:
  o Fix x86 kernel page fault error codes
  o Fix ide-scsi.c uninitialized variable
  o Fix the PROT_EXEC breakage on anonymous mmap
  o Fix subtle bug in "finish_wait()", which can cause kernel stack
    corruption on SMP because of another CPU still accessing a
    waitqueue even after it was de-allocated.
  o More subtle SMP bugs in prepare_to_wait()/finish_wait()
  o Fix thread group leader zombie leak

Martin Devera:
  o [PKT_SCHED]: In HTB, filters must be destroyed before the classes

Matthew Dharm:
  o USB storage: fix for jumpshot and datafab devices

Neil Brown:
  o Fix possible bio corruption with RAID5

Oliver Neukum:
  o USB: fix sleping in interrupt bug in auerswald driver
  o USB: fix race with signal delivery in usbfs

Pavlin Radoslavov:
  o [RTNETLINK]: Add RTPROT_XORP

René Scharfe:
  o HPFS: missing lock_kernel() in hpfs_readdir()

Tom Rini:
  o USB: mark the scanner driver as obsolete

Ulrich Drepper:
  o Fix 'noexec' behaviour



Related Links:

Would like to try, but is any distro 2.6 ready out-of-the-box?

December 18, 2003 - 6:07am
Anonymous

Yes, I know there is an article listing minimum versions of various tools for trying 2.6, but what I would like to know is this:

is any of the distros available on store shelves or as ISO images capable of booting with 2.6, without first downloading and compiling tons of other upgraded software?

Not quite - But almost

December 18, 2003 - 6:22am
Anonymous

Debian Sid (Unstable) is at the moment, more than ready enough for 2.6 :) When I first tried 2.6 (-test4), all the tools necessary was already new enough.

Slackware 9.1

December 18, 2003 - 6:47am
Anonymous

Slackware 9.1 is 2.6 ready, just download the kernel, compile and reboot. I've been using test 9 for sometime now, can't wait to use the official 2.6.0

Fedora

December 18, 2003 - 8:05am
Anonymous

Fedora Core 1 is 2.6 ready (I think) though modules.conf may need slight editing.

Mandrake

December 18, 2003 - 8:13am
Anonymous

Mandrake 9.2 is ready and cooker uses it

Not so ready, I guess

December 18, 2003 - 9:38am
Anonymous

After recompiling, it promptly crashed on me 10 minutes later. So much for done "when it's ready"...

2.6.0 Not so ready

December 18, 2003 - 9:49am
Anonymous

I'll not use 2.6 until the framebuGGer will be fixed!
And also i cannot compile mga_vid.o (mplayer matrox module).

Bye

The preemptivity issue

December 18, 2003 - 10:37am
Anonymous

I'm also stuck with the mga_vid module issue but what I was wondering now is if we can activate the preemptivity options now because it had been said that caused unstable behavior.

I'm using it with no problems

December 19, 2003 - 6:34am
Anonymous

I'm using it with no problems, no crashes with CONFIG_PREEMPPT so far.... though I haven't used it for very long

diy

January 20, 2004 - 5:45am
Anonymous

Gentoo

December 18, 2003 - 9:30pm

Gentoo is entirely happy running on a 2.6 kernel. I've been running it on 2.5/2.6 for 6 months or more.

- Antony Suter ("Exner")

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
speck-geostationary