I'm stating a new thread, because there seems to be some confusion here... I have been trying to use the HP DVD+RW 100i to make a UDFS in Linux for random disk access. I was able to write to the disk last week, but now i've set up a new linux box with the same drive, and i can't write to it at all. right now, i've downloaded the 2.4.18 kernel source, and applied the 2.4.19-rc2 patch to it. I continue by applying the patch that Peter posted on the 21st, and then recompile the kernel starting with 'make oldconfig' with the .config file i have configured for my older kernel source. I get a couple of prompts as the config file is parsed: CONFIG_CDROM_PKTCDVD=m CONFIG_CDROM_PKTCDVD_BUFFERS=256 CONFIG_CDROM_PKTCDVD_WCACHE=y [...] CONFIG_UDF_FS=m CONFIG_UDF_RW=y I set all other prompts to 'No'. then, i make the new kernel, install it, and reboot. -- now, booted up with the new kernel, i assure that i am running ide-cd over ide-scsi by typing 'lsmod' : Module Size Used by Not tainted sg 25404 0 (autoclean) serial 43460 0 (autoclean) sr_mod 11984 0 (autoclean) ide-scsi 7472 0 ide-cd 27620 0 cdrom 28192 0 (autoclean) [sr_mod ide-cd] scsi_mod 79544 3 (autoclean) [sg sr_mod ide-scsi] udf 82944 0 (autoclean) rtc 6044 0 (autoclean) this seems to be ok, so i continue by checking the /dev/cdrom device: [root@ksi4 /root]# l /dev/cdrom lrwxrwxrwx 1 root root 4 Jul 19 23:19 /dev/cdrom -> scd0 this is ok too, so i continue to do a 'cdrecord -scanbus': Cdrecord 1.10 (i686-pc-linux-gnu) Copyright (C) 1995-2001 Jörg Schilling Linux sg driver version: 3.1.24 Using libscg version 'schily-0.5' scsibus0: 0,0,0 0) 'HP ' 'DVD Writer 100j ' '1.37' Removable CD-ROM 0,1,0 1) * 0,2,0 2) * 0,3,0 3) * 0,4,0 4) * 0,5,0 5) * 0,6,0 6) * 0,7,0 7) * ok. Now, i know that the UDF module is loaded, i try to create the UDF file system on the DVD by typing 'mkudffs --media-type=cdrw /dev/cdrom': [root@ksi4 /root]# mkudffs --media-type=cdrw /dev/cdrom trying to change type of multiple extents hmmm... this didn't work. Let's try without specifying the media type: [root@ksi4 /root]# mkudffs /dev/cdrom trying to change type of multiple extents nope. didn't work either. then, i try to blank the cd out by executing the dd command: [root@ksi4 /root]# dd if=/dev/zero of=/dev/cdrom bs=2048 count=2295104 dd: /dev/cdrom: Read-only file system hmm... seems like my UDF module is not supporting writing... why not? i made sure that it was set in the /usr/src/linux/.config file like i stated above. any suggestions? cheers, gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."
On Mon, Jul 22, 2002 at 01:51:11PM -0700, guStaVo ZaeRa wrote:
I'm stating a new thread, because there seems to be some confusion here...
Your telling me =]
[root@ksi4 /root]# mkudffs /dev/cdrom trying to change type of multiple extents
nope. didn't work either. then, i try to blank the cd out by executing the dd command: [root@ksi4 /root]# dd if=/dev/zero of=/dev/cdrom bs=2048 count=2295104 dd: /dev/cdrom: Read-only file system
You need the DVD+RW patch (http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch) And unless your planning on using CDRW's as well, you shouldn't need the pktcdvd patch. (and they could very well conflict) Looking at the patch, I can't tell whether it works with ide-cd directly. My guess would be no... Ben
Ben Fennema wrote:
On Mon, Jul 22, 2002 at 01:51:11PM -0700, guStaVo ZaeRa wrote:
I'm stating a new thread, because there seems to be some confusion here...
Your telling me =]
[root@ksi4 /root]# mkudffs /dev/cdrom trying to change type of multiple extents
nope. didn't work either. then, i try to blank the cd out by executing the dd command: [root@ksi4 /root]# dd if=/dev/zero of=/dev/cdrom bs=2048 count=2295104 dd: /dev/cdrom: Read-only file system
You need the DVD+RW patch (http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch)
Ah!!!! there we go!
And unless your planning on using CDRW's as well, you shouldn't need the pktcdvd patch. (and they could very well conflict)
ok, i won't.
Looking at the patch, I can't tell whether it works with ide-cd directly. My guess would be no...
ok, so now, i've finally been able to do the dd stuff: [root@ksi4 /root]# dd if=/dev/zero of=/dev/cdrom bs=2048 count=2295104 it's taking a looooong time... does dd default to speed=1x? it seems like i'm back where i was on friday.. phew.. what a day.. :) thanks a lot, ben! when this is done, i'll try to write to the disk and see what happens, so i'll be back in a little while.. cheers, gustavo -- guStaSo ZaeRa | Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime."
Ben Fennema wrote:
On Mon, Jul 22, 2002 at 01:51:11PM -0700, guStaVo ZaeRa wrote:
I'm stating a new thread, because there seems to be some confusion here...
Your telling me =]
[root@ksi4 /root]# mkudffs /dev/cdrom trying to change type of multiple extents
nope. didn't work either. then, i try to blank the cd out by executing the dd command: [root@ksi4 /root]# dd if=/dev/zero of=/dev/cdrom bs=2048 count=2295104 dd: /dev/cdrom: Read-only file system
You need the DVD+RW patch (http://fy.chalmers.se/~appro/linux/DVD+RW/linux-2.4.patch)
And unless your planning on using CDRW's as well, you shouldn't need the pktcdvd patch. (and they could very well conflict)
Looking at the patch, I can't tell whether it works with ide-cd directly. My guess would be no...
Ben
allright, so now that i've blanked the disk, i format it to hold udfs: [root@ksi4 /mnt]# mkudffs --media-type=cdrw /dev/cdrom start=0, blocks=16, type=RESERVED start=16, blocks=3, type=VRS start=19, blocks=237, type=USPACE start=256, blocks=1, type=ANCHOR start=257, blocks=31, type=USPACE start=288, blocks=32, type=PVDS start=320, blocks=32, type=LVID start=352, blocks=32, type=STABLE start=384, blocks=1024, type=SSPACE start=1408, blocks=2293408, type=PSPACE start=2294816, blocks=31, type=USPACE start=2294847, blocks=1, type=ANCHOR start=2294848, blocks=160, type=USPACE start=2295008, blocks=32, type=STABLE start=2295040, blocks=32, type=RVDS start=2295072, blocks=31, type=USPACE start=2295103, blocks=1, type=ANCHOR my dmesg shows this: UDF-fs DEBUG lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG super.c:1395:udf_read_super: Multi-session=0 UDF-fs DEBUG super.c:388:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG super.c:731:udf_load_pvoldesc: recording time 1027465803/591412, 2002/07/23 16:10 (1e5c) UDF-fs DEBUG super.c:741:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' UDF-fs DEBUG super.c:748:udf_load_pvoldesc: volSetIdent[] = '3d3de24bLinuxUDF' UDF-fs DEBUG super.c:940:udf_load_logicalvol: Partition (0:0) type 2 on volume 1 UDF-fs DEBUG super.c:950:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=160, partition=0 UDF-fs DEBUG super.c:778:udf_load_partdesc: Searching map: (0 == 0) UDF-fs DEBUG super.c:819:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0 UDF-fs DEBUG super.c:860:udf_load_partdesc: Partition (0:0 type 1522) starts at physical 1408, block length 2293408 UDF-fs DEBUG super.c:1193:udf_load_partition: Using anchor in block 256 UDF-fs DEBUG super.c:1422:udf_read_super: Lastblock=0 UDF-fs DEBUG super.c:703:udf_find_fileset: Fileset at block=160, partition=0 UDF-fs DEBUG super.c:764:udf_load_fileset: Rootdir at block=224, partition=0 UDF-fs INFO UDF 0.9.6 (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/23 16:10 (1e5c) ok.. now, i try to copy a large (~500MB) file to the disk: [root@ksi4 /root]# cp cd1.iso /mnt/dvd+rw/ cp: cannot create regular file `/mnt/dvd+rw/cd1.iso': Input/output error [root@ksi4 /root]# cd /mnt/dvd+rw/ [root@ksi4 dvd+rw]# l ls: lost+found: Permission denied total 0 hmm... this worked with the 2.4.17 kernel and udf patch i used earlier.. any idea why it doesn't work now? dmesg shows me this :: [...] I/O error: dev 0b:00, sector 5632 I/O error: dev 0b:00, sector 6784 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=1696, location=288: read failed udf: udf_read_inode(ino 1696) failed !bh so, i unmount the drive, and re-mount it. [root@ksi4 /mnt]# l dvd+rw/ total 0 drwxr-xr-x 2 root root 40 Jul 23 16:10 lost+found Now, i try to copy the large file into it again: [root@ksi4 /mnt]# cp ~/cd1.iso dvd+rw/ cp: dvd+rw/cd1.iso: No space left on device [root@ksi4 /mnt]# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda7 17803524 2250216 14648852 13% / /dev/cdrom 4586816 32218 4554598 1% /mnt/dvd+rw Dmesg now shows: [...] UDF-fs DEBUG lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG super.c:1395:udf_read_super: Multi-session=0 UDF-fs DEBUG super.c:388:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG super.c:731:udf_load_pvoldesc: recording time 1027465803/591412, 2002/07/23 16:10 (1e5c) UDF-fs DEBUG super.c:741:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' UDF-fs DEBUG super.c:748:udf_load_pvoldesc: volSetIdent[] = '3d3de24bLinuxUDF' UDF-fs DEBUG super.c:940:udf_load_logicalvol: Partition (0:0) type 2 on volume 1 UDF-fs DEBUG super.c:950:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=160, partition=0 UDF-fs DEBUG super.c:778:udf_load_partdesc: Searching map: (0 == 0) UDF-fs DEBUG super.c:819:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0 UDF-fs DEBUG super.c:860:udf_load_partdesc: Partition (0:0 type 1522) starts at physical 1408, block length 2293408 UDF-fs DEBUG super.c:1193:udf_load_partition: Using anchor in block 256 UDF-fs DEBUG super.c:1422:udf_read_super: Lastblock=0 UDF-fs DEBUG super.c:703:udf_find_fileset: Fileset at block=160, partition=0 UDF-fs DEBUG super.c:764:udf_load_fileset: Rootdir at block=224, partition=0 UDF-fs INFO UDF 0.9.6 (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/23 16:10 (1e5c) I/O error: dev 0b:00, sector 5636 I/O error: dev 0b:00, sector 5636 -- Now, I'm back to where i was last week; for each time I re-mount the drive, I am able to write some more to it (~30-100MB). what i did observe, is that with your patch the write speed improved dramaticaly, which is great! :D is there anything i can do to make this work? any suggestions? if you give me an introduction or some hints, i could look at the source and see if I can help in some way. cheers, gustavo -- guStaVo ZaeRa | Assistant Software Engineer BRE Systems LLC. 1532 State Street Suite C Santa Barbara, Ca 93101 gzaera@bresystems.com http://www.bresystems.com "My goal is to make any information available from anywhere, at anytime." -- guStaVo ZaeRa
On Tue, Jul 23, 2002 at 08:28:29AM -0700, guStaVo ZaeRa wrote:
I/O error: dev 0b:00, sector 5636 I/O error: dev 0b:00, sector 5636
--
Now, I'm back to where i was last week; for each time I re-mount the drive, I am able to write some more to it (~30-100MB).
what i did observe, is that with your patch the write speed improved dramaticaly, which is great! :D
is there anything i can do to make this work? any suggestions? if you give me an introduction or some hints, i could look at the source and see if I can help in some way.
You could try ext2 and see if you have any better luck.. My guess is it will behave the same way. Also, make sure you have the latest firmware for your drive. Ben
Ben Fennema wrote:
On Tue, Jul 23, 2002 at 08:28:29AM -0700, guStaVo ZaeRa wrote:
I/O error: dev 0b:00, sector 5636 I/O error: dev 0b:00, sector 5636
--
Now, I'm back to where i was last week; for each time I re-mount the drive, I am able to write some more to it (~30-100MB).
what i did observe, is that with your patch the write speed improved dramaticaly, which is great! :D
is there anything i can do to make this work? any suggestions? if you give me an introduction or some hints, i could look at the source and see if I can help in some way.
You could try ext2 and see if you have any better luck.. My guess is it will behave the same way.
I'm having problems with 'mke2fs /dev/cdrom' should i specify the block size and block count?
Also, make sure you have the latest firmware for your drive.
Ben
fair enough... i've found a firmware update for the HP DVD100i drive (update to 1.42 at http://perso.club-internet.fr/farzeno/firmware/dvd/dvdrf.htm). What i don't really get, is why is the drive information in Linux says that the drive is a DVD100j instead of 'i'... is that a firmware issue? also, how do i actually update the firmare in linux. the only files that follow the zip files are .exe and .bin files. can i do it in linux at all? another question: has anyone gotten the UDF work on a DVD+RW drive in Linux at all? what kind of a drive are you out there using? any suggestions? cheers, gustavo
On Tue, Jul 23, 2002 at 08:28:29AM -0700, guStaVo ZaeRa wrote:
is there anything i can do to make this work? any suggestions? if you give me an introduction or some hints, i could look at the source and see if I can help in some way.
Looking at Andy's site, he mentions COMMAND SEQUENCE ERROR's being generated. I'm curious if this is what your seeing. in scsi_lib.c, can you add: printk(KERN_INFO "Device %s illegal request: cmd=%d, sector=%ld, nr_sectors=%ld\n", kdevname(SCpnt->request.rq_dev), SCpnt->request.cmd, SCpnt->request.sector, SCpnt->request.nr_sectors); After case ILLEGAL_REQUEST: in scsi_io_completion. Rebuild your kernel (or modules if you have scsi modular), retry your copy, and see if you get any illegal request printouts on dmesg. Ben
Ben Fennema wrote:
Looking at Andy's site, he mentions COMMAND SEQUENCE ERROR's being generated. I'm curious if this is what your seeing.
in scsi_lib.c, can you add:
printk(KERN_INFO "Device %s illegal request: cmd=%d, sector=%ld, nr_sectors=%ld\n", kdevname(SCpnt->request.rq_dev), SCpnt->request.cmd, SCpnt->request.sector, SCpnt->request.nr_sectors);
After case ILLEGAL_REQUEST: in scsi_io_completion.
Rebuild your kernel (or modules if you have scsi modular), retry your copy, and see if you get any illegal request printouts on dmesg.
ok... here's what i got : UDF-fs INFO UDF 0.9.6 (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/31 00:11 (1e5c) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabledttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Device 0b:00 illegal request: cmd=0, sector=1672, nr_sectors=4 Device 0b:00 illegal request: cmd=0, sector=1672, nr_sectors=4 I/O error: dev 0b:00, sector 1672 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=418, location=144: read failed udf: udf_read_inode(ino 418) failed !bh Device 0b:00 illegal request: cmd=0, sector=1676, nr_sectors=4 I/O error: dev 0b:00, sector 1676 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=419, location=145: read failed udf: udf_read_inode(ino 419) failed !bh Device 0b:00 illegal request: cmd=0, sector=1680, nr_sectors=4 I/O error: dev 0b:00, sector 1680 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=420, location=146: read failed udf: udf_read_inode(ino 420) failed !bh Device 0b:00 illegal request: cmd=0, sector=56268, nr_sectors=4 I/O error: dev 0b:00, sector 56268 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=14067, location=13793: read failed udf: udf_read_inode(ino 14067) failed !bh sr0: dirty DVD+RW media, "finalizing" What do you get out of that? What is the status on UDF in linux as a whole? has anyone gotten this working? Should I continue to fumble around, or am I "wasting" my time? Could you please give me some pointers on where i could start off if I was to join the development/debugging on UDF? thank you so much, gustavo
On Tue, Jul 30, 2002 at 04:55:49PM -0700, guStaVo ZaeRa wrote:
ok... here's what i got :
UDF-fs INFO UDF 0.9.6 (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/07/31 00:11 (1e5c) Serial driver version 5.05c (2001-07-08) with MANY_PORTS SHARE_IRQ SERIAL_PCI enabledttyS00 at 0x03f8 (irq = 4) is a 16550A ttyS01 at 0x02f8 (irq = 3) is a 16550A Installing knfsd (copyright (C) 1996 okir@monad.swb.de). Device 0b:00 illegal request: cmd=0, sector=1672, nr_sectors=4 Device 0b:00 illegal request: cmd=0, sector=1672, nr_sectors=4 I/O error: dev 0b:00, sector 1672 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=418, location=144: read failed udf: udf_read_inode(ino 418) failed !bh Device 0b:00 illegal request: cmd=0, sector=1676, nr_sectors=4 I/O error: dev 0b:00, sector 1676 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=419, location=145: read failed udf: udf_read_inode(ino 419) failed !bh Device 0b:00 illegal request: cmd=0, sector=1680, nr_sectors=4 I/O error: dev 0b:00, sector 1680 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=420, location=146: read failed udf: udf_read_inode(ino 420) failed !bh Device 0b:00 illegal request: cmd=0, sector=56268, nr_sectors=4 I/O error: dev 0b:00, sector 56268 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=14067, location=13793: read failed udf: udf_read_inode(ino 14067) failed !bh sr0: dirty DVD+RW media, "finalizing"
What do you get out of that?
Ok, so the device is returning ILLEGAL_REQUESTS.. before all the if (SCpnt->device->ten) { ... } add: scsi_queue_next_request(q, SCpnt); result = 0; break; (so right after your printk) That should retry all the illegal requests forever. Hopefully re-reading the sector will work, otherwise you'll prolly hang something =]
What is the status on UDF in linux as a whole? has anyone gotten this working? Should I continue to fumble around, or am I "wasting" my time? Could you please give me some pointers on where i could start off if I was to join the development/debugging on UDF?
Well, this has nothing to do with UDF. It's the drive behaving poorly when in packet mode. Ben
Ben Fennema wrote:
Ok, so the device is returning ILLEGAL_REQUESTS..
yes, definitely. :]
before all the if (SCpnt->device->ten) { ... } add:
scsi_queue_next_request(q, SCpnt); result = 0; break;
(so right after your printk) That should retry all the illegal requests forever. Hopefully re-reading the sector will work, otherwise you'll prolly hang something =]
ya, it hung... :] ok.. so let's see if i get this straight. I assume that the order things happen in is something like : 1. block device 2. find partition info 3. find sector size 4. find block size 5. find start block 6. start writing 7. stop writing 8. if done writing goto 8. otherwise goto 4. 9. call scsi_io_completion 10. unblock device i've seen that scsi_io_completion is only called from the interrupt routine for the device driver in sr.c and sd.c. (btw... what's the difference between these two files?)
Well, this has nothing to do with UDF. It's the drive behaving poorly when in packet mode.
ok.. would it help if i used a HP dvd200 drive instead? What kind of a driver do you guys use? gustavo
On Wed, Jul 31, 2002 at 11:29:58AM -0700, guStaVo ZaeRa wrote:
ya, it hung... :]
ok.. so let's see if i get this straight. I assume that the order things happen in is something like :
At what level? the filesystem level or the block device level?
i've seen that scsi_io_completion is only called from the interrupt routine for the device driver in sr.c and sd.c. (btw... what's the difference between these two files?)
scsi disc and scsi rom basically =)
Well, this has nothing to do with UDF. It's the drive behaving poorly when in packet mode.
ok.. would it help if i used a HP dvd200 drive instead? What kind of a driver do you guys use?
You could give it a shot and see if it behaves any differently/better. I'm living vicariously through those who have DVD+RW drives =] Ben
Looking at Andy's site, he mentions COMMAND SEQUENCE ERROR's being generated. I'm curious if this is what your seeing.
in scsi_lib.c, can you add:
printk(KERN_INFO "Device %s illegal request: cmd=%d, sector=%ld, nr_sectors=%ld\n", kdevname(SCpnt->request.rq_dev), SCpnt->request.cmd, SCpnt->request.sector, SCpnt->request.nr_sectors);
After case ILLEGAL_REQUEST: in scsi_io_completion.
Try following instead. Edit drivers/scsi/sr.c and before rw_intr() declaration add following function: static void flush_intr(Scsi_Cmnd *SCpnt) { /* this is a temporary hack which suspends i/o if unexpected happens */ if (driver_byte(SCpnt->result) != 0 && SCpnt->sense_buffer[0] == 0xF0) SCpnt->device->changed = 1; scsi_release_request(SCpnt->sc_request); } Then right before call to scsi_io_completion() in rw_intr() inject following code: if (driver_byte(result) != 0 && SCpnt->sense_buffer[0] == 0xF0 && /* Sense data is valid */ SCpnt->sense_buffer[2] == ILLEGAL_REQUEST && SCpnt->sense_buffer[12] == 0x2c) do { Scsi_Request *SRpnt; printk ("DVD+RW asks for flush\n"); SRpnt = scsi_allocate_request (SCpnt->device); if (SRpnt==NULL) break; /* mind do{}while(0); around */ SRpnt->sr_cmnd[0]=0x35; SRpnt->sr_cmd_len=10; SRpnt->sr_data_direction = SCSI_DATA_NONE; SRpnt->sr_timeout_per_command = 5*HZ; SRpnt->sr_done=flush_intr; /* interrupt callback */ #if 0 /* scsi_insert_special_req isn't exported :-( */ scsi_insert_special_req(SRpnt,1); #else /* * As scsi_insert_special_req is not exported, I have * to copy some code from scsi_lib.c. This is a TEMPORARY * solution and the ONLY reason for doing this is that I * don't want to patch scsi_syms.c! Below is inlined code * __scsi_insert_special(q,rq,SRpnt,1) from 2.4.18. */ { request_queue_t *q=&SRpnt->sr_device->request_queue; struct request *rq=&SRpnt->sr_request; unsigned long flags; rq->cmd = SPECIAL; rq->special = SRpnt; rq->q = NULL; rq->nr_segments = 0; rq->elevator_sequence = 0; spin_lock_irqsave(&io_request_lock, flags); list_add(&rq->queue, &q->queue_head); q->request_fn(q); spin_unlock_irqrestore(&io_request_lock, flags); } #endif /* * fake "LOGICAL UNIT IS IN PROCESS OF BECOMING READY" * for current command to fool scsi_io_completion(). */ SCpnt->sense_buffer[0]=0xF0; SCpnt->sense_buffer[2]&=0xF0; SCpnt->sense_buffer[2]|=NOT_READY; SCpnt->sense_buffer[12]=4; SCpnt->sense_buffer[13]=1; good_sectors=0; } while (0); Rebuild modules, reload sr_mod, mount rw,noatime, copy some files and how it went. Cheers. A.
Then right before call to scsi_io_completion() in rw_intr() inject following code:
if (driver_byte(result) != 0 && SCpnt->sense_buffer[0] == 0xF0 && /* Sense data is valid */ ^^ "==" should be replaced with "&" as [at least mine 200i] drive flags vendor specific code and returns 0x70 and not 0xF0 here.
a.
Andy Polyakov wrote:
Then right before call to scsi_io_completion() in rw_intr() inject following code:
if (driver_byte(result) != 0 && SCpnt->sense_buffer[0] == 0xF0 && /* Sense data is valid */
^^ "==" should be replaced with "&" as [at least mine 200i] drive flags vendor specific code and returns 0x70 and not 0xF0 here.
i tried to change it to 0x70, but i wasn't able to write one single byte to the drive. i remounted it, and then was able to write the same as before (~95MB).. again, my drive makes illegal requests : Device 0b:00 illegal request: cmd=0, sector=1108, nr_sectors=4 I/O error: dev 0b:00, sector 1108 Device 0b:00 illegal request: cmd=0, sector=1108, nr_sectors=4 I/O error: dev 0b:00, sector 1108 gustavo
Andy Polyakov wrote:
Try following instead. Edit drivers/scsi/sr.c and before rw_intr() declaration add following function:
[code snip]
ok, so i've rebuildt it, and loaded it. my dmesg shows this when i mount it: UDF-fs DEBUG lowlevel.c:57:udf_get_last_session: XA disk: no, vol_desc_start=0 UDF-fs DEBUG super.c:1395:udf_read_super: Multi-session=0 UDF-fs DEBUG super.c:388:udf_vrs: Starting at sector 16 (2048 byte sectors) UDF-fs DEBUG super.c:731:udf_load_pvoldesc: recording time 1028561968/694416, 2002/08/05 08:39 (1e5c) UDF-fs DEBUG super.c:741:udf_load_pvoldesc: volIdent[] = 'LinuxUDF' UDF-fs DEBUG super.c:748:udf_load_pvoldesc: volSetIdent[] = '3d4e9c30LinuxUDF' UDF-fs DEBUG super.c:940:udf_load_logicalvol: Partition (0:0) type 2 on volume 1 UDF-fs DEBUG super.c:950:udf_load_logicalvol: FileSet found in LogicalVolDesc at block=160, partition=0 UDF-fs DEBUG super.c:778:udf_load_partdesc: Searching map: (0 == 0) UDF-fs DEBUG super.c:819:udf_load_partdesc: unallocSpaceBitmap (part 0) @ 0 UDF-fs DEBUG super.c:860:udf_load_partdesc: Partition (0:0 type 1522) starts at physical 1408, block length 2293408 UDF-fs DEBUG super.c:1193:udf_load_partition: Using anchor in block 256 UDF-fs DEBUG super.c:1422:udf_read_super: Lastblock=0 UDF-fs DEBUG super.c:703:udf_find_fileset: Fileset at block=160, partition=0 UDF-fs DEBUG super.c:764:udf_load_fileset: Rootdir at block=224, partition=0 UDF-fs INFO UDF 0.9.6 (2002/03/11) Mounting volume 'LinuxUDF', timestamp 2002/08/05 08:39 (1e5c) then i try to ls the contents of it, and i get this: ls: lost+found: Permission denied total 0 my dmesg shows this: Device 0b:00 illegal request: cmd=0, sector=6784, nr_sectors=4 Device 0b:00 illegal request: cmd=0, sector=6784, nr_sectors=4 I/O error: dev 0b:00, sector 6784 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=1696, location=288: read failed udf: udf_read_inode(ino 1696) failed !bh i then unmount it and remount the drive, and do an ls. Now ls works fine. so, i proceed to copy a file (~500MB) onto the drive. [root /mnt]# cp ~/cd1.iso dvd+rw/ cp: dvd+rw/cd1.iso: No space left on device [root /mnt]# l dvd+rw/ ls: dvd+rw/lost+found: Permission denied total 97464 -rw------- 1 root root 99803136 Aug 5 08:49 cd1.iso apparently, I was able to to copy more than before, but my dmesg still shows that the drive is doing some illegal requests : Device 0b:00 illegal request: cmd=0, sector=5644, nr_sectors=4 I/O error: dev 0b:00, sector 5644 Device 0b:00 illegal request: cmd=0, sector=5644, nr_sectors=4 I/O error: dev 0b:00, sector 5644 Device 0b:00 illegal request: cmd=0, sector=6784, nr_sectors=4 I/O error: dev 0b:00, sector 6784 UDF-fs DEBUG misc.c:274:udf_read_tagged: block=1696, location=288: read failed udf: udf_read_inode(ino 1696) failed !bh what i don't get, is why the sectors requested are considered illegal. gustavo
participants (3)
-
Andy Polyakov -
Ben Fennema -
guStaVo ZaeRa