Kernel Traffic
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Latest | Archives | People | Topics
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic

Kernel Traffic #249 For 27 Jan 2004

By Zack Brown

Table Of Contents


DVD CCA has surrendered in the Bunner case, probably due in large part to the Jon Johansen decision. As a result of this, the author of the DeCSS Haiku has decided to step forward and acknowledge his authorship. If he had done so before now, he would almost certainly have become the target of a terrible lawsuit.

The true author of the DeCSS Haiku is in reality Seth David Schoen, the Staff Technologist of the Electronic Frontier Foundation. Now that he's stepping out of the shadows, he's written a really great article about what he did and why. Don't miss the easter egg!

Mailing List Stats For This Week

We looked at 1877 posts in 9836K.

There were 581 different contributors. 288 posted more than once. 180 posted last week too.

The top posters of the week were:

1. ide-scsi Maintainership And Status; The Saga Continues

26 Dec 2003 - 7 Jan 2004 (17 posts) Archive Link: "The survival of ide-scsi in 2.6.x"

Topics: Disks: IDE, Disks: SCSI, USB

People: Willem RiedePete ZaitcevMikael PetterssonBartlomiej ZolnierkiewiczJames BottomleyBill DavidsenJens AxboeWakko WarnerStephen TweedieLinus Torvalds

Back in November, Linus Torvalds had some pretty harsh words to say about ide-scsi, covered in Issue #242, Section #1  (3 Nov 2003: Status Of IDE-SCSI Maintainance) .

This week, Willem Riede said:

I know that many feel that ide-scsi is useless, and should go away. And you are probably tired of message threads talking about it. Yet I ask respectfully that you hear me out, and give me feedback.

I need ide-scsi to survive. Why? I maintain osst, a driver for OnStream tape drives, which need special handling. These drives exist in SCSI, ATAPI, USB and IEEE1394 versions.

One high-level driver, osst, handles all of them, and that's how it should be, right? For ATAPI, it relies on ide-scsi.

(By the way, ide-tape contains code for the ATAPI version, the DI-30, but that code is old and has serveral known problems - I'd like to see it removed - or at least deprecated - I will do that myself later if people want me to.)

So can we agree to keep ide-scsi? I know it is not desired any more for cd writers. To avoid the problem reports from people who don't realize that and select ide-scsi anyway, we can refuse to attach to a cd-type device (today it just warns). And/or make a new explicit module parameter to tell ide-scsi exactly which drives to attach to.

Today, ide-scsi is buggy, and that needs fixing. The underlying problem is that ide-scsi stands with one leg in the IDE world and one leg in the SCSI world, which creates the challenge to make the IDE error recovery work in sync with, and under the direction of the SCSI error handler.

Example bug reports are [1], [2], [3], [4], [5], and [6].

A recurring problem is scheduling while atomic, see [1], [5], [7]. Linus points bluntly to the problem in [7]. I plead guilty to having introduced that code segment in [8]. I later attempted to improve on the error handling in [9], but that patch was not accepted (and wouldn't have fixed that particular problem).

[6] is different, and has me baffled - what can evoke a page fault in idescsi_transfer_pc?

In the spirit of cleaning up one's own mess, I am working on a new patch, to hopefully alleviate the problems. I've made liberal use of the attachments to the osdl bug reports [1]-[4] created by Mike Christie and a patch from Philip Auld [10], to give credit where it is due. I've also looked at ide-cd to see what it does differently.

Please look at the attachment (looking past the touch-ups that I made while I was at it...). Am I moving in the right direction? Specific changes I need advise on:

  1. timer expiry
    attachments to [1]-[4] and [10] suggest using it. Is it useful to buy some more time? I don't see the point to wait longer. By returning 0, I let ide_timer_expiry do its thing to handle lost (dma) interrupts. By seeting the PC_TIMEDOUT flag, I tell our end_request function to return DID_TIME_OUT to the scsi system.
  2. ide (atapi) abort/error
    By providing ide-scsi's own error/abort functions, I defer all errror handling to the scsi error handlers. I have nagging doubts about totally removing ide_do_reset() calls from them though :-(
  3. scsi (eh) abort/error
    These take much inspiration from Mike Christie's work on [1]-[4] The eh_abort gets called first, and takes an opportunistic approach (if the problem resolves itslf, great). The eh_error pulls the carpet from under the request, and does the ide_do_reset(). I hope I've not introduced any new locking/scheduling issues :-)

I've tested the patched ide-scsi with 2.6.0 - and it works fine. Too good actually, meaning the new error routines have not been adequately exercised. Any hints as to how to simulate errors at the ide subsystem level? Something like Stephen Tweedie's testdrive [11] perhaps (if applicable to char device), but for 2.6?

Linus states in [7] that ide-scsi needs a maintainer. I haven't seen anyone step forward, so that leads me to believe I may be the only person that depends enough on ide-scsi to be motivated?

If people will have me, I am prepared to take on that responsibility. I am just concerned that I may not have enough of a variety of devices to be able to thoroughly test it (unless the DI-30 is the only one :-)). What do people see as the requirements to be able to maintain ide-scsi?

OK, let me have it... Thanks, Willem Riede.


Wakko Warner suggested, half-seriously, just getting rid of both the IDE and the SCSI layers entirely, and replacing them with a generic layer that both could share. Short of that, he felt the IDE layer at least had always been ugly, and could be replaced by an IDE-to-SCSI converter, so all IDE devices would appear to be SCSI to the system.

Pete Zaitcev also replied to Willem, saying, "Based on my expirience with ide-tape, I would rather have it killed instead. One neat trick to appease enemies of ide-scsi might be to rename it into ide-scsi into ide-tape-bis. Might even add DSC bit handling... But the ide-tape is too ugly to live for sure." Willem agreed in principal, but asked, "are there any IDE tape drives currently supported by ide-tape, that are not compatble with ide-scsi plus st?" Mikael Pettersson offered, "My Seagate STT8000A works better with ide-scsi+st than with ide-tape. As long as a working ide-scsi is around, I couldn't care less about the ide-tape abomination." At this point, Bartlomiej Zolnierkiewicz said, "Both ide-tape and ide-scsi are to stay in 2.6.x and die in 2.7.x."

Elsewhere, James Bottomley also replied to Willem's initial post, saying that since no one else was interested, Willem was certainly welcome to start sending in patches; and James would look at them. He added, "In the long term, I think libata will end up assuming much of the role that ide-scsi does now, but since it doesn't interface to a lot of existing motherboard chipsets, we're going to need ide-scsi around for a while at least." Willem thanked him, adding that Linus had asked Jens Axboe to look over Willem's original patch; and Jens said he hadn't gotten to it yet, but would look it over soon.

Elsewhere, Bill Davidsen also thought it would be fine for Willem to do what he could with ide-scsi. Bill said, "here we have someone who has the need, the ambition, and the time to do this. Users of tape and MO still have need for ide-scsi, and would be happy to help test at least."

2. New kthread Threading Functions

30 Dec 2003 - 7 Jan 2004 (37 posts) Archive Link: "[PATCH 1/2] kthread_create"

Topics: Hot-Plugging

People: Rusty RussellJeff GarzikAndrew Morton

Rusty Russell posted a patch, saying:

The hotplug CPU code introduces two major problems:

  1. Threads which previously never stopped (migration thread, ksoftirqd, keventd) have to be stopped cleanly as CPUs go offline.
  2. Threads which previously never had to be created now have to be created when a CPU goes online.

Unfortunately, stopping a thread is fairly baroque, involving memory barriers, a completion and spinning until the task is actually dead.

There are also three problems in starting a thread:

  1. Doing it from a random process context risks environment contamination: better to do it from keventd to guarantee a clean environment, a-la call_usermodehelper.
  2. Getting the task struct without races is a hard: see kernel/sched.c migration_call(), kernel/workqueue.c create_workqueue_thread().
  3. There are races in starting a thread for a CPU which is not yet online: migration thread does a complex dance at the moment for a similar reason (there may be no migration thread to migrate us).

Place all this logic in some primitives to make life easier: kthread_create(), kthread_start() and kthread_destroy(). These primitives require no extra data-structures in the caller: they operate on normal "struct task_struct"s.

Other changes:

Andrew Morton suggested putting all the hotplugging patches in one location for easy review, and Rusty said, "I've had this on for a few years now. It's even at the top of the page:"

Elsewhere, Jeff Garzik really liked Rusty's work, and said:

there are two mechanisms I (and some others) felt were missing from the equally nifty workqueue stuff:

  1. one-shot threads
  2. keventd overflow

For #1, your patch seems to cover that nicely.

For #2, that's to be used for situations where (a) you need a thread context _and_ (b) you simply cannot wait for keventd to become available (since there are no time guarantees).

Rusty replied, regarding Jeff's item 1, "It's really for persistent threads, but you can use it as one-shot by either (1) calling exit() in the core function (and noone calls kthread_destroy), or (2) not having a core function and just having an init function. I used this in a test patch."

3. Linux 2.6.0-rc1-mm1

31 Dec 2003 - 4 Jan 2004 (16 posts) Archive Link: "2.6.0-rc1-mm1"

Topics: Version Control

People: Matthias UrlichsAndrew Morton

Andrew Morton posted 2.6.1-rc1-mm1, primarily to resync with the mainline 2.6 tree. Various folks posted fixes, and Matthias Urlichs also said Andrew's release was

available via Bitkeeper at <bk://>.

If you use this tree, please consider dropping me a note or whatever; I don't like to work in a vacuum...

The way I've built this, in case anybody's curious:

Oh yes, I've stopped prefixing the patch tags with mm[12]; that would get too confusing in the long run.

4. Some Problems With SuSE gcc 3.3 Prereleases

1 Jan 2004 - 5 Jan 2004 (14 posts) Archive Link: "[PATCH] disable gcc warnings of sign/unsigned comparison"

People: Paul JacksonAdrian BunkTrond MyklebustAndrew Morton

Paul Jackson posted a patch to disable gcc warnings on comparing signed and unsigned numbers, because he was seeing a lot of these when using gcc 3.3 under SuSE. In a later post he said:

Right now, compiling a 2.6.0-mm1 (what I had handy) with the 3.3 gcc on my Pentium system for arch i386 generates 1386 signed and unsigned warnings, of the two kinds:

   warning: signed and unsigned type in conditional expression
   warning: comparison between signed and unsigned

A patch that resolved these 1386 warnings would (1) generate more crap than it cleaned up, (2) immediately result in adding more bugs than removed, and (3) due to the crap level rising, generate more bugs long term than it avoided.

Andrew Morton was revolted by this, and was all set to go with Paul's path, in spite of the fact that Trond Myklebust and others felt it would be better to just fix the kernel code causing the warnings instead. But before Andrew could add the patch to his tree, Paul discovered that "the only place I can find the gcc with this bug (that -Wall implies -Wsign-compare) is the gcc 3.3 that came with my SuSE Linux 8.2 distribution. Each of the 3.3, 3.3.1 and 3.3.2 versions available at are ok - no such bug." Some folks began to speculate that the bug was in 3.3, and that is had been fixed subsequently; but elsewhere in the thread, Adrian Bunk also said, "It was _not_ a bug in gcc 3.3 . It was a bug in some _prerelease_ versions of gcc 3.3 SuSE decided to ship in a release of their distribution. There is no officially released version of gcc with this problem."

5. Some Filesystem Comparisons

2 Jan 2004 (14 posts) Archive Link: "file system technical comparisons"

Topics: FS: JFS, FS: NTFS, FS: ReiserFS, FS: ext3

People: Randy Dunlap

Steve Glines asked for a technical comparison between ext3, reiserfs, xfs jfs, and if possible any other supported filesystems. Stewart Smith said he'd done some comparisons of a number of filesystems in his honor's thesis, notable exceptions being JFS and NTFS. Someone else also gave a link to a Linux Magazine article. Randy Dunlap also gave a pointer to a comparison he'd done in the 2.4 era, which he said was quite dated and probably not so accurate anymore.

6. Minimizing The Kernel

2 Jan 2004 - 10 Jan 2004 (11 posts) Archive Link: "2.6.1-rc1-tiny1 tree for small systems"

Topics: FS: ext2, Networking, Small Systems

People: Matt MackallEric W. BiedermanAndi Kleen

Matt Mackall announced:

This is the third release of the -tiny kernel tree. The aim of this tree is to collect patches that reduce kernel disk and memory footprint as well as tools for working on small systems. Target users are things like embedded systems, small or legacy desktop folks, and handhelds.

Latest release includes:

The big bit here is SLOB, which optionally replaces the SLAB allocator and kmalloc wrappers with a traditional malloc arena and a SLAB emulation layer. SLOB is less than a tenth the size of the SLAB code and is considerably more space efficient with its allocations, but is not as fast and may prove less resistant to long-term fragmentation.

Thanks to Andi Kleen, Magnus Naeslund, and various others for their contributions and suggestions.

The patch can be found at:

Contributions and suggestions are encouraged. In particular, it would be helpful if people with non-x86 hardware could take a stab at extending some of the stuff that's currently only been done for X86 to other architectures.

Eric W. Biederman gave it a try, and found that he was able to create a 220K compressed kernel, which he felt was a huge reduction compared with other kernels. He also felt there was a lot of room for improvement, because there were many non-optional features still in Matt's tree. Matt said, "Suggestions? I'm rapidly exhausting a lot of the obvious candidates. My target build at the moment is ide + ext2 + proc + ipv4 + console, and that's currently at around 800K uncompressed, booting in a little less than 2.5MB. Hoping to get that under 2." Eric replied:

I have a 386 I really should try this out on.

Of note IPv4 is about 90K compressed. And I know you can do a minimal IPv4 stack in about 8K compressed.

My target is a minimal kernel that can be used as a bootloader. But what I am looking for at first is to be able to turn as many things off as possible so that we can test to see how much individual pieces add.

If you look at ELKS or one of the old unix like kernels you can get those down to 64K and still be usable.

I'm currently looking at removing the buffer cache, since I most of the time I don't care about disks. This is complicated by the fact that many of the default paths in the kernel when they don't have a better implementation use buffer cache methods. But I'm making headway.

Proc is one of things that frequently has loads of crap that are not needed in a minimal setup.

Until I find more candidates to turn off I can't see any low hanging fruit for shrinking in size.

Later, Eric posted a patch to remove block device support from Matt's kernel. This brought his compiled bzImage down to 191K. After some feedback, he posted a cleaner patch that also did more, and Matt merged it into his tree.

7. New Set Of Input Patches

3 Jan 2004 - 4 Jan 2004 (19 posts) Archive Link: "New set of input patches"

People: Dmitry TorokhovVojtech Pavlik

Dmitry Torokhov said to Vojtech Pavlik:

I have a new set of input patches, could you take look at them?

  1. i8042-suspend.patch
    Add suspend methods to i8042 to restore BIOS settings on suspend and kill polling timer which sometimes prevents APM suspend
  2. i8042-options-parsing.patch
    Complete conversion to the new way of parsing parameters. Drop "i8042_", "psmouse_" and "atkbd_" prefixes from option names when compiled as a module and require "i8042.", "psmouse." and "atkbd." prefixes if built into the kernel.
  3. missing-module-license.patch
    Maple and newton keyboard drivers were missing MODULE_LICENSE("GPL")
  4. kconfig-synaptics-help.patch
    Suggest psmouse.proto=imps to Synaptics users who do not want install native XFree Synaptics driver so taps would still work
  5. sis-aux-port.patch
    Do not ignore AUX port if chipset fails to disable it when we do probes as SiS is having trouble disabling but otherwise mouse works fine.

The patches are on top of 2 other input patches (remove jitter and ps2 emulation) that I have sent to the list earlier. You can find the complete set of patches at and

After some discussion and typo-hunting, Vojtech said, "Andrew, please apply these patches to your tree and/or schedule them for inclusion into mainline."

8. Web Page HTML Validity

4 Jan 2004 (2 posts) Archive Link: " Webpage validator and Web accessibility."

People: Tim Cambrant

Someone pointed out that if one were to run through the W3C HTML validator, the page would turn out invalid. Tim Cambrant replied, "You should contact the webmaster of at [email protected] about this, since it isn't a kernel-development issue. I agree though, standards should be followed, and making it valid really doesn't take long."

9. Usagi Stable Version 5 Released

4 Jan 2004 (1 post) Archive Link: "USAGI STABLE Release 5"

Topics: Networking

People: Yuji Sekiya

Yuji Sekiya announced:

We are glad to announce the USAGI STABLE RELEASE 5, dated on January 4th, 2004. This is the last major STABLE release based on linux-2.4 kernel from USAGI Project. Our primary target of development is moved to linux-2.6 kernel.

Changes from the STABLE RELEASE 4.1 are:

However, the IPsec and Mobile IPv6 implementations included in this STABLE release may not developed further. Because the IPsec stack was written for linux-2.4 kernel by USAGI Project and currently we have rewritten NEW IPsec stack for linux-2.6 kernel and the stack is included linux-2.6 mainline kernel. The IPsec stack included linux-2.6 kernel is implemented based on "xfrm" architecture and we will continue developing based on the NEW IPsec stack.

The Mobile IPv6 stack is the same situation as the IPsec. The Mobile IPv6 stack included in this release is developed by HUT GO Project and the stack is mainly written for linux-2.4 kernel. Currently USAGI Project and GO Project have started joint project for developing new Mobile IPv6 stack based on linux-2.6 kernel.

You can get our complete kit which includes kernel tree, library and applications from <>.

We also provide separate patches against the main-line kernel and the tools <>.

Many of our efforts are already in mainline kernel tree. We will continue making reasonable size patches and trying to merge it into mainline kernel tree.

We announce the latest information on our web pages. Please check our web site <>.

We also manage the mailing lists for USAGI users. If you have questions, please join the mailing list. Comments and advises are also welcome on that mailing list. Please visit <> for further information.

10. Status Of HPT372 And HPT374 IDE Controller Support

4 Jan 2004 - 5 Jan 2004 (8 posts) Archive Link: "Any hope for HPT372/HPT374 IDE controller?"

Topics: Disks: IDE

People: Andre Hedrick

Tom Wallard asked if the Highpoint HPT372 and HPT374 IDE controllers had been fixed yet. As reported way back in Issue #216, Section #3  (29 Apr 2003: 'Must-Fix' Bug List For 2.6 (Or 3.0)) , at least the HPT372N would "eat disks" in 2.5; Andre Hedrick replied:

I have a version stable for the KT400 chipset, it is the KT600 which is unstable now. As soon as I finish resolving the issues one of my customers is having with the KT600, it will be released shortly there after.

Some of the problems appear with the APIC routing and interrupts being lost and not begin processed.

Various reports followed Tom's, including some claiming to work perfectly, and others claiming to exhibit problems.

11. Linux 2.6.1-rc1-mm2 Released

5 Jan 2004 - 7 Jan 2004 (8 posts) Archive Link: "2.6.1-rc1-mm2"

Topics: Version Control

People: Andrew MortonMatthias Urlichs

Andrew Morton announced 2.6.1-rc1-mm2, saying, "Many new fixes, all over the place." Matthias Urlichs said that this release "will be bitkeeperized shortly, in fact as soon as is again reachable. :-/"

12. Linux 2.4.24 To Be Serious Bugfix Only; mremap Exploit Plugged; XFS Inclusion Delayed

5 Jan 2004 - 6 Jan 2004 (11 posts) Archive Link: "Linux 2.4.24-rc1"

Topics: FS: XFS

People: Marcelo TosattiMartin Knoblauch

Marcelo Tosatti announced 2.4.24-rc1, saying:

This release fixes a few critical problems in 2.4.23, including fixes for two security bugs.

Upgrade is recommended.

The release dealt with a recently discovered mremap vulnerability. Martin Knoblauch asked if this release postponed other changes that had already been accepted into the 2.4 pre-releases; things like XFS, in particular. Marcelo explained, "Yes. The 2.4.24-pre tree with all its modifications becomes 2.4.25-pre."

13. mremap Security Patch For 2.6

5 Jan 2004 - 8 Jan 2004 (22 posts) Archive Link: "[patchlet link] Re: 2.6.1-rc1 affected?"

Topics: Version Control

People: Linus TorvaldsBastiaan SpandawTomas Szepe

Markus Hastbacka asked if there would be a patch against 2.6 to fix the recently discovered mremap security hold. Linus Torvalds replied, "Yup. I'd actually personally prefer a stronger test than the one in 2.4.24, and my personal preference would be for just disallowing the degenerate cases entirely. I don't see a "mremap away" as being a valid thing to do, since if that is what you want, why not just do a "munmap()"?" Marcus asked why there wasn't already a new -rc release for 2.6; and Linus replied, "Because nobody actually contacted me about the problem and I read about it on linux-kernel like everybody else? Because I just got up and created the patch? And because nobody has an exploit yet, and one may be hard or impossible to create? And because people who care about these things tend to not update to x.0 kernels anyway?" He added, "They'll get a 2.6.1 soonish. The patch is in the current BK tree, will be in -rc2, and will be in 2.6.1. Let's just make sure we don't screw up the release due to being too much in a hurry either.."

At some point, Tomas Szepe asked for some sample code to prove that an exploit was possible, and Bastiaan Spandaw said, "According to a slashdot comment this is proof of concept code." . Several folks tested this on a few kernels and found it to successfully exploit the hole.

14. Hotplug Scripts Version 2004_01_05 Released

5 Jan 2004 (5 posts) Archive Link: "[ANNOUNCE] 2004-01-05 release of hotplug scripts"

Topics: Backward Compatibility, Hot-Plugging

People: Greg KH

Greg KH announced:

I've just packaged up the latest Linux hotplug scripts into a release, which can be found at:

Or from your favorite mirror at:
or for those who like bz2 packages:

I've also packaged up some pre-built (and signed) Red Hat FC 1 based rpms:

The source rpm is available if you want to rebuild it for other distros or versions of Red Hat at:

The main web site for the linux-hotplug project can be found at:
which contains lots of documentation on the whole linux-hotplug process.

This release is recommended for _anyone_ using the 2.6.0 and beyond kernels who is still using hotplug scripts older than 2003_08_05, as a number of changes have been made in order to support the 2.6 kernel properly.

The release is still backwards compatible with 2.4, so there is no need to worry about upgrading.

15. Linux 2.4.24-pre4 Released; htree Code Not Yet Merged

6 Jan 2004 - 9 Jan 2004 (12 posts) Archive Link: "Linux 2.4.25-pre4"

Topics: FS: ext2, Version Control

People: Marcelo TosattiMike Fedyk

Marcelo Tosatti said:

Moving on with the 2.4.24-pre tree, here is 2.4.25-pre4.

It contains an ext2/3 update (mostly forward compatibility related), the usual architecture updates (this time S390, PPC64/32, SH), osst update, TG3 bugfixes, amongst others.

Some of the fixes listed in this changelog (the rtc fixes, the IrDA "log buster" fix and the netfilter MASQUERADE oops) were already in other -pre's, they got removed and re added for technical BK reasons.

Mike Fedyk asked if Marcelo planned to merge the htree code, and Marcelo said yes, in the next -pre release.

16. Linus Talks About Declaring 'volatile' Variables

6 Jan 2004 (16 posts) Archive Link: "[PATCH] fix get_jiffies_64 to work on voyager"

Topics: Assembly, PCI, SMP

People: Linus Torvalds

In the course of discussion, during which the suggestion was made to declare a variable 'volatile', Linus Torvalds said:

we should _never_ make anything volatile. There just isn't any reason to. The compiler will never do any "better" with a volatile, it will only ever do worse.

If there are memory ordering constraints etc, the compiler won't be able to handle them anyway, and volatile will be a no-op. That's why we have "barrier()" and "mb()" and friends.

The _only_ acceptable use of "volatile" is basically:

That said, the "sure sign of a bug" case has one specific sub-case:

But the "jiffies" case is safe only _exactly_ because it's an atomic read. You always get a valid value - so it's actually "safe" to mark jiffies as baing volatile. It allows people to be sloppy (bad), but at least it allows people to be sloppy in a safe way.

In contrast, "jiffies_64" is _not_ an area where you can safely let the compiler read a unstable value, so "volatile" is fundamentally wrong for it. You need to have some locking, or to explicitly say "we don't care in this case", and in both cases it would be wrong to call the thing "volatile". With locking, it _isn't_ volatile, and with "we don't care", it had better not make any difference. In either case the "volatile" is wrong.

We had absolutely _tons_ of bugs in the original networking code, where clueless people thougth that "volatile" somehow means that you don't need locking. EVERY SINGLE CASE, and I mean EVERY ONE, was a bug.

There are some other cases where the "volatile" keyword is fine, notably inline asm has a specific meaning that is pretty well-defined and very useful. But in all other cases I'd suggest having the volatile be part of the code, possibly with an explanation _why_ it is ok to use volatile there unless it is obvious.

17. FUSE 1.1-pre1 Released

7 Jan 2004 (1 post) Archive Link: "[ANNOUNCE] Filesystem in Userspace (FUSE) 1.1-pre1"

People: Miklos Szeredi

Miklos Szeredi announced FUSE (Filesystem in User SpacE) version 1.1-pre1, and said:

I did a release at long last, it's got proper 2.6 kernel support and all the rest of the stuff that people contributed since 1.0.

It can be downloaded from the usual place:

18. kgdb 2.0 For 2.6.0

7 Jan 2004 (1 post) Archive Link: "kgdb 2.0 for kernel 2.6.0"

People: Amit S. KaleGeorge AnzingerAndi KleenAndrew Morton

Amit S. Kale said:

I have released kgdb 2.0 for kernel 2.6.0 for i386 and x86_64 architectures at

This version of kgdb has been supported by TimeSys Corporation and Storad Inc. It contains code from kgdb patches maintained by Andrew Morton (George Anzinger), Andi Kleen and Jim Housten.

Significant changes since previous version:

  1. This version contains three patches: architecture specific patches for i386 and x86_64 and a common patch.
  2. Automatic loading of modules in gdb is available on x86_64 platform now. Debugging of modules, including those in initrd, should be trivial with this feature.
  3. Hasslefree detach and reconnect from gdb possible on x86_64 platform also.
  4. New format of kgdb kernel command line options: kgdbwait, kgdb8250.
  5. Shadow thread to get backtraces lost when gdb can't go beyond do_IRQ.
  6. Uses new thread list packet qf instead of qL. This fixes the thread information loss previous versions of kgdb had.

19. iostat 2.0 Released

7 Jan 2004 (1 post) Archive Link: "iostat - Linux I/O performance monitoring utility"

People: Zlatko Calusic

Zlatko Calusic said:

iostat v2.0 is out!

It works flawlessly on both 2.4 & 2.6, compiles on Debian, Redhat, you name it... IOW, it's perfect. :)

Looks something like this:

                             extended device statistics
device mgr/s mgw/s    r/s    w/s    kr/s    kw/s   size queue   wait svc_t  %b
hde        0  3530    5.0   92.0    20.2 14597.8  150.6  68.1  563.2   6.0  58
hdg        0     0    0.0    0.0     0.0     0.0    0.0   0.0    0.0   0.0   0
hda        0   105  159.6   69.4   637.7   812.9    6.3  56.0  176.4   4.1  95

Find it on:

20. Using Floating Point Operations In Kernel Code

7 Jan 2004 (6 posts) Archive Link: "Use of floating point in the kernel"

People: H. Peter AnvinLinus Torvalds

Pekka Pietikainen found some cases of floating point math operations inside kernel code, which is not supposed to be allowed; H. Peter Anvin said, "Has anyone considered asking the gcc people to add an -fno-fpu (or -mno-fpu) option, throwing an error if any FP instructions are used?" Linus Torvalds replied:

We really should, but there really are some rare cases where it is actually ok.

In particular, you _can_ do math, if you just do the proper "kernel_fpu_begin()"/"kernel_fpu_end()" around it, and you have reason to believe that you can assume a math processor exists.

Is it needed? I dunno. I'd frown on it in general, but I don't see it being fundamentally wrong under the rigth circumstances.

21. Linux 2.6.1-rc3 Released

7 Jan 2004 - 8 Jan 2004 (2 posts) Archive Link: "2.6.1-rc3"

Topics: Kernel Release Announcement

People: Linus Torvalds

Linus Torvalds announced kernel 2.6.1-rc3, saying, "Not a lot to say, the ChangeLog says it all (and I include the -rc2 log too, since I forgot to actually ever post it). Mostly random smaller stuff all over. The big merges were all in rc1 and do not seem to have caused any huge headaches."

22. Linux 2.6.1-rc2-mm1 Released; Also Uptodate Against 2.6.1-rc3

7 Jan 2004 - 9 Jan 2004 (19 posts) Archive Link: "2.6.1-rc2-mm1"

Topics: Disk Arrays: RAID, FS: ext2, Framebuffer, Power Management: ACPI, Security, User-Mode Linux, Version Control

People: Andrew Morton

Andrew Morton announced:

He replied to himself, having noticed that Linus had put out 2.6.1-rc3 just moment's before Andrew's own release. He said, "2.6.1-rc2-mm1 contains everything which is in 2.6.1-rc3."

23. RAM Hotplugging And Allocation

7 Jan 2004 - 9 Jan 2004 (5 posts) Archive Link: "a new version of memory hotremove patch"

Topics: Big Memory Support, Hot-Plugging

People: Toshihiro IwamotoHirokazu Takahashi

Toshihiro Iwamoto said:

This is an update of the memory hot removal patch. As I'll merge this patch over Goto-san's hotplug patch (, this will be the final version in this standalone form. When that is done, there will be no more zone_active checks in page allocation code.

Changes from the previous version (dated 20031126) are:

Known problems:

I guess many of you think this patch has no use for yourselves, but it was at least useful for finding some kind of kernel memory leaks. :) contains some patch explaination and usage info. This page hasn't changed much since the last post.

Hirokazu Takahashi replied:

I just implemented a patch which allow us to allocate huge continuous pages easily. As We know it's very hard to allocate them on demand, since free memory on system may be fragmented. My approach is that I let annoying pages move to another place so that we can make free coninuous space on memory. Iwamoto's memory-hot-removal patch will help to do it.

I believe moving pages approach will be much better than random swaping page out approach for this purpose.

iwamoto> This is an update of the memory hot removal patch.

My patch needs the iwamoto's memory-hot-removeval patch. You should apply both of them against linux-2.6.0.

Known problems:


24. Linux Test Project January Version Released

8 Jan 2004 (1 post) Archive Link: "[ANNOUNCE] Linux Test Project January Release Announcement"

People: Robert WilliamsonRandy HronErik Andersen

Robert Williamson said:

The Linux Test Project test suite <> has been released. The latest version of the testsuite contains 2100+ tests for the Linux OS. Our web site also contains other information such as: test results, a Linux test tools matrix, technical papers and HowTos on Linux testing, and a code coverage analysis tool.

Developers from the Linux Test Project co-authored the whitepaper, "Putting Linux Reliability to the Test". This article documents the test results and analysis of the Linux kernel and other core OS components, including everything from libraries and device drivers to file systems and networking, all under some fairly adverse conditions, over a period of 60 days. You can find the paper at:

Release Highlights:

We encourage the community to post results to [email protected], and patches, new tests, or comments/questions to [email protected]

25. Keycode Problems In Recent Kernels

8 Jan 2004 - 9 Jan 2004 (2 posts) Archive Link: "Broken keycodes in recent kernels"

Topics: Microsoft, USB

People: Andries BrouwerVojtech Pavlik

Andries Brouwer said:

Just received my tenth complaint this year about the fact that kbd and recent kernels disagree as to what the right keycodes are. Since I maintain kbd it follows that recent kernels are broken.

What is right?

The old Linux convention is that for 1-88 keycode equals scancode. Above that things are a bit messy, mainly because the 128 scancodes xx and the 128 escaped scancodes e0 xx and the single combination e1 1d 45 are put into 127 keycodes, and that doesnt fit.

OK. So we want at least to preserve this 1-88 range, and may worry about the rest later. All common keys should keep their keycode. See also setkeycodes(8).

2.6 does first an untranslate and then a map to keycode, so the fact that keycode equals (translated) scancode now becomes atkbd_set2_keycode[atkbd_unxlate_table[i]] == i for i=1,...,88.

Looking at 2.6.0 we see a single mistake: scancode 84 is translated incorrectly. And many Japanese complained. Looking at 2.6.1-rc1 we see two mistakes: also scancode 85 is now mistranslated.

So, I think the change of 2.6.1-rc1 was not necessarily an improvement, but 2.6.0 needs a fix.

I can look at the details, but perhaps Vojtech wants to comment.

Vojtech Pavlik replied:

I won't argue that the 2.6.1-rc situation is correct, but I'll describe it and the difference from 2.4:

  1. Keycode 84.

    On 2.4, keycode 84 is the SysRq keycode, since historically AT keyboards do emit a different keycode for SysRq than form PrintScreen, although they're on the same key.

    On 2.6, there is only one keycode for PrintScreen, in an attempt to be a bit saner, and that is 99. And here comes my mistake - since 84 was not used anymore, I used it for the "103rd" European key.

    The 103rd key usually produces either backslash-bar or hash-tilde, or other national combo. I believe that 2.4 did emit keycode 43 for it, since this keyboard is treated the same as backslash by AT Set 2 keyboards, in hardware.

    USB keyboards, and Set 3 keyboards, however differentiate between this key and the real backslash, and since there also can be the real backslash in addition to this key on the keyboard, it makes sense to allocate a scancode to it.

    Now my snafu was that I allocated a 2.4-used scancode to it, and one that is mapped to SAK in 2.4 keymaps usually.

    This bites French, British and probably Brazilian people, too.

    I'm open to suggestions about how to fix it.

  2. Keycode 85.

    Scancode 85 (translated, set2) at the moment is not mapped to any keycode. There are other scancodes that are not mapped at all, only known scancodes are mapped, the rest should be changed by the user.

    Keycode 85 is defined as F13 (in keymaps), and is mapped to scancode 93 (both in atkbd.c and keyboard.c), which is F13, according to Microsoft documentation, which was used as reference, since that's what keyboard manufacturers tend to follow nowadays.

  3. Japanese and Korean keys.

    2.6 has unified support for Japanese and Korean keys on both USB and PS/2 keyboards.

    The keycodes are defined as:

    KEY_INTL1  181  /* Romanji */
    KEY_INTL2  182  /* Hiragana / Katakana */
    KEY_INTL3  183  /* Yen */
    KEY_INTL4  184  /* Henkan */
    KEY_INTL5  185  /* Muhenkan */
    KEY_INTL6  186  /* PC9800 KP , */
    KEY_LANG1  190  /* Hanguel */
    KEY_LANG2  191  /* Hanja */
    KEY_LANG3  192  /* Katakana */
    KEY_LANG4  193  /* Hiragana */
    KEY_LANG5  194  /* Zenkaku / Hankaku */

    These keycodes are translated back to the PS/2 scancodes in raw mode.

    The problem here lies in that that all the keycodes are above 128, and are different from what 2.4 used for these keys on an AT keyboard.

    We could go back to the 2.4 layout, where the keycodes are scattered where there was space in the translated set2 scancode list, and not even all fit there, but I think that way lies madness. The 2.6 layout is based on the USB HUT definition.







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 All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.