Current trouble
I just tried current as of yesterday and had to give up rather quickly. unbound sig#11'ed on bootup, couldn't find a coredump. Trying to read a PDF file with evince I got one: $ evince Fatal error 'mutex is on list' at line 424 in file /freebsd/svn_src/head/lib/libthr/thread/thr_mutex.c (errno = 2) Abort (core dumped) Backtrace looks like: #0 0x00080457648a in thr_kill () from /lib/libc.so.7 #1 0x0008045763f8 in raise () from /lib/libc.so.7 #2 0x000804574959 in abort () from /lib/libc.so.7 #3 0x00080422660a in pthread_attr_getaffinity_np () from /lib/libthr.so.3 #4 0x000804221c00 in pthread_mutex_destroy () from /lib/libthr.so.3 #5 0x000810ee0aa9 in Array::decRef () from /usr/local/lib/libpoppler.so.46 #6 0x000810f524ef in Object::free () from /usr/local/lib/libpoppler.so.46 #7 0x000810f07408 in Gfx::go () from /usr/local/lib/libpoppler.so.46 #8 0x000810f06ecb in Gfx::display () from /usr/local/lib/libpoppler.so.46 #9 0x000810f57058 in Page::displaySlice () from /usr/local/lib/libpoppler.so.46 #10 0x000810a3b3e2 in _poppler_page_render () from /usr/local/lib/libpoppler-glib.so.8 #11 0x00081080df51 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #12 0x00081080d2c5 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #13 0x000800ae4cc1 in ev_job_print_set_cairo () from /usr/local/lib/libevview3.so.3 #14 0x000800ae5bc0 in ev_job_scheduler_get_running_thread_job () from /usr/local/lib/libevview3.so.3 #15 0x0008039360fa in g_thread_proxy () from /usr/local/lib/libglib-2.0.so.0 #16 0x00080421b6e4 in pthread_create () from /lib/libthr.so.3 #17 0x in ?? () I'm not sure if these two observations are connected, but it was enough to make -current unworkable for me... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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: old bug: mount_nfs path/name is limited to 88 chars
On 2015-01-20 2:05, Xin Li wrote: Doing it in 11 makes sense since there is a compat layer for 10 now… if I knew all of the steps I would happily do them as annoys me from time to time as well with the path length issue. Compat layer may break applications in other funny ways and we probably have to return e.g. ENAMETOOLONG for legacy applications if the names are too long to fit into the buffer, but I don't see any easy solution either: I wish we have bumped it in 2003 when the struct receives its first big revamp by bumping all statistic fields to 64-bit. On 2015-01-20 1:23, Allan Jude wrote: On 2015-01-19 16:20, Garrett Especially with ZFS, I find I have a lot more mounts now, under longer and longer path names, and then I have .zfs/snapshots/snapshotnamehere/path/to/file etc. Definitely a +1 for this is something we need for 11 +1 Well to be honest: Things are already broken for me ATM. I do have paths that are too long, and tools trip over it. Things like building the locate database just don't have everything. Which is a pain, especially for finding things fast in backups of ZFS, where the path is even more convoluted that what Allan suggests So whether being bitten by the cat of the dog: it still hurts. Perhaps it is an intermediate solution to add new settings which are going to be used for userspace programs, like USER_MNAMELEN and USER_PATH_MAX. It will certainly give ENAMETOOLONG back when it involves systemcalls. But then a lot of the other tool stuff would just function. --WjW ___ 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: [RFC] kern/kern_timeout.c rewrite in progress
On Tue, Jan 20, 2015 at 08:29:47AM +0100, Hans Petter Selasky wrote: On 01/17/15 23:18, Hans Petter Selasky wrote: On 01/17/15 20:11, Jason Wolfe wrote: HPS, Just to give a quick status update, this patch has most certainly resolved our spin lock held too long panics on stable/10. Thank you to JHB for spending some time digging into the issue and leading us to td_slpcallout as the culprit, and HPS for your rewrite. I had heard rumors of other being affected by similar issues, so this seems like a fine candidate for an MFC if possible. Jason Hi Jason, I'm glad to hear that my patch has resolved your issue and I'm happy we now have a more stable system. It was actually a co-worker at work which wrote some bad code which I started debugging which then lead me to look at the callout subsystem. One bug kills the other ;-) I'm planning a MFC to 10-stable - yes, and will possibly add the _callout_stop_safe() function to not break binary compatibility with existing drivers as part of the MFC. --HPS Hi, Here is a followup patch for the TCP stack like I mentioned in the beginning of the work done on the callout subsystem: https://reviews.freebsd.org/D1563 If someone has a setup for massive TCP testing please give it a spin. I have on 10.1 (with applied r261906). ___ 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: Current trouble
On Tue, Jan 20, 2015 at 08:55:05AM +, Poul-Henning Kamp wrote: I just tried current as of yesterday and had to give up rather quickly. unbound sig#11'ed on bootup, couldn't find a coredump. Trying to read a PDF file with evince I got one: $ evince Fatal error 'mutex is on list' at line 424 in file /freebsd/svn_src/head/lib/libthr/thread/thr_mutex.c (errno = 2) Abort (core dumped) This message typically mean that non-async signal safe function was called after fork in the multithreaded process. Cannot say anything more useful. The backtrace below clearly indicates that a new thread was in the process of being created, but what was the global state of process ? Backtrace looks like: #0 0x00080457648a in thr_kill () from /lib/libc.so.7 #1 0x0008045763f8 in raise () from /lib/libc.so.7 #2 0x000804574959 in abort () from /lib/libc.so.7 #3 0x00080422660a in pthread_attr_getaffinity_np () from /lib/libthr.so.3 #4 0x000804221c00 in pthread_mutex_destroy () from /lib/libthr.so.3 #5 0x000810ee0aa9 in Array::decRef () from /usr/local/lib/libpoppler.so.46 #6 0x000810f524ef in Object::free () from /usr/local/lib/libpoppler.so.46 #7 0x000810f07408 in Gfx::go () from /usr/local/lib/libpoppler.so.46 #8 0x000810f06ecb in Gfx::display () from /usr/local/lib/libpoppler.so.46 #9 0x000810f57058 in Page::displaySlice () from /usr/local/lib/libpoppler.so.46 #10 0x000810a3b3e2 in _poppler_page_render () from /usr/local/lib/libpoppler-glib.so.8 #11 0x00081080df51 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #12 0x00081080d2c5 in register_evince_backend () from /usr/local/lib/evince/4/backends/libpdfdocument.so #13 0x000800ae4cc1 in ev_job_print_set_cairo () from /usr/local/lib/libevview3.so.3 #14 0x000800ae5bc0 in ev_job_scheduler_get_running_thread_job () from /usr/local/lib/libevview3.so.3 #15 0x0008039360fa in g_thread_proxy () from /usr/local/lib/libglib-2.0.so.0 #16 0x00080421b6e4 in pthread_create () from /lib/libthr.so.3 #17 0x in ?? () I'm not sure if these two observations are connected, but it was enough to make -current unworkable for me... -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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-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: [PATCH] nmbclusters should be always positive
On Monday, January 19, 2015 6:12:25 pm Davide Italiano wrote:
Currently, the following is allowed in FreeBSD:
root@rabbit1:/home/davide/udp-clt # sysctl kern.ipc.nmbclusters=2147483647
kern.ipc.nmbclusters: 2036598 - -2147483648
The following is an attempt of fixing.
I also think nmbcluster should actually be u_int and not it, but this
is a discussion for another day, maybe.
diff --git a/sys/kern/kern_mbuf.c b/sys/kern/kern_mbuf.c
index 7ab6509..15b38a9 100644
--- a/sys/kern/kern_mbuf.c
+++ b/sys/kern/kern_mbuf.c
@@ -162,7 +162,7 @@ sysctl_nmbclusters(SYSCTL_HANDLER_ARGS)
newnmbclusters = nmbclusters;
error = sysctl_handle_int(oidp, newnmbclusters, 0, req);
if (error == 0 req-newptr newnmbclusters != nmbclusters) {
- if (newnmbclusters nmbclusters
+ if (newnmbclusters 0 newnmbclusters nmbclusters
nmbufs = nmbclusters + nmbjumbop + nmbjumbo9 +
nmbjumbo16) {
nmbclusters = newnmbclusters;
nmbclusters = uma_zone_set_max(zone_clust,
nmbclusters);
1) If you fix this one you need to fix the other handlers in this file (all
the jumbo ones, etc.)
2) Shouldn't the 'newnmbclusters nmbclusters' check catch this already?
That should fail right? Might be worth figuring out why it isn't.
--
John Baldwin
___
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
