login
Search
Linus Torvalds announced the release of the 2.6.13 Linux kernel. "The most painful part of 2.6.13 is likely to be the fact that we made x86 use the generic PCI bus setup code for assigning unassigned resources," Linus began. "That uncovered rather a lot of nasty small details, but should also mean that a lot of laptops in particular should be able to discover PCI devices behind bridges that the BIOS hasn't set up." He went on to note, "we've hopefully fixed up all the problems that the longish -rc series showed, and it shouldn't be that painful, but if you have device problems, please make a report that at a minimum contains the unified diff of the output of 'lspci -vvx' running on 2.6.12 vs 2.6.13. That might give us some clues."
During the 2005 Linux Kernel Developer's Summit it was decided that all major changes need to be merged within two weeks of a major release, giving the rest of the development cycle to fixing bugs [story]. Linus implied that the deadline would be pushed out a week this cycle, "I'm actually going to be away for most of next week, but in general we should now try to do all major merges within the first two weeks of the release. After that, we go into calm-down mode, and if you have work that didn't make the cut, you get to wait until 2.6.14." He also noted that going forward this should mean that major releases happen more frequently. You can download the latest kernel from your nearest Linux Kernel Archive mirror [story], and browse through all the changes using the 2.6 kernel's gitweb interface.
From: Linus Torvalds [email blocked] To: Linux Kernel Mailing List [email blocked] Subject: Linux 2.6.13 Date: Sun, 28 Aug 2005 17:17:29 -0700 (PDT) There it is. The most painful part of 2.6.13 is likely to be the fact that we made x86 use the generic PCI bus setup code for assigning unassigned resources. That uncovered rather a lot of nasty small details, but should also mean that a lot of laptops in particular should be able to discover PCI devices behind bridges that the BIOS hasn't set up. We've hopefully fixed up all the problems that the longish -rc series showed, and it shouldn't be that painful, but if you have device problems, please make a report that at a minimum contains the unified diff of the output of "lspci -vvx" running on 2.6.12 vs 2.6.13. That might give us some clues. The changes since -rc7 are pretty small, full shortlog and diffstat of that appended. As to the new world order: I'm actually going to be away for most of next week, but in general we should now try to do all major merges within the first two weeks of the release. After that, we go into calm-down mode, and if you have work that didn't make the cut, you get to wait until 2.6.14. The plan is that this should bring in the time between releases, so that even stuff that misses the deadline won't have to wait _too_ long for the next one. Linus ---- Al Viro: bogus iounmap() in emac bogus function type in qdio late spinlock initialization in ieee1394/ohci mmaper_kern.c fixes [buffer overruns] Alexey Dobriyan: drivers/hwmon/*: kfree() correct pointers zfcp: fix compilation due to rports changes Andi Kleen: x86_64: update defconfig - reenable fusion x86_64: Tell VM about holes in nodes Andreas Herrmann: zfcp: add rports to enable scsi_add_device to work again Andreas Schwab: m68k: fix broken macros causing compile errors Anton Blanchard: ppc64: Fix issue with gcc 4.0 compiled kernels Benjamin Herrenschmidt: ppc64: Export machine_power_off for therm_pm72 module Deepak Saxena: arm: fix IXP4xx flash resource range Eric W. Biederman: acpi_shutdown: Only prepare for power off on power_off Heiko Carstens: zfcp: bugfix and compile fixes James Bottomley: Fix oops in sysfs_hash_and_remove_file() James Morris: Fix capifs bug in initialization error path. Jan Blunck: sg.c: fix a memory leak in devices seq_file implementation Jean Delvare: hwmon: Off-by-one error in fscpos driver Jens Axboe: cfq-iosched.c: minor fixes John McCutchan: Document idr_get_new_above() semantics, update inotify Keith Owens: Export pcibios_bus_to_resource Linus Torvalds: Only pre-allocate 256 bytes of cardbio IO range Ignore disabled ROM resources at setup Merge HEAD from master.kernel.org:/.../davem/net-2.6.git Merge refs/heads/upstream-fixes from master.kernel.org:/.../jgarzik/netdev-2.6 Linux v2.6.13 Marcelo Tosatti: ppc32 8xx: fix m8xx_ide_init() #ifdef Mark M. Hoffman: I2C hwmon: kfree fixes Michael Chan: [TG3]: Fix ethtool loopback test lockup NeilBrown: md: create a MODULE_ALIAS for md corresponding to its block major number. md: clear the 'recovery' flags when starting an md array. Paolo 'Blaisorblade' Giarrusso: Fixup symlink function pointers for hppfs [for 2.6.13] hppfs: fix symlink error path Patrick Boettcher: fix for race problem in DVB USB drivers (dibusb) Patrick McHardy: [FIB_TRIE]: Don't ignore negative results from fib_semantic_match Paul Jackson: cpu_exclusive sched domains build fix undo partial cpu_exclusive sched domain disabling completely disable cpu_exclusive sched domain Paul Mackerras: Remove race between con_open and con_close Ralf Baechle: 6pack Timer initialization Fix 6pack setting of MAC address Roland Dreier: IB: fix use-after-free in user verbs cleanup Steve French: Fix oops in fs/locks.c on close of file with pending locks ---- Makefile | 2 + arch/arm/mach-ixp4xx/coyote-setup.c | 2 + arch/arm/mach-ixp4xx/gtwx5715-setup.c | 2 + arch/arm/mach-ixp4xx/ixdp425-setup.c | 2 + arch/ia64/pci/pci.c | 1 + arch/ppc/syslib/m8xx_setup.c | 2 + arch/ppc64/kernel/setup.c | 2 + arch/sparc64/kernel/pci.c | 1 + arch/um/drivers/mmapper_kern.c | 41 ++++++----------------------- arch/x86_64/defconfig | 21 +++++++++------ arch/x86_64/kernel/e820.c | 34 ++++++++++++++++++++++++ arch/x86_64/mm/init.c | 16 ++++++++--- arch/x86_64/mm/numa.c | 8 +++++- drivers/acpi/sleep/poweroff.c | 6 ++++ drivers/block/cfq-iosched.c | 31 +++++++++++++++------- drivers/char/vt.c | 2 + drivers/hwmon/adm1026.c | 4 +-- drivers/hwmon/adm1031.c | 4 +-- drivers/hwmon/adm9240.c | 2 + drivers/hwmon/fscpos.c | 2 + drivers/hwmon/smsc47b397.c | 2 + drivers/hwmon/smsc47m1.c | 2 + drivers/ieee1394/ohci1394.c | 8 +++++- drivers/infiniband/core/uverbs_main.c | 3 +- drivers/isdn/capi/capifs.c | 4 ++- drivers/md/md.c | 2 + drivers/media/dvb/dvb-usb/dibusb-common.c | 19 ++++++++++--- drivers/media/dvb/dvb-usb/dvb-usb-dvb.c | 5 ++-- drivers/net/hamradio/6pack.c | 9 ++---- drivers/net/ibm_emac/ibm_emac_core.c | 2 + drivers/net/tg3.c | 6 +--- drivers/pci/setup-bus.c | 2 + drivers/pci/setup-res.c | 4 ++- drivers/s390/cio/qdio.c | 2 + drivers/s390/scsi/zfcp_aux.c | 28 ++++---------------- drivers/s390/scsi/zfcp_ccw.c | 10 +++++++ drivers/s390/scsi/zfcp_def.h | 2 + drivers/s390/scsi/zfcp_erp.c | 25 ++++++++++++++++-- drivers/s390/scsi/zfcp_ext.h | 2 + drivers/s390/scsi/zfcp_fsf.c | 1 + drivers/s390/scsi/zfcp_scsi.c | 25 ++++++++++++++---- drivers/s390/scsi/zfcp_sysfs_port.c | 2 - drivers/scsi/sg.c | 13 ++++----- fs/cifs/file.c | 2 + fs/hppfs/hppfs_kern.c | 30 ++++++++------------- fs/inotify.c | 2 + fs/sysfs/inode.c | 4 +++ include/asm-m68k/page.h | 6 ++-- include/asm-ppc64/bug.h | 7 +++-- include/asm-x86_64/e820.h | 2 + kernel/cpuset.c | 30 +++++++++------------ lib/idr.c | 2 + net/ipv4/fib_trie.c | 14 +++++----- 53 files changed, 277 insertions(+), 185 deletions(-)
So...
What's going to be next month's policy for kernel development? Perhaps we should start a pool.
What's so wrong about tweaking a process?
It's been well over a year since it was desided not to open 2.7 but continue 2.6 after a new model. Since then the process has been tweaked a little (once?, twice?) and what's wrong with that?
Kernel development is not static, code changes, people change, the world around us changes. The kernel development model needs to keep up. When something is found to be sub-optimal it is discarded and something else is tried instead.
I find it odd that I see a lot of people whining about the development process and the changes being made to it, both here and on other websites and mailing lists. The funny thing about it is that you very rarely hear kernel developers (you know, the people actually affected by this stuff) complaining - actually quite the opposite in many cases.
Right. And Debian should learn too?
You are right about everything you said - especially the bit about people who don't take part in the development process complaining about it.
As a side note, I have a growing feeling that Debian might benefit from adopting such a process - e.g.
1. port over to GCC 4.x, fix bugs, release
2. upgrade X11, fix bugs, release
3. upgrade Gnome & KDE, fix bugs, release
4. upgrade versions of all the smaller packages, fix bugs, release
And so on and so forth.
Instead, Debian seems to try to do it all at once and therefore the release cycle is so painfully slow.
(who was is that coined the term "release often, release early"? Was it in "The Cathedral and the Bazaar"?)
Err, Debian is slow to releas
Err, Debian is slow to release for other reasons, like creating a Debian installer that should works for 11 (12?) architectures and who knows how many HW permutations...
Well
Its about the only distribution which installs on 11 or 12 architectures. I certainly don't know another one. While we have zillions for x86. Its nice to have something familiar when you install Linux on a non-x86 architecture. Not only familiar, its almost the same!
Well
What about using Gentoo then? It compiles to heaps of architectures and YOU decide what and when you will update.
Want the latest kernel? Fine, go for it
Want to recompile everything with GCC4, well, you have rocks in your head, but OK, we'll let you.
Don't want to waste space on Gnome, but want to run enlightenment instead? OK, you may have poor taste but who are we to stop you.
This whole waiting for Debian argument is pointless.
How exactly is this so incred
How exactly is this so incredibly difficult? OpenBSD installs on a comparable number of architectures and maintains a 6-month release cycle.
s/Open/Net/ , right?
s/Open/Net/ , right?
no, fool
No, he meant what he said.
From http://openbsd.org/plat.html, I see 16 platforms.
From http://openbsd.org/goals.html,
"Make a CDROM-based release approximately every six months..."
not a good idea...
I write kernel code and I don't think redoing PCI in the middle of a release is a good idea. This is major kernel version material. Not a little thing you do in between minor releases. This is typical for linux kernel development though which is not exactly known for trying to achieve quality. This'll be tweaked for the next year or so; can't wait to drop this onto my production machine.
"wait until 2.6.14" ?? surely
"wait until 2.6.14" ?? surely this should be 2.6.15 ?
he probably meant "you have t
he probably meant "you have to wait until .14 happened and then you have the chance for another two weeks to get your stuff merged"
Why did x86 have it own PCI c
Why did x86 have it own PCI code to start with?
Don't know the history, but I'll venture a guess
There were a number of subsystems in Linux that showed up for x86 first that were written specifically to the PC way of doing things. Later, more general versions were written for the various other architectures that started adopting PC technologies. For instance, came to PCs first and later showed up on Alpha, SPARC and PPC boxes, amongst other things.
I'm willing to bet that that's the case here with PCI. It appears the x86 PCI code started life as part of the BIOS interfacing code. Since there's more eyeballs on the x86 stuff and there's a huge variety of quirky, I'm guessing it was easier to maintain its PCI code as x86-specific than bend it to meet the needs of the other platforms as Linux got ported. Of course, as PCI matured and got more complicated, at some point this argument no longer held up.
In contrast, it appears the other platforms may've started with their own PCI kludges, but ended up merging them together to lower the overall burden.
Just my Scientific Wild Arsed Guess.
"""For instance, came to PCs
"""For instance, came to PCs first and later showed up on Alpha, SPARC and PPC boxes, amongst other things."""
I think you lost a subject there... :/
Well looky there.
Well looky there: It's a typo! At least the meaning was clear.
"""At least the meaning was c
"""At least the meaning was clear."""
Actually, no. I still don't know what came to PC first.
PCI.
PCI.
Thank you. Guess I'm thick, b
Thank you. Guess I'm thick, but it really wasn't clear to me.
locks.c patch from 2.6.9
Is this patch ever going to make it into 2.6 proper?
http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0902.html
I've been running it on 2.6.12.4 to fix system crashes under heavy load with mod_python & apache2 blocking on many file locks (they are used for global mutex implementation provded by libapr and connection serialization in apache2)
it has so far successfully fixed the problem.
> Is this patch ever going to
> Is this patch ever going to make it into 2.6 proper?
> http://www.ussg.iu.edu/hypermail/linux/kernel/0409.2/0902.html
It would probably stand a better chance if you asked that on LKML instead of here.
Submit / re-send it to lkml (don't forget to include relevant people on CC) and include a description of your experience with it - that might get things moving - talking about it here sure won't.
What about Reiser4 filesystem.
So.. why was Reiser4 not included this time?
What are the reasons for not including it?
And... What are the problems that have to be solved before it can be included in kernel?
Re: What about Reiser4 filesystem.
Reiser4 still needs 8Kb kernel stacks.
There's still some controversy over some Reiser4 features.
Reiser4 has not been in -mm /that/ long, it needs more testing.
People who are desperate to use it can run a -mm kernel and help test it.
Why does Reiser4 need 8Kb kernel stacks before being merged?
Thanks for reply, but...:
Why does Reiser4 need 8Kb kernel stacks before being merged?
What are the main controversy issues?
Reiser's stacks need to go on a diet.
The kernel is moving from 8K kernel stacks to 4K kernel stacks by default on x86, to reduce the number of "order 1" (two consecutive page) allocations.
Reiser4 still has too large of a stack footprint on some paths to work with 4K kernel stacks. This needs to be fixed if it's going to get merged into mainline.
Please merge Reiser4
I' have been playing with reiser4 with external patch's from -mm and the ones from namesys, and it's extremely stable (i have been doing heavy loads ) please merge it! don't wait for Linux 2.7 for that!
Marco
Tested 2.6.13, is painfully slow
I tested 2.6.13 on my productive server.
I've compiled it with the same .config like 2.6.12.6.
The only exception was that I've changed MHZ to 100 (I think that default in 2.6 kernels was 1000).
The new 2.6.13 kernel wasn't good for me. Load increased dramatically (for times worse, 40 instead of 10). I don't know if my problem was caused by these HZ, nevertheless there's something strange...
I recomment to stay with 2.6.12.6 untill this is resolved.
Kernel 2.6.13 Unstable
Agreed. I gave 2.6.13 and 2.6.13.1 a chance for a few days and tons of problems arose, even on a very very generic Intel 82801 chipset. Seems that the HZ changes increased latency signifigantly and some drivers have broken. I recommend 2.6.12.6 until the team hits an even number, then try it again. The naming convention for kernels is a bit strange, so I can promise an even release say 2.6.14, will be any better. I´m hoping that Andrew M and Linus T fix the 160 or so reported bugs soon.
2.6.12 has problems too
2.6.12 panics when doing massive "connect()"s over bluetooth while 2.6.10 and 2.6.13 don't. By massive I mean this: after 3 consecutive connects with no delay between them (program calls connect then exits then it's called again - repeat forever), kernel stalls for 20 seconds and then dies with a panic (NULL pointer). This happens for latest 2.6.12 too.
Agreed
I thought that I had messed something up until I started reading these posts. I'm going to downgrade tonight. This is killing my productivity.