Kernel Traffic #242 For 24 Nov 2003

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

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

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:

Wrong.

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.

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

http://marc.theaimsgroup.com/?l=linux-kernel&m=105000779411632&w=2

(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.

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:

for burning IDE CD-ROM's you should use the IDE driver. Not ide-scsi. End of discussion. It's a supported and _improved_ situation from where it was in 2.4.x.
For all those devices you claim exists, show me the patches. Nobody broke ide-scsi on purpose - but the fact is that nobody also ever came forward and _fixed_ it.

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.

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

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 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.

this way we`ll get whole-tree changesets, file renames etc.
this way Larry will have a terrific argument to shut whiners.

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:

gnu-arch-users@gnu.org

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.)

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).

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

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.

Remarks:

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

KernelHooks

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

http://sourceforge.net/projects/lkst/
http://sourceforge.jp/projects/lkst/

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

lkst-users@lists.sourceforge.net
lkst-users@lists.sourceforge.jp

To subscribe, please refer following URL,

http://lists.sourceforge.net/lists/listinfo/lkst-users
http://lists.sourceforge.jp/mailman/listinfo/lkst-users

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

lkst-develop@lists.sourceforge.net
lkst-develop@lists.sourceforge.jp

* unofficial LiNUX kernel SCSI/RAID drivers list *

<xose@wanadoo.es>

linux-2.4.23-rc1
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*adaptec.com> <markh*AT*osdl.org>
               <aacraid*AT*adaptec.com> <linux-aacraid-devel*AT*dell.com>
   url: http://linux.adaptec.com
        http://www.domsch.com/linux/#aacraid

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
   features:
   maintainer: <gibbs*AT*scsiguy.com>
   url: http://people.freebsd.org/~gibbs/linux/SRC/

o cciss
   manufacturer: HP
   kernel: 2.4.50
   latest: 2.4.50
   arch: i386
   features: block_device_driver
   maintainer: <mike.miller*AT*hp.com> <arrays*AT*hp.com>
               <Cciss-discuss*AT*lists.sourceforge.net>
   url: http://sf.net/projects/cciss/

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*osdl.org>
   url: http://www.osdl.org/archive/dmo/DAC960/
        http://www.dandelion.com/Linux/DAC960.html

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*adaptec.com>
   url: http://linux.adaptec.com

o emulex
   manufacturer: EMULEX
   kernel: -
   latest: 1.23a
   arch: i386 ia64 ppc
   features:
   maintainer: <tech.support*AT*emulex.com>
   url: http://www.emulex.com/ts/docfc/linuxos.shtml

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*feral.com>
   url: http://www.feral.com/isp.html

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
   features:
   maintainer: <emoore*AT*lsil.com> <mpt_linux_developer*AT*lsil.com>
   url: ftp://ftp.lsil.com/HostAdapterDrivers/linux/

o gdth
   manufacturer: ADAPTEC
   kernel: 2.05 (03 Oct 2002)
   latest: 2.06a (04 Aug 2003)
   arch: i386 alpha ia64
   features:
   maintainer: <achim.leubner*AT*intel.com> <johannes_dinner*AT*adaptec.com>
   url: http://www.icp-vortex.com/english/download/rz_neu/8x24/linux/linux_e.htm

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

o megaraid
   manufacturer: LSI Logic
   kernel: v1.18k/v2.00.9
   latest: v1.18k/v2.00.9
   arch: i386
   features:
   maintainer: <atulm*AT*lsil.com> <linux-megaraid-devel*AT*dell.com>
   url: ftp://ftp.lsil.com/pub/linux-megaraid/
        http://domsch.com/linux/#megaraid

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

o qla2x00
   manufacturer: QLOGIC
   kernel: -
   latest: 6.06.10
   beta: 8.00.00b6
   arch: i386
   features:
   maintainer: <andrew.vasquez*AT*qlogic.com>
   url: http://www.qlogic.com/support/product_resources.asp?id=339
        http://sf.net/projects/linux-qla2xxx/

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
   features:
   maintainer: <groudier*AT*free.fr>
   url: http://www.tux.org/pub/tux/roudier/drivers/linux/stable/

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."

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

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:

0.15: 08 Nov 2003: fix smp deadlock with set_multicast_list during open.
0.16: 15 Nov 2003: include file cleanup for ppc64, rx buffer size increased to 1628 bytes.
0.17: 16 Nov 2003: undo rx buffer size increase. Substract 1 from the tx length.

Known issues:

Oops during module removal, probably sysfs related. Could a sysfs expert please take a look at the code? Call trace is at http://www.ussg.iu.edu/hypermail/linux/kernel/0311.1/0213.html More traces (roughly the same) available on request.
Some boards give bogus MAC addresses and work only partially. Same problem happens with nvnet on these boards.
Transmit for packets close to MTU size was broken, should be fixed now.

Please test.

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).

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)"

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 netdev@oss.sgi.com on all feedback.

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.

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."

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


Kernel Traffic Latest \| Archives \| People \| Topics	Wine Latest \| Archives \| People \| Topics	GNUe Latest \| Archives \| People \| Topics
Czech

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

Kernel Traffic #242 For 24 Nov 2003

By Zack Brown