Hi!

I'm new to this list and decided a few days ago, after
realizing that NG1 support works, to try out the latest
NetBSD release on my Indy for the first time. hinv output:

              System: IP22
           Processor: 100 MHz R4000, with FPU
Primary I-Cache size: 8 Kbytes
Primary D-Cache size: 8 Kbytes
Secondary Cache size: 1024 Kbytes
         Memory size: 160 Mbytes
            Graphics: Indy 24-bit
           SCSI Disk: scsi(0)disk(6)
               Audio: Iris Audio Processor: version A2 revision 4.1.0

The system was running Irix 5.3 for the last years and never
had any problems. The hardware should be stable and reliable.

My main problem is that many (most? all?) NetBSD programs tend
to cause a segmentation fault. For example, when typing "w"
30 times, I will get 26 successful executions and 4 times a
segmentation fault (occurence is total random). This is only
an example and probably valid for all programs (segmentation
faults seen with "df", "gcc", "ls", "rm", "sed", etc..).

Often it already segfaults one or several times during booting
into multiuser mode. Sometimes is boots without crashing.

Inspecting such a core dump with gdb always leads to the same
result: the program pointer is in illegal address space
(at least I believe so). The address is always 0x5ffe????.

Example: gdb /usr/bin/w w.core
---8<---
GNU gdb 5.3nb1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you ar=
e
welcome to change it and/or distribute copies of it under certain condition=
s.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "mipseb--netbsd"...(no debugging symbols found).=
=2E.
Core was generated by `w'.
Program terminated with signal 11, Segmentation fault.

    GDB is unable to find the start of the function at 0x5ffe5734
and thus can't determine the size of that function's stack frame.
This means that GDB may be unable to access that stack frame, or
the frames below it.
    This problem is most likely caused by an invalid program counter or
stack pointer.
    However, if you think GDB should simply search farther back
from 0x5ffe5734 for code which looks like the beginning of a
function, you can increase the range of the search using the `set
heuristic-fence-post' command.
#0  0x5ffe5734 in ?? ()
(gdb)=20
---8<---

It seems that it only occurs when a new program is started. Once
a program is running, it will never crash.

The "dmesg" output of my Indy:
---8<---
Copyright (c) 1996, 1997, 1998, 1999, 2000, 2001, 2002, 2003, 2004
    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 2.0_RC4 (GENERIC32_IP2x) #0: Mon Oct 18 21:50:39 UTC 2004
        autobuild@tgm.netbsd.org:/autobuild/netbsd-2-0/sgimips/OBJ/autobuil=
d/netbsd-2-0/src/sys/arch/sgimips/compile/GENERIC32_IP2x
total memory =3D 160 MB
(768 KB reserved for ARCS)
avail memory =3D 151 MB
mainbus0 (root): SGI-IP22 [SGI, 69083e9f], 1 processor
cpu0 at mainbus0: MIPS R4000 CPU (0x422) Rev. 2.2 with MIPS R4010 FPC Rev. =
0.0
cpu0: 8KB/16B direct-mapped L1 Instruction cache, 48 TLB entries
cpu0: 8KB/16B direct-mapped write-back L1 Data cache
cpu0: 1024KB/128B direct-mapped write-back L2 Unified cache
ioc0 at mainbus0 addr 0x1fbd9800: rev 0, machine Indy (Guiness), board rev =
0
int0 at mainbus0 addr 0x1fbd9880: bus 50MHz, CPU 100MHz
imc0 at mainbus0 addr 0x1fa00000: revision 3
gio0 at imc0
newport0 at gio0 slot 2 addr 0x1f000000: SGI NG1 (board revision 5, cmap re=
vision 5, xmap revision 5, vc2 revision 0), depth 8
wsdisplay0 at newport0 kbdmux 1: console (1280x1024, vt100 emulation)
wsmux1: connecting to wsdisplay0
hpc0 at gio0 addr 0x1fb80000: SGI HPC3
zsc0 at hpc0 offset 0x59830
zstty0 at zsc0 channel 1
zstty1 at zsc0 channel 0
pckbc0 at hpc0 offset 0x59840
pckbd0 at pckbc0 (kbd slot)
wskbd0 at pckbd0: console keyboard, using wsdisplay0
pms0 at pckbc0 (aux slot)
wsmouse0 at pms0 mux 0
sq0 at hpc0 offset 0x54000: SGI Seeq 80c03
sq0: Ethernet address 08:00:69:08:3e:9f
wdsc0 at hpc0 offset 0x44000: WD33C93B SCSI, rev=3D0, target 0
scsibus0 at wdsc0: 8 targets, 8 luns per target
dsclock0 at hpc0 offset 0x60000
haltwo0 at hpc0 offset 0x58000: HAL2 revision 4.1.0
audio0 at haltwo0: half duplex
biomask 07 netmask 07 ttymask 0f clockmask bf
scsibus0: waiting 2 seconds for devices to settle...
sd0 at scsibus0 target 6 lun 0: <IBM, DCAS-34330, S65A> disk fixed
sd0: 4134 MB, 8205 cyl, 6 head, 171 sec, 512 bytes/sect x 8467200 sectors
sd0: sync (200.00ns offset 12), 8-bit (5.000MB/s) transfers, tagged queuein=
g
boot device: sd0
root on sd0a dumps on sd0b
root file system type: ffs
---8<---


Some more points which I realized during testing:

- Some PROM variables were changed after installation, but not
  enough to make NetBSD start.
  "OSLoader" was still set to "sash", which failed. Had to replace
  it with "boot".

- When booting the system for the first time, it didn't seem
  to like some superblocks which the installer generated?
  ---8<---
  Checking for botched superblock upgrades
  Reparing partition /dev/rsd0a
  Alternate super block location: 16
  DOWNGRADING TO OLD SUPERBLOCK LAYOUT
  ---8<---
  This never happened again, though.

- The NG1 driver places the cursor one position to the left
  besides the correct one. When I type a character I can't see
  it, because the cursor will appear immediately over it. ;)
  My graphics card is reported a "depth 8", although it's 24 bit.
  Maybe this has something to do with it?

- "poweroff" works, but the Indy's shutdown-melody is destroyed.
  I hear a loud random noise.


--=20
   _  Frank Wille (frank@phoenix.owl.de)
_ //  http://devnull.owl.de/~frank/
\X/   Phx @ #AmigaGer