Bug 20790

Do you actually have a tape loaded in the drive when you issue the 'mt stat'
command? If so, it may be the code that tries to sense what media is there-
this can break for some drives. Try building a CAMDEBUG kernel, reboot, do
camcontrol debug -Ic 0:4:0 and then do the 'mt' test with a tape inserted and
send me the results, thank you.


> 
> >Number:         20790
> >Category:       i386
> >Synopsis:       SCSI tape drive no longer works
> >Confidential:   no
> >Severity:       serious
> >Priority:       high
> >Responsible:    freebsd-bugs
> >State:          open
> >Quarter:        
> >Keywords:       
> >Date-Required:
> >Class:          sw-bug
> >Submitter-Id:   current-users
> >Arrival-Date:   Tue Aug 22 16:10:00 PDT 2000
> >Closed-Date:
> >Last-Modified:
> >Originator:     Jim Dutton
> >Release:        FreeBSD 4.1-RELEASE i386
> >Organization:
> Southern Illinois University
> >Environment:
> 
> FreeBSD 4.1-RELEASE #2: Tue Aug 22 00:52:51 CDT 2000
> jimd@dutton3.it.siu.edu:/usr/src/sys/compile/XSYSDELL41
> Calibrating clock(s) ... TSC clock: 398768762 Hz, i8254 clock: 1193166 Hz
> CLK_USE_I8254_CALIBRATION not specified - using default frequency
> Timecounter "i8254"  frequency 1193182 Hz
> CLK_USE_TSC_CALIBRATION not specified - using old calibration method
> CPU: Pentium II/Pentium II Xeon/Celeron (398.78-MHz 686-class CPU)
> Origin = "GenuineIntel"  Id = 0x651  Stepping = 1
> Features=0x183f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,
>                    CMOV,PAT,PSE36,MMX,FXSR>
> real memory  = 134217728 (131072K bytes)
> 
> 
> pci2: <PCI bus> on pcib2
> ahc0: <Adaptec aic7850 SCSI adapter> port 0xdc00-0xdcff
>       mem 0xfafff000-0xfaffffff irq 10 at device 11.0 on pci2
> ahc0: No SEEPROM available.
> ahc0: aic7850 Single Channel A, SCSI Id=7, 3/255 SCBs
> ahc0: Host Adapter Bios disabled.  Using default SCSI device parameters
> ahc0: Downloading Sequencer Program... 411 instructions downloaded
> xl0: <3Com 3c905B-TX Fast Etherlink XL> port 0xcc00-0xcc7f
>      mem 0xff000000-0xff00007f irq 11 at device 17.0 on pci0
> 
> Waiting 15 seconds for SCSI devices to settle
> (noperiph:ahc0:0:-1:-1): SCSI bus reset delivered. 0 SCBs aborted.
> ahc0: target 4 synchronous at 5.0MHz, offset = 0xf
> sa0 at ahc0 bus 0 target 4 lun 0
> sa0: <CONNER CTMS  3200 7.10> Removable Sequential Access SCSI-2 device 
> sa0: Serial Number  offset 15)
> pass0 at ahc0 bus 0 target 4 lun 0
> pass0: <CONNER CTMS  3200 7.10> Removable Sequential Access SCSI-2 device 
> pass0: Serial Number 
> pass0: 5.000MB/s transfers (5.000MHz, offset 15)
> 
> >Description:
> 
> Most of the *sa0* tape devices respond to "not configured" when used with
> the MT command. Any device that does not result in this message, hangs up.
> The tape drive read light is on solid, but the drive motor is not running,
> as far as I can tell. The MT command process is locked and can not be KILLed.
> None of the *pass0* devices are "configured".
> 
> This same system and hardware worked under the previous V3.2 installation of
> FreeBSD. The specific SCSI controller is an Adaptec 2902. While the
> environment report above shows a modified kernel, this problem started after
> the 4.1 upgrade, "out of the box".
> 
> >How-To-Repeat:
> 
> Turn on tape drive, install tape, execute MT command with one of the *sa0*
> tape devices.
> 
> >Fix:
> 
> Reboot machine, turn off and do not use tape drive.
> 
> >Release-Note:
> >Audit-Trail:
> >Unformatted:
> 
> 
> To Unsubscribe: send mail to majordomo@FreeBSD.org
> with "unsubscribe freebsd-bugs" in the body of the message
>

Comment 2 Sheldon Hearn 2000-08-23 10:05:29 UTC

State Changed
From-To: open->feedback

Matt has made some suggestions. 

Comment 3 Sheldon Hearn 2000-08-23 10:05:29 UTC

Responsible Changed
From-To: freebsd-bugs->mjacob

Matt will want the feedback.

On 23 Aug, sheldonh@FreeBSD.org wrote:
> Synopsis: SCSI tape drive no longer works
> 
> State-Changed-From-To: open->feedback
> State-Changed-By: sheldonh
> State-Changed-When: Wed Aug 23 02:05:29 PDT 2000
> State-Changed-Why: 
> Matt has made some suggestions.

You are NOT going to beLIEVE this! I never completed the CAMDEBUG setup
and test. I DID find out that the "tape" that I was attempting to use
was written by Solaris-2.8 some time ago, when I had the SCSI controller
in a FBSD-2.2.6 machine (since Solaris-2.5 and up had a patch applied to
ufsdump and would no longer dump to the tape drive when it was under the
control of FBSD-3.2). In previous correspondance, I stated that the tape
used was a previous backup tape. That was correct - but it wasn't an
FBSD backup tape.

I moved the SCSI controller from the FBSD-2.2.6 machine into the
FBSD-3.2 machine prior to the upgrade to 4.1, backing up FBSD-3.2. After
the V4.1 upgrade, I couldn't get ANY MT commands to respond, as noted in
the original problem report. Even withOUT any tape in the drive. I had
been able to query the tape drive beFORE 4.1 without any tape.

Perhaps I "kicked something" over that past 4 hours - I don't know, but
"all of a sudden", MT can now query the drive SO LONG AS I don't have
one of those old Solaris-2.8 generated tapes in the drive!

Put in an old Solaris generated tape, and MT hangs! Use any OTHER tape,
and no problem!!???

It should also be pointed out, as a side note, that the PAM
documentation really "bites". I had to experiment several times to get
the PAM configuration for RSHD to allow a remote dump to work. Now why
did somebody set it to DENY by default?

At this point, I would have to say that "the problem is fixed" so long
as one does NOT use tapes generated by Solaris prior to a FBSD-4.1
upgrade.

You may CLOSE the problem - thanks.

Comment 5 Matt Jacob 2000-08-23 16:25:15 UTC

State Changed
From-To: feedback->closed

Here's what I believe has occurred: DAT tapes come in many formats, 
and the tape drive in question is a pretty old one. My best guess is 
that the tape, written on Solaris, probably in DDS2 format, confused 
the heck out of the drive f/w. So, h/w problem. 

Your only solution for using *that* tape on your FreeBSD tape drive 
is to degauss it.