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:
>
> marck@w
On Fri, 30 Aug 2013, Patrick wrote:
> On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon 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 som
On Fri, Aug 30, 2013 at 1:30 AM, Andriy Gapon 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 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 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
On Thu, Aug 29, 2013 at 2:32 PM, Andriy Gapon 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 tra
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
> fa
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
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 th
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
m 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
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address
ate 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 while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x19
fault code = supervisor write, page not present
instruction pointer
pe "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
process `vnlru' to stop...done
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 mo
on signal 15
Waiting (max 60 seconds) for system process `vnlru' to stop...done
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.
60 seconds) for system process `vnlru' to stop...done
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 fa
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
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
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
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 t
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;
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 qu
D]
GTalk : [EMAIL PROTECTED]
Steve Kargl a écrit :
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
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
Descri
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
> >>
>
CTED]
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 b
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.
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
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 optio
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. t
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
s.
> 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 = 0x0
> fault code = supervisor re
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 12: page fault while in kernel mo
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 usua
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.
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.
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 ag
"i386-marcel-freebsd".
Unread portion 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
s
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
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 server
[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 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 me
6 (send_nsca), uid 0: exited on signal 11
(core dumped)
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 cod
> 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
> thi
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
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 tra
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
>
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 carefull
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 address = 0x24
A
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
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
> > i
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 i
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 net.inet.i
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
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 handbo
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 ra
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 net.inet.ip.f
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:
http://di
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
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).
> 8-).
nope. ipfw does
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
>
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
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 o
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 t
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 mod
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 ha
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, 2002
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
>
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,
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 pa
I have this problem, someone can help me?
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x3090
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01d0a61
stack pointer = 0x10:0xd7ec3e18
frame pointer = 0x10
[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
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. H
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 really
> a cap on the number
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 sysct
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
Andrew Gallatin wrote:
> While the fix being discussed by Peter & others will prevent panics,
> the linux box will still run your server out of mbufs clusters. This
> is happening because the linux box is using a 16K write size over UDP
> by default. This is a stupid default. If there is any lo
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 discus
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 ()
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 s
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 ipintr ()
>
>
>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_wa
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 happ
ess 0x002d6fa0
panicstr: page fault
panic 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
> Now, today 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 =
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
m crashing 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 mo
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 = 0x
0MHZ Pentium II
> swap file 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, pag
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 = 0x10:0xf9135f74
frame pointer = 0x10:0xf9135f7c
code se
92 matches
Mail list logo
