Kernel Traffic #242 For 24 Nov 2003

By Zack Brown

Table Of Contents

Mailing List Stats For This Week

We looked at 1076 posts in 4864K.

There were 357 different contributors. 168 posted more than once. 131 posted last week too.

The top posters of the week were:

1. Status Of IDE-SCSI Maintainance

3 Nov 2003 - 17 Nov 2003 (132 posts) Subject: "2.9test9-mm1 and DAO ATAPI cd-burning corrupt"

Topics: Disks: IDE, Disks: SCSI, Ioctls, Serial ATA

People: Prakash K. CheemplavamBill DavidsenLinus TorvaldsJohn Bradford

Prakash K. Cheemplavam reported, "I am using k3b0.10.1 and either choosing cdrdao or cdrecord in DAO mode to burn the cd ends up in non-bit identical copies, wheres ion TAO (atleast with my 10x CD-RW I tested) the copy succeded." Later he added that the data was not actually corrupted, "but in a way truncated in DAO mode: When I read out the image from the CD-RW drive, about 5kbyte are missing at the end (and doing several burn, it is always the same amount). Strange enough if I read the DAO burnt disk out by my DVD-ROM, the image can be read out completely!" A couple posts later, he clarified, "The data is on the disc, as my DVD-ROM restores the full image (md5sum matches), but the CD-RW does not." Bill Davidsen replied, "There is a problem with ide-scsi in 2.6, and rather than fix it someone came up with a patch to cdrecord to allow that application to work properly, and perhaps "better" in some way. Since the problem with ide-scsi seems to still exist for other applications, you will probably find you have to work around the problem, by using the -pad option of cdrecord (thought that was standard now for TAO at least) or reading using the ide-cd driver." And Linus Torvalds replied:


The "somebody" strongly felt that ide-scsi was not just ugly but _evil_, and that the syntax and usage of "cdrecord" was absolutely stupid.

That somebody was me.

ide-scsi has always been broken. You should not use it, and indeed there was never any good reason for it existing AT ALL. But because of a broken interface to cdrecord, cdrecord historically only wanted to touch SCSI devices. Ergo, a silly emulation layer that wasn't really worth it.

The fact that nobody has bothered to fix ide-scsi seems to be a result of nobody _wanting_ to really fix it.

So don't use it. Or if you do use it, send the fixes over.

John Bradford said:

Hmmm, but ide-scsi is used for a lot more than cd recorders these days. Alan mentioned 'crazy' SATA devices back in April.

(Not that I'm suggesting that it is particularly sane to deal with an SATA connected printer by presenting it as a SCSI device, but I just can't see how ide-scsi could successfully be removed now :-( )

And Bill replied, "And I don't see the joy of doing so. Unless someone wants to write new versions of all the SCSI software out in use, a lot of functionality is lost. In the long run it might have been better to simply fix or rewrite ide-scsi and stop using the ide interface, becuase disk manufacturers certainly aren't going to stop making scsi and it needs to be supported anyway. I guess Doug Gilbert is doing other things now, I would have expected at least an opinion out of him ;-)" He also said, "I mentioned ide tapes and ZIP drives, Linus didn't mention how one gets around those." To which Linus replied:

The thing is, the non-ide-scsi interfaces really _should_ work. The fact is, SG_IO ("send a SCSI command") just _works_.

However, right now only the CD-ROM driver exposes those commands. Why? Because nobody has apparently cared enough about those theoretical IDE tapes and ZIP drives.

In other words, they seem to "exist" in the same sense that soubdblaster CD-ROM users "exist". True in theory, but apparently only really useful for theoretical arguments.

Getting SCSI command support is not complicated: you add

ret = scsi_cmd_ioctl(dev, cmd, arg);

to your ioctl routine. Of course, since so far nobody seems to have cared about anything but CD writing, it's not really tested for anything else.

Bill replied ryely:

I take it that if the IDE maintainer and you don't use a device it will not be supported in the future? There's nothing theoretical about ZIP drives and ATAPI tape drives, you can order them mail order or buy them at any computer show. And 2.4 ide-scsi seems to support them perfectly, or at least usefully, which is probably why there haven't been any complaints.

I admit I can't understand why 2.6 supports old NICs and motherboard chipsets which haven't been made in five years, and then deliberately desupports devices which did work and which are available at computer stores and mail order today.

Linus said:

Those other devices have people MAINTAINING THEM AND CARING!

What's so horribly hard to understand about this? You're barking up the wrong tree.

Again, I tell you once more:

Get it now?

So come back to me when you find somebody who cares enough about the devices you claim exists enough that he actually _does_ something about it.

Bill again insisted that there were lots of users using the hardware; and he and Linus went back and forth, with Bill saying a strong user-base existed for the hardware, and Linus saying that someone had to submit patches in order for hardware to be supported. At one point Linus shouted:


What part of "open source" do you not understand?

SATA devices work fine. They have all the SCSI infrastructure working for them. They'll "just work", even though I fervently hope that we can move them over to the block device layer later to make them work more efficiently.

As per the MO device that wants ide-scsi, send out patches to the kernel mailing list, and maybe the person can test it. I certainly can't test it.

My point is that YOU ARE BARKING UP THE WRONG TREE. It does not help to complain to me - since I don't even have the hardware to test anything with. I fixed the IDE CD burning issue. That I had hardware for, and knew how to fix properly.

Now it's your turn. Instead of wasting my time complaining, how about you put up or shut up? Show me the code. THEN post it. Until you do, there's no point to your mails.

They did not reach agreement during the thread.

2. Down For Security Reasons; arch Proposed As BitKeeper Alternative

6 Nov 2003 - 19 Nov 2003 (122 posts) Subject: " off the air"

Topics: BSD, Version Control

People: Larry McVoyH. Peter AnvinAndrew WalrondAndrea ArcangeliSamium GromoffDavide LibenziJan HarkesZack BrownTom Lord

Larry McVoy reported:

As many of you have figured out, I took (aka,, and of the air yesterday due to the breakin that attempted to add a trojan horse to the kernel source.

I took it down after talking with Linus and Dave about it, the point was to shut down the disk drive so that we can go do forensics on it after the fact and see what we can figure out. Maybe someone can track down who caused the problem.

This means someone has to go down to the colo with a new disk and do an install and we've been too busy to do this. Would anyone object if this wasn't done until this weekend? We're pretty booked up here with other work. Last I checked only about 6 IP addresses where using the CVS server, I've never checked on the SVN server (Ben? You have any idea?).

H. Peter Anvin put in, "That doesn't include anyone who uses the mirrored repository on the main machines. Doubt it's a big deal with the timing, though." And Larry replied, "Last I checked, isn't offering pserver access, just ftp. If you want to take over the CVS access just say the word." H. Peter said, "No, we don't do the pserver access, but some people get the whole repository through the mirror. The current division seems to work well, so I don't see any reason to change it." Close by, Davide Libenzi mentioned that rsync was actually better than straight CVS for synchronization, and Larry said, "If that's the preferred interface then maybe we should shut down the pserver completely and let people rsync it from" But Davide said he couldn't speak for everyone, and that some folks might prefer accessing the tree directly through CVS.

Elsewhere, in the course of discussion, Andrew Walrond suggested, "Persuade Larry to release a 'clone/pull-only' version of bk which *anyone* can use to access open source software" and Larry said, "I'd be far more likely to build a sort of CVS like client that could do checkouts and updates of read only files. That's a pretty straightforward thing to do, in fact, nobody needs BK source to do that, it could all be done as wrappers pretty trivially. If someone wanted to code that up and make the code available under a BSD license we'd take a good look at adding that into the BK server side. It doesn't need to be bundled in BK however. Anyone could write a daemon that locally called BK to get the data and a client that talked to the daemon. The hard part is renames but even that can be handled reasonably easily."

At this point Andrea Arcangeli suggested that the arch ( revision control system was up to the task of hosting Linux kernel development, "but we need to checkout a coherent cvs to import the data into arch." Samium Gromoff replied:

i propose to go further than that.

I hope that Larry recognises that at some point the linux kernel community _will_ switch to a free software alternative.

I think we should have a better choice than the lossy bk->cvs.

I propose we as a whole ask Larry to create a bk->arch gateway _not_ via cvs but directly, and therefore using all the extended metadata possible.

The choice of Arch is not random, but motivated by my belief in that it is the leading Free Software revision control effort.

If Larry wishes to give a birth to this idea, the list to contact is:

Jan Harkes, an arch user, pointed out that there would be significant pain involved in any transition from BitKeeper to another tool; also, he felt that arch was not yet ready to scale to the size of the kernel project. Finally, he thought it was absurd to ask for Larry's help in migrating away from Larry's own product. Samius said that his suggestion was only that Larry provide a better gateway than CVS, not that Larry help the kernel developers switch away from BitKeeper.

(ed. [Zack Brown] Having used arch and read its mailing list for many months, I can say that arch has come a long, long way. It is fast, robust, and capable of hosting very large projects; and in my opinion represents a great leap forward in revision control systems. If it is not yet up to the scale of the Linux kernel, it is still easily up to many of the large projects out there. Its only major drawback is that Tom Lord, the maintainer, is extremely unreceptive to newcomers, and tends to flame beginners after an initial pretense of politeness. You heard it here first. I recommend that folks definitely try arch for their projects, but read and learn all the available documentation before asking anything on the mailing list.)

3. Maximum Partition Sizes Under 2.4 And 2.5

10 Nov 2003 - 14 Nov 2003 (26 posts) Subject: "2 TB partition support"

Topics: Disk Arrays: LVM, FS: JFS, FS: ReiserFS, FS: XFS, FS: ext2

People: Peter ChubbRandy DunlapMike Fedyk

Joseph Shamash asked if it were possible (and if so, how) to create a 2 terabyte partition under Linux. Peter Chubb replied:

Yes you can do it.

You need a 2.6 kernel. And it's best to use something other than the MSDOS partition format --- I suggest you use parted to create a GPT partition table (which means compiling your kernel to understand that format).

You didn't say what architecture you're running on. If it's a 64-bit system you don't have to do anything else. If it's a 32-bit system, then turn on CONFIG_LBD when you compile.

Joseph also asked the maximum parition size under the 2.4 kernel; Mike Fedyk replied that he believed the maximu was 16 terabytes per block device, under either 2.6 or a patched 2.4 kernel. But Peter said:

That's right for 32-bit systems with 4k pages. For 64 bit systems the limit is over 8 Exabytes.

You should note that software raid has smaller limits, as does the LVM. Also the 2.4 patches have seen *much* less testing than the 2.6 mainline (except possibly on the SGI Altix).

Randy Dunlap also said:

I made the table below for LinuxWorld Expo/Conference in Aug. 2002, for Linux 2.4.x on 32-bit architectures, so it is a bit out of date, but it might be helpful or useful.

Linux 2.4 filesystem limits on 32-bit architectures, with 4 KB block sizes:

                     ext2/3fs    reiserfs     JFS       XFS#
max filesize:          4 TB&      16 TB$     16 TB$%  16 TB$
max filesystem size:  16 TB&      16 TB&     16 TB$   16 TB$
                                              4 PB&    8 EB&
kernel bldev limit:    2 TB        2 TB       2 TB     2 TB

#: all kernel limits
$: kernel limit
%: 4 KB pages
@: block device limit: 2 TB (or 1 TB if signed)
&: fs limit

4. LKST v2.0.0 Released For 2.6.0-test9

14 Nov 2003 (1 post) Subject: "LKST v2.0.0 is released (Kernel v2.6.0-test9)"

People: Yumiko Sugita

Yumiko Sugita announced:

I'd like to announce publication of Linux Kernel State Tracer (LKST) version 2.0.0, which is a tracer for Linux kernel. LKST is a useful tool for analyzing Kernel fault and evaluating of Kernel.

LKST v2.0.0 is for Kernel version 2.6.0-test9(*). And platforms of LKST 2.0.0 are both IA32 and IA64. The details are described in changes-2.0.0.txt.

LKST v2.0.0 is also for Kernel version 2.6.0-test8. After you executed LKST patches, please change EXTRAVERSION value in Makefile of Kernel to test8-lkst.


for supporting IA64, we changed some codes in the following programs.

  • KernelHooks

LKST binaries, source code and documents are available in the following site,

We prepared a mailing list written below in order to let users know update of LKST.

To subscribe, please refer following URL,

And if you have any comments, please send to the above list, or to another mailing-list written below.

5. Status Of SCSI Drivers

16 Nov 2003 - 17 Nov 2003 (3 posts) Subject: "[summary] state of scsi drivers"

Topics: BSD: FreeBSD, Big Memory Support, Disk Arrays: RAID, Disks: SCSI, Hot-Plugging, I2O

People: Xose Vazquez PerezMeelis Roos

Xose Vazquez Perez posted:

* unofficial LiNUX kernel SCSI/RAID drivers list *


Sun Nov 16 17:38:00 CET 2003

x features:
   hot-plug vary_io highmem_io block_device_driver 64_bit_SG

o aacraid
   manufacturer: ADAPTEC
   kernel: 1.1.2 (15 May 2003)
   latest: 1.1.4 (31 Oct 2003)
   arch: i386 ia64 x86_64(amd64) alpha (sparc not confirmed, but expected)
   features: highmem_io 64_bit_SG
   maintainer: <Mark_Salyzyn*AT*> <markh*AT*>
               <aacraid*AT*> <linux-aacraid-devel*AT*>

o aic7xxx/aic79xx
   manufacturer: ADAPTEC
   kernel: 6.2.36/1.3.10 (03 Jun 2003)
   latest: 6.3.3 /2.0.4 (06 Nov 2003)
   arch: i386 ia64 powerpc
   maintainer: <gibbs*AT*>

o cciss
   manufacturer: HP
   kernel: 2.4.50
   latest: 2.4.50
   arch: i386
   features: block_device_driver
   maintainer: <mike.miller*AT*> <arrays*AT*>

o DAC960
   manufacturer: LSI Logic
   kernel: 2.4.11 (11 Oct 2001)
   latest: 2.4.20 (01 May 2003)
   arch: i386 ia64 alpha
   features: block_device_driver
   maintainer: <dmo*AT*>

o dpt_i2o
   manufacturer: ADAPTEC
   kernel: 2.4.5 (25 Jul 2001)
   latest: 2.5.0 (11 Sep 2003)
   arch: i386 ia64 alpha sparc x86_64(amd64)
   features: highmem_io 64_bit_SG
   maintainer: <Mark_Salyzyn*AT*>

o emulex
   manufacturer: EMULEX
   kernel: -
   latest: 1.23a
   arch: i386 ia64 ppc
   maintainer: <*AT*>

o feral_isp
   manufacturer: QLOGIC
   kernel: -
   latest: Linux Platform 2.1 Common Core Code 2.7 (13 Nov 2003)
   arch: i386 alpha sparc powerpc
   features: alternative driver for all qlogic products
   maintainer: <mjacob*AT*>

o fusion
   manufacturer: LSI Logic
   kernel: 2.05.05+ (14 Apr 2003)
   latest: 2.05.10 (10 Oct 2003)
   arch: i386 alpha sparc ia64 x86_64
   maintainer: <emoore*AT*> <mpt_linux_developer*AT*>

o gdth
   manufacturer: ADAPTEC
   kernel: 2.05 (03 Oct 2002)
   latest: 2.06a (04 Aug 2003)
   arch: i386 alpha ia64
   maintainer: <achim.leubner*AT*> <johannes_dinner*AT*>

o ips
   manufacturer: ADAPTEC
   kernel: 6.00.26
   latest: 6.00.26
   arch: i386 ia64
   maintainer: <david_jeffery*AT*> <ipslinux*AT*>
   url: -

o megaraid
   manufacturer: LSI Logic
   kernel: v1.18k/v2.00.9
   latest: v1.18k/v2.00.9
   arch: i386
   maintainer: <atulm*AT*> <linux-megaraid-devel*AT*>

o qla1280
   manufacturer: QLOGIC
   kernel: 3.23.37
   latest: 3.23.37
   arch: i386 alpha powerpc sparc
   maintainer: <jes*AT*>
   url: -

o qla2x00
   manufacturer: QLOGIC
   kernel: -
   latest: 6.06.10
   beta: 8.00.00b6
   arch: i386
   maintainer: <andrew.vasquez*AT*>

o sym53c8xx_2
   manufacturer: LSI Logic
   kernel: 2.1.17a (Dec 01 2001)
   latest: 2.1.19-pre3 (Nov 23 2002)
   arch: i386 alpha sparc powerpc ia64
   maintainer: <groudier*AT*>

Regarding the qla1280, Meelis Roos remarked, "qla1280 doesn't work on sparc (neither 2.4 nor 2.6) since it uses flush_cache_all symbol from MM internals and there's no such internal function on sparc."

6. Version 0.17 Of Forcedeth Released

16 Nov 2003 - 18 Nov 2003 (4 posts) Subject: "forcedeth: version 0.17 available"

Topics: FS: sysfs

People: Carl-Daniel Hailfinger

Carl-Daniel Hailfinger announced:

version 0.17 of forcedeth for Linux 2.4 and 2.6 is available at

Fixes in this release over 0.14:

Known issues:

Please test.

7. Trouble Bringing The BK-CVS Gateway Back Online

18 Nov 2003 (2 posts) Subject: "bkcvs at not up-to-date?"

Topics: Version Control

People: Pavel MachekLarry McVoy

Pavel Machek asked, "Web interface indicates last change 22 hours ago, yet rsync indicates nothing new. I know that bkcvs was supposed to be down over weekend, but I thought it should be up by now?" Larry McVoy replied:

It's still down. The machine got moved from one colo to another and when we went down there to find it it was nowhere to be found. So they are tracking it down and we'll try and get it up tomorrow.

I've offered to update the rsync tree on directly if HPA figures out how to turn on my account (something I've been waiting on for at least a year, hint, hint).

8. Status Of e-Galax USB Touchscreen Support In 2.4

18 Nov 2003 - 19 Nov 2003 (2 posts) Subject: "e-Galax USB touchscreens and 2.4"

Topics: Touchscreen, USB

People: Jakub BoguszJames Lamanna

James Lamanna asked if e-Galax USB touchscreens worked under Linux 2.4; the module on the company web site seemed broken. Jakub Bogusz replied, "I had a terminal with eGalax touchscreen for tests some time ago and it worked. But for new USB core (Linux 2.4.20+) it required a patch (unpatched driver worked on 2.4.18 but caused Oops on 2.4.20): (yes, it uses old GNU-style initializers, now I would use C99-style)"

9. Status Of Experimental Net Driver Updates

19 Nov 2003 (4 posts) Subject: "[CFT] 2.6.x experimental net driver updates"

People: Jeff GarzikAlexander Viro

Jeff Garzik announced:

Ok, Al Viro's net driver refcounting work is pretty much complete, and shemminger/ogawa NAPI conversation of 8139too is also merged.

Please beat this up as much as possible. Don't let the "experimental" tag fool you... these changes should be solid, and will be going to Andrew/Linus when the 2.6.0 tree re-opens.

Don't forget to CC on all feedback.

Alexander Viro replied, "The hell it is" [complete]. He went on:

We are through with legacy probes, we are through with init_etherdev(), we are practically through with static struct net_device.

However, we still have weird allocators (I've got almost all of them done by now, will submit in the next batch) and we still have struct net_device embedded as a field of other structures in several drivers.

It's nowhere near as massive as legacy probes series, but it's going to be 10--20 patches. At least.

10. BK->CVS Gateway Back Online

19 Nov 2003 (1 post) Subject: "BK2CVS tree is back"

Topics: Version Control

People: Larry McVoy

Larry McVoy announced, "I just updated the copy on and I'll be updating that directly from now, nightly, at about 3am PST. It will probably take a couple of days before I have the bugs worked out but there is a fresh up to date copy there now. Thanks to HPA for fixing my account and other admin help."

11. Some ACPI Bug Fixes For 2.6

19 Nov 2003 (1 post) Subject: "[BKPATCH] ACPI 2.6"

Topics: Power Management: ACPI, Version Control

People: Len Brown

Len Brown said:

Linus, please do a

bk pull

The world will not stop revolving if these wait till 2.6.1, but it will make 2.6.0 easier to support if they're included.

3 bug fixes -- all are in 2.4:

a plain patch is also available here:

12. Version 0.18 Of Forcedeth Released

19 Nov 2003 (1 post) Subject: "forcedeth: version 0.18 available"

People: Carl-Daniel Hailfinger

Carl-Daniel Hailfinger announced:

version 0.18 of forcedeth for Linux 2.4 and 2.6 is available at It is also integrated in 2.6.0-test9-mm4.

Fixes in this release over 0.17:

Known issues:

Please test.







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.