From owner-freebsd-scsi  Sun Jul  1  4:58:11 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailout06.sul.t-online.de (mailout06.sul.t-online.com [194.25.134.19])
	by hub.freebsd.org (Postfix) with ESMTP id 5D7FF37B405
	for <FreeBSD-SCSI@freebsd.org>; Sun,  1 Jul 2001 04:58:02 -0700 (PDT)
	(envelope-from Norman.Czarczinski@t-online.de)
Received: from fwd02.sul.t-online.de 
	by mailout06.sul.t-online.de with smtp 
	id 15GfrU-00025J-03; Sun, 01 Jul 2001 13:58:00 +0200
Received: from amd.local (320049594980-0001@[217.1.85.225]) by fwd02.sul.t-online.com
	with esmtp id 15GfrG-1xCARUC; Sun, 1 Jul 2001 13:57:46 +0200
Received: (from norman@localhost)
	by amd.local (8.11.3/8.11.3) id f61Bvgk00472
	for FreeBSD-SCSI@freebsd.org; Sun, 1 Jul 2001 13:57:42 +0200 (CEST)
	(envelope-from norman)
Content-Type: text/plain;
  charset="iso-8859-1"
From: Norman.Czarczinski@t-online.de (Norman Czarczinski)
To: FreeBSD-SCSI@freebsd.org
Subject: Trouble with SCSI Streamer
Date: Sun, 1 Jul 2001 13:57:42 +0200
X-Mailer: KMail [version 1.2]
MIME-Version: 1.0
Message-Id: <01070113574200.00419@amd.local>
Content-Transfer-Encoding: 8bit
X-Sender: 320049594980-0001@t-dialin.net
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

Hi,

I have a Wangtek 5525ES streamer on an Adaptec 2940UW host and run 
FreeBSD 4.3-stable:
ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem 
0xe4000000-0xe4000fff irq 11 at device 12.0 on pci0
aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs
sa0 at ahc0 bus 0 target 5 lun 0
sa0: <WANGTEK 5525ES SCSI REV1 6F6> Removable Sequential Access SCSI-CCS 
device sa0: 3.300MB/s transfers

Writing the first tape works fine. But after I inserted a new tape, I get a 
data overrun error:
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): WRITE(06). CDB: a 1 0 0 14 
0 
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_action
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): data overrun detected in 
Data-out phase.  Tag == 0x4.
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): Have seen Data Phase.  
Length = 10240.  NumSGs = 3.
Jun 27 20:02:03 pentium /kernel: sg[0] - Addr 0x1fd7000 : Length 4096
Jun 27 20:02:03 pentium /kernel: sg[1] - Addr 0x1eb8000 : Length 4096
Jun 27 20:02:03 pentium /kernel: sg[2] - Addr 0x3af9000 : Length 2048
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_done - scb 4
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_done
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): camisr(sa0:ahc0:0:5:0): 
Cam Status 0x12
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_setup_ccb
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_action
Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): error 5 resid 10240 count 
10240

Then a reboot is needed to use the streamer normaly. (camcontrol reset 
doesn't work)

I have this problem with dump and afio. When I start them again on the 
rewinded tape, they work. But a restart after a short tape-eject fails. Only 
tar let me change the tape without problems. 

Any hints?

Bye
  Norman

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1  5: 9:13 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id AB75D37B405
	for <freebsd-scsi@freebsd.org>; Sun,  1 Jul 2001 05:09:02 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from fokus.gmd.de (sherwood [193.175.133.102])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id OAA00450;
	Sun, 1 Jul 2001 14:08:49 +0200 (MET DST)
Received: (from jes@localhost)
	by fokus.gmd.de (8.8.8+Sun/8.8.8) id OAA16717;
	Sun, 1 Jul 2001 14:08:18 +0200 (MET DST)
Date: Sun, 1 Jul 2001 14:08:18 +0200 (MET DST)
From: Joerg Schilling <schilling@fokus.gmd.de>
Message-Id: <200107011208.OAA16717@fokus.gmd.de>
To: ken@kdm.org, mckay@thehub.com.au
Cc: freebsd-scsi@freebsd.org, schilling@fokus.gmd.de
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>From ken@panzer.kdm.org Sun Jul  1 06:01:32 2001

>[ CCing Joerg Schilling, since he might have a clue about what's going on
>here.  Joerg:  look down at the bottom of this message for the question
>addressed to you.  The rest of this is primarily background information. ]

>On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote:
>> Some months ago I made vague assertions that one must use a 2 kilobyte
>> block size when reading raw CD data, or risk missing the last part of
>> the CD.  Then I couldn't reproduce it, so blamed some mystery past version
>> of FreeBSD.
>> 
>> Actually, the difference is pressed vs burned CDs.
...
>> Here is an example from reading a (short) burned CD on a Toshiba
>> XM-5701 SCSI CD-ROM, on a 4.3-R system:
>> 
>> # dd if=/dev/cd1c of=/dev/null bs=2k
>> dd: /dev/cd1c: Input/output error
>> 8367+0 records in
>> 8367+0 records out
>> 17135616 bytes transferred in 88.964899 secs (192611 bytes/sec)
>> 
>> # dd if=/dev/cd1c of=/dev/null bs=4k
>> dd: /dev/cd1c: Input/output error
>> 4183+0 records in
>> 4183+0 records out
>> 17133568 bytes transferred in 88.895442 secs (192738 bytes/sec)
>> 
>> Also, the system logs "Random positioning error" scsi errors, and there

It is really a bad idea to use dd to read a CD.

To read a CD use 'readcd'.

Unfortunately this does not work for ATAPI on FreeBSD. Another reason to see why
uniform SCSI suport is needed....


>> Is there any way around these problems with SCSI CD drives?


Read README.verify & README.copy for a long answer....


>Just out of curiosity, what did you use to burn the CD?  cdrecord?

>I spent some time looking into this, and got some interesting results.  In
>short, I can reproduce your results with a burned CD versus a pressed CD.

There is no difference between a burned and a pressed CD.
There _is_ a difference between a TAO and a DAO CD.

>The results are the same for both a Plextor CD-RW and a Toshiba DVD-ROM in
>my machine, so I don't think it's a CDROM firmware issue.

>It looks like the problem is a capacity reporting problem, possibly due to
>the way the burned CD was burned.

There is no capacity reporting problem, the capacity is reported as documented
in the CD standards.

>Now we do a read capacity on cd0 (the burned CD-RW):

># camcontrol cmd cd0 -c "25 0 0 0 0 0 0 0 0 0" -i 8 "i4 i4"                    
>297518 2048 

>So the last address is 297518.  We attempt to read that block:

># camcontrol cmd cd0 -v -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>CAM status is 0xb

>Looks like we got a command timeout.  (That's what 0xb means.  Under
>FreeBSD-current, camcontrol prints out more descriptive messages for
>non-SCSI errors.)

>So let's bump the timeout up to 120 seconds and try to read the same block
>again:

># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
>(pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0
>(pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred

This makes me believe that you have a bug in the SCSI Transport in the kernel...

>Oh yeah, the BDR sent in response to the timeout will cause a unit
>attention condition.  Let's try it again:

># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>camcontrol: error sending command
>(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
>(pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2e asc:11,5
>(pass2:ahc1:0:4:0): L-EC uncorrectable error

This one or 'illegal mode for this track' is a correct repspose.
You should check why the drivr send a bus reset to the drive without reason.

>Hmm, looks like we can't read the LBA the drive claims is the last one on
>the CD.

>Still can't read that one.  Let's try decrementing the LBA again:

># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297516 1 -i 2048 - > /dev/null

>That works fine.

As documented in several standards an in README.copy & README.verify

>So it looks like the CD may have a bogus table of contents on it, since it
>doesn't seem to describe the range of valid data on the disk.  The table of
>contents on the drives seems to agree with the read capacity data:  (that's
>probably where the drive gets the data in the first place)


The TOC is OK, many OS don't deal correctly with the run-out blocks.
While it is OK for dd to abort, it is not OK when the filesystem does read-ahead
bejond the FS size as noted in the PVD and then believes that the last blocks
(including parts of the last file) are un-readable.

>This is the Plextor CD-RW with the burned CD-RW in it:

># cdrecord dev=1,4,0 -toc
>Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling

A really old one.....

>So now the question for Joerg -- do you know of any difference between
>burned CDs and "pressed" CDs (i.e. CDs produced commercially) that would
>account for the reported capacity of the burned CDs apparantly being a
>couple of blocks longer than the actual amount of data that can be read?

>Or could it possibly be a bug in mkisofs or cdrecord that's causing the TOC
>to get written improperly?  (I don't know which application writes the TOC,
>or whether the drive is actually doing it.)

>Anyway, I don't have a ready answer for this one.  Hopefully Joerg can shed
>some light on the problem.

If you write in TAO, you get 2 run-out blocks (16 ??? on early Yamaha)
that are part of the TOC. 

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1  7:50:28 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30])
	by hub.freebsd.org (Postfix) with ESMTP id 6A78537B407
	for <freebsd-scsi@freebsd.org>; Sun,  1 Jul 2001 07:50:23 -0700 (PDT)
	(envelope-from mckay@thehub.com.au)
Received: from dungeon.home (ppp2.dyn248.pacific.net.au [203.143.248.2])
	by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id AAA21163;
	Mon, 2 Jul 2001 00:50:20 +1000 (EST)
Received: from dungeon.home (localhost [127.0.0.1])
	by dungeon.home (8.11.3/8.11.1) with ESMTP id f61EoUw14742;
	Mon, 2 Jul 2001 00:50:30 +1000 (EST)
	(envelope-from mckay)
Message-Id: <200107011450.f61EoUw14742@dungeon.home>
To: Joerg Schilling <schilling@fokus.gmd.de>
Cc: ken@kdm.org, freebsd-scsi@freebsd.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs 
References: <200107011208.OAA16717@fokus.gmd.de>
In-Reply-To: <200107011208.OAA16717@fokus.gmd.de>
    from Joerg Schilling at "Sun, 01 Jul 2001 14:08:18 +0200"
Date: Mon, 02 Jul 2001 00:50:30 +1000
From: Stephen McKay <mckay@thehub.com.au>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Sunday, 1st July 2001, Joerg Schilling wrote:

>>From ken@panzer.kdm.org Sun Jul  1 06:01:32 2001
>
>>On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote:
>>> Actually, the difference is pressed vs burned CDs.

>It is really a bad idea to use dd to read a CD.

I think it's important that the raw CD be presented in a fully readable
format.  Then dd (and everything else) will work properly.

>>> Is there any way around these problems with SCSI CD drives?
>
>Read README.verify & README.copy for a long answer....

I'm still digesting this information (from the cdrecord program, if anyone
else is looking for them).  I am assuming that 2 (or more) unreadable
sectors are added, not that I lose 2 sectors of data.  Right?

>>Just out of curiosity, what did you use to burn the CD?  cdrecord?

One was burned with cdrecord (version 1.8, I think).  Another by some
Adaptec burner program under Windoze (unknown version of both).

>There is no difference between a burned and a pressed CD.
>There _is_ a difference between a TAO and a DAO CD.

I am constantly surprised by the CD standards.  Never pleasantly, either.

>>It looks like the problem is a capacity reporting problem, possibly due to
>>the way the burned CD was burned.
>
>There is no capacity reporting problem, the capacity is reported as documented
>in the CD standards.

We might either have to lie about the capacity (so that every reported byte
can be read), or deal specially with the run out blocks (by faking them
as nulls).

>># cdrecord dev=1,4,0 -toc
>>Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
>
>A really old one.....

Old software lives on!  I'm still using 1.8, by the way.

It also looks like you renamed your suite to: cdrtools.  I expect the
cdrecord port maintainer didn't notice.

>>So now the question for Joerg -- do you know of any difference between
>>burned CDs and "pressed" CDs (i.e. CDs produced commercially) that would
>>account for the reported capacity of the burned CDs apparantly being a
>>couple of blocks longer than the actual amount of data that can be read?

>If you write in TAO, you get 2 run-out blocks (16 ??? on early Yamaha)
>that are part of the TOC. 

I think we can ignore old drives if we can establish that the standard
requires 2 sectors, and that most drives support this.

Stephen.

PS I checked ATAPI on -current, and now that the new accurate TOC code
is in there, it also produces error messages on burned CDs using my
Pioneer DVD reader.  Progress! :-)

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1  8: 3:40 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id 855B537B406
	for <freebsd-scsi@freebsd.org>; Sun,  1 Jul 2001 08:03:33 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from fokus.gmd.de (sherwood [193.175.133.102])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA06395;
	Sun, 1 Jul 2001 17:03:21 +0200 (MET DST)
Received: (from jes@localhost)
	by fokus.gmd.de (8.8.8+Sun/8.8.8) id RAA16964;
	Sun, 1 Jul 2001 17:02:54 +0200 (MET DST)
Date: Sun, 1 Jul 2001 17:02:54 +0200 (MET DST)
From: Joerg Schilling <schilling@fokus.gmd.de>
Message-Id: <200107011502.RAA16964@fokus.gmd.de>
To: mckay@thehub.com.au, schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, ken@kdm.org
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>From mckay@thehub.com.au Sun Jul  1 16:50:52 2001

>On Sunday, 1st July 2001, Joerg Schilling wrote:

>>>From ken@panzer.kdm.org Sun Jul  1 06:01:32 2001
>>
>>>On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote:
>>>> Actually, the difference is pressed vs burned CDs.

>>It is really a bad idea to use dd to read a CD.

>I think it's important that the raw CD be presented in a fully readable
>format.  Then dd (and everything else) will work properly.

Please don't try to do this!

It is a known fact that these problems with TAO CD's exist.
If you change FreeBSD, then it would behave different from an other OS.

As I already said: you should not read a CD with dd but with 'readcd'.
readcd allows you to specify sectors=from-to to exclude these run-out
sectors. Future versions may even do this automatically.

>>>> Is there any way around these problems with SCSI CD drives?
>>
>>Read README.verify & README.copy for a long answer....

>I'm still digesting this information (from the cdrecord program, if anyone
>else is looking for them).  I am assuming that 2 (or more) unreadable
>sectors are added, not that I lose 2 sectors of data.  Right?

correct.

>>>Just out of curiosity, what did you use to burn the CD?  cdrecord?


>We might either have to lie about the capacity (so that every reported byte
>can be read), or deal specially with the run out blocks (by faking them
>as nulls).

Again: please don't do that! You would only create confusion.
All people who know CD standards known about this Authors of CD drivers and
ISO-9660 filesystem should know it.

>>># cdrecord dev=1,4,0 -toc
>>>Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
>>
>>A really old one.....

>Old software lives on!  I'm still using 1.8, by the way.

>It also looks like you renamed your suite to: cdrtools.  I expect the
>cdrecord port maintainer didn't notice.

I don't know who this is and I expect that a port maintaner is on the
right mailing lists where this change has been discussed at least for 2 years.

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1  8:30:27 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30])
	by hub.freebsd.org (Postfix) with ESMTP id 088F237B405
	for <freebsd-scsi@freebsd.org>; Sun,  1 Jul 2001 08:30:18 -0700 (PDT)
	(envelope-from mckay@thehub.com.au)
Received: from dungeon.home (ppp2.dyn248.pacific.net.au [203.143.248.2])
	by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id BAA22636;
	Mon, 2 Jul 2001 01:30:12 +1000 (EST)
Received: from dungeon.home (localhost [127.0.0.1])
	by dungeon.home (8.11.3/8.11.1) with ESMTP id f61FUNw15125;
	Mon, 2 Jul 2001 01:30:23 +1000 (EST)
	(envelope-from mckay)
Message-Id: <200107011530.f61FUNw15125@dungeon.home>
To: Joerg Schilling <schilling@fokus.gmd.de>
Cc: freebsd-scsi@freebsd.org, ken@kdm.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs 
References: <200107011502.RAA16964@fokus.gmd.de>
In-Reply-To: <200107011502.RAA16964@fokus.gmd.de>
    from Joerg Schilling at "Sun, 01 Jul 2001 17:02:54 +0200"
Date: Mon, 02 Jul 2001 01:30:23 +1000
From: Stephen McKay <mckay@thehub.com.au>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Sunday, 1st July 2001, Joerg Schilling wrote:

>>From mckay@thehub.com.au Sun Jul  1 16:50:52 2001
>
>>On Sunday, 1st July 2001, Joerg Schilling wrote:
>>>It is really a bad idea to use dd to read a CD.
>
>>I think it's important that the raw CD be presented in a fully readable
>>format.  Then dd (and everything else) will work properly.
>
>Please don't try to do this!
>
>It is a known fact that these problems with TAO CD's exist.
>If you change FreeBSD, then it would behave different from an other OS.

I was surprised by the TAO difference.  I'm not alone.  I suspect that
only a tiny percentage of people are aware of the problem.  One job of
the OS is to hide these surprises.  FreeBSD can be different from
other OSes, if need be.

>As I already said: you should not read a CD with dd but with 'readcd'.
>readcd allows you to specify sectors=from-to to exclude these run-out
>sectors. Future versions may even do this automatically.

Although 'readcd' is useful now, it is only problems with drivers and
specifications that make it useful.  We should fix the underlying
problem.  Maybe the other OSes will catch up.

>>We might either have to lie about the capacity (so that every reported byte
>>can be read), or deal specially with the run out blocks (by faking them
>>as nulls).
>
>Again: please don't do that! You would only create confusion.
>All people who know CD standards known about this Authors of CD drivers and
>ISO-9660 filesystem should know it.

I don't think this is relevant.  The Unix way is to abstract away device
differences.  A CD should be readable by simple application of open,
read, read, read (returning 0 => EOF), close.  If I write 100MB of data
to a CD (or tape, or regular file, etc), then read it back, I should get
100MB of data, then EOF.  There is no need for CDs to end with a read failure.

Is there anything useful in the error return that CD duplicators require?
Or is it just junk?  We could add a mode to preserve the old behaviour.

>>>># cdrecord dev=1,4,0 -toc
>>>>Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
>>>
>>>A really old one.....
>
>>Old software lives on!  I'm still using 1.8, by the way.
>
>>It also looks like you renamed your suite to: cdrtools.  I expect the
>>cdrecord port maintainer didn't notice.
>
>I don't know who this is and I expect that a port maintaner is on the
>right mailing lists where this change has been discussed at least for 2 years.

I'll let the maintainer know.

Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1  9: 7:51 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id D295637B401
	for <FreeBSD-SCSI@FreeBSD.ORG>; Sun,  1 Jul 2001 09:07:47 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from wonky.feral.com (wonky.feral.com [192.67.166.7])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f61G7i410792;
	Sun, 1 Jul 2001 09:07:45 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Sun, 1 Jul 2001 09:07:27 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
Reply-To: <mjacob@feral.com>
To: Norman Czarczinski <Norman.Czarczinski@t-online.de>
Cc: <FreeBSD-SCSI@FreeBSD.ORG>
Subject: Re: Trouble with SCSI Streamer
In-Reply-To: <01070113574200.00419@amd.local>
Message-ID: <20010701090455.M20993-100000@wonky.feral.com>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


It's some kind of SCSI signal or HBA issue or breakage at the device.
The CDB matches the S/G list spit out by the aic driver (10KB == 10KB),
but the drive still claims to be in Data Out phase.

I wonder, btw, what the Tag is doing there.

-matt


On Sun, 1 Jul 2001, Norman Czarczinski wrote:

> Hi,
>
> I have a Wangtek 5525ES streamer on an Adaptec 2940UW host and run
> FreeBSD 4.3-stable:
> ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem
> 0xe4000000-0xe4000fff irq 11 at device 12.0 on pci0
> aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs
> sa0 at ahc0 bus 0 target 5 lun 0
> sa0: <WANGTEK 5525ES SCSI REV1 6F6> Removable Sequential Access SCSI-CCS
> device sa0: 3.300MB/s transfers
>
> Writing the first tape works fine. But after I inserted a new tape, I get a
> data overrun error:
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): WRITE(06). CDB: a 1 0 0 14
> 0
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_action
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): data overrun detected in
> Data-out phase.  Tag == 0x4.
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): Have seen Data Phase.
> Length = 10240.  NumSGs = 3.
> Jun 27 20:02:03 pentium /kernel: sg[0] - Addr 0x1fd7000 : Length 4096
> Jun 27 20:02:03 pentium /kernel: sg[1] - Addr 0x1eb8000 : Length 4096
> Jun 27 20:02:03 pentium /kernel: sg[2] - Addr 0x3af9000 : Length 2048
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_done - scb 4
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_done
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): camisr(sa0:ahc0:0:5:0):
> Cam Status 0x12
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_setup_ccb
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_action
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): error 5 resid 10240 count
> 10240
>
> Then a reboot is needed to use the streamer normaly. (camcontrol reset
> doesn't work)
>
> I have this problem with dump and afio. When I start them again on the
> rewinded tape, they work. But a restart after a short tape-eject fails. Only
> tar let me change the tape without problems.
>
> Any hints?
>
> Bye
>   Norman
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1 13:41:40 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from cmailg4.svr.pol.co.uk (cmailg4.svr.pol.co.uk [195.92.195.174])
	by hub.freebsd.org (Postfix) with ESMTP
	id F22B537B401; Sun,  1 Jul 2001 13:41:33 -0700 (PDT)
	(envelope-from n_hibma@webweaving.org)
Received: from modem-94.apanonar.dialup.pol.co.uk ([62.136.117.94] helo=heather.plazza.uk)
	by cmailg4.svr.pol.co.uk with esmtp (Exim 3.13 #0)
	id 15Gnz3-0004hH-00; Sun, 01 Jul 2001 21:38:21 +0100
Date: Sun, 1 Jul 2001 21:39:32 +0100 (BST)
From: Nick Hibma <n_hibma@webweaving.org>
X-X-Sender:  <n_hibma@heather.plazza.uk>
To: j mckitrick <jcm@FreeBSD-uk.eu.org>
Cc: <freebsd-hackers@FreeBSD.ORG>, <freebsd-scsi@FreeBSD.ORG>
Subject: Re: disconnecting from detached zip drive
In-Reply-To: <20010612122731.A81226@dogma.freebsd-uk.eu.org>
Message-ID: <20010701213608.F5327-100000@heather.plazza.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Have a look at the umass driver. When I wrote the detach code I never
managed to actually detach the SIM. It would panic on reattach. I never
bothered to figure out why.

What the driver does: When the module loads it does not immediatelly
attach itself to CAM as a SIM as I might want to unload it. When it
finds a device it wants to tell CAM about it registers the SIM,
announces the device, and is ready to start servicing requests.

On detach it only removes the drive from CAM and not the SIM. However,
there is some code in there that shows how I *think* detaching the SIM
should work. So there should be a starting point.

Another example of a detachable SIM would be the AIC driver I believe.
Ask Warner Losh, at imp@freebsd.org, he wrote the detach code for that
driver I believe.

I'd be very interested to hear about it, if you find a reliable
solution.

Nick


On Tue, 12 Jun 2001, j mckitrick wrote:

>
> hi all,
>
> i'm working on turning the zip driver and all the ppbus devices into
> modules.  So far, i have the vpo (zip driver) detaching, but i have problems
> when i reattach.
>
> In the initial attach() call, we allocate a tiny bit of memory for a device
> controlling microsequence, and we call cam_sim_alloc(), xpt_bus_register(),
> and then rescan the bus.  If we fail, we call cam_simq_free() if the
> xxx_alloc call failed, and we call cam_sim_free() if xxx_register() fails.
>
> In detach(), i am experimenting (!) and right now i free() the microsequence
> (unrelated to cam) and call cam_sim_free().
>
> Here is the problem: when i detach, everything looks fine. I attach() when i
> reload the module, and the log message says it is now allocating device vpo0
> and vpo1.  There is only supposed to be vpo0, of course.  It also assigns
> these as da1 and da2, instead of da0.  Now, when i try to mount the drive, i
> get a page fault in cam and/or mount, depending on what i did in detach().
>
> What needs to be done to completely disconnect the zip drive from cam, so
> that the new attachment looks like it is starting over from scratch?
>
> Jonathon
> --
> Tech support:  Try this.  Arrange the parts in neat piles.  Stand on your
> chair until you can see over your cubicle walls.  Now shout "Does anybody
> know how to read a manual?"
>
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-hackers" in the body of the message
>


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1 13:48:12 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from guru.mired.org (okc-27-141-144.mmcable.com [24.27.141.144])
	by hub.freebsd.org (Postfix) with SMTP id 79EAC37B405
	for <scsi@freebsd.org>; Sun,  1 Jul 2001 13:48:07 -0700 (PDT)
	(envelope-from mwm@mired.org)
Received: (qmail 12867 invoked by uid 100); 1 Jul 2001 20:48:06 -0000
From: Mike Meyer <mwm@mired.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-ID: <15167.35974.774198.722692@guru.mired.org>
Date: Sun, 1 Jul 2001 15:48:06 -0500
To: "Jamil Taylor" <jamil_taylor@pobox.com>
Cc: scsi@freebsd.org
Subject: RE: System Hang During tar Backup
In-Reply-To: <OAENJAIJJFKLPKFKIBMGMEPLCCAA.jamil_taylor@pobox.com>
References: <OAENJAIJJFKLPKFKIBMGAEPJCCAA.jamil_taylor@pobox.com>
	<OAENJAIJJFKLPKFKIBMGMEPLCCAA.jamil_taylor@pobox.com>
X-Mailer: VM 6.90 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
X-face: "5Mnwy%?j>IIV\)A=):rjWL~NB2aH[}Yq8Z=u~vJ`"(,&SiLvbbz2W`;h9L,Yg`+vb1>RG%
 *h+%X^n0EZd>TM8_IB;a8F?(Fb"lw'IgCoyM.[Lg#r\
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

[Moved from -stable to -scsi, as that seems to be where the problem is.]

Jamil Taylor <jamil_taylor@pobox.com> types:
> I attempted this one more time and got it to work. What I had to do this
> time was reboot the machine in single user mode. I entered the following
> commands after pressing space during boot:
> 
> unload
> load kernel
> boot -s
> 
> After boot, I mounted all drives and successfully used tar to backup all
> files. I used the same tar syntax, with the exception of running it verbose.
> 
> If I now have to use tar in single user mode, so be it. I did not have to do
> this previously though.

Having updated today - or rather tried to - I'm now seeing similar
problems. Keyboard input is obviously active, and the console driver
will let me switch virtual ttys, but no user processes seem to be
getting any cpu. There's no tape drive involved in freezing the
system, just disk activity across multiple devices on the
controller. In particular, I've got:

<SEAGATE ST39236LW 0004>           at scbus0 target 0 lun 0 (pass0,da0)
<SEAGATE ST39173W 5958>            at scbus0 target 1 lun 0 (pass1,da1)

attached to:

<Adaptec aic7890/91 Ultra2 SCSI adapter> port 0xe800-0xe8ff mem 0xfebff000-0xfebfffff irq 10 at device 14.0 on pci0

I can get it to freeze reliably - meaning every time I tried to start
X - on a kernel supped earlier today, wherease the one from June 24th
has no problems.

I've got a debugging kernel built, but don't know if I'll have time to
do any work on this in the next two weeks. I should be dealing with
email, though.

James, you might report your hardware configuration as well.

	<mike




> -----Original Message-----
> From: owner-freebsd-stable@FreeBSD.ORG
> [mailto:owner-freebsd-stable@FreeBSD.ORG]On Behalf Of Jamil Taylor
> Sent: Saturday, June 30, 2001 1:43 PM
> To: stable@FreeBSD.ORG
> Subject: System Hang During tar Backup
> 
> 
> I am encountering a problem when using tar to backup the files on my system.
> I am uncertain of when this problem began, but this worked a month ago. The
> backup seems to run for at least ten minutes, but the system seems to hang
> after a period of time. Keyboard input appears on the screen, but control-C
> has no effect. Control-Alt-Delete has no effect either, and my only option
> is to press the reset button or power down the machine. No services are
> active when the system is in this state (i.e., I cannot make a remote
> connection to the machine).
> 
> I am running 4.3-STABLE that was built after a cvsup of RELENG_4 as of
> yesterday.
> 
> I am using the following syntax:
> 
> tar --create --totals --absolute-paths --file /dev/rsa0 /
> 
> My hardware is a Seagate Scorpion STD2401LW. This is a DDS4 DAT drive.
> 
> Is anyone else experiencing a similar problem?
> 
> Thanks.
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-stable" in the body of the message
> 
--
Mike Meyer <mwm@mired.org>			http://www.mired.org/home/mwm/
Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1 14:28:22 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from scribe.pobox.com (scribe.pobox.com [208.210.124.35])
	by hub.freebsd.org (Postfix) with ESMTP id DF55537B403
	for <scsi@freebsd.org>; Sun,  1 Jul 2001 14:28:17 -0700 (PDT)
	(envelope-from jamil_taylor@pobox.com)
Received: from jamil (unknown [64.32.165.75])
	by scribe.pobox.com (Postfix) with SMTP
	id 8D69D3258B; Sun,  1 Jul 2001 17:27:57 -0400 (EDT)
From: "Jamil Taylor" <jamil_taylor@pobox.com>
To: <scsi@freebsd.org>
Cc: "Mike Meyer" <mwm@mired.org>
Subject: RE: System Hang During tar Backup
Date: Sun, 1 Jul 2001 17:29:04 -0400
Message-ID: <OAENJAIJJFKLPKFKIBMGMEPMCCAA.jamil_taylor@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
X-Priority: 3 (Normal)
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2911.0)
Importance: Normal
In-Reply-To: <15167.35974.774198.722692@guru.mired.org>
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4522.1200
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

Attached are snippets of dmesg output from my system:

FreeBSD 4.3-STABLE #13: Thu Jun 28 20:00:13 EDT 2001
    root@jamiltaylor.net:/usr/src/sys/compile/STANDARD
Timecounter "i8254"  frequency 1193182 Hz
CPU: Pentium III/Pentium III Xeon/Celeron (930.96-MHz 686-class CPU)
  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6

Features=0x383fbff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,
CM
OV,PAT,PSE36,MMX,FXSR,SSE>
real memory  = 536469504 (523896K bytes)
config> q
avail memory = 518221824 (506076K bytes)
Changing APIC ID for IO APIC #0 from 0 to 2 on chip
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor motherboard
 cpu0 (BSP): apic id:  0, version: 0x00040011, at 0xfee00000
 cpu1 (AP):  apic id:  1, version: 0x00040011, at 0xfee00000
 io0 (APIC): apic id:  2, version: 0x00170020, at 0xfec00000

----------------------------------------------------------------------------
---

ahc0: <Adaptec 2930CU SCSI adapter> port 0xec00-0xecff mem
0xfafff000-0xfaffffff
 irq 13 at device 5.0 on pci3
aic7860: Single Channel A, SCSI Id=7, 3/255 SCBs
ahc1: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe800-0xe8ff mem
0xfaffe000-
0xfaffefff irq 17 at device 10.0 on pci3
aic7899: Wide Channel A, SCSI Id=7, 32/255 SCBs
ahc2: <Adaptec aic7899 Ultra160 SCSI adapter> port 0xe400-0xe4ff mem
0xfaffd000-
0xfaffdfff irq 2 at device 10.1 on pci3
aic7899: Wide Channel B, SCSI Id=7, 32/255 SCBs

----------------------------------------------------------------------------
---
sa0 at ahc1 bus 0 target 6 lun 0
sa0: <SEAGATE DAT    06240-XXX 8110> Removable Sequential Access SCSI-3
device
sa0: 80.000MB/s transfers (40.000MHz, offset 32, 16bit)
pass1 at ahc0 bus 0 target 3 lun 0
pass1: <HP C7670A 3925> Fixed Processor SCSI-2 device
pass1: 3.300MB/s transfers
Mounting root from ufs:/dev/da1s3a
da1 at ahc1 bus 0 target 0 lun 0
da1: <SEAGATE ST318404LW 0006> Fixed Direct Access SCSI-3 device
da1: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing
Enable
d
da1: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
da3 at ahc1 bus 0 target 2 lun 0
da3: <SEAGATE ST318404LW 0006> Fixed Direct Access SCSI-3 device
da3: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing
Enable
d
da3: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
da2 at ahc1 bus 0 target 1 lun 0
da2: <SEAGATE ST318404LW 0006> Fixed Direct Access SCSI-3 device
da2: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing
Enable
d
da2: 17501MB (35843670 512 byte sectors: 255H 63S/T 2231C)
cd0 at ahc0 bus 0 target 1 lun 0
cd0: <TOSHIBA DVD-ROM SD-M1401 1007> Removable CD-ROM SCSI-2 device
cd0: 20.000MB/s transfers (20.000MHz, offset 15)
cd0: Attempt to query device size failed: NOT READY, Medium not present
cd1 at ahc0 bus 0 target 4 lun 0
cd1: <YAMAHA CRW8424S 1.0j> Removable CD-ROM SCSI-2 device
cd1: 20.000MB/s transfers (20.000MHz, offset 15)
cd1: Attempt to query device size failed: NOT READY, Medium not present -
tray c
losed
da0 at ahc0 bus 0 target 5 lun 0
da0: <FUJITSU MCD3130SS 0020> Removable Optical SCSI-2 device
da0: 10.000MB/s transfers (10.000MHz, offset 15)
da0: Attempt to query device size failed: NOT READY, Medium not present

-----Original Message-----
From: Mike Meyer [mailto:mwm@mired.org]
Sent: Sunday, July 01, 2001 4:48 PM
To: Jamil Taylor
Cc: scsi@freebsd.org
Subject: RE: System Hang During tar Backup

Having updated today - or rather tried to - I'm now seeing similar
problems. Keyboard input is obviously active, and the console driver
will let me switch virtual ttys, but no user processes seem to be
getting any cpu. There's no tape drive involved in freezing the
system, just disk activity across multiple devices on the
controller. In particular, I've got:

<SEAGATE ST39236LW 0004>           at scbus0 target 0 lun 0 (pass0,da0)
<SEAGATE ST39173W 5958>            at scbus0 target 1 lun 0 (pass1,da1)

attached to:

<Adaptec aic7890/91 Ultra2 SCSI adapter> port 0xe800-0xe8ff mem
0xfebff000-0xfebfffff irq 10 at device 14.0 on pci0

I can get it to freeze reliably - meaning every time I tried to start
X - on a kernel supped earlier today, wherease the one from June 24th
has no problems.

I've got a debugging kernel built, but don't know if I'll have time to
do any work on this in the next two weeks. I should be dealing with
email, though.

James, you might report your hardware configuration as well.

	<mike


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Sun Jul  1 17: 9:59 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id BD1BF37B403
	for <freebsd-scsi@freebsd.org>; Sun,  1 Jul 2001 17:09:53 -0700 (PDT)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id SAA26714;
	Sun, 1 Jul 2001 18:09:47 -0600 (MDT)
	(envelope-from ken)
Date: Sun, 1 Jul 2001 18:09:47 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Joerg Schilling <schilling@fokus.gmd.de>
Cc: mckay@thehub.com.au, freebsd-scsi@freebsd.org
Subject: Re: Problems reading burned CDs
Message-ID: <20010701180947.A26662@panzer.kdm.org>
References: <200107011208.OAA16717@fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <200107011208.OAA16717@fokus.gmd.de>; from schilling@fokus.gmd.de on Sun, Jul 01, 2001 at 02:08:18PM +0200
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Sun, Jul 01, 2001 at 14:08:18 +0200, Joerg Schilling wrote:
> >From ken@panzer.kdm.org Sun Jul  1 06:01:32 2001
> 
> >[ CCing Joerg Schilling, since he might have a clue about what's going on
> >here.  Joerg:  look down at the bottom of this message for the question
> >addressed to you.  The rest of this is primarily background information. ]
> 
> >On Thu, Jun 28, 2001 at 22:25:18 +1000, Stephen McKay wrote:
> >> # dd if=/dev/cd1c of=/dev/null bs=4k
> >> dd: /dev/cd1c: Input/output error
> >> 4183+0 records in
> >> 4183+0 records out
> >> 17133568 bytes transferred in 88.895442 secs (192738 bytes/sec)
> >> 
> >> Also, the system logs "Random positioning error" scsi errors, and there
> 
> It is really a bad idea to use dd to read a CD.
> 
> To read a CD use 'readcd'.
> 
> Unfortunately this does not work for ATAPI on FreeBSD. Another reason to see why
> uniform SCSI suport is needed....

That would be nice.  Soren does what he wants to, though, so we have
separate ATA and SCSI subsystems for now.

> >> Is there any way around these problems with SCSI CD drives?
> 
> Read README.verify & README.copy for a long answer....

Ahh, that does explain some things.

> >Just out of curiosity, what did you use to burn the CD?  cdrecord?
> 
> >I spent some time looking into this, and got some interesting results.  In
> >short, I can reproduce your results with a burned CD versus a pressed CD.
> 
> There is no difference between a burned and a pressed CD.
> There _is_ a difference between a TAO and a DAO CD.

Ahh, I see.  Is there any way to detect a TAO CD?

> >The results are the same for both a Plextor CD-RW and a Toshiba DVD-ROM in
> >my machine, so I don't think it's a CDROM firmware issue.
> 
> >It looks like the problem is a capacity reporting problem, possibly due to
> >the way the burned CD was burned.
> 
> There is no capacity reporting problem, the capacity is reported as documented
> in the CD standards.

Well, it's good to know it isn't a bug. :)

> >So let's bump the timeout up to 120 seconds and try to read the same block
> >again:
> 
> ># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
> >camcontrol: error sending command
> >(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
> >(pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0
> >(pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred
> 
> This makes me believe that you have a bug in the SCSI Transport in the kernel...

Nope, that's the expected behavior.  We give the user the option of turning
on error recovery, and I didn't use error recovery.  

If the user turns on error recovery, and specifies enough retries, he won't
see any unit attention conditions.

> >Oh yeah, the BDR sent in response to the timeout will cause a unit
> >attention condition.  Let's try it again:
> 
> ># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
> >camcontrol: error sending command
> >(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
> >(pass2:ahc1:0:4:0): MEDIUM ERROR info:48a2e asc:11,5
> >(pass2:ahc1:0:4:0): L-EC uncorrectable error
> 
> This one or 'illegal mode for this track' is a correct repspose.
> You should check why the drivr send a bus reset to the drive without reason.

The driver sent a bus device reset because the default timeout of 5
seconds wasn't long enough for the command to complete.

> >Hmm, looks like we can't read the LBA the drive claims is the last one on
> >the CD.
> 
> >Still can't read that one.  Let's try decrementing the LBA again:
> 
> ># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297516 1 -i 2048 - > /dev/null
> 
> >That works fine.
> 
> As documented in several standards an in README.copy & README.verify
> 
> >So it looks like the CD may have a bogus table of contents on it, since it
> >doesn't seem to describe the range of valid data on the disk.  The table of
> >contents on the drives seems to agree with the read capacity data:  (that's
> >probably where the drive gets the data in the first place)
> 
> 
> The TOC is OK, many OS don't deal correctly with the run-out blocks.
> While it is OK for dd to abort, it is not OK when the filesystem does read-ahead
> bejond the FS size as noted in the PVD and then believes that the last blocks
> (including parts of the last file) are un-readable.

FreeBSD won't read past the specified end of media (as reported by the read
capacity command), and shouldn't have any trouble reading files on the CD,
since any file won't encompass the last two blocks on a TAO CD.

> >This is the Plextor CD-RW with the burned CD-RW in it:
> 
> ># cdrecord dev=1,4,0 -toc
> >Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
> 
> A really old one.....

It works well enough, although I should upgrade. :)

> >So now the question for Joerg -- do you know of any difference between
> >burned CDs and "pressed" CDs (i.e. CDs produced commercially) that would
> >account for the reported capacity of the burned CDs apparantly being a
> >couple of blocks longer than the actual amount of data that can be read?
> 
> >Or could it possibly be a bug in mkisofs or cdrecord that's causing the TOC
> >to get written improperly?  (I don't know which application writes the TOC,
> >or whether the drive is actually doing it.)
> 
> >Anyway, I don't have a ready answer for this one.  Hopefully Joerg can shed
> >some light on the problem.
> 
> If you write in TAO, you get 2 run-out blocks (16 ??? on early Yamaha)
> that are part of the TOC. 

Thanks for the explanation.  I didn't know about the run-out blocks.

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2  6:42: 3 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id 7BD2D37B403
	for <freebsd-scsi@freebsd.org>; Mon,  2 Jul 2001 06:41:57 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from burner.fokus.gmd.de (burner [193.175.133.116])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA24389;
	Mon, 2 Jul 2001 15:41:47 +0200 (MET DST)
Received: (from jes@localhost)
	by burner.fokus.gmd.de (8.9.3+Sun/8.9.3) id PAA16435;
	Mon, 2 Jul 2001 15:41:40 +0200 (MEST)
Date: Mon, 2 Jul 2001 15:41:40 +0200 (MEST)
Message-Id: <200107021341.PAA16435@burner.fokus.gmd.de>
From: schilling@fokus.gmd.de
To: ken@kdm.org, schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>From ken@panzer.kdm.org Mon Jul  2 02:09:50 2001

>> To read a CD use 'readcd'.
>> 
>> Unfortunately this does not work for ATAPI on FreeBSD. Another reason to see why
>> uniform SCSI suport is needed....

>That would be nice.  Soren does what he wants to, though, so we have
>separate ATA and SCSI subsystems for now.

The more features cdrecord gives you the more sense is in having a unique
interface.

The latest cdrecord e.g. introduces RAW writing which is thew only way
of doing DAO on Philips drives.  Note that Philips OEM drives are dominating
the drive market now.

Also 99 minutes CD may only be written in RAW mode as firmware does not
handle anything > 79 minutes as you expect.


>> There is no difference between a burned and a pressed CD.
>> There _is_ a difference between a TAO and a DAO CD.

>Ahh, I see.  Is there any way to detect a TAO CD?

If you have a MMC writer, you could send a read disk info and check the disk status.
In general it does not work :-(
So you could say that in general you cannot distinguish a CD with bad sectors
from one written on TAO.

>> There is no capacity reporting problem, the capacity is reported as documented
>> in the CD standards.

>Well, it's good to know it isn't a bug. :)

It definitely _is_ a bug.

There is no reason why a host should send a SCSI bus device reset except when
the drive does not respond to a unit reset and even that is not necessary in out case.

>> >So let's bump the timeout up to 120 seconds and try to read the same block
>> >again:
>> 
>> ># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
>> >camcontrol: error sending command
>> >(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
>> >(pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0
>> >(pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred
>> 
>> This makes me believe that you have a bug in the SCSI Transport in the kernel...

>Nope, that's the expected behavior.  We give the user the option of turning
>on error recovery, and I didn't use error recovery.  

If you connect one storage unit to more than one computer for availability,
bad things may happen if you send SCSI bus resets without rerason.
Even when you only have a local SCSI bus but a tape drive it will rewind!

Sending SCSI bus resets is the quick and dirty way SCSI drivers on UNIX have been
in the mid 80's. This time has gone....

>The driver sent a bus device reset because the default timeout of 5
>seconds wasn't long enough for the command to complete.

5 seconds is definitely too short.

Anything < 20 seconds makes no sense.

>> As documented in several standards an in README.copy & README.verify
>> 
>> >So it looks like the CD may have a bogus table of contents on it, since it
>> >doesn't seem to describe the range of valid data on the disk.  The table of
>> >contents on the drives seems to agree with the read capacity data:  (that's
>> >probably where the drive gets the data in the first place)
>> 
>> 
>> The TOC is OK, many OS don't deal correctly with the run-out blocks.
>> While it is OK for dd to abort, it is not OK when the filesystem does read-ahead
>> bejond the FS size as noted in the PVD and then believes that the last blocks
>> (including parts of the last file) are un-readable.

>FreeBSD won't read past the specified end of media (as reported by the read
>capacity command), and shouldn't have any trouble reading files on the CD,
>since any file won't encompass the last two blocks on a TAO CD.

So did you tests with a TAO ISO-9660 CD where the last file's last block is in the
first fraction of a FS buffer block and the rest would take the run-out sectors? 

>> ># cdrecord dev=1,4,0 -toc
>> >Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
>> 
>> A really old one.....

>It works well enough, although I should upgrade. :)

If you have a drive that does not support SAO, you would like to use RAW writing.

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2  7:25:57 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30])
	by hub.freebsd.org (Postfix) with ESMTP id 10D9E37B40B
	for <freebsd-scsi@freebsd.org>; Mon,  2 Jul 2001 07:25:49 -0700 (PDT)
	(envelope-from mckay@thehub.com.au)
Received: from dungeon.home (ppp125.dyn249.pacific.net.au [203.143.249.125])
	by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id AAA00126;
	Tue, 3 Jul 2001 00:25:46 +1000 (EST)
Received: from dungeon.home (localhost [127.0.0.1])
	by dungeon.home (8.11.3/8.11.1) with ESMTP id f62EPxX12646;
	Tue, 3 Jul 2001 00:25:59 +1000 (EST)
	(envelope-from mckay)
Message-Id: <200107021425.f62EPxX12646@dungeon.home>
To: schilling@fokus.gmd.de
Cc: ken@kdm.org, freebsd-scsi@freebsd.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs 
References: <200107021341.PAA16435@burner.fokus.gmd.de>
In-Reply-To: <200107021341.PAA16435@burner.fokus.gmd.de>
    from schilling@fokus.gmd.de at "Mon, 02 Jul 2001 15:41:40 +0200"
Date: Tue, 03 Jul 2001 00:25:59 +1000
From: Stephen McKay <mckay@thehub.com.au>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Monday, 2nd July 2001, schilling@fokus.gmd.de wrote:

>The more features cdrecord gives you the more sense is in having a unique
>interface.

I still have hopes that a unified CD burner driver interface can be
built.  There are many ways to burn a CD (unfortunately!) but we only
need a few by default.  For example, I believe it is safe nowadays to
write everything as multisession (left open).  That could be the
default.  Also, now we know that TAO causes certain problems, we can
pad by default.  And so on.  Maybe raw writing becomes the default too.
It's too complicated the way it is.

>The latest cdrecord e.g. introduces RAW writing which is thew only way
>of doing DAO on Philips drives.  Note that Philips OEM drives are dominating
>the drive market now.

Can this be automatically detected?  Then the best write mode can be
used without the user being involved.

>>> There is no difference between a burned and a pressed CD.
>>> There _is_ a difference between a TAO and a DAO CD.

>So you could say that in general you cannot distinguish a CD with bad sectors
>from one written on TAO.

This kills all my ideas for making this "just work".  But I might experiment
with heuristics to lower timeouts for the last 2 sectors and absorb errors
on them.  Don't worry Jörg, I won't commit anything without consensus!

>>FreeBSD won't read past the specified end of media (as reported by the read
>>capacity command), and shouldn't have any trouble reading files on the CD,
>>since any file won't encompass the last two blocks on a TAO CD.
>
>So did you tests with a TAO ISO-9660 CD where the last file's last block is in the
>first fraction of a FS buffer block and the rest would take the run-out sectors? 

What's the simplest way (using cdrecord) to write such a disk?  I'll test
it on my gear.  I am not in the habit of intentionally making difficult to
read CDs.  That happens only by accident. :-)  So I could use a hint.

By the way, Jörg, do you have expert knowledge of CDROM filesystems,
as well as CD burners?  I have a multisession Joliet CDROM that is
completely unreadable on FreeBSD (mount reports cd9660: /dev/acd0c:
Invalid argument).  It has one more track than it has sessions.  The
extra track is between the others, and is 63 seconds long.  It reads
perfectly on Win98.

Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2  8: 6:28 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id D8B3037B403
	for <freebsd-scsi@freebsd.org>; Mon,  2 Jul 2001 08:06:23 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from burner.fokus.gmd.de (burner [193.175.133.116])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id RAA05596;
	Mon, 2 Jul 2001 17:06:15 +0200 (MET DST)
Received: (from jes@localhost)
	by burner.fokus.gmd.de (8.9.3+Sun/8.9.3) id RAA20637;
	Mon, 2 Jul 2001 17:06:08 +0200 (MEST)
Date: Mon, 2 Jul 2001 17:06:08 +0200 (MEST)
Message-Id: <200107021506.RAA20637@burner.fokus.gmd.de>
From: schilling@fokus.gmd.de
To: mckay@thehub.com.au, schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, ken@kdm.org
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>From mckay@thehub.com.au Mon Jul  2 16:26:06 2001

>>The more features cdrecord gives you the more sense is in having a unique
>>interface.

>I still have hopes that a unified CD burner driver interface can be
>built.  There are many ways to burn a CD (unfortunately!) but we only
>need a few by default.  For example, I believe it is safe nowadays to
>write everything as multisession (left open).  That could be the
>default.  Also, now we know that TAO causes certain problems, we can
>pad by default.  And so on.  Maybe raw writing becomes the default too.
>It's too complicated the way it is.

The unified cd recorder interface is the top level of libscg.

It is > 99% compatible on any of 29 supported OS.

You will not really try to write your own cd recording program inside the kernel
and this even in two versions (SCSI & ATAPI) will you?

>>The latest cdrecord e.g. introduces RAW writing which is thew only way
>>of doing DAO on Philips drives.  Note that Philips OEM drives are dominating
>>the drive market now.

>Can this be automatically detected?  Then the best write mode can be
>used without the user being involved.

Cdrecord tells you a supported mode if you select the wrong one.

>What's the simplest way (using cdrecord) to write such a disk?  I'll test
>it on my gear.  I am not in the habit of intentionally making difficult to
>read CDs.  That happens only by accident. :-)  So I could use a hint.

Create any CD with only one medium sized file on it (e.g. 2-10 MB).

use mkisofs -no-pad to create a ISO image. Check whether this image
will not be a multiple of the kernel's FS buffer size.
Write the image in TAO, mount the media and do a dd from the file on the
ISO FS.

>By the way, Jörg, do you have expert knowledge of CDROM filesystems,
>as well as CD burners?  I have a multisession Joliet CDROM that is
>completely unreadable on FreeBSD (mount reports cd9660: /dev/acd0c:
>Invalid argument).  It has one more track than it has sessions.  The
>extra track is between the others, and is 63 seconds long.  It reads
>perfectly on Win98.

Well first: Joliet is non standard, second: you cannot really create
a multi session CD without Rock Ridge and with only Joliet on it.
The reason is that there is no relation between the Joliet filenames
and the ISO filenames.

If the CD is XA-mode 2 it may be that your CD-rom or the kernel driver
does not support to read XA.


Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2  8:28:17 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30])
	by hub.freebsd.org (Postfix) with ESMTP id 59ADB37B405
	for <freebsd-scsi@freebsd.org>; Mon,  2 Jul 2001 08:28:13 -0700 (PDT)
	(envelope-from mckay@thehub.com.au)
Received: from dungeon.home (ppp125.dyn249.pacific.net.au [203.143.249.125])
	by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id BAA02791;
	Tue, 3 Jul 2001 01:28:07 +1000 (EST)
Received: from dungeon.home (localhost [127.0.0.1])
	by dungeon.home (8.11.3/8.11.1) with ESMTP id f62FSKX13432;
	Tue, 3 Jul 2001 01:28:20 +1000 (EST)
	(envelope-from mckay)
Message-Id: <200107021528.f62FSKX13432@dungeon.home>
To: schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, ken@kdm.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs 
References: <200107021506.RAA20637@burner.fokus.gmd.de>
In-Reply-To: <200107021506.RAA20637@burner.fokus.gmd.de>
    from schilling@fokus.gmd.de at "Mon, 02 Jul 2001 17:06:08 +0200"
Date: Tue, 03 Jul 2001 01:28:20 +1000
From: Stephen McKay <mckay@thehub.com.au>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Monday, 2nd July 2001, schilling@fokus.gmd.de wrote:

>The unified cd recorder interface is the top level of libscg.
>
>It is > 99% compatible on any of 29 supported OS.
>
>You will not really try to write your own cd recording program inside the
>kernel and this even in two versions (SCSI & ATAPI) will you?

Before I learned how complex it was, yes I was interested in having
SCSI CD burning support in the kernel (like ATAPI).  But now? :-)

If you have a FreeBSD system handy, try "man burncd".  This is slightly
more complex than I would like it to be, and it is ATAPI only.  Perhaps
with libscg it could be ATAPI and SCSI.  But then the huge number of
options that cdrecord has would have to be trimmed down to fit burncd's
simpler approach.  Thus the search for sensible defaults that nobody
normally has to change.

>>>The latest cdrecord e.g. introduces RAW writing which is thew only way
>>>of doing DAO on Philips drives.  Note that Philips OEM drives are dominating
>>>the drive market now.
>
>>Can this be automatically detected?  Then the best write mode can be
>>used without the user being involved.
>
>Cdrecord tells you a supported mode if you select the wrong one.

I'm still looking for more automation.  The user says "Burn this stuff
to a CD.  Use whatever mode works best.  Tell me when you are done."
Behind the scenes the default should also be friendly to our CD reading
routines (default to DAO, and pad TAO, that sort of thing).

>>By the way, Jörg, do you have expert knowledge of CDROM filesystems,
>>as well as CD burners?  I have a multisession Joliet CDROM that is
>>completely unreadable on FreeBSD (mount reports cd9660: /dev/acd0c:
>>Invalid argument).  It has one more track than it has sessions.  The
>>extra track is between the others, and is 63 seconds long.  It reads
>>perfectly on Win98.
>
>Well first: Joliet is non standard, second: you cannot really create
>a multi session CD without Rock Ridge and with only Joliet on it.
>The reason is that there is no relation between the Joliet filenames
>and the ISO filenames.

It was created on an NT box using Adaptec Easy CD Creator in two
sessions.  But it has three tracks on it.

When you say "Joliet is non standard", are you saying that there is
no published documentation?  I can believe that.

>If the CD is XA-mode 2 it may be that your CD-rom or the kernel driver
>does not support to read XA.

The same hardware running Win98 will read the CD that FreeBSD won't read.
I have other multisession CDs made with the same method on the same
system.  FreeBSD reads them all properly.  It is quite puzzling.

Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2 20:47:59 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id C5C2C37B403
	for <freebsd-scsi@freebsd.org>; Mon,  2 Jul 2001 20:47:52 -0700 (PDT)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id VAA34273;
	Mon, 2 Jul 2001 21:47:47 -0600 (MDT)
	(envelope-from ken)
Date: Mon, 2 Jul 2001 21:47:47 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Message-ID: <20010702214746.A34195@panzer.kdm.org>
References: <200107021341.PAA16435@burner.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
User-Agent: Mutt/1.2i
In-Reply-To: <200107021341.PAA16435@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Mon, Jul 02, 2001 at 03:41:40PM +0200
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Mon, Jul 02, 2001 at 15:41:40 +0200, schilling@fokus.gmd.de wrote:
> >From ken@panzer.kdm.org Mon Jul  2 02:09:50 2001
> 
> >> To read a CD use 'readcd'.
> >> 
> >> Unfortunately this does not work for ATAPI on FreeBSD. Another reason to see why
> >> uniform SCSI suport is needed....
> 
> >That would be nice.  Soren does what he wants to, though, so we have
> >separate ATA and SCSI subsystems for now.
> 
> The more features cdrecord gives you the more sense is in having a unique
> interface.
> 
> The latest cdrecord e.g. introduces RAW writing which is thew only way
> of doing DAO on Philips drives.  Note that Philips OEM drives are dominating
> the drive market now.
> 
> Also 99 minutes CD may only be written in RAW mode as firmware does not
> handle anything > 79 minutes as you expect.

I'm not the one you have to sell on the idea. :)

> >> There is no difference between a burned and a pressed CD.
> >> There _is_ a difference between a TAO and a DAO CD.
> 
> >Ahh, I see.  Is there any way to detect a TAO CD?
> 
> If you have a MMC writer, you could send a read disk info and check the disk status.
> In general it does not work :-(
> So you could say that in general you cannot distinguish a CD with bad sectors
> from one written on TAO.

Ahh, okay.  So I suppose the solution is just to leave it as-is, and
missing a few blocks at the end is expected behavior for TAO.

> >> There is no capacity reporting problem, the capacity is reported as documented
> >> in the CD standards.
> 
> >Well, it's good to know it isn't a bug. :)
> 
> It definitely _is_ a bug.
> 
> There is no reason why a host should send a SCSI bus device reset except when
> the drive does not respond to a unit reset and even that is not necessary in out case.

We're talking about two different things here.  I was talking about
capacity reporting for TAO CDs.  It looks like you're talking about
sending a BDR versus a logical unit reset when a device doesn't respond.

My guess is that the ahc driver (aic7xxx) sends a BDR since most
devices understand that.  A logical unit reset is a post SCSI-2
development I believe.

> >> >So let's bump the timeout up to 120 seconds and try to read the same block
> >> >again:
> >> 
> >> ># camcontrol cmd cd0 -v -t 120 -c "28 0 v:i4 0 v:i2 0" 297518 1 -i 2048 - > /dev/null
> >> >camcontrol: error sending command
> >> >(pass2:ahc1:0:4:0): READ(10). CDB: 28 0 0 4 8a 2e 0 0 1 0 
> >> >(pass2:ahc1:0:4:0): UNIT ATTENTION asc:29,0
> >> >(pass2:ahc1:0:4:0): Power on, reset, or bus device reset occurred
> >> 
> >> This makes me believe that you have a bug in the SCSI Transport in the kernel...
> 
> >Nope, that's the expected behavior.  We give the user the option of turning
> >on error recovery, and I didn't use error recovery.  
> 
> If you connect one storage unit to more than one computer for availability,
> bad things may happen if you send SCSI bus resets without rerason.
> Even when you only have a local SCSI bus but a tape drive it will rewind!
> 
> Sending SCSI bus resets is the quick and dirty way SCSI drivers on UNIX have been
> in the mid 80's. This time has gone....

The driver didn't send a bus reset, but rather a bus *device* reset.
That shouldn't hose up other devices on the bus.

> >The driver sent a bus device reset because the default timeout of 5
> >seconds wasn't long enough for the command to complete.
> 
> 5 seconds is definitely too short.
> 
> Anything < 20 seconds makes no sense.

The 5 second timeout is just a default timeout for a generic SCSI
command facility, not the timeout for a particular command.
camcontrol(8) doesn't look at the command the user is attempting to
send and then have some default timeout for it.  That would be too
cumbersome.  Instead, if the user is composing his own CDB (as opposed
to using a predefined camcontrol operation, like 'camcontrol format'),
he is expected to also know what sort of timeout he should set.

In this case I didn't set the timeout, and the 5 second default was
too short.

> >> The TOC is OK, many OS don't deal correctly with the run-out blocks.
> >> While it is OK for dd to abort, it is not OK when the filesystem does read-ahead
> >> bejond the FS size as noted in the PVD and then believes that the last blocks
> >> (including parts of the last file) are un-readable.
> 
> >FreeBSD won't read past the specified end of media (as reported by the read
> >capacity command), and shouldn't have any trouble reading files on the CD,
> >since any file won't encompass the last two blocks on a TAO CD.
> 
> So did you tests with a TAO ISO-9660 CD where the last file's last block is in the
> first fraction of a FS buffer block and the rest would take the run-out sectors? 

Nope, I didn't test it.  FreeBSD doesn't chunk things into arbitrary
block sizes inside the kernel like Linux.  The FreeBSD ISO9660
filesystem code operates with the blocksize reported by the underlying
device.  (i.e. 2K)

> >> ># cdrecord dev=1,4,0 -toc
> >> >Cdrecord 1.9 (i386-unknown-freebsd4.2) Copyright (C) 1995-2000 Jörg Schilling
> >> 
> >> A really old one.....
> 
> >It works well enough, although I should upgrade. :)
> 
> If you have a drive that does not support SAO, you would like to use RAW writing.

Ahh.

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2 22:58:55 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from smtprt16.wanadoo.fr (smtprt16.wanadoo.fr [193.252.19.183])
	by hub.freebsd.org (Postfix) with ESMTP id 8C31137B403
	for <freebsd-scsi@FreeBSD.ORG>; Mon,  2 Jul 2001 22:58:52 -0700 (PDT)
	(envelope-from dockes@real-time.com)
Received: from amyris.wanadoo.fr (193.252.19.150) by smtprt16.wanadoo.fr; 3 Jul 2001 07:58:51 +0200
Received: from layon.wanadoo.fr (193.250.242.69) by amyris.wanadoo.fr; 3 Jul 2001 07:58:43 +0200
Received: (from dockes@localhost)
	by layon.wanadoo.fr (8.11.3/8.11.3) id f097xes01878;
	Tue, 9 Jan 2001 08:59:40 +0100
From: Jean-Francois Dockes <jean-francois.dockes@wanadoo.fr>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: 8bit
Message-ID: <14938.50411.764264.64943@gargle.gargle.HOWL>
Date: Tue, 9 Jan 2001 08:59:39 +0100
To: schilling@fokus.gmd.de
Cc: ken@kdm.org, freebsd-scsi@FreeBSD.ORG, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
In-Reply-To: <200107021341.PAA16435@burner.fokus.gmd.de>
References: <200107021341.PAA16435@burner.fokus.gmd.de>
X-Mailer: VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

schilling@fokus.gmd.de writes:
 > If you have a MMC writer, you could send a read disk info and check the
 > disk status.  In general it does not work :-( So you could say that in
 > general you cannot distinguish a CD with bad sectors from one written on
 > TAO.
 > 
Both MMC and pre MMC-writers have a (different: 0x52/0xe5) command named
something like 'READ TRACK INFO' which returns the track data length, and
would allow detecting a TAO disk by comparing the returned value, which
comes from the cdr-specific Program Memory Area (PMA), to the TOC data. 

For a TAO disk, there is usually a difference of 2 (the runout blocks).

I think that a more accurate statement would be to say that you cannot
detect a TAO disk on a *reader* (except if the firmware in current writers
has deteriorated to the point where they don't support READ TRACK INFO, about
which I have no idea).

 > While it is OK for dd to abort, it is not OK when the filesystem does
 > read-ahead bejond the FS size as noted in the PVD and then believes
 > that the last blocks (including parts of the last file) are
 > un-readable.
 > 
 > >From ken@panzer.kdm.org Mon Jul  2 02:09:50 2001
 > >FreeBSD won't read past the specified end of media (as reported by the read
 > >capacity command), and shouldn't have any trouble reading files on the CD,
 > >since any file won't encompass the last two blocks on a TAO CD.

As Jörg noted, the end of the iso9660 volume should be taken from the PVD,
not the READ CAPACITY data (or take the smallest of the 2). This way, you
won't ever try to read the runout blocks. Indeed, I think that this is what
the FreeBSD iso mount code does (of course).

As read requests are usually truncated to the volume size (at least they
used to), I don't think that it would be possible to cause an error by
reading a logical iso9660 file. 

Only dd from the physical track will cause an error, but then, CDs are
complicated beasts, and you can't expect dd to work on them in the
general case. In some important cd formats (xa), the driver has no way to
know *what* data to return to a read call, if not specifically instructed
what to do. dd would need a few additional options before this works,
but I guess that this is the reason why 'readcd' exists :)

Regards,
Jean-Francois Dockes


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Mon Jul  2 23:18: 9 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from TYO201.gate.nec.co.jp (TYO201.gate.nec.co.jp [202.32.8.214])
	by hub.freebsd.org (Postfix) with ESMTP id 47B5137B401
	for <scsi@FreeBSD.ORG>; Mon,  2 Jul 2001 23:18:04 -0700 (PDT)
	(envelope-from T.Anchalalai@thai.necl.nec.co.jp)
Received: from mailgate4.nec.co.jp ([10.7.69.193])
	by TYO201.gate.nec.co.jp (8.11.3/3.7W01041220) with ESMTP id f636I2a05430
	for <scsi@FreeBSD.ORG>; Tue, 3 Jul 2001 15:18:02 +0900 (JST)
Received: from mailsv.nec.co.jp (mailgate51.nec.co.jp [10.7.69.190]) by mailgate4.nec.co.jp (8.11.3/3.7W-MAILGATE-NEC) with ESMTP
	id f636HxK10189 for <scsi@FreeBSD.ORG>; Tue, 3 Jul 2001 15:17:59 +0900 (JST)
Received: from MT-NECLI6.kis.necl.nec.co.jp ([10.113.16.225]) by mailsv.nec.co.jp (8.11.3/3.7W-MAILSV-NEC) with ESMTP
	id f636Htt00874 for <scsi@FreeBSD.ORG>; Tue, 3 Jul 2001 15:17:55 +0900 (JST)
Received: from necl-t03.THAI.NECL.NEC.CO.JP ([172.16.58.246])
          by MT-NECLI6.kis.necl.nec.co.jp (Post.Office MTA v3.5.3J
          release 223-101-J ID# 1001-70956U100L100S0V35J) with ESMTP id jp
          for <scsi@FreeBSD.ORG>; Tue, 3 Jul 2001 15:12:24 +0900
Received: from edp3 ([172.16.58.83]) by necl-t03.THAI.NECL.NEC.CO.JP
          (Post.Office MTA v3.5.3 release 223 ID# 110-60190U100L100S0V35)
          with SMTP id JP for <scsi@FreeBSD.ORG>;
          Tue, 3 Jul 2001 12:14:17 +0700
Message-ID: <004201c10381$32ec5c60$533a10ac@edp3>
From: T.Anchalalai@thai.necl.nec.co.jp (ANCHALALAI TRONGTORSAK)
To: <scsi@FreeBSD.ORG>
Date: Tue, 3 Jul 2001 12:29:58 +0700
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_NextPart_000_003F_01C103BB.DF29A2A0"
X-Priority: 3
X-MSMail-Priority: Normal
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
X-MimeOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


This is a multi-part message in MIME format.

------=_NextPart_000_003F_01C103BB.DF29A2A0
Content-Type: text/plain;
	charset="windows-874"
Content-Transfer-Encoding: quoted-printable

           =20
        Good afternoon, I'd like to quest you about PYTHON 28388-XXX =
SCSI tape drive as below :=20

            1.What type of back up tape it's compatible for?
            2.There are error message"There're unused media,please =
choose another type of media",when I utilize DSS 90 Meter with it.Why?=20


Thanks so much

------=_NextPart_000_003F_01C103BB.DF29A2A0
Content-Type: text/html;
	charset="windows-874"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Dwindows-874">
<META content=3D"MSHTML 5.50.4207.2601" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial=20
size=3D2>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;=20
<DIV>
<DIV><FONT face=3DVerdana size=3D4>&nbsp;&nbsp;&nbsp; &nbsp;&nbsp;&nbsp; =
Good=20
afternoon, I'd like to quest you about PYTHON 28388-XXX SCSI tape drive =
as below=20
: </FONT></DIV>
<DIV><FONT face=3DVerdana size=3D4></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana=20
size=3D4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p; 1.What=20
type of back up tape it's compatible for?</FONT></DIV>
<DIV><FONT face=3DVerdana=20
size=3D4>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbs=
p;&nbsp;2.There=20
are error message"There're unused media,please choose another&nbsp;type =
of=20
media",when I utilize DSS 90 Meter with it.Why? </FONT></DIV>
<DIV><FONT face=3DVerdana size=3D4></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D4></FONT>&nbsp;</DIV>
<DIV><FONT face=3DVerdana size=3D4>Thanks so=20
much</FONT></DIV></DIV></FONT></DIV></BODY></HTML>

------=_NextPart_000_003F_01C103BB.DF29A2A0--


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Jul  3  7:31:50 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106])
	by hub.freebsd.org (Postfix) with ESMTP id 0729B37B401
	for <freebsd-scsi@FreeBSD.ORG>; Tue,  3 Jul 2001 07:31:48 -0700 (PDT)
	(envelope-from gibbs@scsiguy.com)
Received: from scsiguy.com (localhost [127.0.0.1])
	by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f63EVRU89661;
	Tue, 3 Jul 2001 08:31:31 -0600 (MDT)
	(envelope-from gibbs@scsiguy.com)
Message-Id: <200107031431.f63EVRU89661@aslan.scsiguy.com>
To: schilling@fokus.gmd.de
Cc: ken@kdm.org, freebsd-scsi@FreeBSD.ORG, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs 
In-Reply-To: Your message of "Mon, 02 Jul 2001 15:41:40 +0200."
             <200107021341.PAA16435@burner.fokus.gmd.de> 
Date: Tue, 03 Jul 2001 08:31:27 -0600
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>>> There is no capacity reporting problem, the capacity is reported as documen
>ted
>>> in the CD standards.
>
>>Well, it's good to know it isn't a bug. :)
>
>It definitely _is_ a bug.

Sending a Bus Device Reset message to a target when it doesn't respond
in the expected amount of time is a bug?  Perhaps the driver could try
an abort message first, but the behavior is not completely unreasonable.
Your other complaints seem to be in regard to a "bus reset", which never
occurred in this situation.

--
Justin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Jul  3  7:40:25 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from aslan.scsiguy.com (aslan.scsiguy.com [63.229.232.106])
	by hub.freebsd.org (Postfix) with ESMTP id C81D637B405
	for <FreeBSD-SCSI@FreeBSD.ORG>; Tue,  3 Jul 2001 07:40:23 -0700 (PDT)
	(envelope-from gibbs@scsiguy.com)
Received: from scsiguy.com (localhost [127.0.0.1])
	by aslan.scsiguy.com (8.11.2/8.9.3) with ESMTP id f63EeIU89723;
	Tue, 3 Jul 2001 08:40:18 -0600 (MDT)
	(envelope-from gibbs@scsiguy.com)
Message-Id: <200107031440.f63EeIU89723@aslan.scsiguy.com>
To: mjacob@feral.com
Cc: Norman Czarczinski <Norman.Czarczinski@t-online.de>,
	FreeBSD-SCSI@FreeBSD.ORG
Subject: Re: Trouble with SCSI Streamer 
In-Reply-To: Your message of "Sun, 01 Jul 2001 09:07:27 PDT."
             <20010701090455.M20993-100000@wonky.feral.com> 
Date: Tue, 03 Jul 2001 08:40:18 -0600
From: "Justin T. Gibbs" <gibbs@scsiguy.com>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>
>It's some kind of SCSI signal or HBA issue or breakage at the device.
>The CDB matches the S/G list spit out by the aic driver (10KB == 10KB),
>but the drive still claims to be in Data Out phase.
>
>I wonder, btw, what the Tag is doing there.

Tag == transaction identifier as well as any tag value sent to the
device.  If we aren't in a tag mode, we won't send the tag.

Do we know what the set block length is?  Perhaps the device
believes it is in 1K mode or something.

--
Justin

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Jul  3  8:59:35 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id 0562637B403
	for <FreeBSD-SCSI@FreeBSD.ORG>; Tue,  3 Jul 2001 08:59:32 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f63FxQS04634;
	Tue, 3 Jul 2001 08:59:26 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Tue, 3 Jul 2001 08:59:25 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: "Justin T. Gibbs" <gibbs@scsiguy.com>
Cc: Norman Czarczinski <Norman.Czarczinski@t-online.de>,
	FreeBSD-SCSI@FreeBSD.ORG
Subject: Re: Trouble with SCSI Streamer 
In-Reply-To: <200107031440.f63EeIU89723@aslan.scsiguy.com>
Message-ID: <Pine.BSF.4.21.0107030858470.4597-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


On Tue, 3 Jul 2001, Justin T. Gibbs wrote:

> >
> >It's some kind of SCSI signal or HBA issue or breakage at the device.
> >The CDB matches the S/G list spit out by the aic driver (10KB == 10KB),
> >but the drive still claims to be in Data Out phase.
> >
> >I wonder, btw, what the Tag is doing there.
> 
> Tag == transaction identifier as well as any tag value sent to the
> device.  If we aren't in a tag mode, we won't send the tag.
> 
> Do we know what the set block length is?  Perhaps the device
> believes it is in 1K mode or something.

No. It's in fixed mode (512 byte), and the CDB says 20 512 byte blocks,
which matches the 10K S/G list.

-matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Jul  3 22:27: 6 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id 2CA8137B407
	for <FreeBSD-SCSI@FreeBSD.ORG>; Tue,  3 Jul 2001 22:27:03 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f645QxS08757;
	Tue, 3 Jul 2001 22:26:59 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Tue, 3 Jul 2001 22:26:59 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Norman Czarczinski <Norman.Czarczinski@t-online.de>
Cc: FreeBSD-SCSI@FreeBSD.ORG
Subject: Re: Trouble with SCSI Streamer
In-Reply-To: <01070113574200.00419@amd.local>
Message-ID: <Pine.BSF.4.21.0107032226180.8572-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Say- could you do a 'mt status' on the drive with a tape inserted and
send that to me?


On Sun, 1 Jul 2001, Norman Czarczinski wrote:

> Hi,
> 
> I have a Wangtek 5525ES streamer on an Adaptec 2940UW host and run 
> FreeBSD 4.3-stable:
> ahc0: <Adaptec 2940 Ultra SCSI adapter> port 0xd800-0xd8ff mem 
> 0xe4000000-0xe4000fff irq 11 at device 12.0 on pci0
> aic7880: Wide Channel A, SCSI Id=7, 16/255 SCBs
> sa0 at ahc0 bus 0 target 5 lun 0
> sa0: <WANGTEK 5525ES SCSI REV1 6F6> Removable Sequential Access SCSI-CCS 
> device sa0: 3.300MB/s transfers
> 
> Writing the first tape works fine. But after I inserted a new tape, I get a 
> data overrun error:
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): WRITE(06). CDB: a 1 0 0 14 
> 0 
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_action
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): data overrun detected in 
> Data-out phase.  Tag == 0x4.
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): Have seen Data Phase.  
> Length = 10240.  NumSGs = 3.
> Jun 27 20:02:03 pentium /kernel: sg[0] - Addr 0x1fd7000 : Length 4096
> Jun 27 20:02:03 pentium /kernel: sg[1] - Addr 0x1eb8000 : Length 4096
> Jun 27 20:02:03 pentium /kernel: sg[2] - Addr 0x3af9000 : Length 2048
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): ahc_done - scb 4
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_done
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): camisr(sa0:ahc0:0:5:0): 
> Cam Status 0x12
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_setup_ccb
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): xpt_action
> Jun 27 20:02:03 pentium /kernel: (sa0:ahc0:0:5:0): error 5 resid 10240 count 
> 10240
> 
> Then a reboot is needed to use the streamer normaly. (camcontrol reset 
> doesn't work)
> 
> I have this problem with dump and afio. When I start them again on the 
> rewinded tape, they work. But a restart after a short tape-eject fails. Only 
> tar let me change the tape without problems. 
> 
> Any hints?
> 
> Bye
>   Norman
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Tue Jul  3 22:32: 0 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id 2BC6237B407
	for <scsi@freebsd.org>; Tue,  3 Jul 2001 22:31:16 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f645VFS08789
	for <scsi@freebsd.org>; Tue, 3 Jul 2001 22:31:15 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Tue, 3 Jul 2001 22:31:15 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: scsi@freebsd.org
Subject: target mode patches review
Message-ID: <Pine.BSF.4.21.0107032228020.8572-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


I've some changes to target mode- if folks could take a quick
look... I'm starting to migrate target more toward a model of the
user application driving more. These fix some cases with propagation
of disconnects disabled and these also us to set Inquiry data for
a device.

Index: scsi_targ_bh.c
===================================================================
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_targ_bh.c,v
retrieving revision 1.12
diff -u -r1.12 scsi_targ_bh.c
--- scsi_targ_bh.c	2001/02/07 07:05:59	1.12
+++ scsi_targ_bh.c	2001/07/04 05:27:18
@@ -1,7 +1,7 @@
 /*
  * Implementation of the Target Mode 'Black Hole device' for CAM.
  *
- * Copyright (c) 1999 Justin T. Gibbs.
+ * Copyright (c) 1999, 2001 Justin T. Gibbs.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -487,7 +487,8 @@
 		desc = (struct targbh_cmd_desc *)atio->ccb_h.ccb_descr;
 
 		/* Is this a tagged request? */
-		flags = atio->ccb_h.flags & (CAM_TAG_ACTION_VALID|CAM_DIR_MASK);
+		flags = atio->ccb_h.flags &
+		    (CAM_DIS_DISCONNECT|CAM_TAG_ACTION_VALID|CAM_DIR_MASK);
 
 		csio = &start_ccb->csio;
 		/*
@@ -510,7 +511,7 @@
 			      /*retries*/2,
 			      targbhdone,
 			      flags,
-			      (flags & CAM_TAG_ACTION_VALID)?
+			      (flags & CAM_TAG_ACTION_VALID) ?
 				MSG_SIMPLE_Q_TAG : 0,
 			      atio->tag_id,
 			      atio->init_id,
@@ -529,6 +530,19 @@
 		CAM_DEBUG(periph->path, CAM_DEBUG_SUBTRACE,
 			  ("Sending a CTIO\n"));
 		xpt_action(start_ccb);
+		/*
+		 * If the queue was frozen waiting for the response
+		 * to this ATIO (for instance disconnection was disallowed),
+		 * then release it now that our response has been queued.
+		 */
+		if ((atio->ccb_h.status & CAM_DEV_QFRZN) != 0) {
+			cam_release_devq(periph->path,
+					 /*relsim_flags*/0,
+					 /*reduction*/0,
+					 /*timeout*/0,
+					 /*getcount_only*/0); 
+			atio->ccb_h.status &= ~CAM_DEV_QFRZN;
+		}
 		s = splbio();
 		ccbh = TAILQ_FIRST(&softc->work_queue);
 		splx(s);
@@ -556,6 +570,7 @@
 		struct ccb_accept_tio *atio;
 		struct targbh_cmd_desc *descr;
 		u_int8_t *cdb;
+		int priority;
 
 		atio = &done_ccb->atio;
 		descr = (struct targbh_cmd_desc*)atio->ccb_h.ccb_descr;
@@ -645,9 +660,16 @@
 		}
 
 		/* Queue us up to receive a Continue Target I/O ccb. */
-		TAILQ_INSERT_TAIL(&softc->work_queue, &atio->ccb_h,
-				  periph_links.tqe);
-		xpt_schedule(periph, /*priority*/1);
+		if ((atio->ccb_h.flags & CAM_DIS_DISCONNECT) != 0) {
+			TAILQ_INSERT_HEAD(&softc->work_queue, &atio->ccb_h,
+					  periph_links.tqe);
+			priority = 0;
+		} else {
+			TAILQ_INSERT_TAIL(&softc->work_queue, &atio->ccb_h,
+					  periph_links.tqe);
+			priority = 1;
+		}
+		xpt_schedule(periph, priority);
 		break;
 	}
 	case XPT_CONT_TARGET_IO:
@@ -672,7 +694,22 @@
 		done_ccb->ccb_h.flags &= ~CAM_SEND_SENSE;
 		done_ccb->ccb_h.status &= ~CAM_SENT_SENSE;
 
-		/* XXX Check for errors */
+		/*
+		 * Any errors will not change the data we return,
+		 * so make sure the queue is not left frozen.
+		 * XXX - At some point there may be errors that
+		 *       leave us in a connected state with the
+		 *       initiator...
+		 */
+		if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) {
+			printf("Releasing Queue\n");
+			cam_release_devq(done_ccb->ccb_h.path,
+					 /*relsim_flags*/0,
+					 /*reduction*/0,
+					 /*timeout*/0,
+					 /*getcount_only*/0); 
+			done_ccb->ccb_h.status &= ~CAM_DEV_QFRZN;
+		}
 		desc->data_resid -= desc->data_increment;
 		xpt_release_ccb(done_ccb);
 		if (softc->state != TARGBH_STATE_TEARDOWN) {
@@ -696,11 +733,23 @@
 	}
 	case XPT_IMMED_NOTIFY:
 	{
+		int frozen;
+
+		frozen = (done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0;
 		if (softc->state == TARGBH_STATE_TEARDOWN
 		 || done_ccb->ccb_h.status == CAM_REQ_ABORTED) {
 			printf("Freed an immediate notify\n");
 			free(done_ccb, M_DEVBUF);
+		} else {
+			/* Requeue for another immediate event */
+			xpt_action(done_ccb);
 		}
+		if (frozen != 0)
+			cam_release_devq(periph->path,
+					 /*relsim_flags*/0,
+					 /*opening reduction*/0,
+					 /*timeout*/0,
+					 /*getcount_only*/0);
 		break;
 	}
 	default:
Index: scsi_target.c
===================================================================
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_target.c,v
retrieving revision 1.40
diff -u -r1.40 scsi_target.c
--- scsi_target.c	2001/05/08 08:30:48	1.40
+++ scsi_target.c	2001/07/04 05:27:19
@@ -1,7 +1,7 @@
 /*
  * Implementation of a simple Target Mode SCSI Proccessor Target driver for CAM.
  *
- * Copyright (c) 1998, 1999 Justin T. Gibbs.
+ * Copyright (c) 1998, 1999, 2001 Justin T. Gibbs.
  * All rights reserved.
  *
  * Redistribution and use in source and binary forms, with or without
@@ -93,6 +93,11 @@
 /* We stick a pointer to the originating accept TIO in each continue I/O CCB */
 #define ccb_atio	ppriv_ptr1
 
+/*
+ * When we're constructing a unit, we point to passed in user inquiry data here.
+ */
+#define ccb_inq		ppriv_ptr1
+
 struct targ_softc {
 	/* CTIOs pending on the controller */
 	struct		ccb_queue pending_queue;
@@ -154,7 +159,9 @@
 	struct	  bio *bp;	/* Buffer for this transfer */
 	u_int	  max_size;	/* Size of backing_store */
 	u_int32_t timeout;	
-	u_int8_t  status;	/* Status to return to initiator */
+	u_int32_t
+		user_atio	: 1, /* user ATIO (will define last CTIO) */
+		status		: 8; /* Status to return to initiator */
 };
 
 static	d_open_t	targopen;
@@ -187,8 +194,8 @@
 static periph_init_t	targinit;
 static void		targasync(void *callback_arg, u_int32_t code,
 				struct cam_path *path, void *arg);
-static int		targallocinstance(struct ioc_alloc_unit *alloc_unit);
-static int		targfreeinstance(struct ioc_alloc_unit *alloc_unit);
+static int		targallocinstance(void *, u_long);
+static int		targfreeinstance(struct ioc_alloc_unit *);
 static cam_status	targenlun(struct cam_periph *periph);
 static cam_status	targdislun(struct cam_periph *periph);
 static periph_ctor_t	targctor;
@@ -472,8 +479,8 @@
 		softc->istate[i].pending_ua = UA_POWER_ON;
 	
 	/*
-	 * Allocate an initial inquiry data buffer.  We might allow the
-	 * user to override this later via an ioctl.
+	 * Allocate an inquiry data buffer. 
+	 * We let the user to override this if desired.
 	 */
 	softc->inq_data_len = sizeof(*softc->inq_data);
 	softc->inq_data = malloc(softc->inq_data_len, M_DEVBUF, M_NOWAIT);
@@ -482,19 +489,35 @@
 		targdtor(periph);
 		return (CAM_RESRC_UNAVAIL);
 	}
-	bzero(softc->inq_data, softc->inq_data_len);
-	softc->inq_data->device = T_PROCESSOR | (SID_QUAL_LU_CONNECTED << 5);
-	softc->inq_data->version = 2;
-	softc->inq_data->response_format = 2; /* SCSI2 Inquiry Format */
-	softc->inq_data->flags =
-	    cpi->hba_inquiry & (PI_SDTR_ABLE|PI_WIDE_16|PI_WIDE_32|PI_TAG_ABLE);
-	softc->inq_data->additional_length = softc->inq_data_len - 4;
-	strncpy(softc->inq_data->vendor, "FreeBSD ", SID_VENDOR_SIZE);
-	strncpy(softc->inq_data->product, "TM-PT           ", SID_PRODUCT_SIZE);
-	strncpy(softc->inq_data->revision, "0.0 ", SID_REVISION_SIZE);
+	if (cpi->ccb_h.ccb_inq) {
+		bcopy(cpi->ccb_h.ccb_inq, softc->inq_data, softc->inq_data_len);
+	} else {
+		bzero(softc->inq_data, softc->inq_data_len);
+		softc->inq_data->device =
+		    T_PROCESSOR | (SID_QUAL_LU_CONNECTED << 5);
+		softc->inq_data->version = 2;
+		softc->inq_data->response_format = 2; /* SCSI2 Inquiry Format */
+		softc->inq_data->additional_length = softc->inq_data_len - 4;
+		strncpy(softc->inq_data->vendor, "FreeBSD ", SID_VENDOR_SIZE);
+		strncpy(softc->inq_data->product,
+		    "TM-PT           ", SID_PRODUCT_SIZE);
+		strncpy(softc->inq_data->revision, "0.0 ", SID_REVISION_SIZE);
+	}
+
+	/*
+	 * Preserve the SIM's capabilities here. Don't let user applications
+	 * do something dumb.
+	 */
+	if (softc->inq_data->version >= 2) {
+		softc->inq_data->flags &=
+		    ~(PI_SDTR_ABLE|PI_WIDE_16|PI_WIDE_32|PI_TAG_ABLE);
+		softc->inq_data->flags |= (cpi->hba_inquiry & 
+		    (PI_SDTR_ABLE|PI_WIDE_16|PI_WIDE_32|PI_TAG_ABLE));
+	}
 	softc->targ_dev = make_dev(&targ_cdevsw, periph->unit_number, UID_ROOT,
 				   GID_OPERATOR, 0600, "%s%d",
 				   periph->periph_name, periph->unit_number);
+
 	softc->init_level++;
 	return (CAM_REQ_CMP);
 }
@@ -621,8 +644,10 @@
 }
 
 static int
-targallocinstance(struct ioc_alloc_unit *alloc_unit)
+targallocinstance(void *arg, u_long cmd)
 {
+	struct ioc_alloc_unit *alloc_unit = arg;
+	struct scsi_inquiry_data local;
 	struct ccb_pathinq cpi;
 	struct cam_path *path;
 	struct cam_periph *periph;
@@ -642,7 +667,6 @@
 
 	free_path_on_return++;
 
-
 	xpt_setup_ccb(&cpi.ccb_h, path, /*priority*/1);
 	cpi.ccb_h.func_code = XPT_PATH_INQ;
 	xpt_action((union ccb *)&cpi);
@@ -655,7 +679,8 @@
 
 	/* Can only alloc units on controllers that support target mode */
 	if ((cpi.target_sprt & PIT_PROCESSOR) == 0) {
-		printf("Controller does not support target mode%x\n", status);
+		printf("Controller does not support target mode - status %x\n",
+		       status);
 		status = CAM_PATH_INVALID;
 		goto fail;
 	}
@@ -666,6 +691,16 @@
 		goto fail;
 	}
 
+	if (cmd == TARGCTLIOALLOCUNIT) {
+		status = copyin(alloc_unit->inquiry_data, &local, sizeof local);
+		if (status)
+			goto fail;
+		cpi.ccb_h.ccb_inq = &local;
+	} else {
+		cpi.ccb_h.ccb_inq = NULL;
+	}
+	
+
 	/*
 	 * Allocate a peripheral instance for
 	 * this target instance.
@@ -783,10 +818,17 @@
 	error = 0;
 	if (TARG_IS_CONTROL_DEV(unit)) {
 		switch (cmd) {
+		case OTARGCTLIOALLOCUNIT:
 		case TARGCTLIOALLOCUNIT:
-			error = targallocinstance((struct ioc_alloc_unit*)addr);
+			error = targallocinstance(addr, cmd);
 			break;
+		case OTARGCTLIOFREEUNIT:
 		case TARGCTLIOFREEUNIT:
+			/*
+			 * Old_ioc_alloc_unit and ioc_alloc_unit are the
+			 * same with respect to what we need from the structure
+			 * for this function.
+			 */
 			error = targfreeinstance((struct ioc_alloc_unit*)addr);
 			break;
 		default:
@@ -888,9 +930,9 @@
 		}
 		break;
 	}
-#ifdef	CAMDEBUG
 	case TARGIODEBUG:
 	{
+#ifdef	CAMDEBUG
 		union ccb ccb;
 		bzero (&ccb, sizeof ccb);
 		if (xpt_create_path(&ccb.ccb_h.path, periph,
@@ -918,9 +960,11 @@
 			error = 0;
 		}
 		xpt_free_path(ccb.ccb_h.path);
+#else
+		error = 0;
+#endif
 		break;
 	}
-#endif
 	default:
 		error = ENOTTY;
 		break;
@@ -1337,22 +1381,24 @@
 		desc = (struct targ_cmd_desc *)atio->ccb_h.ccb_descr;
 
 		/* Is this a tagged request? */
-		flags = atio->ccb_h.flags &
-		    (CAM_DIS_DISCONNECT|CAM_TAG_ACTION_VALID|CAM_DIR_MASK);
+		flags = atio->ccb_h.flags & (CAM_DIS_DISCONNECT |
+		    CAM_TAG_ACTION_VALID | CAM_DIR_MASK | CAM_SEND_STATUS);
 
 		/*
 		 * If we are done with the transaction, tell the
 		 * controller to send status and perform a CMD_CMPLT.
 		 */
-		if (desc->data_resid == desc->data_increment)
+		if (desc->user_atio == 0 &&
+		    desc->data_resid == desc->data_increment) {
 			flags |= CAM_SEND_STATUS;
+		}
 
 		csio = &start_ccb->csio;
 		cam_fill_ctio(csio,
 			      /*retries*/2,
 			      targdone,
 			      flags,
-			      (flags & CAM_TAG_ACTION_VALID)?
+			      (flags & CAM_TAG_ACTION_VALID) ?
 				MSG_SIMPLE_Q_TAG : 0,
 			      atio->tag_id,
 			      atio->init_id,
@@ -1390,13 +1436,13 @@
 		 * to this ATIO (for instance disconnection was disallowed),
 		 * then release it now that our response has been queued.
 		 */
-		if ((atio->ccb_h.flags & CAM_DEV_QFRZN) != 0) {
+		if ((atio->ccb_h.status & CAM_DEV_QFRZN) != 0) {
 			cam_release_devq(periph->path,
 					 /*relsim_flags*/0,
 					 /*reduction*/0,
 					 /*timeout*/0,
 					 /*getcount_only*/0); 
-			atio->ccb_h.flags &= ~CAM_DEV_QFRZN;
+			atio->ccb_h.status &= ~CAM_DEV_QFRZN;
 		}
 		s = splbio();
 		ccbh = TAILQ_FIRST(&softc->work_queue);
@@ -1441,6 +1487,9 @@
 			free(done_ccb, M_DEVBUF);
 			return;
 		}
+		descr->data_resid = 0;
+		descr->data_increment = 0;
+		descr->user_atio = 0;
 
 #ifdef	CAMDEBUG
 		{
@@ -1450,8 +1499,8 @@
 				snprintf(dcb, sizeof dcb,
 				    "%s %02x", dcb, cdb[i] & 0xff);
 			}
-			CAM_DEBUG(periph->path,
-			    CAM_DEBUG_PERIPH, ("cdb:%s\n", dcb));
+			CAM_DEBUG(periph->path, CAM_DEBUG_PERIPH,
+			    ("flags %x cdb:%s\n", atio->ccb_h.flags, dcb));
 		}
 #endif
 		if (atio->sense_len != 0) {
@@ -1464,8 +1513,6 @@
 			 */
 			atio->ccb_h.flags &= ~CAM_DIR_MASK;
 			atio->ccb_h.flags |= CAM_DIR_NONE;
-			descr->data_resid = 0;
-			descr->data_increment = 0;
 			descr->timeout = 5 * 1000;
 			descr->status = SCSI_STATUS_CHECK_COND;
 			copy_sense(softc, istate, (u_int8_t *)&atio->sense_data,
@@ -1483,8 +1530,6 @@
 			/* Direction is always relative to the initator */
 			atio->ccb_h.flags &= ~CAM_DIR_MASK;
 			atio->ccb_h.flags |= CAM_DIR_NONE;
-			descr->data_resid = 0;
-			descr->data_increment = 0;
 			descr->timeout = 5 * 1000;
 			descr->status = SCSI_STATUS_CHECK_COND;
 			fill_sense(softc, atio->init_id,
@@ -1538,8 +1583,6 @@
 				 || inq->page_code != 0) {
 					atio->ccb_h.flags &= ~CAM_DIR_MASK;
 					atio->ccb_h.flags |= CAM_DIR_NONE;
-					descr->data_resid = 0;
-					descr->data_increment = 0;
 					descr->timeout = 5 * 1000;
 					descr->status = SCSI_STATUS_CHECK_COND;
 					fill_sense(softc, atio->init_id,
@@ -1591,8 +1634,6 @@
 			case TEST_UNIT_READY:
 				atio->ccb_h.flags &= ~CAM_DIR_MASK;
 				atio->ccb_h.flags |= CAM_DIR_NONE;
-				descr->data_resid = 0;
-				descr->data_increment = 0;
 				descr->timeout = 5 * 1000;
 				descr->status = SCSI_STATUS_OK;
 				break;
@@ -1633,7 +1674,7 @@
 			}
 			case RECEIVE:
 			case SEND:
-			{
+			if (SID_TYPE(softc->inq_data) == T_PROCESSOR) {
 				struct scsi_send_receive *sr;
 
 				sr = (struct scsi_send_receive *)cdb;
@@ -1679,6 +1720,9 @@
 				 * counterpart and  transition to the exception
 				 * state.
 				 */
+				descr->data_resid = 0;
+				descr->data_increment = 0;
+				descr->user_atio = 1;
 				TAILQ_INSERT_TAIL(&softc->unknown_atio_queue,
 						  &atio->ccb_h,
 						  periph_links.tqe);
@@ -1707,7 +1751,7 @@
 		struct ccb_accept_tio *atio;
 		struct targ_cmd_desc *desc;
 		struct bio *bp;
-		int    error;
+		int    error, lastctio;
 
 		CAM_DEBUG(periph->path, CAM_DEBUG_PERIPH,
 			  ("Received completed CTIO\n"));
@@ -1725,7 +1769,9 @@
 				break;
 			/*
 			 * Right now we don't need to do anything
-			 * prior to unfreezing the queue...
+			 * prior to unfreezing the queue.  This may
+			 * change if certain errors are reported while
+			 * we are in a connected state.
 			 */
 			if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0) {
 				printf("Releasing Queue\n");
@@ -1734,6 +1780,7 @@
 						 /*reduction*/0,
 						 /*timeout*/0,
 						 /*getcount_only*/0); 
+				done_ccb->ccb_h.status &= ~CAM_DEV_QFRZN;
 			}
 		} else
 			error = 0;
@@ -1753,8 +1800,22 @@
 			done_ccb->ccb_h.status &= ~CAM_SENT_SENSE;
 			CAM_DEBUG(periph->path, CAM_DEBUG_PERIPH,
 				  ("Sent Sense\n"));
+			done_ccb->ccb_h.flags &= ~CAM_SEND_SENSE;
+		}
+
+		if (done_ccb->ccb_h.status & CAM_AUTOSNS_VALID) {
+			struct initiator_state *istate;
+
+			istate = &softc->istate[csio->init_id];
+			copy_sense(softc, istate, (u_int8_t *)&csio->sense_data,
+				   csio->sense_len);
+			set_ca_condition(periph, csio->init_id, CA_CMD_SENSE);
+			done_ccb->ccb_h.status &= ~CAM_AUTOSNS_VALID;
 		}
-		done_ccb->ccb_h.flags &= ~CAM_SEND_SENSE;
+		/*
+		 * Was this the last CTIO?
+		 */
+		lastctio = done_ccb->ccb_h.status & CAM_SEND_STATUS;
 
 		desc->data_increment -= csio->resid;
 		desc->data_resid -= desc->data_increment;
@@ -1785,10 +1846,11 @@
 			}
 		}
 
+		if ((done_ccb->ccb_h.status & CAM_DEV_QFRZN) != 0)
+			atio->ccb_h.status |= CAM_DEV_QFRZN;
 		xpt_release_ccb(done_ccb);
 		if (softc->state != TARG_STATE_TEARDOWN) {
-
-			if (desc->data_resid == 0) {
+			if (lastctio) {
 				/*
 				 * Send the original accept TIO back to the
 				 * controller to handle more work.
@@ -1800,25 +1862,25 @@
 				break;
 			}
 
-			/* Queue us up for another buffer */
-			if (atio->cdb_io.cdb_bytes[0] == SEND) {
-				if (desc->bp != NULL)
-					TAILQ_INSERT_HEAD(
-						&softc->snd_bio_queue.queue,
-						bp, bio_queue);
+			if (SID_TYPE(softc->inq_data) == T_PROCESSOR) {
+				/* Queue us up for another buffer */
+				if (atio->cdb_io.cdb_bytes[0] == SEND) {
+					if (desc->bp != NULL)
+				TAILQ_INSERT_HEAD(&softc->snd_bio_queue.queue,
+						  bp, bio_queue);
 				TAILQ_INSERT_HEAD(&softc->snd_ccb_queue,
 						  &atio->ccb_h,
 						  periph_links.tqe);
-			} else {
-				if (desc->bp != NULL)
-					TAILQ_INSERT_HEAD(
-						&softc->rcv_bio_queue.queue,
-						bp, bio_queue);
+				} else {
+					if (desc->bp != NULL)
+				TAILQ_INSERT_HEAD(&softc->rcv_bio_queue.queue,
+						  bp, bio_queue);
 				TAILQ_INSERT_HEAD(&softc->rcv_ccb_queue,
 						  &atio->ccb_h,
 						  periph_links.tqe);
+				}
+				desc->bp = NULL;
 			}
-			desc->bp = NULL;
 			targrunqueue(periph, softc);
 		} else {
 			if (desc->bp != NULL) {
Index: scsi_targetio.h
===================================================================
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_targetio.h,v
retrieving revision 1.8
diff -u -r1.8 scsi_targetio.h
--- scsi_targetio.h	2000/07/14 19:42:47	1.8
+++ scsi_targetio.h	2001/07/04 05:27:20
@@ -106,11 +106,19 @@
 #define TARGIOCGETISTATE	_IOWR('C', 6, struct ioc_initiator_state)
 #define TARGIOCSETISTATE	_IOW('C', 5, struct ioc_initiator_state)
 
+struct old_ioc_alloc_unit {
+	path_id_t	path_id;
+	target_id_t	target_id;
+	lun_id_t	lun_id;
+	u_int		unit;
+};
+
 struct ioc_alloc_unit {
 	path_id_t	path_id;
 	target_id_t	target_id;
 	lun_id_t	lun_id;
 	u_int		unit;
+	struct scsi_inquiry_data *inquiry_data;
 };
 
 /*
@@ -120,6 +128,8 @@
  * newly created instance.  For de-allocation, all fields must match
  * an instance in the inactive (i.e. closed) state.
  */
+#define OTARGCTLIOALLOCUNIT	_IOWR('C', 7, struct old_ioc_alloc_unit)
+#define OTARGCTLIOFREEUNIT	_IOW('C', 8, struct old_ioc_alloc_unit)
 #define TARGCTLIOALLOCUNIT	_IOWR('C', 7, struct ioc_alloc_unit)
 #define TARGCTLIOFREEUNIT	_IOW('C', 8, struct ioc_alloc_unit)
 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4  0:13:13 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP
	id DFFF137B406; Wed,  4 Jul 2001 00:13:05 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f647D5S09340;
	Wed, 4 Jul 2001 00:13:05 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 00:13:04 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: scsi@freebsd.org
Cc: audit@freebsd.org
Subject: tunable retry count for DA
Message-ID: <Pine.BSF.4.21.0107040011230.8572-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


This change implements a sysctl for setting the retry count for normal
I/O for scsi_da- this is useful if you're working with noisy Fibre
Channel Loops.

The principal node, cam, overlaps the same definition in scsi_cd. They
probably ought to be moved to someplace else.

Index: cam/scsi/scsi_da.c
===================================================================
RCS file: /home/ncvs/src/sys/cam/scsi/scsi_da.c,v
retrieving revision 1.73
diff -u -r1.73 scsi_da.c
--- cam/scsi/scsi_da.c	2001/07/04 05:22:42	1.73
+++ cam/scsi/scsi_da.c	2001/07/04 07:11:13
@@ -38,6 +38,7 @@
 #include <sys/systm.h>
 #include <sys/kernel.h>
 #include <sys/bio.h>
+#include <sys/sysctl.h>
 #endif /* _KERNEL */
 
 #include <sys/devicestat.h>
@@ -277,6 +278,18 @@
 #define DA_DEFAULT_TIMEOUT 60	/* Timeout in seconds */
 #endif
 
+#ifndef	DA_DEFAULT_RETRY
+#define	DA_DEFAULT_RETRY	4
+#endif
+
+static int da_retry_count = DA_DEFAULT_RETRY;
+
+SYSCTL_NODE(_kern, OID_AUTO, cam, CTLFLAG_RD, 0, "CAM Subsystem");
+SYSCTL_NODE(_kern_cam, OID_AUTO, da, CTLFLAG_RD, 0,
+            "CAM Direct Access Disk driver");
+SYSCTL_INT(_kern_cam_da, OID_AUTO, retry_count, CTLFLAG_RW,
+           &da_retry_count, 0, "Normal I/O retry count");
+
 /*
  * DA_ORDEREDTAG_INTERVAL determines how often, relative
  * to the default timeout, we check to see whether an ordered
@@ -1103,7 +1116,7 @@
 				tag_code = MSG_SIMPLE_Q_TAG;
 			}
 			scsi_read_write(&start_ccb->csio,
-					/*retries*/4, /* retry a few times */
+					/*retries*/da_retry_count,
 					dadone,
 					tag_code,
 					bp->bio_cmd == BIO_READ,


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4  2:11:34 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from ns5.pacific.net.au (ns5.pacific.net.au [203.143.252.30])
	by hub.freebsd.org (Postfix) with ESMTP id 6D98637B403
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 02:11:30 -0700 (PDT)
	(envelope-from mckay@thehub.com.au)
Received: from dungeon.home (ppp21.dyn248.pacific.net.au [203.143.248.21])
	by ns5.pacific.net.au (8.9.0/8.9.1) with ESMTP id TAA11687;
	Wed, 4 Jul 2001 19:11:09 +1000 (EST)
Received: from dungeon.home (localhost [127.0.0.1])
	by dungeon.home (8.11.3/8.11.1) with ESMTP id f649BQM14473;
	Wed, 4 Jul 2001 19:11:26 +1000 (EST)
	(envelope-from mckay)
Message-Id: <200107040911.f649BQM14473@dungeon.home>
To: freebsd-scsi@freebsd.org
Cc: schilling@fokus.gmd.de, ken@kdm.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs (one problem solved)
References: <200107021506.RAA20637@burner.fokus.gmd.de> <200107021528.f62FSKX13432@dungeon.home>
In-Reply-To: <200107021528.f62FSKX13432@dungeon.home>
    from Stephen McKay at "Tue, 03 Jul 2001 01:28:20 +1000"
Date: Wed, 04 Jul 2001 19:11:26 +1000
From: Stephen McKay <mckay@thehub.com.au>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Tuesday, 3rd July 2001, Stephen McKay wrote:

>>>I have a multisession Joliet CDROM that is
>>>completely unreadable on FreeBSD (mount reports cd9660: /dev/acd0c:
>>>Invalid argument).  It has one more track than it has sessions.  The
>>>extra track is between the others, and is 63 seconds long.  It reads
>>>perfectly on Win98.

>The same hardware running Win98 will read the CD that FreeBSD won't read.
>I have other multisession CDs made with the same method on the same
>system.  FreeBSD reads them all properly.  It is quite puzzling.

Tony Maher <tonym@angis.org.au> pointed out the -s flag to mount_cd9660.
With that, I was able to mount the CD and read all the files.  Here's how:

# cdcontrol -f acd0
Compact Disc Control utility, version 2.0
Type `?' for command list

cdcontrol> info
Starting track = 1, ending track = 3, TOC size = 34 bytes
track     start  duration   block  length   type
-------------------------------------------------
    1   0:02.00  10:59.64       0   49339   data
    2  10:59.64   1:02.60   49339    4560   data
    3  12:00.49  41:17.24   53899  185649   data
  170  53:15.73         -  239548       -      -

cdcontrol> quit
# mount_cd9660 -s 49339 /dev/acd0c /mnt
# df /mnt
Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
/dev/acd0c     478792   478792        0   100%    /mnt
#

In other words, the burner program, for whatever reason, split the
second session into two tracks.  The final track is not an ISO filesystem.
But the 2nd track is the directory for the whole disk.

Presumably Windoze steps backwards through the tracks until it can mount
successfully.  We should to the same.  It should be easy.

Stephen.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4  6:10: 1 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from relay1.mail.uk.psi.net (relay1.mail.uk.psi.net [154.32.105.6])
	by hub.freebsd.org (Postfix) with ESMTP id 55C0737B403
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 06:09:57 -0700 (PDT)
	(envelope-from dbhague@allstor-sw.co.uk)
Received: from mail.plasmon.co.uk ([193.115.5.217])
	by relay1.mail.uk.psi.net with esmtp (Exim 2.12 #2)
	id 15HmPf-0002Zo-00
	for freebsd-scsi@freebsd.org; Wed, 4 Jul 2001 14:09:51 +0100
From: dbhague@allstor-sw.co.uk
Subject: LTO Tape support
To: freebsd-scsi@freebsd.org
Date: Wed, 4 Jul 2001 14:08:07 +0100
Message-ID: <OF9E54FC0A.0567C894-ON80256A7F.0045E40B@plasmon.co.uk>
X-MIMETrack: Serialize by Router on Melbourn01/SVR/Plasmon(Release 5.0.6a |January 17, 2001) at
 07/04/2001 02:08:12 PM
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

Does anyone have, or is working on, a driver for the new LTO tape drives ?

I believe IBM have written a Red Hat Linux driver.
Information is available at
http://www.storage.ibm.com/techsup/tapetech/lto_ftp.htm

We need one so if one is not available we will write one, in which case any
helpful suggestions
would be welcome.

Regards Dave


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4  7:22:28 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134])
	by hub.freebsd.org (Postfix) with ESMTP id C2A8437B408
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 07:22:25 -0700 (PDT)
	(envelope-from kwc@world.std.com)
Received: from world.std.com (world-f.std.com [199.172.62.5])
	by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id KAA23924423
	for <freebsd-scsi@freebsd.org>; Wed, 4 Jul 2001 10:22:24 -0400 (EDT)
Received: (from kwc@localhost)
	by world.std.com (8.9.3/8.9.3) id KAA21945;
	Wed, 4 Jul 2001 10:22:23 -0400 (EDT)
Date: Wed, 4 Jul 2001 10:22:23 -0400 (EDT)
From: Kenneth W Cochran <kwc@world.std.com>
Message-Id: <200107041422.KAA21945@world.std.com>
To: freebsd-scsi@freebsd.org
Subject: USB/umass in addition to "other" SCSI
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

Hello -scsi:

How do I "connect" a USB "disk" when I already have a SCSI
HBA & other peripherals installed & operating?  And what will
(should :) be its device-name (in /dev)?

USB devices in this case can be a ZIP-250 USB and/or a USB
digital camera (which mounts just fine in Linux 2.4.x & is
seen as a MS-DOS filesystem).

Umass, scbus, da & pass are configured into the running kernel.
OS is RELENG_4 as of 1 July.

"Camcontrol rescan 0" doesn't show it(?)  But I'm thinking
this will be a different bus(?) & "camcontrol rescan 1" gives
me an ioctl() error.

I'm guessing that I should probably "wire down" my devices
(or at least the USB one?) in my kernel config, but before I
do that I could use some input from Someone Who Know More
About This Than I(tm). :)  That, & I'm not sure about the
kernel-config syntax for this...

I've searched the Handbook & various FreeBSD mailing-list archives
& haven't yet found anything; any FAQ/doc/howto pointers?
(Or a better place to ask?  -SCSI seems the closest thing I can find.)

Please cc replies to me, in case I don't see it in the list.

Many thanks,

-kc

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4  7:32:55 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from salmon.maths.tcd.ie (salmon.maths.tcd.ie [134.226.81.11])
	by hub.freebsd.org (Postfix) with SMTP id 29A4B37B401
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 07:32:53 -0700 (PDT)
	(envelope-from dwmalone@maths.tcd.ie)
Received: from walton.maths.tcd.ie by salmon.maths.tcd.ie with SMTP
          id <aa17479@salmon>; 4 Jul 2001 15:32:52 +0100 (BST)
Date: Wed, 4 Jul 2001 15:32:52 +0100
From: David Malone <dwmalone@maths.tcd.ie>
To: dbhague@allstor-sw.co.uk
Cc: freebsd-scsi@freebsd.org
Subject: Re: LTO Tape support
Message-ID: <20010704153252.A87801@walton.maths.tcd.ie>
References: <OF9E54FC0A.0567C894-ON80256A7F.0045E40B@plasmon.co.uk>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2.5i
In-Reply-To: <OF9E54FC0A.0567C894-ON80256A7F.0045E40B@plasmon.co.uk>; from dbhague@allstor-sw.co.uk on Wed, Jul 04, 2001 at 02:08:07PM +0100
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Wed, Jul 04, 2001 at 02:08:07PM +0100, dbhague@allstor-sw.co.uk wrote:
> Does anyone have, or is working on, a driver for the new LTO tape drives ?
> 
> I believe IBM have written a Red Hat Linux driver.
> Information is available at
> http://www.storage.ibm.com/techsup/tapetech/lto_ftp.htm
> 
> We need one so if one is not available we will write one, in which case any
> helpful suggestions

From the looks of the web page, Linux treates the drive as a standard
SCSI tape drive, which means it should work under FreeBSD.

	David.

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 10:27:13 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id 03F3037B406
	for <freebsd-scsi@FreeBSD.ORG>; Wed,  4 Jul 2001 10:27:11 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f64HR1S12376;
	Wed, 4 Jul 2001 10:27:01 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 10:27:01 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: dbhague@allstor-sw.co.uk
Cc: freebsd-scsi@FreeBSD.ORG
Subject: Re: LTO Tape support
In-Reply-To: <OF9E54FC0A.0567C894-ON80256A7F.0045E40B@plasmon.co.uk>
Message-ID: <Pine.BSF.4.21.0107041026350.11969-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Since this is a SCSI tape drive, do you have a list where the current
sa(4) driver doesn't work?


On Wed, 4 Jul 2001 dbhague@allstor-sw.co.uk wrote:

> Does anyone have, or is working on, a driver for the new LTO tape drives ?
> 
> I believe IBM have written a Red Hat Linux driver.
> Information is available at
> http://www.storage.ibm.com/techsup/tapetech/lto_ftp.htm
> 
> We need one so if one is not available we will write one, in which case any
> helpful suggestions
> would be welcome.
> 
> Regards Dave
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 10:33:18 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
	by hub.freebsd.org (Postfix) with ESMTP id 6E01637B403
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 10:33:12 -0700 (PDT)
	(envelope-from arg@arg1.demon.co.uk)
Received: by arg1.demon.co.uk (Postfix, from userid 300)
	id 238089B03; Wed,  4 Jul 2001 18:33:08 +0100 (BST)
Received: from localhost (localhost [127.0.0.1])
	by arg1.demon.co.uk (Postfix) with ESMTP
	id 14A815D1D; Wed,  4 Jul 2001 18:33:08 +0100 (BST)
Date: Wed, 4 Jul 2001 18:33:07 +0100 (BST)
From: Andrew Gordon <arg@arg1.demon.co.uk>
X-X-Sender:  <arg@server.arg.sj.co.uk>
To: Kenneth W Cochran <kwc@world.std.com>
Cc: <freebsd-scsi@freebsd.org>
Subject: Re: USB/umass in addition to "other" SCSI
In-Reply-To: <200107041422.KAA21945@world.std.com>
Message-ID: <20010704181957.G65863-100000@server.arg.sj.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Wed, 4 Jul 2001, Kenneth W Cochran wrote:

> Hello -scsi:
>
> How do I "connect" a USB "disk" when I already have a SCSI
> HBA & other peripherals installed & operating?

It should appear of its own accord when usbd sees it.  However, this
doesn't appear to work properly at present.

>  And what will
> (should :) be its device-name (in /dev)?

/dev/daX*  where X is the next available number

> USB devices in this case can be a ZIP-250 USB and/or a USB
> digital camera (which mounts just fine in Linux 2.4.x & is
> seen as a MS-DOS filesystem).
>
> Umass, scbus, da & pass are configured into the running kernel.
> OS is RELENG_4 as of 1 July.
>
> "Camcontrol rescan 0" doesn't show it(?)  But I'm thinking
> this will be a different bus(?)

Yes.

> & "camcontrol rescan 1" gives
> me an ioctl() error.

I haven't found a method that works other than to have the device present
at boot time.

> I'm guessing that I should probably "wire down" my devices
> (or at least the USB one?) in my kernel config, but before I

More important to wire down the hard drives - having your root filesystem
mounted from the camera is more traumatic than having the camera pop up at
an unexpected id.

> do that I could use some input from Someone Who Know More
> About This Than I(tm). :)  That, & I'm not sure about the
> kernel-config syntax for this...

I am far from an expert in this area, but I am successfully using a USB
smartmedia reader on a system that also has SCSI discs.

I have the disc wired down:

# SCSI Controllers
device      sym0        # NCR/Symbios Logic (newer chipsets)
# SCSI peripherals
device      scbus       # SCSI bus (required)
device      da      # Direct Access (disks)
device      sa      # Sequential Access (tape etc)
device      cd      # CD
device      pass        # Passthrough device (direct SCSI access)
# Wire down the boot disc to avoid being usurped by USB peripherals!
device  scbus0 at sym0
device  da0 at scbus0 target 0 unit 0


If your camera has the usual formatting for smartmedia or compact-flash,
it will have an fdisk table and a DOS filesystem in the first slice, so
you want something like:

mount -t msdos /dev/da1s1 /mnt

to mount it when the drive has popped up at da1.






To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 10:34:32 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id 80A6837B401
	for <scsi@freebsd.org>; Wed,  4 Jul 2001 10:34:29 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f64HYQS12411;
	Wed, 4 Jul 2001 10:34:26 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 10:34:26 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Norman Czarczinski <Norman.Czarczinski@t-online.de>
Cc: scsi@freebsd.org
Subject: Re: Trouble with SCSI Streamer
In-Reply-To: <01070418043800.00419@amd.local>
Message-ID: <Pine.BSF.4.21.0107041033030.11969-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Well, that's one theory shot down. Can you explicitly try changing the
blocksize to 1k, test, back to 512 and test again? 

On Wed, 4 Jul 2001, Norman Czarczinski wrote:

> On Wednesday 04 July 2001 07:26, you wrote:
> > Say- could you do a 'mt status' on the drive with a tape inserted and
> > send that to me?
> 
> mt status with a 6525 tape inserted:
> Mode      Density              Blocksize      bpi      Compression
> Current:  0x11:QIC-320         512 bytes      16000    unsupported
> ---------available modes---------
> 0:        0x11:QIC-320         512 bytes      16000    unsupported
> 1:        0x11:QIC-320         512 bytes      16000    unsupported
> 2:        0x11:QIC-320         512 bytes      16000    unsupported
> 3:        0x11:QIC-320         512 bytes      16000    unsupported
> ---------------------------------
> Current Driver State: at rest.
> ---------------------------------
> File Number: 0	Record Number: 0	Residual Count 28
> 
> Ciao
>   Norman
> 



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 10:59:27 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id AF5B237B409
	for <scsi@freebsd.org>; Wed,  4 Jul 2001 10:59:24 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f64HxMS12578;
	Wed, 4 Jul 2001 10:59:22 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 10:59:22 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Ben <xbhe@yahoo.com>
Cc: scsi@freebsd.org
Subject: target mode usage quick primer
In-Reply-To: <200107041708.KAA31613@geocrawler.com>
Message-ID: <Pine.BSF.4.21.0107041055040.11969-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


On Wed, 4 Jul 2001, Ben wrote:

> This message was sent from Geocrawler.com by "Ben" <xbhe@yahoo.com>
> 
> 
> Dear Matthew,
>      I have connected two PCs running FreeBSD 4.3 
> each with an adaptec 39160 adapter.These two 
> apaters are connected through a SCSI cable. One 
> of the SCSI ID is set to 6,the other is set to 7. 
> I am trying to make one machine running under 
> target mode. What I did is to change 
> AHC_TMODE_ENABLE to 1 and rebuild the 
> kernel.After I reboot these two systems,nothing 
> is new. Could you point out how I shold test the 
> target mode?Thank you very much.
> Ben

You need the drivers

device scsi_target
device scsi_targ_bh

in your kernel as well as enabling target mode support in either the
Adaptec driver or the the QLogic driver. Note that while the QLogic
driver supports simultaneous initiator/target mode operation, the last
I checked, the Adaptec doesn't, so for your h/w, you have to have the
initiator side *not* have AHC_TMODE_ENABLE on. You might probably want
to put

device pt

in the initiator side.

Once you boot the target mode side, you'll eee wildcard enabling
via the targbh driver so that commands to non-existent luns have
somebody to actually respond.

Then go off and compile /usr/share/examples/scsi_target/scsi_target.c
and enable a lun for real.

Then boot the initiator side or camcontrol rescan the initiator side.

-matt



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 12:30:12 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from sgi04-e.std.com (sgi04-e.std.com [199.172.62.134])
	by hub.freebsd.org (Postfix) with ESMTP id 264D437B403
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 12:30:03 -0700 (PDT)
	(envelope-from kwc@world.std.com)
Received: from world.std.com (world-f.std.com [199.172.62.5])
	by sgi04-e.std.com (8.9.3/8.9.3) with ESMTP id PAA24661872;
	Wed, 4 Jul 2001 15:29:40 -0400 (EDT)
Received: (from kwc@localhost)
	by world.std.com (8.9.3/8.9.3) id PAA03557;
	Wed, 4 Jul 2001 15:29:39 -0400 (EDT)
Date: Wed, 4 Jul 2001 15:29:39 -0400 (EDT)
From: Kenneth W Cochran <kwc@world.std.com>
Message-Id: <200107041929.PAA03557@world.std.com>
To: Andrew Gordon <arg@arg1.demon.co.uk>
Subject: Re: USB/umass in addition to "other" SCSI
Cc: freebsd-scsi@freebsd.org
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>Date: Wed, 4 Jul 2001 18:33:07 +0100 (BST)
>From: Andrew Gordon <arg@arg1.demon.co.uk>
>To: Kenneth W Cochran <kwc@world.std.com>
>Cc: <freebsd-scsi@freebsd.org>
>Subject: Re: USB/umass in addition to "other" SCSI
>
>On Wed, 4 Jul 2001, Kenneth W Cochran wrote:
>> Hello -scsi:
>> How do I "connect" a USB "disk" when I already have a SCSI
>> HBA & other peripherals installed & operating?
>
>It should appear of its own accord when usbd sees it.

Ah, so usbd is what "makes the connection?"  (It would seem
so, but I can't find this documented just yet...)

>However, this doesn't appear to work properly at present.

Worked here...

>>  And what will (should :) be its device-name (in /dev)?
>
>/dev/daX*  where X is the next available number

Confirmed...

>> USB devices in this case can be a ZIP-250 USB and/or a USB
>> digital camera (which mounts just fine in Linux 2.4.x & is
>> seen as a MS-DOS filesystem).
>>
>> Umass, scbus, da & pass are configured into the running kernel.
>> OS is RELENG_4 as of 1 July.
>>
>> "Camcontrol rescan 0" doesn't show it(?)  But I'm thinking
>> this will be a different bus(?)
>
>Yes.

Ummm-hmmm - usbd "connected" umass to da*.

>> & "camcontrol rescan 1" gives me an ioctl() error.
>
>I haven't found a method that works other than to have the
>device present at boot time.

You don't mention your OS "patchlevel."  Maybe some
maintenance has fixed your problem?  Zip-250 USB seems
working ok now...

>> I'm guessing that I should probably "wire down" my devices
>> (or at least the USB one?) in my kernel config, but before I
>
>More important to wire down the hard drives - having your
>root filesystem mounted from the camera is more traumatic
>than having the camera pop up at an unexpected id.

Sounds sensible; other than that I guess you could just
make sure your usb devices are disconnected at boot...

>> do that I could use some input from Someone Who Know More
>> About This Than I(tm). :)  That, & I'm not sure about the
>> kernel-config syntax for this...
>
>I am far from an expert in this area, but I am successfully
>using a USB smartmedia reader on a system that also has
>SCSI discs.
>
>I have the disc wired down:
>
># SCSI Controllers
>device      sym0        # NCR/Symbios Logic (newer chipsets)
># SCSI peripherals
>device      scbus       # SCSI bus (required)
>device      da      # Direct Access (disks)
>device      sa      # Sequential Access (tape etc)
>device      cd      # CD
>device      pass        # Passthrough device (direct SCSI access)
># Wire down the boot disc to avoid being usurped by USB peripherals!
>device  scbus0 at sym0
>device  da0 at scbus0 target 0 unit 0
>
>If your camera has the usual formatting for smartmedia or
>compact-flash, it will have an fdisk table and a DOS
>filesystem in the first slice, so you want something like:
>
>mount -t msdos /dev/da1s1 /mnt
>
>to mount it when the drive has popped up at da1.

Oops!  This Does Not Work Here. :-/  Camera (Olympus) has
SmartMedia card; usbd does properly sense camera attachment
& make/model, but if I try to mount it, the OS reboots(!)
I tried using fdisk to look at the camera's "filesystem"
but got an "invalid sector size" & then "synchronize cache
failed" in syslog.  Here's the relevant syslog:

Jul  4 13:48:01 <kern.crit> myname /kernel: da3: invalid sector size 3273166177
Jul  4 13:48:01 <kern.crit> myname /kernel: (da3:umass-sim0:0:0:0): Synchronize
cache failed, status == 0x10, scsi status == 0x0

Restating, if I try to mount that da3 device (the USB
camera with SmartMedia) I get what appears to be a lockup &
the system reboots. :(

Ideas?  (Maybe some other list I should ask?)

-kc

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 12:48:15 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id A152837B403
	for <scsi@freebsd.org>; Wed,  4 Jul 2001 12:48:08 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f64Jm5S13691;
	Wed, 4 Jul 2001 12:48:05 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 12:48:05 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Norman Czarczinski <Norman.Czarczinski@t-online.de>
Cc: scsi@freebsd.org
Subject: Re: Trouble with SCSI Streamer
In-Reply-To: <01070421461600.00594@amd.local>
Message-ID: <Pine.BSF.4.21.0107041247130.11969-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Okay- sounds like a bug in sa(4) then- and wierdness in the drive. It
shouldn't allow you to set it to 512 bytes if that doesn't work.

On Wed, 4 Jul 2001, Norman Czarczinski wrote:

> On Wednesday 04 July 2001 19:34, you wrote:
> > Well, that's one theory shot down. Can you explicitly try changing the
> > blocksize to 1k, test, back to 512 and test again?
> 
> That was it. With 1k it works. After switching back to 512 the problem came 
> back.
> 
> Bye
>   Norman
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 22:15:15 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP id EB31037B401
	for <scsi@freebsd.org>; Wed,  4 Jul 2001 22:15:11 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f655F6S26484;
	Wed, 4 Jul 2001 22:15:06 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Wed, 4 Jul 2001 22:15:04 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Xubin He <xbhe@yahoo.com>
Cc: scsi@freebsd.org
Subject: Re: target mode usage quick primer
In-Reply-To: <20010705034040.23800.qmail@web13007.mail.yahoo.com>
Message-ID: <Pine.BSF.4.21.0107042214410.26426-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


Go chdir to /dev and do the appropriate MAKEDEV magic?


On Wed, 4 Jul 2001, Xubin He wrote:

> Dear Matthew,
> Thank you very much for your detail information.It is
> really helpful. Now when I boot the target side
> machine,I can see the message
> "(targbh0:ahc0:0:-1:-1):Lun now enabled for target
> mode", which means that the system has already been
> set to target mode.But when I tried to run
> ./scsi_target -p 0 -t 0 -l 3 to test the target mode,
> I got an error message "/dev/targ.ctl:no such file or
> directory."Do you have any idea about this error?Sorry
> for bothering you again. Have a great holiday.
> ---Ben
> --- Matthew Jacob <mjacob@feral.com> wrote:
> > 
> > On Wed, 4 Jul 2001, Ben wrote:
> > 
> > > This message was sent from Geocrawler.com by "Ben"
> > <xbhe@yahoo.com>
> > > 
> > > 
> > > Dear Matthew,
> > >      I have connected two PCs running FreeBSD 4.3 
> > > each with an adaptec 39160 adapter.These two 
> > > apaters are connected through a SCSI cable. One 
> > > of the SCSI ID is set to 6,the other is set to 7. 
> > > I am trying to make one machine running under 
> > > target mode. What I did is to change 
> > > AHC_TMODE_ENABLE to 1 and rebuild the 
> > > kernel.After I reboot these two systems,nothing 
> > > is new. Could you point out how I shold test the 
> > > target mode?Thank you very much.
> > > Ben
> > 
> > You need the drivers
> > 
> > device scsi_target
> > device scsi_targ_bh
> > 
> > in your kernel as well as enabling target mode
> > support in either the
> > Adaptec driver or the the QLogic driver. Note that
> > while the QLogic
> > driver supports simultaneous initiator/target mode
> > operation, the last
> > I checked, the Adaptec doesn't, so for your h/w, you
> > have to have the
> > initiator side *not* have AHC_TMODE_ENABLE on. You
> > might probably want
> > to put
> > 
> > device pt
> > 
> > in the initiator side.
> > 
> > Once you boot the target mode side, you'll eee
> > wildcard enabling
> > via the targbh driver so that commands to
> > non-existent luns have
> > somebody to actually respond.
> > 
> > Then go off and compile
> > /usr/share/examples/scsi_target/scsi_target.c
> > and enable a lun for real.
> > 
> > Then boot the initiator side or camcontrol rescan
> > the initiator side.
> > 
> > -matt
> > 
> > 
> 
> 
> __________________________________________________
> Do You Yahoo!?
> Get personalized email addresses from Yahoo! Mail
> http://personal.mail.yahoo.com/
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 23:47:14 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from elm.phenome.org (elm.phenome.org [194.153.169.3])
	by hub.freebsd.org (Postfix) with ESMTP id 4506637B405
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 23:47:12 -0700 (PDT)
	(envelope-from joshua@roughtrade.net)
Received: from localhost (joshua@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f656l2kw010888
        for <freebsd-scsi@freebsd.org>; Thu, 5 Jul 2001 07:47:02 +0100
Date: Thu, 5 Jul 2001 07:47:02 +0100 (BST)
From: Joshua Goodall <joshua@roughtrade.net>
X-X-Sender:  <joshua@elm.phenome.org>
To: <freebsd-scsi@freebsd.org>
Subject: shared bus
Message-ID: <Pine.LNX.4.33.0107050743440.31772-100000@elm.phenome.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


I'm sure this is at least an OAQ if not a FAQ, but still. The archives
didn't help me.

I want to experiment with shared-bus and shared-disk setups under -STABLE,
in particular shared-readonly and shared-raw fs's. Without getting into
FC-AL or dual-ported disks, what are my options for experimentation?
What's "known to work already"?

pointers appreciated!

joshua



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Wed Jul  4 23:52:40 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mass.dis.org (dhcp44-21.dis.org [216.240.44.21])
	by hub.freebsd.org (Postfix) with ESMTP id 0914537B403
	for <freebsd-scsi@freebsd.org>; Wed,  4 Jul 2001 23:52:38 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Received: from mass.dis.org (localhost [127.0.0.1])
	by mass.dis.org (8.11.4/8.11.3) with ESMTP id f6575ax01317;
	Thu, 5 Jul 2001 00:05:37 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200107050705.f6575ax01317@mass.dis.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Joshua Goodall <joshua@roughtrade.net>
Cc: freebsd-scsi@freebsd.org
Subject: Re: shared bus 
In-reply-to: Your message of "Thu, 05 Jul 2001 07:47:02 BST."
             <Pine.LNX.4.33.0107050743440.31772-100000@elm.phenome.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Jul 2001 00:05:36 -0700
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

> 
> I'm sure this is at least an OAQ if not a FAQ, but still. The archives
> didn't help me.
> 
> I want to experiment with shared-bus and shared-disk setups under -STABLE,
> in particular shared-readonly and shared-raw fs's. Without getting into
> FC-AL or dual-ported disks, what are my options for experimentation?
> What's "known to work already"?

The simplest setup is two SCSI controllers, one at each end of a SCSI 
bus, with the initiator ID set differently on each controller.

You may have some work to do wrt. reservations, etc. though, since I 
don't think we support this mode out-of-the-box.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5  0: 6: 5 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from elm.phenome.org (elm.phenome.org [194.153.169.3])
	by hub.freebsd.org (Postfix) with ESMTP
	id 85AEA37B403; Thu,  5 Jul 2001 00:06:03 -0700 (PDT)
	(envelope-from joshua@roughtrade.net)
Received: from localhost (joshua@localhost [127.0.0.1])
        by localhost (8.12.0.Beta7/8.12.0.Beta7/Debian 8.12.0.Beta7-1) with ESMTP id f65762kw011232;
	Thu, 5 Jul 2001 08:06:02 +0100
Date: Thu, 5 Jul 2001 08:06:02 +0100 (BST)
From: Joshua Goodall <joshua@roughtrade.net>
X-X-Sender:  <joshua@elm.phenome.org>
To: Mike Smith <msmith@freebsd.org>
Cc: <freebsd-scsi@freebsd.org>
Subject: Re: shared bus 
In-Reply-To: <200107050705.f6575ax01317@mass.dis.org>
Message-ID: <Pine.LNX.4.33.0107050757420.31772-100000@elm.phenome.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Thu, 5 Jul 2001, Mike Smith wrote:

> The simplest setup is two SCSI controllers, one at each end of a SCSI
> bus, with the initiator ID set differently on each controller.

so any scsi controller is known to work in this configuration? or has
no-one tried it? in particular, is there any card which won't let me
change the initiator ID?

i don't intend to burn cash on duff hardware :)

J


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5  0: 9: 3 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mass.dis.org (dhcp44-21.dis.org [216.240.44.21])
	by hub.freebsd.org (Postfix) with ESMTP id 6772337B406
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 00:09:00 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Received: from mass.dis.org (localhost [127.0.0.1])
	by mass.dis.org (8.11.4/8.11.3) with ESMTP id f657MHx01533;
	Thu, 5 Jul 2001 00:22:17 -0700 (PDT)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200107050722.f657MHx01533@mass.dis.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: Joshua Goodall <joshua@roughtrade.net>
Cc: freebsd-scsi@freebsd.org
Subject: Re: shared bus 
In-reply-to: Your message of "Thu, 05 Jul 2001 08:06:02 BST."
             <Pine.LNX.4.33.0107050757420.31772-100000@elm.phenome.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 05 Jul 2001 00:22:17 -0700
From: Mike Smith <msmith@freebsd.org>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

> On Thu, 5 Jul 2001, Mike Smith wrote:
> 
> > The simplest setup is two SCSI controllers, one at each end of a SCSI
> > bus, with the initiator ID set differently on each controller.
> 
> so any scsi controller is known to work in this configuration? or has
> no-one tried it? in particular, is there any card which won't let me
> change the initiator ID?

I don't think many people have tried it.  I'd expect you'd be OK with the 
higher-end Adaptec and LSI controllers.

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E



To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5  0:18:48 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from beppo.feral.com (beppo.feral.com [192.67.166.79])
	by hub.freebsd.org (Postfix) with ESMTP
	id 9A14A37B401; Thu,  5 Jul 2001 00:18:45 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Received: from beppo (mjacob@beppo [192.67.166.79])
	by beppo.feral.com (8.11.3/8.11.3) with ESMTP id f657IiS30831;
	Thu, 5 Jul 2001 00:18:44 -0700 (PDT)
	(envelope-from mjacob@feral.com)
Date: Thu, 5 Jul 2001 00:18:44 -0700 (PDT)
From: Matthew Jacob <mjacob@feral.com>
X-Sender: mjacob@beppo
Reply-To: mjacob@feral.com
To: Mike Smith <msmith@FreeBSD.ORG>
Cc: Joshua Goodall <joshua@roughtrade.net>, freebsd-scsi@FreeBSD.ORG
Subject: Re: shared bus 
In-Reply-To: <200107050722.f657MHx01533@mass.dis.org>
Message-ID: <Pine.BSF.4.21.0107050018290.30810-100000@beppo>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


I've tried it. All of Adaptec, Symbios and QLogic are fine.


On Thu, 5 Jul 2001, Mike Smith wrote:

> > On Thu, 5 Jul 2001, Mike Smith wrote:
> > 
> > > The simplest setup is two SCSI controllers, one at each end of a SCSI
> > > bus, with the initiator ID set differently on each controller.
> > 
> > so any scsi controller is known to work in this configuration? or has
> > no-one tried it? in particular, is there any card which won't let me
> > change the initiator ID?
> 
> I don't think many people have tried it.  I'd expect you'd be OK with the 
> higher-end Adaptec and LSI controllers.
> 
> -- 
> ... every activity meets with opposition, everyone who acts has his
> rivals and unfortunately opponents also.  But not because people want
> to be opponents, rather because the tasks and relationships force
> people to take different points of view.  [Dr. Fritz Todt]
>            V I C T O R Y   N O T   V E N G E A N C E
> 
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-scsi" in the body of the message
> 


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5  6:10:49 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id A9F5837B401
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 06:10:46 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from burner.fokus.gmd.de (burner [193.175.133.116])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id PAA12970;
	Thu, 5 Jul 2001 15:10:22 +0200 (MET DST)
Received: (from jes@localhost)
	by burner.fokus.gmd.de (8.9.3+Sun/8.9.3) id PAA00961;
	Thu, 5 Jul 2001 15:10:07 +0200 (MEST)
Date: Thu, 5 Jul 2001 15:10:07 +0200 (MEST)
Message-Id: <200107051310.PAA00961@burner.fokus.gmd.de>
From: schilling@fokus.gmd.de
To: gibbs@scsiguy.com, schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, ken@kdm.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

>From gibbs@scsiguy.com Tue Jul  3 16:31:46 2001

>>>> There is no capacity reporting problem, the capacity is reported as documen
>>ted
>>>> in the CD standards.
>>
>>>Well, it's good to know it isn't a bug. :)
>>
>>It definitely _is_ a bug.

>Sending a Bus Device Reset message to a target when it doesn't respond
>in the expected amount of time is a bug?  Perhaps the driver could try
>an abort message first, but the behavior is not completely unreasonable.
>Your other complaints seem to be in regard to a "bus reset", which never
>occurred in this situation.

OK, if it is no bus device reset, it should be OK.

However, 5 seconds is a too short timeout.


Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 10:49:12 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id CAB2437B403
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 10:49:08 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from burner.fokus.gmd.de (burner [193.175.133.116])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id TAA15798;
	Thu, 5 Jul 2001 19:48:50 +0200 (MET DST)
Received: (from jes@localhost)
	by burner.fokus.gmd.de (8.9.3+Sun/8.9.3) id TAA01309;
	Thu, 5 Jul 2001 19:48:39 +0200 (MEST)
Date: Thu, 5 Jul 2001 19:48:39 +0200 (MEST)
Message-Id: <200107051748.TAA01309@burner.fokus.gmd.de>
From: schilling@fokus.gmd.de
To: freebsd-scsi@freebsd.org, mckay@thehub.com.au
Cc: ken@kdm.org, schilling@fokus.gmd.de
Subject: Re: Problems reading burned CDs (one problem solved)
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


>From mckay@thehub.com.au Wed Jul  4 11:11:28 2001

>Tony Maher <tonym@angis.org.au> pointed out the -s flag to mount_cd9660.
>With that, I was able to mount the CD and read all the files.  Here's how:

># cdcontrol -f acd0
>Compact Disc Control utility, version 2.0
>Type `?' for command list

>cdcontrol> info
>Starting track = 1, ending track = 3, TOC size = 34 bytes
>track     start  duration   block  length   type
>-------------------------------------------------
>    1   0:02.00  10:59.64       0   49339   data
>    2  10:59.64   1:02.60   49339    4560   data
>    3  12:00.49  41:17.24   53899  185649   data
>  170  53:15.73         -  239548       -      -

>cdcontrol> quit
># mount_cd9660 -s 49339 /dev/acd0c /mnt
># df /mnt
>Filesystem  1K-blocks     Used    Avail Capacity  Mounted on
>/dev/acd0c     478792   478792        0   100%    /mnt
>#

>In other words, the burner program, for whatever reason, split the
>second session into two tracks.  The final track is not an ISO filesystem.
>But the 2nd track is the directory for the whole disk.

>Presumably Windoze steps backwards through the tracks until it can mount
>successfully.  We should to the same.  It should be easy.

If you are right, then this CD is completely nonstandard.

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 12:22:44 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from kumquat.hlcca.org (kumquat.hlcca.org [209.244.192.145])
	by hub.freebsd.org (Postfix) with SMTP id DEF1437B406
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 12:22:40 -0700 (PDT)
	(envelope-from dakota@kumquat.hlcca.org)
Received: (qmail 93213 invoked by uid 143); 5 Jul 2001 15:21:56 -0000
Received: from localhost (HELO kumquat.hlcca.org) (sendmail-bs@127.0.0.1)
  by localhost with SMTP; 5 Jul 2001 15:21:56 -0000
X-Mailer: exmh version 2.3.1 01/18/2001 with nmh-1.0.4
To: freebsd-scsi@freebsd.org, dakota@FreeBSD.ORG
From: lists@mediumgreen.com
Subject: Re: USB/umass in addition to "other" SCSI 
In-Reply-To: Message from Andrew Gordon <arg@arg1.demon.co.uk> 
   of "Wed, 04 Jul 2001 18:33:07 +0100." <20010704181957.G65863-100000@server.arg.sj.co.uk> 
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Transfer-Encoding: quoted-printable
Date: Thu, 05 Jul 2001 15:21:56 +0000
Message-Id: <20010705192240.DEF1437B406@hub.freebsd.org>
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

I think I heard Andrew Gordon say:
>On Wed, 4 Jul 2001, Kenneth W Cochran wrote:
>
>> Hello -scsi:
>>
>> How do I "connect" a USB "disk" when I already have a SCSI
>> HBA & other peripherals installed & operating?


What great timing for this discussion.. I've been trying to get
a compact flash reader working on my machine at home for a couple
of days.


>It should appear of its own accord when usbd sees it.  However, this
>doesn't appear to work properly at present.

I've attached the device before startup and have noticed some usbd
messages when I remove and reinstall it.

Jul  4 22:06:22 blueberry /kernel: ugen0: at uhub0 port 2 (addr 3) discon=
nected
Jul  4 22:06:22 blueberry /kernel: ugen0: detached
Jul  4 22:06:26 blueberry /kernel: ugen0: SIIG DigiFilm-Combo Reader, rev=
 =

1.00/0.01, addr 3

blueberry# usbdevs
addr 1: UHCI root hub, VIA
 addr 2: Microsoft IntelliMouse=AE Optical, Microsoft
 addr 3: DigiFilm-Combo Reader, SIIG


>>  And what will
>> (should :) be its device-name (in /dev)?
>
>/dev/daX*  where X is the next available number

By the above output, I figured that da3 is what I'd use, but it
does seem to work (FWIW, I've tired da[0-4]):

blueberry# mount -t msdos /dev/da3s1 /mnt
msdos: /dev/da3s1: Device not configured
blueberry# camcontrol devlist
<IMS CDD2000/00 1.26>              at scbus0 target 2 lun 0 (pass0,cd0)
<HP C1553A 9503>                   at scbus0 target 4 lun 0 (pass1,sa0)
<HP C1553A 9503>                   at scbus0 target 4 lun 1 (pass2,ch0)


>> & "camcontrol rescan 1" gives
>> me an ioctl() error.
>
>I haven't found a method that works other than to have the device presen=
t
>at boot time.

Had it present at boot.

Have everything that seems relevant in my kernel....

# SCSI peripherals
device          scbus           # SCSI bus (required)
device          da              # Direct Access (disks)
device          sast of options # Sequential Access (tape etc)
device          cdalso present i# CD
device          pass            # Passthrough device (direct SCSI access)=

# USB support
device          uhci            # UHCI PCI->USB interface
device          ohci            # OHCI PCI->USB interface
device          usb             # USB Bus (required)
device          ugen            # Generic
device          uhid            # "Human Interface Devices"
device          ukbd            # Keyboard
device          ulpt            # Printer
device          umass           # Disks/Mass storage - Requires scbus and=
 da
device          ums             # Mouse

Is there anything I've forgotten?

-matthew


To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 15:45:47 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 05BC637B401
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 15:45:44 -0700 (PDT)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id QAA54042;
	Thu, 5 Jul 2001 16:45:33 -0600 (MDT)
	(envelope-from ken)
Date: Thu, 5 Jul 2001 16:45:33 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: schilling@fokus.gmd.de
Cc: gibbs@scsiguy.com, freebsd-scsi@freebsd.org, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Message-ID: <20010705164533.A53974@panzer.kdm.org>
References: <200107051310.PAA00961@burner.fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200107051310.PAA00961@burner.fokus.gmd.de>; from schilling@fokus.gmd.de on Thu, Jul 05, 2001 at 03:10:07PM +0200
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Thu, Jul 05, 2001 at 15:10:07 +0200, schilling@fokus.gmd.de wrote:
> >From gibbs@scsiguy.com Tue Jul  3 16:31:46 2001
> 
> >>>> There is no capacity reporting problem, the capacity is reported as documen
> >>ted
> >>>> in the CD standards.
> >>
> >>>Well, it's good to know it isn't a bug. :)
> >>
> >>It definitely _is_ a bug.
> 
> >Sending a Bus Device Reset message to a target when it doesn't respond
> >in the expected amount of time is a bug?  Perhaps the driver could try
> >an abort message first, but the behavior is not completely unreasonable.
> >Your other complaints seem to be in regard to a "bus reset", which never
> >occurred in this situation.
> 
> OK, if it is no bus device reset, it should be OK.

Eh?  It is a bus device reset...

> However, 5 seconds is a too short timeout.

For what?  The 5 second timeout is for a generic SCSI command facility,
not for any particular command.  5 seconds is plenty of time for some
commands, and way too short for others.  A user savvy enough to compose
his own CDBs should also be knowledgeable enough to specify a suitable
timeout.

Sometimes a knowledgeable user will forget (like I did) to specify a
longer timeout or will try to find a suitable timeout via
experimentation.  Either way, he'll figure out soon enough whether the
timeout was long enough and therefore whether he needs to make it longer.

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 16:45: 9 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from arg1.demon.co.uk (arg1.demon.co.uk [194.222.34.166])
	by hub.freebsd.org (Postfix) with ESMTP id 0BBA237B406
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 16:45:07 -0700 (PDT)
	(envelope-from arg@arg1.demon.co.uk)
Received: by arg1.demon.co.uk (Postfix, from userid 300)
	id 9C6DC9B03; Fri,  6 Jul 2001 00:45:02 +0100 (BST)
Received: from localhost (localhost [127.0.0.1])
	by arg1.demon.co.uk (Postfix) with ESMTP
	id 996A25D1D; Fri,  6 Jul 2001 00:45:02 +0100 (BST)
Date: Fri, 6 Jul 2001 00:45:02 +0100 (BST)
From: Andrew Gordon <arg@arg1.demon.co.uk>
X-X-Sender:  <arg@server.arg.sj.co.uk>
To: <lists@mediumgreen.com>
Cc: <freebsd-scsi@freebsd.org>
Subject: Re: USB/umass in addition to "other" SCSI 
In-Reply-To: <20010705192240.DEF1437B406@hub.freebsd.org>
Message-ID: <20010706003309.E70405-100000@server.arg.sj.co.uk>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=ISO-8859-1
Content-Transfer-Encoding: QUOTED-PRINTABLE
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org



On Thu, 5 Jul 2001 lists@mediumgreen.com wrote:

> I think I heard Andrew Gordon say:
>
> >It should appear of its own accord when usbd sees it.  However, this
> >doesn't appear to work properly at present.
>
> I've attached the device before startup and have noticed some usbd
> messages when I remove and reinstall it.
>
> Jul  4 22:06:22 blueberry /kernel: ugen0: at uhub0 port 2 (addr 3) discon=
nected
> Jul  4 22:06:22 blueberry /kernel: ugen0: detached
> Jul  4 22:06:26 blueberry /kernel: ugen0: SIIG DigiFilm-Combo Reader, rev
> 1.00/0.01, addr 3
>
> blueberry# usbdevs
> addr 1: UHCI root hub, VIA
>  addr 2: Microsoft IntelliMouse=AE Optical, Microsoft
>  addr 3: DigiFilm-Combo Reader, SIIG

This is a different problem.  The system hasn't even tried to associate
this unit with a disc device, because it hasn't been identified as a USB
Mass Storage device.

Unfortunately, you are probably out of luck: this is most likely a device
which uses a proprietary protocol rather than the standard mass-storage
class.

Sadly, the proportion of junk among USB peripherals seems to be even
higher than among PC hardware generally.




To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 17: 4:41 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from mailhub.fokus.gmd.de (mailhub.fokus.gmd.de [193.174.154.14])
	by hub.freebsd.org (Postfix) with ESMTP id 9AC7937B403
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 17:04:37 -0700 (PDT)
	(envelope-from schilling@fokus.gmd.de)
Received: from fokus.gmd.de (sherwood [193.175.133.102])
	by mailhub.fokus.gmd.de (8.8.8/8.8.8) with ESMTP id CAA08888;
	Fri, 6 Jul 2001 02:04:28 +0200 (MET DST)
Received: (from jes@localhost)
	by fokus.gmd.de (8.8.8+Sun/8.8.8) id CAA04785;
	Fri, 6 Jul 2001 02:03:53 +0200 (MET DST)
Date: Fri, 6 Jul 2001 02:03:53 +0200 (MET DST)
From: Joerg Schilling <schilling@fokus.gmd.de>
Message-Id: <200107060003.CAA04785@fokus.gmd.de>
To: ken@kdm.org, schilling@fokus.gmd.de
Cc: freebsd-scsi@freebsd.org, gibbs@scsiguy.com, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org


>From ken@panzer.kdm.org Fri Jul  6 00:45:37 2001

>> 
>> >Sending a Bus Device Reset message to a target when it doesn't respond
>> >in the expected amount of time is a bug?  Perhaps the driver could try
>> >an abort message first, but the behavior is not completely unreasonable.
>> >Your other complaints seem to be in regard to a "bus reset", which never
>> >occurred in this situation.
>> 
>> OK, if it is no bus device reset, it should be OK.

>Eh?  It is a bus device reset...

I believe you are talking about a target reset which does not reset the whole
bus but a specific target.

>> However, 5 seconds is a too short timeout.

>For what?  The 5 second timeout is for a generic SCSI command facility,
>not for any particular command.  5 seconds is plenty of time for some
>commands, and way too short for others.  A user savvy enough to compose
>his own CDBs should also be knowledgeable enough to specify a suitable
>timeout.

Believe that _any_ SCSI device I know will take much longer if there is some
problem to read the media.

For a hard disk you should wait at least 20 seconds for error recovery
(this means read retries _and_ eventually error correction).

If a CD-ROM uses error correction, you should give it ~ 100 seconds.

If you don't follow these rules, you will end up believing that there are
completely _unreadable_ blocks where the media is only _very hard_ to read.

Jörg

 EMail:joerg@schily.isdn.cs.tu-berlin.de (home) Jörg Schilling D-13353 Berlin
       js@cs.tu-berlin.de		(uni)  If you don't have iso-8859-1
       schilling@fokus.gmd.de		(work) chars I am J"org Schilling
 URL:  http://www.fokus.gmd.de/usr/schilling   ftp://ftp.fokus.gmd.de/pub/unix

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message


From owner-freebsd-scsi  Thu Jul  5 17:28:38 2001
Delivered-To: freebsd-scsi@freebsd.org
Received: from panzer.kdm.org (panzer.kdm.org [216.160.178.169])
	by hub.freebsd.org (Postfix) with ESMTP id 3460937B405
	for <freebsd-scsi@freebsd.org>; Thu,  5 Jul 2001 17:28:28 -0700 (PDT)
	(envelope-from ken@panzer.kdm.org)
Received: (from ken@localhost)
	by panzer.kdm.org (8.9.3/8.9.1) id SAA54698;
	Thu, 5 Jul 2001 18:28:24 -0600 (MDT)
	(envelope-from ken)
Date: Thu, 5 Jul 2001 18:28:24 -0600
From: "Kenneth D. Merry" <ken@kdm.org>
To: Joerg Schilling <schilling@fokus.gmd.de>
Cc: freebsd-scsi@freebsd.org, gibbs@scsiguy.com, mckay@thehub.com.au
Subject: Re: Problems reading burned CDs
Message-ID: <20010705182824.A54608@panzer.kdm.org>
References: <200107060003.CAA04785@fokus.gmd.de>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
User-Agent: Mutt/1.2i
In-Reply-To: <200107060003.CAA04785@fokus.gmd.de>; from schilling@fokus.gmd.de on Fri, Jul 06, 2001 at 02:03:53AM +0200
Sender: owner-freebsd-scsi@FreeBSD.ORG
Precedence: bulk
List-ID: <freebsd-scsi.FreeBSD.ORG>
List-Archive: <http://docs.freebsd.org/mail/> (Web Archive)
List-Help: <mailto:majordomo?subject=help> (List Instructions)
List-Subscribe: <mailto:majordomo?subject=subscribe%20freebsd-scsi>
List-Unsubscribe: <mailto:majordomo?subject=unsubscribe%20freebsd-scsi>
X-Loop: FreeBSD.org

On Fri, Jul 06, 2001 at 02:03:53 +0200, Joerg Schilling wrote:
> 
> >From ken@panzer.kdm.org Fri Jul  6 00:45:37 2001
> 
> >> 
> >> >Sending a Bus Device Reset message to a target when it doesn't respond
> >> >in the expected amount of time is a bug?  Perhaps the driver could try
> >> >an abort message first, but the behavior is not completely unreasonable.
> >> >Your other complaints seem to be in regard to a "bus reset", which never
> >> >occurred in this situation.
> >> 
> >> OK, if it is no bus device reset, it should be OK.
> 
> >Eh?  It is a bus device reset...
> 
> I believe you are talking about a target reset which does not reset the whole
> bus but a specific target.

The SCSI-2 terminology is "Bus Device Reset", SCSI-3 terminology is "Target
Reset".  You said above "if it is no bus device reset, it should be OK.".
It is a bus device reset, a.k.a. a target reset.

> >> However, 5 seconds is a too short timeout.
> 
> >For what?  The 5 second timeout is for a generic SCSI command facility,
> >not for any particular command.  5 seconds is plenty of time for some
> >commands, and way too short for others.  A user savvy enough to compose
> >his own CDBs should also be knowledgeable enough to specify a suitable
> >timeout.
> 
> Believe that _any_ SCSI device I know will take much longer if there is some
> problem to read the media.
> 
> For a hard disk you should wait at least 20 seconds for error recovery
> (this means read retries _and_ eventually error correction).
> 
> If a CD-ROM uses error correction, you should give it ~ 100 seconds.
> 
> If you don't follow these rules, you will end up believing that there are
> completely _unreadable_ blocks where the media is only _very hard_ to read.

True enough, there are certainly situations where that timeout is too
short.  It may be a good idea to raise it, but I'll never be able to set it
to the "just right" value for any command the user might send.

e.g., a 3 hour timeout might be sufficient for most modern hard disks to
complete a format unit command, but I don't want a user to have to wait 3
hours to figure out his drive is dead.

So in any case, it's still up to the user to set the right timeout for the
command if he is specifying the CDB.  For the pre-configured commands in
camcontrol, like 'format', 'inquiry', 'start', 'stop', etc., the timeout is
already set to something appropriate for the command in question.

Ken
-- 
Kenneth Merry
ken@kdm.org

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-scsi" in the body of the message