adding flex file layout support to the pNFS client
Hi, I now have a series of patches that adds Flex File layout support to the NFSv4 client for pNFS. I am now thinking about how to get them into head. 1 - I could put them up on reviews.freebsd.org, but since they are purely NFS patches and there is no Flex file layout server to test against (except the one I have in a projects tree under subversion), I doubt anyone will want to review them. 2 - I could create another projects tree under subversion but, again, I doubt anyone will be able to test them and the result will be one large patch to merge into head. 3 - I can put them in head as a series of patches and then they will be usable for testing of the pNFS server in the projects area. Some of these patches are fairly large, but they should not affect current operation of the NFS client. I am leaning towards #3, but thought I would ask others for comments w.r.t. how I should do this? Thanks for any comments, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r323694 amd64 - crash in linsysfs: Was: svn commit: r323692 - in head/sys/compat: linsysfs linux
Please try r323710. I believe you're running into the issue Hans noticed here: https://lists.freebsd.org/pipermail/svn-src-all/2017-September/151324.html . It should be addressed in r323710. Sorry, Conrad ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r323694 amd64 - crash in linsysfs: Was: svn commit: r323692 - in head/sys/compat: linsysfs linux
On Sunday 17 September 2017 23:40:16 Conrad Meyer wrote: > Author: cem > Date: Sun Sep 17 23:40:16 2017 > New Revision: 323692 > URL: https://svnweb.freebsd.org/changeset/base/323692 > > Log: > linsysfs(5): Add support for recent libdrm > > Expose more information about PCI devices (and GPUs in particular) via > linsysfs to libdrm. > > This allows unmodified modern 64-bit Linux libdrm to work, which allows > modern Linux Mesa to work. The submitter reports that he tested the > change with an Ubuntu 16.04 chroot + amdgpu from graphics/drm- next-kmod. > > PR: 222375 > Submitted by: Greg V > > Modified: > head/sys/compat/linsysfs/linsysfs.c > head/sys/compat/linux/linux_util.c > > Modified: head/sys/compat/linsysfs/linsysfs.c > Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x3f fault code = supervisor read data, page not present instruction pointer = 0x20:0x81027779 stack pointer = 0x28:0xfe034bc66e70 frame pointer = 0x28:0xfe034bc66f00 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 = 65 (mount) trap number = 12 panic: page fault cpuid = 0 time = 1505752282 Uptime: 2s ... #0 doadump (textdump=) at pcpu.h:232 232 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump (textdump=) at pcpu.h:232 #1 0x804d74f6 in kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:386 #2 0x804d791c in vpanic (fmt=, ap=) at /usr/src/sys/kern/kern_shutdown.c:779 #3 0x804d7773 in panic (fmt=) at /usr/src/sys/kern/kern_shutdown.c:710 #4 0x806bc877 in trap_fatal (frame=0xfe034bc66db0, eva=63) at /usr/src/sys/amd64/amd64/trap.c:799 #5 0x806bca59 in trap_pfault (frame=, usermode=) at pcpu.h:247 #6 0x806bc1c3 in trap (frame=0xfe034bc66db0) at /usr/src/sys/amd64/amd64/trap.c:420 #7 0x806a2363 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:237 #8 0x81027779 in linsysfs_run_bus (dir=) at /usr/src/sys/compat/linsysfs/linsysfs.c:357 #9 0x810278a1 in linsysfs_run_bus (dir=0xf8000e028600) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #10 0x810278a1 in linsysfs_run_bus (dir=0xf8000e028600) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #11 0x810278a1 in linsysfs_run_bus (dir=0xf80004c8fe00) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #12 0x810278a1 in linsysfs_run_bus (dir=0xf80004c8fe00) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #13 0x810278a1 in linsysfs_run_bus (dir=0xf80004c8fe00) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #14 0x810278a1 in linsysfs_run_bus (dir=0xf80004c8fe00) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #15 0x810278a1 in linsysfs_run_bus (dir=0xf80004c8fe00) at /usr/src/sys/compat/linsysfs/linsysfs.c:382 #16 0x81027194 in linsysfs_init (pi=, vfc=) at /usr/src/sys/compat/linsysfs/linsysfs.c:478 #17 0x80462773 in pfs_init (pi=0x810285e8, vfc=0x810284e0) at /usr/src/sys/fs/pseudofs/pseudofs.c:395 #18 0x805792b0 in vfs_modevent (mod=, type=, data=0x810284e0) at /usr/src/sys/kern/vfs_init.c:281 #19 0x804c09a8 in module_register_init (arg=0x810284c8) at /usr/src/sys/kern/kern_module.c:123 #20 0x804b5df6 in linker_load_module (kldname=, modname=0xf80004062a70 "linsysfs", parent=0x0, verinfo=, lfpp=) at /usr/src/sys/kern/kern_linker.c:234 #21 0x804b731f in kern_kldload (td=, file=, fileid=0xfe034bc677c4) at /usr/src/sys/kern/kern_linker.c:1042 #22 0x80578e1d in vfs_byname_kld ( fstype=0xf80004062a70 "linsysfs", td=0xf80004c1f560, error=0xfe034bc679ec) at /usr/src/sys/kern/vfs_init.c:147 #23 0x8057c44f in vfs_donmount (td=, fsflags=, fsoptions=0xf80004ca2400) at /usr/src/sys/kern/vfs_mount.c:1088 #24 0x8057ba70 in sys_nmount (td=0xf80004c1f560, uap=) at /usr/src/sys/kern/vfs_mount.c:421 #25 0x806bd2a2 in amd64_syscall (td=0xf80004c1f560, traced=0) at subr_syscall.c:132 #26 0x806a26bb in Xfast_syscall () at /usr/src/sys/amd64/amd64/exception.S:419 #27 0x000800a88b3a in ?? () Previous frame inner to this frame (corrupt stack?) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[HEADS UP] Update of graphics/drm-next-kmod is required after FreeBSD r323702
Hi, If you are using the drm-next-kmod from ports, don't upgrade your kernel beyond r323702 until the drm-next-kmod port has been updated. There are some changes planned for the LinuxKPI which can lead to memory leaks if you mix the versions together. Rebuilding the drm-next-kmod module is not enough to fix this. Possibly a FreeBSD kernel version check should be added to drm-next-kmod before building after the planned update. Thank you for the attention. --HPS ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
lldb unusable for regular user
Hello!
lldb coredumps for regular user, but works for root.
> uname -a
FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r323675: Sun Sep 17
21:14:33 MSK 2017 root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG
amd64
> cat test.c
#include
#include
int main()
{
printf("PID: %d\n", getpid());
sleep(10);
return 0;
}
> cc -O0 -g test.c -o test
> lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 37758 launching
Process 37758 launched: './test' (x86_64)
Segmentation fault (core dumped)
Exit 139
> sudo lldb ./test
(lldb) target create "./test"
Current executable set to './test' (x86_64).
(lldb) run
Process 37776 launching
Process 37776 launched: './test' (x86_64)
PID: 37776
Process 37776 exited with status = 0 (0x)
(lldb)
Postmortem by gdb:
> gdb ./test test.core
...
[New LWP 101456]
Core was generated by `./test'.
Program terminated with signal SIGTRAP, Trace/breakpoint trap.
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
50 {
(gdb) bt
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
(gdb) f
#0 _start (ap=0x7fffe858, cleanup=0x800605910 ) at
/usr/src/lib/csu/amd64/crt1.c:50
50 {
> gdb `which lldb` lldb.core
...
Reading symbols from /usr/bin/lldb...Reading symbols from
/usr/lib/debug//usr/bin/lldb.debug...done.
done.
[New LWP 101610]
[New LWP 100968]
[New LWP 100126]
[New LWP 101631]
[New LWP 101637]
[New LWP 101662]
[New LWP 101672]
[New LWP 100337]
[New LWP 101593]
Core was generated by `lldb ./test'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
60 ./md-unwind-support.h: No such file or directory.
[Current thread is 1 (LWP 101610)]
(gdb) f
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
60 in ./md-unwind-support.h
(gdb) bt
#0 x86_64_freebsd_fallback_frame_state (context=0x7fffddff6e20,
context=0x7fffddff6e20, fs=0x7fffddff6b70) at ./md-unwind-support.h:60
#1 uw_frame_state_for (context=context@entry=0x7fffddff6e20,
fs=fs@entry=0x7fffddff6b70) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind-dw2.c:1249
#2 0x000804f6cffb in _Unwind_ForcedUnwind_Phase2
(exc=exc@entry=0x806b23230, context=context@entry=0x7fffddff6e20) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:155
#3 0x000804f6d334 in _Unwind_ForcedUnwind (exc=0x806b23230,
stop=0x804631760 , stop_argument=) at
/wrkdirs/usr/ports/lang/gcc6/work/gcc-6.4.0/libgcc/unwind.inc:207
#4 0x0008046315c3 in _Unwind_ForcedUnwind (ex=,
stop_func=0xe, stop_arg=0x806b23000) at
/usr/src/lib/libthr/thread/thr_exit.c:106
#5 thread_unwind () at /usr/src/lib/libthr/thread/thr_exit.c:172
#6 _pthread_exit_mask (status=, mask=) at
/usr/src/lib/libthr/thread/thr_exit.c:254
#7 0x0008046313eb in _pthread_exit (status=0x806b23000) at
/usr/src/lib/libthr/thread/thr_exit.c:206
#8 0x000804623c0d in thread_start (curthread=0x806b23000) at
/usr/src/lib/libthr/thread/thr_create.c:289
#9 0x7fffdddf7000 in ?? ()
Backtrace stopped: Cannot access memory at address 0x7fffddff7000
--
Regards, | "In theory there is no difference between theory
Vladimir Zakharov | and practice. In practice there is."- Yogi Berra
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
