> From: jim@reptiles.org (Jim Mercer)
> Date: Mon, 27 Nov 1995 13:56:45 -0500 (EST)

> hmmm, my sun 3/280 chewed up it's root drive, and since i lent my 
> sunos 4.1.1_u1 tapes to someone, i decided that now was as good a time as
> any to put up netbsd/sun3.
> 
> here's my relevant dmesg info:
> NetBSD 1.1_ALPHA (GENERIC) #68: Fri Nov 17 17:51:26 EST 1995
>     gwr@kanga:/home/gwr/netbsd/work/src/sys/arch/sun3/compile/GENERIC
> Model: Sun 3/260
[...]
> ncr5380_command: short transfer: wanted 10 got 6.
> si(0:0:0)-28,0,0,1c,3e,c0,0,0,20,0-
> 
> i'm in the process of unpacking the source so that i can stress test the
> machine with a full system build.
> 
> however, i'm getting that same error, but it is not a soft error, it
> is a hard error, and causes the console to dump into debug mode.

When you see "wanted 10 got 6" it is not a hard error.  The system
should continue without problem if you enter the "continue" command
at the "db>" prompt.  It was a mistake to leave the debug variable
set which controls this debugger stop.

Here is how you turn off the debugger breaks in the si driver:

# gdb -k --write /netbsd
(kgdb) set ncr5380_debug = 0
(kgdb) quit

> is this because the default 1.1-ALPHA kernel has reselects enabled?

No, it does not even have DMA enabled (so it's slow).

Here is how you turn on DMA and interrupts:
# gdb -k --write /netbsd
(kgdb) set si_options = 3
(kgdb) quit

> can someone get me a kernel with the relects disabled so i can
> move forward?

Not necessary (see above)

> (a slight side issue, i'm using a serial console on this beast, and
> when it kicks into debug mode, the terminal keyboard no longer works,
> i need to poke the reset button on the CPU to get into monitor so i can
> reboot.)

Is the EEPROM set correctly for the serial console?
(I'm puzzled.  Serial console works OK for me...)

> you mention that this is an Emulex problem.  do you mean it is an
> Emulex ESDI/SCSI problem, or is there some Emulex hardware on the VME si
> SCSI controller?

I have only seen this protocol disagreement with the "si" driver
talking to an Emulex SCSI/ESDI target adapter (common on 3/260).
Your "QUANTUM EMPIRE_1080S" appears to have the same problem.

SCSI targets control how many bytes are actually transfered in any
SCSI bus phase, but the "si" driver doesn't trust the target (good
practice) and checks all transfer lengths.  This particular SCSI
command (28: READ_BIG - 4 byte block number) is supposed to be
ten bytes long, but some targets appear to become confused and
assume the command is 6 bytes long like most other commands.
Perhaps they have all they need to reject the command...

Gordon