Date: Mon, 23 Jun 1997 09:36:37 +0200 From: j@uriah.heep.sax.de (J Wunsch) To: scsi@freebsd.org Cc: mmcg@cs.monash.edu.au, jmz@freebsd.org Subject: Re:kern/3909:Apatchsupportingsomenewwormdrivers Message-ID: <19970623093637.MV17592@uriah.heep.sax.de> In-Reply-To: <199706230355.NAA21529@heraclitus.cs.monash.edu.au>; from mmcg@cs.monash.edu.au on Jun 23, 1997 13:55:12 %2B1000 References: <199706230355.NAA21529@heraclitus.cs.monash.edu.au>
next in thread | previous in thread | raw e-mail | index | archive | help
(Redirecting from `bugs' to `scsi'. Jean-Marc, are you also on this list?) As mmcg@cs.monash.edu.au wrote: > > Multisession works fine for me (one of my test CDs bailed out with [...] > > For writing, you should always set the block number to 0. > > Hmm. My SCSI manual claims that blocks are always relative to > logical block 0, which is at 0:02:00 (I presumed this included > when writing). Do I want to ruin my perfect record to test > this? (29 CDs, 0 coasters :) I don't think you're ruining anything. Since writes to a CD-R are always in streaming mode, and per track, the block number doesn't make much sense at all. My Plasmon manual marks the block address in the WRITE command as `reserved', the HP manual mandates it to be either the next block in sequence, or 0. We settled to always provide it as 0 in the current driver. > > These things have been moved out to scsiconfig.c. I assume you had to > > modify scsiconfig.c anyway, in order to make the device known as a > > CD-R, did you? > > No, it's configured as a `worm' type scsi device (device type 4?), > and the kernel happily attaches it to worm0. Interesting. Then it's different from the HPs in this respect. My Plasmon also announces itself as type 4, unless i put a CD-ROM (or fixated CD-R) into the drive. > > scsiconfig { "T.YUDEN CD-WO", "EW-50", ...} or { "T.YUDEN", "CD-WO > > EW-50", ... }? > 04 80 02 02 27 00 00 18 54 2e 59 55 44 45 4e 20 # ....'...T.YUDEN > 43 44 2d 57 4f 20 45 57 2d 35 30 20 20 20 20 20 # CD-WO EW-50 > 32 2e 31 36 31 38 2f 31 30 2f 39 36 00 00 00 00 # 2.1618/10/96.... > 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 # ................ This makes it { "T.YUDEN", "CD-WO EW-50", ... }. > > What's the difference to the existing HP4020/HP6020/CDD2000/CDD2660 > > option? From a cursory look, i didn't see any. There's not much use > > to duplicate code. > > You're quite right - the only quirk function that changed was the > prepare_track routine. I added a `Write Track' command, which > causes laser calibration to commence on the unit. Hmm, doesn't the drive do this automatically at the first write? I think that's how it's documented for my drive. The write channel can either be opened explicitly by a WRITE TRACK command, or implicitly by the first WRITE command provided that the other preparations have been done. I opted for the latter sequence, since it looked easier to implement to me. As i understand it, the power calibration is a necessary step the burner cannot omit at all. > the general (non drive-specific) finalize_track routine to do the > flush to disk before issuing the spindown; doing it in the other > order confused my drive. As i wrote, we agreed that the spindown is totally useless (it has apparently been cloned from the CD-ROM driver), and Jean-Marc did already do the deed of killing it. > > I suspect you could have been successfully using the old code, too, by > > pretending it to be an HP 4020i? > > No, this failed when finalizing the track. Ah, yep. -- cheers, J"org joerg_wunsch@uriah.heep.sax.de -- http://www.sax.de/~joerg/ -- NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?19970623093637.MV17592>