On Fri, 30 Aug 2013, Patrick wrote:
On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon a...@freebsd.org wrote:
I don't have an exact recollection of what is installed by freebsd-update -
are
*.symbols files installed?
Doesn't look like it. I wonder if I can grab that from a distro site
On Sat, 31 Aug 2013, Dmitry Morozovsky wrote:
I don't have an exact recollection of what is installed by freebsd-update
- are
*.symbols files installed?
Doesn't look like it. I wonder if I can grab that from a distro site
or somewhere?
it seems so:
On Thu, Aug 29, 2013 at 2:32 PM, Andriy Gapon a...@freebsd.org wrote:
on 29/08/2013 19:37 Patrick said the following:
I've got a system running on a VPS that I'm trying to upgrade from 8.2
to 8.4. It has a ZFS root. After booting the new kernel, I get:
Fatal trap 12: page fault while
on 30/08/2013 11:17 Patrick said the following:
H...
(kgdb) list *vdev_mirror_child_select+0x67
No symbol table is loaded. Use the file command.
Do I need to build the kernel from source myself? This kernel is what
freebsd-update installed during part 1 of the upgrade.
I don't have
On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon a...@freebsd.org wrote:
I don't have an exact recollection of what is installed by freebsd-update -
are
*.symbols files installed?
Doesn't look like it. I wonder if I can grab that from a distro site
or somewhere?
On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon a...@freebsd.org wrote:
I don't have an exact recollection of what is installed by freebsd-update -
are
*.symbols files installed?
Doesn't look like it. I wonder if I can grab that from a distro site
or somewhere?
I've got a system running on a VPS that I'm trying to upgrade from 8.2
to 8.4. It has a ZFS root. After booting the new kernel, I get:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x40
fault code = supervisor read data, page
on 29/08/2013 19:37 Patrick said the following:
I've got a system running on a VPS that I'm trying to upgrade from 8.2
to 8.4. It has a ZFS root. After booting the new kernel, I get:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x40
fault
a mirror with
zraid's
mounted for /usr, /usr/home, etc..
Is anyone else seeing this as well?
FreeBSD 8.0-BETA2 #137 r195914: Mon Jul 27 19:10:17 BST 2009
snip
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x288
ACK! Sorry.. I messed up the revision number in the message body...
On Monday 27 July 2009 21:18:22 Pegasus Mc Cleaft wrote:
I dont know if there is a current issue with other systems or if it is
localized to me, but ever since r195914 I am getting a fatal trap on
Crud! Just shoot me! I'm very sorry about this.. Typing to fast and not
checking..
On Monday 27 July 2009 21:23:36 Pegasus Mc Cleaft wrote:
ACK! Sorry.. I messed up the revision number in the message body...
On Monday 27 July 2009 21:18:22 Pegasus Mc Cleaft wrote:
I dont know if there
/497231edae4da529 removed.
GEOM_LABEL: Label ufsid/497231f823755a18 removed.
tap0: Ethernet address: 00:bd:9c:3f:00:00
re0: link state changed to DOWN
re0: link state changed to UP
The following is the info obtained by running crashinfo:
### instance 1 (May 21 about 23:00 local time)
Fatal trap 12: page fault
no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xc23f656e
fault code = supervisor read, page
...
Syncing disks, vnodes remaining...6 5 3 1 0 0 done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
All buffers synced.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page not present
instruction pointer = 0x20
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...6 5 3 1 0 0 done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
All buffers synced.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code
seconds) for system process `syncer' to stop...
Syncing disks, vnodes remaining...6 5 3 1 0 0 done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
All buffers synced.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x4
fault code = supervisor read, page
In article [EMAIL PROTECTED] you write:
http://www.freebsd.org/cgi/query-pr.cgi?pr=110892
Crash of system at use of the emulator qemu
$ pkg_info -E kqemu\* qemu\*
kqemu-kmod-1.3.0.p11
qemu-0.9.0
$ kldload aio
$ kldload kqemu
$ qemu -boot c -m 256 \
-hda /usr/EMULATORS/BOCHS/disk0.img \
-net
On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote:
I had one of these [kernel panics] a couple of weeks ago or so...
...[upgrade to -STABLE as of 15 June; repeat panic]...
The message to which I'm replying (posted to -stable) has the
particulars about the panic in question, and
On Fri, 16 Jun 2006, 08:45-0700, David Wolfskill wrote:
On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote:
I had one of these [kernel panics] a couple of weeks ago or so...
...[upgrade to -STABLE as of 15 June; repeat panic]...
The message to which I'm replying (posted to
On Fri, Jun 16, 2006 at 07:58:05PM +0400, Maxim Konovalov wrote:
On Fri, 16 Jun 2006, 08:45-0700, David Wolfskill wrote:
On Thu, Jun 15, 2006 at 04:22:40PM -0700, David Wolfskill wrote:
I had one of these [kernel panics] a couple of weeks ago or so...
...[upgrade to -STABLE as of 15
.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xac
fault code
Hi everybody
Since a little time I began to have some kernel fatal trap 12
I had FreeBSD 5.3 and I decided to install 6.0 to avoid this problem
(thinking that the bug was patched between these versions)
But after installing all, the kernel panic is still there
uname -a output :
FreeBSD freebsd
On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote:
Hi everybody
Since a little time I began to have some kernel fatal trap 12
Kernel panics that magically start for no reason after a long time of
stability are usually because your hardware has begun to fail.
Kris
pgpGuwqbOuIMP.pgp
]
Kris Kennaway a écrit :
On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote:
Hi everybody
Since a little time I began to have some kernel fatal trap 12
Kernel panics that magically start for no reason after a long time of
stability are usually because your hardware has begun
On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote:
Kris Kennaway a ?crit :
On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote:
Hi everybody
Since a little time I began to have some kernel fatal trap 12
Kernel panics that magically start for no reason after
On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote:
Hum, is there a way to have a little idea of which hardware begun to fail ?
Check CPU cooling, power supply, cabling, RAM, etc. Google for more -
this question is asked and answered about once a week.
Kris
pgp61xkB8fejK.pgp
, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote:
Kris Kennaway a ?crit :
On Wed, Apr 19, 2006 at 07:46:16PM +0200, Thomas SOETE wrote:
Hi everybody
Since a little time I began to have some kernel fatal trap 12
Kernel panics that magically start for no reason
Kris Kennaway wrote this message on Wed, Apr 19, 2006 at 14:08 -0400:
On Wed, Apr 19, 2006 at 07:59:08PM +0200, Thomas SOETE wrote:
Hum, is there a way to have a little idea of which hardware begun to fail ?
Check CPU cooling, power supply, cabling, RAM, etc. Google for more -
this
the
packets flowing
through the network.
4. i have used data structures like linked lists and
trees.
now the problem is as soon as i run my modified kernel
it panics with
fatal trap 12. the name of the process that crashed is
sometimes the cron,
sometimes ps, sometimes top, sometimes g_up
Hi,
On 12/25/05, kamal kc [EMAIL PROTECTED] wrote:
[...]
Is the problem related to memory leaks or sleeping
on mutexes or some other causes.
From the backtrace you have provided, it looks like a memory
corruption. In order to aid your debugging, you will want INVARIANTS
and WITESS, etc. to be
thanks,
i will try INVARIANTS and WITNESS options and will try to get
freebsd 6.0. it will be only tomorrow when i'll be able to do this
because it is already evening and i will go to my office tomorrow
only.
in the mean time if the memory corruption is the problem then is there
any
to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap
On Friday 02 December 2005 14.54, John Baldwin wrote:
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
I have the following panic occurring several times a week. The machine is
an NFS server, and it usually panics early in the morning, when first
people try to access it. After
On Wednesday 07 December 2005 02:47 am, Yuri Khotyaintsev wrote:
On Friday 02 December 2005 14.54, John Baldwin wrote:
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
I have the following panic occurring several times a week. The machine
is an NFS server, and it usually
.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as i386-marcel-freebsd.
Unread portion of the kernel message buffer:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address
of the kernel message buffer:
kernel trap 12 with interrupts disabled
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x74
fault code = supervisor read, page not present
instruction pointer = 0x20:0xc053a426
stack pointer = 0x28:0xd56c0b88
frame
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
I have the following panic occurring several times a week. The machine is
an NFS server, and it usually panics early in the morning, when first
people try to access it. After reboot it may work OK for 1-2 days, and then
panics
On Friday 02 December 2005 14.54, John Baldwin wrote:
On Friday 02 December 2005 05:00 am, Yuri Khotyaintsev wrote:
I have the following panic occurring several times a week. The machine is
an NFS server, and it usually panics early in the morning, when first
people try to access it. After
running
#cat /dev/ulpt0
causes fatal trap 12
and system begins dumping.
printer HP LaserJet 1010 USB
---
Script started on Sat Nov 12 16:10:02 2005
[EMAIL PROTECTED] dmesg
Copyright (c) 1992-2005 The FreeBSD Project.
Copyright (c) 1979
running
#cat /dev/ulpt0
causes fatal trap 12 and system begins dumping.
printer HP LaserJet 1010 USB
#uname -a
FreeBSD st1.fqdn 6.0-RELEASE FreeBSD 6.0-RELEASE #0: Thu Nov 10
16:04:32 MSK 2005 root@:/usr/obj/usr/src/sys/st1 i386
___
freebsd-hackers
but eventually i get a fatal trap,
sooner or later.
my compression/decompression uses about 14KB of
memory per packet which i malloc/free after the
job is done.
the fatal trap i observed is:
-
Fatal Trap 12 page fault while in kernel mode
fault virtual address=0xc195600
fault code
)
ufs_rename: fvp == tvp (can't happen)
ufs_rename: fvp == tvp (can't happen)
ufs_rename: fvp == tvp (can't happen)
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 06
fault virtual address = 0x20
fault code = supervisor read, page not present
instruction pointer
On Wed, 9 Feb 2005, David Rice wrote:
We have two NFS file servers running FreeBSD 5.2.1-RELEASE-p9 on Dell
Poweredge 1750's that crash randomly. They each have about 1.3TB of
disk. They are used to server email and web content to several WEB/EMAIL
servers. Followin is the console log
[EMAIL PROTECTED] wrote:
We have two NFS file servers running FreeBSD 5.2.1-RELEASE-p9 on
Dell Poweredge 1750's that crash randomly. They each have about 1.3TB
of disk. They are used to server email and web content to several
WEB/EMAIL servers. Followin is the console log messages and the
On Tue, 8 Feb 2005, ALeine wrote:
[EMAIL PROTECTED] wrote:
We have two NFS file servers running FreeBSD 5.2.1-RELEASE-p9 on
Dell Poweredge 1750's that crash randomly. They each have about 1.3TB
of disk. They are used to server email and web content to several
WEB/EMAIL servers.
Alright, this is driving me nuts. For a little while there I could not
get the system to panic -- it would spontaniously reboot when running a
GL program instead of panic. This afternoon it finally panic'd (who
would think that would be something I want to see but it was).
I am attaching the
On Mon, 23 Aug 2004, Kevin Brunelle wrote:
Alright, this is driving me nuts. For a little while there I could
not get the system to panic -- it would spontaniously reboot when
running a GL program instead of panic. This afternoon it finally
panic'd (who would think that would be something I want
If this is how I got most of my panics, this little script running in
two different xterms helped decrease the time to panic. It got my
system to panic a lot with the older nvidia drivers.
[script trimmed out]
This always helped get my system unstable on 4-STABLE rather quickly. I
think
kernel:
Aug 20 07:33:50 fnord kernel: syncing disks, buffers remaining... kernel trap 12 with
interrupts disabled
Aug 20 07:33:50 fnord kernel:
Aug 20 07:33:50 fnord kernel:
Aug 20 07:33:50 fnord kernel: Fatal trap 12: page fault while in kernel mode
Aug 20 07:33:50 fnord kernel: fault virtual
Okay,
Replication does not look like it will be an issue. Again, the system
panic'd while running a gl application when I was at work. This time I
did get a core dump (but I still don't have a debugging kernel -- it was
building ARG).
Right now, I am going to disable my screensaver and
On Sun, Aug 22, 2004 at 11:22:43AM -0400, Kevin Brunelle wrote:
Okay,
Replication does not look like it will be an issue. Again, the system
panic'd while running a gl application when I was at work. This time I
did get a core dump (but I still don't have a debugging kernel -- it was
Hi,
I am playing around with remote gdb on a -current cvsupped 2 days ago.
In gdb I set a breakpoint on ums_open (USB mouse driver, as a module),
in the console I execute cat /dev/ums0, the breakpoint triggers, in gdb
I issue a continue and I get a Fatal trap 12: page fault while in kernel mode
On Fri, Oct 11, 2002 at 12:46:36AM -0400, abe wrote:
...
Unfortunately, feedback sent while in good intentions did not help. However, in
further
tinkering with this issue I believe I've come to a conclusion. I run a rather
high-traffic
server so I had initially increased
abe wrote:
On Thu, Oct 10, 2002 at 09:50:13PM -0700, Bill Fumerola wrote:
On Fri, Oct 11, 2002 at 12:46:36AM -0400, abe wrote:
static u_int32_t dyn_buckets = 256; /* must be power of 2 */
Well another issue solved, need thicker glasses it appears. Thanks much
Bill. Funny thing is, it's
Luigi Rizzo wrote:
On Fri, Oct 11, 2002 at 12:46:36AM -0400, abe wrote:
...
Unfortunately, feedback sent while in good intentions did not
help. However, in further tinkering with this issue I believe I've
come to a conclusion. I run a rather high-traffic server so I had
initially
Hi,
I've written to the questions list recently with regard to a panic that keeps
occuring
and perhaps my message was not formatted as well as it could have been. In more
testing
it seems that the minute the ipfw rules are loaded (which previously worked without
issue),
the machine
abe wrote:
I've written to the questions list recently with regard to a
panic that keeps occuring and perhaps my message was not formatted
as well as it could have been. In more testing it seems that the
minute the ipfw rules are loaded (which previously worked without
issue), the
Hi Luigi,
Pardon, been a hectic week. Heh. I've tried this on fresh installs of
4.5-rel, 4.5-rel-p20, 4.6.2-p2, and 4.7-RC.
On Thu, Oct 10, 2002 at 02:39:48PM -0700, Luigi Rizzo wrote:
what freebsd version are you using, are you using compiled-in ipfw or
a module ?
cheers
Hi Terry,
This started out as a sudden panic on a machine that was in a datacenter
for more than 8 months without issue. Then I installed on fresh machines,
compiled in ipfw support, and also tried this as a module. The result is the same
regardless.
Regards,
Abe
On Thu, Oct 10,
abe wrote:
This started out as a sudden panic on a machine that was in a
datacenter for more than 8 months without issue. Then I installed
on fresh machines, compiled in ipfw support, and also tried this as
a module. The result is the same regardless.
You have a traceback; do you have
On Thu, Oct 10, 2002 at 03:18:58PM -0700, Terry Lambert wrote:
abe wrote:
This started out as a sudden panic on a machine that was in a
datacenter for more than 8 months without issue. Then I installed
on fresh machines, compiled in ipfw support, and also tried this as
a module.
abe wrote:
You have a traceback; do you have a system dump?
Sorry Terry, unfortunately it wouldn't produce a system dump unless
I was not taking the proper steps to produce one. Any URL that would
point this out to me or any suggestion?
Poul changed this code. I haven't been able to get
On Thu, Oct 10, 2002 at 03:50:47PM -0700, Terry Lambert wrote:
abe wrote:
You have a traceback; do you have a system dump?
Sorry Terry, unfortunately it wouldn't produce a system dump unless
I was not taking the proper steps to produce one. Any URL that would
point this out to me or
abe wrote:
On Thu, Oct 10, 2002 at 03:50:47PM -0700, Terry Lambert wrote:
You should be able to find out the C code at assembly code offset
0x172, assuming you created your kernel with config -g, and you
***
compiled the
On Thu, Oct 10, 2002 at 07:10:52PM -0700, Terry Lambert wrote:
abe wrote:
On Thu, Oct 10, 2002 at 03:50:47PM -0700, Terry Lambert wrote:
You should be able to find out the C code at assembly code offset
0x172, assuming you created your kernel with config -g, and you
Bill,
Any hint as to what seems to be going on here and maybe a clue
to a possible solution?
Regards,
Abe
On Thu, Oct 10, 2002 at 08:02:07PM -0700, Bill Fumerola wrote:
On Thu, Oct 10, 2002 at 07:10:52PM -0700, Terry Lambert wrote:
Not to be emphatic, or anything, but IPFW has to
Hello folks,
Recently I have been corresponding with several from this list and questions@ with
regard to an odd issue with ipfw and my machine panicing after any network
communication
was attempted after loading some IPFW rules.
Some evidence of the panics can be found at:
On Fri, Oct 11, 2002 at 12:46:36AM -0400, abe wrote:
Unfortunately, feedback sent while in good intentions did not help. However, in
further
tinkering with this issue I believe I've come to a conclusion. I run a rather
high-traffic
server so I had initially increased
On Thu, Oct 10, 2002 at 09:50:13PM -0700, Bill Fumerola wrote:
On Fri, Oct 11, 2002 at 12:46:36AM -0400, abe wrote:
Unfortunately, feedback sent while in good intentions did not help. However,
in further
tinkering with this issue I believe I've come to a conclusion. I run a rather
Bill Fumerola wrote:
On Thu, Oct 10, 2002 at 07:10:52PM -0700, Terry Lambert wrote:
Not to be emphatic, or anything, but IPFW has to be static. There
is voodoo you can use to make it know about loaded modules, but I'll
be damned if I know what it is (again, I refer you to the handbook).
abe wrote:
gdb -k kernel.debug
list *add_dyn_rule+0x172
(kgdb) list *add_dyn_rule+0x172
No source file for address 0xc021e5d6
(kgdb)
Not to be emphatic, or anything, but IPFW has to be static.
I thought it was static considering I compiled the kernel with
Bruce A. Mah writes:
I was discussing this with some of my cow-orkers, as we've had a similar
situation (cluster mbufs getting temporarily depleted on a
4.5-RELEASE-p2 NFS server with Linux and FreeBSD clients, but no kernel
panics). Shouldn't the net.inet.ip.maxfragpackets sysctl
Terry Lambert writes:
Andrew Gallatin wrote:
The problem is that ip_maxfragpackets is:
Maximum number of IPv4 fragment reassembly queue entries
You ( I, most people probably) took that number to mean the cap on
the number of mbufs sitting on reassembly queues. However, its
[Moving to -net]
If memory serves me right, Andrew Gallatin wrote:
Alternately, it would be a good idea to have a ip_maxpacketfrags
instead of an ip_maxfragpackets, to put a hard limit on the
number of mbufs that can be consumed by the fragment reassembly
process.
I think this is
Terry Lambert wrote:
David Greenman wrote:
#16 0xc0152220 in tsleep ()
#17 0xc016abfe in m_clalloc_wait ()
#18 0xc01c8b14 in nfs_realign ()
#19 0xc01c9653 in nfsrv_rcv ()
#20 0xc01701d0 in sowakeup ()
#21 0xc01abd7c in udp_input ()
#22 0xc01a1bfb in ip_input ()
#23 0xc01a1c5b in
Will Froning writes:
I have a 4.5-RELEASE-p2 box that is my Firewall/NAT/NFS server. As a
NFS client I have a RH7.2 linux box. When I do massive NFS writes to
my FBSD (from RH7.2 box), I get a panic. I've attached the info I got
from my debug kernel.
While the fix being discussed
If memory serves me right, Andrew Gallatin wrote:
Will Froning writes:
I have a 4.5-RELEASE-p2 box that is my Firewall/NAT/NFS server. As a
NFS client I have a RH7.2 linux box. When I do massive NFS writes to
my FBSD (from RH7.2 box), I get a panic. I've attached the info I got
messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x70
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0152220
stack pointer = 0x10:0xc02ade58
frame pointer = 0x10:0xc02ade7c
code segment
Will Froning wrote:
#12 0xc014f61d in panic ()
#13 0xc025c02f in trap_fatal ()
#14 0xc025bcdd in trap_pfault ()
#15 0xc025b883 in trap ()
#16 0xc0152220 in tsleep ()
#17 0xc016abfe in m_clalloc_wait ()
The tsleep tried to reference a page that wasn't there. This
supposedly can't happen.
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x70
#12 0xc014f61d in panic ()
#13 0xc025c02f in trap_fatal ()
#14 0xc025bcdd in trap_pfault ()
#15 0xc025b883 in trap ()
#16 0xc0152220 in tsleep ()
#17 0xc016abfe in m_clalloc_wait ()
#18 0xc01c8b14 in nfs_realign ()
#19
Peter Wemm wrote:
You will need to modify nfs_realign() to take a waitflag,
+++
as propagated from nfsrv_rcv()... and then pass it through
*
Terry, if you spent half of the time reading the code as
with
this message:
fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc33a3c6d
fault code = supervisor read, page not present
Instruction Pointer = 0x8:0xc022798F
Stack Pointer = 0x 10: 0xc5dc6988
code segment = base 0 x0, limit 0xf type 0x1b
= DPL
the machine was rebooting over and over again, freezing with
this message:
fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc33a3c6d
fault code = supervisor read, page not present
Instruction Pointer = 0x8:0xc022798F
You have to post more information
into DDB (when my driver isn't loaded)...
(I'm also crashing with my driver, but that's another story :)
I left my machine sit at the console login prompt over the weekend,
and today found it had crashed into DDB, showing a "Fatal trap 12:
page fault while in kernel mode", which happened
While installing 2.2.8R (from a CD which I got from cheapbytes) on a
486DX2 66, w/ 16Mb RAM, I get:
sc0 at 0x60-0x6f irq 1 on motherboard
sc0: VGA mono 16 virtual consoles, flags=0x0
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xefc0
fault code
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc47864
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01a1aff
stack pointer = 0x10:0xf9135f74
frame pointer = 0x10:0xf9135f7c
code segment
system 512 MB
my fatal error 12 messages :
panicstr: page fault
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc47864
fault code = supervisor read, page not present
instruction pointer = 0x8:0xf01a1aff
stack pointer
87 matches
Mail list logo
