|Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic|
Table Of Contents
|1.||12�Nov�2003�-�25�Nov�2003||(45 posts)||Linux 2.6.0-test9-mm3 Released|
|2.||18�Nov�2003�-�24�Nov�2003||(84 posts)||New ndiswrapper Project To Load Certain Windows Drivers In Linux|
|3.||18�Nov�2003�-�24�Nov�2003||(18 posts)||Linux 2.6.0-test9-mm4 Released|
|4.||19�Nov�2003�-�20�Nov�2003||(5 posts)||Linux 2.4.23-rc2 Released|
|5.||19�Nov�2003�-�20�Nov�2003||(7 posts)||udev 006 Released|
|6.||19�Nov�2003�-�20�Nov�2003||(14 posts)||Status Of udev|
|7.||19�Nov�2003�-�20�Nov�2003||(3 posts)||New cuecat Serio Driver For 2.6|
|8.||21�Nov�2003||(1 post)||Graphs Comparing Various STP Test Runs For 2.4 And 2.6|
|9.||22�Nov�2003�-�24�Nov�2003||(7 posts)||SIGTRAP Handling Change From 2.4 To 2.6 Under x86|
|10.||23�Nov�2003�-�25�Nov�2003||(13 posts)||Status Of Hyperthreading-Aware Scheduler|
|11.||23�Nov�2003||(1 post)||perfctr 2.6.2 Performance Monitoring Tool Released|
|12.||23�Nov�2003||(1 post)||udev 007 Released|
|13.||23�Nov�2003�-�24�Nov�2003||(18 posts)||Linux 2.6.0-test10 Released; Handoff To Andrew Imminent|
|14.||24�Nov�2003||(8 posts)||Status Of Intel Centrino Drivers|
|15.||24�Nov�2003||(1 post)||New 'Tinderbox' Kernel Debugging Tool|
|16.||24�Nov�2003||(1 post)||New iswraid Intel Software RAID Driver For 2.4|
Mailing List Stats For This Week
We looked at 1424 posts in 7485K.
There were 465 different contributors. 233 posted more than once. 141 posted last week too.
The top posters of the week were:
1. Linux 2.6.0-test9-mm3 Released
12�Nov�2003�-�25�Nov�2003 (45 posts) Subject: "2.6.0-test9-mm3"
Topics: FS: ext2, FS: ext3, Kernel Release Announcement, SMP
People: Andrew Morton,�Zwane Mwaikambo,�Martin J. Bligh,�Linus Torvalds
Andrew Morton announced Linux 2.6.0-test9-mm3, saying:
kernel.org is being slow. Will appear at:
At one point Zwane Mwaikambo remarked, "It's actually triple faulting my laptop (K6 family=5 model=8 step=12) when i have CONFIG_X86_4G enabled and try and run X11. The same kernel is fine on all my other test boxes." Martin J. Bligh said, "Linus had some debug thing for triple faults, a few months ago, IIRC ... probably in the archives somewhere ..." And Linus Torvalds replied:
Triple faults you can't debug, they raise a line outside the CPU, and normal PC hardware will cause that to just trigger a reboot.
But double faults do get caught, and that debugging stuff actually is in the standard kernel. It won't give _nearly_ as good a debug report as a "normal" oops, since I didn't want the double-fault handler to touch anything even remotely unsafe, but it often gives a good hint about what might be wrong. Certainly better than triple-faulting did (which we still do for _catastrophic_ corruption, eg totally munged kernel page tables etc - it's just very hard to avoid once you get corrupted enough).
2. New ndiswrapper Project To Load Certain Windows Drivers In Linux
18�Nov�2003�-�24�Nov�2003 (84 posts) Subject: "Announce: ndiswrapper"
Topics: Assembly, BSD, Microkernels, Microsoft
People: Pontus Fuchs,�Maciej Zenczykowski,�Richard B. Johnson,�Pavel Machek,�Bill Davidsen,�H. Peter Anvin,�Linus Torvalds,�Nuno Silva,�Christian Axelsson
Pontus Fuchs announced:
Since some vendors refuses to release specs or even a binary Linux-driver for their WLAN cards I desided to try to solve it myself by making a kernel module that can load Ndis (windows network driver API) drivers. I'm not trying to implement all of the Ndis API but rather implement the functions needed to get these unsupported cards working.
Currently it works fine with my Broadcom 4301 but I would like to get in touch with people that have similar cards that are willing to do some testing/hacking.
Visit this page for more info: http://ndiswrapper.sourceforge.net/
Please! I don't want to start a flamewar if this is a good thing to do. I'm just trying to scratch my own itch and I doubt that this project changes the way Broadcom treats Linux users.
Christian Axelsson thought this was a great plan, and Maciej Zenczykowski agreed. But Maciej said:
are you loading these drivers into ring 0 (kernel space)? As far as I know linux only supports ring 0 (kernel) and 3 (userspace). However this would seem to be the perfect place to load the binary modules in ring 1 (or even userspace if that was possible...). I can't say I trust any binary only and/or windows driver to not make a mess of my kernel :) actually the driver may actually be errorless - it's just designed for a different operating system and thus some unexplainable misshaps could easily happen...
While we're at it, loading binary only modules into ring 1 would probably also be a good idea for the NV module et al. Although I have no idea how hard it would be to make ring 1 function (and whether there actually is any point to doing it in ring 1 instead of ring 3 with iopl/ioperm anyway) and how big the performance penalty for non-ring 0 would be...
Richard B. Johnson replied:
Do the NDIS drivers work in 32-bit land? Some kludges do! They were the real-mode DOS driver interface to MS-DOS. Now there is a kludge on top of a kludge called NDIS-6. They also used the Pascal calling convention which screws up 'C' code (you need an assembly wrapper).
They are a waste-of-time. Why would you clone a Microsoft interface for a non-Microsoft Operating System when you can't allow such junk to run inside the kernel anyway.
The problem with third-party binary drivers is not the interface to the kernel. Linux has a public interface, well established and well known. The problem is that any third-party driver can completely f**k up the kernel, either by mistake or by design. So the third-party drivers MUST provide source-code so they can be fixed or made to behave if (read when) problems are found.
Pavel Machek also replied to Pontus' original announcement, saying, "Wow, works for me, Broadcom 94306. [Well, I do not have second wifi to test right now, but module loads, I can iwconfig it etc.]"
Elsewhere, at one point in the conversation Bill Davidsen remarked, "I'm curious if the NDIS stuff could be run in ring 1 or 2, being an old MULTICS guy. Not for political reasons, just good tech." H. Peter Anvin said, "Unfortunately the segmentation and paging were so poorly integrated in i386 that rings 1-2 are pretty much totally useless." And Linus Torvalds said:
That may be the politically sensitive (except to Intel) correct answer, but in the end I suspect that the _real_ answer is that ring 1/2 are just fundamentally useless, and it has nothing to do with x86 implementation semantics or anything else.
Any kind of reasonable performance driver requires direct access to the buffers it is going to fill in. And not just the actual data contents, but to the metadata too - the pointers that comprise the skb (or in BSD, mbuf) lists, etc.
So even if you were to use ring1/2 for the driver, you'd really need to give write access to a large portion of the data structures that the "core" kernel networking would use.
Which means that you either put the core kernel in ring1/2 as well (at which point you don't actually use ring0 for anything interesting at all - you could put a microkernel there, but hey, there's no real point), or you map in a _lot_ of ring0 metadata into ring1/2, at which point you lost the whole point of using a different protection domain.
And quite frankly, if you're willing to actually dynamically map all the ranges and be careful, why use ring1/2 at all? You might as well use ring3 and make the whole thing be a user-mode wrapper. You'd never perform really well, but for debugging it is acceptable.
Anyway, whatever way you turn, ring1/2 just don't actually _give_ you anything. Which is, in the end, the _real_ reason nobody uses them.
(I agree, the fact that the x86 paging hardware makes 1/2/3 be equivalent makes it an even _less_ useful abstraction, but I think it is a mistake to think that it would be any more useful even if the page tables wasted precious bits on unnecessary level information).
Multi-ring was a failure. Let it go. The only reason it is making something of a comeback (Palladium-whatever-it-is-called-today) has no good technical reasons, and is purely about other things.
Nuno Silva mentioned:
The good people at Cambridge made a (very nice) VMM that exploits ring0/1/3 to let one machine run various kernels independently (the kernels need to be ported to the xen arch).
Xen itself executes in ring0 and the "guest" operating systems execute in ring1. User code runs in ring3, as usual. They have linux running under xen ;)
The project's home page is at http://www.cl.cam.ac.uk/Research/SRG/netos/xen/ and one paper describing the whole thing is here: http://www.cl.cam.ac.uk/netos/papers/2003-xensosp.pdf
And Linus replied:
This is what I alluded to a few lines later - saying that if you move the driver down to ring1, then you should move _everything_ down to ring1 and just leave a microkernel at ring0.
Now, I'm not big on microkernels, but a pure virtual machine abstraction is at least not the distateful academic mental masturbation that we saw in the 80's.
3. Linux 2.6.0-test9-mm4 Released
18�Nov�2003�-�24�Nov�2003 (18 posts) Subject: "2.6.0-test9-mm4"
Topics: Kernel Release Announcement, Power Management: ACPI
People: Andrew Morton,�Gene Heskett
Andrew Morton announced Linux 2.6.0-test9-mm4, saying:
Gene Heskett reported, "I've rebooted to various elevators and run each for at least a day, and for mm3, I'd have to say that the diffs are tolerable, but the smoothest, most responsive is the deadline version. as still gives an occasional 20 millisecond stutter, and cfq might be 10 milliseconds. Even as is a far cry from the near show stopper 15 to 20 second hangs of the performance in the later 2.4's. Great work guys!"
4. Linux 2.4.23-rc2 Released
19�Nov�2003�-�20�Nov�2003 (5 posts) Subject: "Linux 2.4.23-rc2"
Topics: Networking, Power Management: ACPI, Version Control
People: Marcelo Tosatti,�Samuel Flory,�Len Brown
Marcelo Tosatti announced 2.4.23-rc2, saying:
Here it goes -rc2.
Important netfilter fixes, several ACPI fixes, few driver corrections (tulip, tg3, megaraid2), amongst others.
If no problems shows up this should become final in a few days.
Samuel Flory reported, "The amd64 compile is still breaking for me." Marcelo replied that Len Brown had just sent him a fix for that, and suggested that Samuel try the current BitKeeper tree. Samuel said he didn't use BitKeeper, and asked if a particular patch would work; but there was no reply.
5. udev 006 Released
19�Nov�2003�-�20�Nov�2003 (7 posts) Subject: "[ANNOUNCE] udev 006 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, USB, Version Control
People: Greg KH,�Dave Jones,�Arnd Bergmann,�Chris Friesen,�Paul Mundt,�Robert Love,�Olaf Hering
Greg KH announced:
I've released the 006 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-006.tar.gz
Due to me being on paternity leave for all of November, I've not built up any rpms, but the spec file is in the tarball, so you can do it if you wish.
udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run.
The major changes since the 005 release are:
Many, many thanks to Kay Sievers, for this release, for implementing many of the new features. I really appreciate it.
Thanks also to Dan Stekloff, Robert Love, Paul Mundt, Chris Friesen, Arnd Bergmann, and Olaf Hering, all of whom submitted patches for this release.
The full ChangeLog can be found below.
The udev FAQ can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
The udev BitKeeper tree has moved for now, due to kernel.bkbits.net being off the air to: bk://linuxusb.bkbits.net/udev
Note, to build using klibc, please read the klibc README in the klibc/ directory, and build using 'make -f Makefile.klibc'.
If anyone ever wants a snapshot of the current tree, due to not using BitKeeper, or other reasons, is always available at any time by asking.
He replied to himself, saying:
Oops, two more major changes I forgot to mention:
Thanks a lot to both Pat and Christophe for letting me include their programs in the main udev release, I appreciate it. And if there's any other small programs that people want me to bundle within udev, please let me know.
Dave Jones said, "I just changed my sparse snapshotter to a generic bitkeeper repo snapshotting script. Daily tarballs of udev as well as a daily unpacked tree can now also be found at http://www.codemonkey.org.uk/projects/bitkeeper/udev/" And Greg thanked him.
6. Status Of udev
19�Nov�2003�-�20�Nov�2003 (14 posts) Subject: "[2.6 patch] document that udev isn't yet ready (fwd)"
Topics: FS: devfs, FS: initramfs, FS: ramfs, FS: sysfs, Klibc, Version Control
People: Martin Schlemmer,�Greg KH,�Adrian Bunk
Adrian Bunk posted a patch to document the fact that udev was not ready yet to fully replace DevFS. Grek KH asked what Adrian found lacking in udev as of release 006, and Martin Schlemmer replied:
I am guessing its more driver support, etc. Input devices for instance do not seem to have any sysfs support yet, and full initramfs support with udev in there, and udev.permissions setup to get general permissions, etc right, might make it more advertisable for the masses (no need to maintain /dev or the initial costs for users not so interested in the workings of things).
Lets just say from what I have seen from users talking/asking, the initial setup and seeming 'lack of functionality' is the biggest blocker.
Greg agreed that more driver support would be good, but said there was not much to be done for that at the udev side of things. But he did say, "I have a number of patches pending for 2.6.1 that will add more driver support for sysfs." For initramFS support, Greg also said, "The people keeping the klibc kernel bk tree have enough support in it to place udev into initramfs. Again, nothing that udev needs to do for this." Regarding the udev.permissions situation, Greg said, "We now support wildcards in udev.permissions, forgot to mention that in the 006 release. So it's just a matter of distros building up a permissions file that matches their needs." He admitted that "udev still has a way to go to be solid and mature, but it is usable for the most part :)" And he concluded that the main task remaining was just for the various distributions to put in the work to get themselves set up properly to use udev.
7. New cuecat Serio Driver For 2.6
19�Nov�2003�-�20�Nov�2003 (3 posts) Subject: "[ANNOUNCE] cuecat serio driver for linux 2.6.0-test9"
Topics: FS: devfs
People: Zinx Verituse,�Christoph Hellwig
Zinx Verituse announced:
my cuecat driver is ready for testing.
It does not use the same output format as the driver floating around for 2.2.x/2.4.x kernels.
It currently requires a patch which changes the order serio drivers are searched in (the newest driver is searched first now), and adds a function to walk through the serio port list.
I'm hoping the patch will be included in to the kernel at some point in time -- It's available separately at: http://zinx.xmms.org/cuecat/linux-2.6.0-test9-serio.diff
The driver has some pitfalls, such as standing between -all- serio devices capable of supporting a cuecat, and not just the ones with a cuecat on them (And it has no way to specify which ports to use), but hopefully I'll think of a good way to fix that before 0.0.3.
The major number is dynamicly allocated -- If you aren't using devfs, check /proc/devices.
The minor number for reading all cuecats is 0, and the minor number for individual cuecats is their [driver-assigned] index plus 1. Recommended names are:
and so on.
Christoph Hellwig remarked, "A 2.6 input driver shouldn't create devices by itself but rather use the input core to communicated with the upper drivers like evdev or moused." Zinx replied:
The input core really is designed for actual input devices, rather than devices that send out arbitrary largish amounts of data.
The driver would probably be simplified a bit (superficially) by sending barcodes as events (it would have to be multiple events per barcode -- the input core has very small communications with userland), but it would complicate userspace quite a bit, and it's really just not the sort of thing I'd expect in the input core.
However, if you can think of a way to send the barcodes as a single event, without changing the userland input core interface, I'm all ears :)
There was no reply.
8. Graphs Comparing Various STP Test Runs For 2.4 And 2.6
21�Nov�2003 (1 post) Subject: "[OSDL] Graphical reaim comparisons"
People: Cliff White
Cliff White said:
For those who like data visual, i've created some graphs comparing various STP test runs. I'm using 2.6.0-test9 and 2.4.22/23-rc1 as comparison targets. Data updated as new tests run on STP.
Other test runs here:
Reaim test code here: http://sourceforge.net/project/showfiles.php?group_id=71019
9. SIGTRAP Handling Change From 2.4 To 2.6 Under x86
22�Nov�2003�-�24�Nov�2003 (7 posts) Subject: "x86: SIGTRAP handling differences from 2.4 to 2.6"
Topics: BSD: FreeBSD, Virtual Memory
People: Daniel Barlow,�Linus Torvalds,�Paul Mackerras,�H. Peter Anvin
Daniel Barlow reported:
There is a difference between 2.4 (tested in 2.4.23-rc2) and 2.6 (tested in 2.6.0-pre9) in the handling of "int 3" inside a SIGTRAP handler.
In 2.4, the handler appears to be recursively re-entered. In 2.6 the task is killed, along with any other tasks that share the same VM (I'm not talking about thread groups; I have CLONE_PARENT and CLONE_VM set but not CLONE_THREAD).
I'm not sure what the correct answer is, if indeed it's specified. For contrast, in FreeBSD 5.1 I'm told that the signal handler runs to completion and only on exit is it called again. I would suggest that this behaviour is probably more in keeping with the principle of least astonishment, but maybe I astonish in atypical ways.
Linus Torvalds confirmed the change from 2.4 to 2.6, explaining:
The basic change is basically:
The reason for the change is that the 2.4.x behaviour ends up hiding bugs, and can cause surprising deadlocks in threaded programs. The 2.6.x behaviour is "You did something fundamentally wrong, just _die_ now".
Linus went on to explain, regarding the FreeBSD behavior:
This works because "int 3" and "into" is what Intel calls a "trap" as opposed to a "fault", and as such we _could_ delay handling the signal and just continue along - when the exception happens, the CPU has already executed the instruction, and the exception will return to _after_ the instruction.
However, Linux will refuse to do that because delaying the SIGTRAP is pointless:
So Linux considers both "int 3" and "into" to be thread-synchronous, even though they are trivially recoverable. Which means that we have two options, and two options only: punch through the fact that the signal is blocked, or just say "that's wrong", and kill it.
NOTE NOTE NOTE!! If you actually _want_ the 2.4.x behaviour of recursive signal invocation, you should just tell the kernel so: use the SA_NODEFER flag to sigaction() to tell the kernel that you don't want to defer recursive signals.
In short, the 2.6.x behaviour is the right one. 2.4.x was a strange violation of the signal blocking, and I consider the FreeBSD behaviour to be just bizarre.
And with 2.6.x, if you actually _want_ recursive signal handlers, you can do so (fairly portably, I might add - putting the SA_NODEFER flag there should make everybody do the same thing, even *BSD).
Coming back to the kernel change itself, Paul Mackerras remarked on the particular behavior in question, saying:
Occasionally I have had a situation where the init process hits an instruction fault (often because of a kernel bug, actually), such as an access to a bad address. On embedded platforms we sometimes get the situation where init uses floating-point instructions but the CPU doesn't have floating point and the kernel has been compiled without FP emulation. In these situations the system looks like it just hangs, since init is doing nothing but take the same signal over and over again.
In this case the signal would not actually be set to be blocked or ignored but would end up being ignored because of the rule that "init gets no signals it doesn't want". I would prefer to see thread-synchronous signals kill init if they are not handled, so that at least we get a panic with a message that says what went wrong rather than the system just spinning its wheels uselessly.
Hmm.. Right now the init special case is in the signal _delivery_ path, which makes it hard to do something like that, since by then we no longer know/care who sent the signal.
We could move the special case into the send path instead (and then only do it for "external signals" and not special case init at all for internal signals).
Hmm.. Looking at the signal sending code, we actually do special-case "init" there already - but only for the "kill -1" case. If the test for "pid > 1" was moved into "group_send_sig_info()" instead, that would pretty much do it, I think.
Feel free to try something like that out. I'm not going to apply it right now, though ;)
At this point, H. Peter Anvin asked:
Why do we bother special-casing init at all?
It seems the only things init can't ask the kernel to do already for it is to block SIGSTOP and SIGKILL, and it seems that if you killed (or stopped?) init you should just get the kernel panic.
If there is anything that should be special-cased, then perhaps it should be that init should be allowed to block/catch/ignore SIGSTOP/SIGKILL. Perhaps that should be a capability?
Linus said that the kernel special-cased init...
Because the kernel depends on it existing. "init" literally _is_ special from a kernel standpoint, because its' the "reaper of zombies" (and, may I add, that would be a great name for a rock band).
So without init, the kernel wouldn't have anybody to fall back on when a parent process dies, and would become very very unhappy. Historically it actually oopsed the kernel.
UNIX semantics literally _require_ that "getppid()" should return 1 if your parent dies, and that's "current->p_parent->tgid". So we have to have a parent with pid 1, and thus init really _is_ special.
Yeah, we could have _other_ special cases (we could create another process that is invisible and has pid 1), but the fact is, _some_ special case is required. It might as well be "you can't kill init".
10. Status Of Hyperthreading-Aware Scheduler
23�Nov�2003�-�25�Nov�2003 (13 posts) Subject: "[RFC] generalise scheduling classes"
Topics: Feature Freeze, Hyperthreading, SMP
People: Nick Piggin,�Ingo Molnar
Nick Piggin proposed:
We still don't have an HT aware scheduler, which is unfortunate because weird stuff like that looks like it will only become more common in future.
I made a patch on top of my recent NUMA/SMP scheduling stuff to implement generalised scheduling classes. With this modification we can allow architectures to control scheduling policy in a much finer way. Hyperthreading should be no problem, hierarchical (NUMA) nodes should be doable as well.
I'm not exactly sure how architecuture specific code is supposed to be handled, I'll have to have a look at some examples. Basically architectures build up your own scheduling "classes".
I have supplied a default function to build up the classes if none is supplied. It builds them so functionality should be similar to the previous standard local / remote behaviour.
Haven't done much testing yet, just asking for comments. Will these classes be sufficient for everyone?
Class is struct sched_class in include/linux/sched.h Default classes are built by arch_init_sched_classes in kernel/sched.c
http://www.kerneltrap.org/~npiggin/w23/. The patch in question is this one: http://www.kerneltrap.org/~npiggin/w23/broken-out/sched-domain.patch
Ingo Molnar asked, "uhm, have you seen my HT scheduler patches, in particular the HT scheduler in Fedora Core 1, which is on top of a pretty recent 2.6 scheduler? Works pretty well." Nick replied, "I have seen it. Sorry I know you have done so and it looks good. I wouldn't be adverse to it being included, although Linus seems to be. The changes I have made nearly give you it for free anyway. I just meant that there is not one in Linus' tree yet." Ingo replied, "yes, because when i wrote it we were already in a feature freeze, and the changes are intrusive. And being the scheduler maintainer i'm supposed to show a certain level of self restraint :-)"
11. perfctr 2.6.2 Performance Monitoring Tool Released
23�Nov�2003 (1 post) Subject: "perfctr-2.6.2 released"
Topics: Profiling, SMP
People: Mikael Pettersson
Mikael Pettersson announced:
Version 2.6.2 of perfctr, the Linux/x86 performance monitoring counters driver, is now available at the usual place: http://www.csd.uu.se/~mikpe/linux/perfctr/
I've now also made .rpm files for the user-space components. Please try them out and report any glitches.
Version 2.6.2, 2003-11-23
12. udev 007 Released
23�Nov�2003 (1 post) Subject: "[ANNOUNCE] udev 007 release"
Topics: FS: devfs, FS: sysfs, Hot-Plugging, Klibc, Version Control
People: Greg KH,�Marco d'Itri,�Dave Jones,�Olaf Hering
Greg KH announced:
I've released the 007 version of udev. It can be found at: kernel.org/pub/linux/utils/kernel/hotplug/udev-007.tar.gz
udev is a implementation of devfs in userspace using sysfs and /sbin/hotplug. It requires a 2.6 kernel to run. Please see the udev FAQ for any questions about it: kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ
The CALLOUT rule format has changed. If you have a config file using this rule, please change it to follow the new order. See the man page for the proper style.
The major changes since the 006 release are:
Again, many thanks to Kay Sievers, for lots of great patches in this release. Thanks also to Marco d'Itri and Olaf Hering, both of whom submitted patches for this release.
I think with the ability to capture the output of the CALLOUT rule, combined with the ability to put format modifiers in the CALLOUT program string, we now have everything in place to emulate the existing devfs naming scheme. Anyone want to verify this or not?
The full ChangeLog can be found below.
udev development is done in a BitKeeper repository loacated at: bk://linuxusb.bkbits.net/udev
Daily snapshots of this tree can be found at: http://www.codemonkey.org.uk/projects/bitkeeper/udev/. Many thanks to Dave Jones for managing this.
13. Linux 2.6.0-test10 Released; Handoff To Andrew Imminent
23�Nov�2003�-�24�Nov�2003 (18 posts) Subject: "Linux 2.6.0-test10"
Topics: Disks: SCSI, Kernel Release Announcement, Real-Time, USB, Version Control
People: Linus Torvalds,�John Cherry
Linus Torvalds announced Linux 2.6.0-test10, saying:
it's been almost a month between test9 and test10, with a constant but diminishing trickle of small patches. The full changes are slightly larger than I was hoping for, but considering that the patch is barely over 100kB compressed for a month worth of work, I'm still fairly pleased.
There is still something strange going on that seems to be triggered by preemption, so for now we suggest not enabling CONFIG_PREEMPT if you want the highest stability. On the other hand, I'd love to have more testing, so that we can try to figure out what the pattern is - but please mention explicitly that you ran with preemption if you have problems.
Quite a lot of the -test10 patches are one-liners and quite trivial. I've tried to be quite strict in patch acceptance, so the changes are largely fixes for things that can crash the machine, and they are also of the type "this can't possibly break anything". But hey, we all know that theory and practice don't always match ;)
I'm planning/hoping on basically turning this over to Andrew, and let him decide to make the final 2.6.0 or not. Timing-wise Andrew is apparently going to be off for a few weeks, so regardless of whether this turns out to be rock solid or not, we'll have a few weeks of final testing before that were to happen. Which means that I might still end up making a test11 if Andrew hasn't come back and we find something that warrants it.
Btw, I'm happy to say that maintainers have been self-policing themselves quite admirably. Thanks to everybody involved.
The changelog gives more details, but the bigger things here are various networking fixes, and the SCSI layer being better at refcounting some data structures (the oopses on USB storage removal that some people have seen should hopefully be fixed).
[ Btw, I tried to come up with a good name for this release. But the fact is, that as Scott Adams has so often pointed out, you can't do much better than "weasel" when it comes to funny. Ever since the "greased weasel" series of kernel releases I have been stuck for a good name.
This release is tentatively called the "stoned beaver" release (beavers are _almost_ as good as weasels, as I'm sure Scott Adams would agree).
If you feel strongly about the issue, please send your votes and ideas to "email@example.com", I'm sure somebody will find your insight fascinating.
Thank you in advance. ]
John Cherry posted some stats:
Linux 2.6 Compile Statistics (gcc 3.2.2) Warnings/Errors Summary
Kernel bzImage bzImage bzImage modules bzImage modules (defconfig) (allno) (allyes) (allyes) (allmod) (allmod) ----------- ----------- -------- -------- -------- -------- --------- 2.6.0-test10 0w/0e 0w/0e 170w/ 0e 12w/0e 3w/0e 209w/0e 2.6.0-test9 0w/0e 0w/0e 174w/ 0e 12w/0e 3w/0e 217w/0e 2.6.0-test8 0w/0e 0w/0e 178w/ 0e 12w/0e 3w/0e 219w/0e 2.6.0-test7 0w/0e 0w/0e 173w/ 1e 8w/0e 3w/0e 226w/0e 2.6.0-test6 0w/0e 1w/0e 188w/ 1e 12w/0e 3w/0e 260w/2e 2.6.0-test5 0w/0e 2w/0e 205w/ 9e 15w/1e 0w/0e 305w/5e 2.6.0-test4 0w/0e 2w/0e 797w/55e 68w/1e 3w/0e 1016w/34e 2.6.0-test3 0w/0e 2w/0e 755w/66e 62w/1e 7w/9e 984w/42e 2.6.0-test2 0w/0e 1w/0e 952w/65e 63w/2e 7w/9e 1201w/43e 2.6.0-test1 0w/0e 1w/0e 1016w/60e 75w/1e 8w/9e 1319w/38e
Web page with links to complete details:
Daily compiles (ia32):
Daily compiles (ia64):
Latest changes in Linus' bitkeeper tree:
14. Status Of Intel Centrino Drivers
24�Nov�2003 (8 posts) Subject: "Intel centrino drivers being withheld?"
People: Andrew Walrond,�Felipe Alfaro Solana
Andrew Walrond asked:
Is anybody liasing, asisting or pressuring Intel wrt centrino wireless drivers?
It seems to me that it could have been written at least 20 times over during the time they've supposedly been in development.
This quote from back in March annoys me somewhat:
"The Santa Clara, Calif., chip maker is running Linux drivers in its labs, but whether or not those drivers make it out of the labs depends on customer demand, said Scott McLaughlin, an Intel spokesman"
Well, I am demanding, and my patience is running very thin. And Amd look to be releasing 64bit mobile parts soon, and appear to be very linux friendly. Am I the only one getting annoyed about this?
Can anybody put my mind at rest, or suggest reasons why Intel may be reluctant to release the drivers?
Felipe Alfaro Solana said:
No, you're not alone... Although I don't have a Centrino-powered machine at the moment, the way Intel is behaving is stopping for me for even thinking on buying a new laptop replacement.
I think this kind of disinterest on Linux Centrino drivers is motivated by the fact that Microsoft has a strong relationship with Intel and since, like it or not, Windows has 90% of the desktop market, Intel doesn't see the motivation to spend a few hundred dollars in building the driver themselves.
However, they could at least release the documentation. Since the driver is, I think, going to be GPL'ed, they don't have to fear releasing the internals of Centrino.
15. New 'Tinderbox' Kernel Debugging Tool
24�Nov�2003 (1 post) Subject: "Announce: Kernel Tinderbox (OSDL)"
Topics: Version Control
People: Cliff White
Cliff White announced:
We are pleased to announce Tinderbox-based tool which Linux kernel developers can leverage to flag defects and regressions in the Linux kernel and to relate these defects and regressions to recent change sets for the kernel. The tool is under continuing development and it allows for distributed testing of the kernel using multiple hardware platforms and software configurations.
This tool is derived from the Mozilla Tinderbox infrastructure, with much help from the kind people at Async (http://www.async.com.br/) The Linux Kernel Tinderbox is a client-server system: The clients do a continuous cycle of checking out, compiling and testing the latest code integrated into the source repository. The server provides output as a set of web pages, showing current changes to the kernel tree and state of the client machines. Client status is displayed as a set of time-ordered coloured boxes arranged into columns, one per client.
A prototype for the Linux Kernel Tinderbox is viewable at:
Project documentation is located at:
This project will support any architecture capable of running Linux. It is our intent to encourage owners of these various hardware platforms to contribute Tinderbox clients.
The basic kernel tinderbox client is at: http://developer.osdl.org/cliffw/kernel_tinderclient.tar.gz
Support is via a mailing list: Kernelfirstname.lastname@example.org http://lists.osdl.org/mailman/listinfo/kernel-tinderbox
Let us know if you can provide a non-Intel client machine
16. New iswraid Intel Software RAID Driver For 2.4
24�Nov�2003 (1 post) Subject: "Announce: "iswraid" (ICH5R) ataraid sub-driver for 2.4.22"
Topics: Disk Arrays: RAID, Disks: IDE, Disks: SCSI, Serial ATA
People: Boji Tony Kannanthanam,�James Bottomley,�Arjan van de Ven,�Jeff Garzik
Boji Tony Kannanthanam announced:
Attached to this email is a patch for a new ataraid sub-driver "iswraid" (Intel Software RAID) for Kernel 2.4 series. The patch is taken against Kernel 2.4.22.
The driver (along with the ata_piix driver) can be used with Intel's ICH5R chipset. You will need the Option ROM to do RAID configuration. This driver differs slightly from the other ataraid sub-drivers in that it operates on SCSI block devices rather than the ATA/IDE ones. "iswraid" depends on "ata_piix" driver to detect and load the SATA disks connected to ICH5R. Note that the driver is still considered experimental, use at your own risk.
Thanks to Arjan van de Ven (ataraid), Jeff Garzik (ata_piix) and James Bottomley (scsi) for patiently answering my questions.
FYI: ata_piix patch for 2.4.22: ftp://ftp.kernel.org/pub/linux/kernel/people/jgarzik/libata/
Sharon And Joy
Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. 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.