Subject: Re: problems with >128MB memory?
To: Brian Chase <bdc@world.std.com>
From: Lord Isildur <mrfusion@umbar.vaxpower.org>
List: port-vax
Date: 03/21/2001 13:04:40
hello,

On Wed, 21 Mar 2001, Brian Chase wrote:
> Hehe... wow.  Well for one, I doubt many people here are running
> NetBSD/vax on a system with more than 128MB of RAM.  You lucky b*stard :-)
> What type of system are you running?

it's the 4000/600 i mentioned recently. i just got a 64m board for it 
yesterday, now it has 2 64's and 2 32's. 

> 
> It would probably be helpful if you posted the resulting output from the
> crashed kernel if it generated any.  Did the system crash or did it just
> hang.

it crashed: hered the trace from the kernel db: 
panic: Segv in kernel mode: pc %x addr %x
Stack traceback :
0x94527c2c: _trap+0x1a5(0x94527d00)
0x94527cb4: trap type=0xc code=0x94016657 pc=0x8000085b psl=0x8c00008
0x94527c80: _copyin+0x13(0x94016657,0x7ffff394,0x0)
0x94527d00: _uiomove+0x6b(0x94016657,0xf0,0x0)
0x94527d24: _mmrw+0xf8(0x301,0x94527e88,0x94527de4)
0x94527d60: _spec_read+0x6b(0x0)
0x94527dd0: _nfsspec_read+0x41(0x800394fc)
0x94527e04: _vn_read+0xb2(0x81477bd0,0x94527ef0,0x94527e88,0x8f05bf80,0x6)
0x94527e34: 
_dofileread+0x79(0x8230a1c4,0x4,0x81477bd0,0x7ffff394,0xf0,0x94527ef
0,0x0,0x94016657)
0x94527ea8: _sys_pread+0x9f(0x8230a1c4,0x94527f60,0x7)
0x94527f14: _syscall+0xf5(0x7fffed78)

i halted and rebooted at that point. the offending process was netstat. 
when the system came back up, i ran netstat a few times: 
$ netstat  -s
ip:
        10376687667256583795 total packets received
        10376687675846518389 bad header checksums
        10376687693026387577 with size smaller than minimum
        10376687684436452983 with data size < data length
        10376687899184817833 with length > max ip packet size
(and a lot more of this kind of output- outlandish numbers, basically)
and 
$ netstat
netstat: kvm_read: Bad address

???
netstat: kvm_read: Bad address

(and a few more times of that printed out) 

i'm at work and won't be home til late tonite but anybody have any ideas? 
could it just be the normal kind of mismatches from the kernel being 
compiled from -current and the userland being from the 1.5 sets? 

> 
> Do you know for sure if the memory board you're using is good?  You might
> try pulling the two other boards and running it with just this new board.
> By process of elimination you might be able to find something wrong with
> the board.

the memory passed the tests from the firmware. that isnt necessarily the 
best way to tell but at least i don't _think_ it has any problems. 

> 
> -brian. (dreaming about a nice dual-proc VAX 6000 series with 128MB of RAM)

i got one of them ;-) a 6420, with 288 MB (thats how many XMI slots are
left after 2 processors + XMI dssi + XMI-BI adaptor boards *grin*)
alas, it isnt running. i only got the cardcage and power supplies, etc from
the dude i got it from, and no cabinet and only one of the cooling
fans. I need to build a frame and cabinet for it, and do the 3phase/1phase
conversion before i can run it. i also dont have cab kits for some of the 
stuff, and no docs on how to connect anything back up. unfortunately, 
everything was disconnected when i took the machine apart to fit into my 
trunk 2 years ago, and like a fool i never catalogued what wwnt where. ACK!
considering unix only really is gonna dig one of those processors, 
thats even more room for memory, (i have a couple extra memory boards, since
i got the machine as a 224 meg 6320 and then bought a box of boards some guy
stripped out of a 6420).. Ultrix should run on this machine though, and 
even support both processors. smp ultrix from what i have heard is even 
slower than just disabling the extra processors.. Pitt (my alma mater)'s 
old primary UNIX system was an 8850 and they found it faster to run on
a single processor.. :) 

After seeing the bogus numbers from netstat, i am not so sure it has anything
to do with the >128 megs so much as with some other improper getting of 
information from the kernel.. 


isildur