* Re: sparc64 mt race?
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
` (2 subsequent siblings)
3 siblings, 0 replies; 5+ messages in thread
From: Eddie C. Dost @ 1998-10-29 23:06 UTC (permalink / raw)
To: ultralinux
> 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
> to 100%. Running processes continue but cannot terminate, new processes
> will not start. dmesg shows:
No problems observed with my Tandberg SLR 5 tape.
Eddie.
ecd@skynet.be
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: sparc64 mt race?
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
1998-10-30 21:21 ` Rich Sahlender
3 siblings, 0 replies; 5+ messages in thread
From: Rich Sahlender @ 1998-10-30 13:51 UTC (permalink / raw)
To: ultralinux
Which model ultra, and which scsi controller?
Eddie C. Dost wrote:
> > 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
> > to 100%. Running processes continue but cannot terminate, new processes
> > will not start. dmesg shows:
>
> No problems observed with my Tandberg SLR 5 tape.
>
>
> Eddie.
> ecd@skynet.be
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: sparc64 mt race?
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
1998-10-30 21:21 ` Rich Sahlender
3 siblings, 0 replies; 5+ messages in thread
From: Roger J. Allen @ 1998-10-30 20:15 UTC (permalink / raw)
To: ultralinux
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
^ permalink raw reply [flat|nested] 5+ messages in thread* Re: sparc64 mt race?
1998-10-29 14:17 sparc64 mt race? Rich Sahlender
` (2 preceding siblings ...)
1998-10-30 20:15 ` Roger J. Allen
@ 1998-10-30 21:21 ` Rich Sahlender
3 siblings, 0 replies; 5+ messages in thread
From: Rich Sahlender @ 1998-10-30 21:21 UTC (permalink / raw)
To: ultralinux
This is an Ultra 1 Creator, basically just a newer 170e. The tape drive
is in an external cabinet with terminator and the cable has wide connector
at ultra end and centronics at drive end. The "mt -f /dev/st0 status"
does the same as "offload" although I get timeouts instead of parity errors
on the console.
I also tried connecting a small BoxHill Disk tower with a couple 3gb
narrow scsi disks in it. The machine hangs during boot after probing
the scsi bus and getting timeouts. I'll try a wide/fast external 9gb
early next week and see if it's just a wide to narrow problem or
if it's *any* external device.
Roger J. Allen wrote:
> 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
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread