< 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.
On Sun, Nov 25, 2018 at 11:35:30PM -0500, Garrett Wollman wrote:
> < 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.
> >>
> >> ---
<
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.
>>
>>
>> Fatal trap 12: pag
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 trap 12: page fault while in
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
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
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 quality and these errors might not be correctly
> > counted.
>
> I can't che
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 quality and these errors might not be correctly
> counted.
I can't check cable and switch counters on bge1 before Feb 24.
> > 3. packets don't lost on
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
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 repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone
> > > shed light o
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 repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone
> > shed light on the below error? I unfortunately cannot provide a proper crash
> > dump. The
On Sun, Feb 14, 2010 at 10:04:58AM -0800, Nick Rogers wrote:
> I'm having repeated kernel panic issues on 8.0-RELEASE/amd64. Can anyone
> shed light on the below error? I unfortunately cannot provide a proper crash
> dump. The pointer addresses are always the same. The only other thing I've
> notic
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
Quoting John Baldwin :
On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote:
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 fr
On Tuesday 14 July 2009 9:51:01 am Ian J Hart wrote:
> 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 sc
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 virtual
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
> >
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
instruction
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:0xff
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:0xff
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 write data, page not present
>
On Fri, 3 Jul 2009, Ian J Hart wrote:
Is this likely to be hardware? Details will follow if not.
This looks like a kernel NULL pointer deference (faulting address 0x0), which
means it is most likely a kernel bug, although it could be triggered by a
hardare problem. If this early in the boo
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 = supervisor write data, page n
On Tue, 4 Jul 2006, Stanislaw Halik wrote:
On Fri, Jun 30, 2006, Robert Watson wrote:
Thanks for testing the patch -- it looks like there's a more pressing
logical problem in this code! Could you try the following simpler patch:
http://www.watson.org/~robert/freebsd/netperf/ip_ctloutput.di
On Fri, Jun 30, 2006, Robert Watson wrote:
> Thanks for testing the patch -- it looks like there's a more pressing
> logical problem in this code! Could you try the following simpler patch:
> http://www.watson.org/~robert/freebsd/netperf/ip_ctloutput.diff
> The IP option code seems not to know
On Fri, Jun 30, 2006, Robert Watson wrote:
>> Unfortunately, it still happens to crash in the same code path:
>
>> I'll be happy to test any other patches when they're available.
> Thanks for testing the patch -- it looks like there's a more pressing
> logical problem in this code! Could you tr
On Fri, 30 Jun 2006, Stanislaw Halik wrote:
Per my earlier e-mail, I had hoped to merge a larger set of changes from
HEAD that resolve the underlying problem here (that inpcb's can be detached
from a socket while the socket is still in use), but right now I'm
deferring merging those changes as
On Wed, Jun 28, 2006, Robert Watson wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an
error inside the OS?
>>> This is a known bug in the TCP code; a large set of outstanding changes
>
On Wed, Jun 28, 2006, Robert Watson wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an
error inside the OS?
>>> This is a known bug in the TCP code; a large set of outstanding changes
>
On Tue, 27 Jun 2006, Stanislaw Halik wrote:
On Tue, Jun 27, 2006, Robert Watson wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an
error inside the OS?
This is a known bug in the TCP code; a large
Stanislaw Halik wrote:
On Tue, Jun 27, 2006, Stanislaw Halik wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an
error inside the OS?
[...]
More info follows:
#7 0xc058e01a in ip_ctloutput
On Tue, Jun 27, 2006, Robert Watson wrote:
>> 6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
>> experienced people, suggest me if it's a hardware problem or is it an
>> error inside the OS?
> This is a known bug in the TCP code; a large set of outstanding changes is
> pre
On Tue, 27 Jun 2006, Stanislaw Halik wrote:
6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
experienced people, suggest me if it's a hardware problem or is it an error
inside the OS?
This is a known bug in the TCP code; a large set of outstanding changes is
present in
On Tue, Jun 27, 2006, Stanislaw Halik wrote:
> 6.1-STABLE crashed on me. I'm providing a backtrace. Could any of you,
> experienced people, suggest me if it's a hardware problem or is it an
> error inside the OS?
[...]
More info follows:
#7 0xc058e01a in ip_ctloutput (so=0xd68d5d90, sopt=0xd68d5
>>Dumping 1023 MB
>>
>>Dump failed writing data (1)
>>
>>Dump failed writing trailer (1)
>>
>>Dump complete
>>
>> any hints to finding out why i can not get a saved core on this
>> machnine would be much appreciated.
>>
> Is your swap drive your dumping to > 1023M. If not you
On Wed, 12 Jan 2005 00:29:42 -0800, Randy Bush <[EMAIL PROTECTED]> wrote:
> managed to catch a crash that seems to happen every few days. this
> was on an old build, re-cvsupping now
>
> FreeBSD foo.edu 5.3-STABLE FreeBSD 5.3-STABLE #3: Fri Dec 17 19:01:18 GMT
> 2004 [EMAIL PROTECTED]:/usr/o
Jesus Rodriguez <[EMAIL PROTECTED]> writes:
> Please, could some one give me a description of this fatal trap: ?
Please refer to section 13.13 of the FAQ.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the bod
58 matches
Mail list logo
