Jason,

This patch looks good to me.  Looking at the HPC3 Datasheet reveals the
reason why this works:

   ch_reset   Channel reset.  Resets both external controller and this DMA
              channel.

Good pickup!  My trusty old Exabyte-8200 drive makes the right noises when
the bus reset is delivered - something that didn't happen during scsi bus
probing before.

If there are no objections I believe this patch should be commited.

As for the CD-ROM not being probed correctly - a little mystery.
I have a similar model (XM-5301 vs your XM-5401) on my SGI machine which
is probed correctly.   Could it be a sector size issue???


Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001
    The NetBSD Foundation, Inc.  All rights reserved.
Copyright (c) 1982, 1986, 1989, 1991, 1993
    The Regents of the University of California.  All rights reserved.

NetBSD 1.5Y (IRIS) #7: Sun Nov 18 15:41:39 NZDT 2001
    wdk@grunt:/home/wdk/netbsd/src/sys/arch/sgimips/compile/IRIS
65536 KB memory, 57588 KB free, 768 KB for ARCS, 3376 KB in 844 buffers
mainbus0 (root): SGI-IP22 [SGI, 6907cc25], 1 processor
cpu0 at mainbus0: MIPS R4400 CPU (0x450) Rev. 5.0 with MIPS R4010 FPC Rev. 0.0
cpu0: 16KB/16B direct-mapped L1 Instruction cache, 48 TLB entries
cpu0: 16KB/16B direct-mapped write-back L1 Data cache
cpu0: 1024KB/128B direct-mapped write-back L2 Unified cache
imc0 at mainbus0 addr 0x1fa00000
imc0: Revision 3
gio0 at imc0
hpc0 at gio0 addr 0x1fb80000
zsc0 at hpc0
zstty0 at zsc0 channel 1 (console i/o)
zstty1 at zsc0 channel 0 (kgdb)
sq0 at hpc0: SGI Seeq 80c03
sq0: Ethernet address 08:00:69:07:cc:25
wdsc0 at hpc0: WD33C93B SCSI, rev=0, target 7
scsibus0 at wdsc0: 8 targets, 8 luns per target
dsclock0 at hpc0 offset 0x60000
biomask 07 netmask 07 ttymask 0f clockmask bf
scsibus0: waiting 5 seconds for devices to settle...
sd0 at scsibus0 target 1 lun 0: <SGI, SEAGATE ST31200N, 9278> SCSI2 0/direct fixed
sd0: 1014 MB, 2700 cyl, 9 head, 85 sec, 512 bytes/sect x 2077833 sectors
sd0: sync (200.0ns offset 12), 8-bit (5.000MB/s) transfers, tagged queueing
sd1 at scsibus0 target 2 lun 0: <DEC, RZ28M    (C) DEC, 0568> SCSI2 0/direct fixed
sd1: 2007 MB, 3045 cyl, 16 head, 84 sec, 512 bytes/sect x 4110480 sectors
sd1: sync (200.0ns offset 12), 8-bit (5.000MB/s) transfers, tagged queueing
sd2 at scsibus0 target 3 lun 0: <DEC, RZ28M    (C) DEC, 0568> SCSI2 0/direct fixed
sd2: 2007 MB, 3045 cyl, 16 head, 84 sec, 512 bytes/sect x 4110480 sectors
sd2: sync (200.0ns offset 12), 8-bit (5.000MB/s) transfers, tagged queueing
sd3 at scsibus0 target 4 lun 0: <SEAGATE, ST51080N, 0958> SCSI2 0/direct fixed
sd3: 1030 MB, 4826 cyl, 4 head, 109 sec, 512 bytes/sect x 2109840 sectors
sd3: sync (200.0ns offset 12), 8-bit (5.000MB/s) transfers, tagged queueing
cd0 at scsibus0 target 5 lun 0: <TOSHIBA, CD-ROM XM-5301TA, 0925> SCSI2 5/cdrom removable
cd0: sync (300.0ns offset 12), 8-bit (3.333MB/s) transfers
st0 at scsibus0 target 6 lun 0: <EXABYTE, EXB-8200, 425A> SCSI1 1/sequential removable
st0: drive empty
st0: async, 8-bit transfers
IPsec: Initialized Security Association Processing.
boot device: sd0
root on sd0a dumps on sd0b


On Sat, 17 Nov 2001, Jason R Thorpe wrote:

> On Fri, Nov 16, 2001 at 06:33:47PM -0700, Michael L. Hitch wrote:
>
>  >   I think I noticed a simliar problem once with the new SCSI driver.  I
>  > seem to remember doing an init, which cleared it up.  The problem is very
>  > likely due to the new SCSI driver negotiating sync transfer mode, and when
>  > rebooting, the device is still sync while the kernel has defaulted to
>  > async.  The 33C93 chip does not appear to have any way to do a SCSI bus
>  > reset (a problem I remember from long ago in the amiga driver as well).  I
>  > would guess that 33C93 designs would need to have additional logic to do a
>  > SCSI bus reset.
>
> So, I looked into this just a little bit.  I have a patch that seems
> to reset the SCSI bus, at least, my devices are detected "reliably" now.
>
> However, my CD-ROM isn't probed properly ... comes up as direct/fixed.
> Weird.

-- 
Wayne Knowles			NetBSD/mipsco port maintainer
wdk@netbsd.org			http://www.netbsd.org