Re: kern/55965: st(4) on adaptec fails to 'mt erase'

To: kern-bug-people%netbsd.org@localhost,gnats-admin%netbsd.org@localhost,netbsd-bugs%netbsd.org@localhost,Hauke Fath <hauke%Espresso.Rhein-Neckar.DE@localhost>
Subject: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
From: Frank Kardel <kardel%netbsd.org@localhost>
Date: Fri, 29 Jan 2021 18:10:01 +0000 (UTC)

The following reply was made to PR kern/55965; it has been noted by GNATS.

From: Frank Kardel <kardel%netbsd.org@localhost>
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
Date: Fri, 29 Jan 2021 19:06:43 +0100

 Also part of the now closed bug from 2005 - PR/kern 29369.
 
 Seems like the ahc driver did not get any love on timeout processing. 
 Any takers?
 
 Frank
 
 
 On 01/29/21 18:35, Hauke Fath wrote:
 >> Number:         55965
 >> Category:       kern
 >> Synopsis:       st(4) on adaptec fails to 'mt erase'
 >> Confidential:   no
 >> Severity:       serious
 >> Priority:       medium
 >> Responsible:    kern-bug-people
 >> State:          open
 >> Class:          sw-bug
 >> Submitter-Id:   net
 >> Arrival-Date:   Fri Jan 29 17:35:00 +0000 2021
 >> Originator:     Hauke Fath
 >> Release:        NetBSD 9.1_STABLE
 >> Organization:
 > Falling Raindrops
 >> Environment:
 > 	
 > 	
 > System: NetBSD henkelmann.causeuse.org 9.1_STABLE NetBSD 9.1_STABLE (HENKELMANN) #0: Wed Jan 27 15:57:38 CET 2021 hauke%pizza.causeuse.org@localhost:/var/obj/netbsd-builds/9/macppc/sys/arch/macppc/compile/HENKELMANN macppc
 > Architecture: powerpc
 > Machine: macppc
 >> Description:
 > 	An Adaptec 2944 (HVD) scsi adapter
 >
 > [     1.000000] ahc0 at pci1 dev 2 function 0: Adaptec 2944 Ultra SCSI adapter
 > [     1.000000] genppc_pci_intr_map: pin: 3, line: 23
 > [     1.000000] ahc0: interrupting at irq 23
 > [     1.000000] ahc0: aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
 > [     1.000000] scsibus0 at ahc0: 16 targets, 8 luns per target
 >
 > 	with Quantum DLT4000 drives attached
 >
 > [     4.319997] st0 at scsibus0 target 5 lun 0: <Quantum, DLT4000, CC1E> tape removable
 > [     4.319997] st0: drive empty
 > [     4.329997] st1 at scsibus0 target 6 lun 0: <Quantum, DLT4000, CC1E> tape removable
 > [     4.329997] st1: density code 25, variable blocks, write-enabled
 > [     4.329997] st1: sync (100.00ns offset 15), 8-bit (10.000MB/s) transfers
 >
 > 	generally works fine, but an 'mt erase' leads to surprising
 > 	verbosity after a few seconds:
 >
 > [...]
 > [   198.050100] ahc0:SCB 0xe - timed out
 > [   198.050100]  Dump Card State Begins <<<<<<<<<<<<<<<<<
 > [   198.050100] ahc0: Dumping Card State while idle, at SEQADDR 0x7
 > [   198.050100] Card was paused
 > [   198.050100] ACCUM = 0x32, SINDEX = 0x67, DINDEX = 0x27, ARG_2 = 0x3
 > [   198.050100] HCNT = 0x0 SCBPTR = 0x0
 > [   198.050100] SCSISIGI[0x0] ERROR[0x0] SCSIBUSL[0x0] LASTPHASE[0x1]
 > [   198.050100] SCSISEQ[0x12] SBLKCTL[0x2] SCSIRATE[0x0] SEQCTL[0x10]
 > [   198.050100] SEQ_FLAGS[0xc0] SSTAT0[0x5] SSTAT1[0xa] SSTAT2[0x0]
 > [   198.050100] SSTAT3[0x0] SIMODE0[0x0] SIMODE1[0xa4] SXFRCTL0[0x80]
 > [   198.050100] DFCNTRL[0x0] DFSTATUS[0x2d]
 > [   198.050100] STACK: 0x0 0x16c 0x19c 0x3
 > [   198.050100] SCB count = 16
 > [   198.050100] Kernel NEXTQSCB = 15
 > [   198.050100] Card NEXTQSCB = 15
 > [   198.050100] QINFIFO entries:
 > [   198.050100] Waiting Queue entries:
 > [   198.050100] Disconnected Queue entries: 0:14
 > [   198.050100] QOUTFIFO entries:
 > [   198.050100] Sequencer Free SCB List: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
 > [   198.050100] Sequencer SCB Info:
 > [   198.050100]   0 SCB_CONTROL[0x44] SCB_SCSIID[0x67]
 > [   198.050100] SCB_LUN[0x0] SCB_TAG[0xe]
 > [   198.050100]   1 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   2 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   3 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   4 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   5 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   6 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   7 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   8 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]   9 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  10 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  11 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  12 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  13 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  14 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100]  15 SCB_CONTROL[0x0] SCB_SCSIID[0xff]
 > [   198.050100] SCB_LUN[0xff] SCB_TAG[0xff]
 > [   198.050100] Pending list:
 > [   198.050100]  14 SCB_CONTROL[0x40] SCB_SCSIID[0x67]
 > [   198.050100] SCB_LUN[0x0]
 > [   198.050100] Kernel Free SCB list: 13 12 11 10 9 8 7 6 5 4 3 2 1 0
 > [   198.050100] Untagged Q(6): 14
 >
 > [   198.050100]
 > [   198.050100] ahc0:Queuing a BDR SCB
 > [   198.050100] ahc0:Bus Device Reset Message Sent
 > [   198.050100] st1(ahc0:0:6:0): ahc0: no longer in timeout, status = 0
 > [   198.050100] ahc0: Bus Device Reset on A:6. 1 SCBs aborted
 > [...]
 >
 > 	and no erase.
 >
 > 	I originally encountered this on the machine's netbsd-5
 > 	installation, then upgraded since "surely this has long been
 > 	fixed". Not so, although -5 lost the scsibus as a result till
 > 	the next reboot, whereas -9 will recover, and you can repeat
 > 	the exercise.
 >
 > 	This PowerMac G3 B/W is my only homeoffice machine with a pci
 > 	bus, but I don't think the issue is specific to macppc. This
 > 	used to be my home server for a couple of years, and it ran a
 > 	DLT4000 off a different interface just fine.
 >
 > 	
 >> How-To-Repeat:
 > 	
 >
 > 	Hang a DLT drive off an Adaptec 2944 (HVD), and attempt to
 > 	erase a tape.
 >   
 >> Fix:
 > 	
 >
 > 	Yes, please.
 >
 > 	My single-ended drive has died, and I need to erase the tapes...
 >
 >> Unformatted:
 >   	
 >

Follow-Ups:
- Re: kern/55965: st(4) on adaptec fails to 'mt erase'
  - From: Manuel Bouyer

Prev by Date: kern/55965: st(4) on adaptec fails to 'mt erase'
Next by Date: PR/55914 CVS commit: [netbsd-9] src/usr.bin/progress
Previous by Thread: kern/55965: st(4) on adaptec fails to 'mt erase'
Next by Thread: Re: kern/55965: st(4) on adaptec fails to 'mt erase'
Indexes:

Home | Main Index | Thread Index | Old Index