Re: Heavy I/O blocks FreeBSD box for several seconds
on 31/07/2011 01:55 Rick Macklem said the following: Andriv Gapon wrote: on 26/07/2011 00:44 Rick Macklem said the following: hrs sent me this panic. I'm wondering if it might be relevant to this? To 'this' what? Well, my thinking was (and it is quite likely completely incorrect) is that, since this panic is a result of holding the spin lock too long, that it might be another symptom of the same problem as when the scheduler seems to lock up for several seconds. I don't think that there is any issue with the scheduler locking up or taking too long to make scheduling decisions, at least when we talk about performance problems. There can be issues with the scheduler making sub-optimal scheduling decisions. -- The bug might be some case where the spin lock isn't being released when it should be, and that could result in Heavy I/O blocks FreeBSD box for several seconds. Note that the server was under heavy I/O load when this panic occurred. A panic is a panic. spin lock 0x80cb52c0 (sched lock 1) held by 0xff0012c7f8c0 (tid 100317) too long panic: spin lock held too long I guess it's more related to the thread on stable@ which has the panic message as its subject. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e sched_add() at sched_add+0x117 setrunnable() at setrunnable+0x78 sleepq_signal() at sleepq_signal+0x7a cv_signal() at cv_signal+0x3b xprt_active() at xprt_active+0xe3 svc_vc_soupcall() at svc_vc_soupcall+0xc sowakeup() at sowakeup+0x69 tcp_do_segment() at tcp_do_segment+0x2cbd tcp_input() at tcp_input+0xcdd ip_input() at ip_input+0xac netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17d em_rxeof() at em_rxeof+0x1ca em_handle_que() at em_handle_que+0x5b taskqueue_run_locked() at taskqueue_run_locked+0x85 taskqueue_thread_loop() at taskqueue_thread_loop+0x4e fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000160d00, rbp = 0 --- KDB: enter: panic [thread pid 0 tid 100033 ] Stopped at kdb_enter+0x3b: movq $0,0x6b4e62(%rip) db ps -- Andriy Gapon ___ 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 -- Andriy Gapon ___ 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
weekly_catman not generating the right result?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJONRDMAAoJEATO+BI/yjfBvm8H/inlCp7yRRpo5wCqGnvskZCw TueCyHrcDbgU4B+W1ZxRM02S9HpCYpPBB5EQQ6HSCIkPb3IyckK4MJzyJ+w57Dxb Z6MH0T8zQ8gtto60Xz4Hos+rPJEGRHBw645ABLGm5N2RbQ+zvzvwSR91Ma40zf/Q l5GMTq0E/L2UsKkX1WQ+RgPDJmefc4ckvOawp0XsnhNGdeAXu8K+DsmJ6x2UoKLr BwJMbytBjQJ89MCKdpWdvB0r8VmjglqoZ0J8JLdTx3Bv9cG0YAGH4vp9MG1Dv7YT PaTOof4iN/vt5ZD2nkv6IH1nAGgPcumlXqrS2UX1vw63Bpd+EyzjKW9OdUXz0Qo= =e88D -END PGP SIGNATURE- ___ 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
breakage caused by changes to mount structure
as of r224290, the mnt_flag in the mount structure was changed from 32 to 64 bits. should __FreeBSD_version be bumped to reflect breakage introduced by this change? fusefs-kmod broke after the kernel was upgraded, and the ports failed to build due to inconsistent data type as it is expecting 32bit int. thanks kit ___ 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: weekly_catman not generating the right result?
On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Now it is :) This is due to the recent changes that made groff emit ANSI sequences and catman(1) is still putting col(1) in the pipe, which is not really required and gobbles up part of the escape sequences. Please try the attached patch. Thanks. Uli commit 363e4ce24b5017eb060d6a54bebbf92608ba3873 Author: Ulrich Spörlein u...@spoerlein.net Date: Sun Jul 31 14:13:51 2011 +0200 Unbreak catman(1) by removing calls to col(1). col(1) was mangling the SGR escapes and is not strictly required. Tab compression is now done by passing -h to nroff directly. See r222650 and r222653 for more details. Reviewed by: ? Approved by: ? MFC after: 3 weeks diff --git a/usr.bin/catman/catman.c b/usr.bin/catman/catman.c index c17a091..886563b 100644 --- a/usr.bin/catman/catman.c +++ b/usr.bin/catman/catman.c @@ -432,7 +432,7 @@ process_page(char *mandir, char *src, char *cat, enum Ziptype zipped) } snprintf(tmp_file, sizeof tmp_file, %s.tmp, cat); snprintf(cmd, sizeof cmd, - %scat %s | tbl | nroff -T%s -man | col | %s %s.tmp, + %scat %s | tbl | nroff -h -T%s -man | %s %s.tmp, zipped == BZIP ? BZ2CAT_CMD : zipped == GZIP ? GZCAT_CMD : , src, nroff_device, zipped == BZIP ? BZ2_CMD : zipped == GZIP ? GZ_CMD : cat, pgp0Dx1jKVmpu.pgp Description: PGP signature
Re: weekly_catman not generating the right result?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/31/11 05:17, Ulrich Spörlein wrote: On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Now it is :) This is due to the recent changes that made groff emit ANSI sequences and catman(1) is still putting col(1) in the pipe, which is not really required and gobbles up part of the escape sequences. Please try the attached patch. Thanks. Thanks, that fixes the problem. Note that I noticed that setting PAGER to less won't work. Looking at my 8.2-RELEASE system, the rendered catpages are using ^H when highlighting while on -CURRENT it's an escape sequence (but I didn't see any change to nroff script nor catman itself)... Cheers, - -- Xin LI delp...@delphij.nethttps://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (FreeBSD) iQEcBAEBCAAGBQJONU37AAoJEATO+BI/yjfBwwkH/2lBNu/Qk+kfYqlknmBN6/f6 1JfwR/oL8ByYwc1wfDVNH9dHFgwwsmkwOja+InJNeSD62Vld8A5kLw7+AopWvsWu WRSu24qq6mP4l82K9mnClHgHEnQxmXa3AIbYcGqiTF1T8AqzVp9iqZfHnC6FDcNI l7EQZZdp3x2Uvx5ATPuTsPaZbWs5gdUC2gKEWBVlUzoIK/U2zQtBw92HbYuOuMcR dViuYNJqetuABre+m0IqslQktmd3/pIwwlJJVoDJ3KYG2SFqZTS1a4cM8dS+dX1U 8JnICR1KfkKiwKyh0QSpnoTtgy2WoCVBb5gwzXofsBZujkUbMCtkChgSxf0ulM8= =pw5b -END PGP SIGNATURE- ___ 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: weekly_catman not generating the right result?
On Sun, 2011-07-31 at 05:43:39 -0700, Xin LI wrote: On 07/31/11 05:17, Ulrich Spörlein wrote: On Sun, 2011-07-31 at 01:22:36 -0700, Xin LI wrote: Hi, I just noticed that weekly_catman is not generating the right result, e.g. instead of a highlight NAME, it gives 1mNAME0m (looks like the escape character is missing here). Is this a known issue? Now it is :) This is due to the recent changes that made groff emit ANSI sequences and catman(1) is still putting col(1) in the pipe, which is not really required and gobbles up part of the escape sequences. Please try the attached patch. Thanks. Thanks, that fixes the problem. Note that I noticed that setting PAGER to less won't work. Looking at my 8.2-RELEASE system, the rendered catpages are using ^H when highlighting while on -CURRENT it's an escape sequence (but I didn't see any change to nroff script nor catman itself)... The change that did this is r222648. You'll need to use `less -Rs' as your PAGER/MANPAGER (or export LESS=-Rs). It's debatable if we want catpages to retain the old way of marking up bold and underlined text. Ruslan: bsd.doc.mk was told to not use SGR in r222647, does it make sense to do the same for catpages? Uli pgpxjlZ2OIjHC.pgp Description: PGP signature
print_INTEL_info/print_INTEL_TLB
Just an observation: - print_INTEL_info and print_INTEL_TLB are missing from amd64 identcpu.c - print_INTEL_TLB doesn't cover all the codes defined by Intel specs - not sure; perhaps print_INTEL_info should use deterministic cache parameters as provided by CPUID 0x4 for a more complete coverage... -- Andriy Gapon ___ 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
libc build broken with clang ?
Hi! I'm writing because I'm having some issues with -CURRENT and clang in amd64. I first compiled latest revision at this date and everything went ok: [0][root@Symphony ~]# uname -a FreeBSD Symphony.Gl 9.0-CURRENT FreeBSD 9.0-CURRENT #4: Sun Jul 10 10:38:28 ART 2011 t...@symphony.gl:/usr/obj/usr/src/sys/GENERIC amd64 Now, a week or two later, something around libc broke. here's the output of make buildworld with clang : lang -fpic -DPIC -O2 -pipe -march=native -I/usr/src/lib/libc/include -I/usr/src/lib/libc/../../include -I/usr/src/lib/libc/amd64 -DNLS -D__DBINTERFACE_PRIVATE -I/usr/src/lib/libc/../../contrib/gdtoa -DINET6 -I/usr/obj/usr/src/lib/libc -I/usr/src/lib/libc/resolv -D_ACL_PRIVATE -DPOSIX_MISTAKE -I/usr/src/lib/libc/../../contrib/tzcode/stdtime -I/usr/src/lib/libc/stdtime -I/usr/src/lib/libc/locale -DBROKEN_DES -DPORTMAP -DDES_BUILTIN -I/usr/src/lib/libc/rpc -DYP -DNS_CACHING -DSYMBOL_VERSIONING -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/lib/libc/string/wmemset.c -o wmemset.So building shared library libc.so.7 /usr/bin/ld: cap_getrights.So: relocation R_X86_64_32S against `SYS_cap_getrights' can not be used when making a shared object; recompile with -fPIC cap_getrights.So: could not read symbols: Bad value clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/lib/libc. *** Error code 1 Stop in /usr/src. *** Error code 1 My kernel configurations is very generic ( here it is, just in case - http://pastebin.com/ev78UTZL ), I've just disabled debug-related stuff (I have a separate kernel for that) I also think that my make.conf has nothing special (but I'll leave it anyways - http://pastebin.com/2Pi0ejbR ) So, I'm kinda confused here (I'm still not completely familiar with the source code) Any idea ? Thanks for reading ! -- -BEGIN GEEK CODE BLOCK- Version: 3.1 GCS/M/MU d-x s+:- !a C++(+++)@$ UBLVS$ P+ L+++() E- W++ N++(+++) o K- w--- !O- M-@ !V PS++@ PE? Y+ PGP+++ t- 5? X- R* tv-- b+ DI+ D+(++) G h-- r++@ z?** --END GEEK CODE BLOCK-- signature.asc Description: This is a digitally signed message part.
Re: Heavy I/O blocks FreeBSD box for several seconds
Andriy Gapon wrote: on 31/07/2011 01:55 Rick Macklem said the following: Andriv Gapon wrote: on 26/07/2011 00:44 Rick Macklem said the following: hrs sent me this panic. I'm wondering if it might be relevant to this? To 'this' what? Well, my thinking was (and it is quite likely completely incorrect) is that, since this panic is a result of holding the spin lock too long, that it might be another symptom of the same problem as when the scheduler seems to lock up for several seconds. I don't think that there is any issue with the scheduler locking up or taking too long to make scheduling decisions, at least when we talk about performance problems. There can be issues with the scheduler making sub-optimal scheduling decisions. -- The bug might be some case where the spin lock isn't being released when it should be, and that could result in Heavy I/O blocks FreeBSD box for several seconds. Note that the server was under heavy I/O load when this panic occurred. A panic is a panic. spin lock 0x80cb52c0 (sched lock 1) held by 0xff0012c7f8c0 (tid 100317) too long panic: spin lock held too long I guess it's more related to the thread on stable@ which has the panic message as its subject. cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a kdb_backtrace() at kdb_backtrace+0x37 panic() at panic+0x187 _mtx_lock_spin_failed() at _mtx_lock_spin_failed+0x39 _mtx_lock_spin() at _mtx_lock_spin+0x9e sched_add() at sched_add+0x117 setrunnable() at setrunnable+0x78 sleepq_signal() at sleepq_signal+0x7a cv_signal() at cv_signal+0x3b xprt_active() at xprt_active+0xe3 svc_vc_soupcall() at svc_vc_soupcall+0xc sowakeup() at sowakeup+0x69 tcp_do_segment() at tcp_do_segment+0x2cbd tcp_input() at tcp_input+0xcdd ip_input() at ip_input+0xac netisr_dispatch_src() at netisr_dispatch_src+0x7e ether_demux() at ether_demux+0x14d ether_input() at ether_input+0x17d em_rxeof() at em_rxeof+0x1ca em_handle_que() at em_handle_que+0x5b taskqueue_run_locked() at taskqueue_run_locked+0x85 taskqueue_thread_loop() at taskqueue_thread_loop+0x4e fork_exit() at fork_exit+0x11f fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8000160d00, rbp = 0 --- KDB: enter: panic [thread pid 0 tid 100033 ] Stopped at kdb_enter+0x3b: movq $0,0x6b4e62(%rip) db ps -- Andriy Gapon Ok, so if the scheduler spin lock is being held too long, what could cause this, if it isn't a scheduler bug? I can't think of how NFS would affect this beyond causing a heavy I/O load, but if there is some way it does, I suppose I need to know what that is? rick ___ 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: Heavy I/O blocks FreeBSD box for several seconds
on 31/07/2011 22:03 Rick Macklem said the following: Ok, so if the scheduler spin lock is being held too long, what could cause this, if it isn't a scheduler bug? I can't think of how NFS would affect this beyond causing a heavy I/O load, but if there is some way it does, I suppose I need to know what that is? I think I've already referred to the thread on stable@. This is currently being investigated. P.S. Just a pure illustration you can grep for thread_lock to see where else outside schedulers the sched locks are taken. -- Andriy Gapon ___ 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] updated /etc/rc.d/jail and added ZFS support
Dňa 30. 7. 2011 17:29, Alexander Leidinger wrote / napísal(a): On Thu, 28 Jul 2011 16:11:37 +0200 Martin Matuska m...@freebsd.org wrote: The attached patch allows better fine-tuning of jails started via /etc/rc.d, uses the new jail(8) flags (-c -m), the persist parameter and adds ZFS support. Patch is fully backward compatible. Please review, comment and/or test my attached patch. Can you please have a look at the jail part of http://www.leidinger.net/FreeBSD/current-patches/etc:rc.d.diff and take some parts which you didn't take care about (jailname/securelevel/correctness check for fstab entries)? Bye, Alexander. I have added the check for fstab entries to my patch. The jailname/securelevel part is questionable. As to discussion with Jamie Gritton (jamie@) we should go the jail_example_params way for as many parameters as possible so we don't unnecessarily pollute rc.conf. This is not possible for persist because it has to be set to 1 on creation time for ZFS support. This way a user can set something like: jail_example_params=name=test securelevel=1 enforce_statfs=1 allow.mount=1 Patch available at: http://people.freebsd.org/~mm/patches/jail/jail_etc.patch -- Martin Matuska FreeBSD committer http://blog.vx.sk ___ 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: Heavy I/O blocks FreeBSD box for several seconds
Abdriy Gapon wrote: on 31/07/2011 22:03 Rick Macklem said the following: Ok, so if the scheduler spin lock is being held too long, what could cause this, if it isn't a scheduler bug? I can't think of how NFS would affect this beyond causing a heavy I/O load, but if there is some way it does, I suppose I need to know what that is? I think I've already referred to the thread on stable@. This is currently being investigated. P.S. Just a pure illustration you can grep for thread_lock to see where else outside schedulers the sched locks are taken. -- Yes, I see what you mean (ie. it's all over the place). Sorry about the noise, rick ___ 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
FreeBSD9 ifnet + Member Function void (*if_watchdog)(struct ifnet *ifp)
Hi, I just tried to build VMware modules for FreeBSD9-BETA1 and noticed the ifnet Member Function void (*if_watchdog)(struct ifnet *ifp) was removed from net/if_var.h. Is there a suggested replacement? PS: The man page for ifnet(9) does not reflect the remove of this (now missing) Member Function. -- olli ___ 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
