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>