SCSI->IDE
Jan Stocker
LINUX has? This is very useful to get proggys like cdrecord (and the GUIs
[GnomeToaster]) running on IDE cd writers.
Jan
To Unsubscribe: send mail to majo...@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message
Thomas Quinot
> It would require that someone write an ATA SIM for CAM. As yet, no one
> has stepped forward to volunteer.
I have started one a few days ago. Still testing code, still many known,
unknown or otherwise bizarre problems, but at least I can mount a
CD-ROM, use cdrecord and cdrdao on my ATAPI drive through CAM.
A patch against -STABLE is available from
http://www.cuivre.fr.eu.org/~thomas/atapicam/
Use at your own risk. YMMV. Feedback welcome. Be prepared for panics,
especially on multi-processor machines.
Thomas.
--
Thomas Quinot ** Département Informatique & Réseaux ** qui...@inf.enst.fr
ENST // 46 rue Barrault // 75634 PARIS CEDEX 13
Thomas Quinot
> Very cool! Have you tested it on anything other than a CDROM?
I have tested it only with a CD-ROM drive (SAMSUNG CD-ROM SC-148F F007),
a CD-RW unit (LITE-ON LTR-16102B OS0B) and a DVD drive (only tested
CD-ROM and CD-audio functionality on this one, PIONEER DVD-ROM DVD-105F 1.22).
I do not have any tape or floppy ATAPI devs.
Thomas.
--
Thomas Quinot ** Département Informatique & Réseaux ** qui...@inf.enst.fr
ENST // 46 rue Barrault // 75634 PARIS CEDEX 13
To Unsubscribe: send mail to majo...@FreeBSD.org
Nick Hibma
verify that all SCSI commands are valid ATAPI commands?
I am doing something similar in the umass.c driver.
Nick
> with "unsubscribe freebsd-current" in the body of the message
Kris Kennaway
> Le 2001-11-05, Scott Long écrivait :
>
> > It would require that someone write an ATA SIM for CAM. As yet, no one
> > has stepped forward to volunteer.
>
> I have started one a few days ago. Still testing code, still many known,
> unknown or otherwise bizarre problems, but at least I can mount a
> CD-ROM, use cdrecord and cdrdao on my ATAPI drive through CAM.
>
> A patch against -STABLE is available from
> http://www.cuivre.fr.eu.org/~thomas/atapicam/
>
> Use at your own risk. YMMV. Feedback welcome. Be prepared for panics,
> especially on multi-processor machines.
Very cool!
Kris
Thomas Quinot
> You are not doing any conversion of commands from SCSI to ATAPI. Did you
> verify that all SCSI commands are valid ATAPI commands?
Actually the current version of the patch does do some translation
(MODE_{SENSE,SELECT}_6 are mapped to their _10 equivalent, because
the _6 variants are not implemented by ATAPI/MMC devices), but a
better solution might be to move these translations up to transport
independant layers, and be handled through quirk entries, or some
similar flagging mechanism. After all, ATAPI really is a /transport/
mechanism for SCSI commands: it is up to the initiator of a request
to know which command set to use for a given device.
Thomas Quinot
> I used your patches to change my -current release and got this:
>
> $ camcontrol devlist -v
> scbus0 on umass-sim0 bus 0:
> <MINOLTA DIMAGE 2330 ZOOM 1.00> at scbus0 target 0 lun 0 (da0)
> scbus-1 on xpt0 bus 0:
> < > at scbus-1 target -1 lun -1 (xpt0)
Ah. Interesting. Can you do a 'dmesg | grep "Registered SIM"' ?
> P.S. Do you have forgotten to do a detach???
Not forgotten... Omitted for now. I started developing this 4 days ago!
:)
Thomas.
Scott Long
> Le 2001-11-07, Nick Hibma écrivait :
>
> > You are not doing any conversion of commands from SCSI to ATAPI. Did you
> > verify that all SCSI commands are valid ATAPI commands?
>
> Actually the current version of the patch does do some translation
> (MODE_{SENSE,SELECT}_6 are mapped to their _10 equivalent, because
> the _6 variants are not implemented by ATAPI/MMC devices), but a
> better solution might be to move these translations up to transport
> independant layers, and be handled through quirk entries, or some
> similar flagging mechanism. After all, ATAPI really is a /transport/
> mechanism for SCSI commands: it is up to the initiator of a request
> to know which command set to use for a given device.
Adding even more quirk entries is not the right way to go. One, or
both, of the following things should happen.
1. The SIM should inform the upper layers that 6 bytes commands are
not allowed.
2. If a 6 byte command is issued and fails, the failure code should be
analyzed and the command retried in its 10 byte version. If that
succeeds, then the upper layers should be flagged to only use 10 byte
commands.
Scott
Nick Hibma
allowed? (12 byte in the case of ATAPI).
Nick
Joerg Wunsch
> This all looks not very good... a bus with number -1???
That's quite normal if you specify the -v option:
uriah # camcontrol devlist -v
scbus0 on sym0 bus 0:
<FUJITSU MAJ3182M SUN18G 0804> at scbus0 target 0 lun 0 (pass0,da0)
<IBM DDRS-39130D DC1B> at scbus0 target 4 lun 0 (pass1,da1)
<IBM DDRS-34560W S97B> at scbus0 target 8 lun 0 (pass2,da2)
< > at scbus0 target -1 lun -1 ()
scbus1 on sym1 bus 0:
<TOSHIBA CD-ROM XM-3401TA 3353> at scbus1 target 2 lun 0 (pass3,cd0)
<TANDBERG TDC 4222 =07:> at scbus1 target 4 lun 0 (pass4,sa0)
<HP C2520A 3503> at scbus1 target 5 lun 0 (pt0,pass5)
<YAMAHA CRW2100S 1.0H> at scbus1 target 6 lun 0 (pass6,cd1)
< > at scbus1 target -1 lun -1 ()
scbus-1 on xpt0 bus 0:
< > at scbus-1 target -1 lun -1 (xpt0)
xpt0 is sorta like a `super-SCSI' device which you always have,
regardless of the number of SCSI busses and targets. camcontrol uses
it e. g. to rescan busses (at least that's how i understand its
purpose).
--
cheers, J"org .-.-. --... ...-- -.. . DL8DTL
http://www.sax.de/~joerg/ NIC: JW11-RIPE
Never trust an operating system you don't have sources for. ;-)
Stijn Hoop
a -STABLE system somehow?
--Stijn
--
"I used to think I was indecisive, but now I'm not so sure."
Thomas Quinot
> Just curious, but how is the patch progressing?
For the moment I am expecting feedback from the testers who have
reported problems booting with the patch (esp. on SMP machines).
> Can I try this out on a -STABLE system somehow?
Yes, the patch available from
http://www.cuivre.fr.eu.org/~thomas/atapicam/
is against -STABLE.
BTW, I have succesfully used it this week-end for playing DVDs with
xine and mplayer.
Thomas.
Stijn Hoop
> Stijn Hoop writes:
> > [-current snipped, IMHO not so relevant]
> >
> > On Tue, Nov 13, 2001 at 07:58:36PM -0800, David Bushong wrote:
> > > Though this is sure to invoke "_you_ try it and tell _us_"... Anyone
> > > gotten tosha to work with this? Since cdd broke and dagrab is worthless
> > > quality-wise, AFAICT, and the cdparanoia port to *BSD isn't done... I'm
> > > left without a good way to rip.
> >
> > That's what I'm looking for too - but cdparanoia is ported to NetBSD (maybe
> > OpenBSD as well), only FreeBSD's SCSI layer is completely different. I've
> > attempted to port it, but this stuff is way over my head. Maybe someone with
> > SCSI subsystem knowledge can take a look at the NetBSD port? :)
>
> cdrdao says it has cdparanoia built-in. Is it lying?
Dunno - I haven't heard of cdrdao, but the pkg-descr doesn't imply that it
can rip CDs, only write CDs in Disc-At-Once mode. Why would it have audio
ripping code then? Maybe I'll check it out, but I'm a bit pressed for time
right now.
> > Haven't heard of tosha, got an URL?
>
> /usr/ports/audio/tosha/
Duh. Well, for me it fails to work:
[root@pcwin002] <~> tosha -d /dev/cd0c -i
Device: /dev/cd0c -- "PHILIPS" "PCRW804" "1.1"
error sending SCSI command: Invalid argument
I get the same error with my CD-ROM. Maybe I'll play with it later.
cdrecord seems to work fine, now that I've added 'device pass' to my kernel
(previously I only had 'device scbus'). Thank you Thomas! Now I can use the
various GUI cd-write frontends, and not worry about obscure mkisofs options!
--Stijn
--
What would this sentence be like if it weren't self-referential?