Kernel Traffic #254 by Zack Brown
[email protected] Sat, 20 Mar 2004 08:27:08 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <[email protected]> |
Kernel Traffic #254 For 19 Mar
By Zack Brown
"Recent research, however, suggests that there is a possibility that this
gradual global warming could lead to a relatively abrupt slowing of the ocean's
thermohaline conveyor, which could lead to harsher winter weather conditions,
sharply reduced soil moisture, and more intense winds in certain regions that
currently provide a significant fraction of the world's food production. With
inadequate preparation, the result could be a significant drop in the human
carrying capacity of the Earth's environment." -- Secret Pentagon Report to the
White House (dod-climate.pdf) (See Google News (http://news.google.com/news?num
=100&hl=en&ie=UTF-8&oe=UTF-8&q=pentagon+climate&btnG=Search+News) )
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 27 Jan - 11 Feb (25 Gathering All KGDB Implementations Together
posts)
2. 4 Feb - 15 Feb (8 Status Of Building IPV4 As A Loadable Module
posts)
3. 9 Feb - 13 Feb (25 Linux 2.6.3-rc1-mm1 Released; Huge ISDN Patch
posts) Problematic For Inclusion
4. 9 Feb - 13 Feb (24 Linux 2.6.3-rc2 Released
posts)
5. 11 Feb (1 CVS Repository For KGDB At SourceForge
post)
6. 11 Feb - 14 Feb (2 Status Of Copy-On-Write Filesystem
posts)
7. 11 Feb - 13 Feb (15 BitMover Considering ReiserFS For bkbits
posts) Server
8. 11 Feb - 13 Feb (4 Linux 2.4.25-rc2 Released
posts)
9. 11 Feb - 13 Feb (8 Module Debugging And Documentation
posts)
10. 11 Feb - 12 Feb (8 Support For The PowerMac G5 In 2.6
posts)
11. 11 Feb - 13 Feb (3 RadeonFB Update
posts)
12. 12 Feb - 18 Feb (33 Linux 2.6.3-rc2-mm1 Released
posts)
13. 12 Feb - 17 Feb (44 CodingStyle Documentation Update
posts)
14. 12 Feb (2 udev 017 Released
posts)
15. 12 Feb - 13 Feb (2 New kernbench Benchmark To measure CPU
posts) Throughput
16. 13 Feb (1 UML Update 2.6.3-rc2-1
post)
17. 14 Feb - 16 Feb (12 fbdev Patches Too Big And Buggy For
posts) Acceptance; Patch Submission Policy
18. 14 Feb - 17 Feb (34 Linux 2.6.3-rc3 Released
posts)
19. 15 Feb (2 PlatinumFB Driver Updated
posts)
20. 16 Feb - 17 Feb (10 Linux 2.6.3-rc3-mm1 Released
posts)
21. 16 Feb (1 Linux 2.4.25-rc3 Released
post)
22. 16 Feb (1 KDB 4.3 Released For Linux 2.6.3-rc3
post)
23. 16 Feb - 18 Feb (27 Linux 2.6.3-rc4 Released
posts)
24. 16 Feb (1 KDB 4.3 Released For Linux 2.6.3-rc4
post)
25. 17 Feb - 18 Feb (10 Some Progress On KGDB
posts)
26. 18 Feb (1 Linux 2.4.25 Released
post)
27. 18 Feb (1 ftape No Longer A Removable Module
post)
28. 18 Feb (9 Local Root Exploit Found In 2.4 And 2.6;
posts) Upgrade Recommended
29. 18 Feb (7 Netlink-Based Notifications For SELinux Kernel
posts) Events
30. 18 Feb (1 KDB 4.3 Released For Linux 2.4.25
post)
Mailing List Stats For This Week
We looked at 1893 posts in 9249K.
There were 557 different contributors. 266 posted more than once. 220 posted
last week too.
The top posters of the week were:
* 69 posts in 434K by Benjamin Herrenschmidt
* 60 posts in 242K by Andrew Morton
* 47 posts in 242K by Greg KH
* 36 posts in 439K by Tom Rini
* 31 posts in 118K by Linus Torvalds
* Full Stats
1. Gathering All KGDB Implementations Together
27 Jan - 11 Feb (25 posts) Archive Link: "BitKeeper repo for KGDB"
Topics: FS: devfs, Networking, Version Control
People: Tom Rini, Sam Ravnborg, Dave Jones, Pavel Machek, Chris Wright
Tom Rini said:
Since I've been talking with George off-list about trying to merge the
various versions of KGDB around, and I just read the thread between Andy
and Jim about conflicting on KGDB work, I've put up a BitKeeper repository
(If anyone here won't / can't use BitKeeper, I'll happily move over to a
repo someone else sets up in something else.) to try and coordinate things.
What's in there right now is Amit's kgdb 2.1.0, without the ethernet patch.
There's also all of the changes for PPC and for generic stuffs that I've
been doing of late.
What I'll be doing shortly (this afternoon even) is to change from a struct
of function pointers, for the arch specific functions, into a set of
provided, weak, variants and then allow arches to override as needed.
What I'd like is for someone to move the ethernet bits from the -mm tree
into here, and for people to merge the fixes / enhancements that're in
their per-arch stubs in the -mm tree into the split design that Amit's
version has.
Sam Ravnborg suggested that Tom "ask Dave Jones if he can take nightly
snapshots - as he does for sparse and udev." And Dave Jones said, "Hmm, reminds
me, the scripts to make those snapshots broke when I migrated to the new box.
I'll go fix them up. But yeah, sure. If you want me to add them to the snapshot
list, just mail me the bk: url and I'll add it."
Elsewhere, Chris Wright also asked for the BitKeeper URL, and Tom gave it as
bk://ppc.bkbits.net/linux-2.6-kgdb. Dave replied, "daily diffs vs mainline
generated at.. http://www.codemonkey.org.uk/projects/bitkeeper/kgdb"
Elsewhere, Pavel Machek and others started hacking on the code, and at some
point Tom summarized his own work:
here's the highlights of what I've done so far:
[email protected], 2004-01-30 11:14:44-07:00, [email protected]
Lots of changes to the serial stub driver.
In sum, it's got many of the features (but not all) of George
Anzginer's version (+ fix or two), and fully flushed out and tested
support for SERIAL_IOMEM.
[email protected], 2004-01-30 11:10:03-07:00, [email protected]
Change *kgdb_serial into kgdb_serial_driver. We will now have
only one serial driver.
[email protected], 2004-01-30 10:44:55-07:00, [email protected]
Convert the kgdb ethernet driver over to netpoll.
Patch from Pavel Machek <[email protected]>, who warns this probably
doesn't work.
[email protected], 2004-01-29 14:30:47-07:00, [email protected]
Move all KGDB questions into kernel/Kconfig.kgdb.
[email protected], 2004-01-27 16:59:06-07:00, [email protected]
- PPC32: Add KGDB support for PRePs (part of MULTIPLATFORM).
- PPC32: Add a choice of baud rate for the gen550 backend.
[email protected], 2004-01-27 14:44:54-07:00, [email protected]
Remove the function pointers from kgdb_ops.
Most have become kgdb_foo, instead of foo. The exceptions
are the gdb/kgdb register fiddling functions.
kgdb_gdb_regs_to_regs makes my head hurt.
[email protected], 2004-01-27 11:46:13-07:00, [email protected]
Merge by hand to current 2.6 bk.
--- UNTESTED, x86_64 might be broken ---
[email protected], 2004-01-27 11:32:54-07:00, [email protected]
- Send a 'T' packet initially, not an 'S' followed by 'p'
- On PPC32, try to pass in the correct signal back.
I'm mostly happy with the serial changes (and I'll set aside the user
console bits from George's version for now), but comments and criticisms
would be welcome. And as a reminder the BitKeeper version is bk://
ppc.bkbits.net/linux-2.6-kgdb and there's snapshots (thanks Dave!) at http:
//www.codemonkey.org.uk/projects/bitkeeper/kgdb
2. Status Of Building IPV4 As A Loadable Module
4 Feb - 15 Feb (8 posts) Archive Link: "IPV4 as module?"
Topics: Disks: IDE, Networking
People: Andrey Borzenkov, Jan-Benedict Glaw
Andrey Borzenkov asked if there were "Any technical reaon IPV4 cannot be built
as module? Current kernel barely fits on floopy (even with IDE as module);
factoring out IPV4 would allow to reduce size even more." Jan-Benedict Glaw
replied that this would be very difficult to accomplish; but there was no
discussion of this, and the conversation skewed off into why anyone would use a
floppy as opposed to a CD in the first place; and the thread petered out.
3. Linux 2.6.3-rc1-mm1 Released; Huge ISDN Patch Problematic For Inclusion
9 Feb - 13 Feb (25 posts) Archive Link: "2.6.3-rc1-mm1"
Topics: Access Control Lists, FS: NFS, Hot-Plugging, Networking, Version
Control
People: Andrew Morton, Stian Jordet, Bill Davidsen, Karsten Keil, Dominik Kubla
, Trond Myklebust, Kai Germaschewski, Linus Torvalds
Andrew Morton announced 2.6.3-rc1-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc1/
2.6.3-rc1-mm1/
+ NFSD update
+ MD update
+ Added Randy's include/linux/syscalls.h work, to address a pet peeve.
+ Various fixes
+ Added early printk for ia32. It simply does #include "x86_64's
version".
+ I'll probably drop the CPU hotplug patches next time. They've been
tested and they now appear to be obsolete.
+ Unless suddenly persuaded otherwise I shall also drop the enhanced ia32
CPU-type selection patches (retaining pentium-M support). Sorry Adrian,
but they do not seem to have sufficient value, given the general
intrusiveness and patch footprint.
Stian Jordet begged him to include Karstein Keil's large ISDN patch (ftp://
ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6) , but Andrew said:
Boggle. That thing is 1.8MB.
163 files changed, 25877 insertions(+), 22424 deletions(-)
This is the first time that anyone told me that it even existed. How on
earth could a patch to a major subsystem grow to such a size in such
isolation? When we're at kernel version 2.6.3!
How mature is this code? What is its testing status? What is the size of
its user base? Is it available as individual, changelogged patches?
It would be crazy to simply shut our eyes and slam something of this
magnitude into the tree. And it is totally unreasonable to expect
interested parties to be able to review and understand it.
Could someone please tell me how this situation came about, and what we can
do to prevent any reoccurrence?
Stian replied:
I don't know more than this:
http://marc.theaimsgroup.com/?l=linux-kernel&m=107523583528989&w=2
But I _do_ know that ISDN is non-working for me with 2.6.x kernels without
this patch.
Bill Davidsen also said to Andrew:
We've had this discussion before, haven't we? And all the solutions seemed
to involve not having just one person approve things, which isn't likely to
change. I don't recall seeing WHEN it was sent to Linus, but clearly
something working in 2.4 and not in 2.6 probably shouldn't wait years for
2.8.
I guess the real question is how invasive it is, this isn't the first time
I've heard that 2.6 ISDN doesn't work, so it's not as if putting it in -mm
would break ISDN, the question is how many other things are touched and
might break.
At least it seems to have been widely tested, and is based on something
which is in a stable kernel. A maintainer's lot is not a happy one, and you
have my sympathy.
Maybe leave it in -mm for a bit and not promote it until people have a
chance to really beat on it?
Karsten Keil also replied to Andrew, taking responsible for sending the patch
only to Linus Torvalds and not Andrew. He quoted an email he had sent to Linus
two weeks before, in late January:
here is a really big patch for ISDN in kernel 2.6. The reason for this big
patch is, that I give up to fix the bugs in the new implementation of the
obsolate (but currently most used) I4L code. Here are too much changes that
never work in this code and since the authors of the new implementations
don't have time (here was no real effort since half an year) I started a
new port of the well working and stable 2.4 I4L code to 2.6.
Note: The new port is only for the old I4L part, which is common used up to
now, not for the new CAPI like interface, which got a new design in 2.5 and
should become the successor of I4L, but here are only few cards with CAPI
drivers at the moment. This will change soon, but since all distributions
depend on the old I4L stuff at the moment, here is a strong need to have a
working I4L part in the kernel now. Since new year I got ~500 mails dialing
with ISDN problems and kernel 2.6.
This stuff is well tested on my equipment (~40 different cards) and also
tested by few other people.
The diff is against the current patch-2.6.2-rc1-bk3 version and should
apply clean.
He also now offered some more history of the patch:
Kai Germaschewski was maintaining the ISDN code in 2.4/2.5 and did a big
redesign in all parts in 2.5, to prepare ISDN4Linux for the CAPI interface,
which should make the I4L interface obsolate (CAPI Common ISDN API, is a
common standard for ISDN application), my job was to develop a CAPI
hardware driver for passive cards as a replacement of hisax, this is known
now as mISDN driver (modular ISDN driver), but this driver supports only
few of the cards which are supported by hisax at the moment.
Kai did a good job, but he changed also lot of the old (coming obsolate)
code in incompatible ways and his changes never were complete and tested in
practice, also not from himself, his changes were only academic, because he
left Germany to a study in US and in US he had never access to ISDN. I was
aware that he is in US, but I was to stupid to recognise this missing ISDN
problem, I thought he had some NI1 line in US too. Since also I was too
busy to play with his 2.5/2.6 stuff last year and also nobody else did (I
got only compiling fixes during 2.5/6) we run into this situation. After
first 2.6 versions came out I got many reports about ISDN and 2.6 issues in
last august. Since then I tried to fix the code and get a partial working
version in october??, but as I had more time during XMas I did lot of
regression test and run into lot of problems with the new code, and even
fixing some of these bring up a bundle of new problems. So I ask all
remaining I4l developers for help, but nobody take care/has time.
So I make a proposal to start a new 2.4 -> 2.6 port of the old I4L
interface, since I know the 2.4 code very well (since most of the driver
code is from me) and 2.4 ISDN is known as very stable and has got also some
certification from telecomunication authorities.
Nobody of the other I4L developers complain and the result was this patch.
I was preparing new patch last days against current 2.6 version but since I
got ill last weekend, it is not finished yet, but hopefully during next
houres. I have also BitKeeper running here with a clone of the linux-2.5
tree, so if you prefer a bk diff I can also prepare one (but note, I'm a BK
beginner).
Andrew replied, "let's find a way in which I can obtain the latest version and
also be kept up to date with any fixes." Karsten replied:
Here are the latest versions, since they are so big only as reference:
Linus tree:
ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6/i4l-2.6.3-rc1-bk2.gz
Andrew tree:
ftp://ftp.isdn4linux.de/pub/isdn4linux/kernel/v2.6/i4l-2.6.3-rc1-mm1.gz
The result of both patches are the same source, but in Andrews tree some
smaller fixes were already included, to avoid rejects I created patches for
both trees.
ChangeLog:
+ new port of 2.4 I4L core to 2.6
+ new port of 2.4 I$L HiSax to 2.6
+ fixes for I4L CAPI subsystem to make it stable in 2.6
+ fix parameter handling of AVM ISA cards (calle)
+ cleanup ISDN config variables
These patches are in sync with I4L cvs (kernel 2.6 branch).
Elsewhere, Dominik Kubla responded to Andrew's initial announcement, saying:
How about including the NFSACL patch from acl.bestbits.at? One reason for
people to move to 2.6 from 2.4 is that they no longer need to patch the
kernel to get ACL support. Unless they want to have ACL support over NFSv3
that is... NFSACL support is quite an argument for Linux in an existing
Solaris production environments, so i would like to see it included into
the mainstream kernel ASAP (Note: I am not speaking for Andreas and the
other people working on the ACL code!). Including it into -mm would give it
the necessary exposure.
The patch is available in broken up form at:
http://acl.bestbits.at/current/diff/nfsacl-2.6.1-0.8.67.tar.gz
And before somebody mentions NFSv4: This is not (yet) an option for
production environments.
Andrew Morton said that this patch would have to go through the NFS developers
and Trond Myklebust in order to get into his tree.
4. Linux 2.6.3-rc2 Released
9 Feb - 13 Feb (24 posts) Archive Link: "Linux 2.6.3-rc2"
Topics: FS: NFS, FS: XFS, Hot-Plugging, Power Management: ACPI, USB
People: Linus Torvalds
Linus Torvalds announced 2.6.3-rc2, saying:
Uhhuh. There was a bit more pending, so here's a -rc2. Now please calm
down, I'd like this to have some time to stabilize..
The rc1->rc2 changes are mostly driver side stuff: PnP update, USB, ACPI,
IRDA, i2c, hotplug-PCI and netdrivers etc. But there's a NFSv4 update and
soem XFS fixes there too.
And some ARM and sparc updates.
5. CVS Repository For KGDB At SourceForge
11 Feb (1 post) Archive Link: "CVS repository for kgdb"
Topics: Version Control
People: Amit S. Kale
Amit S. Kale announced:
I have setup a cvs repository for kgdb at sourceforge. Those who plan to
contribute to kgdb on a regular basis, feel free become add yourself as
developers to this project and checkin changes yourself.
Here is cvs access information for users of kgdb:
kgdb project page includes instructions for accessing kgdb cvs tree. Here
is a quick download guide for users of kgdb.
cvs -d:pserver:[email protected]:/cvsroot/kgdb login
cvs -z3 -d:pserver:[email protected]:/cvsroot/kgdb co .
These instructions will fetch latest kgdb development version in current
directory. The directory kgdb-2 contains kgdb for 2.6 kernels. For further
updates, go to the same directory and run cvs update
6. Status Of Copy-On-Write Filesystem
11 Feb - 14 Feb (2 posts) Archive Link: "status of copy-on-write filesystem?"
People: Chris Friesen, Herbert Poetzl
Chris Friesen asked:
I'm doing some work where it would simplify things greatly to have
copy-on-write semantics available.
I've seen overlayfs and the proposed "-union" option for mount, but there
doesn't seem to be anything thats really ready for serious use.
Am I missing something? Is someone working on this?
And Herbert Poetzl replied:
http://vserver.13thfloor.at/TBVFS
no active work atm, but some info/links maybe
7. BitMover Considering ReiserFS For bkbits Server
11 Feb - 13 Feb (15 posts) Archive Link: "reiserfs for bkbits.net?"
Topics: FS: ReiserFS, Version Control
People: Erik Hensema, Tomas Szepe, Nikita Danilov, Larry McVoy
Larry McVoy was considering using ReiserFS for bkbits, the server that hosts
the Linux kernel BitKeeper tree, among others; and asked if anyone knew of any
reasons against ReiserFS. Erik Hensema replied, "If bitkeeper uses lots of
small files and/or many files in a directory, then reiserfs is the FS for you.
The FS has been stable for a while now and I currently don't see any reason not
to use it." Tomas Szepe added:
During the last two years, we have deployed some 400+ linux firewall
machines, all of which use reiserfs 3.6 for all of their filesystems. While
some of these boxes live in very wild environments (attics, cellars, under
the bed, in public block-of-flats corridors, ...) and we've seen hardware
die, there have been zero filesystem problems. I think I can say we're
happy with how reiser3 has fared so far.
Sounds a bit like from your favorite marketing department, but still I
thought you might want to know.
Elsewhere, Nikita Danilov of the ReiserFS team remarked that "concurrent bk
clone of kernel repositories is very good file system stress tool that we are
using while debugging reiser4."
No one had anything to say against ReiserFS.
8. Linux 2.4.25-rc2 Released
11 Feb - 13 Feb (4 posts) Archive Link: "Linux 2.4.25-rc2"
Topics: Power Management: ACPI
People: Marcelo Tosatti
Marcelo Tosatti announced 2.4.25-rc2, saying:
Here goes -rc2, with small number of fixes and corrections.
Most notably acpi4asus and toshiba ACPI updates.
9. Module Debugging And Documentation
11 Feb - 13 Feb (8 posts) Archive Link: "[PATCH] Shut up about the damn
modules already..."
Topics: Networking
People: Rusty Russell, Alex Goddard, Bas Mevissen, Russell King, Rik van Riel
Rusty Russell posted a patch, saying:
Please apply before 2.6.3.
In almost all distributions, the kernel asks for modules which don't exist,
such as "net-pf-10" or whatever. Changing "modprobe -q" to "succeed" in
this case is hacky and breaks some setups, and also we want to know if it
failed for the fallback code for old aliases in fs/char_dev.c, for example.
Just remove the debugging message which fill people's logs: the correct way
of debugging module problems is something like this:
echo '#! /bin/sh' > /tmp/modprobe
echo 'echo "$@" >> /tmp/modprobe.log' >> /tmp/modprobe
echo 'exec /sbin/modprobe "$@"' >> /tmp/modprobe
chmod a+x /tmp/modprobe
echo /tmp/modprobe > /proc/sys/kernel/modprobe
Rik van Riel suggested putting this in the documentation directory, and Alex
Goddard replied:
I couldn't think of, or find a good place to put this, so I put the
information in it's own file. I'm only moderately sure I've generated the
patch correctly. However, it does apply with patch -p1 to a clean
2.6.3-rc2-bk2 tree, so it should be fine.
The wording is a slightly changed version of what Rusty said at the start
of this thread.
Elsewhere, Bas Mevissen asked, "I'm wondering why it is that the kernel is
asking for non-existing modules so often. Is it that userspace applications try
to access all kinds of devices too often (autoprobing) or it this (wanted)
kernel behaviour?" Russell King replied:
Userspace probes the kernel to see if IPv6 is available by trying to create
an IPv6 socket.
The correct solution is to fix /etc/modprobe.conf such that it doesn't try
to load the module when you don't have it configured:
install net-pf-10 /bin/true
Note that if you alias net-pf-10 to ipv6 before this install line, you need
to replace net-pf-10 with ipv6 in the install line.
PS, I notice Arjan's RPM packages don't seem to contain the modprobe.conf
manual page... maybe this is what's causing some of the confusion?
PPS, It might also help to either mention in the man page that the above
corresponds to the original "alias modulename off" _or_ add "install off /
bin/true" into modprobe.conf.dist such that the old alias line works as
expected.
10. Support For The PowerMac G5 In 2.6
11 Feb - 12 Feb (8 posts) Archive Link: "PPC64 PowerMac G5 support available"
People: Benjamin Herrenschmidt, Linus Torvalds
Benjamin Herrenschmidt announced a patch to support the PowerMac G5, saying:
If Andrew prefers keeping it into -mm for a while, I can do a big patch
from the bk tree, though this patch is putting other ppc64 stuffs on hold
for now, so it shall go in asap (as it would be too nasty to deal with
conflicts if other things went in at this point).
Linus: you will probably need an updated radeonfb anyway as I told you.
I'll start working on it now and will post a patch separately.
Also, there is currently a known build problem with the zImage wrapper in
2.6.3-rc2, unrelated to this patch, it doesn't prevent the build of the
plain vmlinux which is what yaboot uses on the G5.
Finally, ieee1394 triggers an oops in kobject since 2.6.3-rc2, 100%
reproduceable for me (and apparently x86 users too), so that's also
unrelated to the G5 code.
Linus Torvalds pulled the code into his tree, adding, "I didn't realize that
the whole aty/radeon driver was new. Regardless, the bits above look obvious
enough, and I'll take the new radeon driver too once it's ready." But shortly
after that he posted again, saying:
Actually, at least for me, the _old_ radeon driver works without any
modifications at all in text mode. Rock stable image, unlike the new one
that needed the clock fixes.
But trying to start X hangs the system hard, which may well be an issue
with the old radeonfb. Whenever you have a new driver, I will test.
11. RadeonFB Update
11 Feb - 13 Feb (3 posts) Archive Link: "[PATCH] New radeonfb"
Topics: FS: sysfs, Framebuffer
People: Benjamin Herrenschmidt, James Simmons
Benjamin Herrenschmidt announced:
Here is the new radeonfb. It doesn't remove the old one, just in case,
though CONFIG_FB_RADEON now builds the new one.
I also had to add an empty fb_set_suspend() function to fbmem.c (the real
implementation is in James tree and will be here soon). That means that
Power Management on Apple laptops isn't completely right yet until the core
fbdev fixes get in, but that's probably enough for 2.6.3.
The patch is too big to put in the email text uncompressed, so here it is
as a bzip2 attachment.
James: The version in your tree is good too, when merging your stuff, you
should ignore the few radeonfb diffs and let me deal with them.
Linus: This new driver uses framebuffer_alloc/release, so if you back out
the fb sysfs patch, make sure to replace it with wrapper functions that
just kmalloc/kfree
James Simmons replied, "No need to back out the sysfs patch since I have new
patches coming for the drivers. I just finished out how to deal with non pci
devices."
12. Linux 2.6.3-rc2-mm1 Released
12 Feb - 18 Feb (33 posts) Archive Link: "2.6.3-rc2-mm1"
Topics: Big Memory Support, Networking
People: Andrew Morton, Mark Haverkamp, Anton Blanchard, Nick Piggin, James
Morris, Zwane Mwaikambo
Andrew Morton announced 2.6.3-rc2-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc2/
2.6.3-rc2-mm1/
+ Added the big ISDN update
+ Device Mapper update
About an hour later he replied to himself, saying, "This kernel and also
2.6.3-rc1-mm1 have a nasty bug which causes current->preempt_count to be
decremented by one on each hard IRQ. It manifests as a BUG() in the slab code
early in boot. Disabling CONFIG_DEBUG_SPINLOCK_SLEEP will fix this up. Do not
use this feature on ia32, for it is bust." Anton Blanchard wanted to know who
wrote that patch, and how it broke ia32. Andrew said he (Andrew) had written it
himself, and that he didn't quite know how it broke ia32. He said, "I spent a
couple of hours debugging the darn thing, then gave up and used binary search
to find the offending patch." Zwane Mwaikambo found a way to trigger the bug
using a particular compilation configuration, and Anton guessed that this might
actually be his (Anton's) own fault after all.
Nick Piggin said that neither this kernel nor the previous one would boot on
his NUMAQ maching. Zwane Mwaikambo confirmed seeing this problem, as did Mark
Haverkamp, who added that for him, "The problem went away when I backed out the
highmem-equals-user-friendliness.patch" . Nick confirmed that this fix worked
for him as well, and Andrew also said, "Thanks for working that out. James
Morris reports that the same patch causes initrd-with-highmem failures. Having
enough bugs to care for, I guess I'll drop it."
13. CodingStyle Documentation Update
12 Feb - 17 Feb (44 posts) Archive Link: "PATCH, RFC: 2.6 Documentation/
Codingstyle"
People: Michael Frank, Giuliano Pochini, Andrew Morton, David Weinehall,
Andries Brouwer
Michael Frank posted an update to the CodingStyle document, which describes the
proper appearance and structure that developers should use when adding code to
the kernel. Among the changes, there was one allowing 'dont' and 'cant' in
kernel comments. Tim Bird and others objected that this made kernel developers
appear illiterate, but there was no real discussion on the issue. However, in
the next iteration of the document, among other changes Michael took out the
part allowing 'dont' and 'cant', and replaced it with, "Kernel developers like
to be seen as literate. Do mind the spelling of kernel messages to make a good
impression. Do not use crippled words like "dont" and use "do not" or "don't"
instead." There was no argument.
Another portion of the document stated that 80 character line-lengths was a
hard limit and should not be violated. Giuliano Pochini said of this, "I think
this requirement is a bit silly IMHO. How many of us do usually code in a 80x25
terminal screen nowadays?" But Andrew Morton replied:
"I think the 90x25 requirement is silly"
"I think the 100x25 requirement is silly"
And so it goes. You get into an xterm arms race wherein everyone has to
make their terminal as wide as the widest guy so anyone can get any work
done.
Yes, 80 cols sucks and the world would be a better place had CodingStyle
mandated 96 columns five years ago. But it didn't happen.
David Weinehall, Andries Brouwer and others also remarked that they did still
use 80-column screen sizes.
Michael posted a couple more iterations of the document, and eventually
conversation petered out peacefully.
14. udev 017 Released
12 Feb (2 posts) Archive Link: "[ANNOUNCE] udev 017 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, Version Control
People: Greg KH, Chris Friesen
Greg KH said:
I've released the 017 version of udev. It can be found at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017.tar.gz (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-017.tar.gz)
rpms built against Red Hat FC1 are available at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.i386.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.i386.rpm)
with the source rpm at:
kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.src.rpm (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev-017-1.src.rpm)
udev allows users to have a dynamic /dev and provides the ability to have
persistent device names. It uses sysfs and /sbin/hotplug and runs entirely
in userspace. It requires a 2.6 kernel with CONFIG_HOTPLUG enabled to run.
Please see the udev FAQ for any questions about it:
kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ (http://www.kernel.org/
pub/linux/utils/kernel/hotplug/udev-FAQ)
For any udev vs devfs questions anyone might have, please see:
kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs (http://
www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs)
Major changes from the 015 version:
+ lots of udevd and udevsend cleanups and tweaks. udevd can now be built
with klibc, and doesn't need a lock file anymore to work.
+ lots of bug fixes and other cleanups.
+ shrink the size of the database by a large amount.
In all, there is nothing major in this release, but any current users of
udev will want this version for all of the bugfixes if for nothing else.
Thanks a lot to Chris Friesen and Kay Sievers for cleaning up the udevd and
udevsend communication path and code so much. I really appreciate it.
Thanks also to everyone who has send me patches for this release, a full
list of everyone, and their changes is below.
udev development is done in a BitKeeper repository located at:
bk://linuxusb.bkbits.net/udev
Daily snapshots of udev from the BitKeeper tree can be found at:
http://www.codemonkey.org.uk/projects/bitkeeper/udev/
If anyone ever wants a tarball of the current bk tree, just email me.
15. New kernbench Benchmark To measure CPU Throughput
12 Feb - 13 Feb (2 posts) Archive Link: "[ANNOUNCE] kernbench-0.20"
Topics: SMP
People: Con Kolivas, Cliff White, Martin J. Bligh
Con Kolivas announced
Martin J. Bligh has for some time been producing results of a benchmark he
devised called "kernbench" which is designed to measure cpu throughput,
with emphasis on SMP systems.
I set out to make this benchmark a portable and easy to use script for
anyone with adequate hardware to perform kernbench, after some feedback
from MJB. All the SMP work currently underway inspired this. So here is the
first public release:
http://ck.kolivas.org/kernbench/
What it does:
It runs the venerable kernel compile a number of different ways: It cleans
and primes a kernel tree with a make defconfig. Then it reads all the
kernel source to cache it in ram. Then it will perform a number of
different kernel compiles after a warmup run compile the same as the one it
is about to test. Then it times the following runs 5 times:
half load: make -j (NR_CPUS/2)
optimal load: make -j (NR_CPUS*4)
maximum load: make -j
Optionally it can also perform a single threaded make, the number of jobs
for optimal can be defined, the number of runs can be defined, and any of
the default runs can be disabled.
Then it will print out an average of each of the loads with some useful
statistics. A sample from an IBM X440 8x1.5Ghz P4HT on linux-2.6.3-rc2
follows:
Average Single Threaded Run:
Elapsed Time 1069.65
User Time 965.894
System Time 117.856
Percent CPU 101
Context Switches 6223.2
Sleeps 23056.4
Average Half Load Run:
Elapsed Time 120.808
User Time 802.428
System Time 92.072
Percent CPU 740
Context Switches 10613.6
Sleeps 26667
Average Optimum Load Run:
Elapsed Time 81.59
User Time 1007.89
System Time 112.36
Percent CPU 1372.6
Context Switches 63006.2
Sleeps 40406
Average Maximum Load Run:
Elapsed Time 82.944
User Time 1012.33
System Time 122.424
Percent CPU 1367.6
Context Switches 44822.2
Sleeps 22161
A few points:
Do not try to run the maximum load on a machine with less than 2Gb ram, as
swap thrashing is likely, so the benchmark will not be a cpu throughput one
but a vm benchmark (of course you may want to do this too).
It is best run on a non-journalled filesystem to minimise the effects of
the journal write-out; although this is probably not greatly important.
If run on a 4x box, the half load will be make -j2. The problem with
compiling a kernel at make -j2 is that usually only one job spawns so the
results may not be very useful.
Cliff if you want to wrap this into an OSDL benchmark, it may be worthwhile
profiling each group of runs together and using the -s option by default as
a separate "kernbench-long" to include the single threaded runs.
Thanks, Martin for the idea and feedback. Thanks osdl for the hardware for
development, and others for code help.
Cliff White replied, "Thanks! We'll get it into STP asap."
16. UML Update 2.6.3-rc2-1
13 Feb (1 post) Archive Link: "uml-patch-2.6.3-rc2-1"
Topics: User-Mode Linux
People: Jeff Dike
Jeff Dike said:
This patch updates UML to 2.6.3-rc2. This breaks with my usual practice of
ignoring test patches. However, when I updated my UML tree, I had forgotten
that my stock Linus tree was up to 2.6.3-rc2. I took this as a sign from a
higher power that this was Meant To Be.
As well as catching up, there are some bug fixes and cleanups -
modules should now work
worked around a process start time bug
fixed a bug which caused ps to divide by zero
The 2.6.3-rc2-1 UML patch is available at
http://www.user-mode-linux.org/mirror/uml-patch-2.6.3-rc2-1.bz2
BK users can pull my 2.5 repository from
http://www.user-mode-linux.org:5000/uml-2.5
For the other UML mirrors and other downloads, see
http://user-mode-linux.sourceforge.net/dl-sf.html
Other links of interest:
The UML project home page : http://user-mode-linux.sourceforge.net
The UML Community site : http://usermodelinux.org
17. fbdev Patches Too Big And Buggy For Acceptance; Patch Submission Policy
14 Feb - 16 Feb (12 posts) Archive Link: "[PATCH] back out fbdev sysfs
support"
Topics: FS: sysfs, Framebuffer, Version Control
People: Christoph Hellwig, Linus Torvalds, Alexander Viro
Christoph Hellwig said:
this patch backs out James' sysfs support for fbdev again. It introduces a
big, race for every driver not converted to framebuffer_{alloc,release}
(that is every driver but Ben's new radeonfb).
I've left in framebuffer_{alloc,release} as stubs so drivers can be
converted to it gradually and once all drivers are done it can be enabled
again.
<rant>
James, what about pushing the 2GB worth of fbdev driver fixes in your tree
to Linus so people actually get working fb support again instead of adding
new holes? A maintainers job can't be to apply patches to his personal CVS
repository and sitting on them forever
</rant>
Linus Torvalds replied:
at this point I WOULD NOT EVEN TAKE IT ANY MORE.
That's just how I work: if somebody maintains his own tree and builds up a
lot of patches, that's _his_ problem. I'm not going to replace things
totally unless there is some really fundamental reason I would have to. And
quite frankly, the most common "fundamental reason" is that the maintainer
has not done his job.
I want controlled patches that do one thing at a time. Not a 2GB untested
dump.
He went on:
These things need to be done in a timely fashion, incrementally, one thing
at a time. Anything else does not work.
And btw, for anybody who is impacted by this: you are encouraged to help.
If you have a machine that works with some out-of-tree code but does _not_
work with the in-tree code, send a patch that fixes JUST THAT BUG.
Because if James can't trickle them in, somebody else will have to. That's
what happened with the new radeon driver.
Alexander Viro offered to help split the patches up into small, clean chunks.
There was a small flurry of activity, and the thread petered out.
18. Linux 2.6.3-rc3 Released
14 Feb - 17 Feb (34 posts) Archive Link: "Linux 2.6.3-rc3"
Topics: Power Management: ACPI
People: Linus Torvalds
Linus Torvalds announced 2.6.3-rc3, saying:
More merges, although most of them are architecture updates. IA64, ppc32/
64, SuperH and ARM.
But also some cpufreq, watchdog and ACPI updates.
19. PlatinumFB Driver Updated
15 Feb (2 posts) Archive Link: "[PATCH] Update platinumfb driver"
Topics: Framebuffer
People: Benjamin Herrenschmidt
Benjamin Herrenschmidt said:
This patch updates the PowerMac-only platinumfb driver to use the new
mac-io device infrastructure. It also switch allocation to the new
framebuffer_alloc/release and fix a couple of bugs.
I finally found the old hardware to really test it so please apply :)
20. Linux 2.6.3-rc3-mm1 Released
16 Feb - 17 Feb (10 posts) Archive Link: "2.6.3-rc3-mm1"
Topics: Hot-Plugging
People: Andrew Morton, Bill Davidsen
Andrew Morton announced 2.6.3-rc3-mm1, saying:
ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.3-rc3/
2.6.3-rc3-mm1/
+ New hotplug CPU implementation from Rusty
+ Dropped the x86 CPU-type selection patches
+ Added support for dynamic allocation of unix98 ptys.
Regarding why the x86 CPU-type selection patches were dropped, Bill Davidsen
asked, "Was there a problem with this? Seems like a good start to allow
cleaning up some "but I don't have that CPU" things which embedded and tiny
systems really would like to eliminate." Andrew replied, "I think it was a good
change, and was appropriate to 2.5.x. But for 2.6.x the benefit didn't seem to
justify the depth of the change." Bill asked if 2.7 would be an appropriate
place to pick it up again, but this question went unanswered.
21. Linux 2.4.25-rc3 Released
16 Feb (1 post) Archive Link: "Linux 2.4.25-rc3"
People: Marcelo Tosatti
Marcelo Tosatti announced 2.4.25-rc3, saying:
Here goes the third 2.4.25 release candidate.
This release includes a few important net fixes, amongst others.
22. KDB 4.3 Released For Linux 2.6.3-rc3
16 Feb (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel
2.6.3-rc3"
People: Keith Owens, Jim Houston
Keith Owens announced:
ftp://oss.sgi.com/projects/kdb/download/v4.3/
With many thanks to Jim Houston and Xavier Bru.
Current versions are :
kdb-v4.3-2.6.3-rc3-common-1.bz2
kdb-v4.3-2.6.3-rc3-i386-1.bz2
kdb-v4.3-2.6.3-rc3-ia64-1.bz2
Warning: the 2.6 versions of kdb have had minimal testing. In particular
they have not been tested with CONFIG_PREEMPT.
23. Linux 2.6.3-rc4 Released
16 Feb - 18 Feb (27 posts) Archive Link: "Linux 2.6.3-rc4"
Topics: Disks: IDE
People: Linus Torvalds
Linus Torvalds announced Linux 2.6.3-rc4, saying:
I'm planning on doing the final 2.6.3 tomorrow, so please test this final
-rc.
Most notably, this should support ppc/ppc64 out-of-the-box, complete with
G5 support (64-bit). Special thanks to BenH who made sure the new radeonfb
driver works on a wide variety of hardware (a number of the fixes here
relative to -rc3 was making sure the driver works on regular x86 laptops).
Apart from the radeon updates, there's some IDE oops fixes (and cleanups),
and a SELinux update.
And yes, document the fact that sparc is no longer f*cked up (both atomics
and irq save/restore now work the way they always did everywhere else).
24. KDB 4.3 Released For Linux 2.6.3-rc4
16 Feb (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel
2.6.3-rc4"
People: Keith Owens
Keith Owens announced:
ftp://oss.sgi.com/projects/kdb/download/v4.3/
Current versions are :
kdb-v4.3-2.6.3-rc4-common-1.bz2
kdb-v4.3-2.6.3-rc3-i386-1.bz2
kdb-v4.3-2.6.3-rc3-ia64-1.bz2
The arch specific i386 and ia64 patches have not changed between rc3 and
rc4. Use the arch rc3 patches with rc4-common-1.
Warning: the 2.6 versions of kdb have had minimal testing. In particular
they have not been tested with CONFIG_PREEMPT.
25. Some Progress On KGDB
17 Feb - 18 Feb (10 posts) Archive Link: "[PATCH][0/6] A different KGDB stub"
Topics: Networking
People: Tom Rini, Pavel Machek, Amit S. Kale
Tom Rini said:
The following is my next attempt at a different KGDB stub for your tree
(and then hopefully into kernel.org). This is against 2.6.3-rc4 +
bk-netdev-rc3 (from your tree), and nothing else. This has been tested on
PPC32 (KGDB=y/n) and i386 (KGDB=y and allmodconfig) and not at all on
x86_64 (no time to build a toolchain yet). Since the last time, I've done
the following:
+ SysRq-G is always part of SYSRQ && KGDB.
+ choice for I/O (8250 serial, kgdboe and PPC 'simple' serial, for now).
+ On x86_64 / PPC32, we don't bother with CHK_DEBUGGER, but instead
always use the arch provided debugger hooks.
Thre are 6 different patches:
core.patch: All of the non-arch specific bits, that aren't drivers.
8250.patch: The i/o driver for KGDB, via a standard PC uart.
kgdboe.patch: The i/o driver for KGDB, via netpoll.
i386.patch: The i386-specific code, tested.
ppc32.patch: The ppc32-specific code, tested.
x86_64.patch: The x86_64-specific bits, untested.
One last note. For some reason, kgdboe isn't working for me right now. But
it doesn't look like it's something specific to the kgdboe driver (Dropping
in the -mm one and changing names to match still shows it, and the serial
driver is solid) so I'm not sure if it's anything other than my bad luck
today. So if nothing else, if someone else could give this a shot and let
me know if it works for them...
Andrew asked if everyone agreed on this patch, and Pavel Machek replied, "It is
based on Amit's version, so I think answer is "yes". I certainly like this
one." But Amit S. Kale said:
I don't agree. I did a few more cleanups after Andi expressed concerns over
globals kgdb_memerr and debugger_memerr_expected.
I liked Pavel's approach. Let's first get a minimal kgdb stub into mainline
kernel. Even this much is going to involve some effort. We can merge other
features later.
Let's create a cvs tree at kgdb.sourceforge.net for kgdb components to be
pushed int mainline kernel. This split is to keep current kgdb unaffected.
People who are already using it won't be affected.
May I suggest we breakup this task into following tasklets. I have expanded
item 1 because Pavel has something that's already close. The rest of the
items can be discussed in detail later. These need not be done in this
order except for first 2 whose sequence is fixed.
1. A minimal kgdb stub
core.patch:
kgdbstub.c full.
No changes to module.c
No changes for CONFIG_KGDB_THREAD
No changes to calling convention of do_IRQ (Needs to be done)
CONFIG_KGDB_CONSOLE removed i386.patch
No changes for CONFIG_KGDB_THREAD
No manipulation of kernel stack before entry into do_IRQ
No non-source level CFI directives.
2. Minimal x86_64.patch
3. Patch to sync ppc kgdb with arch independent stub
4. Patch to sync other architecture kgdbs with arch independent stub on
help from maintainers of those architectures.
5. KGDB_CONSOLE patch
This is a must for embedded boards that have only one serial port
6. gdb automatic module loading
7. CONFIG_KGDB_THREAD patch
This may or may not be a separate config option. This patch will
include x86_64 support required to enable threads.
8. i386 thread support
9. Ethernet interface based on netconsole
10. ... Any other features
Tom, Pavel and Andrew had various technical comments, and they started hashing
out the details.
26. Linux 2.4.25 Released
18 Feb (1 post) Archive Link: "linux-2.4.25 released"
People: Marcelo Tosatti
Marcelo Tosatti announced:
final:
- 2.4.25-rc4 was released as 2.4.25 with no changes.
27. ftape No Longer A Removable Module
18 Feb (1 post) Archive Link: "[PATCH] mark ftape un-removable"
People: Christoph Hellwig
Christoph Hellwig said:
I've just grepped over the tree for reamining MOD_INC_USE_COUNT users, and
ftape is a really horrible one, it relies on MOD_{INC,DEV}_USE_COUNT in the
most horrible places + it's own bookkepping and the <= 2.4 may unload
hooks. And although I don't have the hardware I can guarantee it doesn't
work as expected.
So let's just remove the module_exit handler and mark it unremovable, if
someone wants to fix up ftape later it's fine with me, but it's a really
scary driver..
28. Local Root Exploit Found In 2.4 And 2.6; Upgrade Recommended
18 Feb (9 posts) Archive Link: "New do_mremap vulnerabitily."
People: Raphael Rigo, Ulrich Keil, Linus Torvalds, Chris Friesen
Raphael Rigo said:
Since it seems nobody posted it yet (at least I hope so) :
http://www.isec.pl/vulnerabilities/isec-0014-mremap-unmap.txt
It is a local root exploit.
Ulrich Keil replied:
There was also a Proof-of-concept exploit released:
http://www.derkeiler.com/Mailing-Lists/Securiteam/2004-02/0052.html
Linus Torvalds said, "Fixed in 2.6.3 and 2.4.25 (and, I think, vendor kernels),
please upgrade if you allow local shell access to untrusted users." Chris
Friesen pointed out:
There is still a call to do_munmap() that does not check the return code,
called from move_vma(), which in turn is called in do_mremap().
Can that call ever fail and cause Bad Things to happen?
Linus replied, "Yes it can fail, and no, bad things can't happen. We could
return the error code to user space, but on the other hand, by the time the
munmap fails we would already have done 90% of the mremap(), so it doesn't much
help user space to know that the old area still has a vma, but no pages
associated with it."
29. Netlink-Based Notifications For SELinux Kernel Events
18 Feb (7 posts) Archive Link: "[SELINUX] Event notifications via Netlink"
People: James Morris, David S. Miller
James Morris said:
This patch against 2.6.3 implements Netlink based notifications for SELinux
kernel events. This will allow SELinux userspace components to maintain
synchronization with kernel state.
For example, a userspace AVC (Access Vector Cache, the component that makes
access control decisions) is being implemented for use by Security Enhanced
X and SE-DBUS. These applications will request access control decisions
from the usersapce AVC, which will relay and cache decisions from the
kernel AVC.
When the security policy is reloaded or the enforcing mode is changed in
the kernel, the userspace AVC can be notified and take appropriate action
(e.g. flush cache).
After some technical discussion and fixes, David S. Miller accepted the patch.
30. KDB 4.3 Released For Linux 2.4.25
18 Feb (1 post) Archive Link: "Announce: kdb v4.3 is available for kernel
2.4.25"
People: Keith Owens
Keith Owens said:
KDB (Linux Kernel Debugger) has been updated.
ftp://oss.sgi.com/projects/kdb/download/v4.3/
Current versions are :
kdb-v4.3-2.4.25-common-1.bz2
kdb-v4.3-2.4.25-i386-1.bz2
kdb-v4.3-2.4.25-ia64-040218-1.bz2
The ia64 patch has changed slightly since kdb-v4.3-2.4.25-rc1, due to more
clean ups in the base arch/ia64/kernel/mca.c file. Apart from that, the
only changes are to the target kernel name in the change logs.
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this
site are copyright their original authors, and distributed under the terms of
the GNU General Public License, version 2.0.