All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Roger J. Allen" <rja@sis.rpslmc.edu>
To: ultralinux@vger.kernel.org
Subject: Re: sparc64 mt race?
Date: Fri, 30 Oct 1998 20:15:57 +0000	[thread overview]
Message-ID: <marc-linux-ultrasparc-90978880305808@msgid-missing> (raw)
In-Reply-To: <marc-linux-ultrasparc-90967139815468@msgid-missing>

On Thu, 29 Oct 1998, Rich Sahlender wrote:

> I'm not sure if this is a kernel, scsi, or 32 .vs. 64 bit issue...
> 
> Using the latest 2.1.126 from vger cvs with ultrapenguin-1.0.9 on an
> Ultra1, a simple "mt -f /dev/st0 off" to unload a tape sends the cpu

Is the offline command your only problem, or do you also get errors with
other mt commands that access the drive?

> to 100%. Running processes continue but cannot terminate, new processes
> will not start. dmesg shows:
> 
> esp0: IRQ 3,7e0 SCSI ID 7  Clock 40 MHz CCF=8 Time-Out 167 NCR53C9XF(espfast) detected
> esp0: FAST chip is fasHME (family\x10, version=5)
> ESP: Total of 1 ESP hosts found, 1 actually in use.
> scsi0 : Sparc ESP366-HME
> scsi : 1 host.

My ultra1 170E has the same values for the esp.  I think that is where
the problem(s) lie(s).

>   Vendor: SEAGATE   Model: ST32171W SUN2.1G  Rev: 7462
>   Type:   Direct-Access                      ANSI SCSI revision: 02
> Detected scsi disk sda at scsi0, channel 0, id 0, lun 0
>   Vendor: EXABYTE   Model: EXB-85008SQANXBA  Rev: 07J0
>   Type:   Sequential-Access                  ANSI SCSI revision: 02
> Detected scsi tape st0 at scsi0, channel 0, id 4, lun 0

I may have the same problem, but my dmesg output shows error messages.
This is with an Exabyte 8505XLE attached to the EXTERNAL scsi port,
which works fine with Solaris 2.6.  Is your tape drive external or
internal?  Maybe it does not matter.

>   Vendor: TOSHIBA   Model: XM5701TASUN12XCD  Rev: 0997
>   Type:   CD-ROM                             ANSI SCSI revision: 02
> Detected scsi CD-ROM sr0 at scsi0, channel 0, id 6, lun 0
> scsi : detected 1 SCSI tape 1 SCSI cdrom 1 SCSI disk total.
> esp0: Disabling sync for buggy Toshiba CDROM.
                           ^^^^^
The Exabyte may have similar ?bug(s)?.

> esp0: Disabling DISCONNECT for target 6 lun 0
> esp0: target 6 asynchronous
> Uniform CDROM driver Revision: 2.14
> esp0: Disabling DISCONNECT for target 0 lun 0
> esp0: 16 byte WIDE transfers enabled for target 0.
> esp0: target 0 [period 100ns offset 15 20.00MHz FAST-WIDE SCSI-II]
> SCSI device sda: hdwr sector= 512 bytes. Sectors= 4157201 [2029 MB] [2.0 GB]
> sunhme.c:v1.2 10/Oct/96 David S. Miller (davem@caipfs.rutgers.edu)
> eth0: HAPPY MEAL (SBUS) 10/100baseT Ethernet 08:00:20:8d:21:cd
> eth0: Link is up using internal transceiver at 100Mb/s, Full Duplex.
> 
> Nothing unusual there nor in syslog. Is there anything else I can
> provide to help?
> 

Instead of "mt -f /dev/st0 off", try "mt -f /dev/nst0 status".  When I
try to get the status, I get esp parity errors:

esp0: Disabling DISCONNECT for target 4 lun 0
esp0: data bad parity detected.
esp0: data bad parity detected.
esp0: yieee, bytes_sent < 0!
esp0: csz=0 fifocount=0 ecount=0
esp0: use_sg=0 ptr\000000000500006 this_residual=0
esp0: Forcing async for target 4
esp0: got status only, esp0: bad parity somewhere mout= 5
esp0: still in msgout, parity error assumed
esp0: data bad parity detected.
esp0: data bad parity detected.
esp0: yieee, bytes_sent < 0!
esp0: csz=0 fifocount=0 ecount=0
esp0: use_sg=0 ptr\00000000050000c this_residual=0
esp0: Forcing async for target 4
esp0: got status only, esp0: bad parity somewhere mout= 5
esp0: still in msgout, parity error assumed

Someone mentioned checking the termination.  Since the ultra has a 68
pin scsi and the Exabyte has a 50 pin centronics connector, I tried an
active terminator and a 68 to 50 pin adapter with high bit termination,
but that did not help (nor hurt).

One symptom that I noticed was the output from /proc/scsi/esp/0.  Before
the tape drive is accessed, it shows:

Sparc ESP Host Adapter:
	PROM node		fffffffff0061044
	PROM name		SUNW,fas
	ESP Model		Happy Meal FAS
	DMA Revision		Rev HME/FAS
	Live Targets		[ 0 1 4 6 ]

Target #	config3		Sync Capabilities	Disconnect	Wide
0		000000e3	[5f,04]			no		yes
1		000000e3	[5f,04]			no		yes
4		000000a1	[5f,04]			no		no
6		000000a1	[5f,04]			no		no

But after running an "mt -f /dev/nst0 status" command, the esp complains
with the esp errors and the cat /proc/scsi/esp/0 shows:

Sparc ESP Host Adapter:
	PROM node		fffffffff0061044
	PROM name		SUNW,fas
	ESP Model		Happy Meal FAS
	DMA Revision		Rev HME/FAS
	Live Targets		[ 0 1 4 6 ]

Target #	config3		Sync Capabilities	Disconnect	Wide
0		000000e3	[5f,04]			no		yes
1		000000e3	[5f,04]			no		yes
4		000000e1	[5f,04]			no		yes
6		000000a1	[5f,04]			no		no

Which shows the tape drive on target 4 as a WIDE scsi instead of NARROW!

If I try to read from the drive, then the esp parity errors are constant
and nothing can be done except reboot.

In the kernel drivers/scsi/esp.c code, there is a section where it
checks to see if the device is wide or not.  There is some code that
claims that Toshiba CD-ROMS are buggy and they do not get checked to see
if they are wide (or synchronous).  I copied the Toshiba code where it
checks if the device is wide, changed it to also check for Exabyte tape
drives, re-built the kernel, rebooted, and then I could read from the
tape drive without any errors!

Here is what I added (I wish I changed the order of the files for the
diff command):

*** esp.c	Thu Oct 29 18:17:11 1998
--- esp.c-dist	Tue Sep 22 19:13:54 1998
***************
*** 1429,1436 ****
  		 */
  		if(esp->erev = fashme && !SDptr->wide) {
  			if(!SDptr->borken &&
- 			   (SDptr->type != TYPE_TAPE ||
- 			    strncmp(SDptr->vendor, "EXABYTE", 7)) &&
  			   (SDptr->type != TYPE_ROM ||
  			    strncmp(SDptr->vendor, "TOSHIBA", 7))) {
  				build_wide_nego_msg(esp, 16);
--- 1429,1434 ----

Maybe the test should be for just my model of Exabyte, or all Exabyte's,
like the above code.  Are there wide Exabyte tape drives that this would
break?  Are all Toshiba cd-rom's buggy, narrow, and asynchronous?

After changing the code in esp.c, I am still getting timeouts on the
scsi bus when I rewind the tape drive for only a few hundred megabytes.
This is when the tape is read without any errors using:

cpio -itv -C 1024 -I /dev/nst0

esp0: Disabling DISCONNECT for target 4 lun 0
esp0: target 4 [period 200ns offset 11 5.00MHz synchronous SCSI]

Later, when it is rewound, these occur:

scsi : aborting command due to timeout : pid 9822, scsi0, channel 0, id 1, lun 0 Write (6) 00 40 38 02 00 
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<b2b70a10> addr<1e000000>
esp0: SW [sreg<17> sstep<04> ireg<20>]
esp0: HW reread [sreg<12> sstep<cb> ireg<00>]
esp0: current command [tgt<04> lun<00> pphase<UNISSUED> cphase<SLCTNORM>]
esp0: disconnected 
SCSI disk error : host 0 channel 0 id 1 lun 0 return code = 50000
scsidisk I/O error: dev 08:11, sector 16440
scsi : aborting command due to timeout : pid 9823, scsi0, channel 0, id 1, lun 0 Write (6) 02 40 30 02 00 
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<b2b70a10> addr<1e000000>
esp0: SW [sreg<17> sstep<04> ireg<20>]
esp0: HW reread [sreg<12> sstep<cb> ireg<00>]
esp0: current command [tgt<04> lun<00> pphase<UNISSUED> cphase<SLCTNORM>]
esp0: disconnected 
SCSI disk error : host 0 channel 0 id 1 lun 0 return code = 50000
scsidisk I/O error: dev 08:11, sector 147504
scsi : aborting command due to timeout : pid 9974, scsi0, channel 0, id 1, lun 0 Read (6) 02 40 30 02 00 
esp0: Aborting command
esp0: dumping state
esp0: dma -- cond_reg<b2b70a10> addr<1e000000>
esp0: SW [sreg<17> sstep<04> ireg<20>]
esp0: HW reread [sreg<12> sstep<cb> ireg<00>]
esp0: current command [tgt<04> lun<00> pphase<UNISSUED> cphase<SLCTNORM>]
esp0: disconnected 
SCSI disk error : host 0 channel 0 id 1 lun 0 return code = 50000
scsidisk I/O error: dev 08:11, sector 147504

I also get timeouts with "mt -f /dev/st0 offline".

My wild guess is that the disabling of DISCONNECT for all devices on the
fashme/fasHME/espfast/ESP366-HME/NCR53C9XF (a few lines later in esp.c)
is causing the timeouts.

-- 
Roger J. Allen                Rush-Presbyterian-St. Luke's Medical Center
System Administrator                                   Chicago,  IL   USA
Surgical Information Systems                       Voice:  (312)-942-4825
Internet: rja@sis.rpslmc.edu                         FAX:  (312)-733-6921

  parent reply	other threads:[~1998-10-30 20:15 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-10-29 14:17 sparc64 mt race? Rich Sahlender
1998-10-29 23:06 ` Eddie C. Dost
1998-10-30 13:51 ` Rich Sahlender
1998-10-30 20:15 ` Roger J. Allen [this message]
1998-10-30 21:21 ` Rich Sahlender

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=marc-linux-ultrasparc-90978880305808@msgid-missing \
    --to=rja@sis.rpslmc.edu \
    --cc=ultralinux@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.