>Number:         29603
>Category:       kern
>Synopsis:       esiop has problems with scsi request ioctl
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Mar 05 18:11:00 +0000 2005
>Originator:     john heasley
>Release:        NetBSD 2.99.16
>Organization:
	
>Environment:
	
	
System: NetBSD guelah 2.99.16 NetBSD 2.99.16 (andreynonfs) #9: Sat Mar 5 17:21:06 UTC 2005 heas@guelah:/sys/arch/sparc64/compile/andreynonfs sparc64
Architecture: sparc64
Machine: sparc64
>Description:
I have a daemon which monitors a chaparral SCSI RAID box that presents
itself as a SCSI processor.

uk0 at scsibus1 target 0 lun 6: <CNSi, K5412, K410> processor fixed
uk0: sync (25.00ns offset 31), 16-bit (80.000MB/s) transfers, tagged queueing

esiop1 at pci2 dev 8 function 1: Symbios Logic 53c896 (ultra2-wide scsi)
esiop1: using on-board RAM
esiop1: interrupting at ivec 20
scsibus1 at esiop1: 16 targets, 8 luns per target

When the monitoring daemon starts, the box panics.  One of the first things
it does is issue a SCSI inquiry.  I do not know if that is what triggers the
failure, it is just a data-point.

If the siop driver is used instead, everything works fine.

siop1 at pci2 dev 8 function 1: Symbios Logic 53c896 (ultra2-wide scsi)
siop1: using on-board RAM
siop1: interrupting at ivec 20
scsibus1 at siop1: 16 targets, 8 luns per target

data fault: pc=10af8e8 addr=0
kernel trap 30: data access exception 
Stopped in pid 343.1 (crd) at   netbsd:esiop_start+0x284:       ldx
[ %g3 + 0x10], %g2
db> bt 
esiop_scsipi_request(468ec00, 46d2e40, 3ec6700, 0, 3ec6700, 0) at netbsd:esiop_scsipi_request+0x4a8
scsipi_run_queue(468ec60, 3ec67ca, ffffffffffffffff, 3ec67c4, 0, 3ec67c4) at netbsd:scsipi_run_queue+0x170
scsipi_execute_xs(3ec6700, 3f26118, 6, 0, 0, 0) at netbsd:scsipi_execute_xs+0x200
scsistrategy(3f26010, 3f26108, 78, 3f26108, 0, 2710) at netbsd:scsistrategy+0xd0
scsipi_do_ioctl(19, 3c00, 3f26108, e77fc10, 3f26000, e794c30) at netbsd:scsipi_do_ioctl+0x184
spec_ioctl(6, 40715c59, 65, 65, 40715c52, 40704b50) at netbsd:spec_ioctl+0x58
VOP_IOCTL(ee4e7d0, c0785101, e77fc10, 3, ddc0000, e794c30) at netbsd:VOP_IOCTL+0x38
vn_ioctl(dde6d20, c0785101, e77fc10, e794c30, 100a14c, 0) at netbsd:vn_ioctl+0xb0
sys_ioctl(c0785101, e77fdd0, e77fdc0, 0, e77fdd0, 0) at netbsd:sys_ioctl+0xe8
syscall(e77fed0, 36, 40737070, e77fdd0, 40737070, 40737074) at netbsd:syscall+0xd4
?(3, c0785101, 211628, 214bb8, 0, 211638) at 0x1008cb8
db> show registers
tstate      0x1d000604
pc          0x10af8e8   esiop_start+0x284
npc         0x10af8ec   esiop_start+0x288 
ipl         0x5
y           0
g0          0
g1          0
g2          0xc0
g3          0
g4          0x700
g5          0x1800000
g6          0x3000000000000000 
g7          0x1099e8
o0          0x889907c0
o1          0x44a0c88
o2          0x46c9380
o3          0x1988
o4          0xac
o5          0x5
o6          0xe77eb61
o7          0x10af8d8   esiop_start+0x274

(gdb) list *0x10af8e8 
0x10af8e8 is in esiop_start (../../../../dev/ic/esiop.c:1746).
1741                    panic("esiop_start: bad status");
1742            /* DSA table for reselect */
1743            if (esiop_cmd->cmd_c.flags & CMDFL_TAG) {
1744                    esiop_lun->tactive[esiop_cmd->cmd_c.tag] = esiop_cmd;
1745                    /* DSA table for reselect */
1746                    esiop_lun->lun_tagtbl->tbl[esiop_cmd->cmd_c.tag] =
1747                        htole32(esiop_cmd->cmd_c.dsa);
1748                    bus_dmamap_sync(sc->sc_c.sc_dmat,
1749                        esiop_lun->lun_tagtbl->tblblk->blkmap,
1750                        esiop_lun->lun_tagtbl->tbl_offset,

>How-To-Repeat:
	
>Fix:
I have not had time to look.  I will, if no one gets to it before me. :)

>Unformatted: