empting a dump failed. I'm afraid all for
>> information is the below. The kernel was a
>> non-debug kernel (with debug information).
>>
>> The following is hand typed from a screen shot:
>>
>> Fatal trap 12: page fault while in kernel mode
>> c
he following is hand typed from a screen shot:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0xff53f000e2b0
New one: 0x806b49010
> fault code= supervisor read data, page not present
New one
Attempting a dump failed. I'm afraid all for
information is the below. The kernel was a
non-debug kernel (with debug information).
The following is hand typed from a screen shot:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0xff53f00
Am Fri, 14 Apr 2017 20:18:57 +0300
Konstantin Belousov schrieb:
> On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 02
> > fault virtual address = 0xf8001282fb00
> > fault cod
nn wrote:
> > > > Fatal trap 12: page fault while in kernel mode
> > > > cpuid = 2; apic id = 02
> > > > fault virtual address = 0xf8001282fb00
> > > > fault code = supervisor read instruction, protection
> > > > viol
On Sat, Apr 15, 2017 at 11:18:41AM +0200, O. Hartmann wrote:
> Am Fri, 14 Apr 2017 20:18:57 +0300
> Konstantin Belousov schrieb:
>
> > On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > > Fatal trap 12: page fault while in kernel mode
> > > cp
Am Fri, 14 Apr 2017 20:18:57 +0300
Konstantin Belousov schrieb:
> On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 2; apic id = 02
> > fault virtual address = 0xf8001282fb00
> > fault cod
On Fri, Apr 14, 2017 at 06:58:27PM +0200, O. Hartmann wrote:
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0xf8001282fb00
> fault code = supervisor read instruction, protection violation
> ??() at 0xf
: link state changed to UP
> > igb1.2: link state changed to UP
> > igb1.66: link state changed to UP
> > igb1.111: link state changed to UP
> > igb1.10: link state changed to UP
> > tun0: link state changed to UP
> > link state changed to down
> > igb0: lin
> tun0: link state changed to UP
> link state changed to down
> igb0: link state changed to DOWN
> Bump sched buckets to 64 (was 0)
> Link state changed to up
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address =
ed to UP
igb1.66: link state changed to UP
igb1.111: link state changed to UP
igb1.10: link state changed to UP
tun0: link state changed to UP
link state changed to down
igb0: link state changed to DOWN
Bump sched buckets to 64 (was 0)
Link state changed to up
Fatal trap 12: page fault while in k
On 18 Dec, Mateusz Guzik wrote:
> On Fri, Dec 18, 2015 at 09:44:10AM -0800, Don Lewis wrote:
>> On 18 Dec, Mateusz Guzik wrote:
>> > On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote:
>> >> On 17 Dec, Mateusz Guzik wrote:
>> >> > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
>>
On Fri, Dec 18, 2015 at 09:44:10AM -0800, Don Lewis wrote:
> On 18 Dec, Mateusz Guzik wrote:
> > On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote:
> >> On 17 Dec, Mateusz Guzik wrote:
> >> > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
> >> >> On 17 Dec, Konstantin Belousov w
On 18 Dec, Mateusz Guzik wrote:
> On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote:
>> On 17 Dec, Mateusz Guzik wrote:
>> > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
>> >> On 17 Dec, Konstantin Belousov wrote:
>> >> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wro
On Thu, Dec 17, 2015 at 02:33:46PM -0800, Don Lewis wrote:
> On 17 Dec, Mateusz Guzik wrote:
> > On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
> >> On 17 Dec, Konstantin Belousov wrote:
> >> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
> >> >> I used to have a patch the
On Fri, Dec 18, 2015 at 11:36:44AM +0100, Fabian Keil wrote:
> Fabian Keil wrote:
>
> > Konstantin Belousov wrote:
> >
> > > On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> > > > Thanks. I'm currently testing the patch on three systems but it may
> > > > take a while ...
> > >
Fabian Keil wrote:
> Konstantin Belousov wrote:
>
> > On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> > > Thanks. I'm currently testing the patch on three systems but it may take
> > > a while ...
> > >
> >
> > Better use mjg' patch with the small adjustment. I put it b
On 17 Dec, Mateusz Guzik wrote:
> On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
>> On 17 Dec, Konstantin Belousov wrote:
>> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
>> >> I used to have a patch the deferred linking the new process into
>> >> proctree/allproc until i
On Thu, Dec 17, 2015 at 11:48:08AM -0800, Don Lewis wrote:
> On 17 Dec, Konstantin Belousov wrote:
> > On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
> >> I used to have a patch the deferred linking the new process into
> >> proctree/allproc until it was fully formed. The motivation wa
On 17 Dec, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
>> I used to have a patch the deferred linking the new process into
>> proctree/allproc until it was fully formed. The motivation was to get
>> rid of all of the PRS_NEW stuff scattered around the so
On Wed, Dec 16, 2015 at 11:08:02AM -0800, Don Lewis wrote:
> I used to have a patch the deferred linking the new process into
> proctree/allproc until it was fully formed. The motivation was to get
> rid of all of the PRS_NEW stuff scattered around the source.
> Unfortunately the patch bit-rotted
Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> > Thanks. I'm currently testing the patch on three systems but it may take a
> > while ...
> >
>
> Better use mjg' patch with the small adjustment. I put it below.
Will do.
Fabian
pgpARhuAh6qDb.p
On 16 Dec, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
>> Konstantin Belousov wrote:
>> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
>>
>> Unfortunately it's not available and apparently I removed the attempts
>> to get
On Wed, Dec 16, 2015 at 04:09:17PM +0100, Fabian Keil wrote:
> Thanks. I'm currently testing the patch on three systems but it may take a
> while ...
>
Better use mjg' patch with the small adjustment. I put it below.
diff --git a/sys/kern/kern_proc.c b/sys/kern/kern_proc.c
index 435a07b..fc392
Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov wrote:
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame
> > > 8.
> >
> > Unfortunately it's not available and apparently I removed the attempts
> >
Oliver Pinter wrote:
> Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
> now lesser time for the real fix in this month.
>
> Are you running on ZFS?
Yes.
Fabian
pgpuOBy_BlV8u.pgp
Description: OpenPGP digital signature
On Wed, Dec 16, 2015 at 02:54:27PM +0100, Mateusz Guzik wrote:
> While I agree with analysis the patch does not look right. Since the
> struct is only assigned and all locks get dropped, there is nothing
> preventing another thread from the forking process to change the process
> group.
>
> Intere
onths, usually while poudriere was running and with sh being the
> > current process.
> >
> > This one is from a system based on r290926 running with
> > kern.randompid=9001 and forking frequently (>1000 forks/second)
> > due to poudriere and afl-fuzz:
> >
>
On Wed, Dec 16, 2015 at 02:10:00PM +0200, Konstantin Belousov wrote:
> On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> > Konstantin Belousov wrote:
> > > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
> >
> > Unfortunately it's not available and apparent
Yes, it's a HardenedBSD commit. Currently only a workaround, because I have
now lesser time for the real fix in this month.
Are you running on ZFS?
On Wednesday, December 16, 2015, Fabian Keil
wrote:
> Oliver Pinter > wrote:
>
> > Is this with latest 11-CURRENT or 10-STABLE?
> >
> > Or contains
Oliver Pinter wrote:
> Is this with latest 11-CURRENT or 10-STABLE?
>
> Or contains the ad578c311ef commit?
The panic is from a system based on 11-CURRENT r290926.
Is ad578c311ef a HardenedBSD commit? It doesn't seem to
exist in https://github.com/freebsd/freebsd.git.
Fabian
pgpHRlok72ddQ.p
gt; kern.randompid=9001 and forking frequently (>1000 forks/second)
> due to poudriere and afl-fuzz:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 04
> fault virtual address = 0x618b00a8
> fault code = supervisor read data, page
On Wed, Dec 16, 2015 at 12:21:16PM +0100, Fabian Keil wrote:
> Konstantin Belousov wrote:
> > It is the values of *p and *(p->p_pgrp) that are needed, from the frame 8.
>
> Unfortunately it's not available and apparently I removed the attempts
> to get it from the previous output.
> allproc is a
gt; This one is from a system based on r290926 running with
> > kern.randompid=9001 and forking frequently (>1000 forks/second)
> > due to poudriere and afl-fuzz:
> >
> > Fatal trap 12: page fault while in kernel mode
> > cpuid = 1; apic id = 04
> > fault virt
gt; kern.randompid=9001 and forking frequently (>1000 forks/second)
> due to poudriere and afl-fuzz:
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 04
> fault virtual address = 0x618b00a8
> fault code = supervisor read data, page
and afl-fuzz:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 04
fault virtual address = 0x618b00a8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80909158
stack pointer = 0x28:0xfe011e03b940
frame
В Tue, 10 Feb 2015 22:01:29 +0200
Ivan Klymenko пишет:
> I do not know the conditions - it just happened.
>
> http://pastebin.com/BASJB599
next
http://pastebin.com/hY8GYpjd
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/
В Tue, 10 Feb 2015 22:01:29 +0200
Ivan Klymenko пишет:
> I do not know the conditions - it just happened.
>
> http://pastebin.com/BASJB599
> ___
> freebsd...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-fs
> To unsubscri
I do not know the conditions - it just happened.
http://pastebin.com/BASJB599
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
On Fri, Nov 1, 2013 at 6:03 AM, Alexey Dokuchaev wrote:
> On Thu, Oct 31, 2013 at 09:59:42AM -0700, Kevin Oberman wrote:
> > On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev wrote:
> > > I was running out of space on my UFS partition and decided to use big
> NTFS
> > > one I also have on the dr
On Thu, Oct 31, 2013 at 09:59:42AM -0700, Kevin Oberman wrote:
> On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev wrote:
> > I was running out of space on my UFS partition and decided to use big NTFS
> > one I also have on the drive. I've mounted it with ntfs-3g and our native
> > fuse.ko. I ne
FYI, works fine after changed to pkg0.isc.FreeBSD.org.
# pkg update
Updating repository catalogue
digests.txz
100% 960KB 240.0KB/s 80.0KB/s 00:04
packagesite.txz
100% 5258KB 309.3KB/s 498.5KB/s 00:17
Incremental update completed, 0 packages processed:
0 packages updated, 0 removed and 21724
On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev wrote:
> Hi again,
>
> I was running out of space on my UFS partition and decided to use big NTFS
> one I also have on the drive. I've mounted it with ntfs-3g and our native
> fuse.ko. I needed the scratch space to built Open/LibreOffice on it *
core at the end of
this email; full debug info is available upon request).
This is on fresh 11-CURRENT, i386.
./danfe
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x64
fault code = supervisor read, page not present
instruction po
On 07/06/12 00:21, O. Hartmann wrote:
> On 07/05/12 23:27, John Baldwin wrote:
>> On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote:
>>> The most recent build of FreeBSD 10.0-CURRENT crashes on one of our
>>> boxes with recent Intel hardware, see dmesg extract below. FreeBSD does
>>> obviously
On 07/05/12 23:27, John Baldwin wrote:
> On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote:
>> The most recent build of FreeBSD 10.0-CURRENT crashes on one of our
>> boxes with recent Intel hardware, see dmesg extract below. FreeBSD does
>> obviously only crash on hardware with modern "Sandy-B
On Tuesday, July 03, 2012 1:43:30 am O. Hartmann wrote:
> The most recent build of FreeBSD 10.0-CURRENT crashes on one of our
> boxes with recent Intel hardware, see dmesg extract below. FreeBSD does
> obviously only crash on hardware with modern "Sandy-Bridge" hardware,
> the very same kernel conf
the kernel trap message.
I do this report on the fly, so if there is need for deeper
investigations let me know, I will provide necessary detail requested.
Regards,
Oliver
Jul 2 13:34:26 sb211 kernel: Fatal trap 12: page fault while in kernel mode
Jul 2 13:34:26 sb211 kernel: cpuid = 3; apic id =
Fabian Keil wrote:
> Fabian Keil wrote:
>
> > I pretty reproducible get the following (handtranscribed) panic
> > when sending an zfs snapshot to geli provider based on an USB
> > stick that disappears (due to a bug, or because it's unplugged):
> >
>
Fabian Keil wrote:
> I pretty reproducible get the following (handtranscribed) panic
> when sending an zfs snapshot to geli provider based on an USB
> stick that disappears (due to a bug, or because it's unplugged):
>
> Fatal trap 12: page fault while in kernel mode
>
I pretty reproducible get the following (handtranscribed) panic
when sending an zfs snapshot to geli provider based on an USB
stick that disappears (due to a bug, or because it's unplugged):
Fatal trap 12: page fault while in kernel mode
cpuid = 0: apic id = 00
fault virtual address =
On amd64 r210786 booting kernel with iwn(4)
I get this fatal trap (copied by hand) :
*skip*
acpi_throttle0: on cpu0
powernow0: on cpu0
acpi_throttle1: on cpu1
acpi_throttle1: failed to attach P_CNT
device_attach: acpi_throttle1 attach returned 6
powernow1: on cpu1
Fatal trap 12: page fault
On Sat, Jul 31, 2010 at 12:12:50AM +0200, Marko Zec wrote:
>
> VIMAGE kernels do not properly set curvnet context when dynamically attaching
> devices (such as USB or pccard NICs), that's why the dereferencing V_if_index
> fails. You can use the "show pcpu" and "show vnets" DDB commands to
On Friday 30 July 2010 22:43:12 David Wolfskill wrote:
> I thought I had mentioned this a while back, as I've been seeing it
> since at least 13 July, but a quick check didn't convince me otherwise.
>
> So I reproduced the problem yesterday, as of r210598: Thu Jul 29
> 17:54:37 PDT 2010.
>
> Sympto
On Sat, Jul 31, 2010 at 12:12:50AM +0200, Marko Zec wrote:
> ...
> > Symptom is that I get a panic on insert (or kernel probe, if it's
> > inserted already at boot time) of a PCcard NIC.
>
>
> VIMAGE kernels
Oh -- right. I fogot that I had configured this kernel for VIMAGE so
Julian to demo som
ether 00:30:48:2d:32:6b
> media: Ethernet autoselect
> status: no carrier
> add net default: gateway 172.16.8.1
> add net :::0.0.0.0: gateway ::1
> add net ::0.0.0.0: gateway ::1
> add net fe80::: gateway ::1
> add net ff02::: gateway ::1
> ELF ldconfig path
ng lpd.
Updating motd:.
Starting ntpd.
Starting powerd.
Starting rsyncd.
Starting cvsupd.
Configuring syscons: blanktime.
Starting sshd.
Starting cron.
Starting background file system checks in 60 seconds.
Tue May 11 21:20:35 PDT 2010
FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0)
login:
Fatal trap
s_debugger(c0cc998b,c52138b0,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,0,c0d00028,c55810a4,c557f7f8,...) at witness_warn+0x1fd
> trap(c521393c) at trap+0x19e
> calltrap() at calltrap+0x6
> --- trap 0xc, eip = 0xc0a4d4b0, esp = 0xc521397c, ebp = 0xc5213b14 ---
> ip6_output
tclock+0x24a
intr_event_execute_handlers(c557f7f8,c5588800,c0cbf49f,533,c5588870,...) at
intr_event_execute_handlers+0x125
ithread_loop(c557e120,c5213d38,c0cbf218,343,c557f7f8,...) at ithread_loop+0x9f
fork_exit(c087c8f0,c557e120,c5213d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- tra
On Mon, May 10, 2010 at 03:52:07PM -0700, David Wolfskill wrote:
> On Mon, May 10, 2010 at 03:39:11PM -0700, K. Macy wrote:
> > Are you not able to dump core?
> >
>
> Here's the crash summary; I can put the dump on my Web server on request.
> (It weighs in at 89MB.)
>
Compression reduce
7,...) at
> db_trace_self_wrapper+0x26
> kdb_backtrace(c0ce3e07,547,,c0f65a1c,c521389c,...) at
> kdb_backtrace+0x29
> _witness_debugger(c0cc982b,c52138b0,4,1,0,...) at _witness_debugger+0x25
> witness_warn(5,0,c0cffec8,c55810a4,c557f7f8,...) at witness_warn+0x1fd
> trap(c521393c) at t
f0b8,343,c557f7f8,...) at ithread_loop+0x9f
fork_exit(c087c780,c557e120,c5213d38) at fork_exit+0xb8
fork_trampoline() at fork_trampoline+0x8
--- trap 0, eip = 0, esp = 0xc5213d70, ebp = 0 ---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0
On Mon, May 10, 2010 at 2:32 PM, K. Macy wrote:
> Could you please try with 207902?
And if not, please get a coredump with a backtrace with symbols.
Thanks
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-c
Could you please try with 207902?
Thanks,
Kip
On Mon, May 10, 2010 at 11:26 AM, David Wolfskill wrote:
> On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
>> ...
>> You don't happen to have a backtrace?
>
> Oops -- sorry; got caught up in getting ready to head in to work:
>
> db> bt
>
On Mon, May 10, 2010 at 08:22:43PM +0200, Ed Schouten wrote:
> ...
> You don't happen to have a backtrace?
Oops -- sorry; got caught up in getting ready to head in to work:
db> bt
Tracing pid 20 tid 100067 td 0xc5a19000
_mtx_lock_flags(58,0,c0cd2d5b,570,80,...) at _mtx_lock_flags+0x46
flowtable_f
Starting cron.
Starting background file system checks in 60 seconds.
Mon May 10 06:48:07 PDT 2010
FreeBSD/i386 (freebeast.catwhisker.org) (ttyu0)
login:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 06
fault virtual address = 0x68
fault code = supervisor re
On Fri, Mar 19, 2010 at 7:09 AM, David Wolfskill wrote:
> On Fri, Mar 19, 2010 at 01:09:11PM +, Rui Paulo wrote:
>> ...
>> > Do you all have either out-of-tree modules or modules that you did not
>> > re-build when re-compiling your kernel?
>>
>> I have in-tree modules, but I tried a clean bui
On Fri, Mar 19, 2010 at 01:09:11PM +, Rui Paulo wrote:
> ...
> > Do you all have either out-of-tree modules or modules that you did not
> > re-build when re-compiling your kernel?
>
> I have in-tree modules, but I tried a clean build.
I corresponded with kmacy@ a bit yesterday.
Pending resol
On 18 Mar 2010, at 22:15, K. Macy wrote:
> On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote:
I have the same panic. I'll try to revert 205266.
>>>
>>> Yes, 205266 is the culprit.
>>
>> Try updating. I've made the change a no-op until I can track the problem
>> down.
>
> Do you all h
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/10 18:15, K. Macy wrote:
> On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote:
I have the same panic. I'll try to revert 205266.
>>>
>>> Yes, 205266 is the culprit.
>>
>> Try updating. I've made the change a no-op until I can track the
On Thu, Mar 18, 2010 at 1:38 PM, K. Macy wrote:
>>>
>>> I have the same panic. I'll try to revert 205266.
>>
>> Yes, 205266 is the culprit.
>
> Try updating. I've made the change a no-op until I can track the problem down.
Do you all have either out-of-tree modules or modules that you did not
re-
>>
>> I have the same panic. I'll try to revert 205266.
>
> Yes, 205266 is the culprit.
Try updating. I've made the change a no-op until I can track the problem down.
-Kip
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/lis
eebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
> WARNING: WITNESS option enabled, expect reduced performance.
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault virtual address = 0xf000efd2
> fault code = s
a. All rights reserved.
>> FreeBSD is a registered trademark of The FreeBSD Foundation.
>> FreeBSD 9.0-CURRENT #102 r205276: Thu Mar 18 06:06:56 PDT 2010
>> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
>> WARNING: WITNESS option enabled, expect reduced performa
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 03/18/10 09:35, David Wolfskill wrote:
> On first reboot after building & installing; yesterday (@r205249) was OK:
[ .. ]
> --- trap 0xc, eip = 0xc08853d6, esp = 0xc1420bb0, ebp = 0xc1420bd0 ---
> _mtx_lock_flags(f000ff53,0,c0cd0df2,9a2,0,...) at
SD is a registered trademark of The FreeBSD Foundation.
FreeBSD 9.0-CURRENT #102 r205276: Thu Mar 18 06:06:56 PDT 2010
r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC i386
WARNING: WITNESS option enabled, expect reduced performance.
Fatal trap 12: page fault while in kernel mod
In message <[EMAIL PROTECTED]>, Andrey Chernov writes:
>On Tue, Sep 23, 2003 at 17:47:52 +0400, Igor Timkin wrote:
>
>> panic(c2e873da,6,0,c21a6000,c03535e0) at panic+0x60
>> freerq(c358a800,c2e873b2,e4,6,dc6c1bc4) at freerq+0x100
>> complete_rqe(c3434c24,396c,6e0d1def,1b90c284,dc6c1c14) at complet
On Tue, Sep 23, 2003 at 17:47:52 +0400, Igor Timkin wrote:
> panic(c2e873da,6,0,c21a6000,c03535e0) at panic+0x60
> freerq(c358a800,c2e873b2,e4,6,dc6c1bc4) at freerq+0x100
> complete_rqe(c3434c24,396c,6e0d1def,1b90c284,dc6c1c14) at complete_rqe+0x6ca
> bufdone(c3434c24,dc6c1c5c,c0198846,c0364e9c,c0
Another panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x40
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc025a1f9
stack pointer = 0x10:0xdc6bb984
frame pointer = 0x10
I have panic:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id = 0100
fault virtual address = 0x38
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc025a224
stack pointer = 0x10:0xdc6b5b64
frame pointer = 0x10
Hi,
I was playing around with CAM and got this reproducible panic:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x46
fault code = supervisor read, page not present
instruction pointer = 0x:0xc03962fe
stack pointer = 0x10:0xd835b9b4
frame
27;s a cut/paste from the serial console:
Additional TCP options:.
Starting inetd.
Starting background file system checks in 60 seconds.
Tue Sep 2 06:05:00 PDT 2003
FreeBSD/i386 (freebeast.catwhisker.org) (cuaa0)
login:
Fatal trap 12: page fault while in kernel mode
cpuid = 1; lapic.id = 01000
On Tue, 12 Aug 2003, David Taylor wrote:
> I've been getting this occasionally (a few times a day) since I upgraded
> to -CURRENT yesterday. I tried installing Bosko's Intel Data Corruption
> patch today, to see if that changed anything, but it doesn't appear to
> have worked.
>
[snip]
*sigh*
I changed my kernel earlier
today, but if it crashes again I'll add any more information I can get.
Here's the panic message/backtrace:
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x2006218
fault code = supervisor read, page not present
At Wed, 23 Jul 2003 13:31:31 -0700 (PDT),
Doug White wrote:
>
> On Mon, 21 Jul 2003, Bjoern A. Zeeb wrote:
>
> > Thanks. This works fine. Is there any "global" solution to the problem
> > so that I won't need to patch again the time 5.2R comes out ?
>
> Smells like a good candiate for a TUNABLE.
On Mon, 21 Jul 2003, Bjoern A. Zeeb wrote:
> Thanks. This works fine. Is there any "global" solution to the problem
> so that I won't need to patch again the time 5.2R comes out ?
Smells like a good candiate for a TUNABLE.
--
Doug White| FreeBSD: The Power to Serve
[EMAIL P
On Tue, 22 Jul 2003, M. Warner Losh wrote:
Hi,
> In message: <[EMAIL PROTECTED]>
> "Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
> : On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:
> :
> : > I have similar problem.
> : > disable re-route interrupts.
> : > It's works fine.
> : >
> : > ---
In message: <[EMAIL PROTECTED]>
"Bjoern A. Zeeb" <[EMAIL PROTECTED]> writes:
: On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:
:
: > I have similar problem.
: > disable re-route interrupts.
: > It's works fine.
: >
: > --- /sys/dev/pci/pci.c.orig Tue Jul 1 23:08:32 2003
: > +++ /sys/dev/
On Mon, 21 Jul 2003, Noriyoshi Kawano wrote:
> I have similar problem.
> disable re-route interrupts.
> It's works fine.
>
> --- /sys/dev/pci/pci.c.orig Tue Jul 1 23:08:32 2003
> +++ /sys/dev/pci/pci.cMon Jul 21 11:04:55 2003
> @@ -800,7 +800,7 @@
> }
>
> if (cfg->intpin > 0
t; npx0: on motherboard
> npx0: INT 16 interface
> pcibios: BIOS version 2.10
> Using $PIR table, 10 entries at 0xc00e8790
> pcib0: at pcibus 0 on motherboard
> pci0: on pcib0
> pci_cfgintr: 0:31 INTD BIOS irq 10
> pci_cfgintr: 0:31 INTB BIOS irq 11
> agp0:
n pcib0
pci_cfgintr: 0:31 INTD BIOS irq 10
pci_cfgintr: 0:31 INTB BIOS irq 11
agp0: mem 0x4800-0x4bff at device
0.0 on pci0
pcib1: at device 1.0 on pci0
pci1: on pcib1
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x240
fault code = supervisor
kadafi kernel: Fatal trap 12: page fault while in kernel mode
Jun 16 00:42:30 kadafi kernel: fault virtual address= 0xbffe
Jun 16 00:42:30 kadafi kernel: fault code = supervisor write, page not
present
Jun 16 00:42:30 kadafi kernel: instruction pointer = 0x8:0xc02c349c
Ju
- Forwarded message from Bobb Shires <[EMAIL PROTECTED]> -
I'm trying to install 5.0-RELEASE on a Gateway Solo 5150 laptop
(PII-366/128M), can't seem to get past this situation while
booting from the CD:
Fatal trap 12: page fault while in kernel mode
fault
fer is not busy
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0x50
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc024927c
stack pointer = 0x10:0xd2b567b0
frame pointer = 0x10:0xd2b56824
code
Hi
I recompiled the official nv driver with debugging symbols: X works as
expected. My apologies if I alarmed anyone.
John Baldwin wrote:
On 22-Jan-2003 Peter Kostouros wrote:
Hi
I am having a similar problem to what has been reported previously
regarding X. Basically I get a fatal trap 12.
On 22-Jan-2003 Peter Kostouros wrote:
> Hi
>
> I am having a similar problem to what has been reported previously
> regarding X. Basically I get a fatal trap 12. (cvsup'ed about one hour
> ago.) I have attached a backtrace I hope is useful.
>
> When I started X within gdb, I received the followi
ibute 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-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
On Thu, 3 Oct 2002 07:59:44 -0700 (PDT)
David Wolfskill <[EMAIL PROTECTED]> wrote:
> Today's -CURRENT did not panic, so I'm hoping it's fixed. :-)
>
> freebeast(5.0-C)[2] uname -a
> FreeBSD freebeast.catwhisker.org 5.0-CURRENT FreeBSD 5.0-CURRENT #11:
> Thu Oct 3 07:28:05 PDT 2002
But it kill
>Date: Wed, 2 Oct 2002 14:16:03 -0700 (PDT)
>From: David Wolfskill <[EMAIL PROTECTED]>
>Saw Alfred's commit to un-break -CURRENT, did likewise locally,
>built today's -CURRENT, and an attempted multi-user boot panics:
>
Today's -CURRENT did not panic, so I'm hoping it's fixed. :-)
freebea
e(AES,md10)
pensive timeout(9) function: 0xc02125a0(0) 0.008110381
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x110
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc0153d95
stack pointer
1 - 100 of 102 matches
Mail list logo
