undefined symbol: rand_range
Hey folks, I'm getting the error below when compiling -CURRENT. Anyone else having this error? --- perf.full --- cc -target x86_64-unknown-freebsd14.0 --sysroot=/usr/obj/usr/src.git/amd64.amd64/tmp -B/usr/obj/usr/src.git/amd64.amd64/tmp/usr/bin -O -pipe -fno-common -march=core2 -fPIE -g -gz=zlib -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations -Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Qunused-arguments -pie -o perf.full perf.o util.o -lalias ld: error: undefined symbol: rand_range >>> referenced by perf.c:122 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:122) >>> perf.o:(main) >>> referenced by perf.c:123 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:123) >>> perf.o:(main) >>> referenced by perf.c:126 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:126) >>> perf.o:(main) >>> referenced 13 more times ld: error: undefined symbol: addr_eq >>> referenced by perf.c:164 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:164) >>> perf.o:(main) >>> referenced by perf.c:165 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:165) >>> perf.o:(main) >>> referenced by perf.c:246 >>> (/usr/src.git/tests/sys/netinet/libalias/perf.c:246) >>> perf.o:(main) >>> referenced 3 more times cc: error: linker command failed with exit code 1 (use -v to see invocation) -- Jeremie Le Hen j...@freebsd.org
-CURRENT compilation time
Hey, I want to build -CURRENT again from sources. It's been a long time since I hadn't done that. I'm shocked by the compilation time. I started the whole thing on Friday night and Monday morning it's still in stage 4.2 (building libraries). Through occasional glancing at the screen over the weekend, it seems obvious to me that the compilation time is utterly dominated by LLVM. Compiling C++ seems extremely CPU heavy and this is made worse by the fact LLVM is built twice (once for build/cross tools, once for the actual world). So OK, my CPU is not the most powerful out there but it's still decent [1]. So I have a couple of questions coming to my mind: 1. Is there any optimization I could benefit from? (I'm sure there's a knob to use the existing compiler instead of building a cross-compiler.) 2. More generally, isn't this compilation time not considered as a problem for developers? This seems to terribly slow down the iteration time for people working on the build system. I wouldn't be surprised if this drove people away from working on/improving that area. [1] https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i5-6260U+%40+1.80GHz=2671 Cheers, -- Jeremie Le Hen j...@freebsd.org
Re: ZFS crash with -CURRENT from Aug 23rd
On Fri, Aug 27, 2021 at 1:40 PM Jeremie Le Hen wrote: > > Hey, > > I can consistently crash my machine by creating a directory using Samba: > > Tracing pid 57242 tid 270954 td 0xfe01446941e0 > kdb_enter() at kdb_enter+0x37/frame 0xfe0147380210 > vpanic() at vpanic+0x1b2/frame 0xfe0147380260 > spl_panic() at spl_panic+0x3a/frame 0xfe01473802c0 > zfs_sa_get_xattr() at zfs_sa_get_xattr+0x1ac/frame 0xfe0147380300 > zfs_ensure_xattr_cached() at zfs_ensure_xattr_cached+0x6c/frame > 0xfe0147380330 > zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 > zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 > VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe0147380500 > null_bypass() at null_bypass+0xf6/frame 0xfe0147380680 > VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe01473806a0 > extattr_set_vp() at extattr_set_vp+0x11d/frame 0xfe0147380770 > kern_extattr_set_path() at kern_extattr_set_path+0x181/frame > 0xfe01473809a0 > sys_extattr_set_file() at sys_extattr_set_file+0x29/frame 0xfe01473809c0 > amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0147380af0 > fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0147380af0 > > Let me know if I can provide further information. Actually this may help too Dump header from device: /dev/gptid/25d0ef97-914b-11e4-9b8e-f44d30620eeb Architecture: amd64 Architecture Version: 4 Dump Length: 422400 Blocksize: 512 Compression: none Dumptime: 2021-08-27 11:27:30 +0200 Hostname: obiwan.local Magic: FreeBSD Text Dump Version String: FreeBSD 14.0-CURRENT #7 main-n248866-72a92f91f466: Mon Aug 23 14:24:56 CEST 2021 root@obiwan.local:/usr/obj/usr/src.git/amd64.amd64/sys/OBIWAN Panic String: VERIFY(zp->z_is_sa) failed Dump Parity: 1322125898 Bounds: 3 Dump Status: good -- Jeremie Le Hen j...@freebsd.org
ZFS crash with -CURRENT from Aug 23rd
Hey, I can consistently crash my machine by creating a directory using Samba: Tracing pid 57242 tid 270954 td 0xfe01446941e0 kdb_enter() at kdb_enter+0x37/frame 0xfe0147380210 vpanic() at vpanic+0x1b2/frame 0xfe0147380260 spl_panic() at spl_panic+0x3a/frame 0xfe01473802c0 zfs_sa_get_xattr() at zfs_sa_get_xattr+0x1ac/frame 0xfe0147380300 zfs_ensure_xattr_cached() at zfs_ensure_xattr_cached+0x6c/frame 0xfe0147380330 zfs_deleteextattr_sa() at zfs_deleteextattr_sa+0x1e/frame 0xfe0147380360 zfs_setextattr() at zfs_setextattr+0x1e3/frame 0xfe01473804e0 VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe0147380500 null_bypass() at null_bypass+0xf6/frame 0xfe0147380680 VOP_SETEXTATTR_APV() at VOP_SETEXTATTR_APV+0x40/frame 0xfe01473806a0 extattr_set_vp() at extattr_set_vp+0x11d/frame 0xfe0147380770 kern_extattr_set_path() at kern_extattr_set_path+0x181/frame 0xfe01473809a0 sys_extattr_set_file() at sys_extattr_set_file+0x29/frame 0xfe01473809c0 amd64_syscall() at amd64_syscall+0x12e/frame 0xfe0147380af0 fast_syscall_common() at fast_syscall_common+0xf8/frame 0xfe0147380af0 Let me know if I can provide further information. -- Jeremie Le Hen j...@freebsd.org
Re: Lenovo X1 Carbon or T460s
Thanks for the feedback on the X1 Carbon. Does anyone have experience with the T460s? On Nov 11, 2016 12:25, "Jeremie Le Hen" <j...@freebsd.org> wrote: > Hi guys, > > I'm about to purchase a new laptop, one of the two mentioned in the > subject. > > I'm looking for reports of hardware support for both of them under > FreeBSD. What are the goods and bads? > > Thanks! > -- Jeremie > ___ 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"
Lenovo X1 Carbon or T460s
Hi guys, I'm about to purchase a new laptop, one of the two mentioned in the subject. I'm looking for reports of hardware support for both of them under FreeBSD. What are the goods and bads? Thanks! -- Jeremie ___ 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"
Panic in pfsync_sendout()
Hey, I happen to have pfsync in my kernel but I don't use it. I do use pf though. It panics when my jails are starting. No idea if it's related or not. I managed to grab a core with "call doadump()" but I can't open it with kgdb(1). I get: # kgdb /boot/kernel.panic/kernel vmcore.3 [...] Attempt to extract a component of a value that is not a structure pointer. Attempt to extract a component of a value that is not a structure pointer. kgdb: kvm_read: invalid address (0x0) #0 0x in ?? () "bt" doesn't work, "info threads" yields hundreds of: * 51 Thread 0 (PID=0: /zil_clean) 0x in ?? () Why is that? This should work since How can I get a proper one? DDB spit the following stacktrace (this is amd64): Fatal trap 9: general protection fault while in kernel mode [...] pfsync_sendout() at pfsync_sendout+0x1d0 pfsyncintr() at pfsyncintr+0x42 intr_event_execute_handlers() ithread_loop() -- Jeremie Le Hen j...@freebsd.org ___ 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: Panic from vesa_configure()
On Mon, Dec 21, 2015 at 12:57 AM, Adrian Chadd <adrian.ch...@gmail.com> wrote: > can you copy/paste the file:line that each of those stackframes represents? > > I may have an idea or two.. Sure here we go: (kgdb) list *vesa_configure+0x270 0x80b25cd0 is in vesa_configure (/usr/src-svn/sys/dev/fb/vesa.c:827). (kgdb) list *vga_init+0x65 0x80b286e5 is in vga_init (/usr/src-svn/sys/dev/fb/vga.c:1402). (kgdb) list *isavga_attach+0x92 0x80b9afd2 is in isavga_attach (/usr/src-svn/sys/isa/vga_isa.c:224). -- Jeremie Le Hen j...@freebsd.org ___ 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"
Panic from vesa_configure()
Hey guys, I got the panic below with r292509. For some reason, "call doadump" didn't work (any idea why?), so I took a picture. I checked today's commits, there doesn't seem to be to be a fix. Any clue? https://people.freebsd.org/~jlh/vesa_panic.jpg Regards, -- Jeremie Le Hen j...@freebsd.org ___ 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"
panic when RACCT_RSS still 0 when struct racct destroyed
Hi all, I keep getting the following panic from time to time: https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042528.html -- Jeremie Le Hen j...@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: panic when RACCT_RSS still 0 when struct racct destroyed
Sorry for the early sending in the previous email. Hi all, I keep getting the following panic from time to time: % panic: destroying non-empty racct: 1142784 allocated for resource 4 % % cpuid = 1 % KDB: stack backtrace: % db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e6240630 % vpanic() at vpanic+0x189/frame 0xfe00e62406b0 % kassert_panic() at kassert_panic+0x132/frame 0xfe00e6240720 % racct_destroy() at racct_destroy+0x96/frame 0xfe00e6240750 % uifree() at uifree+0x5e/frame 0xfe00e6240770 % crfree() at crfree+0x48/frame 0xfe00e6240790 % thread_wait() at thread_wait+0x8e/frame 0xfe00e62407b0 % proc_reap() at proc_reap+0x40e/frame 0xfe00e6240800 % proc_to_reap() at proc_to_reap+0x332/frame 0xfe00e6240850 % kern_wait6() at kern_wait6+0x1f7/frame 0xfe00e62408f0 % sys_wait4() at sys_wait4+0x73/frame 0xfe00e6240ae0 % amd64_syscall() at amd64_syscall+0x27f/frame 0xfe00e6240bf0 % Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e6240bf0 I had already reported this two years ago, but we couldn't find a solution: https://lists.freebsd.org/pipermail/freebsd-current/2013-June/042528.html Note that since then I spotted an instance of this which wasn't for a jailed process. I made a bit more research today on RACCT_RSS throughout the kernel source. It is only set using racct_set() from - vmspace_container_set() but it only zero a couple of resources - vm_daemon() The first question, do you guys (kib, alc) think there could be a bug, or rather a race, in there? The other solution where the RSS resource can be modified is through: - racct_proc_ucred_changed() - racct_move() - racct_proc_fork() I think this is pretty much the surface through which the bug can arise. In the thread pointed above, Edward advised me to create a rctl rule to cause the uidinfo to be held, but this can happen with various users (the last one with user 2 in the root jail). Any idea what I could do to narrow the issue? Cheers, -- Jeremie Le Hen j...@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: libc.so dependency on libssp_nonshared.a
Hi Gleb, On Sun, Feb 1, 2015 at 9:24 PM, Gleb Kurtsou g...@freebsd.org wrote: I came across some build issues in libc.so and SSP. libc.ldscript (aka libc.so) unconditionally includes @@LIBDIR@@/libssp_nonshared.a libssp* are not built if WITHOUT_SSP defined. ObsoleteFiles.inc doesn't mention libssp*. Consider WITHOUT_SSP=yes case. As soon as one does clean installworld and/or removes stale libssp_nonshared.a ld fails to link anything because of missing libssp_nonshared.a I think nowadays it would make sense to get it of WITHOUT_SSP altogether. This will turn this into a non-issue. libc.so during buildworld (as found under /usr/obj) is symlink to the actual shared library, but not ldscript. Is it intentional? I wouldn't expect make -C /usr/src/bin/cat to match buildworld result closely assuming src and world are in sync, but they seem to have different idea of what libc is.. I don't remember the details except this was pretty twisted :). I don't work enough on this subject to keep it warm in my head and each time I need to go back to it, it takes me hours. The code is here if you want to give a try: http://svnweb.freebsd.org/base/head/share/mk/bsd.lib.mk?view=annotate#l335 -- Jeremie Le Hen j...@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
panic in rt2860_drain_stats_fifo()
Hi,
I've got hit by this panic numerous times over the last few months.
I've tried to debug it, but I couldn't figure out what the issue was.
It is not reproducible, sometimes the machine will work correctly for
weeks, sometimes it will happen within a few hours after a reboot.
See the attached file for the backtrace and some debugging information.
The issue is that ni-ni_vap is 0xdeadcode. But
ic-ic_node_alloc() is only called from ieee80211_alloc_node() and
ieee80211_tmp_node() which both seem to initialize ni_vap correctly,
which means the bad value comes from higher in the stack but I
couldn't figure out where.
--
Jeremie Le Hen
j...@freebsd.org
(kgdb) bt
#0 doadump (textdump=Unhandled dwarf expression opcode 0x93
) at pcpu.h:219
#1 0x80310d66 in db_fncall (dummy1=value optimized out,
dummy2=value optimized out, dummy3=value optimized out,
dummy4=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:568
#2 0x80310a4c in db_command (cmd_table=0x0)
at /usr/src-svn/sys/ddb/db_command.c:440
#3 0x803107b4 in db_command_loop ()
at /usr/src-svn/sys/ddb/db_command.c:493
#4 0x803132f0 in db_trap (type=value optimized out, code=Unhandled
dwarf expression opcode 0x93
)
at /usr/src-svn/sys/ddb/db_main.c:251
#5 0x806f60ae in kdb_trap (type=Unhandled dwarf expression opcode 0x93
)
at /usr/src-svn/sys/kern/subr_kdb.c:654
#6 0x80a31909 in trap_fatal (frame=0xfe00e50189b0,
eva=value optimized out) at /usr/src-svn/sys/amd64/amd64/trap.c:862
#7 0x80a315be in trap (frame=value optimized out)
at /usr/src-svn/sys/amd64/amd64/trap.c:201
#8 0x80a11882 in calltrap ()
at /usr/src-svn/sys/amd64/amd64/exception.S:235
#9 0x804afaeb in rt2860_drain_stats_fifo (sc=0xfed56000)
at /usr/src-svn/sys/dev/ral/rt2860.c:1128
#10 0x804af2a6 in rt2860_intr (arg=0xfed56000)
at /usr/src-svn/sys/dev/ral/rt2860.c:1435
#11 0x80683ab1 in intr_event_execute_handlers (
p=value optimized out, ie=0xf80002ae2200)
at /usr/src-svn/sys/kern/kern_intr.c:1241
#12 0x8068446c in ithread_loop (arg=0xf80002b2de20)
at /usr/src-svn/sys/kern/kern_intr.c:1254
#13 0x80681454 in fork_exit (
callout=0x806843c0 ithread_loop, arg=0xf80002b2de20,
frame=0xfe00e5018c00) at /usr/src-svn/sys/kern/kern_fork.c:996
#14 0x80a11dbe in fork_trampoline ()
at /usr/src-svn/sys/amd64/amd64/exception.S:610
#15 0x in ?? ()
Current language: auto; currently minimal
(kgdb) frame 9
#9 0x804afaeb in rt2860_drain_stats_fifo (sc=0xfed56000)
at /usr/src-svn/sys/dev/ral/rt2860.c:1128
1128ieee80211_ratectl_tx_complete(ni-ni_vap, ni,
(kgdb) print *ni [60/1893]
$1 = {ni_vap = 0xdeadc0dedeadc0de, ni_ic = 0xdeadc0dedeadc0de,
ni_table = 0xdeadc0dedeadc0de, ni_list = {tqe_next = 0xdeadc0dedeadc0de,
tqe_prev = 0xdeadc0dedeadc0de}, ni_hash = {le_next = 0xdeadc0dedeadc0de,
le_prev = 0xdeadc0dedeadc0de}, ni_refcnt = 3735929054,
ni_scangen = 3735929054, ni_flags = 3735929054, ni_associd = 49374,
ni_vlan = 57005, ni_txpower = 49374, ni_authmode = 173 '�',
ni_ath_flags = 222 '�', ni_ath_defkeyix = 49374,
ni_txparms = 0xdeadc0dedeadc0de, ni_jointime = 3735929054,
ni_challenge = 0xdeadc0dedeadc0de, ni_ies = {
wpa_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
rsn_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
wme_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
ath_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
htcap_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
htinfo_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
tdma_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
meshid_ie = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
spare = {0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds},
data = 0xdeadc0dedeadc0de Address 0xdeadc0dedeadc0de out of bounds,
len = -559038242}, ni_txseqs = {49374, 57005, 49374, 57005, 49374, 57005,
49374, 57005, 49374, 57005, 49374, 57005, 49374, 57005, 49374, 57005,
49374}, ni_rxseqs = {57005, 49374, 57005, 49374, 57005, 49374, 57005,
49374, 57005, 49374, 57005, 49374, 57005, 49374, 57005, 49374, 57005},
ni_rxfragstamp = 3735929054, ni_rxfrag = {0xdeadc0dedeadc0de,
0xdeadc0dedeadc0de, 0xdeadc0dedeadc0de}, ni_ucastkey = {
wk_keylen = 222 '�', wk_pad = 192 '�', wk_flags = 57005,
wk_keyix = 49374, wk_rxkeyix = 57005,
wk_key =
���������ï
ddb_enable=YES doesn't reboot anymore
Hi, I noticed that on panic, the default ddb script does not reboot the machine automatically anymore. It just stays at the debugger prompt. # sysctl debug.ddb.scripting.scripts debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo I don't really know when it started to behave like this as I upgrade pretty rarely. My kernel is running r268370. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Fresh-install from -current snapshot: Boot loader too large
Hi, I installed FreeBSD-11.0-CURRENT-i386-20140428-r265054-disc1.iso to a VirtualBox i386 VM. I did the most straightforward install you can possibly do (hit enter repeatedly, except for hostname and password). On the first boot I get the following error message: Boot loader too large Note that FreeBSD-11.0-CURRENT-i386-20140423-r264794-disc1.iso does not has the problem. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
=0xf80058178938, rdir=0xf80013dc0b10, buf=0xf80002bae000 ..., retbuf=0xfe00e612bab0, buflen=1016) at /usr/src-svn/sys/kern/vfs_cache.c:1330 #28 0x806f4906 in kern___getcwd (td=0xf80061c26490, buf=0x7fffcc18 Address 0x7fffcc18 out of bounds, bufseg=UIO_USERSPACE, buflen=Cannot access memory at address 0x400 ) at /usr/src-svn/sys/kern/vfs_cache.c:1094 #29 0x809b1af5 in amd64_syscall (td=0xf80061c26490, traced=0) at subr_syscall.c:133 #30 0x8099640b in Xfast_syscall () at /usr/src-svn/sys/amd64/amd64/exception.S:390 On Mon, Feb 10, 2014 at 09:56:07PM +0100, Jeremie Le Hen wrote: Hi, I run 11.0-CURRENT r260696 on amd64. I've got the following panic: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e5e53980 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e5e53a30 vpanic() at vpanic+0x126/frame 0xfe00e5e53a70 kassert_panic() at kassert_panic+0x136/frame 0xfe00e5e53ae0 _vn_lock() at _vn_lock+0x70/frame 0xfe00e5e53b50 zfs_lookup() at zfs_lookup+0x44d/frame 0xfe00e5e53be0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe00e5e53d20 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xfe00e5e53d50 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xfe00e5e53da0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e5e53dd0 null_lookup() at null_lookup+0x8b/frame 0xfe00e5e53e40 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e5e53e70 lookup() at lookup+0x590/frame 0xfe00e5e53f00 namei() at namei+0x524/frame 0xfe00e5e53fd0 vn_open_cred() at vn_open_cred+0x28f/frame 0xfe00e5e54120 vop_stdvptocnp() at vop_stdvptocnp+0x17d/frame 0xfe00e5e54460 null_vptocnp() at null_vptocnp+0x2b/frame 0xfe00e5e544c0 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xfe00e5e544f0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe00e5e54560 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xfe00e5e545c0 vn_fullpath() at vn_fullpath+0xc5/frame 0xfe00e5e54620 export_fd_to_sb() at export_fd_to_sb+0x2fd/frame 0xfe00e5e54850 kern_proc_filedesc_out() at kern_proc_filedesc_out+0x237/frame 0xfe00e5e548d0 sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x66/frame 0xfe00e5e54940 sysctl_root() at sysctl_root+0x1e4/frame 0xfe00e5e54990 userland_sysctl() at userland_sysctl+0x192/frame 0xfe00e5e54a30 sys___sysctl() at sys___sysctl+0x74/frame 0xfe00e5e54ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e5e54bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e5e54bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801027d1a, rsp = 0x7fffc758, rbp = 0x7fffc790 --- I can provide core upon request. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
On Sat, Feb 15, 2014 at 10:02:59PM +0200, Konstantin Belousov wrote:
On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
on 14/02/2014 21:18 Jeremie Le Hen said the following:
I've just got another occurence of the exact same panic. Any clue how
to debug this?
Could you please obtain *vp from frame 12 ?
The problem seems to be happening in this piece of ZFS code:
if (cnp-cn_flags ISDOTDOT) {
ltype = VOP_ISLOCKED(dvp);
VOP_UNLOCK(dvp, 0);
}
ZFS_EXIT(zfsvfs);
error = vn_lock(*vpp, cnp-cn_lkflags);
if (cnp-cn_flags ISDOTDOT)
vn_lock(dvp, ltype | LK_RETRY);
ltype is apparently LK_SHARED and the assertion is apparently triggered by
EDEADLK error. The error can occur only if a thread tries to obtain a lock
in a
shared mode when it already has the lock exclusively.
My only explanation of how this could happen is that dvp == *vpp and
cn_lkflags
is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in
the
same vnode. I think that this is only possible if dvp is the root vnode.
I am not sure if my theory is correct though.
Also, I am not sure if zfs_lookup() should be prepared to handle such a
lookup
or if this kind of lookup should be handled by upper/other layers. In this
case
these would be VFS lookup code and nullfs code.
So, is VV_ROOT flag set on the corresponding ZFS vnode ?
Just in case, you could try the following change, but I doubt that it
would have any effect. Nullfs root vnode is cached so its VV_ROOT flag
should not be lost. Also, I never seen similar issue with UFS.
diff --git a/sys/fs/nullfs/null_subr.c b/sys/fs/nullfs/null_subr.c
index fa6c4af..3f74579 100644
--- a/sys/fs/nullfs/null_subr.c
+++ b/sys/fs/nullfs/null_subr.c
@@ -251,6 +251,7 @@ null_nodeget(mp, lowervp, vpp)
vp-v_type = lowervp-v_type;
vp-v_data = xp;
vp-v_vnlock = lowervp-v_vnlock;
+ vp-v_vflag = lowervp-v_vflag VV_ROOT;
error = insmntque1(vp, mp, null_insmntque_dtr, xp);
if (error != 0)
return (error);
I've applied it and recompiling my kernel right now. I cannot really
reproduce the problem for sure: it sometimes happens when I'm performing
file manipulations on command-line on my nullfs-mounted zfs dataset;
right after the reboot, I try again and it works.
Well, now I'm writing this, this could well be the problem you describe:
right after the boot I guess the root vnode is cached and still here.
--
Jeremie Le Hen
Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
On Sat, Feb 15, 2014 at 02:12:40PM +0200, Andriy Gapon wrote:
on 14/02/2014 21:18 Jeremie Le Hen said the following:
I've just got another occurence of the exact same panic. Any clue how
to debug this?
Could you please obtain *vp from frame 12 ?
Sure:
$1 = {v_tag = 0x815019a5 zfs, v_op = 0x815164a0,
v_data = 0xf80010dcb2e0, v_mount = 0xf80010dcd660,
v_nmntvnodes = {tqe_next = 0xf80010dc7ce8,
tqe_prev = 0xf80010dcd6c0}, v_un = {vu_mount = 0x0,
vu_socket = 0x0, vu_cdev = 0x0, vu_fifoinfo = 0x0},
v_hashlist = {le_next = 0x0, le_prev = 0x0}, v_cache_src = {
lh_first = 0xf8005aeefcb0}, v_cache_dst = {tqh_first = 0x0,
tqh_last = 0xf80010dc8050}, v_cache_dd = 0x0, v_lock = {
lock_object = {lo_name = 0x815019a5 zfs,
lo_flags = 117112832, lo_data = 0, lo_witness = 0x0},
lk_lock = 18446735277920538624, lk_exslpfail = 0, lk_timo = 51,
lk_pri = 96}, v_interlock = {lock_object = {
lo_name = 0x80b46085 vnode interlock,
lo_flags = 16973824, lo_data = 0, lo_witness = 0x0},
mtx_lock = 4}, v_vnlock = 0xf80010dc8068, v_actfreelist = {
tqe_next = 0x0, tqe_prev = 0xf80010dc7da8}, v_bufobj = {
bo_lock = {lock_object = {
lo_name = 0x80b4e613 bufobj interlock,
lo_flags = 86179840, lo_data = 0, lo_witness = 0x0},
rw_lock = 1}, bo_ops = 0x80e2d440,
bo_object = 0xf800a30bbd00, bo_synclist = {le_next = 0x0,
le_prev = 0x0}, bo_private = 0xf80010dc8000,
__bo_vnode = 0xf80010dc8000, bo_clean = {bv_hd = {
tqh_first = 0x0, tqh_last = 0xf80010dc8120}, bv_root = {
pt_root = 0}, bv_cnt = 0}, bo_dirty = {bv_hd = {
tqh_first = 0x0, tqh_last = 0xf80010dc8140}, bv_root = {
pt_root = 0}, bv_cnt = 0}, bo_numoutput = 0, bo_flag = 0,
bo_bsize = 131072}, v_pollinfo = 0x0, v_label = 0x0,
v_lockf = 0x0, v_rl = {rl_waiters = {tqh_first = 0x0,
tqh_last = 0xf80010dc8188}, rl_currdep = 0x0},
v_cstart = 0, v_lasta = 0, v_lastw = 0, v_clen = 0, v_holdcnt = 7,
v_usecount = 6, v_iflag = 512, v_vflag = 1, v_writecount = 0,
v_hash = 3, v_type = VDIR}
The problem seems to be happening in this piece of ZFS code:
if (cnp-cn_flags ISDOTDOT) {
ltype = VOP_ISLOCKED(dvp);
VOP_UNLOCK(dvp, 0);
}
ZFS_EXIT(zfsvfs);
error = vn_lock(*vpp, cnp-cn_lkflags);
if (cnp-cn_flags ISDOTDOT)
vn_lock(dvp, ltype | LK_RETRY);
ltype is apparently LK_SHARED and the assertion is apparently triggered by
EDEADLK error. The error can occur only if a thread tries to obtain a lock
in a
shared mode when it already has the lock exclusively.
My only explanation of how this could happen is that dvp == *vpp and
cn_lkflags
is LK_EXCLUSIVE. In other words, this is a dot-dot lookup that results in the
same vnode. I think that this is only possible if dvp is the root vnode.
I am not sure if my theory is correct though.
Also, I am not sure if zfs_lookup() should be prepared to handle such a lookup
or if this kind of lookup should be handled by upper/other layers. In this
case
these would be VFS lookup code and nullfs code.
--
Jeremie Le Hen
Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
On Tue, Feb 18, 2014 at 03:31:53PM +0200, Andriy Gapon wrote: So, VV_ROOT is indeed set in v_vflag. Thank you. So there's no need for me to reboot with kib's patch, right? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
On Tue, Feb 11, 2014 at 10:35:29AM +0100, Jeremie Le Hen wrote: On Mon, Feb 10, 2014 at 11:48:19PM +0200, Andriy Gapon wrote: stack trace from kgdb could be a good middle ground between ddb stack trace and a full vmcore file... Here we go: #1 0x80302ca5 in db_fncall (dummy1=value optimized out, dummy2=value optimized out, dummy3=value optimized out, dummy4=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:578 #2 0x8030298d in db_command (cmd_table=value optimized out) at /usr/src-svn/sys/ddb/db_command.c:449 #3 0x80306bef in db_script_exec ( scriptname=0xfe00e5e53610 kdb.enter.panic, warnifnotfound=value optimized out) at /usr/src-svn/sys/ddb/db_script.c:302 #4 0x80306a26 in db_script_kdbenter (eventname=0x0) at /usr/src-svn/sys/ddb/db_script.c:324 #5 0x803050ab in db_trap (type=value optimized out, code=0) at /usr/src-svn/sys/ddb/db_main.c:230 #6 0x80696c33 in kdb_trap (type=3, code=0, tf=value optimized out) at /usr/src-svn/sys/kern/subr_kdb.c:656 #7 0x809b0e92 in trap (frame=0xfe00e5e53960) at /usr/src-svn/sys/amd64/amd64/trap.c:571 #8 0x80996122 in calltrap () at /usr/src-svn/sys/amd64/amd64/exception.S:231 #9 0x806963ee in kdb_enter (why=0x80b3c985 panic, msg=value optimized out) at cpufunc.h:63 #10 0x8065ec96 in vpanic (fmt=value optimized out, ap=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:752 #11 0x8065eb46 in kassert_panic (fmt=value optimized out) at /usr/src-svn/sys/kern/kern_shutdown.c:647 #12 0x807167c0 in _vn_lock (vp=0xf8000f8943b0, flags=2098176, file=0x81508fe5 /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c, line=1518) at /usr/src-svn/sys/kern/vfs_vnops.c:1436 #13 0x8148417d in zfs_lookup () at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:1518 #14 0x814844e1 in zfs_freebsd_lookup (ap=0xfe00e5e53d60) at /usr/src-svn/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vnops.c:6106 #15 0x80a6b34a in VOP_CACHEDLOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:195 #16 0x806f480f in vfs_cache_lookup (ap=value optimized out) at vnode_if.h:80 #17 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #18 0x80578ecb in null_lookup (ap=0xfe00e5e53eb8) at vnode_if.h:54 #19 0x80a6b1fa in VOP_LOOKUP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:127 #20 0x806fc980 in lookup (ndp=0xfe00e5e541b8) at vnode_if.h:54 #21 0x806fc0f4 in namei (ndp=0xfe00e5e541b8) at /usr/src-svn/sys/kern/vfs_lookup.c:298 #22 0x80715f5f in vn_open_cred (ndp=0xfe00e5e541b8, flagp=0xfe00e5e54340, cmode=0, vn_open_flags=value optimized out, cred=0xf8008c070b00, fp=0x0) at /usr/src-svn/sys/kern/vfs_vnops.c:205 #23 0x806f7b5d in vop_stdvptocnp (ap=value optimized out) at /usr/src-svn/sys/kern/vfs_default.c:797 #24 0x805797fb in null_vptocnp (ap=0xfe00e5e54508) at /usr/src-svn/sys/fs/nullfs/null_vnops.c:824 #25 0x80a6fb40 in VOP_VPTOCNP_APV (vop=value optimized out, a=value optimized out) at vnode_if.c:3647 #26 0x806f5048 in vn_vptocnp_locked (vp=0xfe00e5e54590, cred=0xf8008c070b00, buf=0xf8000474ac00 ...snipped..., buflen=0xfe00e5e5458c) at vnode_if.h:1564 #27 0x806f4b6a in vn_fullpath1 (td=0xf800399a9920, vp=0xf8009d2ba000, rdir=0xf8000f9d7938, buf=0xf8000474ac00 ...snipped..., retbuf=0xfe00e5e54660, buflen=995) at /usr/src-svn/sys/kern/vfs_cache.c:1330 #28 0x806f4de5 in vn_fullpath (td=0xf800399a9920, vn=0xf8009584c588, retbuf=0xfe00e5e54660, freebuf=0xfe00e5e54658) at /usr/src-svn/sys/kern/vfs_cache.c:1156 #29 0x8061a9dd in export_fd_to_sb (data=0xf8009584c588, type=1, fd=-1, fflags=1, refcnt=-1, offset=-1, rightsp=value optimized out, efbuf=0xf8008343a800) at /usr/src-svn/sys/kern/kern_descrip.c:3584 #30 0x8061a4c7 in kern_proc_filedesc_out (p=value optimized out, sb=0xfe00e5e548e8, maxlen=-1) at /usr/src-svn/sys/kern/kern_descrip.c:3405 #31 0x8061b2e6 in sysctl_kern_proc_filedesc ( oidp=value optimized out, arg1=value optimized out, arg2=-2135739022, req=value optimized out) at /usr/src-svn/sys/kern/kern_descrip.c:3534 #32 0x80669c84 in sysctl_root (arg1=value optimized out, arg2=value optimized out) at /usr/src-svn/sys/kern/kern_sysctl.c:1497 #33 0x8066a282 in userland_sysctl (td=value optimized out, name=0xfe00e5e54a70
Re: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
, retval=value optimized out, flags=0) at /usr/src-svn/sys/kern/kern_sysctl.c:1607 #34 0x8066a0b4 in sys___sysctl (td=0xf800399a9920, uap=0xfe00e5e54b80) at /usr/src-svn/sys/kern/kern_sysctl.c:1533 #35 0x809b1af5 in amd64_syscall (td=0xf800399a9920, traced=0) at subr_syscall.c:133 #36 0x8099640b in Xfast_syscall () at /usr/src-svn/sys/amd64/amd64/exception.S:390 -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11)
Hi, I run 11.0-CURRENT r260696 on amd64. I've got the following panic: panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e5e53980 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e5e53a30 vpanic() at vpanic+0x126/frame 0xfe00e5e53a70 kassert_panic() at kassert_panic+0x136/frame 0xfe00e5e53ae0 _vn_lock() at _vn_lock+0x70/frame 0xfe00e5e53b50 zfs_lookup() at zfs_lookup+0x44d/frame 0xfe00e5e53be0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x91/frame 0xfe00e5e53d20 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xfe00e5e53d50 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xfe00e5e53da0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e5e53dd0 null_lookup() at null_lookup+0x8b/frame 0xfe00e5e53e40 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xfe00e5e53e70 lookup() at lookup+0x590/frame 0xfe00e5e53f00 namei() at namei+0x524/frame 0xfe00e5e53fd0 vn_open_cred() at vn_open_cred+0x28f/frame 0xfe00e5e54120 vop_stdvptocnp() at vop_stdvptocnp+0x17d/frame 0xfe00e5e54460 null_vptocnp() at null_vptocnp+0x2b/frame 0xfe00e5e544c0 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xfe00e5e544f0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xfe00e5e54560 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xfe00e5e545c0 vn_fullpath() at vn_fullpath+0xc5/frame 0xfe00e5e54620 export_fd_to_sb() at export_fd_to_sb+0x2fd/frame 0xfe00e5e54850 kern_proc_filedesc_out() at kern_proc_filedesc_out+0x237/frame 0xfe00e5e548d0 sysctl_kern_proc_filedesc() at sysctl_kern_proc_filedesc+0x66/frame 0xfe00e5e54940 sysctl_root() at sysctl_root+0x1e4/frame 0xfe00e5e54990 userland_sysctl() at userland_sysctl+0x192/frame 0xfe00e5e54a30 sys___sysctl() at sys___sysctl+0x74/frame 0xfe00e5e54ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e5e54bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e5e54bf0 --- syscall (202, FreeBSD ELF64, sys___sysctl), rip = 0x801027d1a, rsp = 0x7fffc758, rbp = 0x7fffc790 --- I can provide core upon request. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
-CURRENT on VBox is broken (was: Re: buildworld fails with Zero byte read from file, skipping rest) of line
On Wed, Jan 15, 2014 at 12:36:53PM +0100, Jeremie Le Hen wrote: On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote: J J Can you try to reproduce this with unmapped I/O turned off in boot loader? J J I've never heard of that. Can you please point me to the right J code/doc? In loader prompt: OK set vfs.unmapped_buf_allowed=0 OK boot No, unfortunately I still have the same problem without unmapped bufs. Ok, I'm back to try to try building world on VirtualBox with a recent -CURRENT. So, on a new workstation, I've installed a new VirtualBox, downloaded the latest i386 snapshot and installed it: FreeBSD-11.0-CURRENT-i386-20140203-r261419-disc1.iso Things started to be shady when I tried to build and install ports-mgmt/pkg: % install -s -o root -g wheel -m 555 pkg-static /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static % strip: /usr/ports/ports-mgmt/pkg/work/stage/usr/local/sbin/pkg-static: File format not recognized So I tried to disallow VFS unmapped bufs as you advised me and this seems to have solved the problem (but maybe by chance, see below). Now I'm still running with vfs.unmapped_buf_allowed=0, I installed all the ports I need for basic development. I fetched freebsd-src from GitHub and tried to build world... And now it's started to be very wacky: it failed, multiple times, but never at the same place (I removed /usr/obj/* between each run). There is at least something consistent, it always fails with the same error .../.depend: Zero byte read from file, skipping rest of line.: % [jlh@freefall ~/www/wacky_buildworld_on_vbox]$ grep -B 1 -A 5 'warning: Zero byte read from file' * % typescript.fail1.txt-TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' .depend $TMP; mv $TMP .depend % typescript.fail1.txt:make[4]: /usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 3: warning: Zero byte read from file, skipping rest of line. % typescript.fail1.txt-make[4]: /usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 3: Need an operator % typescript.fail1.txt-make[4]: /usr/obj/usr/src/kerberos5/lib/libheimbase/.depend line 4: Need an operator % typescript.fail1.txt-make[4]: Fatal errors encountered -- cannot continue % typescript.fail1.txt-make[4]: stopped in /usr/src/kerberos5/lib/libheimbase % typescript.fail1.txt-*** Error code 1 % -- % typescript.fail2.txt-TMP=_depend$$; sed -e 's/^\([^\.]*\).o[ ]*:/\1.o \1.po \1.So:/' .depend $TMP; mv $TMP .depend % typescript.fail2.txt:make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 3: warning: Zero byte read from file, skipping rest of line. % typescript.fail2.txt-make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 3: Need an operator % typescript.fail2.txt-make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/lib/libvers/.depend line 4: Need an operator % typescript.fail2.txt-make[3]: Fatal errors encountered -- cannot continue % typescript.fail2.txt-make[3]: stopped in /usr/src/kerberos5/lib/libvers % typescript.fail2.txt-*** Error code 1 % -- % typescript.fail3.txt-echo libroken.so.11: /usr/obj/usr/src/tmp/usr/lib/libcrypt.a .depend % typescript.fail3.txt:make[4]: /usr/obj/usr/src/kerberos5/lib/libroken/.depend line 3: warning: Zero byte read from file, skipping rest of line. % typescript.fail3.txt-make[4]: /usr/obj/usr/src/kerberos5/lib/libroken/.depend line 3: Need an operator % typescript.fail3.txt-make[4]: /usr/obj/usr/src/kerberos5/lib/libroken/.depend line 4: Unknown directive % typescript.fail3.txt-make[4]: Fatal errors encountered -- cannot continue % typescript.fail3.txt-make[4]: stopped in /usr/src/kerberos5/lib/libroken % typescript.fail3.txt-*** Error code 1 % -- % typescript.fail4.txt-echo asn1_compile: /usr/lib/libc.a /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libroken/libroken.a /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/../../lib/libvers/libvers.a /usr/obj/usr/src/tmp/legacy/usr/lib/libegacy.a .depend % typescript.fail4.txt:make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 3: warning: Zero byte read from file, skipping rest of line. % typescript.fail4.txt-make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 3: Need an operator % typescript.fail4.txt-make[3]: /usr/obj/usr/src/tmp/usr/src/kerberos5/tools/asn1_compile/.depend line 4: Need an operator % typescript.fail4.txt-make[3]: Fatal errors encountered -- cannot continue % typescript.fail4.txt-make[3]: stopped in /usr/src/kerberos5/tools/asn1_compile Any idea how to debug this? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ freebsd-current@freebsd.org mailing list http
Re: buildworld fails with Zero byte read from file, skipping rest of line
On Wed, Jan 15, 2014 at 12:40:35PM +0400, Gleb Smirnoff wrote: Jeremie, On Wed, Jan 15, 2014 at 08:40:53AM +0100, Jeremie Le Hen wrote: J J === gnu/usr.bin/groff/src/libs/libgroff (all) J J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: warning: Zero byte read from file, skipping rest of line. J J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: Need an operator J J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 4: Need an operator J J make[6]: Fatal errors encountered -- cannot continue J J make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff J J *** [all] Error code 1 J J J J Typscript available here: J J http://people.freebsd.org/~jlh/typescript.buildworld.txt J J J J Any ideas? J J Can you try to reproduce this with unmapped I/O turned off in boot loader? J J I've never heard of that. Can you please point me to the right J code/doc? In loader prompt: OK set vfs.unmapped_buf_allowed=0 OK boot No, unfortunately I still have the same problem without unmapped bufs. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: buildworld fails with Zero byte read from file, skipping rest of line
On Tue, Jan 14, 2014 at 12:58:18PM +0400, Gleb Smirnoff wrote: Jeremie, On Tue, Jan 14, 2014 at 08:26:21AM +0100, Jeremie Le Hen wrote: J Hi, J J I have a FreeBSD -CURRENT in Virtualbox (running on Linux). I have been J unable to buildworld for a while. J J I suspect this is not a problem with the source because I didn't see any J report so far, whereas I've been experiencing this for a month or more. J Thus I naturally suspected it was a binary problem, so I've upgraded J to the latest snapshot, but the problem still exists. J J === gnu/usr.bin/groff/src/libs/libgroff (all) J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: warning: Zero byte read from file, skipping rest of line. J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: Need an operator J make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 4: Need an operator J make[6]: Fatal errors encountered -- cannot continue J make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff J *** [all] Error code 1 J J Typscript available here: J http://people.freebsd.org/~jlh/typescript.buildworld.txt J J Any ideas? Can you try to reproduce this with unmapped I/O turned off in boot loader? I've never heard of that. Can you please point me to the right code/doc? Thanks? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
buildworld fails with Zero byte read from file, skipping rest of line
Hi, I have a FreeBSD -CURRENT in Virtualbox (running on Linux). I have been unable to buildworld for a while. I suspect this is not a problem with the source because I didn't see any report so far, whereas I've been experiencing this for a month or more. Thus I naturally suspected it was a binary problem, so I've upgraded to the latest snapshot, but the problem still exists. === gnu/usr.bin/groff/src/libs/libgroff (all) make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: warning: Zero byte read from file, skipping rest of line. make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 3: Need an operator make[6]: /usr/obj/usr/src.svn/tmp/usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff/.depend line 4: Need an operator make[6]: Fatal errors encountered -- cannot continue make[6]: stopped in /usr/src.svn/gnu/usr.bin/groff/src/libs/libgroff *** [all] Error code 1 Typscript available here: http://people.freebsd.org/~jlh/typescript.buildworld.txt Any ideas? Cheers, -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Mon, Sep 09, 2013 at 09:32:26AM +0200, Jeremie Le Hen wrote: Indeed, probably a bad key combo in vi :). I'm reverting r253821 and r254753 (the second one was supposingly fixing the first one) and recompiling my kernel. I will let you know. So far so good, I've been able to synchronize my datasets beyond the point where it crashed last time. Matthew, do you have any idea of a fix I could try on top of FreeBSD's r253821 and r254753? There has been some debugging on the ZFS mailing-list and I have tested a working fix. See: http://www.listbox.com/member/archive/182191/2013/09/sort/time_rev/page/1/entry/1:38/20130909182626:D79EC5B8-199E-11E3-8BF5-CB08091A731B/ -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 11:14:44PM +0200, Jeremie Le Hen wrote: On Sun, Sep 08, 2013 at 10:05:55PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? Errm, was there meant to be some content in your reply Jeremie, as it seems to be missing? Indeed, probably a bad key combo in vi :). I'm reverting r253821 and r254753 (the second one was supposingly fixing the first one) and recompiling my kernel. I will let you know. So far so good, I've been able to synchronize my datasets beyond the point where it crashed last time. Matthew, do you have any idea of a fix I could try on top of FreeBSD's r253821 and r254753? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sat, Sep 07, 2013 at 02:35:45PM +0200, Jeremie Le Hen wrote: Hi, I have the following panic every time I do a zfs receive on a given dataset. For the background, I synchronize a zfs dataset every couple of minutes using zfs send/receive. I think I recently got a panic (I'm running mav@'s geom direct dispatch patch) which probably happen at a bad time and left the snapshot/data in an inconsistent state. Now, whenever my cron job runs, it triggers the panic. The process that triggers the panic is: zfs receive -F data/jail/caravan Probably relevant, on boot, I have the following message: Solaris: WARNING: can't open objset for data/jail/caravan/%recv I have a core around if needed to debug. I will not try to repair the snapshot/dataset during this weekend, to get a chance to test a patch. Afterward I will have to start this job again. panic: solaris assert: dn-dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e62401a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e6240250 vpanic() at vpanic+0x126/frame 0xfe00e6240290 panic() at panic+0x43/frame 0xfe00e62402f0 assfail() at assfail+0x22/frame 0xfe00e6240300 dmu_tx_hold_free() at dmu_tx_hold_free+0x167/frame 0xfe00e62403e0 dmu_free_long_range() at dmu_free_long_range+0x1f5/frame 0xfe00e6240450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfe00e6240480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfe00e62406b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00e6240920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00e62409c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00e6240a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00e6240a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00e6240ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e6240bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e6240bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019ddf1a, rsp = 0x7fff5c08, rbp = 0x7fff5c90 --- I rolled back my kernel arbitrarily in the past (2013/08/01). The panic doesn't happen any more. I will try to narrow this down by dichotomy but that will be more efficient if someone has a rough idea wherefrom the problem appeared. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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 in ZFS: solaris assert: dn-dn_datablkshift != 0
On Sun, Sep 08, 2013 at 10:05:55PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 09:02:48PM +0100, Steven Hartland wrote: On Sun, Sep 08, 2013 at 03:17:09PM +0100, Steven Hartland wrote: I believe this was added by this change set:- http://svnweb.freebsd.org/base?view=revisionrevision=253821 Might want to try back out that change and see if everything works after that? Actually, I already rolled back my kernel to August 1st: # svn info . Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head/sys Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253847 Node Kind: directory Schedule: normal Last Changed Author: ian Last Changed Rev: 253847 Last Changed Date: 2013-07-31 21:14:00 +0200 (Wed, 31 Jul 2013) And the problem seems to have gone away. I could perform a full zfs send/receive whereas it would trigger a panic 100% of the time with a recent kernel. I still think r253821 is the cause the reason being is prior to r253996 ASSERTS in ZFS where not actually active in HEAD. So if you could roll forward but then backout r253821 and confirm this is indeed the cause that would be a good starting point. If this is indeed the cause be worth engaging Matthew Ahrens cc'ed to find out the reasoning behind the new ASSERT why you may be hitting it? Errm, was there meant to be some content in your reply Jeremie, as it seems to be missing? Indeed, probably a bad key combo in vi :). I'm reverting r253821 and r254753 (the second one was supposingly fixing the first one) and recompiling my kernel. I will let you know. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Panic in ZFS: solaris assert: dn-dn_datablkshift != 0
Hi, I have the following panic every time I do a zfs receive on a given dataset. For the background, I synchronize a zfs dataset every couple of minutes using zfs send/receive. I think I recently got a panic (I'm running mav@'s geom direct dispatch patch) which probably happen at a bad time and left the snapshot/data in an inconsistent state. Now, whenever my cron job runs, it triggers the panic. The process that triggers the panic is: zfs receive -F data/jail/caravan Probably relevant, on boot, I have the following message: Solaris: WARNING: can't open objset for data/jail/caravan/%recv I have a core around if needed to debug. I will not try to repair the snapshot/dataset during this weekend, to get a chance to test a patch. Afterward I will have to start this job again. panic: solaris assert: dn-dn_datablkshift != 0, file: /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/dmu_tx.c, line: 638 cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00e62401a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00e6240250 vpanic() at vpanic+0x126/frame 0xfe00e6240290 panic() at panic+0x43/frame 0xfe00e62402f0 assfail() at assfail+0x22/frame 0xfe00e6240300 dmu_tx_hold_free() at dmu_tx_hold_free+0x167/frame 0xfe00e62403e0 dmu_free_long_range() at dmu_free_long_range+0x1f5/frame 0xfe00e6240450 dmu_free_long_object() at dmu_free_long_object+0x1f/frame 0xfe00e6240480 dmu_recv_stream() at dmu_recv_stream+0x86e/frame 0xfe00e62406b0 zfs_ioc_recv() at zfs_ioc_recv+0x96c/frame 0xfe00e6240920 zfsdev_ioctl() at zfsdev_ioctl+0x54a/frame 0xfe00e62409c0 devfs_ioctl_f() at devfs_ioctl_f+0xf0/frame 0xfe00e6240a20 kern_ioctl() at kern_ioctl+0x2ca/frame 0xfe00e6240a90 sys_ioctl() at sys_ioctl+0x11f/frame 0xfe00e6240ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00e6240bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00e6240bf0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x8019ddf1a, rsp = 0x7fff5c08, rbp = 0x7fff5c90 --- -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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][CFT] GEOM direct dispatch and fine-grained CAM locking
On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote: On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin m...@freebsd.org wrote: I've found and fixed possible double request completion, that could cause such symptoms if happened. Updated patch located as usual: http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch Good catch! this new patch (applied to r255188) fix the problem on my laptop. With this new one I cannot boot any more (I also updated the source tree). This is a hand transcripted version: Trying to mount root from zfs:zroot/root []... panic: Batch flag already set cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() vpanic() kassert_panic() xpt_batch_start() ata_interrupt() softclock_call_cc() softclock() ithread_loop() fork_exit() fork_trampoline() -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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][CFT] GEOM direct dispatch and fine-grained CAM locking
On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: On 06.09.2013 11:06, Jeremie Le Hen wrote: On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote: On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin m...@freebsd.org wrote: I've found and fixed possible double request completion, that could cause such symptoms if happened. Updated patch located as usual: http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch With this new one I cannot boot any more (I also updated the source tree). This is a hand transcripted version: Trying to mount root from zfs:zroot/root []... panic: Batch flag already set cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() vpanic() kassert_panic() xpt_batch_start() ata_interrupt() softclock_call_cc() softclock() ithread_loop() fork_exit() fork_trampoline() Thank you for the report. I see my fault. It is probably specific to ata(4) driver only. I've workarounded that in new patch version, but probably that area needs some rethinking. http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch I'm not sure you needed a confirmation, but it boots. Thanks :). I didn't quite understand the thread; is direct dispatch enabled for amd64? ISTR you said only i386 but someone else posted the macro for amd64. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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][CFT] GEOM direct dispatch and fine-grained CAM locking
On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: Hi. I would like to invite more people to review and test my patches for improving CAM and GEOM scalability, that for last six months you could see developing in project/camlock SVN branch. Full diff of that branch against present head (r255131) can be found here: http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch I'm building my kernel right now. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 03, 2013 at 02:10:32PM -0400, Outback Dingo wrote: On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen j...@freebsd.org wrote: On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: Hi. I would like to invite more people to review and test my patches for improving CAM and GEOM scalability, that for last six months you could see developing in project/camlock SVN branch. Full diff of that branch against present head (r255131) can be found here: http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch I'm building my kernel right now. Can anyone confirm how well tested/stable this patch set might be?? if theres positive input i have a zoo of dev machines i could load it on, to help further it. Just checking to see how widely its been tested, Very stable so far. I'm doing a make -j 4 buildworld in parallel of a periodic security run. This has been running for hours without failure. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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][CFT] GEOM direct dispatch and fine-grained CAM locking
On Tue, Sep 03, 2013 at 11:24:26PM +0200, Jeremie Le Hen wrote: On Tue, Sep 03, 2013 at 02:10:32PM -0400, Outback Dingo wrote: On Tue, Sep 3, 2013 at 9:42 AM, Jeremie Le Hen j...@freebsd.org wrote: On Mon, Sep 02, 2013 at 11:49:33AM +0300, Alexander Motin wrote: Hi. I would like to invite more people to review and test my patches for improving CAM and GEOM scalability, that for last six months you could see developing in project/camlock SVN branch. Full diff of that branch against present head (r255131) can be found here: http://people.freebsd.org/~mav/camlock_patches/camlock_20130902.patch I'm building my kernel right now. Can anyone confirm how well tested/stable this patch set might be?? if theres positive input i have a zoo of dev machines i could load it on, to help further it. Just checking to see how widely its been tested, Very stable so far. I'm doing a make -j 4 buildworld in parallel of a periodic security run. This has been running for hours without failure. FWIW, I have 4 drives total, distributed in 2 zpool containing 2 mirrored zdev each. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: bsdtar/libarchive change behaviour 9-10
On Mon, Aug 19, 2013 at 01:52:33AM +0200, Eitan Adler wrote: On Sun, Aug 18, 2013 at 9:39 PM, Tim Kientzle t...@kientzle.com wrote: Libarchive 3.x can treat them as extended metadata. As a result, bsdtar doesn't see them at all (except as additional metadata which can't be restored on FreeBSD). This sounds like a POLA breakage. The rule is maybe different for softwares in contrib/. If you are using libarchive directly, you can ask it to not interpret those files as metadata. Bsdtar does request such handling from libarchive. Perhaps this could be exposed to the UI as a env var or a flag? +1 for this. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
panic: excl-share in zfs
Hi guys, I've just got a panic with: FreeBSD obiwan 10.0-CURRENT FreeBSD 10.0-CURRENT #21: Sun Jul 21 21:37:10 CEST 2013 root@obiwan:/usr/obj/usr/src/sys/OBIWAN amd64 I have a core around if needed. obiwan:/usr/src# svn info Path: . Working Copy Root Path: /usr/src URL: http://svn0.us-west.freebsd.org/base/head Repository Root: http://svn0.us-west.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 253515 Node Kind: directory Schedule: normal Last Changed Author: des Last Changed Rev: 253515 Last Changed Date: 2013-07-21 09:24:25 +0200 (Sun, 21 Jul 2013) ddb capture buffer db:0:kdb.enter.panic run lockinfo db:1:lockinfo show locks exclusive lockmgr zfs (zfs) r = 0 (0xfe0046ac4d50) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1806 db:1:locks show alllocks Process 29451 (git) thread 0xfe008bbc4000 (101227) exclusive lockmgr zfs (zfs) r = 0 (0xfe0046ac4d50) locked @ /usr/src/sys/modules/zfs/../../cddl/contrib/opensolaris/uts/common/fs/zfs/zfs_vfsops.c:1806 Process 11062 (sshd) thread 0xfe008c59a490 (101159) exclusive sx so_rcv_sx (so_rcv_sx) r = 0 (0xfe008c268e40) locked @ /usr/src/sys/kern/uipc_sockbuf.c:148 db:1:alllocks show lockedvnods Locked vnodes db:0:kdb.enter.panic show pcpu cpuid= 1 dynamic pcpu = 0xff807f417080 curthread= 0xfe008bbc4000: pid 29451 git curpcb = 0xff80e61d8cc0 fpcurthread = none idlethread = 0xfe0009693490: tid 14 idle: cpu1 curpmap = 0xfe000969a138 tssp = 0x8108e2f8 commontssp = 0x8108e2f8 rsp0 = 0xff80e61d8cc0 gs32p= 0x8108fd50 ldt = 0x8108fd90 tss = 0x8108fd80 spin locks held: db:0:kdb.enter.panic bt Tracing pid 29451 tid 101227 td 0xfe008bbc4000 kdb_enter() at kdb_enter+0x3e/frame 0xff80e61d7d10 vpanic() at vpanic+0x146/frame 0xff80e61d7d50 kassert_panic() at kassert_panic+0x136/frame 0xff80e61d7dc0 witness_checkorder() at witness_checkorder+0x327/frame 0xff80e61d7e50 __lockmgr_args() at __lockmgr_args+0x456/frame 0xff80e61d7f80 vop_stdlock() at vop_stdlock+0x3c/frame 0xff80e61d7fa0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xff80e61d7fd0 _vn_lock() at _vn_lock+0xab/frame 0xff80e61d8040 zfs_lookup() at zfs_lookup+0x395/frame 0xff80e61d80d0 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xff80e61d8210 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xea/frame 0xff80e61d8240 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff80e61d8290 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xff80e61d82c0 null_lookup() at null_lookup+0x8b/frame 0xff80e61d8330 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xea/frame 0xff80e61d8360 lookup() at lookup+0x590/frame 0xff80e61d83f0 namei() at namei+0x464/frame 0xff80e61d84a0 vn_open_cred() at vn_open_cred+0x28f/frame 0xff80e61d85f0 vop_stdvptocnp() at vop_stdvptocnp+0x1a4/frame 0xff80e61d8920 null_vptocnp() at null_vptocnp+0x2b/frame 0xff80e61d8980 VOP_VPTOCNP_APV() at VOP_VPTOCNP_APV+0xf0/frame 0xff80e61d89b0 vn_vptocnp_locked() at vn_vptocnp_locked+0x118/frame 0xff80e61d8a20 vn_fullpath1() at vn_fullpath1+0x1ca/frame 0xff80e61d8a80 kern___getcwd() at kern___getcwd+0xd6/frame 0xff80e61d8ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xff80e61d8bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xff80e61d8bf0 --- syscall (326, FreeBSD ELF64, sys___getcwd), rip = 0x8016ad99c, rsp = 0x7fffd848, rbp = 0x76cd20 --- -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: Fix for sys_munlock(2) with racct
On Sat, Jul 20, 2013 at 08:33:35PM -0700, Alan Cox wrote:
On Jul 20, 2013, at 4:22 AM, Jeremie Le Hen wrote:
Hi Edward, Alan,
I plan to commit the following patch:
http://people.freebsd.org/~jlh/racct_munlock.diff
This solves the following panic:
panic: racct_sub: freeing 301989888 of resource 5, which is more than
allocated 73728 for pwsafe (pid 4177)
The problem is that the racct code in sys_munlock() trusts too much the
user's input. vm_map_unwire_count() now returns how much memory has
really been unwired.
Any objection?
Can you elaborate on what you mean by sys_munlock() trusts too much
the user's input. munlock(2) is supposed to return ENOMEM if any
addresses within the specified range are not backed by valid mappings.
(Valid mappings with PROT_NONE access are something of a gray area
here.) However, it is not error for a to call munlock() on a range
that isn't locked, or to call it a second, third, etc. time on the
same range. Is that what is provoking your panic?
I'm using sysutils/pwsafe and it seems to mlock(2) 18 pages (end - start
= 73728 bytes) but then munlock(2) 73728 pages :-). vm_map_unwire()
seems to do the right thing with those buggy boundaries, but then the
racct code assumes that those boundaries were correct as long as
vm_map_unwire() returned successfully. This is what causes the
assertion failure.
By the way, sys_mlock() uses a simpler approach to deal with a similar
situation:
error = vm_map_wire(map, start, end,
VM_MAP_WIRE_USER | VM_MAP_WIRE_NOHOLES);
#ifdef RACCT
if (error != KERN_SUCCESS) {
PROC_LOCK(proc);
racct_set(proc, RACCT_MEMLOCK,
ptoa(pmap_wired_count(map-pmap)));
PROC_UNLOCK(proc);
}
#endif
However, the code in sys_mlock() for maintaining RACCT_MEMLOCK,
including the above snippet, is race-y. Two simultaneous callers to
sys_mlock() will produce incorrect results. (I haven't looked at
sys_mlockall() or vm_map_growstack().)
Ok, I will commit that as the first bandaid then.
Also, a wired mapping can be destroyed by calling munmap(2) without
first calling munlock(2), in which case, RACCT_MEMLOCK will be
incorrect.
So I think the right way to tackle this is to handle racct in the vm
layer rather than at the syscall layer.
vm_fault_{wire,unwire}() look like natural places for this, but racct
functions require the struct proc to be locked. Any idea how to handle
this?
--
Jeremie Le Hen
Scientists say the world is made up of Protons, Neutrons and Electrons.
They forgot to mention Morons.
___
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: core.txt.N not created anymore on panic
On Thu, Jul 18, 2013 at 12:00:26PM +0300, Mikolaj Golub wrote: On Wed, Jul 17, 2013 at 09:21:51AM +0200, Jeremie Le Hen wrote: On Wed, Jul 17, 2013 at 09:16:55AM +0200, Jeremie Le Hen wrote: Hi, Early May I set ddb_enable=YES (crashinfo_enable=YES by default). Upon panic, it created the following kind of files: -rw--- 1 root wheel 549 Jun 26 22:09 info.0 -rw--- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 -rw--- 1 root wheel 196981 Jun 26 22:09 core.txt.0 -rw--- 1 root wheel 546 Jun 26 23:15 info.1 -rw--- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 -rw--- 1 root wheel 207034 Jun 26 23:15 core.txt.1 -rw--- 1 root wheel 546 Jun 27 00:47 info.2 -rw--- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 -rw--- 1 root wheel 208745 Jun 27 00:48 core.txt.2 -rw--- 1 root wheel 549 Jul 3 14:40 info.3 -rw--- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 -rw--- 1 root wheel 208173 Jul 3 14:41 core.txt.3 The core.txt.N files contained crashinfo(8) informations along with ddb textdump, because crashinfo(8) outputs dmesg. Yesterday, I upgraded to latest -CURRENT from one from June 9th. While stress-testing overnight, I got a couple of panics but core.txt.N are not created anymore. -rw--- 1 root wheel 530 Jul 17 01:10 info.5 -rw--- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 -rw--- 1 root wheel 529 Jul 17 02:01 info.6 -rw--- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 -rw--- 1 root wheel 530 Jul 17 04:20 info.7 -rw--- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 -rw--- 1 root wheel 530 Jul 17 07:50 info.8 -rw--- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 -rw--- 1 root wheel 531 Jul 17 08:44 info.9 -rw--- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 Each textdump.tar.N contains: tar tvf /var/crash/textdump.tar.9 -rw--- 0 root wheel 49152 Jul 17 08:30 ddb.txt -rw--- 0 root wheel3179 Jul 17 08:30 config.txt -rw--- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt -rw--- 0 root wheel 88 Jul 17 08:30 panic.txt -rw--- 0 root wheel 120 Jul 17 08:30 version.txt Any idea changed in between? I checked svn log in etc/ but I found nothing relevant. Before your system was configured to generate vmcore dumps. Now it is configured to generate textdumps. crashinfo(8) works with vmcore. For the record: debug.ddb.capture.bufoff: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.inprogress: 0 debug.ddb.capture.bufsize: 49152 debug.ddb.capture.data: debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; 'textdump set' tells ddb to store dumps in textdump format. Remove this from /etc/ddb.conf (and run /etc/rc.d/ddb) if you want crashinfo(8) data. That was it, thanks! I'm still confused why until recently, it worked as if textdump wasn't enabled. ddb capture was and I have never modified ddb.conf. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Fix for sys_munlock(2) with racct
Hi Edward, Alan, I plan to commit the following patch: http://people.freebsd.org/~jlh/racct_munlock.diff This solves the following panic: panic: racct_sub: freeing 301989888 of resource 5, which is more than allocated 73728 for pwsafe (pid 4177) The problem is that the racct code in sys_munlock() trusts too much the user's input. vm_map_unwire_count() now returns how much memory has really been unwired. Any objection? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
core.txt.N not created anymore on panic
Hi, Early May I set ddb_enable=YES (crashinfo_enable=YES by default). Upon panic, it created the following kind of files: -rw--- 1 root wheel 549 Jun 26 22:09 info.0 -rw--- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 -rw--- 1 root wheel 196981 Jun 26 22:09 core.txt.0 -rw--- 1 root wheel 546 Jun 26 23:15 info.1 -rw--- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 -rw--- 1 root wheel 207034 Jun 26 23:15 core.txt.1 -rw--- 1 root wheel 546 Jun 27 00:47 info.2 -rw--- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 -rw--- 1 root wheel 208745 Jun 27 00:48 core.txt.2 -rw--- 1 root wheel 549 Jul 3 14:40 info.3 -rw--- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 -rw--- 1 root wheel 208173 Jul 3 14:41 core.txt.3 The core.txt.N files contained crashinfo(8) informations along with ddb textdump, because crashinfo(8) outputs dmesg. Yesterday, I upgraded to latest -CURRENT from one from June 9th. While stress-testing overnight, I got a couple of panics but core.txt.N are not created anymore. -rw--- 1 root wheel 530 Jul 17 01:10 info.5 -rw--- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 -rw--- 1 root wheel 529 Jul 17 02:01 info.6 -rw--- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 -rw--- 1 root wheel 530 Jul 17 04:20 info.7 -rw--- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 -rw--- 1 root wheel 530 Jul 17 07:50 info.8 -rw--- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 -rw--- 1 root wheel 531 Jul 17 08:44 info.9 -rw--- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 Each textdump.tar.N contains: tar tvf /var/crash/textdump.tar.9 -rw--- 0 root wheel 49152 Jul 17 08:30 ddb.txt -rw--- 0 root wheel3179 Jul 17 08:30 config.txt -rw--- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt -rw--- 0 root wheel 88 Jul 17 08:30 panic.txt -rw--- 0 root wheel 120 Jul 17 08:30 version.txt Any idea changed in between? I checked svn log in etc/ but I found nothing relevant. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: core.txt.N not created anymore on panic
On Wed, Jul 17, 2013 at 09:16:55AM +0200, Jeremie Le Hen wrote: Hi, Early May I set ddb_enable=YES (crashinfo_enable=YES by default). Upon panic, it created the following kind of files: -rw--- 1 root wheel 549 Jun 26 22:09 info.0 -rw--- 1 root wheel 1518501888 Jun 26 22:09 vmcore.0 -rw--- 1 root wheel 196981 Jun 26 22:09 core.txt.0 -rw--- 1 root wheel 546 Jun 26 23:15 info.1 -rw--- 1 root wheel 472608768 Jun 26 23:15 vmcore.1 -rw--- 1 root wheel 207034 Jun 26 23:15 core.txt.1 -rw--- 1 root wheel 546 Jun 27 00:47 info.2 -rw--- 1 root wheel 667717632 Jun 27 00:47 vmcore.2 -rw--- 1 root wheel 208745 Jun 27 00:48 core.txt.2 -rw--- 1 root wheel 549 Jul 3 14:40 info.3 -rw--- 1 root wheel 1455198208 Jul 3 14:40 vmcore.3 -rw--- 1 root wheel 208173 Jul 3 14:41 core.txt.3 The core.txt.N files contained crashinfo(8) informations along with ddb textdump, because crashinfo(8) outputs dmesg. Yesterday, I upgraded to latest -CURRENT from one from June 9th. While stress-testing overnight, I got a couple of panics but core.txt.N are not created anymore. -rw--- 1 root wheel 530 Jul 17 01:10 info.5 -rw--- 1 root wheel 75776 Jul 17 01:10 textdump.tar.5 -rw--- 1 root wheel 529 Jul 17 02:01 info.6 -rw--- 1 root wheel 74240 Jul 17 02:01 textdump.tar.6 -rw--- 1 root wheel 530 Jul 17 04:20 info.7 -rw--- 1 root wheel 74752 Jul 17 04:20 textdump.tar.7 -rw--- 1 root wheel 530 Jul 17 07:50 info.8 -rw--- 1 root wheel 92672 Jul 17 07:50 textdump.tar.8 -rw--- 1 root wheel 531 Jul 17 08:44 info.9 -rw--- 1 root wheel 110592 Jul 17 08:44 textdump.tar.9 Each textdump.tar.N contains: tar tvf /var/crash/textdump.tar.9 -rw--- 0 root wheel 49152 Jul 17 08:30 ddb.txt -rw--- 0 root wheel3179 Jul 17 08:30 config.txt -rw--- 0 root wheel 54137 Jul 17 08:30 msgbuf.txt -rw--- 0 root wheel 88 Jul 17 08:30 panic.txt -rw--- 0 root wheel 120 Jul 17 08:30 version.txt Any idea changed in between? I checked svn log in etc/ but I found nothing relevant. For the record: debug.ddb.capture.bufoff: 0 debug.ddb.capture.maxbufsize: 5242880 debug.ddb.capture.inprogress: 0 debug.ddb.capture.bufsize: 49152 debug.ddb.capture.data: debug.ddb.scripting.scripts: lockinfo=show locks; show alllocks; show lockedvnods kdb.enter.panic=textdump set; capture on; run lockinfo; show pcpu; bt; ps; alltrace; capture off; call doadump; reset kdb.enter.witness=run lockinfo debug.ddb.scripting.unscript: debug.ddb.textdump.pending: 0 debug.ddb.textdump.do_config: 1 debug.ddb.textdump.do_ddb: 1 debug.ddb.textdump.do_msgbuf: 1 debug.ddb.textdump.do_panic: 1 debug.ddb.textdump.do_version: 1 debug.debugger_on_panic: 1 debug.kdb.available: ddb debug.kdb.current: ddb debug.kdb.enter: 0 debug.kdb.panic: 0 debug.kdb.trap: 0 debug.kdb.trap_code: 0 debug.kdb.break_to_debugger: 0 debug.kdb.alt_break_to_debugger: 0 -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: Problem with installworld
Hi Michael, On Tue, Jun 25, 2013 at 10:38:59AM +0200, Michael Tuexen wrote: Dear all, when doing a make installworld the following happens: -- Installing everything -- cd /usr/home/tuexen/head; make -f Makefile.inc1 install === share/info (install) === lib (install) === lib/csu/amd64 (install) install -o root -g wheel -m 444 crt1.o crti.o crtn.o Scrt1.o gcrt1.o /usr/lib === lib/libc (install) install -C -o root -g wheel -m 444 libc.a /usr/lib install -C -o root -g wheel -m 444 libc_p.a /usr/lib install -s -o root -g wheel -m 444 -fschg -S libc.so.7 /lib install: exec(strip): No such file or directory install: wait: No such file or directory *** Error code 70 Stop. make: stopped in /usr/home/tuexen/head/lib/libc *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head/lib *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head *** Error code 1 Stop. make: stopped in /usr/home/tuexen/head # Any idea how to progress? This is using svn head of yesterday. install(1) uses strip(1). Can you check: ls -l /usr/bin/strip Can you run it manually? Did you check you $PATH? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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
Panic with RACCT on a jailed process
Hi, I've been bit by a panic three times over the last month. I'm currently running: FreeBSD obiwan.piupiu.local 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r251519: Sun Jun 9 22:37:09 CEST 2013 root@obiwan.piupiu.local:/usr/obj/usr/src/sys/OBIWAN amd64 The panic message is: panic: destroying non-empty racct: 1007616 allocated for resource 4 I quicky tried to track this down, but in half an hour I didn't get very far. Resource 4 is RACCT_RSS. The faulty process seems to be 66555 which looks like a 32-bits cron(8) running in a jail. This is the call trace: kdb_enter() at kdb_enter+0x3e/frame 0xff80e63b3610 vpanic() at vpanic+0x146/frame 0xff80e63b3650 kassert_panic() at kassert_panic+0x136/frame 0xff80e63b36c0 racct_destroy() at racct_destroy+0x8e/frame 0xff80e63b36f0 uifree() at uifree+0x5e/frame 0xff80e63b3710 crfree() at crfree+0x48/frame 0xff80e63b3730 thread_wait() at thread_wait+0xac/frame 0xff80e63b3750 proc_reap() at proc_reap+0x43f/frame 0xff80e63b37a0 proc_to_reap() at proc_to_reap+0x340/frame 0xff80e63b37f0 kern_wait6() at kern_wait6+0x1fa/frame 0xff80e63b3890 kern_wait() at kern_wait+0x5a/frame 0xff80e63b39e0 freebsd32_wait4() at freebsd32_wait4+0x2e/frame 0xff80e63b3ae0 ia32_syscall() at ia32_syscall+0x26c/frame 0xff80e63b3bf0 The panic happened each three times because of cron(8), but both with 32-bits and 64-bits versions. crashinfo + ddb textdump available here: http://people.freebsd.org/~jlh/crash/core.txt.9.txt Note that the dmesg included in the core contains another panic I got with ZFS. I usually wait to see it twice before reporting, but if you want I still have the core and the crashinfo around. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: amd64 buildworld lib32 flags fail
Hi Ian, On Sun, Apr 21, 2013 at 11:08:41AM +0200, Ian FREISLICH wrote: I have some amd64 systems that fail cleaning up lib32 and some that don't. I have to chflags noschg these files before starting a buildworld. I can't figure out what the difference is between the systems that work and those that don't. -- Rebuilding the temporary build tree -- rm -rf /usr/obj/usr/src/tmp rm -rf /usr/obj/usr/src/lib32 rm: /usr/obj/usr/src/lib32/usr/lib32/libc.so.7: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libcrypt.so.5: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/libthr.so.3: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32/librt.so.1: Operation not permitted rm: /usr/obj/usr/src/lib32/usr/lib32: Directory not empty rm: /usr/obj/usr/src/lib32/usr: Directory not empty rm: /usr/obj/usr/src/lib32: Directory not empty *** [_worldtmp] Error code 1 Maybe you buildworld is jailed? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: CLANG and -fstack-protector
Hi Kimmo, On Thu, Feb 07, 2013 at 10:06:49PM +0100, Dimitry Andric wrote: On 2013-02-07 20:42, Kimmo Paasiala wrote: Does the -fstack-protector option work on CLANG 3.1 and 3.2? Yes, it works with both clang and gcc. There is thread on FreeBSD forums about the stack protector and ports and I'm wondering if it's possible to use the -fstack-protector option with CLANG. http://forums.freebsd.org/showthread.php?t=36927 That thread seems to be full of confusion. :-) The base system is mostly built with -fstack-protector, except for the ia64, arm and mips arches, and for some specific cases where it is not necessary, or unwanted. Ports are largely independent of the base system, and their compilation flags are different from port to port. You could set -fstack-protector for your ports in either make.conf or ports.conf, if you wanted. You can do this, it will work for most of the ports but some ports do not honor CFLAGS. If those ports happen to be linked againsst libraries that were compiled with -fstack-protector, you will get a missing symbol error. Well, to be honest, I don't remember enough details, they faded from my memory, I need to check this. So if you care about security enough, go for it! If you meet weird error like a missing stack_chk_fail symbol for some ports (lang/perl might be a candidate in my memory), then look at the PR below, it will probably solve your problem. Time has passed and I am interested in your feedback without the patch (and then with, if relevant). Basically the following PR contains a patch that waits for an exp run to be committed into the base system. This just turns libc.so into an ld script that pulls in libssp_nonshared.a. You just have to run make all install in src/lib/libc after applying it. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/168010 I run it on my servers with -fstack-protector enabled for ports without any problem. Cheers! -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: sysctl kern.ipc.somaxconn limit 65535 why?
Hi, On Wed, Oct 03, 2012 at 10:15:32PM +0200, Andre Oppermann wrote: On 03.10.2012 22:03, Adrian Chadd wrote: somaxconn is the connection queue depth. If it's sitting at a couple hundred thousand then something else is going crazily wrong. I understand your frustration, but there's a lot of instances where the application just isn't doing things right and the OS tries to hide it as much as psosible. Blowing out somaxconn to chew up a whole lot of resources seems a bit silly. I'd rather investigate why the userland application is not servicing the connect queue often enough. I've written network services that supported tens of thousands of new TCP connections a second on a LAN and I never once had to bump somaxconn past 32767. I'm not saying that it won't apply to your scenario, I'm just trying to explain that there's likely more going on. I guess the problem is rather kern.ipc.maxsockets which is only 25600. The name somaxconn is confusing as it specifies the listen queue limit instead of the maximum number of connections as the it suggests. If we want to change that name to something more sensible and less error-prone like somaxbacklog, does the project has a policy to change sysctl names? I'm thinking of something like renaming the sysctl to somaxbacklog and make somaxconn compatibility shim during RELENG_10 which still works but prints a warning in the dmesg. -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: pkgng 1.0 release schedule, and HEAD switch to pkgng by default schedule
Hi Baptise, On Mon, Aug 20, 2012 at 09:43:13PM +0200, Baptiste Daroussin wrote: Since 1.0-rc6 release, everything looks ready for a final release of 1.0, I'll give more details on the release commit bit :) this is planned for 30th august 2012. Current was supposed to switch to pkgng by default today, it has been delayed until the nvidia-driver is fixed with pkgng. Thanksfully kwm@ and danfe@ has been working on this, and the situation should be fixed pretty soon. Please continue testing pkgng and reporting bugs, if you are new comers do not hesitate to ask question about pkgng so that we can improve documentation: The usual links about pkgng: - http://wiki.freebsd.org/pkgng - http://wiki.freebsd.org/PkgPrimer - https://github.com/pkgng/pkgng/blob/master/FAQ.md - http://people.freebsd.org/~bapt/pres-pkgng-bsdcan.pdf - http://www.youtube.com/watch?v=4Hxq7AHZ27I First thank you and all who have worked to make this first release of pkgng. This is a great milestone in FreeBSD history. Supposedly, pkgng will stay opt-in for RELENG_9 and will be the default (opt-out?) on RELENG_10. During the upgrade from the old branch to the new one, how do we ensure users will perform the required step (basically, run pkg2ng) to switch their pkg database to pkgng? Will it be a note in src/UPDATING and as well in the release notes? -- Jeremie Le Hen Scientists say the world is made up of Protons, Neutrons and Electrons. They forgot to mention Morons. ___ 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: csup ends up in sigwai after Shutting down connection to server, never exits
Anton, Sorry for the delay, I was AFK over the last couple of days. On Tue, Jun 19, 2012 at 01:19:38PM +0100, Anton Shterenlikht wrote: On Tue, Jun 19, 2012 at 01:49:36PM +0200, Jeremie Le Hen wrote: I think recompiling the kernel and the libraries csup depends on will be enough. you mean # make cleandir make obj make make install for all these libs: # ldd /root/csup/csup /root/csup/csup: libz.so.6 = /lib/libz.so.6 (0x1200ca000) libthr.so.3 = /lib/libthr.so.3 (0x120102000) libmd.so.5 = /lib/libmd.so.5 (0x12014c000) libc.so.7 = /lib/libc.so.7 (0x120178000) Yes, right. And the kernel of course. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: csup ends up in sigwai after Shutting down connection to server, never exits
Anton,
On Mon, Jun 18, 2012 at 09:55:44AM +0100, Anton Shterenlikht wrote:
On Thu, Jun 14, 2012 at 12:15:05PM +0100, Anton Shterenlikht wrote:
On Thu, Jun 14, 2012 at 11:57:38AM +0100, Anton Shterenlikht wrote:
On ia64 r235474 and r235163 I get:
# csup -L2 /root/ports-supfile
Parsing supfile /root/ports-supfile
Connecting to cvsup.uk.FreeBSD.org
Connected to 131.111.8.41
Server software version: SNAP_16_1h
MD5 authentication started
MD5 authentication successful
Negotiating file attribute support
Exchanging collection information
Establishing multiplexed-mode data connection
Running
Updating collection ports-all/cvs
Shutting down connection to server
csup never exits.
From top:
PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU
COMMAND
33822 root 2 200 37496K 23352K sigwai 1 0:32 0.00% csup
On amd64 r236740M I don't see this problem.
Just to update - I don't see this problem on ia64 r231193M.
It seems the only relevant change in usr.bin/csup since then was:
Index: usr.bin/csup/auth.c
===
--- usr.bin/csup/auth.c (revision 231193)
+++ usr.bin/csup/auth.c (working copy)
@@ -293,7 +293,7 @@
gettimeofday(tv, NULL);
pid = getpid();
ppid = getppid();
- srand(tv.tv_usec ^ tv.tv_sec ^ pid);
+ srandom(tv.tv_usec ^ tv.tv_sec ^ pid);
addrlen = sizeof(laddr);
error = getsockname(config-socket, (struct sockaddr *)laddr,
addrlen);
if (error 0) {
I was thinking of doing a binary search for this,
but realised that I'd have to build/install world,
not just kernel, right? This will take a *long* time.
I think recompiling the kernel and the libraries csup depends on will be
enough.
--
Jeremie Le Hen
Men are born free and equal. Later on, they're on their own.
Jean Yanne
___
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: csup ends up in sigwai after Shutting down connection to server, never exits
Hi Anton, On Thu, Jun 14, 2012 at 11:57:38AM +0100, Anton Shterenlikht wrote: On ia64 r235474 and r235163 I get: # csup -L2 /root/ports-supfile Parsing supfile /root/ports-supfile Connecting to cvsup.uk.FreeBSD.org Connected to 131.111.8.41 Server software version: SNAP_16_1h MD5 authentication started MD5 authentication successful Negotiating file attribute support Exchanging collection information Establishing multiplexed-mode data connection Running Updating collection ports-all/cvs Shutting down connection to server csup never exits. From top: PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 33822 root 2 200 37496K 23352K sigwai 1 0:32 0.00% csup On amd64 r236740M I don't see this problem. mux@ fixed many bugs in his bitbucket source tree [1], would you mind giving it a spin? I may import the latest code into the tree when I have enough free time. [1] https://bitbucket.org/mux/csup -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: UFS+J panics on HEAD
On Thu, May 24, 2012 at 09:58:52PM +0200, Matthew Seaman wrote: On 24/05/2012 00:05, Mark Linimon wrote: On Wed, May 23, 2012 at 10:58:48PM +0100, Steven Hartland wrote: While it might be a shame to see FFS go by the wayside are there any big reasons why you would rather stick with FFS instead of moving to ZFS with all the benefits that brings? - ZFS eats bytes for breakfast. It is completely inappropriate for anything with less than 4GB RAM. - ZFS performs poorly under disk-nearly-full conditions. - ZFS is not optimal for situations where there are a lot of small, randomly dispersed IOs around the disk space. Like in any sort of RDBMS. This is very true for reads, not for writes because it is a COW filesystem so writes are usually sequencial disk-wise. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
Ilya, On Mon, May 21, 2012 at 01:43:39PM +0200, Ilya Bakulin wrote: On Mon, May 21, 2012 12:36 pm, Jeremie Le Hen wrote: Can you provide the exact commands you have used to create your chroot? Sure! 1. The build host is FreeBSD 8.2-RELEASE-p3 amd64 2. Directory where project resides ($PROJROOT): /home/kibab/repos/freebsd-cap-git 2. FreeBSD-CURRENT sources are in $PROJROOT/freebsd 3. Object directory is $PROJROOT/obj 4. Installation directory is $PROJROOT/inst 5. Building world: while in $PROJROOT/freebsd, I type: make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 buildworld ...After a while, build ends... 6. while in $PROJROOT/freebsd, type `sudo make buildenv`, after entering build environment I set nessesary env variables: PROJROOT=/home/kibab/repos/freebsd-cap-git MAKEOBJDIRPREFIX=/home/kibab/repos/freebsd-cap-git/obj DISTDIR=/home/kibab/repos/freebsd-cap-git/inst DESTDIR=/home/kibab/repos/freebsd-cap-git/inst 7. After that, type: make __MAKE_CONF=$PROJROOT/make.conf SRCCONF=$PROJROOT/src.conf -j16 installworld This is expected I think, as make buildenv defines $_SHLIBDIRPREFIX which is used to make the toolchain use libraries built during stage 4.2 of buildworld. Just run make installworld with the correct DESTDIR and your chroot will be fine. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: Broken symbolic links in /usr/lib after compiling and installing -CURRENT
Hi, On Sun, May 20, 2012 at 07:54:22PM +0200, Ilya Bakulin wrote: Hi all, I have compiled FreeBSD-CURRENT amd64 (fresh checkout from today, git revision 46b12ff6d8ab4f736d155646ae32133083e1da05 -- from official FreeBSD github mirror) and installed it in custom location (DESTDIR= make installworld). After chrooting to installed system and trying to compile any program I get the message: # gcc -o hello hello.c /usr/bin/ld: cannot find -lgcc_s Here is an output of 'ls -l' after chrooting to installed system: total 89076 -rwxr-xr-x 1 0 0 3352 19 ?? 21:27 Scrt1.o drwxr-xr-x 2 0 0 512 20 ?? 08:39 aout drwxr-xr-x 3 0 0 512 20 ?? 08:39 compat -rwxr-xr-x 1 0 0 3296 19 ?? 21:27 crt1.o -rwxr-xr-x 1 0 0 2408 19 ?? 21:27 crtbegin.o ... -rwxr-xr-x 1 0 0 56354 20 ?? 09:31 libalias.a lrwxr-xr-x 1 0 0 71 20 ?? 09:54 libalias.so - /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libalias.so.7 -rwxr-xr-x 1 0 0 3200 20 ?? 09:31 libalias_cuseeme.a ... -rwxr-xr-x 1 0 0 17108 20 ?? 09:31 libbegemot.a lrwxr-xr-x 1 0 0 73 20 ?? 09:54 libbegemot.so - /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libbegemot.so.4 ... lrwxr-xr-x 1 root wheel 71 20 ?? 21:31 libgcc_s.so - /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib/libgcc_s.so.1 Links to libalias, libbegemot, libgcc_s point to respective libraries under /usr/obj/home/kibab/repos/freebsd-cap-git/freebsd/tmp/lib. But this path doesn't exist even on build system! In my setup, FreeBSD source tree is under /home/kibab/repos/freebsd-cap-git/freebsd, object directory is /home/kibab/repos/freebsd-cap-git/freebsd/obj, installation directory is /home/kibab/repos/freebsd-cap-git/freebsd/inst. As I understand, this problem will arise only if using non-standard object directory (not under /usr/obj), because symbolic links will otherwise point to some files under /usr/obj and required files will be actually there. This is still incorrect, but at least would seem to work... I'm using custom src.conf with these options: WITHOUT_CLANG=yes WITHOUT_GAMES=yes WITHOUT_KERNEL_SYMBOLS=yes WITHOUT_EXAMPLES=yes WITHOUT_HTML=yes WITHOUT_NCP=yes WITHOUT_PROFILE=yes WITHOUT_SENDMAIL=yes WITHOUT_SYSINSTALL=yes WITHOUT_VINUM=yes WITHOUT_LIB32=yes I tried a fresh build with clean object directory. Could anyone tell what may have gone wrong? Can you provide the exact commands you have used to create your chroot? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: howto debug a complete hard reset
Hi Alexander, On Fri, Apr 13, 2012 at 09:36:44PM +, Alexander Best wrote: i'm running HEAD on amd64 and experienced some really annoying resets during the last couple of months. when i do 'sysctl -a' or 'sysctl -a|grep bla', my whole system does a hard reset. no core dump gets produced. isn't there a way to find out which sysctl variable is causing the reset? This is probably a sysctl handler that is causing the reboot. You can run this one-liner to spot the culprit (use sh): for i in $(sysctl -Na); do sysctl $i ~/sysctl.out; sync; done Each sysctl will be called in turn and the output is appended to a file, but the file will forcibly written to the disk before the next occurence. When your computer will be reset, the culprit will obviously not be written to this file, but the previous one will. You can then look at the output of sysctl -Na to see which one is causing the reboot. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: howto debug a complete hard reset
On Sat, Apr 14, 2012 at 08:59:42AM -0400, Robert Huff wrote: This is probably a sysctl handler that is causing the reboot. You can run this one-liner to spot the culprit (use sh): for i in $(sysctl -Na); do sysctl $i ~/sysctl.out; sync; done Each sysctl will be called in turn and the output is appended to a file, but the file will forcibly written to the disk before the next occurence. Um ... it is my understanding sync(8) does not guarantee pending i/o will be written before it returns, but merely requests this happen irrespective of when it would normally occur. An I mistaken? Honestly I don't know, but I have do admit that the small paragraph in the BUGS section of the sync(2) manpage is a little bit shivering: BUGS The sync() system call may return before the buffers are completely flushed. Can any enlightened person answer this? -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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] Enable nxstack by default
Hi, On Wed, Oct 19, 2011 at 12:37:44AM +0200, Oliver Pinter wrote: In NetBSD has been some PaX feature [0] implemented. (ASLR, W^X (~nxstack), mprotect restriction, veriexec, mmap randomization[2]...) [0] http://pax.grsecurity.net/docs/index.html [1] http://www.netbsd.org/~elad/recent/man/security.8.html [2] http://people.freebsd.org/~ssouhlal/testing/stackgap-20050527.diff Suleiman actually wrought two patches, one randomizing the stack (the one you pointed out) and another one randomizing non-fixed mmap(2) calls: http://people.freebsd.org/~ssouhlal/testing/mmap_random-20050528.diff FYI, they do not apply cleanly on recent source trees (the patches were made in 2005), but they can be applied with little fiddling. I'm running multiple 8.x production machines with them without any problem. I've always wanted them to be committed as opt-in knobs, but I can't remember why they hadn't at the time. Cheers, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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
Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 03:59:53PM +0300, Kostik Belousov wrote: On Wed, Sep 14, 2011 at 02:36:07PM +0200, Jeremie Le Hen wrote: Hi list, I've recently migrated my services from a box running 8.1-STABLE to another one running 9.0-BETA2. I run stunnel 4.28 on 8.1-STABLE, and it has run flawlessly so far. I compiled manually this very version on 9.0-BETA2. But I get the following segfault: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 803008c00 (LWP 100496/stunnel)] 0x00080110d359 in gmtime_r () from /lib/libc.so.7 (gdb) thread [Current thread is 3 (Thread 803008c00 (LWP 100496/stunnel))] (gdb) bt #0 0x00080110d359 in gmtime_r () from /lib/libc.so.7 #1 0x00080110cdde in gmtime_r () from /lib/libc.so.7 #2 0x00080110dab4 in gmtime_r () from /lib/libc.so.7 #3 0x00080110dcc8 in gmtime_r () from /lib/libc.so.7 #4 0x000800e1d9e8 in pthread_once () from /lib/libthr.so.3 #5 0x00080110ca9f in timegm () from /lib/libc.so.7 #6 0x000805dff8d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x000805e74631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x000805e9462d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x000805e9478c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x000805e9496d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x000805e95f46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000805b7f4c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000805b5d6e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000805b612bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x00406f6e in init_ssl (c=0x803093000) at client.c:329 #16 0x004069a6 in do_client (c=0x803093000) at client.c:202 #17 0x0040676b in run_client (c=0x803093000) at client.c:150 #18 0x004066cf in client (arg=0x803093000) at client.c:123 #19 0x000800e18224 in pthread_getprio () from /lib/libthr.so.3 #20 0x in ?? () Note that I tried with the newest version of stunnel, it crashes at the same place. I also tried libssl.so both from the base system and from the ports, same thing. You need to compile both libc and libthr with debugging symbols and do a backtrace with such libraries. Here it is: #0 0x000807509359 in tzload (name=0x807536281 posixrules, sp=0x7fbf8e80, doextend=0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:393 #1 0x000807508dde in tzparse (name=0x7fbeec95 , sp=0x7fbf8e80, lastditch=Variable lastditch is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1001 #2 0x000807509ab4 in tzload (name=Variable name is not available. ) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:579 #3 0x000807509cc8 in gmtload (sp=0x80776f6c0) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1196 #4 0x00080ce5d9e8 in _pthread_once (once_control=0x80776af00, init_routine=0x807509cf0 gmt_init) at /usr/src/lib/libthr/thread/thr_once.c:87 #5 0x000807508a9f in gmtsub (timep=0x7fbfdaf8, offset=0, tmp=0x7fbfdb00) at /usr/src/lib/libc/../../contrib/tzcode/stdtime/localtime.c:1485 #6 0x00080e7e58d9 in OPENSSL_gmtime () from /usr/local/lib/libcrypto.so.7 #7 0x00080e85a631 in ASN1_UTCTIME_adj () from /usr/local/lib/libcrypto.so.7 #8 0x00080e87a62d in X509_time_adj_ex () from /usr/local/lib/libcrypto.so.7 #9 0x00080e87a78c in X509_cmp_time () from /usr/local/lib/libcrypto.so.7 #10 0x00080e87a96d in internal_verify () from /usr/local/lib/libcrypto.so.7 #11 0x00080e87bf46 in X509_verify_cert () from /usr/local/lib/libcrypto.so.7 #12 0x000809ec94c8 in ssl_verify_cert_chain () from /usr/local/lib/libssl.so.7 #13 0x000809ea76e3 in ssl3_get_client_certificate () from /usr/local/lib/libssl.so.7 #14 0x000809eab2bc in ssl3_accept () from /usr/local/lib/libssl.so.7 #15 0x004076f9 in ?? () #16 0x004082cf in ?? () #17 0x00408c50 in ?? () #18 0x00408d17 in ?? () #19 0x00080ce58224 in thread_start (curthread=0x80d408c00) at /usr/src/lib/libthr/thread/thr_create.c:284 #20 0x in ?? () Error accessing memory address 0x7fbfe000: Bad address. -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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: Segfault in libthr.so on 9.0-BETA2 (with stunnel FWIW)
On Wed, Sep 14, 2011 at 11:04:56PM +0300, Kostik Belousov wrote: tzload() allocates ~80KB for the local variables. The backtrace you provided shows the nested call to tzload(), so there is total 160KB of the stack space consumed. Isn't it a little bit hungry? To do this on stack? Softwares with a large amount of threads might want to reduce their stack size dramatically, and so much space might not be available. By default, stack for the amd64 thread is 4MB, that should be plenty. This is not the case for ezm3. Possibly, stunnel also reduces the size of the thread stack. Correct, I checked stunnel source, it reduces it to 64KB by default. However it is possible to override it from the config file. Raising solves the problem indeed. Please, try the patch below. I did not tested it, only compiled. I see that now tzload allocates only ~300 bytes on the stack. I've also tried it, leaving the default stack size chosen by stunnel. It works. Please go ahead and commit it if it's still possible. Thanks. Regards, -- Jeremie Le Hen Men are born free and equal. Later on, they're on their own. Jean Yanne ___ 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] Force stdio output streams to line-buffered mode
On Sat, Feb 19, 2011 at 02:37:29PM -0600, Matthew D. Fuller wrote: On Sat, Feb 19, 2011 at 07:50:43PM +0100 I heard the voice of Jeremie Le Hen, and lo! it spake thus: I've attached a small patch for stdio, so if the environment variable STDIO_IOLBF is set, the output streams will be line-oriented by default. iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n I've no real comment on anything else (sounds like an interesting hack, whatever else), but just for this particular case, you know that grep has a --line-buffered arg, right? Yes indeed, my example wasn't especially smart :). Actually, I often stumble on this problem with an awk script I use to columize output. -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ 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
[RFC] Force stdio output streams to line-buffered mode
Hi,
I've been annoyed multiple time when running a command such like
iostat -x 1 | grep -v ad10 | cat -n
The problem stems from two factors:
- grep's stdio sees that its stdout is not a terminal, so stdout is
full buffered and not line-buffered;
- iostat produces output too slowly so the aforementioned buffer takes
numerous seconds to be filled and flushed to the last command.
This problems is not specific to FreeBSD, it is actually a consequence
of POSIX specification. I've checked this on Solaris and Linux.
I've attached a small patch for stdio, so if the environment variable
STDIO_IOLBF is set, the output streams will be line-oriented by default.
iostat -x 1 | env STDIO_IOLBF=1 grep -v ad10 | cat -n
Before send it as a PR, I would like to hear your comments about this,
especially:
- the variable name (no bikeshed please, I just ask this if there is a
naming convention I'm not aware of);
- the documentation: I've put a hint in stdio(3) manpage and put the
full explanation in setvbuf(3).
Thanks.
Regards,
--
Jeremie Le Hen
Humans are born free and equal. But some are more equal than others.
Coluche
diff -rup /usr/src.orig/lib/libc/stdio/makebuf.c /usr/src/lib/libc/stdio/makebuf.c
--- /usr/src.orig/lib/libc/stdio/makebuf.c 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/makebuf.c 2011-02-19 19:09:56.0 +0100
@@ -59,6 +59,7 @@ __smakebuf(fp)
FILE *fp;
{
void *p;
+ char *bmode;
int flags;
size_t size;
int couldbetty;
@@ -79,7 +80,8 @@ __smakebuf(fp)
flags |= __SMBF;
fp-_bf._base = fp-_p = p;
fp-_bf._size = size;
- if (couldbetty isatty(fp-_file))
+ if (((bmode = getenv(STDIO_IOLBF)) bmode[0] != '\0') ||
+ (couldbetty isatty(fp-_file)))
flags |= __SLBF;
fp-_flags |= flags;
}
diff -rup /usr/src.orig/lib/libc/stdio/setbuf.3 /usr/src/lib/libc/stdio/setbuf.3
--- /usr/src.orig/lib/libc/stdio/setbuf.3 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/setbuf.3 2011-02-19 19:09:13.0 +0100
@@ -79,7 +79,9 @@ and an optimally-sized buffer is obtaine
If a stream refers to a terminal
(as
.Dv stdout
-normally does) it is line buffered.
+normally does), or the environment variable
+.Ev STDIO_IOLBF
+is set, it is line buffered.
The standard error stream
.Dv stderr
is always unbuffered.
@@ -176,6 +178,12 @@ The
function returns what the equivalent
.Fn setvbuf
would have returned.
+.Sh ENVIRONMENT
+.Bl -tag -width .Ev STDIO_IOLBF
+If the environment variable
+.Ev STDIO_IOLBF
+is set, output streams will be line-buffered by default
+even when not referring to a terminal.
.Sh SEE ALSO
.Xr fclose 3 ,
.Xr fopen 3 ,
diff -rup /usr/src.orig/lib/libc/stdio/stdio.3 /usr/src/lib/libc/stdio/stdio.3
--- /usr/src.orig/lib/libc/stdio/stdio.3 2009-08-03 10:13:06.0 +0200
+++ /usr/src/lib/libc/stdio/stdio.3 2011-02-19 12:56:00.0 +0100
@@ -137,7 +137,8 @@ an interactive or
.Dq terminal
device, as determined by the
.Xr isatty 3
-function.
+function (this can be overriden with an environment variable, see
+.Xr setvbuf 3 ) .
In fact,
.Em all
freshly-opened streams that refer to terminal devices
___
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: ffs_copyonwrite panics
Hi Roman, On Mon, May 24, 2010 at 03:21:41PM +0400, Roman Bogorodskiy wrote: I am not sure how to save coredump as when the system boots after the crash and starts saving coredump from swap partition to disk the system crashes again. Generally, the system is almost unusable and in order to try a new kernel I cross-compile it on my i386 laptop and copy in using livefs cdrom. Do you have an idea how to save a trace? Sorry for the late reply. If you're still undergoing this issue, once your kernel has crashed and dumped his memory, you can reboot using your previously working kernel. You will be able to save the core to the disk. Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ 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: Strange disk problem
Hi David, On Tue, Apr 20, 2010 at 08:58:49AM -0700, David Ehrmann wrote: On Tue, Apr 20, 2010 at 5:29 AM, Attilio Rao atti...@freebsd.org wrote: David, do you think you are willing to re-create the problem and do a PMC analysis on it? (If you need any guidance let me know, I will be happy to give it). Maybe, but I don't know what PMC analysis is, so a lot of guidance might be required. Quick howto from Robert Watson: http://lists.freebsd.org/pipermail/freebsd-current/2006-February/061096.html Other interesting links: http://people.freebsd.org/~jkoshy/projects/perf-measurement/ http://people.freebsd.org/~jkoshy/download/acm-apr-09.pdf Regards, -- Jeremie Le Hen Humans are born free and equal. But some are more equal than others. Coluche ___ 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
