Very Computer

Here's what it said. Any ideas? I still have the coredump in case
that's useful....

Fatal trap 12: page fault while in kernel mode
fault virtual address    = 0x3c
fault code               = supervisor read, page not present
instruction pointer      = 0x8:0xf0165167
code segment             = base 0x0, limit 0xfffff, type 0x1b
                 = DPL 0, pres 1, def32 1, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process          = 25991 (smail)
interrupt mask           =
panic: page fault

syncing disks... 16 16 15 11 5 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 giving up

dumping to dev 1, offset 57344
dump 11 10 9 8 7 6 5 4 3 2 1

Here's the backtrace from the coredump.

IdlePTD 1bb000
current pcb at 1ace18
panic: page fault
#0  0xf017ac49 in boot ()
(kgdb) bt
#0  0xf017ac49 in boot ()
#1  0xf01134c3 in panic ()
#2  0xf017face in trap_fatal ()
#3  0xf017f640 in trap_pfault ()
#4  0xf017f2df in trap ()
#5  0xf017846d in calltrap ()
#6  0xf0165167 in ufs_direnter ()
#7  0xf0169182 in ufs_makeinode ()
#8  0xf0166ac5 in ufs_create ()
#9  0xf012d9ee in vn_open ()
#10 0xf012ae53 in open ()
#11 0xf017fd13 in syscall ()
#12 0xf01784bb in Xsyscall ()
#13 0x2ee23 in ?? ()
#14 0x26c82 in ?? ()
#15 0x13f6d in ?? ()
#16 0x158c3 in ?? ()
#17 0x15702 in ?? ()
#18 0x11be0 in ?? ()
#19 0x10d3 in ?? ()

Quote:>Here's what it said. Any ideas? I still have the coredump in case
>that's useful....

What hardware are you using?  If it's an AHA294X, then you need to
upgrade to -stable.  If not, then knowing your hardware is still a good
thing.

Nate
--


work #: (406) 449-7662 | Montana.
home #: (406) 443-7063 | A fly pole and a 4x4 Chevy truck = Heaven on Earth

: >Here's what it said. Any ideas? I still have the coredump in case
: >that's useful....
:
: What hardware are you using?  If it's an AHA294X, then you need to
: upgrade to -stable.  If not, then knowing your hardware is still a good
: thing.

I'll include the boot messages at the end of this message. It's
also possible that some of the other messages I get are relevant.
They are:

        ed2: device timeout

These occur sporadically. I have no idea if they're meaningful.

        arplookup 205.246.209.98 failed: host is not on local network

I get a lot of these. The addresses (different ones appear at
different times) are in fact not on the local network; they're
aliases on another host.

        in_rtqtimo: adjusted rtq_reallyold to 62

I have no clue. :-)

Here are the boot messages:

FreeBSD 2.1.0-RELEASE #0: Thu Jan 11 10:39:19 EST 1996

CPU: i486DX (486-class CPU)
real memory  = 12582912 (12288K bytes)
avail memory = 10956800 (10700K bytes)
Probing for devices on the ISA bus:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA color <16 virtual consoles, flags=0x0>
ed0 at 0x280-0x29f irq 5 maddr 0xda000 msize 8192 on isa
ed0: address 00:00:c0:4d:b3:b2, type SMC8416C/SMC8416BT (16 bit)
ed1 at 0x2a0-0x2bf irq 10 maddr 0xd8000 msize 8192 on isa
ed1: address 00:00:c0:f2:b5:b2, type SMC8416C/SMC8416BT (16 bit)
ed2 at 0x2c0-0x2df irq 15 maddr 0xdc000 msize 8192 on isa
ed2: address 00:00:c0:b2:b2:b2, type SMC8416C/SMC8416BT (16 bit)
sio0 at 0x3f8-0x3ff irq 4 on isa
sio0: type 16550A
sio1 at 0x2f8-0x2ff irq 3 on isa
sio1: type 16550A
fdc0 at 0x3f0-0x3f7 irq 6 drq 2 on isa
fdc0: NEC 72065B
fd0: 1.44MB 3.5in
wdc0 at 0x1f0-0x1f7 irq 14 on isa
wdc0: unit 0 (wd0): <QUANTUM LP120A GM120A01X>
wd0: 116MB (238765 sectors), 901 cyls, 5 heads, 53 S/T, 512 B/S
wdc0: unit 1 (wd1): <Conner Peripherals 200MB - CP3204F>
wd1: 203MB (415872 sectors), 684 cyls, 16 heads, 38 S/T, 512 B/S
wdc1 not found at 0x170
aha0 not found at 0x330
ahc1: 284x Single Channel, SCSI Id=7, aic7770 >= Rev E, 4 SCBs
ahc1 at 0x1000-0x10ff irq 11 on eisa slot 1
ahc1 waiting for scsi devices to settle
(ahc1:0:0): "CONNER CFP4207S  4.28GB 1420" type 0 fixed SCSI 2
sd0(ahc1:0:0): Direct-Access 4096MB (8388608 512 byte sectors)
(ahc1:1:0): "FUJITSU M2694ES-512 812A" type 0 fixed SCSI 2
sd1(ahc1:1:0): Direct-Access 1033MB (2117025 512 byte sectors)
(ahc1:4:0): "ARCHIVE Python 25501-XXX 2.96" type 1 removable SCSI 2
st0(ahc1:4:0): Sequential-Access density code 0x13, 512-byte blocks, write-enabled
npx0 on motherboard
npx0: INT 16 interface

Just after boot, I also see these though I expect they're innocuous.

sd0: raw partition size != slice size
sd0: start 0, end 8388607, size 8388608
sd0c: start 0, end 8317919, size 8317920
sd0: raw partition size != slice size
sd0: start 0, end 8388607, size 8388608
sd0c: start 0, end 8317919, size 8317920

Quote:>: >Here's what it said. Any ideas? I still have the coredump in case
>: >that's useful....
>:
>: What hardware are you using?  If it's an AHA294X, then you need to
>: upgrade to -stable.  If not, then knowing your hardware is still a good
>: thing.

>I'll include the boot messages at the end of this message. It's
>also possible that some of the other messages I get are relevant.
>They are:

>    ed2: device timeout

>These occur sporadically. I have no idea if they're meaningful.

It may be an actual timeout, who knows?

Quote:>    arplookup 205.246.209.98 failed: host is not on local network

>I get a lot of these. The addresses (different ones appear at
>different times) are in fact not on the local network; they're
>aliases on another host.

Bill Fenner has been looking into these.  You might want to post
something to the mailing list to see what he's been up to.

Quote:>    in_rtqtimo: adjusted rtq_reallyold to 62

>I have no clue. :-)

Ignore this.  It's something that should be only printed out when
DIAGNOSTIC is defined.

I'm pretty sure that *all* of the Adaptec boards suffer from the
problems Justin fixed in -stable.  If I remember correctly, it was a generic
bug in the sequencer code used by all of the Adaptec boards.

almost positive it's a known bug in 2.1R that's now fixed in -stable.

At least get the -stable kernel sources and usr.sbin/config sources
(note that the kernel configuration file format has changed *slightly*
now) and build a new kernel to see if it helps.

Nate

--


work #: (406) 449-7662 | Montana.
home #: (406) 443-7063 | A fly pole and a 4x4 Chevy truck = Heaven on Earth

: I'm pretty sure that *all* of the Adaptec boards suffer from the
: problems Justin fixed in -stable.  If I remember correctly, it was a generic
: bug in the sequencer code used by all of the Adaptec boards.

Is it safe to use a -stable kernel with an otherwise 2.1.0-RELEASE
system? All the machines I have are production machines....