Table Of Contents
|1.||3 Nov 2003 - 17 Nov 2003||(132 posts)||Status Of IDE-SCSI Maintainance|
|2.||6 Nov 2003 - 19 Nov 2003||(122 posts)||kernel.bkbits.net Down For Security Reasons; arch Proposed As BitKeeper Alternative|
|3.||10 Nov 2003 - 14 Nov 2003||(26 posts)||Maximum Partition Sizes Under 2.4 And 2.5|
|4.||14 Nov 2003||(1 post)||LKST v2.0.0 Released For 2.6.0-test9|
|5.||16 Nov 2003 - 17 Nov 2003||(3 posts)||Status Of SCSI Drivers|
|6.||16 Nov 2003 - 18 Nov 2003||(4 posts)||Version 0.17 Of Forcedeth Released|
|7.||18 Nov 2003||(2 posts)||Trouble Bringing The BK-CVS Gateway Back Online|
|8.||18 Nov 2003 - 19 Nov 2003||(2 posts)||Status Of e-Galax USB Touchscreen Support In 2.4|
|9.||19 Nov 2003||(4 posts)||Status Of Experimental Net Driver Updates|
|10.||19 Nov 2003||(1 post)||BK->CVS Gateway Back Online|
|11.||19 Nov 2003||(1 post)||Some ACPI Bug Fixes For 2.6|
|12.||19 Nov 2003||(1 post)||Version 0.18 Of Forcedeth Released|
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. Cheemplavam, Bill Davidsen, Linus Torvalds, John 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.
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:
NOBODY IS SENDING ME PATCHES.
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. kernel.bkbits.net Down For Security Reasons; arch Proposed As BitKeeper Alternative
6 Nov 2003 - 19 Nov 2003 (122 posts) Subject: "kernel.bkbits.net off the air"
Topics: BSD, Version Control
People: Larry McVoy, H. Peter Anvin, Andrew Walrond, Andrea Arcangeli, Samium Gromoff, Davide Libenzi, Jan Harkes, Zack Brown, Tom Lord
Larry McVoy reported:
As many of you have figured out, I took kernel.bkbits.net (aka bk.kernel.org, cvs.kernel.org, and svn.kernel.org) 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 kernel.org machines. Doubt it's a big deal with the timing, though." And Larry replied, "Last I checked, kernel.org 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 kernel.org." 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 (http://gnuarch.org/bin/view) 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 Chubb, Randy Dunlap, Mike 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 Notes: #: 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.
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 Perez, Meelis Roos
Xose Vazquez Perez posted:
* unofficial LiNUX kernel SCSI/RAID drivers list *
Sun Nov 16 17:38:00 CET 2003
hot-plug vary_io highmem_io block_device_driver 64_bit_SG
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*adaptec.com> <markh*AT*osdl.org>
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: <mike.miller*AT*hp.com> <arrays*AT*hp.com>
manufacturer: LSI Logic
kernel: 2.4.11 (11 Oct 2001)
latest: 2.4.20 (01 May 2003)
arch: i386 ia64 alpha
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
arch: i386 ia64 ppc
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
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*lsil.com> <mpt_linux_developer*AT*lsil.com>
kernel: 2.05 (03 Oct 2002)
latest: 2.06a (04 Aug 2003)
arch: i386 alpha ia64
maintainer: <achim.leubner*AT*intel.com> <johannes_dinner*AT*adaptec.com>
arch: i386 ia64
maintainer: <david_jeffery*AT*adaptec.com> <ipslinux*AT*adaptec.com>
manufacturer: LSI Logic
maintainer: <atulm*AT*lsil.com> <linux-megaraid-devel*AT*dell.com>
arch: i386 alpha powerpc sparc
manufacturer: LSI Logic
kernel: 2.1.17a (Dec 01 2001)
latest: 2.1.19-pre3 (Nov 23 2002)
arch: i386 alpha sparc powerpc ia64
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 http://www.hailfinger.org/carldani/linux/patches/forcedeth/
Fixes in this release over 0.14:
7. Trouble Bringing The BK-CVS Gateway Back Online
18 Nov 2003 (2 posts) Subject: "bkcvs at rsync.kernel.org not up-to-date?"
Topics: Version Control
People: Pavel Machek, Larry 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 kernel.org 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 Bogusz, James 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): http://cvs.pld-linux.org/SOURCES/touchkit-2.4.20.patch. (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 Garzik, Alexander 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 email@example.com 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 master.kernel.org 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 http://linux-acpi.bkbits.net/linux-acpi-release-2.6.0
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:
1390: adds cmdline to allow manual over-ride if out policy of forcing the ACPI SCI to level triggered is wrong.
If we don't apply, some folks with no ACPI events will need to patch.
1177: makes print_IO_APIC() output useful instead of garbage.
If we don't apply, then we need to send this patch to anybody who has an IO-APIC mode interrupt issue in ACPI mode.
1434: 1-line panic fix
BIOS with correct ACPI table check-sums but garbled data can cause panic immediately after loading with no kernel output unless this is fixed.
a plain patch is also available here: ftp://ftp.kernel.org/pub/linux/kernel/people/lenb/acpi/patches/release/2.6.0-test9/acpi-20031002-2.6.0-test9.diff.gz
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 http://www.hailfinger.org/carldani/linux/patches/forcedeth/ It is also integrated in 2.6.0-test9-mm4.
Fixes in this release over 0.17:
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.