On Mon, Oct 09, 2017 at 03:39:41AM -0700, Aaron J. Grier wrote:
> On Sat, Oct 07, 2017 at 07:33:45PM +1100, Paul Ripke wrote:
> > Ok, I've bitten the bullet and switched to npf and altq. Setup seems
> > to be working so far, and it's fixed another annoyance I recently
> > noticed: ipf was blocking
On Sat, Oct 07, 2017 at 07:33:45PM +1100, Paul Ripke wrote:
> Ok, I've bitten the bullet and switched to npf and altq. Setup seems
> to be working so far, and it's fixed another annoyance I recently
> noticed: ipf was blocking in-bound syn-acks from select remote sites.
> 99% of sites were fine, a
On Oct 7, 7:33pm, s...@stix.id.au (Paul Ripke) wrote:
-- Subject: Re: Fatal page fault in cbq_enqueue()
| Ok, I've bitten the bullet and switched to npf and altq. Setup seems
| to be working so far, and it's fixed another annoyance I recently
| noticed: ipf was blocking in-bound syn-acks from
Ok, I've bitten the bullet and switched to npf and altq. Setup seems
to be working so far, and it's fixed another annoyance I recently
noticed: ipf was blocking in-bound syn-acks from select remote sites.
99% of sites were fine, a handful of sites broke. It's all fine with
npf.
--
Paul Ripke
page fault in cbq_enqueue()
} Recently upgraded to netbsd-8 branch, and I'm still seeing these
} occassionally. Eg:
}
} Sep 25 20:57:16 slave /netbsd: fatal page fault in supervisor mode
} Sep 25 20:57:16 slave /netbsd: trap type 6 code 0 rip 0x807a68b9 cs
0x8 rflags 0x10286 cr2 0x8 ilevel
On Wed, Mar 08, 2017 at 08:53:56PM -0500, Christos Zoulas wrote:
> On Mar 9, 12:16pm, s...@stix.id.au (Paul Ripke) wrote:
> -- Subject: Re: Fatal page fault in cbq_enqueue()
>
> | > > Index: altq_classq.h
> | > > =
On Mar 9, 12:16pm, s...@stix.id.au (Paul Ripke) wrote:
-- Subject: Re: Fatal page fault in cbq_enqueue()
| > > Index: altq_classq.h
| > > ===
| > > RCS file: /cvsroot/src/sys/altq/altq_classq.h,v
| > >
On Wed, Feb 08, 2017 at 11:09:55PM +1100, Paul Ripke wrote:
> On Fri, Jan 27, 2017 at 06:10:52PM +, Christos Zoulas wrote:
> > In article <20170127111545.GB9450@slave.private>,
> > Paul Ripke wrote:
> > >Still happening, although not as often. Maybe the hot weather helps...
In article <20170127111545.GB9450@slave.private>,
Paul Ripke wrote:
>Still happening, although not as often. Maybe the hot weather helps...
>
>I've got a core this time, on amd64 7.0_STABLE as of 2016-10-12.
How about this? At least you'll not crash
christos
Index:
Still happening, although not as often. Maybe the hot weather helps...
I've got a core this time, on amd64 7.0_STABLE as of 2016-10-12.
(gdb) bt
#0 0x80647ff5 in cpu_reboot (howto=howto@entry=260,
bootstr=bootstr@entry=0x0) at
So, just wondering if anyone else is using altq, or if there's some
replacement I don't know about?
I'm running NetBSD 7.0_STABLE amd64 as of 2016-10-12, and it's
panicing a couple of times a week. Latest was at:
Oct 17 07:03:04 slave /netbsd: panic: _rmc_wrr_dequeue_next
Oct 17 07:03:04 slave
I've had a handful of these, unfortunately I don't have a matching
debug kernel and dump. Just wondering if anyone else has seen this
or has any idea? Guessing spl race somewhere? What's the state of
altq?
Kernel is:
NetBSD slave 7.0_STABLE NetBSD 7.0_STABLE (SLAVE) #0: Thu Mar 31 10:32:02 AEDT
12 matches
Mail list logo