head -r308247 (12-CURRENT) PowerMac G5 powerpc64: ddb's dump gets "panic: vm_fault: fault on nofault entry, addr: c000000000022000"

[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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

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=,

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

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

panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe00873d8000

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 >

Re: panic: vm_fault: fault on nofault entry

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-sleepable

Re: panic: vm_fault: fault on nofault entry

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

Re: panic: vm_fault: fault on nofault entry

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

Re: panic: vm_fault: fault on nofault entry

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 for access

Re: panic: vm_fault: fault on nofault entry

) { + if ((curthread-td_pflags TDP_DEVMEMIO) != 0) { + vm_map_unlock_read(fs.map); + return (KERN_FAILURE); + } panic(vm_fault: fault on nofault entry, addr: %lx, (u_long)vaddr); } pgpxYCZdi32dp.pgp Description

Re: panic: vm_fault: fault on nofault entry

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 before and

panic: vm_fault: fault on nofault entry

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 cpuid = 1 KDB: stack backtrace

Re: panic: vm_fault: fault on nofault entry

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 amd64-marcel-freebsd... Unread portion of the kernel message buffer: panic: vm_fault

Re: panic: vm_fault: fault on nofault entry

. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: panic: vm_fault: fault on nofault entry, addr: fe03becbc000 cpuid = 23 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1838ec1180 kdb_backtrace

Re: panic: vm_fault: fault on nofault entry

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: fe03becbc000 cpuid = 23 KDB: stack

panic: vm_fault: fault on nofault entry, addr: c3dce000

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

Re: panic: vm_fault: fault on nofault entry

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 with mfs filesystem. Yaeh, latest kernel

Re: panic: vm_fault: fault on nofault entry

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

panic: vm_fault: fault on nofault entry

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... panic: vm_fault: fault on nofault entry, addr

Re: panic: vm_fault:

? It doesn't occur anymore. Seems to be fixed. Thanks! Kris Kennaway reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger(panic) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db trace Debugger(c03c1cf1,c043fd00,c03d3c82

panic: vm_fault:

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: Kris Kennaway reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger

Re: panic: vm_fault:

reported something IMHO similar on 07/31/03 panic: vm_fault: fault on nofault entry, addr: deadc000 Debugger(panic) Stopped at Debugger+0x4d: xchgl %ebx,in_Debugger.0 db trace Debugger(c03c1cf1,c043fd00,c03d3c82,e929f9e4,100) at Debugger+0x4d panic(c03d3c82,deadc000,1,e929fa80,e929fa70

USB / VM-related panic (vm_fault)

When attempting to copy files from my digital camera I get this panic in what appears to be the VM system, however I don't get a traditional panic message or a kernel dump, just a ddb backtrace. This is copied by hand so I hope there are no errors: panic: vm_fault: fault on nofault entry, addr

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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 nofault

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

: 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 (memory management fault) I'm also seeing a lot of random corruption going

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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 entry, addr

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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 coming up!

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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 have

panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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

Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000

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: panic