Linus Torvalds announced the release of the 2.6.17 Linux kernel this past weekend, following the previous stable kernel release by three months [story]. He noted, "not a lot of changes since the last -rc, the bulk is actually some last-minute MIPS updates and s390 futex changes, the rest tend to be various very small fixes that trickled in over the last week. Have fun with it". The latest kernel source can be downloaded from your nearest Linux Kernel Archive mirror [story]. You can browse through all the changes using the gitweb interface.
From: Linus Torvalds [email blocked]
To: Linux Kernel Mailing List [email blocked]
Subject: Linux v2.6.17
Date: Sat, 17 Jun 2006 18:59:25 -0700 (PDT)
Not a lot of changes since the last -rc, the bulk is actually some
last-minute MIPS updates and s390 futex changes, the rest tend to be
various very small fixes that trickled in over the last week.
Have fun with it,
Linus
---
Aki M Nyrhinen:
[TCP]: continued: reno sacked_out count fix
Andrea Bittau:
[DCCP] Ackvec: fix soft lockup in ackvec handling code
Andrew Morton:
powernow-k8 crash workaround
PCI: fix pciehp compile issue when CONFIG_ACPI is not enabled
Andy Currid:
Fix HPET operation on 32-bit NVIDIA platforms
Fix HPET operation on 64-bit NVIDIA platforms
Arnd Bergmann:
powerpc: Fix cell blade detection
powerpc: Fix 64k pages on non-partitioned machines
powerpc: enable CPU_FTR_CI_LARGE_PAGE for cell
Auke Kok:
e1000: fix ethtool test irq alloc as "probe"
e1000: remove risky prefetch on next_skb->data
Benjamin Herrenschmidt:
powerpc: Fix call to ibm,client-architecture-support
Christoph Lameter:
typo in vmscan.c
Dave Jones:
PCI: Improve PCI config space writeback
David Howells:
Further alterations for memory barrier document
David S. Miller:
[SPARC64]: Dump local cpu registers in sun4v_log_error()
[TG3]: Handle Sun onboard tg3 chips more correctly.
[SPARC64]: Avoid JBUS errors on some Niagara systems.
[SPARC64]: Set appropriate max_cache_size.
[SPARC64]: Do not double-export sys_close() when CONFIG_SOLARIS_EMUL_MODULE
Jean Delvare:
PCI: Error handling on PCI device resume
Jens Axboe:
elevator switching race
debugfs inode leak
cfq-iosched: fix crash in do_div()
fix cdrom open
Fix missing ret assignment in __bio_map_user() error path
Kirill Korotaev:
Return error in case flock_lock_file failure
Krzysztof Helt:
[SPARC]: Migration cost tune up in sparc smp.
Lennert Buytenhek:
ep93xx build fix
Linus Torvalds:
[sky2] Fix sky2 network driver suspend/resume
Linux v2.6.17
Malcom Parsons:
fbcon: fix limited scroll in SCROLL_PAN_REDRAW mode
Mark Lord:
sata_mv: grab host lock inside eng_timeout
Markus Lidel:
I2O: Bugfixes to get I2O working again
Martin Schwidefsky:
s390: fix in-user atomic futex operation.
Matt Reimer:
[ARM] 3546/1: PATCH: subtle lost interrupts bug on i.MX
Michael Buesch:
bcm43xx: add DMA rx poll workaround to DMA4
Milton Miller:
powerpc: console_initcall ordering issues
Oleg Nesterov:
check_process_timers: fix possible lockup
run_posix_cpu_timers: remove a bogus BUG_ON()
arm_timer: remove a racy and obsolete PF_EXITING check
Paul Mackerras:
powerpc: Fix machine check problem on 32-bit kernels
Fix for the PPTP hangs that have been reported
Ralf Baechle:
Fix mempolicy.h build error
Randy Dunlap:
alpha: generic hweight build fix
Richard Purdie:
[ARM] 3547/1: PXA-OHCI: Allow platforms to specify a power budget
Robin H. Johnson:
tmpfs: time granularity fix for [acm]time going backwards
Russell King:
[ARM] Fix Neponset IRQ handling
[ARM] Fix Integrator and Versatile interrupt initialisation
Sergey Vlasov:
tmpfs: Decrement i_nlink correctly in shmem_rmdir()
Stephen Hemminger:
sky2: set_power_state should be void
sky2: don't hard code number of ports
sky2: fix hotplug detect during poll
sky2: save/restore base hardware irq during suspend/resume
sky2: stop/start hardware idle timer on suspend/resume
sky2: netconsole suspend/resume interaction
Tom "spot" Callaway:
[FUSION]: Fix mptspi.c build with CONFIG_PM not set.
Weidong:
[IPV4]: Increment ipInHdrErrors when TTL expires.
Yu, Luming:
PCI: reverse pci config space restore order
Documentation/serial/driver | 9
MAINTAINERS | 27 +
Makefile | 4
arch/alpha/kernel/alpha_ksyms.c | 1
arch/alpha/kernel/process.c | 6
arch/alpha/kernel/smp.c | 14 -
arch/alpha/kernel/sys_titan.c | 2
arch/arm/Kconfig.debug | 2
arch/arm/mach-ixp23xx/core.c | 18 +
arch/arm/mach-ixp4xx/Kconfig | 2
arch/arm/mach-pxa/mainstone.c | 1
arch/arm/mach-s3c2410/Kconfig | 2
arch/arm/mm/mm-armv.c | 4
arch/arm/mm/proc-xsc3.S | 3
arch/i386/kernel/acpi/boot.c | 8
arch/i386/kernel/syscall_table.S | 1
arch/i386/mach-generic/probe.c | 16 -
arch/mips/Kconfig | 96 ++--
arch/mips/au1000/common/irq.c | 1
arch/mips/au1000/common/prom.c | 24 -
arch/mips/au1000/common/sleeper.S | 5
arch/mips/au1000/common/time.c | 1
arch/mips/ddb5xxx/ddb5476/dbg_io.c | 2
arch/mips/ddb5xxx/ddb5477/kgdb_io.c | 2
arch/mips/gt64120/ev64120/serialGT.c | 2
arch/mips/gt64120/momenco_ocelot/dbg_io.c | 2
arch/mips/ite-boards/generic/dbg_io.c | 2
arch/mips/kernel/asm-offsets.c | 4
arch/mips/kernel/cpu-bugs64.c | 8
arch/mips/kernel/cpu-probe.c | 15 +
arch/mips/kernel/entry.S | 2
arch/mips/kernel/gdb-low.S | 8
arch/mips/kernel/module.c | 6
arch/mips/kernel/proc.c | 2
arch/mips/kernel/scall64-o32.S | 2
arch/mips/kernel/setup.c | 18 -
arch/mips/kernel/signal-common.h | 30 -
arch/mips/kernel/smp.c | 5
arch/mips/kernel/syscall.c | 27 -
arch/mips/kernel/traps.c | 20 +
arch/mips/kernel/vmlinux.lds.S | 20 -
arch/mips/math-emu/dp_fint.c | 4
arch/mips/math-emu/dp_flong.c | 4
arch/mips/math-emu/sp_fint.c | 4
arch/mips/math-emu/sp_flong.c | 4
arch/mips/mm/c-r4k.c | 78 +++
arch/mips/mm/init.c | 2
arch/mips/mm/pg-r4k.c | 1
arch/mips/mm/tlbex.c | 2
arch/mips/momentum/jaguar_atx/dbg_io.c | 2
arch/mips/momentum/ocelot_c/dbg_io.c | 2
arch/mips/momentum/ocelot_g/dbg_io.c | 2
arch/mips/oprofile/common.c | 9
arch/mips/oprofile/op_model_mipsxx.c | 34 +
arch/mips/oprofile/op_model_rm9000.c | 2
arch/mips/sgi-ip32/ip32-irq.c | 4
arch/powerpc/kernel/prom_init.c | 48 ++
arch/powerpc/platforms/powermac/low_i2c.c | 12
arch/powerpc/platforms/powermac/pfunc_core.c | 18 -
arch/powerpc/platforms/powermac/setup.c | 12
arch/ppc/kernel/asm-offsets.c | 2
arch/ppc/platforms/mpc8272ads_setup.c | 10
arch/ppc/syslib/pq2_devices.c | 16 -
arch/ppc/syslib/pq2_sys.c | 8
arch/s390/kernel/time.c | 2
arch/sparc64/kernel/head.S | 30 +
arch/sparc64/kernel/setup.c | 23 -
arch/sparc64/kernel/smp.c | 16 -
arch/sparc64/lib/checksum.S | 5
arch/sparc64/lib/csum_copy.S | 5
arch/um/Makefile-i386 | 4
arch/um/include/kern_util.h | 13 -
arch/um/kernel/time_kern.c | 10
arch/um/os-Linux/main.c | 2
arch/um/os-Linux/time.c | 10
arch/um/sys-i386/syscalls.c | 9
arch/um/sys-x86_64/signal.c | 24 +
arch/um/sys-x86_64/syscalls.c | 2
arch/x86_64/ia32/ia32_binfmt.c | 4
arch/x86_64/kernel/e820.c | 2
arch/x86_64/kernel/entry.S | 7
arch/x86_64/kernel/pci-dma.c | 4
arch/x86_64/kernel/pci-gart.c | 6
arch/x86_64/kernel/pmtimer.c | 2
arch/x86_64/kernel/setup.c | 2
arch/x86_64/mm/srat.c | 4
block/cfq-iosched.c | 77 ++-
drivers/base/power/suspend.c | 5
drivers/char/agp/Kconfig | 2
drivers/char/agp/amd64-agp.c | 3
drivers/char/agp/via-agp.c | 7
drivers/char/ipmi/ipmi_si_intf.c | 38 +
drivers/char/pcmcia/cm4000_cs.c | 2
drivers/char/tpm/tpm_bios.c | 89 +--
drivers/char/tpm/tpm_tis.c | 4
drivers/char/vt.c | 8
drivers/i2c/busses/scx200_acb.c | 2
drivers/ide/pci/sgiioc4.c | 16 -
drivers/ieee1394/sbp2.c | 2
drivers/infiniband/hw/mthca/mthca_srq.c | 41 +-
drivers/infiniband/ulp/ipoib/ipoib_ib.c | 1
drivers/input/joystick/sidewinder.c | 11
drivers/input/keyboard/corgikbd.c | 12
drivers/input/keyboard/spitzkbd.c | 12
drivers/input/misc/wistron_btns.c | 19 +
drivers/input/mouse/alps.c | 4
drivers/input/mouse/lifebook.c | 24 +
drivers/input/mouse/logips2pp.c | 6
drivers/input/touchscreen/ads7846.c | 53 +-
drivers/md/md.c | 15 +
drivers/message/fusion/mptbase.c | 27 +
drivers/mmc/Kconfig | 2
drivers/net/e1000/e1000_main.c | 10
drivers/net/forcedeth.c | 16 +
drivers/net/irda/Kconfig | 20 -
drivers/net/netconsole.c | 2
drivers/net/pcmcia/nmclan_cs.c | 2
drivers/net/pcnet32.c | 2
drivers/net/pppoe.c | 3
drivers/net/wireless/arlan-main.c | 4
drivers/net/wireless/wavelan.c | 2
drivers/pcmcia/ds.c | 6
drivers/rtc/rtc-m48t86.c | 72 +--
drivers/s390/cio/css.h | 4
drivers/s390/cio/device_fsm.c | 2
drivers/s390/net/ctcmain.c | 26 +
drivers/s390/net/ctctty.c | 10
drivers/s390/net/cu3088.c | 10
drivers/s390/net/iucv.c | 36 +
drivers/s390/net/iucv.h | 622 ++++++++++++------------
drivers/s390/net/lcs.c | 345 +++++++------
drivers/s390/net/lcs.h | 14 -
drivers/s390/net/netiucv.c | 36 +
drivers/s390/net/qeth.h | 18 -
drivers/s390/net/qeth_eddp.c | 18 -
drivers/s390/net/qeth_fs.h | 2
drivers/s390/net/qeth_main.c | 107 ++--
drivers/s390/net/qeth_mpc.h | 4
drivers/s390/net/qeth_proc.c | 8
drivers/s390/net/qeth_sys.c | 6
drivers/s390/net/qeth_tso.h | 4
drivers/scsi/libata-core.c | 1
drivers/scsi/ppa.c | 7
drivers/scsi/sata_sil24.c | 6
drivers/scsi/scsi_devinfo.c | 1
drivers/scsi/scsi_lib.c | 2
drivers/scsi/scsi_transport_sas.c | 4
drivers/serial/cpm_uart/cpm_uart_core.c | 8
drivers/serial/cpm_uart/cpm_uart_cpm2.c | 2
drivers/spi/spi_s3c24xx.c | 4
drivers/video/au1100fb.c | 21 +
drivers/video/console/fbcon.c | 2
drivers/video/maxinefb.c | 4
fs/affs/namei.c | 3
fs/cifs/CHANGES | 7
fs/cifs/cifsfs.h | 2
fs/cifs/cifsproto.h | 2
fs/cifs/cifssmb.c | 40 +-
fs/cifs/connect.c | 97 +++-
fs/cifs/file.c | 12
fs/ext3/resize.c | 1
fs/namei.c | 19 -
include/asm-alpha/smp.h | 4
include/asm-alpha/termbits.h | 1
include/asm-arm/arch-ixp23xx/memory.h | 2
include/asm-arm/arch-l7200/serial_l7200.h | 2
include/asm-arm/arch-l7200/uncompress.h | 2
include/asm-arm/system.h | 6
include/asm-generic/pgtable.h | 11
include/asm-mips/addrspace.h | 1
include/asm-mips/cpu.h | 6
include/asm-mips/delay.h | 22 -
include/asm-mips/futex.h | 141 ++++-
include/asm-mips/inst.h | 33 +
include/asm-mips/mipsregs.h | 2
include/asm-mips/page.h | 2
include/asm-mips/pgtable-32.h | 61 ++
include/asm-mips/pgtable-64.h | 13 -
include/asm-mips/pgtable.h | 103 ++--
include/asm-mips/sigcontext.h | 10
include/asm-mips/smp.h | 5
include/asm-mips/sparsemem.h | 14 +
include/asm-powerpc/termbits.h | 1
include/asm-s390/lowcore.h | 4
include/asm-sparc64/pgtable.h | 17 +
include/asm-um/irqflags.h | 6
include/asm-um/uaccess.h | 6
include/asm-x86_64/elf.h | 2
include/linux/input.h | 13 -
include/linux/m48t86.h | 4
include/linux/mmzone.h | 1
include/linux/pci_ids.h | 1
include/linux/vt_kern.h | 5
include/net/compat.h | 3
kernel/hrtimer.c | 6
mm/memory_hotplug.c | 8
mm/slab.c | 27 +
net/bridge/br_if.c | 19 -
net/core/dev.c | 20 -
net/ethernet/Makefile | 1
net/ethernet/sysctl_net_ether.c | 14 -
net/ipv4/netfilter/Kconfig | 4
net/ipv4/netfilter/ip_conntrack_core.c | 1
net/ipv4/netfilter/ip_conntrack_helper_pptp.c | 4
net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c | 1
net/ipv4/tcp_highspeed.c | 3
net/ipv4/tcp_output.c | 12
net/ipv6/route.c | 16 -
net/irda/irlap.c | 3
net/sysctl_net.c | 8
security/selinux/hooks.c | 6
211 files changed, 2151 insertions(+), 1534 deletions(-)
From: Linus Torvalds [email blocked]
Subject: Re: Linux v2.6.17
Date: Sat, 17 Jun 2006 19:06:17 -0700 (PDT)
On Sat, 17 Jun 2006, Linus Torvalds wrote:
>
> Not a lot of changes since the last -rc, the bulk is actually some
> last-minute MIPS updates and s390 futex changes, the rest tend to be
> various very small fixes that trickled in over the last week.
Btw, one thing that I was planning to ask people - does anybody find the
full-format ChangeLog's that I produce at all useful?
You can get the exact same information directly from git, and the full
changelog (as opposed to the shortlog) tends to be pretty rough to read,
so I suspect that most people who do want to delve into the details are
actually much more likely to look it up using git instead (at which point
you can obviously get much better information - graphical history, diffs,
etc)
I'm not going to stop doing the incremental shortlogs, since those are
easy to read and I usually post them with the release announcement unless
they end up being too large (usually -rc1 has a _lot_ of changes as a
result of the merge window), but I'm just wondering if anybody finds the
full logs useful at all?
They're easy for me to generate, but if nobody uses them, I don't see much
of a point..
Linus
Users space implications of new kernel?
IMHO kerneltrap.org posts too little informations about the new
kernels, like - what is the difference for regular user?
Is it faster on desktop? Lower latency in sounds (especially in wine?)
Better support for 16 bitcode (dosemu)?
What important drivers are added, what problems where solved?
your answer is at the changel
your answer is at the changelog in kernelnewbies wiki.
a link
Here's a link.
sd_mod 2.6.17
Anyone notice SCSI sd_mod not working, it will not modprobe and says something about FAT option "flush" unknown.
Roadmap
Hi all. I'm looking for kernel definitions in Linux 2.6, but I cannot find anything.
Is there any kind of roadmap in Linux kernel ??? When will 2.6 be more "stable" (in sense of increase bug fixes/new features) ? Linux 2.6 interface is frozen ? Will be?
[]'s
Rodrigo
Use a vendor kernel
If you want stability, use a vendor kernel.
Roadmap
Here is the roadmap:
"We are here, we are going wherever it takes us"
Here is the stability document:
"It is as stable as it's ever going to get and we are not going to freeze it"
Runaway Train
Con Kolivas
Your first setence looks like runaway train lyrics:
"Runaway train never going back
Wrong way on a one way track
Seems like I should be getting somewhere
Somehow I'm neither here no there
(...)
I can go where no one else can go
I know what no one else knows
Here I am just drownin' in the rain
With a ticket for a runaway train "
What are next targets for Linux kernel?
What could we expect for next releases? And, in medium horizon, is there any thing that developers are looking for?
Best regards,
Rodrigo
Ask your distro vendor!
(First, if I never hear that song again it'll be too soon. Don't do that again. I'll forgive you this time. :-) )
I don't think the kernel developers are really interested in flag day "Stable Release" releases any more. (I don't think they ever really were, but they did try to maintain the fiction.) Rather, they seem to prefer to develop at a continuous pace and let vendors fork and stabilize their own kernels on whatever schedules suit the particular distribution. So the question of "When's the next stable release" really depends on what distro you're running, and not at all on Linus and co.
This works great with most distros, such as RedHat, Debian, etc. that pick a kernel, backport security fixes, add their own out-of-tree patches (well, at least RH does), etc.
It doesn't suit folks who want to run the latest and greated Linus kernel. Some distros, such as Slackware, have historically always stuck to the Linus kernel. (Dunno if that's changed.) Those distros may wish to rethink their policy now that Linus' policy's changed.
This change also affects those of us using other distros, but who wish to run Linus' Linux kernel. (I was previously in that camp.) But the fact of the matter is, running the Linus kernel has always been a tad hit-or-miss. The latest shift in development style just has pushed that to the forefront, with Linus and co. saying "We're not going to try to be end-user friendly any more."
Partially
I only partially agree with you. Since Linus has moved to the system of feature freeze at rc1 followed by bugfixes till stable release, the quality and stability of vanilla kernels has improved vastly to the point that end users can rely on them.
You're right, I overstated it.
Actually, yeah, it hasn't been too bad, I'll admit. At the same time, it's not "stable" in the sense that, say, Debian users consider stable. Judging by the magnitude that "y" is getting to in 2.6.x.y these days, I'd say that indicates that there's still a fair number of caveats in a 2.6.x.0 kernel.
For the bulk of the kernel, you're 100% right though. It's just the features added in the last one or two sub-versions that are perhaps the more "exciting" to try to use, judging by the commentary I see here and on places like LWN.
I guess if, when 2.6.x comes out, you go for the highest 2.6.(x-1).y you can find and don't need cutting-edge features added between 2.6.(x-2) and 2.6.(x-1), you'll be doing pretty good as far as stable mainline kernels go.
Still about roadmaps
Thank you very much for your attention. But I´m sorry. I guess my question were not clear. When, I ask about stability, I´d like to know about kernel interfaces (headers stability). IMHO, interfaces are contracts, and a forward incompatibility break could damage a whole system. Anyway, I guess this lesser important question.
My main question is about roadmaps. Why Linux Kernel cannot have a roadmap (and product planning) like
Eclipse and Firefox?
If it can, where is?
[]´s
Hmm
I'm reminded of the Charlton Heston movie where he's painting the Sistine Chapel. "When will you make an end", he is asked. His reply? "When I'm finished"
New features go in when they've had proper testing and are agreed to be decently bug-free. Usually new things are marked EXPERIMENTAL so that people know what pieces are new to the kernel. This also means that since new features are added to a kernel that's already decently stable (as opposed to a development kernel with lots of other new features), that the bugs can be found and fixed more quickly. The end result? Features come faster, and they stabilize faster.
Flag day releases slow down development by at least 2x. People doing bug audits haven't seen an appreciable defect rate rise in 2.6 compared to other kernels.
Anyway, for people who don't want the latest features. You can just sit on the 2.6.16 kernel, since that one has been signaled to be maintained for a while past 2.6.18. (Past the usual 2.6.16.x releases)