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.
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.
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.
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:
- 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.
They did not reach agreement during the thread.
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 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.
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
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.
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.jpTo subscribe, please refer following URL,
http://lists.sourceforge.net/lists/listinfo/lkst-users
http://lists.sourceforge.jp/mailman/listinfo/lkst-usersAnd 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
Xose Vazquez Perez posted:
* unofficial LiNUX kernel SCSI/RAID drivers list *
<xose@wanadoo.es>
linux-2.4.23-rc1
Sun Nov 16 17:38:00 CET 2003x features:
hot-plug vary_io highmem_io block_device_driver 64_bit_SGo 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/#aacraido 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.htmlo 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.como 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.shtmlo 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.htmlo 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.htmo 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/#megaraido 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.
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:
- 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)
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 netdev@oss.sgi.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.
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.
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
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:
- Avoid Oops on rmmod.
Known issues:
- Some boards give bogus MAC addresses and work only partially. Same problem happens with nvnet on these boards.
- Possible system slowdown during periods of extreme network load, fix is currently being tested.
Please test.