< said:
> If you're using a Skylake, I suspect that you can set the
> hw.skz63_enable tunable to 0 as a workaround, assuming you're not using
> any code that relies on Intel TSX. (I don't think there's anything in
> the base system that does.) There are some details in
> https://reviews.freebsd.
en observed on any of our other NFS servers.
> >>
> >> --------
> >> Fatal trap 12: page fault while in kernel mode
>
> >> --- trap 0xc, rip = 0x809a903d, rsp = 0xfe17eb8d0710, rbp =
> >> 0xfe17eb
<
said:
> On Sun, Nov 18, 2018 at 08:24:38PM -0500, Garrett Wollman wrote:
>> Has anyone seen this before? It's on a busy NFS server, but hasn't
>> been observed on any of our other NFS servers.
>>
>> -----
On Sun, Nov 18, 2018 at 08:24:38PM -0500, Garrett Wollman wrote:
> Has anyone seen this before? It's on a busy NFS server, but hasn't
> been observed on any of our other NFS servers.
>
> --------
> Fatal tra
Has anyone seen this before? It's on a busy NFS server, but hasn't
been observed on any of our other NFS servers.
----
Fatal trap 12: page fault while in kernel mode
cpuid = 35; apic id = 35
fault virtual address =
After upgrading to 11.2-RELEASE-p2, the server constantly reboots instead of
hanging at the crash-dump.
Still, I don’t get a crash dump in /var/crash
kern.corefile: %N.core
kern.coredump_devctl: 0
kern.nodump_coredump: 0
kern.coredump: 1
kern.capmode_coredump: 0
kern.sugid_coredump: 0
kern.cor
On Sun, Sep 9, 2018 at 3:59 AM Rainer Duffner
wrote:
>
>
> > Am 09.09.2018 um 11:08 schrieb Eugene Grosbein :
> >
> > This list strips attachments, so you should upload it somewhere and post
> a link.
>
>
>
> Well actually, the text you get when you post one says it’s awaiting
> moderator approva
> Am 09.09.2018 um 11:08 schrieb Eugene Grosbein :
>
> This list strips attachments, so you should upload it somewhere and post a
> link.
Well actually, the text you get when you post one says it’s awaiting moderator
approval.
But I found a way to upload it without signing up for some site
09.09.2018 5:35, Rainer Duffner wrote:
> Hi,
>
> I got a kernel panic
>
> This a a HP Gen10 system.
> It has this new Microsemi SAS HBA that only got the driver with 11.2.
>
> It’s running a syslog-server (syslog-ng)
>
> I have attached a screenshot of the panic, hopefully it comes through.
>
Hi,
I got a kernel panic
This a a HP Gen10 system.
It has this new Microsemi SAS HBA that only got the driver with 11.2.
It’s running a syslog-server (syslog-ng)
I have attached a screenshot of the panic, hopefully it comes through.
dumpdev is set to „AUTO“, but I don’t find any crashdumps in
http://eis.bris.ac.uk/~mexas/core.txt.9
vmcore.9 is >450MB:
http://cmplx.uk/pic/vmcore.9
Thanks
Anton
___
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable
Bezüglich Harry Schmalzbauer's Nachricht vom 01.08.2016 08:41 (localtime):
> Hello,
>
> unfortunately my upgrade from 10.3 to 11-BETA3 caused machine outage.
> ESP encrypted IPv6-traffic acauses a immediate crash.
Andrey V. Elsukov rapidly analysed and corrected that in HEAD with r303657.
This s
0x80ca6c2f at crypto_dispatch+0x7f
#14 0x80c9605a at esp_input+0x4fa
#15 0x80c8179b at ipsec_common_input+0x40b
#16 0x80c8222d at ipsec6_common_input+0xcd
#17 0x80c64070 at ip6_input+0xc70
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
>> (because there were enough files there) and the system eventually panicked
>> because [I assume that a memory allocation failed and] a trap 12 panic was
>> caught. I don’t have the exact details, but it should be relatively easy to
>> repro (YMMV if you have a boatload o
tually panicked
> because [I assume that a memory allocation failed and] a trap 12 panic was
> caught. I don’t have the exact details, but it should be relatively easy to
> repro (YMMV if you have a boatload of RAM):
>
> repro_end=100
> for i in $(seq 1 $repro_end); do m
Hi,
Long story short, I had a lot of mail spooled up in /var/spool. When I
did ls /var/spool, ZFS chewed up almost all 12GB of my memory in <10 mins
(because there were enough files there) and the system eventually panicked
because [I assume that a memory allocation failed and] a t
n/kern_sysctl.c:1549
>> #17 0x807160f7 in amd64_syscall (td=0xfe001e2d4900, traced=0)
>> at subr_syscall.c:135
>> #18 0x806ff66b in Xfast_syscall () at exception.S:387
>> #19 0x00080093697a in ?? ()
>> Previous frame inner to this frame (corrupt sta
On 23.09.2012 23:41, Andriy Gapon wrote:
on 23/09/2012 23:10 Barbara said the following:
After updating src on RELENG_9 from r240236 to r240821 I have rebuilt
my world+kernel.
On reboot I had a kernel panic, "supervisor read, page not present"
for process swapper.
Trying to reboot in Single User
on 23/09/2012 23:10 Barbara said the following:
> After updating src on RELENG_9 from r240236 to r240821 I have rebuilt
> my world+kernel.
> On reboot I had a kernel panic, "supervisor read, page not present"
> for process swapper.
> Trying to reboot in Single User Mode I accidentally disabled ACPI
After updating src on RELENG_9 from r240236 to r240821 I have rebuilt
my world+kernel.
On reboot I had a kernel panic, "supervisor read, page not present"
for process swapper.
Trying to reboot in Single User Mode I accidentally disabled ACPI.
Luckily the machine booted succesfully but there was not
Andriy Gapon wrote:
on 27/03/2012 18:48 Volodymyr Kostyrko said the following:
Hi all.
I'm just puzzled with this. At first I though this happens because of some
memory
problems. But now project was moved to another server with some other brands for
motherboard/memory and different cpu's. And
on 27/03/2012 18:48 Volodymyr Kostyrko said the following:
> Hi all.
>
> I'm just puzzled with this. At first I though this happens because of some
> memory
> problems. But now project was moved to another server with some other brands
> for
> motherboard/memory and different cpu's. And still on
Hi all.
I'm just puzzled with this. At first I though this happens because of
some memory problems. But now project was moved to another server with
some other brands for motherboard/memory and different cpu's. And still
once in an hour this happens again:
== screenshot
current_process = 193
On Tuesday, April 26, 2011 17:35:32 Gardner Bell wrote:
> On Tue, Apr 26, 2011 at 04:25:26PM +0200, Bernhard Schmidt wrote:
> > On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote:
> > > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt
> > > wrote:
> > > > On Tuesday, April 26, 2011 01:09:42
On Tue, Apr 26, 2011 at 04:25:26PM +0200, Bernhard Schmidt wrote:
> On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote:
> > On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt
> > wrote:
> > > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote:
> > >> Downloading a torrent with many peers o
On Tuesday, April 26, 2011 15:15:45 Gardner Bell wrote:
> On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt
> wrote:
> > On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote:
> >> Downloading a torrent with many peers on a toshiba satellite notebook
> >> using an Atheros AR5006 wireless nic cau
On Tue, Apr 26, 2011 at 4:12 AM, Bernhard Schmidt wrote:
> On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote:
>> Downloading a torrent with many peers on a toshiba satellite notebook
>> using an Atheros AR5006 wireless nic caused the following panic. This
>> is an i386 system running 8.2-STA
On Tuesday, April 26, 2011 01:09:42 Gardner Bell wrote:
> Downloading a torrent with many peers on a toshiba satellite notebook
> using an Atheros AR5006 wireless nic caused the following panic. This
> is an i386 system running 8.2-STABLE from around April 06.
Can you reproduce that?
A comment a
on 26/04/2011 02:09 Gardner Bell said the following:
> #6 0xc0bcbebc in calltrap () at /usr/src/sys/i386/i386/exception.s:166
> #7 0xc0999329 in ieee80211_tx_mgt_timeout (arg=0xc647a000)
> at /usr/src/sys/net80211/ieee80211_output.c:2478
Looks like an issue in wireless code...
--
Andriy Ga
Downloading a torrent with many peers on a toshiba satellite notebook
using an Atheros AR5006 wireless nic caused the following panic. This
is an i386 system running 8.2-STABLE from around April 06.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address
Hello, Adam.
You wrote 1 февраля 2011 г., 21:59:31:
> Did it help the problem? I think I saw a related panic today so I'm
> going to try updating past the time this was MFC'ed to 8 which I think
> was Sat Jan 22 01:34:08 2011 UTC (10 days, 17 hours ago). Thanks.
It doesn't crash anymore, but my
On 01/20/11 03:05, Lev Serebryakov wrote:
Hello, Eugene.
You wrote 19 января 2011 г., 12:50:25:
Yes, I've missed it's PRERELEASE already.
Backtrace points to the problem in em_local_timer() fixed in CURRENT
7 days ago, take a look:
http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c
Hello, Eugene.
You wrote 19 января 2011 г., 12:50:25:
> Yes, I've missed it's PRERELEASE already.
> Backtrace points to the problem in em_local_timer() fixed in CURRENT
> 7 days ago, take a look:
> http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/dev/e1000/if_em.c#rev1.65
> I run my servers with this
On 19.01.2011 15:00, Lev Serebryakov wrote:
> Hello, Eugene.
> You wrote 19 января 2011 г., 11:44:01:
>
>> There is known instability in em(4) driver in 8.2-RELEASE,
>> it may panic due to some lack of NULL pointer checks.
>> You should update to RELENG_8 containting fix and retest.
> uname -v
>
Hello, Eugene.
You wrote 19 января 2011 г., 11:44:01:
> There is known instability in em(4) driver in 8.2-RELEASE,
> it may panic due to some lack of NULL pointer checks.
> You should update to RELENG_8 containting fix and retest.
uname -v
FreeBSD 8.2-PRERELEASE #5: Sat Jan 8 14:38:46 MSK 2011
On 19.01.2011 03:12, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
> It doesn
Hello, Jeremy.
You wrote 19 января 2011 г., 0:46:54:
> CC'ing Jack Vogel of Intel, as this looks like it could be something the
> em(4) driver might be tickling. I do see it in the stack trace shortly
> before the crash. In the interim, can you please provide output from the
> following command:
Hello, Eugene.
You wrote 19 января 2011 г., 0:30:09:
> You have not mentioned what tasks does it perform.
Storage of all my data with software RAID5 + torrent-box for
25Mibt/s connection/
--
// Black Lion AKA Lev Serebryakov
___
freebsd-stable@fre
On Wed, Jan 19, 2011 at 12:12:48AM +0300, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
>
On 19.01.2011 03:12, Lev Serebryakov wrote:
> Hello, Freebsd-stable.
>
>
> One of my servers crashes about once a week, with always same
> diagnostics: "kernel trap 12 with interrupts disabled" and in same
> process: "swi4: clock"
>
> It doesn
Hi!
Just tried to rebuild FreeNAS 7 from svn with FreeBSD 8.1p2 and after
iso image rebuild I tried to start it in VMware Player 3.1.3.
--
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address
On Sun, 21 Mar 2010 00:39:01 -0400 jhell wrote:
> DDB as I have heard can be configured AFAIR to textdump but I have no
> knowledge of that.
ddb_enable="YES" in /etc/rc.conf would be enough. But I also remove "textdump
set" in kdb.enter.panic script (/etc/ddb.conf) as I prefer normal dumps (with
boxes (it is always the same core message),
saying something about
Fatal trap 12: page fault while in kernel mode [...] current process:
12
(swi2: cambio)
Can you show the stack traceback from the kernel core?
We had a problem a while ago at Isilon that I can't tell if it's
related.
On 03/16/10 00:04, O. Hartmann wrote:
On 03/15/10 18:30, Matthew Fleming wrote:
Since the last update and make world on Friday, 12th March I get a
crash
on one of my FreeBSD SMP boxes (it is always the same core message),
saying something about
Fatal trap 12: page fault while in kernel mode
On 03/15/10 18:30, Matthew Fleming wrote:
Since the last update and make world on Friday, 12th March I get a
crash
on one of my FreeBSD SMP boxes (it is always the same core message),
saying something about
Fatal trap 12: page fault while in kernel mode [...] current process:
12
(swi2
> Since the last update and make world on Friday, 12th March I get a
crash
> on one of my FreeBSD SMP boxes (it is always the same core message),
> saying something about
>
> Fatal trap 12: page fault while in kernel mode [...] current process:
12
> (swi2: cambio)
Can
Since the last update and make world on Friday, 12th March I get a crash
on one of my FreeBSD SMP boxes (it is always the same core message),
saying something about
Fatal trap 12: page fault while in kernel mode
[...]
current process: 12 (swi2: cambio)
I'm sorry not providing
Second that. Daily panics using a Tyan board w/ BCM5704. Unfortunately
unable to provide crash dump and I was forced to use a different NIC. But
for what its worth here is the relevant pciconf -lv output.
b...@pci0:2:9:0: class=0x02 card=0x164814e4 chip=0x164814e4 rev=0x03
hdr=0x00
vendor
Broadcom 5714 5715 - no problems.
2010/2/22 Denis Lamanov :
> Yes, PCIX BCM5704
> FreeBSD vpn2 8.0-STABLE FreeBSD 8.0-STABLE #1 r204028: Thu Feb 18 08:29:42
> EET 2010 ad...@vpn2:/usr/obj/usr/src/sys/GENERIC i386
>
> 2010/2/22 Pyun YongHyeon
>
>> On Mon, Feb 22, 2010 at 03:17:17PM +0200, Den
Hi Pyun,
On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote:
> Since I don't have BCM5704 hardware it's hard to find which
> revision may affect to this issue. Could you narrow down which
> revision number started showing the issue?
I have BCM5704 hardware (Tyan S2882 system board). I
Yes, PCIX BCM5704
FreeBSD vpn2 8.0-STABLE FreeBSD 8.0-STABLE #1 r204028: Thu Feb 18 08:29:42
EET 2010 ad...@vpn2:/usr/obj/usr/src/sys/GENERIC i386
2010/2/22 Pyun YongHyeon
> On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote:
> > I see same trouble (lost packets after 4 day uptim
On Mon, Feb 22, 2010 at 03:17:17PM +0200, Denis Lamanov wrote:
> I see same trouble (lost packets after 4 day uptime and reboot) :(
>
> dev.bge.0.stats.rx.FCSErrors: 18
>
You also have PCIX BCM5704 controller? What FreeBSD version do you
use?
> 2010/2/19 Slawa Olhovchenkov
>
> > On Fri, Feb 1
On Mon, Feb 22, 2010 at 10:18:47AM +0300, Slawa Olhovchenkov wrote:
> On Sun, Feb 21, 2010 at 03:41:53PM -0800, Pyun YongHyeon wrote:
>
> > On Sun, Feb 21, 2010 at 12:44:50AM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote:
> > >
> > > > Norm
vpn2# sysctl dev.bge.0.stats
dev.bge.0.stats.FramesDroppedDueToFilters: 0
dev.bge.0.stats.DmaWriteQueueFull: 0
dev.bge.0.stats.DmaWriteHighPriQueueFull: 0
dev.bge.0.stats.NoMoreRxBDs: 0
dev.bge.0.stats.InputDiscards: 0
dev.bge.0.stats.InputErrors: 0
dev.bge.0.stats.RecvThresholdHit: 36622
dev.bge.0
I see same trouble (lost packets after 4 day uptime and reboot) :(
dev.bge.0.stats.rx.FCSErrors: 18
2010/2/19 Slawa Olhovchenkov
> On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote:
>
> >
> > > dev.bge.1.stats.rx.Fragments: 1
> >
> > You received a frame that is less than 64 bytes
On Sun, Feb 21, 2010 at 03:41:53PM -0800, Pyun YongHyeon wrote:
> On Sun, Feb 21, 2010 at 12:44:50AM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 19, 2010 at 01:12:01PM -0800, Pyun YongHyeon wrote:
> >
> > > Normally you should not have any FCS errors, it could be related
> > > with signal qu
t; PS: I got kernel panic.
>
I think this is the same crash(NULL pointer dereference in
m_copym(9)) as you reported and I think this means the patch I
posted did not help to fix the panic issue.
> ===
> Fatal trap 12: page fault while in kernel mode
> cpuid = 0; apic id = 00
> fault
d Feb 16.
4. Packets don't lost immediately after reboot.
PS: I got kernel panic.
===
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xf
On Fri, Feb 19, 2010 at 11:13:59PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote:
>
> >
> > > dev.bge.1.stats.rx.Fragments: 1
> >
> > You received a frame that is less than 64 bytes with a bad FCS.
> >
> > > dev.bge.1.stats.rx.UcastPkts: 29565
On Fri, Feb 19, 2010 at 12:06:47PM -0800, Pyun YongHyeon wrote:
>
> > dev.bge.1.stats.rx.Fragments: 1
>
> You received a frame that is less than 64 bytes with a bad FCS.
>
> > dev.bge.1.stats.rx.UcastPkts: 2956515
> > dev.bge.1.stats.rx.MulticastPkts: 0
> > dev.bge.1.stats.rx.FCSErrors: 18
>
>
On Fri, Feb 19, 2010 at 10:11:03PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 19, 2010 at 11:03:59AM -0800, Pyun YongHyeon wrote:
>
> > On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote:
> > > On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote:
> > >
> > > > O
On Fri, Feb 19, 2010 at 11:03:59AM -0800, Pyun YongHyeon wrote:
> On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote:
> > On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote:
> >
> > > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote:
> > >
> > > >
>
On Fri, Feb 19, 2010 at 03:24:15PM +0300, Slawa Olhovchenkov wrote:
> On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote:
>
> > On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote:
> >
> > >
> > > I'm still not sure whether the panic is related with bge(4) but
> > > th
On Fri, Feb 19, 2010 at 08:51:29AM +0300, Slawa Olhovchenkov wrote:
> On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote:
>
> >
> > I'm still not sure whether the panic is related with bge(4) but
> > there are a couple of missing workaround for PCIX BCM5704 silicon
> > bug in bge(4).
On Thu, Feb 18, 2010 at 04:19:13PM -0800, Pyun YongHyeon wrote:
>
> I'm still not sure whether the panic is related with bge(4) but
> there are a couple of missing workaround for PCIX BCM5704 silicon
> bug in bge(4). Did you also see the panic before updating to
> stable/8?
Before updating to st
On Thu, Feb 18, 2010 at 03:32:54PM -0800, Jeremy Chadwick wrote:
> On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote:
> > On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote:
> >
> > > > > dmesg output(only bge(4) related one).
> > > >
> > > > dmesg from boot:
> > > >
On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote:
> On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote:
>
> > > > dmesg output(only bge(4) related one).
> > >
> > > dmesg from boot:
> > >
> > > bge0: mem
> > > 0xfdf7-0xfdf7 irq 25 at device 2.0 on pci2
> >
On Fri, Feb 19, 2010 at 12:50:39AM +0300, Slawa Olhovchenkov wrote:
> On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote:
>
> > > > dmesg output(only bge(4) related one).
> > >
> > > dmesg from boot:
> > >
> > > bge0: mem
> > > 0xfdf7-0xfdf7 irq 25 at device 2.0 on pci2
> >
On Thu, Feb 18, 2010 at 01:32:13PM -0800, Pyun YongHyeon wrote:
> > > dmesg output(only bge(4) related one).
> >
> > dmesg from boot:
> >
> > bge0: mem
> > 0xfdf7-0xfdf7 irq 25 at device 2.0 on pci2
> > miibus0: on bge0
> > brgphy0: PHY 1 on miibus0
> > brgphy0: 10baseT, 10baseT-FDX
On Fri, Feb 19, 2010 at 12:24:28AM +0300, Slawa Olhovchenkov wrote:
> On Thu, Feb 18, 2010 at 11:36:12AM -0800, Pyun YongHyeon wrote:
>
> > On Thu, Feb 18, 2010 at 05:38:22PM +0300, Slawa Olhovchenkov wrote:
> > > On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote:
> > >
> > > > On Su
On Thu, Feb 18, 2010 at 11:36:12AM -0800, Pyun YongHyeon wrote:
> On Thu, Feb 18, 2010 at 05:38:22PM +0300, Slawa Olhovchenkov wrote:
> > On Tue, Feb 16, 2010 at 09:57:19AM -0800, Pyun YongHyeon wrote:
> >
> > > On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote:
> > > > I'm having repea
t 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 "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message bu
by the GNU General Public License, and you are
welcome 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 "amd
her thing I've
> noticed that may be related is a watchdog timeout on bge0 error before the
> panic. Thanks.
>
Any chance to get backtrace from the crash?
> Jan 27 15:25:01 wifi kernel:
> Jan 27 15:25:01 wifi kernel:
> Jan 27 15:25:01 wifi kernel: Fatal trap 12: page fault while
hw.bge.allow_asf: 0
On Mon, Feb 15, 2010 at 2:23 AM, Giacomo Olgeni wrote:
>
> Hello,
>
> Are you running with hw.bge.allow_asf enabled?
>
>
>
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsub
ror before the
panic. Thanks.
Jan 27 15:25:01 wifi kernel:
Jan 27 15:25:01 wifi kernel:
Jan 27 15:25:01 wifi kernel: Fatal trap 12: page fault while in kernel mode
Jan 27 15:25:01 wifi kernel: cpuid = 4; apic id = 04
Jan 27 15:25:02 wifi kernel:
Jan 27 15:25:02 wifi kernel: fault virtual address
Hello everyone,
recently I installed 8.0 on a i386 system (3gb ram,
vm.kmem_size_max=vm.kmem_size=600M, arc size limited to 80M).
Using the same options that made this system work with zfs on 7.1
while running zpool import (sometimes it is as late as zfs mount) I get a
kernel trap 12. I did
Hello,
I recently upgraded a server from RELENG_6_4 to RELENG_7_2 (both i386). Since
then, the box has started crashing regularly. The longest uptime since the
upgrade is 1d5h, the shortest is 2m35s. The backtrace is always similar:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic
From: Richard Mahlerwein
Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
To: "FreeBSD-Stable"
Date: Tuesday, September 1, 2009, 2:58 PM
> From: Gavin Atkinson
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To:
From: Richard Mahlerwein
Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
To: "FreeBSD-Stable"
Date: Tuesday, September 1, 2009, 2:58 PM
> From: Gavin Atkinson
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To:
> From: Gavin Atkinson
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein"
> Cc: "FreeBSD-Stable"
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 29 Aug 2009, Richard
> Mahlerwein wrote:
>
&g
--- On Sun, 8/30/09, Gavin Atkinson wrote:
> From: Gavin Atkinson
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: "Richard Mahlerwein"
> Cc: "FreeBSD-Stable"
> Date: Sunday, August 30, 2009, 3:47 PM
> On Sat, 2
got a core dump, apparently
triggered by devd.
Fatal trap 12: page fault while in kernel mode.
cpu id = 0; apic id = 00
fault virtual address = 0x3030313a
fault code = supervisor write, page not present
[snip]
current process = 355 (devd)
[snip]
Does anyone have a further recommendation
Richard Mahlerwein wrote:
--- On Sat, 8/29/09, Marat N.Afanasyev wrote:
From: Marat N.Afanasyev
Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
To: mahle...@yahoo.com
Cc: "FreeBSD-Stable"
Date: Saturday, August 29, 2009, 6:59 PM
such trap could be tr
near the
> end of the boot sequence I got a core dump, apparently
> triggered by devd.
>
>
> Fatal trap 12: page fault while in kernel mode.
> cpu id = 0; apic id = 00
> fault virtual address = 0x3030313a
> fault code = supervisor write, page not present
> [snip]
&
--- On Sat, 8/29/09, Marat N.Afanasyev wrote:
> From: Marat N.Afanasyev
> Subject: Re: Fatal Trap 12 in various processes always at address 0x3030313a
> To: mahle...@yahoo.com
> Cc: "FreeBSD-Stable"
> Date: Saturday, August 29, 2009, 6:59 PM
> Richard Mahlerwein
, apparently
triggered by devd.
Fatal trap 12: page fault while in kernel mode.
cpu id = 0; apic id = 00
fault virtual address = 0x3030313a
fault code = supervisor write, page not present
[snip]
current process = 355 (devd)
I redid the *whole* process in single user mode, yet no
difference. I
.
Fatal trap 12: page fault while in kernel mode.
cpu id = 0; apic id = 00
fault virtual address = 0x3030313a
fault code = supervisor write, page not present
[snip]
current process = 355 (devd)
I redid the *whole* process in single user mode, yet no
difference. I was out of town for 2.5
Details will follow if not.
>>>>
>>>> [copied from a screen dump]
>>>>
>>>> Fatal trap 12: page fault while in kernel mode
>>>> cpuid = 1; apic id = 01
>>>> fault virtual address = 0x0
>>>> fault code = super
be hardware? Details will follow if not.
> >>>>
> >>>> [copied from a screen dump]
> >>>>
> >>>> Fatal trap 12: page fault while in kernel mode
> >>>> cpuid = 1; apic id = 01
> >>>> fault virtual address = 0x0
Quoting John Baldwin :
On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote:
Quoting Ian J Hart :
Quoting Ian J Hart :
Is this likely to be hardware? Details will follow if not.
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault
On Tuesday 07 July 2009 5:51:03 am Ian J Hart wrote:
> Quoting Ian J Hart :
>
> > Quoting Ian J Hart :
> >
> >> Is this likely to be hardware? Details will follow if not.
> >>
> >> [copied from a screen dump]
> >>
> >> Fatal trap 1
Quoting Ian J Hart :
Quoting Ian J Hart :
Is this likely to be hardware? Details will follow if not.
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor write data, page not present
Quoting Ian J Hart :
Is this likely to be hardware? Details will follow if not.
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x8
Quoting Ian J Hart :
Is this likely to be hardware? Details will follow if not.
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x8
On 12/23/-58 20:59, Ian J Hart wrote:
> Is this likely to be hardware? Details will
> follow if not.
>
> [copied from a screen dump]
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x0
> fault code = supervisor w
boot or a diskless box, hence no dump
device?
Robert N M Watson
Computer Laboratory
University of Cambridge
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor write data, page not present
On Fri, 2009-07-03 at 10:06 +0100, Ian J Hart wrote:
> Is this likely to be hardware? Details will follow if not.
>
> [copied from a screen dump]
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 1; apic id = 01
> fault virtual address = 0x0
> fault code = sup
Is this likely to be hardware? Details will follow if not.
[copied from a screen dump]
Fatal trap 12: page fault while in kernel mode
cpuid = 1; apic id = 01
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x8:0x807c6c12
stack
Am Fri, 15 May 2009 12:05:47 -0400
schrieb John Baldwin :
> On Friday 15 May 2009 11:38:00 am Martin wrote:
> > Am Fri, 15 May 2009 11:09:20 -0400
> > schrieb John Baldwin :
> >
> > > x/i please. The /i decodes it as an instruction so I can see
> > > which registers it was attempting to derefere
1 - 100 of 319 matches
Mail list logo
