Subject: 1.4_ALPHA troubles...
To: None <port-i386@netbsd.org>
From: Dave Huang <khym@bga.com>
List: port-i386
Date: 04/03/1999 01:42:32
1.4_ALPHA from April 2 source is very unstable on my 8MB 386 :( It seems
to be working fine on my 80 and 128MB machines though, so the bug
probably has to do with low memory and paging...

My system:

NetBSD 1.4_ALPHA (SLOTH) #190: Sat Apr  3 00:17:31 CST 1999
    khym@dahan.metonymy.com:/usr/src.local/sys/arch/i386/compile/SLOTH
cpu0: Intel 386DX (386-class)
real mem  = 7995392
avail mem = 5664768
using 123 buffers containing 503808 bytes of memory
mainbus0 (root)
isa0 at mainbus0
ne0 at isa0 port 0x300-0x31f irq 10
ne0: NE2000 Ethernet
ne0: Ethernet address 00:40:05:62:d5:28
com0 at isa0 port 0x3f8-0x3ff irq 4: ns16550a, working fifo
com0: console
com1 at isa0 port 0x2f8-0x2ff irq 3: ns16550a, working fifo
wdc0 at isa0 port 0x1f0-0x1f7 irq 14
wd0 at wdc0 channel 0 drive 0: <QUANTUM LP120A GM120A01X>
wd0: drive supports 8-sector pio transfers, chs addressing
wd0: 116MB, 901 cyl, 5 head, 53 sec, 512 bytes/sect x 238765 sectors
wd1 at wdc0 channel 0 drive 1: <MICROSCIENCE>
wd1: drive supports 1-sector pio transfers, chs addressing
wd1: 102MB, 855 cyl, 7 head, 35 sec, 512 bytes/sect x 209475 sectors
tcom0 at isa0 port 0x100-0x13f irq 11
com2 at tcom0 slave 0: st16650a, working fifo
com3 at tcom0 slave 1: st16650a, working fifo
com4 at tcom0 slave 2: st16650a, working fifo
com5 at tcom0 slave 3: st16650a, working fifo
com at tcom0 slave 4 not configured
com at tcom0 slave 5 not configured
com at tcom0 slave 6 not configured
com at tcom0 slave 7 not configured
lpt0 at isa0 port 0x378-0x37b irq 7
pc0 at isa0 port 0x60-0x6f irq 1: mono
fdc0 at isa0 port 0x3f0-0x3f7 irq 6 drq 2
fd0 at fdc0 drive 0: 1.44MB, 80 cyl, 2 head, 18 sec
biomask 4040 netmask 4440 ttymask 44c2
boot device: wd0
root on wd0a dumps on wd0b
IP Filter: initialized.  Default = pass all, Logging = enabled
uvm_fault(0xf026f470, 0xdeadb000, 0, 3) -> 5
fatal page fault in supervisor mode
trap type 6 code f1b20002 eip f0128772 cs f0250008 eflags 10282 cr2 deadbef3 cpl e00044c2
panic: trap
syncing disks... 10 10 7 3 done

BTW, is there any way to get gdb to give a stack trace past trap()? I
got the rest of the stack by following the frame pointers manually...

(gdb) where
#0  0x0 in ?? ()
#1  0xf02eb000 in ?? ()
#2  0xf0224c1d in cpu_reboot (howto=0x100, bootstr=0x0)
    at ../../../../arch/i386/i386/machdep.c:1350
#3  0xf01288a7 in panic (fmt=0xf0230f26 "trap")
    at ../../../../kern/subr_prf.c:212
#4  0xf02311d8 in trap (frame={tf_es = 0xf0270010, tf_ds = 0xf1b20010, 
      tf_edi = 0x0, tf_esi = 0xf0313050, tf_ebp = 0xf1b23f28, 
      tf_ebx = 0xf0270b04, tf_edx = 0xf0313190, tf_ecx = 0x35b60, 
      tf_eax = 0xdeadbeef, tf_trapno = 0x6, tf_err = 0xf1b20002, 
      tf_eip = 0xf0128772, tf_cs = 0xf0250008, tf_eflags = 0x10282, 
      tf_esp = 0xf021de54, tf_ss = 0xf0111088, tf_vm86_es = 0x0, 
      tf_vm86_ds = 0xf1b23f54, tf_vm86_fs = 0xf01285e1, 
      tf_vm86_gs = 0xf0270b04}) at ../../../../arch/i386/i386/trap.c:310

0xf0128722 is in pr_rmpage (../../../../kern/subr_pool.c:232).
0xf01285e1 is in pool_reclaim (../../../../kern/subr_pool.c:1200).
0xf0128650 is in pool_drain (../../../../kern/subr_pool.c:1230).
0xf0219d33 is in uvm_pageout (../../../../uvm/uvm_pdaemon.c:268).
0xf0111090 is in start_pagedaemon (../../../../kern/init_main.c:583).


-- 
Name: Dave Huang     |   Mammal, mammal / their names are called /
INet: khym@bga.com   |   they raise a paw / the bat, the cat /
FurryMUCK: Dahan     |   dolphin and dog / koala bear and hog -- TMBG
Dahan: Hani G Y+C 23 Y++ L+++ W- C++ T++ A+ E+ S++ V++ F- Q+++ P+ B+ PA+ PL++