From andreas@klemm.gtn.com  Sun Nov 10 02:01:47 1996
Received: from news1.gtn.com (news1.gtn.com [192.109.159.3])
          by freefall.freebsd.org (8.7.5/8.7.3) with ESMTP id CAA27528
          for <FreeBSD-gnats-submit@freebsd.org>; Sun, 10 Nov 1996 02:01:46 -0800 (PST)
Received: (from uucp@localhost) by news1.gtn.com (8.7.2/8.7.2) with UUCP id KAA12134 for FreeBSD-gnats-submit@freebsd.org; Sun, 10 Nov 1996 10:45:35 +0100 (MET)
Received: (from andreas@localhost) by klemm.gtn.com (8.8.2/8.8.2) id KAA00717; Sun, 10 Nov 1996 10:46:38 +0100 (MET)
Message-Id: <199611100946.KAA00717@klemm.gtn.com>
Date: Sun, 10 Nov 1996 10:46:38 +0100 (MET)
From: Andreas Klemm <andreas@klemm.gtn.com>
Reply-To: andreas@klemm.gtn.com
To: FreeBSD-gnats-submit@freebsd.org
Subject: dump problems, if tagged command queueing is enabled
X-Send-Pr-Version: 3.2

>Number:         1989
>Category:       kern
>Synopsis:       dump(8) fails to dump if tagged command queuing is enabled
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    gibbs
>State:          closed
>Quarter:
>Keywords:
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Nov 10 02:10:01 PST 1996
>Closed-Date:    Sat Apr 19 15:51:55 PDT 1997
>Last-Modified:  Sat Apr 19 15:52:23 PDT 1997
>Originator:     Andreas Klemm
>Release:        FreeBSD 3.0-CURRENT i386
>Organization:
>Environment:

Part from boot message describing my SCSI hardware and settings

ahc0 <Adaptec 2940 SCSI host adapter> rev 3 int a irq 11 on pci0:12
	mapreg[10] type=1 addr=0000e400 size=0100.
	mapreg[14] type=0 addr=f7800000 size=1000.
	reg16: ioaddr=0xe400 size=0x100
	reg20: virtual=0xf5fbf000 physical=0xf7800000 size=0x1000
ahc0: Reading SEEPROM...done.
ahc0: aic7870 Single Channel, SCSI Id=7, 16 SCBs
ahc0: Reseting Channel A
ahc0: Downloading Sequencer Program...Done
ahc0: Probing channel A
Choosing drivers for scbus configured at 0
ahc0 waiting for scsi devices to settle
ahc0: target 0 synchronous at 10.0MHz, offset = 0xf
ahc0: target 0 Tagged Queuing Device
(ahc0:0:0): "IBM DORS-32160 WA0A" type 0 fixed SCSI 2
sd is configured at 0
sd0(ahc0:0:0): Direct-Access 2063MB (4226725 512 byte sectors)
sd0(ahc0:0:0): with 6703 cyls, 5 heads, and an average 126 sectors/track
ahc0: target 1 synchronous at 10.0MHz, offset = 0xf
ahc0: target 1 Tagged Queuing Device
(ahc0:1:0): "IBM DORS-32160 WA0A" type 0 fixed SCSI 2
sd is configured at 1
sd1(ahc0:1:0): Direct-Access 2063MB (4226725 512 byte sectors)
sd1(ahc0:1:0): with 6703 cyls, 5 heads, and an average 126 sectors/track
ahc0: target 4 synchronous at 4.4MHz, offset = 0x8
(ahc0:4:0): "TANDBERG  TDC 4222 =07:" type 1 removable SCSI 2
st is configured at 0
st0(ahc0:4:0): Sequential-Access density code 0x0, 512-byte blocks, write-enabled
ahc0: target 6 synchronous at 4.0MHz, offset = 0xf
(ahc0:6:0): "TOSHIBA CD-ROM XM-3601TA 0725" type 5 removable SCSI 2
cd is configured at 0
cd0(ahc0:6:0): CD-ROM cd present [253041 x 2048 byte records]
pci0: uses 33558528 bytes of memory from f7800000 upto f9ffffff.
pci0: uses 272 bytes of I/O space from e400 upto e80f.

Kernel config file:

machine		"i386"
cpu		"I586_CPU"
ident		BISDN
maxusers	64

options		INET			#InterNETworking
options		FFS			#Berkeley Fast Filesystem
options		PROCFS			#Process filesystem
options		"COMPAT_43"		#Compatible with BSD 4.3
options		"SCSI_DELAY=8"		#Be pessimistic about Joe SCSI device
options		UCONSOLE		#Allow users to grab the console
options         IPFIREWALL              #firewall
options         IPFIREWALL_VERBOSE      #print information about
options		TELES_HAS_MEMCPYB	# bisdn 0.97
options		SYSVSHM,SYSVSEM,SYSVMSG	# System V shared memory
options		SHOW_BUSYBUFS		# busy buffers on shutdown ?
options		"I586_OPTIMIZED_BCOPY"
options		"I586_OPTIMIZED_BZERO"
#options	AHC_SCBPAGING_ENABLE
options		AHC_TAGENABLE		# still makes problems with tapes
options		SCSI_REPORT_GEOMETRY
options		MFS			#Memory File System
config		kernel root on sd0 
controller	isa0
controller	pci0
controller	fdc0	at isa? port "IO_FD1" bio irq 6 drq 2 vector fdintr
disk		fd0	at fdc0 drive 0
controller	ahc0
controller	scbus0 at ahc0
disk		sd0 at scbus0 target 0
disk		sd1 at scbus0 target 1
tape		st0 at scbus0 target 4
device		cd0 at scbus0 target 6
options        "MAXCONS=4"
device		sc0	at isa? port "IO_KBD" tty irq 1 vector scintr
device		npx0	at isa? port "IO_NPX" irq 13 vector npxintr
device		sio0	at isa? port "IO_COM1" tty irq 4 vector siointr
device		sio1	at isa? port "IO_COM2" tty irq 3 vector siointr
device		lpt0	at isa? port? tty irq 7 vector lptintr
device		ed0 at isa? port 0x300 net irq 10 iomem 0xcc000 vector edintr
device		joy0	at isa? port "IO_GAME"
pseudo-device	loop
pseudo-device	ether
pseudo-device	log
pseudo-device	tun	1
pseudo-device	pty	16
pseudo-device	bpfilter 4	#Berkeley packet filter
controller	snd0
device sb0	at isa? port 0x220 irq 5 drq 1 vector sbintr
device sbxvi0	at isa? drq 5
device sbmidi0  at isa? port 0x330
device opl0     at isa? port 0x388
# Teles S0/16.3	###################################################### IRQ  9 ##
options		IPI_VJ		# Van Jacobsen header compression support
controller	tel0 at isa? port 0xd80 net irq 9 vector telintr
pseudo-device	disdn
pseudo-device	isdn
pseudo-device	ipi	4
pseudo-device	itel	2
pseudo-device	ispy	1

>Description:

If I enable tagged command queuing in the kernel, then I'm unable to
backup something on my TDC 4222. The mkdump commmand fails like this:

  DUMP: Date of this level 0 dump: Sun Nov 10 10:28:35 1996
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0a (/) to /dev/nrst0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 19161 tape blocks on 0.00 tape(s).
  DUMP:   DUMP: slave couldn't reopen disk: Device not configured
  DUMP: The ENTIRE dump is aborted.
  DUMP: Date of this level 0 dump: Sun Nov 10 10:28:40 1996
  DUMP: Date of last level 0 dump: the epoch
  DUMP: Dumping /dev/rsd0s3f (/var) to /dev/nrst0
  DUMP: mapping (Pass I) [regular files]
  DUMP: mapping (Pass II) [directories]
  DUMP: estimated 21656 tape blocks on 0.00 tape(s).
  DUMP: dumping (Pass III) [directories]
  DUMP:   DUMP: slave couldn't reopen disk: Device not configured
slave couldn't reopen disk: Device not configured
  DUMP: The ENTIRE dump is aborted.
mkdump:: rewinding tape
mt: /dev/rst0: Device busy

On the console the following message will be shown (29 times)
Queue Full
Queue Full
..

Using tar doesn't cause problems...

>How-To-Repeat:

TAPE=/dev/rst0
NTAPE=/dev/nrst0

DUMP="dump 0uBbf 5000000 32 $NTAPE"

echo -n "mkdump:: rewinding tape"
mt -f $TAPE rewind \
        && echo " done."

$DUMP /dev/rsd0a		# root
$DUMP /dev/rsd0s3f		# var

echo -n "mkdump:: rewinding tape"
mt -f $TAPE rewind \
        && echo " done."

>Fix:
	
Workaround: disable tagged command queuing in the kernel.
Since one can use this workaround I choosed priority medium.
But it's a nasty bug, if you have many disks and you want to
make use of the advantages of tagged queuing and you are then
unable to dump the disks...
>Release-Note:
>Audit-Trail:
State-Changed-From-To: open->feedback 
State-Changed-By: joerg 
State-Changed-When: Mon Dec 23 20:04:30 MET 1996 
State-Changed-Why:  
(Note: i've made this PR non-conifential, since it's nothing 
security-related or any other kind of confidential information.) 

Please confirm: does the problem still exist with the recent driver? 

State-Changed-From-To: feedback->open 
State-Changed-By: joerg 
State-Changed-When: Tue Dec 24 11:40:42 MET 1996 
State-Changed-Why:  
> Please confirm: does the problem still exist with the recent driver? 

The problems still arises in -current. 
Exactly this I tried yesterday with a brand new kernel. 
Only one thing changed. The error message: 

sd0(ahc0:0:0) Tagged openings reduced to 3 

This message comes up - nothing more - and the system hangs. 
This happens only with tagged command queuing enabled. 
With or without the compile option AHC_SCBPAGING_ENABLE. 

When using tar as backup tool, this doesn't happen. Or when benching 
SCSI disks using bonnie.  



Responsible-Changed-From-To: freebsd-bugs->gibbs 
Responsible-Changed-By: joerg 
Responsible-Changed-When: Tue Dec 24 11:40:42 MET 1996 
Responsible-Changed-Why:  
Seems like Justin's area. 
State-Changed-From-To: open->feedback 
State-Changed-By: gibbs 
State-Changed-When: Sat Apr 19 08:23:20 PDT 1997 
State-Changed-Why:  
Your problem is probably one of two things: 
1) There was a bug in the driver that was fixed on 4/18/97 that could 
lead to a corrupted input queue to the card meaning that transactions 
could be queued multiple times or a bogus entry could get into the queue. 
Naturatly, this is bad. 

2) Your drive simply cannot handle a large number of tags.  This seems the 
most likely problem as the driver did attempt to reduce the number of 
tags during your dump run.  Dump seems to show these problems much more 
readily than tar due to the way it updates files meaning that lots of 
pending access time updates can be queued at the same time yielding 
lots of transactions.  You can try exprimenting with the number of allowed 
tags in i386/scsi/aic7xxx.c:ahc_done(). 
State-Changed-From-To: feedback->closed 
State-Changed-By: gibbs 
State-Changed-When: Sat Apr 19 15:51:55 PDT 1997 
State-Changed-Why:  
Closed per submitter's request. 
>Unformatted:
