Date: Tue, 1 Dec 1998 11:45:47 -0700 (MST) From: "Kenneth D. Merry" <ken@plutotech.com> To: bsdx@spawnet.com (Adam McDougall) Cc: scsi@FreeBSD.ORG Subject: Re: tosha reports random errors after transition to CAM Message-ID: <199812011845.LAA21068@panzer.plutotech.com> In-Reply-To: <3663EFA0.BD143233@spawnet.com> from Adam McDougall at "Dec 1, 98 08:31:12 am"
next in thread | previous in thread | raw e-mail | index | archive | help
Adam McDougall wrote... > Matthew Hunt wrote: > > > > Since upgrading from 2.2-STABLE to 3.0-CURRENT, and hence CAM, I > > have observed random errors when using tosha to read CD audio data > > from my CD-ROM drive. The drive is branded IBM, but when I purchased > > it, I was told that it is a Toshiba XM-4101. > > > > When I try to rip CD audio, tosha emits the following error: > > > > wopr:~/tmp$ tosha -v -t 1 -o out.pcm > > Device: /dev/cd0c IBM CDRM00201 !F 0724 > > tosha: WARNING: Drive type not recognized. > > Output file: out.pcm > > > > track playing start end raw size mp3 size # of > > number time sector sector in bytes 128 kbps frames > > -------------------------------------------------------------- > > 1 4:22'18 0 19667 46259136 4196675 10039 > > error returned from CD-DA read command: > > (pass1:ahc0:0:3:0): Vendor Specific Command. CDB: d8 > > (pass1:ahc0:0:3:0): ILLEGAL REQUEST asc:bf,0 > > (pass1:ahc0:0:3:0): Vendor Specific ASC > > > > The error is always the same, but it occurs at random places and does > > not appear to depend on what CD or track I am ripping. I never had > > any problems pre-CAM. I have (obviously) recompiled tosha to support > > the CAM architecture. > > > > Can anyone provide illumination? > > Matt > > > > -- > > Matthew Hunt <mph@pobox.com> * Inertia is a property of matter. > > http://www.pobox.com/~mph/pgp.key for PGP public key 0x67203349. > > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > > with "unsubscribe freebsd-scsi" in the body of the message > > > I think I notice the same thing too. (well, similar) > It started happening when I changed HD's from a Atlas II to a Viking UW. That could be your problem...I'll explain below. > Seems like my symptoms are more drastic though, because when I run tosha > (even when not storing the data being read on da0) I will get something > like this: > 1 63:07'00 33 284057 668026800 60592835 144972 > (output file: track01.pcm) > (da0:dpt0:0:0:0): WRITE(06). CDB: a 9 e0 40 10 0 > (da0:dpt0:0:0:0): ILLEGAL REQUEST asc:24,0 > (da0:dpt0:0:0:0): Invalid field in CDB field replaceable unit: 80 > sks:c0,9 > (da0:dpt0:0:0:0): READ(06). CDB: 8 2 95 58 8 0 > (da0:dpt0:0:0:0): ILLEGAL REQUEST asc:24,0 > (da0:dpt0:0:0:0): Invalid field in CDB field replaceable unit: 80 > sks:c0,9 > swap_pager: I/O error - pagein failed; blkno 46424, size 4096, error 22 > vm_fault: pager read error, pid 96 (syslogd) > (da0:dpt0:0:0:0): WRITE(06). CDB: a 1 0 50 10 0 > (da0:dpt0:0:0:0): ILLEGAL REQUEST asc:24,0 > (da0:dpt0:0:0:0): Invalid field in CDB field replaceable unit: 80 > sks:c0,9 > ^C > (da0:dpt0:0:0:0): READ(06). CDB: 8 2 9 b0 28 0 > (da0:dpt0:0:0:0): ILLEGAL REQUEST asc:24,0 > (da0:dpt0:0:0:0): Invalid field in CDB field replaceable unit: 80 > sks:c0,9 This is rather bizzare, since the drive is complaining about byte 9 of a 6 byte CDB. Justin suspects that the drive may not be handling 6-byte reads and writes properly. > dpt0: <DPT Caching SCSI RAID Controller> rev 0x02 int a irq 12 on > pci0.17.0 > dpt0: DPT PM2144UW FW Rev. 07LY, 1 channel, 64 CCBs > da0: <QUANTUM VIKING 4.5 WSE 8808> Fixed Direct Access SCSI2 device > da0: Tagged Queueing Enabled > da0: 4345MB (8899736 512 byte sectors: 255H 63S/T 553C) Try this -- go into sys/cam/scsi/scsi_da.c, and on about line 1079, adjust the minimum_cmd_size for the read and write commands to 10 bytes. It could be that the disk isn't handling 6-byte reads and writes. It could also be some problem with the DPT driver, or the DPT firmware. (Simon would probably have a better idea on this one.) I suspect, though, that it may be a drive firmware problem. Ken -- Kenneth Merry ken@plutotech.com To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-scsi" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199812011845.LAA21068>