building mips world, failing ... oddly
I suspect, somehow, that I've corrupted my build machine, but I'm not sure what I could have don to do this. The following build target failure seems to bail because of libiberty.a not being a mips library as shown by an objdump -a on it (where it is an x86_64 lib). I've gone back to about two weeks ago in source, but it doesn't seem to help. I have done a recent update to my buildbox to current as of a few days ago (11.0-CURRENT #7 r262732), but I can't see anything there that is causing me problems either. ===> gnu/usr.bin/binutils/doc (depend) ===> gnu/usr.bin/cc (depend) ===> gnu/usr.bin/cc/cc_tools (depend) cc -O -pipe -G0 -march=mips32 -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips32\" -I/home/sbruno/bsd/head/../obj/mips//mips.mips/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -c /home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/gengtype.c cc -O -pipe -G0 -march=mips32 -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips32\" -I/home/sbruno/bsd/head/../obj/mips//mips.mips/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -c gengtype-yacc+%DIKED.c cc -O -pipe -G0 -march=mips32 -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips32\" -I/home/sbruno/bsd/head/../obj/mips//mips.mips/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -c gengtype-lex.c cc -O -pipe -G0 -march=mips32 -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips32\" -I/home/sbruno/bsd/head/../obj/mips//mips.mips/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -c /home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/errors.c cc -O -pipe -G0 -march=mips32 -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -DMIPS_ABI_DEFAULT=ABI_32 -DMIPS_CPU_STRING_DEFAULT=\"mips32\" -I/home/sbruno/bsd/head/../obj/mips//mips.mips/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../cc_tools -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/home/sbruno/bsd/head/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89-o gengtype gengtype.o gengtype-yacc+%DIKED.o gengtype-lex.o errors.o libiberty.a libiberty.a: could not read symbols: File format not recognized *** Error code 1 Stop. make[6]: stoppe
panic after resume, triggered by vt_switch_timer() ?
I think I have hit a panic in the code path for vt_switch_timer() when
resuming from suspend.
In both cases it happened, the laptop was suspended for >2 hours.
In both cases, c_func is vt_switch_timer(), and c_arg is a negative
value (both times it is -2133611368). I am not sure if these are valid
values for vt_switch_timer(), but it caught my eye.
The amount of time the laptop has been suspended may be unrelated, but
so far has been the only constant in numerous attempts to reproduce the
crash.
The machine is running 11.0-CURRENT #202 r262562, and the only recent
change to the kernel configuration is switching from sc(4) to vt(4)
a few weeks ago. Prior to this, I could leave the machine suspended for
several hours (sometimes up to 4 when traveling), without issue.
Script started on Sun Mar 9 20:22:44 2014
command: /bin/sh
# kgdb ./kernel.debug /var/crash/vmcore.last
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 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:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x30
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x8064378f
stack pointer = 0x28:0xfe01e47b98f0
frame pointer = 0x28:0xfe01e47b99b0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 12 (swi4: clock (0))
trap number = 12
panic: page fault
cpuid = 0
KDB: stack backtrace:
#0 0x8066c280 at kdb_backtrace+0x60
#1 0x8062bc65 at panic+0x155
#2 0x8095a78f at trap_fatal+0x38f
#3 0x8095aac1 at trap_pfault+0x321
#4 0x8095a160 at trap+0x4a0
#5 0x8093f682 at calltrap+0x8
#6 0x80643b94 at softclock+0x94
#7 0x805f6aa8 at intr_event_execute_handlers+0x1b8
#8 0x805f6ea6 at ithread_loop+0x96
#9 0x805f3c9a at fork_exit+0x9a
#10 0x8093fbbe at fork_trampoline+0xe
Uptime: 6h12m9s
Dumping 3121 out of 7951 MB:..1%..11%..21%..31%..41%..51%..61%..71%..81%..91%
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/i915kms.ko.symbols...done.
Loaded symbols for /boot/kernel/i915kms.ko.symbols
Reading symbols from /boot/kernel/drm2.ko.symbols...done.
Loaded symbols for /boot/kernel/drm2.ko.symbols
#0 doadump (textdump=) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0 doadump (textdump=) at pcpu.h:219
#1 0x8062b808 in kern_reboot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:452
#2 0x8062bca4 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:759
#3 0x8095a78f in trap_fatal (frame=, eva=)
at /usr/src/sys/amd64/amd64/trap.c:874
#4 0x8095aac1 in trap_pfault (frame=0xfe01e47b9840,
usermode=) at /usr/src/sys/amd64/amd64/trap.c:691
#5 0x8095a160 in trap (frame=0xfe01e47b9840)
at /usr/src/sys/amd64/amd64/trap.c:455
#6 0x8093f682 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:231
#7 0x8064378f in softclock_call_cc (c=0x80d3ae78,
cc=0x80eace80,
direct=0) at /usr/src/sys/kern/kern_timeout.c:703
#8 0x80643b94 in softclock (arg=0x80eace80)
at /usr/src/sys/kern/kern_timeout.c:812
#9 0x805f6aa8 in intr_event_execute_handlers (p=,
ie=0xf800031f3a00) at /usr/src/sys/kern/kern_intr.c:1263
#10 0x805f6ea6 in ithread_loop (arg=0xf8000323cf80)
at /usr/src/sys/kern/kern_intr.c:1276
#11 0x805f3c9a in fork_exit (callout=0x805f6e10 ,
arg=0xf8000323cf80, frame=0xfe01e47b9ac0) at
/usr/src/sys/kern/kern_fork.c:977
#12 0x8093fbbe in fork_trampoline () at
/usr/src/sys/amd64/amd64/exception.S:605
#13 0x in ?? ()
Current language: auto; currently minimal
(kgdb) frame 7
#7 0x8064378f in softclock_call_cc (c=0x80d3ae78,
cc=0x80eace80,
direct=0) at /usr/src/sys/kern/kern_timeout.c:703
703 class->lc_unlock(c_lock);
(kgdb) l
698 lastfunc = c_func;
699 }
700 #endif
701 CTR1(KTR_CALLOUT, "callout %p finished", c);
702 if ((c_flags & CALLOUT_RETURNUNLOCKED) == 0)
703 class->lc_unlock(c_lock);
704 skip:
705 CC_LOCK(cc);
PANIC: freebsd-10-stable - acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) Giant @ /usr/src/sys/dev/usb/input/ukbd.c:1929
Hi All! I have this kernel panic: Unread portion of the kernel message buffer: <118>[1212013] Mar 9 21:44:10 pandora-d syslogd: exiting on signal 15 [1212048] Waiting (max 60 seconds) for system process `vnlru' to stop...done [1212048] panic: acquiring blockable sleep lock with spinlock or critical section held (sleep mutex) Giant @ /usr/src/sys/dev/usb/input/ukbd.c:1929 [1212048] cpuid = 0 [1212048] KDB: stack backtrace: [1212048] db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0237bcb470 [1212048] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0237bcb520 [1212048] vpanic() at vpanic+0x127/frame 0xfe0237bcb560 [1212048] kassert_panic() at kassert_panic+0x136/frame 0xfe0237bcb5d0 [1212048] witness_checkorder() at witness_checkorder+0xfe/frame 0xfe0237bcb660 [1212048] __mtx_lock_flags() at __mtx_lock_flags+0xa9/frame 0xfe0237bcb6b0 [1212048] ukbd_ioctl() at ukbd_ioctl+0x7a/frame 0xfe0237bcb6f0 [1212048] kbdmux_ioctl() at kbdmux_ioctl+0x76c/frame 0xfe0237bcb740 [1212048] sc_cnputc() at sc_cnputc+0x90/frame 0xfe0237bcb770 [1212048] cnputc() at cnputc+0x7f/frame 0xfe0237bcb7a0 [1212048] cnputs() at cnputs+0x58/frame 0xfe0237bcb7c0 [1212048] vprintf() at vprintf+0x9a/frame 0xfe0237bcb890 [1212048] printf() at printf+0x43/frame 0xfe0237bcb8f0 [1212048] kproc_shutdown() at kproc_shutdown+0x3a/frame 0xfe0237bcb910 [1212048] kern_reboot() at kern_reboot+0x11e/frame 0xfe0237bcb980 [1212048] sys_reboot() at sys_reboot+0x58/frame 0xfe0237bcb9a0 [1212048] amd64_syscall() at amd64_syscall+0x239/frame 0xfe0237bcbab0 [1212048] Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0237bcbab0 [1212048] --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x8014f470c, rsp = 0x7fffbe88, rbp = 0x7fffbff0 --- [1212048] KDB: enter: panic [1212048] Uptime: 14d0h40m48s [1212048] Dumping 941 out of 8125 MB:..2%..11%..21%..31%..41%..51%..62%..72%..82%..91% #0 doadump (textdump=1) at pcpu.h:219 219 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=1) at pcpu.h:219 #1 0x804b71e7 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:452 #2 0x804b76f6 in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:759 #3 0x804b7586 in kassert_panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:647 #4 0x80507d4e in witness_checkorder (lock=0x80d040e0, flags=9, file=0x807b074a "/usr/src/sys/dev/usb/input/ukbd.c", line=1929, interlock=0x0) at /usr/src/sys/kern/subr_witness.c:1073 #5 0x804a3279 in __mtx_lock_flags (c=0x80d040f8, opts=0, file=0x807b074a "/usr/src/sys/dev/usb/input/ukbd.c", line=1929) at /usr/src/sys/kern/kern_mutex.c:221 #6 0x8040ed7a in ukbd_ioctl (kbd=0xfe00010e6000, cmd=537152276, arg=0xfe0237bcb75c "\002") at /usr/src/sys/dev/usb/input/ukbd.c:1929 #7 0x803452cc in kbdmux_ioctl (kbd=, arg=) at /usr/src/sys/dev/kbdmux/kbdmux.c:1149 #8 0x803d1250 in sc_cnputc (cd=0x0, c=87) at /usr/src/sys/dev/syscons/syscons.c:3715 #9 0x8046e41f in cnputc () at /usr/src/sys/kern/kern_cons.c:476 #10 0x8046e6b8 in cnputs (p=) at /usr/src/sys/kern/kern_cons.c:505 #11 0x804f3d6a in vprintf (fmt=, ap=) at /usr/src/sys/kern/subr_prf.c:402 #12 0x804f3cc3 in printf (fmt=0x0) at /usr/src/sys/kern/subr_prf.c:368 #13 0x804b778a in kproc_shutdown (arg=0xf800024504b8, howto=) at /usr/src/sys/kern/kern_shutdown.c:807 #14 0x804b6b1e in kern_reboot (howto=0) at /usr/src/sys/kern/kern_shutdown.c:324 #15 0x804b69f8 in sys_reboot (td=, uap=) at /usr/src/sys/kern/kern_shutdown.c:196 #16 0x80703cb9 in amd64_syscall (td=0xf80178ebc920, traced=0) at subr_syscall.c:134 #17 0x806e89ab in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:391 #18 0x0008014f470c in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) the relevant source code is this: (kgdb) f 6 #6 0x8040ed7a in ukbd_ioctl (kbd=0xfe00010e6000, cmd=537152276, arg=0xfe0237bcb75c "\002") at /usr/src/sys/dev/usb/input/ukbd.c:1929 1929UKBD_LOCK(); Current language: auto; currently minimal (kgdb) l 1924case KDSETLED: 1925if (!mtx_owned(&Giant) && !SCHEDULER_STOPPED()) 1926return (EDEADLK); /* best I could come up with */ 1927/* FALLTHROUGH */ 1928default: 1929UKBD_LOCK(); 1930result = ukbd_ioctl_locked(kbd, cmd, arg); 1931UKBD_UNLOCK(); 1932return (result); 1933} (kgdb) up #7 0x803452cc in kbdmux_ioctl (kbd=, arg=) at /usr/src/sys/dev/kbdmux/kbdmux.c:1149 1149(void)kbdd_ioctl(k->kbd, KDS
Re: Error when adding user with multiple groups with bsdconfig
On Fri, Jan 10, 2014 at 12:37 AM, Lundberg, Johannes wrote: > Hi > > I'm on 11-CURRENT amd64. I wanted to add a user using "bsdconfig" but got > an error when adding to several groups. > > Error message: > ERROR!: pw > pw: group `wheel daemon operator dialer network` does not exist. > > Creating a user who is only added to one group (for example wheel) works > fine. > > I have submitted a PR. What command line did you use? A user can only have one primary group (-g), but can be in multiple groups (-G). -g group Set the account's primary group to the given group. group may be defined by either its name or group number. -G grouplist Set additional group memberships for an account. grouplist is a comma, space or tab-separated list of group names or group numbers. The user's name is added to the group lists in /etc/group, and removed from any groups not specified in grouplist. Note: a user should not be added to their pri‐ mary group with grouplist. Also, group membership changes do not take effect for current user login sessions, requir‐ ing the user to reconnect to be affected by the changes. Cheers Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: vm_fault: fault on nofault entry
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 from the kgdb(1) session, hopefully providing
> > > enough information. This machine runs 11.0-CURRENT #2 r262892, from
> > > 2 days ago.
> > >
> > > It uses tmpfs(5) for the port build workspace. I have an unconfirmed
> > > suspicion that use of sysutils/lsof is involved somehow, but cannot be
> > > sure. (In my experience with panics with port building, removing lsof
> > > from the system did have an effect, but I may be going down the wrong
> > > rabbit hole.)
> > >
> >
> > This is very similar to issue reported several time ago.
> > Try this patch. I never get a feedback.
> >
> > diff --git a/sys/amd64/amd64/mem.c b/sys/amd64/amd64/mem.c
> > index a21..fd9c5df 100644
> > --- a/sys/amd64/amd64/mem.c
> > +++ b/sys/amd64/amd64/mem.c
> > @@ -98,7 +98,13 @@ memrw(struct cdev *dev, struct uio *uio, int flags)
> > kmemphys:
> > o = v & PAGE_MASK;
> > c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
> > - error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
> > + v = PHYS_TO_DMAP(v);
> > + if (v < DMAP_MIN_ADDRESS ||
> > + (v > DMAP_MIN_ADDRESS + dmaplimit &&
> > + v <= DMAP_MAX_ADDRESS) ||
> > + pmap_kextract(v) == 0)
> > + return (EFAULT);
> > + error = uiomove((void *)v, (int)c, uio);
> > continue;
> > }
> > else if (dev2unit(dev) == CDEV_MINOR_KMEM) {
>
> There is a very similar patch on one of these machines.
>
> Index: sys/amd64/amd64/mem.c
> ===
> --- sys/amd64/amd64/mem.c (revision 262298)
> +++ sys/amd64/amd64/mem.c (working copy)
> @@ -98,6 +98,12 @@
>kmemphys:
> o = v & PAGE_MASK;
> c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
> + v = PHYS_TO_DMAP(v);
> + if (v < DMAP_MIN_ADDRESS ||
> + (v > DMAP_MIN_ADDRESS + dmaplimit &&
> + v <= DMAP_MAX_ADDRESS) ||
> + pmap_kextract(v) == 0)
> + return (EFAULT);
> error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
> continue;
> }
> Index: sys/amd64/amd64/pmap.c
> ===
> --- sys/amd64/amd64/pmap.c (revision 262298)
> +++ sys/amd64/amd64/pmap.c (working copy)
> @@ -321,7 +321,7 @@
>"Number of kernel page table pages allocated on bootup");
>
>static int ndmpdp;
> -static vm_paddr_t dmaplimit;
> +vm_paddr_t dmaplimit;
>vm_offset_t kernel_vm_end = VM_MIN_KERNEL_ADDRESS;
>pt_entry_t pg_nx;
>
> Index: sys/amd64/include/pmap.h
> ===
> --- sys/amd64/include/pmap.h(revision 262298)
> +++ sys/amd64/include/pmap.h(working copy)
> @@ -369,6 +369,7 @@
>extern vm_paddr_t dump_avail[];
>extern vm_offset_t virtual_avail;
>extern vm_offset_t virtual_end;
> +extern vm_paddr_t dmaplimit;
>
>#definepmap_page_get_memattr(m)((vm_memattr_t)(m)->md.pat_mode)
>#definepmap_page_is_write_mapped(m)(((m)->aflags & PGA_WRITEABLE)
> != 0)
>
> The machine this change is on paniced today as well. That machine runs
> r262298M, and I have a vmcore from Feb 24 (there was not enough
> available space to get a crash dump today.)
>
> The backtrace from Feb 24 follows.
>
> Script started on Sun Mar 9 18:14:41 2014
> 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 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: 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() at kdb_backtrace+0x39/frame 0xfe1838ec1230
> panic() at panic+0x155/frame 0xfe1838ec12b0
> vm_fault_hold() at vm_fault_hold+0x1e7a/frame 0xfe1838ec1500
> vm_fault() at vm_fault+0x77/frame 0xfe1838ec1540
>
RE: Error when adding user with multiple groups with bsdconfig
> -Original Message- > From: Lundberg, Johannes [mailto:johan...@brilliantservice.co.jp] > Sent: Thursday, January 9, 2014 11:38 PM > To: David Chisnall > Cc: FreeBSD Current > Subject: Re: Error when adding user with multiple groups with bsdconfig > > On Fri, Jan 10, 2014 at 4:33 PM, David Chisnall wrote: > > > On 10 Jan 2014, at 00:37, Lundberg, Johannes < > > johan...@brilliantservice.co.jp> wrote: > > > > > Creating a user who is only added to one group (for example wheel) > > > works fine. > > > > I created a user with bsdconfig for the first time yesterday and found > > that their new home directory was owned by root. Did you experience > > this, or is it just me? > > > > At least all dot files were owned by root if I remember correctly. I think there is > a PR for this. > http://www.freebsd.org/cgi/query-pr.cgi?pr=misc/184681 Will address this in the rewrite of usermgmt (mirroring the recent rewrite of groupmgmt -- ala SVN revisions 262904 262908 - 262910). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD GSOC proposal in 2014
Hi All, I am a student in Columbia University (Yan Cui), and want to join the FreeBSD GSOC 2014. After scanned the idea list posted online, I think I am interested in the idea titled "user space pthread mutex lock contention profiling and lock order verification tools". I have several year experiences in kernel and user locking and believe I can complete the task in time. Currently, I wonder to know, before submitting an application on GSOC home page, do I need to submit some documents in the community (to review?) Best Wishes! Yan -- Think big; Dream impossible; Make it happen. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: vm_fault: fault on nofault entry
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 information. This machine runs 11.0-CURRENT #2 r262892, from
> > 2 days ago.
> >
> > It uses tmpfs(5) for the port build workspace. I have an unconfirmed
> > suspicion that use of sysutils/lsof is involved somehow, but cannot be
> > sure. (In my experience with panics with port building, removing lsof
> > from the system did have an effect, but I may be going down the wrong
> > rabbit hole.)
> >
>
> This is very similar to issue reported several time ago.
> Try this patch. I never get a feedback.
>
> diff --git a/sys/amd64/amd64/mem.c b/sys/amd64/amd64/mem.c
> index a21..fd9c5df 100644
> --- a/sys/amd64/amd64/mem.c
> +++ b/sys/amd64/amd64/mem.c
> @@ -98,7 +98,13 @@ memrw(struct cdev *dev, struct uio *uio, int flags)
> kmemphys:
> o = v & PAGE_MASK;
> c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
> - error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
> + v = PHYS_TO_DMAP(v);
> + if (v < DMAP_MIN_ADDRESS ||
> + (v > DMAP_MIN_ADDRESS + dmaplimit &&
> + v <= DMAP_MAX_ADDRESS) ||
> + pmap_kextract(v) == 0)
> + return (EFAULT);
> + error = uiomove((void *)v, (int)c, uio);
> continue;
> }
> else if (dev2unit(dev) == CDEV_MINOR_KMEM) {
There is a very similar patch on one of these machines.
Index: sys/amd64/amd64/mem.c
===
--- sys/amd64/amd64/mem.c (revision 262298)
+++ sys/amd64/amd64/mem.c (working copy)
@@ -98,6 +98,12 @@
kmemphys:
o = v & PAGE_MASK;
c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
+ v = PHYS_TO_DMAP(v);
+ if (v < DMAP_MIN_ADDRESS ||
+ (v > DMAP_MIN_ADDRESS + dmaplimit &&
+ v <= DMAP_MAX_ADDRESS) ||
+ pmap_kextract(v) == 0)
+ return (EFAULT);
error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
continue;
}
Index: sys/amd64/amd64/pmap.c
===
--- sys/amd64/amd64/pmap.c(revision 262298)
+++ sys/amd64/amd64/pmap.c(working copy)
@@ -321,7 +321,7 @@
"Number of kernel page table pages allocated on bootup");
static int ndmpdp;
-static vm_paddr_t dmaplimit;
+vm_paddr_t dmaplimit;
vm_offset_t kernel_vm_end = VM_MIN_KERNEL_ADDRESS;
pt_entry_t pg_nx;
Index: sys/amd64/include/pmap.h
===
--- sys/amd64/include/pmap.h (revision 262298)
+++ sys/amd64/include/pmap.h (working copy)
@@ -369,6 +369,7 @@
extern vm_paddr_t dump_avail[];
extern vm_offset_t virtual_avail;
extern vm_offset_t virtual_end;
+extern vm_paddr_t dmaplimit;
#define pmap_page_get_memattr(m)((vm_memattr_t)(m)->md.pat_mode)
#define pmap_page_is_write_mapped(m)(((m)->aflags & PGA_WRITEABLE)
!= 0)
The machine this change is on paniced today as well. That machine runs
r262298M, and I have a vmcore from Feb 24 (there was not enough
available space to get a crash dump today.)
The backtrace from Feb 24 follows.
Script started on Sun Mar 9 18:14:41 2014
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 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: 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() at kdb_backtrace+0x39/frame 0xfe1838ec1230
panic() at panic+0x155/frame 0xfe1838ec12b0
vm_fault_hold() at vm_fault_hold+0x1e7a/frame 0xfe1838ec1500
vm_fault() at vm_fault+0x77/frame 0xfe1838ec1540
trap_pfault() at trap_pfault+0x199/frame 0xfe1838ec15e0
trap() at trap+0x4a0/frame 0xfe1838ec17f0
calltrap() at calltrap+0x8/frame 0xfe1838ec17f0
--- trap 0xc, rip = 0x80d971fb, rsp = 0xfe1838ec18b0, rbp
Re: panic: vm_fault: fault on nofault entry
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 uses tmpfs(5) for the port build workspace. I have an unconfirmed
> suspicion that use of sysutils/lsof is involved somehow, but cannot be
> sure. (In my experience with panics with port building, removing lsof
> from the system did have an effect, but I may be going down the wrong
> rabbit hole.)
>
>
> Script started on Sun Mar 9 16:40:07 2014
> r...@redbuild01.nyi:/usr/obj/usr/src/sys/REDBUILD # sh
> # kgdb ./kernel.debug /var/crash/vmcore.1
> 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 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: fault on nofault entry, addr: fe035021a000
> cpuid = 1
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1839a54180
> kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1839a54230
> panic() at panic+0x155/frame 0xfe1839a542b0
> vm_fault_hold() at vm_fault_hold+0x1e7a/frame 0xfe1839a54500
> vm_fault() at vm_fault+0x77/frame 0xfe1839a54540
> trap_pfault() at trap_pfault+0x199/frame 0xfe1839a545e0
> trap() at trap+0x4a0/frame 0xfe1839a547f0
> calltrap() at calltrap+0x8/frame 0xfe1839a547f0
> --- trap 0xc, rip = 0x80d97bab, rsp = 0xfe1839a548b0, rbp =
> 0xfe1839a54910 ---
> copyout() at copyout+0x3b/frame 0xfe1839a54910
> memrw() at memrw+0x19f/frame 0xfe1839a54950
> giant_read() at giant_read+0xa4/frame 0xfe1839a54990
> devfs_read_f() at devfs_read_f+0xeb/frame 0xfe1839a549f0
> dofileread() at dofileread+0x95/frame 0xfe1839a54a40
> kern_readv() at kern_readv+0x68/frame 0xfe1839a54a90
> sys_read() at sys_read+0x63/frame 0xfe1839a54ae0
> amd64_syscall() at amd64_syscall+0x3fb/frame 0xfe1839a54bf0
> Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1839a54bf0
> --- syscall (3, FreeBSD ELF64, sys_read), rip = 0x800b8444a, rsp =
> 0x7fffd088, rbp = 0x7fffd0d0 ---
> KDB: enter: panic
This is very similar to issue reported several time ago.
Try this patch. I never get a feedback.
diff --git a/sys/amd64/amd64/mem.c b/sys/amd64/amd64/mem.c
index a21..fd9c5df 100644
--- a/sys/amd64/amd64/mem.c
+++ b/sys/amd64/amd64/mem.c
@@ -98,7 +98,13 @@ memrw(struct cdev *dev, struct uio *uio, int flags)
kmemphys:
o = v & PAGE_MASK;
c = min(uio->uio_resid, (u_int)(PAGE_SIZE - o));
- error = uiomove((void *)PHYS_TO_DMAP(v), (int)c, uio);
+ v = PHYS_TO_DMAP(v);
+ if (v < DMAP_MIN_ADDRESS ||
+ (v > DMAP_MIN_ADDRESS + dmaplimit &&
+ v <= DMAP_MAX_ADDRESS) ||
+ pmap_kextract(v) == 0)
+ return (EFAULT);
+ error = uiomove((void *)v, (int)c, uio);
continue;
}
else if (dev2unit(dev) == CDEV_MINOR_KMEM) {
pgp7EkK2uqfLA.pgp
Description: PGP signature
panic: vm_fault: fault on nofault entry
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 uses tmpfs(5) for the port build workspace. I have an unconfirmed
suspicion that use of sysutils/lsof is involved somehow, but cannot be
sure. (In my experience with panics with port building, removing lsof
from the system did have an effect, but I may be going down the wrong
rabbit hole.)
Script started on Sun Mar 9 16:40:07 2014
r...@redbuild01.nyi:/usr/obj/usr/src/sys/REDBUILD # sh
# kgdb ./kernel.debug /var/crash/vmcore.1
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 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: fault on nofault entry, addr: fe035021a000
cpuid = 1
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe1839a54180
kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe1839a54230
panic() at panic+0x155/frame 0xfe1839a542b0
vm_fault_hold() at vm_fault_hold+0x1e7a/frame 0xfe1839a54500
vm_fault() at vm_fault+0x77/frame 0xfe1839a54540
trap_pfault() at trap_pfault+0x199/frame 0xfe1839a545e0
trap() at trap+0x4a0/frame 0xfe1839a547f0
calltrap() at calltrap+0x8/frame 0xfe1839a547f0
--- trap 0xc, rip = 0x80d97bab, rsp = 0xfe1839a548b0, rbp =
0xfe1839a54910 ---
copyout() at copyout+0x3b/frame 0xfe1839a54910
memrw() at memrw+0x19f/frame 0xfe1839a54950
giant_read() at giant_read+0xa4/frame 0xfe1839a54990
devfs_read_f() at devfs_read_f+0xeb/frame 0xfe1839a549f0
dofileread() at dofileread+0x95/frame 0xfe1839a54a40
kern_readv() at kern_readv+0x68/frame 0xfe1839a54a90
sys_read() at sys_read+0x63/frame 0xfe1839a54ae0
amd64_syscall() at amd64_syscall+0x3fb/frame 0xfe1839a54bf0
Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe1839a54bf0
--- syscall (3, FreeBSD ELF64, sys_read), rip = 0x800b8444a, rsp =
0x7fffd088, rbp = 0x7fffd0d0 ---
KDB: enter: panic
Reading symbols from /boot/kernel/zfs.ko.symbols...done.
Loaded symbols for /boot/kernel/zfs.ko.symbols
Reading symbols from /boot/kernel/opensolaris.ko.symbols...done.
Loaded symbols for /boot/kernel/opensolaris.ko.symbols
Reading symbols from /boot/kernel/ums.ko.symbols...done.
Loaded symbols for /boot/kernel/ums.ko.symbols
Reading symbols from /boot/kernel/tmpfs.ko.symbols...done.
Loaded symbols for /boot/kernel/tmpfs.ko.symbols
Reading symbols from /boot/kernel/nullfs.ko.symbols...done.
Loaded symbols for /boot/kernel/nullfs.ko.symbols
Reading symbols from /boot/kernel/linprocfs.ko.symbols...done.
Loaded symbols for /boot/kernel/linprocfs.ko.symbols
Reading symbols from /boot/kernel/linux.ko.symbols...done.
Loaded symbols for /boot/kernel/linux.ko.symbols
#0 doadump (textdump=-967130448) at pcpu.h:219
219 __asm("movq %%gs:%1,%0" : "=r" (td)
(kgdb) bt
#0 doadump (textdump=-967130448) at pcpu.h:219
#1 0x8034a1a5 in db_fncall (dummy1=,
dummy2=, dummy3=, dummy4=)
at /usr/src/sys/ddb/db_command.c:578
#2 0x80349e8d in db_command (cmd_table=0x0) at
/usr/src/sys/ddb/db_command.c:449
#3 0x80349c04 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:502
#4 0x8034c660 in db_trap (type=, code=0)
at /usr/src/sys/ddb/db_main.c:231
#5 0x80987ae9 in kdb_trap (type=3, code=0, tf=)
at /usr/src/sys/kern/subr_kdb.c:656
#6 0x80d999b9 in trap (frame=0xfe1839a54160)
at /usr/src/sys/amd64/amd64/trap.c:571
#7 0x80d7e6e2 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:231
#8 0x8098724e in kdb_enter (why=0x8100f4ba "panic", msg=)
at cpufunc.h:63
#9 0x80946a75 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:752
#10 0x80c0a1fa in vm_fault_hold (map=,
vaddr=, fault_type=,
fault_flags=, m_hold=)
at /usr/src/sys/vm/vm_fault.c:272
#11 0x80c08337 in vm_fault (map=0xf8000200, vaddr=,
fault_type=1 '\001', fault_flags=128) at /usr/src/sys/vm/vm_fault.c:217
#12 0x80d9a1a9 in trap_pfault (frame=0xfe1839a54800, usermode=0)
at /usr/src/sys/amd64/amd64/trap.c:767
#13 0x80d999d0 in trap (frame=0xfe1839a54800)
at /usr/src/sys/amd64/amd64/trap.c:455
#14 0x80d7e6e2 in calltrap () at
/usr/src/sys/amd64/amd64/exception.S:231
#15 0x80d97bab in copyout () at /usr/src/sys/amd64/amd64/support.S:246
#16 0x8099c2f5 in uiomove_faultflag (cp=,
n=, uio=0xfe1839a54ab0, nofault=)
at /usr/src/sys/kern/subr_uio.c:192
#17 0x80d8612f in memrw (
