Arnd Bergmann wrote:
Am Donnerstag, 3. Januar 2002 22:42 schrieben Sie:
A rather old "CRW6416S" on a aic7xxx controller. It first did not work because I had an ISA SCSI card (aha1542) and AFAIR that does not work with scatter/gather the way that is needed by pktcdvd (more that 16 segments in one request).
Maybe this is my problem as well... No, you don't have an ISA card and it also does more that 16 segments per request (something like 128, I think).
Ah so. I thought the problem is on device side, not on the card side. Anyway, there are some problems with the latest aic7xxx driver, I have to boot twice after powerup, because the first start fails with "kerel panic: Loop 1" which is known and reported problem caused by some rewrite of the driver. But packet writing didn't work even with the older driver. The card and all the devices attached work well otherwise.
But it sucessfully writes some data before having problems. Well, that part actually _is_ the same with the aha1542 problem, just for a different reason.
I've done some more tests: dd-in exactly 16MB, either in 64kb ok 2kb blocks works perfectly (readback and cmp), but if I try something 64kb unaligned (I was testing dd-in of 260kb), the pktcdvd has problems prereading the rest of the last packet (it shedules reads and then ignores read errors although the medium is perfectly readable using any userland tool). It will then write the data as they are, so if I dd-out 260kb, I'll get written data but the rest of the last packet is empty (zeroes) instead of the original content. The rest of the disk is unchanged.
Is Jens/anybody else actively working on the driver now? (I've seen lots of Jens's work in 2.5.1 so I'm not sure if he still has time to work on pkt layer)
He once wrote that the work in 2.5.1 is required for packet writing to be cleanly implemented (the current approach is more of a hack), but I guess PW is still part of the big picture and will come when the rest has stabilized (a.k.a. not too soon).
So will the 2.5.x effort be ever backported to 2.4?
I think Peter Osterlund is more or less just porting pktcdvd along the kernels but not adding new features.
Then I'm on my own to hack it for my hardware :-)
Well, I'm not really following pktcdvd that closely anymore, so take this information with a grain of salt.
Arnd <><
Thanks for the info, Nenik
On Fri, 4 Jan 2002, Petr Nejedly wrote:
Arnd Bergmann wrote:
Am Donnerstag, 3. Januar 2002 22:42 schrieben Sie:
But it sucessfully writes some data before having problems. Well, that part actually _is_ the same with the aha1542 problem, just for a different reason.
I've done some more tests: dd-in exactly 16MB, either in 64kb ok 2kb blocks works perfectly (readback and cmp), but if I try something 64kb unaligned (I was testing dd-in of 260kb), the pktcdvd has problems prereading the rest of the last packet (it shedules reads and then ignores read errors although the medium is perfectly readable using any userland tool). It will then write the data as they are, so if I dd-out 260kb, I'll get written data but the rest of the last packet is empty (zeroes) instead of the original content. The rest of the disk is unchanged.
I have seen some strange problems too on my burner. A read immediately following a write sometimes fails with sense code 70/2/4/8, "LUN not ready, long write in progress". I find this strange since I do not use write caching, so there should be no write in progress after the previous write command has finished. Jens has put in some code in the packet patch to handle this case in scsi_lib.c. The failed command will be retried, and the retry usually works on my drive. Maybe on some drives, this isn't enough to fix the read errors. However, if there are read errors that the module can not fix by retrying, there is no way to avoid data corruption. Either you write the packet and lose the information you couldn't read, or you don't write the packet and lose the information you were going to write.
Is Jens/anybody else actively working on the driver now? (I've seen lots of Jens's work in 2.5.1 so I'm not sure if he still has time to work on pkt layer)
He once wrote that the work in 2.5.1 is required for packet writing to be cleanly implemented (the current approach is more of a hack), but I guess PW is still part of the big picture and will come when the rest has stabilized (a.k.a. not too soon).
So will the 2.5.x effort be ever backported to 2.4?
Probably not. The bio changes broke lots of block device drivers, and backporting all those fixes to 2.4 will be a lot of work.
I think Peter Osterlund is more or less just porting pktcdvd along the kernels but not adding new features.
I am actually working on porting pktcdvd to 2.5. I have a patch for 2.5.2-pre7 which seems to work quite well. There are some things missing, but it is usable at least on my USB writer. The patch is available in this directory: http://w1.894.telia.com/~u89404340/patches/packet/2.5/ If someone wants to try it, please note that the CONFIG_CDROM_PKTCDVD_BUFFERS config option is now being used, and the old default value (256) is much too large to be practical. A better value is probably 4-16. (I will make a real announcement once a few more things have been fixed.) -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
but it is usable at least on my USB writer. The patch is available in this directory:
hi what kind of USB cdrw did the Peter use ? i try the HP 8230e and ACER 6404 , the kernel is 2.5.2-pre8 , but when i mount the cdrw , it shows usb-uhci.c: Host controller halted, trying to restart. . . . usb-uhci.c: Host controller halted, trying to restart. hub.c: hub / port 2 connection change hub.c: hub / port 2, portstatus 103, change 3, 12 Mb/s usb.c: USB disconnect on device 3 usb.c: kusbd: /sbin/hotplug remove 3 hub.c: port 2, portstatus 103, change 0, 12 Mb/s Unable to handle kernel paging request at virtual address 4f0a7586 printing eip: c01d1649 *pde = 00000000 Oops: 0000 CPU: 0 EIP: 0010:[<c01d1649>] Not tainted EFLAGS: 00010202 eax: 4f0a756e ebx: c289ee00 ecx: c795fe6c edx: c47a93e0 esi: 0000012c edi: c795fe68 ebp: c795e000 esp: c795fe5c ds: 0018 es: 0018 ss: 0018 Process scsi_eh_1 (pid: 871, stackpage=c795f000) Stack: c01d1732 c47a93e0 c795fe78 00000000 c795fe80 c795fe80 00000000 00000000 c795e000 c795fe6c c795fe6c c289ee00 c7b48cc0 80000000 c289ee00 c01d1895 c47a93e0 0000012c c795fea8 c289ea00 c01d1934 c289ee00 80000000 c7b48cc0 Call Trace: [<c01d1732>] [<c01d1895>] [<c01d1934>] [<c01d27a1>] [<c01d5026>] [<c01be063>] [<c882ec6c>] [<c88342c8>] [<c01be25d>] [<c01be923>] [<c01bee3a>] [<c01088ee>] [<c0107166>] [<c01bed40>] Code: 8b 40 18 85 c0 74 06 52 ff 50 0c 5a c3 b8 ed ff ff ff c3 8d now i use the IODATA cdrw (a product from the japan) it work with the DVDRAM & CDRW on the kernel 2.4.17 with USB , it's almost stable
On Sat, 5 Jan 2002, dino wrote:
but it is usable at least on my USB writer. The patch is available in this directory:
what kind of USB cdrw did the Peter use ? i try the HP 8230e and ACER 6404 , the kernel is 2.5.2-pre8 , but when i mount the cdrw , it shows
usb-uhci.c: Host controller halted, trying to restart.
That's because usb-storage is currently broken in 2.5. I use the patch below as a temporary workaround, but as Jens previously pointed out, it is not the right fix, because the address field in struct scatterlist is scheduled for removal in the near future in 2.5. --- linux-2.5.2-pre7/drivers/usb/storage/scsiglue.c Wed Nov 28 19:22:27 2001 +++ linux-2.5-packet/drivers/usb/storage/scsiglue.c Sat Jan 5 10:00:49 2002 @@ -145,9 +145,19 @@ static int queuecommand( Scsi_Cmnd *srb , void (*done)(Scsi_Cmnd *)) { struct us_data *us = (struct us_data *)srb->host->hostdata[0]; + struct scatterlist *sg; + int i; US_DEBUGP("queuecommand() called\n"); srb->host_scribble = (unsigned char *)us; + + /* Set up address field in the scatterlist. HighMem pages have + * already been bounced at this point. */ + sg = (struct scatterlist *) srb->request_buffer; + for (i = 0; i < srb->use_sg; i++) { + BUG_ON(PageHighMem(sg[i].page)); + sg[i].address = page_address(sg[i].page) + sg[i].offset; + } /* get exclusive access to the structures we want */ down(&(us->queue_exclusion)); -- Peter Osterlund - petero2@telia.com http://w1.894.telia.com/~u89404340
participants (3)
-
dino
-
Peter Osterlund
-
Petr Nejedly