Konstantin Belousov wrote:
> On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote:
> > > > #16 0x80877d5a in bcopy () at
> > > > /usr/src/sys/amd64/amd64/support.S:118
> > > > #17 0x805f64e8 in uiomove_faultflag (cp=,
> > > > n=, uio=0xfe009444aae0, nofault= > > > opt
On Sun, Dec 06, 2015 at 06:51:36PM +0100, Fabian Keil wrote:
> > > #16 0x80877d5a in bcopy () at
> > > /usr/src/sys/amd64/amd64/support.S:118
> > > #17 0x805f64e8 in uiomove_faultflag (cp=,
> > > n=, uio=0xfe009444aae0, nofault= > > out>) at /usr/src/sys/kern/subr_uio.c:208
>
Konstantin Belousov wrote:
> On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote:
> > I got the following panic while trying to import a ZFS pool from a
> > geli-encrypted memory disk backed by a file located on a msdosfs partition:
> >
> I smiled.
I occasionally use this somewhat non
On Sun, Dec 06, 2015 at 11:45:32AM +0100, Fabian Keil wrote:
> I got the following panic while trying to import a ZFS pool from a
> geli-encrypted memory disk backed by a file located on a msdosfs partition:
I smiled.
>
> (kgdb) where
> #0 doadump (textdump=0) at pcpu.h:221
> #1 0x80314
On Mon, 2014-03-10 at 15:10 -0400, Glen Barber wrote:
> On Mon, Mar 10, 2014 at 09:01:12PM +0200, Konstantin Belousov wrote:
> > On Mon, Mar 10, 2014 at 02:05:08PM -0400, Glen Barber wrote:
> > > Unread portion of the kernel message buffer:
> > > Sleeping thread (tid 100702, pid 24712) owns a non-s
On Mon, Mar 10, 2014 at 09:01:12PM +0200, Konstantin Belousov wrote:
> On Mon, Mar 10, 2014 at 02:05:08PM -0400, Glen Barber wrote:
> > Unread portion of the kernel message buffer:
> > Sleeping thread (tid 100702, pid 24712) owns a non-sleepable lock
>
> Would be nice to see the full message befor
On Mon, Mar 10, 2014 at 02:05:08PM -0400, Glen Barber wrote:
> Unread portion of the kernel message buffer:
> Sleeping thread (tid 100702, pid 24712) owns a non-sleepable lock
Would be nice to see the full message before and panic from the console.
From what I see, this is a lock leak, I forgot to
On Mon, Mar 10, 2014 at 11:51:15AM -0400, Glen Barber wrote:
> On Mon, Mar 10, 2014 at 05:46:06PM +0200, Konstantin Belousov wrote:
> > On Sun, Mar 09, 2014 at 02:16:57PM -0400, Glen Barber wrote:
> > > panic: vm_fault: fault on nofault entry, addr: fe03becbc000
> >
> > I see, this panic is fo
On Mon, Mar 10, 2014 at 05:46:06PM +0200, Konstantin Belousov wrote:
> On Sun, Mar 09, 2014 at 02:16:57PM -0400, Glen Barber wrote:
> > panic: vm_fault: fault on nofault entry, addr: fe03becbc000
>
> I see, this panic is for access to the kernel map, not for the direct map.
> I think that this
On Sun, Mar 09, 2014 at 02:16:57PM -0400, Glen Barber wrote:
> panic: vm_fault: fault on nofault entry, addr: fe03becbc000
I see, this panic is for access to the kernel map, not for the direct map.
I think that this is a race with other CPU unmapping some page in the
kernel map, which cannot b
On Sun, 2014-03-09 at 14:16 -0400, Glen Barber wrote:
> On Sun, Mar 09, 2014 at 08:01:32PM +0200, Konstantin Belousov wrote:
> > On Sun, Mar 09, 2014 at 12:56:48PM -0400, Glen Barber wrote:
> > > We are having regular panics on several machines in the cluster.
> > >
> > > Below follows the script
On Sun, Mar 09, 2014 at 08:01:32PM +0200, Konstantin Belousov wrote:
> On Sun, Mar 09, 2014 at 12:56:48PM -0400, Glen Barber wrote:
> > We are having regular panics on several machines in the cluster.
> >
> > Below follows the script from the kgdb(1) session, hopefully providing
> > enough informa
On Sun, Mar 09, 2014 at 12:56:48PM -0400, Glen Barber wrote:
> We are having regular panics on several machines in the cluster.
>
> Below follows the script from the kgdb(1) session, hopefully providing
> enough information. This machine runs 11.0-CURRENT #2 r262892, from
> 2 days ago.
>
> It us
Subject: Re: panic: vm_fault: fault on nofault entry,
On Wed, 19 Nov 2003 12:38:14 +0900, Jun Kuriyama wrote:
> After CVSup'ing to latest source, it can be reproduced. It happens at
> "make release". "/mnt" below may indicates this happened at making
> floppies
After CVSup'ing to latest source, it can be reproduced. It happens at
"make release". "/mnt" below may indicates this happened at making
floppies with mfs filesystem.
- serial console
/mnt: correcting fs_sblockloc from 8192 to 65536
panic: vm_fault: fault on nofault entry, addr: daef5000
c
Jeff Roberson wrote:
On Wed, 17 Sep 2003, Florian C. Smeets wrote:
Hi.
I get this panic on a system with kernel/world from 03 September.
Usually i only run X and xawtv on that system but when i wanted to make
world today i got the panic:
This was fixed recently. Can you cvsup and rebuild?
It
On Wed, 17 Sep 2003, Florian C. Smeets wrote:
> Hi.
>
> I get this panic on a system with kernel/world from 03 September.
> Usually i only run X and xawtv on that system but when i wanted to make
> world today i got the panic:
>
This was fixed recently. Can you cvsup and rebuild?
> Kris Kennawa
On Sat, Aug 02, 2003 at 01:29:22AM -0500, Alan L. Cox wrote:
> Could you please do an objdump -d on sys_pipe.o (or similar) to verify
> that pipe_read+0x290 is the second call to uiomove() in pipe_read()?
Confirmed:
/sys/kern/sys_pipe.c:572
Kris
pgp0.pgp
Description: PGP signature
Kris Kennaway wrote:
>
> On Thu, Jul 31, 2003 at 08:04:11PM -0700, Kris Kennaway wrote:
> > On Thu, Jul 31, 2003 at 01:48:42PM -0700, Kris Kennaway wrote:
> >
> > > > I upgraded the alpha package machines tonight, and one of them fell
> > > > over shortly after taking load, with the following:
> >
On Thu, Jul 31, 2003 at 08:04:11PM -0700, Kris Kennaway wrote:
> On Thu, Jul 31, 2003 at 01:48:42PM -0700, Kris Kennaway wrote:
>
> > > I upgraded the alpha package machines tonight, and one of them fell
> > > over shortly after taking load, with the following:
> > >
> > > panic: vm_fault: fault
On Fri, Aug 01, 2003 at 10:59:06AM -0400, Andrew Gallatin wrote:
>
> Kris Kennaway writes:
> > On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
> >
> > > The crashdump might actually be useful here. You'd have only the
> > > trap() and vm_fault() frames, but at least you'd ha
Kris Kennaway writes:
> On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
>
> > The crashdump might actually be useful here. You'd have only the
> > trap() and vm_fault() frames, but at least you'd have information
> > about the state of the vm system.
>
> Two crashdumps c
On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
> The crashdump might actually be useful here. You'd have only the
> trap() and vm_fault() frames, but at least you'd have information
> about the state of the vm system.
Two crashdumps coming up! I'll move them onto beast:/j/kris
Kris Kennaway writes:
> On Thu, Jul 31, 2003 at 01:48:59AM -0700, Kris Kennaway wrote:
> > I upgraded the alpha package machines tonight, and one of them fell
> > over shortly after taking load, with the following:
<..>
> Two more panics on alpha:
>
> panic: vm_fault: fault on nofault en
On Thu, Jul 31, 2003 at 01:48:42PM -0700, Kris Kennaway wrote:
> > I upgraded the alpha package machines tonight, and one of them fell
> > over shortly after taking load, with the following:
> >
> > panic: vm_fault: fault on nofault entry, addr: fe0007e8e000
> Two more panics on alpha:
>
>
On Thu, Jul 31, 2003 at 01:48:59AM -0700, Kris Kennaway wrote:
> I upgraded the alpha package machines tonight, and one of them fell
> over shortly after taking load, with the following:
>
> panic: vm_fault: fault on nofault entry, addr: fe0007e8e000
> Stack backtrace:
> db_print_backtrace() a
26 matches
Mail list logo
