Kernel Traffic #207 by Zack Brown
[email protected] Sun, 02 Mar 2003 18:17:55 -0800
| Newsgroups | gmane.linux.kernel.kernel-traffic |
|---|---|
| Message-ID | <E18pfWd-0005DD-00@renegade> |
Kernel Traffic #207 For 2 Mar
By Zack Brown
Table Of Contents
* Standard Format
* Text Format
* XML Source
* Mailing List Stats For This Week
* Threads Covered
1. 17 Feb - 27 Feb (94 Linux 2.5.62 Released
posts)
2. 18 Feb - 19 Feb (9 Configuration Option For All SCSI Low-Level
posts) Drivers
3. 18 Feb - 19 Feb (4 Configuration Option For All Ethernet
posts) 1000Mbit NICs
4. 18 Feb - 19 Feb (6 Kernel Panics In Morse Code
posts)
5. 18 Feb - 21 Feb (3 Kernel Errata List
posts)
6. 19 Feb (1 post) Accessing BitKeeper Without BitKeeper
7. 19 Feb (1 post) Documentation For The Kernel Bug Database
8. 19 Feb (1 post) IPMI Driver Version 18 Released
9. 20 Feb (1 post) FUSE (Filesystem In Userspace) 1.0 Released
10. 20 Feb - 24 Feb (28 /proc Reorganization And Speedup
posts)
11. 20 Feb (3 Status Of 8x AGP Support
posts)
12. 20 Feb - 24 Feb (13 Consolidating Multiple ioctl Handler Code
posts)
13. 20 Feb - 21 Feb (3 Status Of SpeedTouch USB Modem Driver
posts)
14. 20 Feb - 21 Feb (23 Some Users Unhappy With Kernel Code Written
posts) Under NDA
15. 23 Feb - 26 Feb (18 Kernel 2.5.62-mm3 Released
posts)
16. 24 Feb (3 NTFS 2.1.1a For 2.4 Released
posts)
17. 24 Feb (1 post) Possible Violation Of GPL
18. 24 Feb (1 post) Free Driver Petition
19. 24 Feb - 25 Feb (11 Mailing List Statistics
posts)
20. 24 Feb - 25 Feb (10 Linux 2.5.63 Released
posts)
Mailing List Stats For This Week
We looked at 1847 posts in 10294K.
There were 444 different contributors. 227 posted more than once. 178 posted
last week too.
The top posters of the week were:
* 83 posts in 1554K by Osamu Tomita
* 57 posts in 151K by "David S. Miller"
* 52 posts in 219K by Andrew Morton
* 46 posts in 248K by "Martin J. Bligh"
* 38 posts in 113K by Alan Cox
* Full Stats
1. Linux 2.5.62 Released
17 Feb - 27 Feb (94 posts) Archive Link: "Linux v2.5.62"
Topics: Kernel Build System, SMP
People: Linus Torvalds, Chris Wedgwood
Linus Torvalds announced 2.5.62 ( ) :
Hmm.. Mostly lots of small updates, although the merge with Andrew included
the RCU dcache patches from IBM that he has carried along for a while (ie
fairly fundamnetal, but also very well tested).
ARM, PPC, PPC64, alpha, kbuild.
Oh, and as a sign that 2.6.x really _is_ approaching, people have started
sending me spelling fixes. Kernel coders are apparently all atrocious
spellers, and for some reason the spelling police always comes out of the
woodwork when stable releases get closer.
Chris Wedgwood reported that all kernels after 2.5.59, and possibly earlier,
would spontaneously reboot under heavy loads. The 2.5.59-mjb4 seemed pretty
stable to him though. Linus asked, "It would be interesting to hear exactly
when the trouble started. And if plain 2.5.59 does it (which is unclear from
your description), but 59-mjb4 doesn't, then that's an interesting data point."
Chris clarified that 2.5.59 did have the problem, and 2.5.59-mjb4 did not.
However, a bit later on, he said:
After much testing, which is still in progress it would seem that *maybe*
mjb4 does have the problem too, although it's much harder to hit. Please
note that this is a single data point where for other kernels I have two or
more occurrences of spontaneous reboots.
I've been checking older kernels... it would seem the problem first occurs
in 2.5.53 (that is 2.5.53 through 2.5.62-bk all reboot for me). 2.5.51
doesn't appear to and thus far neither does 2.5.52.
I say thus far, because the problem usually appears after about 15 minutes
of compiling, but it sometimes takes a little longer. I'm running 2.5.52
now and after 45 minutes it's still going.
As to what difference it might be between '52 and '53 I have no idea. I had
a quick look and the changes there are considerable.
I've tried different compiles, with and without preempt, and and without
IO-APIC and trimming down the kernel...
He posted in reply to himself shortly thereafter, to say that 2.5.52 did show
the behavior after all. He said, "I'm back to 2.5.51 and I'll beat it hard and
see what happens. I guess until I (or someone else who sees this) can get some
concrete data points you'll have to ignore this." Linus had a suggestion for
how to track down the bug. He said, "if it was getting hard to trigger with
2.5.52 too, things might be getting hairier and hairier.. If it becomes hard
enough to trigger as to be practically nondeterministic, a better approach
might be to just go back to -mjb4, and even if it is still there in -mjb4 try
to see which part of the patch seems to be making it more stable. That might
give us more clues, and it's a much smaller problem set than going arbitrarily
far back in the 2.5.x series." He added in reply to himself:
Btw, this is particularly true if it takes you potentially hours to test
something like 2.5.51 for stability, but you can reboot 2.5.59 at will in
ten minutes.
In that case, you can test several vrsions of "2.5.59 + partial -mjb
patches" much more quickly than you can walk backwards in 2.5.x, and try to
pinpoint the "this part of -mjb makes it much less likely to reboot".
Also, with the -mjb patch there are some new configuration options. For
example, CONFIG_100HZ on -mjb has very different behaviour than a plain
2.5.59 kernel that defaults to 1kHz timer clock, and maybe the reason -mjb
seems more stable is that you may have selected a configuration option that
made -mjb act differently.
Regardless, it would be very interesting to hear what the -mjb split-down
results would be. Even if the answer might be "at 1kHz timer it is
unstable, at 100Hz it is stable" (and if that were to be it, then you'd
have to walk backwards to 2.5.24 to find the old 2.5.x kernel that had a
slow tick rate).
Chris reported that 2.5.51 also showed the spontaneous reboot, although it took
almost an hour to induce. At this point Linus said, "Ok, I wrote up this
doublefault task-gate handler which has gotten some very very minimal testing,
and which is probably totally buggered on SMP machines etc, but which has
caught at least one double-fault on one of my test-machines (which I forced to
double-fault by making %esp contain an invalid value in kernel mode)." He
thought it might give Chris some useful debugging information just before the
crash.
A bunch of people posted tons of debugging output, and it seemed as though a
lot of headway was made toward finding various problems in the kernel, but
Chris' spontaneous reboots remained elusive.
2. Configuration Option For All SCSI Low-Level Drivers
18 Feb - 19 Feb (9 posts) Archive Link: "[PATCH 2.5.62]: 2/3: Make SCSI
low-level drivers also a seperate, complete selectable submenu"
Topics: Disks: SCSI
People: Bill Davidsen, Christoph Hellwig, Marc-Christian Petersen
Marc-Christian Petersen posted a patch to make all SCSI low-level drivers a
separate configuration submenu, so they could all be disabled at once.
Christoph Hellwig said people could already choose to disable CONFIG_SCSI, but
Bill Davidsen replied, "Isn't that going to disable all of SCSI? I think the
intention may be to drop hardware drivers and just use ide-scsi, although I
might be misreading the original intent. There are a fair number of tape/CD/DVD
devices out there which you might run SCSI. I many cases will run SCSI or not
at all."
3. Configuration Option For All Ethernet 1000Mbit NICs
18 Feb - 19 Feb (4 posts) Archive Link: "[PATCH 2.5.62]: 1/3: Make Ethernet
1000Mbit also a seperate, complete selectable submenu"
Topics: Networking
People: Jeff Garzik, Marc-Christian Petersen
Marc-Christian Petersen posted a patch to make Ethernet 1000Mbit support a
separate configuration submenu, so all 1000 Mbit NICs could be disabled at
once. Jeff Garzik said he'd apply the patch, though he said he'd prefer a
different name. Marc-Christian had used "NET_ETHERNETGBIT", and Jeff suggested
"NET_GIGE" or something short like that.
4. Kernel Panics In Morse Code
18 Feb - 19 Feb (6 posts) Archive Link: "[PATCH] morse code panics for 2.5.62
"
People: Tomas Szepe, Vojtech Pavlik
Tomas Szepe posted support for displaying kernel panics in morse code, for
2.5.62; he said:
+ Completely arch-independent.
+ No longer touches atkbd (as suggested by Vojtech Pavlik).
+ With minimal changes to existing code.
+ Introducing morse code ops -- a good hack value (MOST IMPORTANT!!).
+ Useful to people who spend most of their time in X.
5. Kernel Errata List
18 Feb - 21 Feb (3 posts) Archive Link: "[ANNOUNCE] 2.5 kernel errata list"
Topics: Bug Tracking
People: Paul Larson, Rik van Riel
Paul Larson announced:
Based on a suggestion and several people saying they would find it useful,
I'm keeping a kernel errata page on the Linux Test Project website at http:
//ltp.sourceforge.net/errata
I'll try to maintain a list of known fixes for blocking problems with the
most recent kernel on this page. By "blocking", I mean anything severe
enough to keep you from testing the kernel (can't compile, panic on boot,
catches your hair on fire, etc). This is _not_ a replacement for the bug
tracking system. I won't put anything here that doesn't have a fix or a
workaround. So if you're looking for an exhaustive list of problems for a
given kernel, look at bugme, but if all you want is a list of known fixes
to get you up and running quickly, the errata list should give you a quick
and easy answer.
If you have any suggestions to make this more useful or if you see anything
I've missed, please let me know.
Rik van Riel asked how this was different from the Bugzilla database already in
place, and Paul explained, "The bugzilla database tracks problems, whether they
are fixed or not. The errata list aims to be a quick (hopefully short) list of
known fixes to problems. Bugzilla also tracks all types of problems where the
errata list will usually only contain fixes to major, blocking problems.
Basically I'm trying to keep a list that will help people quickly find the
diffs against releases that will help them get up and running enough to test
with."
6. Accessing BitKeeper Without BitKeeper
19 Feb (1 post) Archive Link: "accessing bitkeeper without bitkeeper"
Topics: Version Control
People: Pavel Machek
Pavel Machek announced:
With attached patch to CSSC (www.sf.net/projects/cssc), and
rsync -zav --delete nl.linux.org::kernel/linux-2.5 linux-2.5
you can download local copy of whole linux-2.5 repository, and you can
access it, too.
There was no reply.
7. Documentation For The Kernel Bug Database
19 Feb (1 post) Archive Link: "[ANNOUNCE] Kernel Bug Database documentation
on-line"
People: John Bradford
John Bradford announced:
I've put some extensive documentation for the latest version of my Kernel
Bug Database online at:
http://grabjohn.com/kernelbugdatabase/documentation/
The latest version of the Kernel Bug Database is at the usual location:
http://grabjohn.com/kernelbugdatabase/
Main new features since version 2.0:
+ A slightly redesigned layout that loads more quickly
+ Kernel versions are now sorted numerically by version number order
+ The list of all bug reports or confirmed bugs on the search screens has
been replaced with a list of the five most recent
+ Search results now include status information for the latest tested
kernel versions, not the latest versions.
+ Automatic archiving of bug reports after four weeks
+ An active/archive flag for bug reports and confirmed bugs
+ A count of the number of returned bug reports, confirmed bugs or
patches for each search
+ A count of the number of non-returned due to being archived bug reports
or confirmed bugs for each relevant search
+ The searching of confirmed bugs page now replaces the initial main menu
+ An 'include status information for a particular kernel version' toggle
in bug reports and confirmed bug search pages
I've written the code for automatic testing of patches to see whether they
will apply to various kernel versions, but it will not be enabled until the
machine that hosts http://grabjohn.com/ is replaced with a faster one with
more disk space :-).
8. IPMI Driver Version 18 Released
19 Feb (1 post) Archive Link: "IPMI driver version 18 release"
People: Corey Minyard
Corey Minyard announced:
I found a few stupid bugs in the IPMI driver dealing with certain error
cases, and this also contains the documentation updates that I have not
sent to Linus enough times to be included yet :-).
The 2.5 version is attached. The 2.4 version is at: http://sourceforge.net/
projects/openipmi/
9. FUSE (Filesystem In Userspace) 1.0 Released
20 Feb (1 post) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE) 1.0
stable release"
People: Miklos Szeredi
Miklos Szeredi announced:
FUSE lets you write your very own filesystem, as an ordinary program. It
has a simple yet comprehensive interface, and provides an easy way to
create a virtual filesystem for just about any application.
Example applications include: automatic CD changer fs, remote filesystems
for handhelds, filesystem view for databases, etc...
FUSE currently works on all 2.4.x kernels (up to 2.4.20 and possibly
later). Installation is simple, no kernel patching or recompilation is
needed. Documentation for the interface and example programs are provided
in the package.
You can download the latest version from:
http://sourceforge.net/projects/avf
10. /proc Reorganization And Speedup
20 Feb - 24 Feb (28 posts) Archive Link: "[patch] procfs/procps threading
performance speedup, 2.5.62"
Topics: FS: procfs
People: Ingo Molnar, Linus Torvalds, Oliver Xymoron, Alexander Viro
Ingo Molnar announced:
Lots of people have requested that threads should show up in /proc again,
to be able to look at per-thread CPU usage, activity, and generally, to
ease the debugging of threaded apps.
the main problem with threads in /proc is that there's a big slowdown when
using lots of threads. Here are some runtime numbers in seconds, under
2.5.62, on a 525MHz PIII box:
# of threads (*): 1000 2000 4000 8000 16000
--------------------------------------------------------
ps 0.77 1.52 3.13 6.44 13.81
ps -axm 0.93 1.85 3.78 7.73 18.37
top -d 0 -n 0 0.75 1.53 3.23 7.60 22.12
[ (*): the system is completely idle, all threads are sleeping. Overhead is
combined system and userspace overhead measured via 'time'.]
ie. the overhead is really massive, eg. with 16K threads running, procps is
basically unusable for any administration or debugging work. And there are
users that want 50K or more threads. So clearly, this state of procfs and
procps is unacceptable - who would use 'top' to check a system's state if a
single screen-refresh takes 22 seconds?!
in the above timings, only 'ps -axm' is actually displaying every thread,
all other commands produce only a few lines of output. The reason of the
overhead is two-fold:
1) there's significant kernel overhead in reading large /proc directories,
the overhead of many readdir()'s is O(N^2). The main overhead is in
get_pid_list(), which has to loop over an increasing number of threads to
find the next intended batch of PIDs.
to fix this overhead i've introduced a 'lookup cursor' cookie, which is
cached in filp->private_data, across readdir() [getdents64()] calls. If the
cursor matches then we skip all the overhead of skipping threads. If the
cursor is not available then we fall back to the old-style skipping
algorithm.
2) procps is forced to parse every thread in /proc to build up accurate
'process CPU usage' counters. The parsing and accessing of every /proc/PID/
stat file is necessary because CPU statistics are scattered across all
threads.
the fix for this is two-fold. First, it must be possible for procps to
separate 'threads' from 'processes' without having to go into 16 thousand
directories. I solved this by prefixing 'threads' (ie. non-group-leader
threads) with a dot ('.') character in the /proc listing:
$ ls -a /proc
. 16994 .17078 412 7 execdomains locks stat
.. 16995 .17079 460 8 filesystems meminfo swaps
1 17031 .17080 469 9 fs misc sys
16864 17033 .17081 5 92 ide mounts sysvipc
16866 17034 .17082 515 buddyinfo interrupts mtrr tty
16867 17072 17113 516 bus iomem net uptime
16946 .17073 2 517 cmdline ioports partitions version
16948 .17074 3 518 cpuinfo irq profile vmstat
16949 .17075 390 519 devices kcore scsi
16989 .17076 4 520 dma kmsg self
16992 .17077 400 6 driver loadavg slabinfo
the .17073 ... .17082 entries belong to the thread-group 17072.
The key here is for procps to be able to parse threads without having to
call into the kernel 16K times. The dot-approach also has the added benefit
of 'hiding' threads in the default 'ls /proc' listing.
the other change needed was the ability to read comulative CPU usage
statistics from the thread group leader. I've introduced 4 new fields in /
proc/PID/stat for that purpose, the kernel keeps those uptodate across fork
/exit and in the timer interrupt - it's very low-overhead.
the attached patch, against 2.5.62-BK, implements these kernel features.
Alex Larsson has modified procps for these new kernel capabilities, the new
procps package (or the patch against upstream procps) can be downloaded
from:
http://people.redhat.com/alexl/procps/
here are the performance measurements (with stock procps+procfs numbers in
paranthesis)
# of threads: 1000 2000 4000 8000 16000
----------------------------------------------------------------
ps 0.02 0.03 0.03 0.03 0.04
(0.77) (1.52) (3.13) (6.44) (13.81)
ps -axm 0.89 1.72 3.40 6.87 15.57
(0.93) (1.85) (3.78) (7.73) (18.37)
top -d 0 -n 0 0.11 0.12 0.12 0.13 0.16
(0.75) (1.53) (3.23) (7.60) (22.12)
eg. with 16K threads running in the background, a single 'top'
screen-refresh got more than 130 times faster. A simple 'ps' got more than
340 times faster ... Even the 'ps -axm' (which displays all threads)
command got faster, due to the pid-cursor. But even with just 1000 threads
running a simple 'ps' is 30 times faster, and top refresh is 6 times
faster.
another advantage of this approach is that old procps is fully compatible
with the new kernel, and new procps is fully compatible with old kernels.
Plus everything is still encoded in the ASCII namespace, no binary
interfaces are used.
the patch works just fine on my boxes. (the patch is also included in the
threading backport, in the rawhide 2.4 kernel, and has been in use for a
couple of weeks already.)
Linus Torvalds replied:
Well, part of the problem (I think) is that you added all the threads to
the same main directory.
Putting a "." in front of the name doesn't fix the /proc level directory
scalability issues, it only means that you can avoid some of the user-
level scalability ones.
So to offset that bad design, you then add other cruft, like the lookup
cursor and the "." marker. Which is not a bad idea in itself, but I claim
that if you'd made the directory structure saner you wouldn't have needed
it in the first place.
It would just be _so_ much nicer if the threads would show up as
subdirectories ie /proc/<tgid>/<tid>/xxx. More scalable, more readable, and
just generally more sane.
Other folks had similar suggestions, but Ingo replied that Alexander Viro had
said that the /proc/<tgid>/<tid>/xxx solution could not be done sanely, and was
fraught with security problems. Linus said it was no different than the current
situation, except the information would show up in a different place. And
Oliver Xymoron remarked, "Well perhaps that was just Al's way of saying the
current stuff is broken too."
There was a bit more discussion, but folks were unable to agree on the proper
way to go about things.
11. Status Of 8x AGP Support
20 Feb (3 posts) Archive Link: "8x AGP under linux?"
People: Casey Lancour, Dave Jones, Matthew E Tolentino
Casey Lancour asked, "Does anyone know the status to 8x agp support under
linux? I am using the Granite bay 7205 chipset and I cant get my geforce4 card
to use agpgart or nvidia's agp support, it seems to be defaulting to pci mode
(not even using 4x agp)." Dave Jones replied, "For 2.4, there is a patch for
that chipset (that didnt get merged to mainline). 2.5 has it supported
out-of-the-box, but likely breaks with your binary nvidia driver." Matthew E
added, "Casey, I can send you the 2.4 patch for the E7205/E7505 chipsets that I
posted a while back that also incorporates AGP 3.0 support if you are
interested. However as Dave mentioned, I did have quite a bit of trouble with
the Nvidia 8x binary only driver, so ymmv...."
12. Consolidating Multiple ioctl Handler Code
20 Feb - 24 Feb (13 posts) Archive Link: "ioctl32 consolidation"
Topics: Feature Freeze, Ioctls
People: Pavel Machek, Jeff Garzik, Arnd Bergmann, Martin Schwidefsky, Stephen
Rothwell, David S. Miller, Andi Kleen
Pavel Machek posted a patch and said:
Currently, 32-bit emulation in kernel has *5* copies, and its >1000 lines
each. Plus, locking of all but x86-64 architectures is broken (I'm told by
andi ;-).
So, here's patch that starts sharing sys32_ioctl() [as a first step], which
should rmove locking problems.
I've done the work for x86-64 and sparc64; if it looks good I'll attempt to
do other architectures. [Unless maintainers prefer to do it themselves: I
don't have easy access to 64-bit machines besides hammer.]
Jeff Garzik replied:
Yes :/ Consolidating all these copies into a single layer has been a
"project to be" for quite some time.
I do not know if it is too late in 2.5.x to begin this work, however. We
_are_ in a feature freeze... I suppose it is up to the consensus of arch
maintainers, because it [obviously] does not affect ia32.
Pavel replied that Andi Kleen had asked him to do the work; and Pavel asked
David S. Miller and other architecture maintainers what they thought about it.
David said he was totally fine with it. Arnd Bergmann also replied:
For s390, I'd love to see progress in the consolidation. Feel free to
submit changes for arch/s390x/kernel/ioctl32.c directly, like Stephen
Rothwell does for the syscall32 consolidation. Of course, Martin has the
last word here, but I'm rather sure he agress with me in this.
If you want access to an s390x system, you can probably get access to one
at http://www-1.ibm.com/servers/eserver/zseries/os/linux/lcds/ or install
the hercules emulator. I try to keep working kernel tree at http://
linux-390.bkbits.net/, but the 32 bit emulation has been broken for most of
2.5.
Note that for any ioctls that pass pointers, you will need special
massaging for the high order bit of the user space pointer, because s390
only has 31 bit pointers, not 32 bit.
Martin Schwidefsky added, "Everything that moves out of arch/s390x/kernel/
ioctl32.c has my blessing. I am currently working on the 31 bit emulation. It
almost works again and I will include the changes in the next patch set."
13. Status Of SpeedTouch USB Modem Driver
20 Feb - 21 Feb (3 posts) Archive Link: "Alcatel SpeedTouch USB Modem"
Topics: Modems, SMP, USB
People: Duncan Sands, Steve Parker
Steve Parker noticed that the driver for the Alcatel SpeedTouch USB Modem was
now included in the 2.5 kernel. This surprised him, because there had always
been a lot of problems with the kernel driver as opposed to the user-space
version. He'd been using the user-space version for over a year with no
problems; and asked what the status was on the kernel driver.
Duncan Sands replied, saying he was the maintainer. Regarding the historical
troubles, Duncan said:
These problems are being resolved. Most of them have already been resolved.
The cvs version for 2.4, which you can find at
http://www.linux-usb.org/SpeedTouch/
is quite stable. In theory it can still crash (due to various micro races),
but in practice it does not. In any case, these micro races will be fixed
soon. The 2.5 version, which is essentially identical to 2.4 cvs, doesn't
work very well in the current 2.5 kernel. I don't know why. I am working on
it.
I have nothing against the user space version, which I used for many moons.
The kernel version is certainly much lighter weight - less CPU, less
memory. Whether this matters for you depends on your machine/needs. My
machine is slow, and I need all the CPU time I can get!
He added:
The main disadvantages of the kernel mode driver were:
1. unstable, and very unstable on SMP/preempt boxes
2. required running the closed source speedmgmt program
3. required compiling your own kernel
The driver is in 2.5, and is heading for inclusion in 2.4, so I expect that
in the future most distributions will ship with the speedtch module
compiled. Thus (3) is going away.
The cvs version of the user space driver contains a patch for modem_run
which enables it to be used with the kernel driver in place of speedmgmt
(use the -k flag). Thus (2) has already gone away.
As I mentioned, (1) is (almost) dealt with.
Steve replied, "Thanks for that, Duncan. Lightweight and stable certainly
sounds good; I look forward to the project being ready."
14. Some Users Unhappy With Kernel Code Written Under NDA
20 Feb - 21 Feb (23 posts) Archive Link: "Linux kernel rant"
Topics: BSD: FreeBSD, BSD: OpenBSD, Disks: IDE, Disks: SCSI
People: James Buchanan, Jeff Garzik, Rik van Riel, Tomas Szepe
James Buchanan complained:
I am just wondering if anyone thinks the same way. I am thinking about
going to BSD for good because of these things.
Linux is starting to include code written under non-disclosure agreements
and other nasties, and for me this kills the magic of Linux. Doesn't stop
anyone from reading the code, but it's the principle that counts.
I don't know. I feel Linux has lost the plot. It's supposed to be getting
bigger and better (well, at least bigger -- to borrow words from Andy
Tanenbaum. He was referring to the onslaught of "improvements" to Minix
being submitted, but now this applies to Linux as well.)
True, there are lots of nice improvements and binary only drivers cannot
use ksysms, so I've read somewhere. (True? Nice.) But NDAs? Come on, where
do you get off on that?
Jeff Garzik pointed out that this situation had been going on for ages, and
that FreeBSD also had drivers written under NDA. He said, "It's the way of the
hardware world. If you don't get an NDA, you don't get open source support."
Tomas Szepe also said BSD developers had to sign NDAs, but James replied, "Theo
De Raadt refuses to sign them." Jeff replied:
OpenBSD contains drivers _obviously_ written under NDA, just like every
other free BSD. Theo probably imported these drivers from FreeBSD, I would
guess.
I pay attention to net drivers in all the BSD OS's, so if you know net
drivers and their vendors, these things are obvious ;-)
Rik van Riel pointed out that Theo De Raadt didn't have the same hardware
support, precisely because he refused to sign the NDAs. He quipped, "Of course,
you're free to run openbsd on any machine that supports it. I'm sure you'll be
able to put one together from various supported pieces of hardware."
Elsewhere, James said he didn't use any drivers written under NDA, and Rik and
Tomas pointed out that it was virtually impossible to find IDE or modern SCSI
drivers to satisfy that condition. Close by, Jeff asked James to post the list
of kernel drivers he used, so he and others could point out the portions
written under NDA.
15. Kernel 2.5.62-mm3 Released
23 Feb - 26 Feb (18 posts) Subject: "2.5.62-mm3"
Topics: Virtual Memory
People: Andrew Morton, Dave McCracken
Andrew Morton announced:
http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.62/
2.5.62-mm3/
+ Included Dave McCracken's "Object-based RMAP" patch.
What this dopey name actually means is that when page reclaim tries to
unmap a file-backed page it walks the VMAs attached to the
address_space and the pagetables attached thereto. So there is no need
for pte_chains for these pages.
The patch is simple, but potentially has search complexity problems
with weird workloads which have high sharing levels. Allegedly. Work is
ongoing.
+ Several more anticipatory scheduler tweaks. This has been an exercise
in hunting down situations in which the scheduler does the wrong thing,
and plugging those up.
The only known problem at this time is a ~20% falloff in threaded
OLTP-style database activity. This is really complex, involving
interactions between reads, O_SYNC writes and i_sem contention.
The problem will recede to less than 10% when we retune the
anticipation timer (it is currently set too high just so we can
discover these things).
But we do not see a sane way of fixing this for real. At present it
will need to be manually tuned away with
echo 0 > /sys/block/hdXX/antic_expire
Later, we will probably have to perform this disabling automatically.
+ There are some performance fixes which will help OLTP-style workloads
which are using regular old files through the pagecache. It seems to be
running maybe 60-70% faster than 2.4.x now, but it varies.
+ A few performance patches to reduce the amount of work we do in
update_atime() and __mark_inode_dirty() should pull back some of the
regressions which have been observed in there.
16. NTFS 2.1.1a For 2.4 Released
24 Feb (3 posts) Archive Link: "[ANN] NTFS 2.1.1a for kernel 2.4.20 released"
Topics: FS: NTFS
People: Anton Altaparmakov
Anton Altaparmakov announced:
NTFS 2.1.1a is now released for kernel 2.4.20. This fixes both the reported
hangs and improves the handling of compressed files so that the warning
message people keep reporting is now gone. (Note the hangs were specific to
the 2.4.x kernel ntfs versions. 2.5.x kernel ntfs versions are not
affected.)
Download the patch from:
http://linux-ntfs.sf.net/downloads.html
Or get from our BK repository (which is at the current BK linux-2.4
version, i.e. 2.4.21-pre4-bk):
bk://linux-ntfs.bkbits.net/ntfs-2.4
17. Possible Violation Of GPL
24 Feb (1 post) Archive Link: "[ANNOUNCE] interesting new vendor kernels on
kernelnewbies.org"
Topics: FS: NFS, Virtual Memory
People: Christoph Hellwig
Christoph Hellwig announced:
I'd like to annouce that there are two new interesting vendor kernels
available on the kernelnewbies vendor kernels page (http://
www.kernelnewbies.org/kernels/). Both unfortunately don't use the
traditional organization of multiple pathes agains ta base kernel release
but were tarballs that I had to diff against known kernel release.
In detail they are:
1. The NEC kernel for their IA64 machines.
Interestng here are their VM changes and a NFS extension for shared
storage called GFS (it's different from Sistina's filesystem of the
same name)
2. The kernel from TimeSys 3.1 demo release
This one is really interesting, it features a completly new scheduler
architectured around hooks to their propritary real time kernel and
heavyweight mutexes (e.g. with priority inheritance) that replace Linux
spinlocks. These architecture probably violates the GPL, but I'd like
to hear some more opinions on people who actually read the code before
bothering TimeSys about this issue.
18. Free Driver Petition
24 Feb (1 post) Archive Link: "Free Drivers Petition"
People: Harry Lepper
Harry Lepper suggested, "Please sign up the Free Drivers Petition at
<www.petitiononline.com/zxcv7nm (http://www.petitiononline.com/zxcv7nm) >."
19. Mailing List Statistics
24 Feb - 25 Feb (11 posts) Archive Link: "statistics for this mailinglist"
Topics: FS: procfs, SMP
People: Folkert van Heusden, J.W. Schultz, Larry McVoy, Martin J. Bligh, David
S. Miller, Ingo Molnar, Chris Wedgwood, Linus Torvalds, Alan Cox, Andrea
Arcangeli, Osamu Tomita, Jeff Garzik, William Lee Irwin III, Andrew Morton,
Zwane Mwaikambo
Folkert van Heusden posted some statistics for the linux-kernel mailing list:
Overall statistics
------------------
First message was written at: 2003/02/18 13:09:03
Last message was written at: 2003/02/19 23:54:45
Total number of messages: 1595
Total size: 8704KB
Total number of writers: 369
Number of people who wrote >1 message: 196
Total number of lines: 141544
Average lines per message: 88
Total header length (lines): 76324
Average header length (lines): 47
The header is on average 53.92% of the message (lines).
The header is 46.05% bytes in size of the total.
Average number of bits information per byte: 0.7501
Total number of unique user-agents: 142
Total number of unique organisations: 44
Total number of unique top-level domains: 51
Importance
----------
Low : 0.00%
Normal: 1.38%
High : 0.00%
(the rest is unspecified)
Top writers
| # msgs|av size| total|time| e-mail address
---+-------+-------+------+----+--------------------------------
1] 76| 4785| 355KB|0854| Alan Cox <[email protected]>
2] 59| 5692| 328KB|1428| "Martin J. Bligh" <[email protected]>
3] 57| 3410| 189KB|1124| "David S. Miller" <[email protected]>
4] 53| 16844| 871KB|1937| Osamu Tomita <[email protected]>
5] 42| 5531| 226KB|1133| William Lee Irwin III <[email protected]>
6] 42| 5055| 207KB|1415| Andrew Morton <[email protected]>
7] 35| 4743| 162KB|1334| Linus Torvalds <[email protected]>
8] 32| 3391| 105KB|1441| Jeff Garzik <[email protected]>
9] 28| 5374| 146KB|1437| Andrea Arcangeli <[email protected]>
10] 26| 3938| 99KB|1540| Ingo Molnar <[email protected]>
Top subjects
| # msgs|av size| total|time| subject
---+-------+-------+------+----+--------------------------------
1] 150| 4476| 655KB|1255| Minutes from Feb 21 LSE Call
2] 34| 4474| 148KB|1339| doublefault debugging (was Re: Linux v2.5.62 --- spontaneous
3] 28| 4249| 116KB|1154| [patch] procfs/procps threading performance speedup, 2.5.62
4] 23| 3795| 85KB|0840| Longstanding networking / SMP issue? (duplextest)
5] 23| 3507| 78KB|1609| Linux kernel rant
6] 21| 10297| 211KB|1216| AGP backport from 2.5 to 2.4.21-pre4
7] 21| 3944| 80KB|1026| Linux v2.5.62
8] 19| 4189| 77KB|0925| [PATCH] add new DMA_ADDR_T_SIZE define
9] 17| 4824| 80KB|1129| [RFC] Is an alternative module interface needed/possible?
10] 16| 4265| 66KB|1355| RFC3168, section 6.1.1.1 - ECN and retransmit of SYN
Top receivers
| # msgs|av size| total|time| e-mail address
---+-------+-------+------+----+--------------------------------
1] 424| 6563|2717KB|1428| [email protected]
2] 149| 7420|1079KB|1409| Linus Torvalds <[email protected]>
3] 58| 6021| 341KB|1316| Andrew Morton <[email protected]>
4] 48| 8122| 380KB|1334| "David S. Miller" <[email protected]>
5] 47| 5845| 268KB|1509| "Martin J. Bligh" <[email protected]>
6] 36| 5781| 203KB|1359| Jeff Garzik <[email protected]>
7] 29| 8334| 236KB|1052| Alan Cox <[email protected]>
8] 26| 4200| 106KB|1042| [email protected]
9] 23| 4752| 106KB|1134| Larry McVoy <[email protected]>
10] 22| 5346| 114KB|0959| Ingo Molnar <[email protected]>
Top CC'ers
| # msgs|av size| total|time| e-mail address
---+-------+-------+------+----+--------------------------------
1] 752| 5396|3962KB|1242| <[email protected]>
2] 115| 4061| 456KB|1334| [email protected]
3] 56| 5549| 303KB|1249| Andrew Morton <[email protected]>
4] 54| 14239| 750KB|1747| Alan Cox <[email protected]>
5] 39| 6608| 251KB|1102| "David S. Miller" <[email protected]>
6] 35| 9217| 315KB|1301| [email protected]
7] 32| 5170| 161KB|1419| Chris Wedgwood <[email protected]>
8] 32| 4268| 133KB|0844| "Martin J. Bligh" <[email protected]>
9] 26| 5165| 131KB|1459| Zwane Mwaikambo <[email protected]>
10] 24| 8095| 189KB|1313| Jeff Garzik <[email protected]>
Top of top-level-domain
----------------------------------------------------------
1] com 668
2] org 200
3] de 118
4] uk 117
5] net 90
6] jp 55
7] au 49
8] cz 32
9] hu 30
10] edu 27
Top organisations
----------------------------------------------------------
1] 81
2] 42 The Domain of Holomorphy
3] 11 Working Overloaded Linux Kernel
4] 8 none
5] 8 Nuix
6] 7 USAGI Project
7] 7 ith Kommunikationstechnik GmbH
8] 3 Open Source Devlopment Lab
9] 3 My House
10] 3 daimi.au.dk
Top user-agents
----------------------------------------------------------
1] 207 Mutt/1.4i
2] 78 Mutt/1.3.28i
3] 70 Mutt/1.2.5.1i
4] 70 Mutt/1.5.3i
5] 60 ELM [version 2.5 PL6]
6] 55 Mulberry/2.2.1 (Linux/x86)
7] 51 Mutt/1.3.25i
8] 42 Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
9] 42 Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
10] 41 Ximian Evolution 1.2.1 (1.2.1-4)
Messages per day
----------------------------------------------------------
Sunday 257 ************************************
Monday 133 *******************
Tuesday 146 ********************
Wednesday 215 ******************************
Thursday 300 *****************************************
Friday 239 *********************************
Saturday 136 *******************
Messages per Month
----------------------------------------------------------
Jan 0
Feb 1427 *************************************************
Mar 0
Apr 0
May 0
Jun 0
Jul 0
Aug 0
Sep 0
Oct 0
Nov 0
Dec 0
Messages per day-of-the-month
----------------------------------------------------------
1 0
2 0
3 0
4 0
5 0
6 0
7 0
8 0
9 0
10 0
11 0
12 0
13 0
14 0
15 0
16 2 *
17 0
18 146 ************************
19 215 ***********************************
20 301 *************************************************
21 239 ***************************************
22 136 **********************
23 255 *****************************************
24 133 **********************
25 0
26 0
27 0
28 0
29 0
30 0
31 0
Messages per hour
----------------------------------------------------------
1 45 *******************
2 17 ********
3 13 ******
4 10 *****
5 4 **
6 12 ******
7 21 *********
8 41 ******************
9 63 ***************************
10 83 ***********************************
11 72 *******************************
12 83 ***********************************
13 86 *************************************
14 93 ***************************************
15 100 ******************************************
16 101 *******************************************
17 84 ************************************
18 117 **************************************************
19 52 **********************
20 72 *******************************
21 84 ************************************
22 61 **************************
23 63 ***************************
Created with mboxstats; written by [email protected]
Maciej Soltysiak was surprised that there didn't seem to be any Pine users
represented in the statistics. Several folks pointed out that Pine didn't use
an "X-Mailer" header or "User-Agent" header to identify itself, but they said
it could probably be recognized by the "Message-ID" header.
J.W. Schultz also pointed out:
And it wouldn't hurt to aggregate versions. This is really just a top-6
list.
1] 476 Mutt (most common versions versions)
2] 60 ELM [version 2.5 PL6]
3] 55 Mulberry/2.2.1 (Linux/x86)
4] 42 Sylpheed version 0.8.9 (GTK+ 1.2.10; i586-pc-linux-gnu)
5] 42 Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI)
6] 41 Ximian Evolution 1.2.1 (1.2.1-4)
Wonder where "unknown" would land if counted.
Folkert asked:
Problem is: what part is version-information and what is name? For Mutt
1.0, ELM 3.6 it's clear; it's the number part.
But what about:
FlokEdit peanutbutterrelease
FlokEdit RMDrelease
J.W. replied, "I would expect it to take a few regexes but so far $mta =~ s/\
W.*$// would do the trick to produce Mutt, ELM, Mulberry, Sylpheed, Mew, Ximian
and even FlokEdit."
20. Linux 2.5.63 Released
24 Feb - 25 Feb (10 posts) Archive Link: "Linux 2.5.63"
Topics: Version Control
People: Linus Torvalds, John Cherry
Linus Torvalds announced 2.5.63 (http://www.kernel.org/pub/linux/kernel/v2.5/
ChangeLog-2.5.63) :
Hmm.. Nothing really fundamental here - various updates all over
(architecture updates, networking, usb, acpi, bluetooth, the usual
suspects).
The task structure reference counting seems to have broken alpha, Richard
is still chasing that one down.
John Cherry posted:
Compile statistics: 2.5.63
Note that gcc 3.2 was used for all of these statistics.
2.5.62 2.5.63
-------------------- -----------------
bzImage (defconfig) 18 warnings 15 warnings
0 errors 0 errors
bzImage (allmodconfig) 33 warnings 29 warnings
9 errors 9 errors
modules (allmodconfig) 2514 warnings 2426 warnings
105 errors 128 errors
Compile statistics have been for kernel releases from 2.5.46 to 2.5.63 at:
www.osdl.org/archive/cherry/stability
I am also compiling nightly views of Linus' linux-2.5 bitkeeper tree.
Results can be found at:
www.osdl.org/archive/cherry/stability/linus-tree/running.txt (http://
www.osdl.org/archive/cherry/stability/linus-tree/running.txt)
We Hope You Enjoy Kernel Traffic
Kernel Traffic is hosted by the generous folks at Tux.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.