All,

Here's my working-list of issues with the NetBSD/sgimips port.

In particular, I'd like to draw attention to the CDROM issue
on Indigo 2 machines.  If you have an Indigo 2 with a CD attached,
I'd like to find out if you're able to boot the sgimips snapshot
CD distribution on it.  If you're able to test this on any CDROMs
not listed, please let me know if it works and, if not, what the
resulting errors were.

Also, if someone could take a peek at the boot code, item #4 is
particularly annoying.  My workaround is truly a lame hack.  I
am losing synapses elsewhere, so I won't be addressing this any
time soon.

Thanks and regards,
-scott
-----------------------------------------------------------------
1)	Fixed >1 SCSI bus root boot partition identification
	Patch follows:

	(send-pr submitted 20020430)

Index: sys/arch/sgimips/sgimips/autoconf.c
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/sgimips/sgimips/autoconf.c,v
retrieving revision 1.8
diff -r1.8 autoconf.c
181c181,182
< 		booted_controller = dev;
---
> 		if (dev->dv_unit == booted_slot)
> 			booted_controller = dev;

2)	the md(4) device does not work properly on NFS-mounted
	filesystems:

	(Recently reported by another.  Appears to be a cross-platform
	issue--not just MIPS.  See:
	http://mail-index.netbsd.org/netbsd-bugs/2002/04/29/0018.html)

	mod81# dd if=/dev/zero count=6144 of=test.fs
	6144+0 records in
	6144+0 records out
	3145728 bytes transferred in 3.483 secs (903166 bytes/sec)
	mod81# vnconfig -v -c vnd0 test.fs
	/dev/rvnd0c: 3145728 bytes on test.fs
	mod81# disklabel -w -f disktab.ramdisk vnd0 install-ramdisk
	mod81# newfs -B le -m 0 -o space -i 5120 /dev/rvnd0a
	/dev/rvnd0a:    6144 sectors in 128 cylinders of 3 tracks, 16 sectors
        	3.0MB in 1 cyl groups (296 c/g, 6.94MB/g, 608 i/g)
	super-block backups (for fsck -b #) at:
 	32,
	cg 0: bad magic number

	mod81# cat disktab.ramdisk
	install-ramdisk:3MB Installation Ramdisk:\
        	:ty=simulated:se#512:nt#3:ns#16:nc#128:\
        	:ta=4.2BSD:\
        	:pa#6144:oa#0:ba#4096:fa#512:\
        	:pb#0:ob#0:\
        	:pc#6144:oc#0:

	Note1: Copying this same test.fs image to a locally-mounted
		filesystem, then performing the newfs from there, works
		fine.
	Note2: Generating and newfs'ing the test.fs on a locally-mounted 
		filesystem, copying the test.fs to an NFS-mounted filesystem
		then newfs'ing there works fine.

3)	The Indigo 2 seems somewhat particular about CDROM brands and models
	that the PROM will boot (at least with mine).  The PROM will load the 
	boot block successfully, but calls to the PROM "Seek" code by the boot
	program fail.

	Note that the SGI PROMs don't seem to be particular about sector size.

	Compatible:
		Matsushita CR-503-B
		Matsushita CR-503-C (Badged AppleCD 300Plus)
		Matsushita CR-508-B 
		Sony CDU76S
		Toshiba XM-3401TA (Reported by Pascal Dameme)
		Toshiba XM-4101B (Badged DEC RRD43-AA, Jumper IN for DEC mode,
				  Reported by Scott Taylor)

	Incompatible:
		DEC RRD42-AA
		Matsushita CR-503-K (Badged AppleCD 300i Plus - Scott Taylor)
		Matsushita CR-504-B
		Matsushita CR-504-K (Badged AppleCD 600i - Scott Taylor)
		Toshiba XM-4101B (OEM, Reported by Scott Taylor)
		Toshiba XM-4101B (Badged DEC RRD43-AA, Jumper OUT for PC mode,
				  Reported by Scott Taylor)
		Toshiba XM-5301B
		Toshiba XM-5401B 

	All the drives worked fine under NetBSD/sgimips.  The issue only
	arises when attempting to boot from a bootable CDrom distribution.
		
4)	In the boot code (sys/arch/sgimips/boot/common/boot.c), the
	first initalised code defined in the segment is being clobbered.
	This was discovered when trying to reference the kernelnames
	structured defined there:

	char *kernelnames[] = {
        	"Xnetbsd.sgimips",
        	"Xnetbsd",
        	"Xnetbsd.gz",
		...

	References to kernelnames[0] returned garbage.  References
	to [1] and further were fine.

	The code was changed to "static const char * const ..." which
	effectively moved it elsewhere, but then any following definitions
	not declared static were then clobbered.

	The hack is to put a dummy allocation at the top of the code:

		char *hack[] = {
			"test1234567890",
			"test1234567890",
			"test1234567890",
			"test1234567890",
			"test1234567890",
			NULL};

	And, sure enough, checking hack[0] when boot runs shows the data
	munged.

	Beats me what's really going on here for now, but it gets me 
	what I want.

5)	Panic reported, on a quiet system... Connections to the machine
	timed out at 03h30, so the panic may have happened when /etc/daily
	was run at 03h15.  I have run /etc/daily manually with success, so
	I don't believe that to be the cause.

	On console:

panic: kernel diagnostic assertion "umap->refcount != 0" failed: file
"/sys/arch/sgimips/compile/GENERIC_L2/../../../../uvm/uvm_bio.c", line 253

Stopped in pid 21887 (netstat) at       cpu_Debugger+0x4:       jr      ra
                bdslot: nop
db> c
syncing disks... 

<<< VOLUME-DOWN button pushed after about 5 minutes >>>
hpc_power_intr: panel reg = c3c3c3c3
halting...

sc0,1,0: cmd=0x12 timeout after 2 sec.  Resetting SCSI bus
<<< Disks were dirty >>>

6)      Occasional (seeming benign) pmap_unwire console message.
 
Apr 27 12:46:37 mod81 /netbsd: pmap_unwire: wiring for pmap 0x88cce4e0 va 0x7fffc000 didn't change!

7)	Interactive boot program under development.

	To facilitate the dozens of reboots and boot-drive changes I make
	daily, I've rewritten the boot program used for sgimips to
	implement an interactive boot process modeled after the NetBSD/i386
	functionality.  Interactive mode can be entered by pressing any
	key within the timeout period, currently 5 seconds.  Booting can
	occur immediately by pressing ENTER.

	This boot program, along with mods to machdep.c, implements 
	functionality to implement boot flags for RB_ASKNAME, RB_VERBOSE
	(not really implemented in the kernel really) and more control
	over booting multi-user.

	The boot program will also jump immediately into interactive mode
	when booted with '-i':  >> boot --i

	argc and argv are modified by the boot program and sent to the kernel.

	While I'm not expecting to replace the current boot program in the
	cvs tree, this version has proven quite valuable for my development.
	I will include this as an alternate boot in my snapshots.

	A brief interactive log follows:

>> boot -f bootp():/abyss/indy/bootZ
Setting $netaddr to 198.182.227.85 (from server 198.182.227.1)
Obtaining /abyss/indy/bootZ from server 198.182.227.1
52992+0+3536 entry: 0x89000000

NetBSD/sgimips 1.5ZC Interactive Bootstrap, Revision 2.02
(root@mod81, Fri Apr 26 00:38:49 CDT 2002)

Press return to boot now, any other key for boot menu
booting scsi(0)disk(1)rdisk(0)partition(0)/netbsd --- starting in 0 
Key pressed -- Entering Interactive Mode.
Type "?" or "help" for help.
boot> help
Commands are:
   boot [scsi(N)disk(N)rdisk(N)partition(N)][filename] [-aqsv]
        (ex. "scsi(0)disk(1)rdisk(0)partition(0)netbsd.old -s"
   ls [scsi(N)disk(N)rdisk(N)partition(N)][directory]
   dev [scsi(N)disk(N)rdisk(N)partition(N)]
   set [boot_single|boot_auto|verbose|flags FLAGS]
   unset [boot_single|boot_auto|verbose|flags]
   args
   help|?
   quit|halt|exit|reboot
boot> args
Current kernel environment:
    argv[0] = bootp():/abyss/indy/bootZ
    argv[1] = ConsoleIn=serial(0)
    argv[2] = ConsoleOut=serial(0)
    argv[3] = SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
    argv[4] = OSLoader=boot2
    argv[5] = OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
    argv[6] = OSLoadFilename=/netbsd
boot> set boot_auto
boot> args
Current kernel environment:
    argv[0] = bootp():/abyss/indy/bootZ
    argv[1] = ConsoleIn=serial(0)
    argv[2] = ConsoleOut=serial(0)
    argv[3] = SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
    argv[4] = OSLoader=boot2
    argv[5] = OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
    argv[6] = OSLoadFilename=/netbsd
    argv[7] = OSLoadOptions=auto
boot> set boot_single
boot> args
Current kernel environment:
    argv[0] = bootp():/abyss/indy/bootZ
    argv[1] = -s <<< Note: my machdep.c overrides OSLoadOptions with this >>>
    argv[2] = ConsoleIn=serial(0)
    argv[3] = ConsoleOut=serial(0)
    argv[4] = SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
    argv[5] = OSLoader=boot2
    argv[6] = OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
    argv[7] = OSLoadFilename=/netbsd
    argv[8] = OSLoadOptions=auto
boot> ls
devopen: scsi(0)disk(1)rdisk(0)partition(0) type scsi file /
2: . (DIR)
2: .. (DIR)
8832: usr (DIR)
17664: etc (DIR)
26496: kern (DIR)
89: netbsd (REG)
4: netbsd.ecoff (REG)
35328: altroot (DIR)
35329: bin (DIR)
17666: dev (DIR)
8833: home (DIR)
26497: mnt (DIR)
8834: root (DIR)
26498: sbin (DIR)
5: stand (DIR)
6: tmp (DIR)
7: var (DIR)
42: .cshrc (REG)
43: .profile (REG)
75: sys (LNK)
3: netbsd.OK (REG)
88: netbsd2.ecoff (REG)
boot> boot -abcdefgh
Loading scsi(0)disk(1)rdisk(0)partition(0)/netbsd
devopen: scsi(0)disk(1)rdisk(0)partition(0) type scsi file /netbsd
1503872+362156 [61952+51179]=0x1e352c
Starting at 0x88069000

nsym 0x1 ssym 0x8823092c esym 0x8824c52c
Found bootinfo at 0x8900cfc0
zs channel 0 had address 0xbfbd9830
argv[0]: bootp():/abyss/indy/bootZ
argv[1]: -abcdefgh
argv[2]: ConsoleIn=serial(0)
argv[3]: ConsoleOut=serial(0)
argv[4]: SystemPartition=scsi(0)disk(1)rdisk(0)partition(8)
argv[5]: OSLoader=boot2
argv[6]: OSLoadPartition=scsi(0)disk(1)rdisk(0)partition(0)
argv[7]: OSLoadFilename=/netbsd
argv[8]: OSLoadOptions=auto

8)	Frequent ether collision messages.

	I'm sure I work my machines more than most currently using the
	NetBSD/sgimips port.  I am doing constant builds of NetBSD as
	well as generating precompile packages--all over NFS.
	As a result, I see 100's of the following messages daily:

	sq0: max collisions reached

	I don't know if this is a Good Thing, an issue to be investigated,
	or just over-reporting of a full driver queue.  I have never seen
	any negative impact from the messages.