On 05/07/16(Tue) 19:01, Dimitris Papastamos wrote:
> On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote:
> > Without more information it's hard to find what could be the reason
> > for this crash. Being able to reproduce the crash easily is the key
> > to debugging. Can you do that?
On Tue, Jul 05, 2016 at 07:01:11PM +0100, Dimitris Papastamos wrote:
> On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote:
> > Without more information it's hard to find what could be the reason
> > for this crash. Being able to reproduce the crash easily is the key
> > to debugging.
On Wed, 6 Jul 2016, Tobias Ulmer wrote:
> On Tue, Jul 05, 2016 at 07:01:11PM +0100, Dimitris Papastamos wrote:
> > On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote:
> > > Without more information it's hard to find what could be the reason
> > > for this crash. Being able to reproduc
On Wed, Jul 06, 2016 at 03:17:43PM +0200, Martin Pieuchot wrote:
> Thanks! So could you try the second step? After applying the diff below
> set splassert to 4 before starting your loop (sysctl kern.splassert=4).
>
> The machine should no longer panic but dump multiple traces until a NULL
> poin
On Wed, Jul 06, 2016 at 09:56:10AM -0700, Philip Guenther wrote:
> On Wed, 6 Jul 2016, Tobias Ulmer wrote:
> > On Tue, Jul 05, 2016 at 07:01:11PM +0100, Dimitris Papastamos wrote:
> > > On Tue, Jul 05, 2016 at 02:14:57PM +0200, Martin Pieuchot wrote:
> > > > Without more information it's hard to fi
Dimitris Papastamos wrote:
> On Mon, Jun 13, 2016 at 08:42:35AM -0700, Philip Guenther wrote:
> > On Sun, 12 Jun 2016, Dimitris Papastamos wrote:
> > > I was building ports and at the same time started chromium and the
> > > kernel panic-ed.
> > >
> > > This has happened a few times in the last w
