Problems with Yamaha CDR4416S and AHA1542
Hi, I can make packet-writing work. My system: 400MHz AMD K6-2, 128MB RAM Kernel 2.4.18-xfs, all Partitions XFS, IDE Harddisk WD 20GB Adaptec AHA1542C HP 1533A DDS3 Yamaha CDR4416S What I did: 1: patching a 2.4.18 kernel with the patch from http://w1.894.telia.com/~u89404340/patches/packet/packet-2.4.19-pre2.patch.b... 2: After installing the new kernel, I formatted a CD sucessfully 3: pktsetup /dev/pktcdvd0 /dev/sr0 - no errors, see my /var/log/messages 4. mount /dev/pktcdvd0 /mnt -t udf -o rw,noatime, no errors 5. dir /mnt - bang, process stopped. Here my /var/log/messages: Mar 13 00:12:11 kmlinux kernel: pktcdvd: inserted media is CD-RW Mar 13 00:12:11 kmlinux kernel: pktcdvd: Fixed packets, 32 blocks, Mode-2 disc Mar 13 00:12:11 kmlinux kernel: pktcdvd: speed (R/W) 6/4 Mar 13 00:12:11 kmlinux kernel: pktcdvd: 549888kB available on disc Mar 13 00:12:11 kmlinux kernel: UDF-fs DEBUG lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 Mar 13 00:12:11 kmlinux kernel: UDF-fs DEBUG super.c:1413:udf_read_super: Multi-session=0 Mar 13 00:12:11 kmlinux kernel: UDF-fs DEBUG super.c:410:udf_vrs: Starting at sector 16 (2048 byte sectors) Mar 13 00:12:12 kmlinux kernel: UDF-fs DEBUG super.c:753:udf_load_pvoldesc: recording time 1015202463/77698, 2002/03/04 02:41 (1078) Mar 13 00:12:12 kmlinux kernel: UDF-fs DEBUG super.c:763:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' Mar 13 00:12:12 kmlinux kernel: UDF-fs DEBUG super.c:770:udf_load_pvoldesc: volSetIdent[] = '3c82d0afLinuxUDF' Mar 13 00:12:13 kmlinux kernel: UDF-fs DEBUG super.c:954:udf_load_logicalvol: Partition (0:0) type 2 on volume 1 Mar 13 00:12:13 kmlinux kernel: UDF-fs DEBUG super.c:964:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=32, partition=0 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:800:udf_load_partdesc: Searching map: (0 == 0) Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:833:udf_load_partdesc: unallocatedSpaceBitmap (part 0) @ 0 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:874:udf_load_partdesc: Partition (0:0 type 1522) starts at physical 1408, block length 273248 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:1207:udf_load_partition: Using anchor in block 256 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:1440:udf_read_super: Lastblock=0 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:725:udf_find_fileset: Fileset at block=32, partition=0 Mar 13 00:12:14 kmlinux kernel: UDF-fs DEBUG super.c:786:udf_load_fileset: Rootdir at block=64, partition=0 Mar 13 00:12:14 kmlinux kernel: UDF-fs INFO UDF 0.9.5-rw (2001/10/10) Mounting volume 'LinuxUDF', timestamp 2002/03/04 01:41 (103c) Mar 13 00:12:31 kmlinux kernel: Bad segment list supplied to aha1542.c (27, 0) Mar 13 00:12:31 kmlinux kernel: 0: c0278000 4096 Mar 13 00:12:31 kmlinux kernel: 1: c02ab400 2048 Mar 13 00:12:31 kmlinux kernel: 2: c02ae000 2048 Mar 13 00:12:31 kmlinux kernel: 3: c02ae800 2048 Mar 13 00:12:31 kmlinux kernel: 4: c02ad000 2048 Mar 13 00:12:31 kmlinux kernel: 5: c02ad800 2048 Mar 13 00:12:31 kmlinux kernel: 6: c02ac000 2048 Mar 13 00:12:31 kmlinux kernel: 7: c02ac800 2048 Mar 13 00:12:31 kmlinux kernel: 8: c0007000 2048 Mar 13 00:12:31 kmlinux kernel: 9: c0007800 2048 Mar 13 00:12:31 kmlinux kernel: 10: c0006000 2048 Mar 13 00:12:31 kmlinux kernel: 11: c0005000 4096 Mar 13 00:12:31 kmlinux kernel: 12: c0006800 2048 Mar 13 00:12:31 kmlinux kernel: 13: c0004000 2048 Mar 13 00:12:31 kmlinux kernel: 14: c0277000 4096 Mar 13 00:12:31 kmlinux kernel: 15: c0276000 4096 Mar 13 00:12:31 kmlinux kernel: 16: c0004800 2048 Mar 13 00:12:31 kmlinux kernel: 17: c0275000 2048 Mar 13 00:12:31 kmlinux kernel: 18: c0275800 2048 Mar 13 00:12:31 kmlinux kernel: 19: c0274000 2048 Mar 13 00:12:31 kmlinux kernel: 20: c0274800 2048 Mar 13 00:12:31 kmlinux kernel: 21: c0273000 2048 Mar 13 00:12:31 kmlinux kernel: 22: c0272000 4096 Mar 13 00:12:31 kmlinux kernel: 23: c0c35800 2048 Mar 13 00:12:31 kmlinux kernel: 24: c0c35000 2048 Mar 13 00:12:31 kmlinux kernel: 25: c0273800 2048 Mar 13 00:12:31 kmlinux kernel: 26: c0271000 2048 Mar 13 00:12:31 kmlinux kernel: cptr c02abc00: 25 c0 11 01 00 00 e0 d9 25 c0 35 14 00 00 08 da 25 c0 <0>Kernel panic: Foooooooood fight! If I mount without option rw, than the disk can be read correctly, data which were written by an Windows 2000 Direct-CD System can also read without any error. Any hints? Thanks Manfred
On Wed, Mar 13 2002, Manfred Kreisl wrote:
Hi,
I can make packet-writing work.
I suppose that should rean "can't" :-) The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32. One fix would be to allow a packet to span two requests, however it's a bit tricky to get right. So for now the configuration is unsupported. -- Jens Axboe
Hi Jens,
I can make packet-writing work.
I suppose that should rean "can't" :-) Shure.
The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32.
Bad news.
One fix would be to allow a packet to span two requests, however it's a bit tricky to get right. So for now the configuration is unsupported.
Hmm, is there anything what I can do? Manfred
On Wed, Mar 13 2002, Manfred Kreisl wrote:
One fix would be to allow a packet to span two requests, however it's a bit tricky to get right. So for now the configuration is unsupported. Hmm, is there anything what I can do?
An easy way to get it working would be to allocate a dummy buffer_head string set where the b_page's of (at least some of them) line up. IIRC, the aha1542 restriction is only segment numbers, not actual size of the request. Then you could always just memcpy the content from the gathered packet + real data to this private buffer_head set and put that on the request list. Then you always know the segment count is within the allowed range. This would incur a 64kb memory copy per-packet, but that's not a big issue imo. -- Jens Axboe
On Thu, Mar 14 2002, Jens Axboe wrote:
An easy way to get it working would be to allocate a dummy buffer_head string set where the b_page's of (at least some of them) line up. IIRC,
That wouldn't even be necessary, btw, just single pages will do. A packet is 64kB, ie 64kB >> PAGE_SHIFT == 16 segments (for x86). This is exactly what the adapter can handle. If the buffer strings always line up, then bhN and bhN + 1 will map to the same page in b_page (only b_data will be offset in bhN + 1). -- Jens Axboe
Am Donnerstag, 14. März 2002 12:49 schrieb Jens Axboe:
That wouldn't even be necessary, btw, just single pages will do. A packet is 64kB, ie 64kB >> PAGE_SHIFT == 16 segments (for x86). This is exactly what the adapter can handle. If the buffer strings always line up, then bhN and bhN + 1 will map to the same page in b_page (only b_data will be offset in bhN + 1).
I had the same problem with the aha1542 a few years back (I bought a different scsi card then...) and as far as I remember, back then I did not think this would be possible (at least not as easy as it may appear) because what happens when you write e.g. the second and third sector in a packet is that these are put in one bh. When the elevator reads the other sectors in order to write the packet, they are not page aligned wrt to the packet. The bh string you get is then: 2k 4k 4k (12 more) 4k 2k and you need to change every single bh in the packet to get the aha1542 compatible 4k 4k 4k (12 more) 4k However, in the report that Manfred sent, this problem does not happen because the 2k bh's always come in pairs and could be merged. If it is always this way (either because you changed the behavior or because it has always been like this and my memory is getting worse ;-), I would not expect other problems. With my old aha1542 setup, I could `dd' to and from the CD without trouble as long as I used a block size > 4k, while mounting the CD or reading smaller blocks gave the same effect that Manfred is seeing. Arnd <><
On Thu, Mar 14 2002, Arnd Bergmann wrote:
Am Donnerstag, 14. März 2002 12:49 schrieb Jens Axboe:
That wouldn't even be necessary, btw, just single pages will do. A packet is 64kB, ie 64kB >> PAGE_SHIFT == 16 segments (for x86). This is exactly what the adapter can handle. If the buffer strings always line up, then bhN and bhN + 1 will map to the same page in b_page (only b_data will be offset in bhN + 1).
I had the same problem with the aha1542 a few years back (I bought a different scsi card then...) and as far as I remember, back then I did not think this would be possible (at least not as easy as it may appear) because what happens when you write e.g. the second and third sector in a packet is that these are put in one bh. When the elevator reads the other sectors in order to write the packet, they are not page aligned wrt to the packet.
That is correct, that's why I'm suggesting to always have a dummy request with a private buffer_head string allocated that you _always_ copy the data to before sending it to the drive. How many segments there are in the 'original' request and how they are layed out does not matter. -- Jens Axboe
On Wed, 13 Mar 2002, Jens Axboe wrote:
On Wed, Mar 13 2002, Manfred Kreisl wrote:
Hi,
I can make packet-writing work.
I suppose that should rean "can't" :-)
The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32.
This is now supported in the 2.5 version of the packet patch: http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.13.patch.bz... There is a new config option which when enabled makes sure to use 4kb segments, which means that 16 segments is enough for a 64kb packet. -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
Hi, Am Son, 2002-05-05 um 22.10 schrieb Peter Osterlund:
The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32.
This is now supported in the 2.5 version of the packet patch:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.13.patch.bz...
There is a new config option which when enabled makes sure to use 4kb segments, which means that 16 segments is enough for a 64kb packet.
Oh, great! Thanks for information. Now, i only have to wait for xfs-support in the 2.5.x kernel. It seems that xfs patches are not longer available for kernels later than 2.5.7, so i have to wait until xfs is merged into 2.5.x. Bye Manfred
Manfred Kreisl wrote: <SNIP>
Oh, great! Thanks for information. Now, i only have to wait for xfs-support in the 2.5.x kernel. It seems that xfs patches are not longer available for kernels later than 2.5.7, so i have to wait until xfs is merged into 2.5.x.
Not to take this off topic, but does anyone know what the XFS guys are up to? They haven't made any new releases for quite a while. --John
On Sun, May 05 2002, Peter Osterlund wrote:
On Wed, 13 Mar 2002, Jens Axboe wrote:
On Wed, Mar 13 2002, Manfred Kreisl wrote:
Hi,
I can make packet-writing work.
I suppose that should rean "can't" :-)
The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32.
This is now supported in the 2.5 version of the packet patch:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.13.patch.bz...
There is a new config option which when enabled makes sure to use 4kb segments, which means that 16 segments is enough for a 64kb packet.
I disagree with making this an explicit option, it would be far better to find the host the particular device is on and check for scatter gather limits. It's all right there in the request queue (hint: nr_phys_segments) -- Jens Axboe
On Mon, 6 May 2002, Jens Axboe wrote:
On Sun, May 05 2002, Peter Osterlund wrote:
On Wed, 13 Mar 2002, Jens Axboe wrote:
On Wed, Mar 13 2002, Manfred Kreisl wrote:
Hi,
I can make packet-writing work.
I suppose that should rean "can't" :-)
The problem is that you have the your CD-RW on the 1542 adapter. That only supports 16 segments in a request, packet writing typically needs 32.
This is now supported in the 2.5 version of the packet patch:
http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.13.patch.bz...
There is a new config option which when enabled makes sure to use 4kb segments, which means that 16 segments is enough for a 64kb packet.
I disagree with making this an explicit option, it would be far better to find the host the particular device is on and check for scatter gather limits. It's all right there in the request queue (hint: nr_phys_segments)
Thanks for the hint. The 2.5.14 patch implements your suggestion: http://w1.894.telia.com/~u89404340/patches/packet/2.5/packet-2.5.14.patch.bz... -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (6)
-
Arnd Bergmann -
Jens Axboe -
Johnathan Hicks -
Manfred Kreisl -
Manfred Kreisl -
Peter Osterlund