Subject: Re: New -current SCSI integrated support - how?
To: None <port-sparc@NetBSD.ORG>
From: Chuck Cranor <chuck@dworkin.wustl.edu>
List: port-sparc
Date: 01/09/1995 23:09:07
>OK, I haven't looked that hard, but it would appear that the SPARC port is now
>using the "mainline" SCSI code, and thus now support extra goodies like maybe
>my CD-ROM drive and my 5 Gb Exabyte (yes?).

hi-

   support has gotten somewhat better for tape.   a kernel from 
December would see my 1/4" cartridge tape drive but it wouldn't work.
today's -current kernel will read and write the tape.   however,
it also generates kernel error messages and if you generate a SIGINT
in the middle of a tape operation you may crash the machine.  (I 
crashed my 4/370 with a DMAWAIT1 panic...)   There were also long
delays at the start up and stop of the "tar" process (prob. as it
opened and closed the tape device).

   SCSI disk support seems to still have problems.   I am still
trying to get more details on what is going on.   Here is some
*preliminary* info:  

[1] One of my friends has a set of programs that he runs on our 
	ss1 which causes the kernel to hang (only L1-a will break it).   
	If I do a "ctrace" at the "ok" prompt and get a stack trace and 
	use SunOS adb to generate debug info I get:

	_zsabort+0x10:  call    _callrom
	_zswrite+0x330: call    _zsabort
	_zswrite+0x94:  call    _zswrite + 0x2b4
	_sparc_interrupt+0x104:         jmpl    %o1, %o7
	_vm_page_deactivate+0xbc:       call    _pmap_is_modified
	_vm_pageout_scan+0x1e4:         call    _vm_page_deactivate
	_vm_pageout+0x164:              call    _vm_pageout_scan
	_main+0x4f0:    call    _vm_pageout
	_getidprom+0x2e0:               call    _main

	When this happens the disk is continuously making "lots of noise."
	The same application works just fine when run on a diskless sun-4/330.
	The problem appears to be related to heavy paging activity to a
	SCSI disk.

[2] Another friend of mine has a 4/300 with 3 disks and a CD ROM on it and the
	SCSI code is not autoconfiging properly.   It sees one disk twice
	and totally misses another.    Here is some output from autoconfig:

	SunOS autoconfig:
	sm0 at obio 0xfa000000 pri 2 
	st0 at sm0 slave 32
	st1 at sm0 slave 40
	st2 at sm0 slave 24
	st3 at sm0 slave 16
	sr0 at sm0 slave 48
	sd0 at sm0 slave 0
	sd0:  <SEAGATE-ST12550N-0014 cyl 2706 alt 2 hd 19 sec 81>
	sd1 at sm0 slave 1
	sd2 at sm0 slave 8
	sd2:  <SUN0669 cyl 1614 alt 2 hd 15 sec 54>
	sd3 at sm0 slave 9
	sd4 at sm0 slave 16
	sd6 at sm0 slave 24
	sd6:  <CDC Wren IV 94171-344 cyl 1545 alt 2 hd 9 sec 46>

	NetBSD-current autoconfig:
	dma0 at obio0 addr fa001000: rev 0
	esp0 at obio0 addr fa000000 pri 4: ESP100 24Mhz, target 7
	scsibus0 at esp0
	esp0 targ 0 lun 0: <SEAGATE, ST12550N, 0014> SCSI2 0/direct fixed
	sd0 at scsibus0: 2040MB, 2708 cyl, 19 head, 81 sec, 512 bytes/sec
	esp0 targ 1 lun 0: <MICROP, 1588-15MBSUN0669, SN0B> SCSI1 0/direct fixed
	sd1 at scsibus0: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sec
	esp0 targ 3 lun 0: <MICROP, 1588-15MBSUN0669, SN0B> SCSI1 0/direct fixed
	sd2 at scsibus0: 639MB, 1632 cyl, 15 head, 53 sec, 512 bytes/sec
	esp0 targ 6 lun 0: <TOSHIBA, CD-ROM XM-3401TA, 2873> SCSI2 5/cdrom removable
	cd0 at scsibus0: cd present, 1290948 x 512 byte records

	It isn't clear to me why the MICROP disk is showing up twice,
	and the Wren IV seems to have vanished.

[3] I haven't tried this since December, but a December based -current
	kernel would panic in SCSI autoconfig on my ss2 (but would run on
	a ss1).   I need to recheck this with a more recent kernel.

Is anyone else seeing these problems?

Chuck

ps- here is a script with the SCSI tape stuff in action.   It generates
more error messages on the console (which I don't have access to at the
moment):

Script started on Mon Jan  9 19:56:03 1995
Warning: exported path contains relative components.
yikes# tar cvf /dev/rst0 .
./
.cshrc
.klogin
.login
.profile
typescript
tar: can't write to /dev/rst0 : Input/output error
yikes# tail /var/log/messages
Jan  9 19:46:26 yikes /netbsd: st0 at scsibus0: density code 0x0, 512-byte blocks, write-enabled
Jan  9 19:46:26 yikes /netbsd: le0 at obio0 addr f9000000 pri 6: hardware address 08:00:20:07:a8:3e
Jan  9 19:46:26 yikes /netbsd: vmel0 at mainbus0
Jan  9 19:46:26 yikes /netbsd: vmes0 at mainbus0
Jan  9 19:46:24 yikes savecore: no core dump
Jan  9 19:46:29 yikes lpd[92]: restarted
Jan  9 19:46:34 yikes init: kernel security level changed from 0 to 1
Jan  9 19:55:54 yikes su: chuck to root on /dev/ttyp0
Jan  9 19:56:23 yikes /netbsd: st0(esp0:4:0): illegal request
Jan  9 19:56:23 yikes /netbsd: st0: cannot set selected mode
yikes# !tar
tar cvf /dev/rst0 .
./
.cshrc
.klogin
.login
.profile
typescript
yikes# tar tvf /dev/rst0
drwxr-xr-x root/wheel        0 Jan  9 19:56 1995 ./
-rw-r--r-- root/wheel      653 Aug  2 23:04 1994 .cshrc
-rw-r--r-- root/wheel       62 Jul  2 13:45 1994 .klogin
-rw-r--r-- root/wheel       51 Jul  2 13:45 1994 .login
-rw-r--r-- root/wheel      140 Jul  2 13:45 1994 .profile
-rw-r--r-- root/wheel        0 Jan  9 19:56 1995 typescript
yikes# dmesg | tail -11
esp0 at obio0 addr fa000000 pri 4: ESP100 24Mhz, target 7
scsibus0 at esp0
esp0 targ 0 lun 0: <CDC, 94171-9, 0045> SCSI1 0/direct fixed
sd0 at scsibus0: 312MB, 1549 cyl, 9 head, 45 sec, 512 bytes/sec
esp0 targ 4 lun 0: <ARCHIVE, VIPER 150  21531, -003> SCSI1 1/sequential removable
st0 at scsibus0: density code 0x0, 512-byte blocks, write-enabled
le0 at obio0 addr f9000000 pri 6: hardware address 08:00:20:07:a8:3e
vmel0 at mainbus0
vmes0 at mainbus0
st0(esp0:4:0): illegal request
st0: cannot set selected mode
yikes# ^D
Script done on Mon Jan  9 19:58:08 1995
-- 
Chuck Cranor, Graduate Student
Computer and Communications Research Center
Washington University, St. Louis MO  USA
E-Mail: chuck@maria.wustl.edu / cranor@udel.edu