[A version of the below has been submitted to bugzilla as 214598. The specific
powerpc64 context is a PowerMac11,3 PowerMac G5 "Quad Core" --actually 2
sockets with each having 2 cores.]
The failure was: "panic: vm_fault: fault on nofault entry, addr:
c0022000&qu
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
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:
(kgdb) where
#0 doadump (textdump=0) at pcpu.h:221
#1 0x80314c1b in db_dump (dummy=, dummy2=false,
dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_
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
ndex 4a6495f..ab48462 100644
--- a/sys/vm/vm_fault.c
+++ b/sys/vm/vm_fault.c
@@ -269,6 +269,10 @@ RetryFault:;
map_generation = fs.map->timestamp;
if (fs.entry->eflags & MAP_ENTRY_NOFAULT) {
+ if ((curthread->td_pflags & TDP_DEVMEMI
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
> >
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.
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 can
14
> r...@redbuild04.nyi:/usr/obj/usr/src/sys/REDBUILD # sh
> # kgdb ./kernel.debug /var/crash/vmcore.3
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and you are
> welcome to change it
on, Inc.
GDB is free software, covered 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
t; This GDB was configured as "amd64-marcel-freebsd"...
>
> Unread portion of the kernel message buffer:
> panic: vm_fault: fault on nofault entry, addr: fe035021a000
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/fra
;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 buffer:
panic: vm_fault: fault on nofault entry, addr: fe035021a000
This is happening at boot time, but not every time. Yesterday's
-current, r206116. core.txt.3 is in freefall:~dougb.
#0 doadump () at pcpu.h:246
246 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) #0 doadump () at pcpu.h:246
#1 0xc05f754f in boot (howto=260)
at /usr/local/sr
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 nofa
e, 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 "i386-undermydesk-freebsd"...
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
rtly after taking load, with the following:
> > > >
> > > > panic: vm_fault: fault on nofault entry, addr: fe0007e8e000
> >
> > > Two more panics on alpha:
> > >
> > > panic: vm_fault: fault on nofault entry, addr: fe0007fde000
> >
gt;
> > > panic: vm_fault: fault on nofault entry, addr: fe0007e8e000
>
> > Two more panics on alpha:
> >
> > panic: vm_fault: fault on nofault entry, addr: fe0007fde000
>
> > fatal kernel trap:
> >
> > trap entry = 0x2 (memo
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:
>
> pan
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
&g
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:
>
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() at db_print_backtrace+0x18
backtrace() at backtrace+0x2c
panic() at panic
30 matches
Mail list logo
