Re: panic td-td_lock == NULL in scheduler(), csup'd 2011-02-19
Hi,
it looks similar to
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html
Svata
On Wed, Jun 13, 2012 at 1:11 AM, Benjamin Kaduk ka...@mit.edu wrote:
Hi all,
I know, I should update the machine, but I figured I would throw this out
for the archives anyway.
I saw the panic a few minutes after starting X, but I'm pretty sure I was
not actually swapping. In ddb (blind), I ran 'call doadump; show alllocks;
show lockedvnods; call doadump; reboot' ... I'm not sure whether the two
'doadump's will cause any issues with the core.
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 00
fault virtual address = 0x18
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x806d7dce
stack pointer = 0x28:0x81381c40
frame pointer = 0x28:0x81381ca0
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = resume, IOPL = 0
current process = 0 (swapper)
#7 0x809e20a5 in trap (frame=0x81381b90)
at /usr/src/sys/amd64/amd64/trap.c:319
#8 0x809cc6ef in calltrap ()
at /usr/src/sys/amd64/amd64/exception.S:228
#9 0x806d7dce in _thread_lock_flags (td=0xfe003b14d8c0, opts=0,
file=0x80b4b720 /usr/src/sys/vm/vm_glue.c, line=744)
at /usr/src/sys/kern/kern_mutex.c:560
#10 0x8094b395 in scheduler (dummy=Variable dummy is not
available.
) at /usr/src/sys/vm/vm_glue.c:744
#11 0x8069f8c7 in mi_startup () at /usr/src/sys/kern/init_main.c:256
#12 0x80292f2c in btext () at /usr/src/sys/amd64/amd64/locore.S:81
#13 0x in ?? ()
#14 0x80eff8a0 in cpu_top ()
#15 0x80eff900 in affinity ()
#16 0xfe00025f8000 in ?? ()
#17 0x81381b60 in ?? ()
#18 0x81381b08 in ?? ()
#19 0x80ee6030 in proc0 ()
#20 0x8070e5d2 in sched_switch (td=0x0, newtd=0x0, flags=Variable
flags is not available.
)
at /usr/src/sys/kern/sched_ule.c:1847
I verified that td-td_lock was null using kgdb on the coredump.
kern_mutex.c:
558 retry:
559 spinlock_enter();
560 m = td-td_lock;
561 KASSERT(m-mtx_lock != MTX_DESTROYED,
562 (thread_lock() of destroyed mutex @ %s:%d,
file, l
vm_glue.c:
738 FOREACH_THREAD_IN_PROC(p, td) {
739 /*
740 * An otherwise runnable thread of a process
741 * swapped out has only the TDI_SWAPPED bit
set.
742 *
743 */
744 thread_lock(td);
745 if (td-td_inhibitors == TDI_SWAPPED) {
-Ben Kaduk
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic td-td_lock == NULL in scheduler(), csup'd 2011-02-19
2012/6/13, Svatopluk Kraus onw...@gmail.com: Hi, it looks similar to http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html Yes, that is likely the problem. However, I would really love to workaround the pid allocation race in another way than PRS_NEW because this imposes an extra-constraint, undocumented, on iterations of processes in the system. If you want to work on a patch for that, you are welcome to do so. Attilio -- Peace can only be achieved by understanding - A. Einstein ___ 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
[head tinderbox] failure on arm/arm
TB --- 2012-06-13 13:50:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-13 13:50:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-13 13:50:00 - starting HEAD tinderbox run for arm/arm TB --- 2012-06-13 13:50:00 - cleaning the object tree TB --- 2012-06-13 13:50:00 - cvsupping the source tree TB --- 2012-06-13 13:50:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2012-06-13 13:52:37 - building world TB --- 2012-06-13 13:52:37 - CROSS_BUILD_TESTING=YES TB --- 2012-06-13 13:52:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-13 13:52:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-13 13:52:37 - SRCCONF=/dev/null TB --- 2012-06-13 13:52:37 - TARGET=arm TB --- 2012-06-13 13:52:37 - TARGET_ARCH=arm TB --- 2012-06-13 13:52:37 - TZ=UTC TB --- 2012-06-13 13:52:37 - __MAKE_CONF=/dev/null TB --- 2012-06-13 13:52:37 - cd /src TB --- 2012-06-13 13:52:37 - /usr/bin/make -B buildworld World build started on Wed Jun 13 13:52:37 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Jun 13 14:52:48 UTC 2012 TB --- 2012-06-13 14:52:48 - cd /src/sys/arm/conf TB --- 2012-06-13 14:52:48 - /usr/sbin/config -m AVILA TB --- 2012-06-13 14:52:49 - building AVILA kernel TB --- 2012-06-13 14:52:49 - CROSS_BUILD_TESTING=YES TB --- 2012-06-13 14:52:49 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-13 14:52:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-13 14:52:49 - SRCCONF=/dev/null TB --- 2012-06-13 14:52:49 - TARGET=arm TB --- 2012-06-13 14:52:49 - TARGET_ARCH=arm TB --- 2012-06-13 14:52:49 - TZ=UTC TB --- 2012-06-13 14:52:49 - __MAKE_CONF=/dev/null TB --- 2012-06-13 14:52:49 - cd /src TB --- 2012-06-13 14:52:49 - /usr/bin/make -B buildkernel KERNCONF=AVILA Kernel build for AVILA started on Wed Jun 13 14:52:49 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] ld -EL -b binary -d -warn-common -r -d -o IxNpeMicrocode.fwo IxNpeMicrocode.dat cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/arm/xscale/ixp425/ixp425_qmgr.c cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/dev/usb/controller/ehci_ixp4xx.c cc -mlittle-endian -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mcpu=xscale -ffreestanding -Werror /src/sys/arm/xscale/ixp425/avila_machdep.c cc1: warnings being treated as errors /src/sys/arm/xscale/ixp425/avila_machdep.c: In function 'initarm': /src/sys/arm/xscale/ixp425/avila_machdep.c:241: warning: implicit declaration of function 'parse_boot_param' /src/sys/arm/xscale/ixp425/avila_machdep.c:241: warning: nested extern declaration of 'parse_boot_param' [-Wnested-externs] *** Error code 1 Stop in /obj/arm.arm/src/sys/AVILA. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2012-06-13 14:55:50 - WARNING: /usr/bin/make returned exit code 1 TB --- 2012-06-13 14:55:50 - ERROR: failed to build AVILA kernel TB --- 2012-06-13 14:55:50 - 2562.27 user 587.42 system 3949.72 real
Re: panic td-td_lock == NULL in scheduler(), csup'd 2011-02-19
On Wednesday, June 13, 2012 7:11:10 am Svatopluk Kraus wrote: Hi, it looks similar to http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html Hmm, the code in question has a PRS_NEW check though. Benjamin, can you go to the scheduler() frame and do 'p *p' and 'p *td'? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
jemalloc() assumes DSS is aligned
I tracked down a weird bug at work on the older jemalloc in FreeBSD 8/9 that a
co-worker tripped over. Specifically, if you build the program below and link
it with gold, the program will have an _end symbol that is on an odd address
(std::nothrow results in some single-byte symbol being added to the end of the
BSS). This causes the first arena allocated by jemalloc to use an odd
address, and the rbt_nil structures for that arena's embedded trees (like
runs_avail) to be allocated on odd addresses. This interferes with the RB
trees using the low bit to distinguish red vs black. Specifically, the
program ends up setting the right node of rbt_nil to an incorrect pointer
value (the low bit gets cleared) resulting in an eventual segfault. Looking
at phkmalloc, it always applied round_page() to the results from sbrk(). I
believe that for jemalloc only the very first allocation from the DSS needs to
check for misalignment, and the patch below does fix the segfault on FreeBSD
8. I have a stab at porting the change to jemalloc 3.0.0 in HEAD, but I'm not
sure if it is quite correct. Also, I only made the DSS align on the quantum
boundary rather than a page boundary. BTW, I filed a bug with the binutils
folks as I initially thought this was a gold bug. However, POSIX doesn't make
any guarantees about the return value of sbrk(), so I think gold is not
broken.
Test program:
#include stdio.h
#include new
void foo()
{
char *c = new(std::nothrow) char[10];
delete c;
}
int
main()
{
printf(Hello world\n);
}
Tested patch against FreeBSD 8:
Index: malloc.c
===
--- malloc.c(revision 225507)
+++ malloc.c(working copy)
@@ -5132,6 +5132,9 @@ MALLOC_OUT:
#ifdef MALLOC_DSS
malloc_mutex_init(dss_mtx);
dss_base = sbrk(0);
+ i = (uintptr_t)dss_base QUANTUM_MASK;
+ if (i != 0)
+ dss_base = sbrk(QUANTUM - i);
dss_prev = dss_base;
dss_max = dss_base;
extent_tree_szad_new(dss_chunks_szad);
Untested forward port to jemalloc 3.0.0:
Index: chunk_dss.c
===
--- chunk_dss.c (revision 235919)
+++ chunk_dss.c (working copy)
@@ -123,12 +123,16 @@ chunk_in_dss(void *chunk)
bool
chunk_dss_boot(void)
{
+ uintptr_t off;
cassert(config_dss);
if (malloc_mutex_init(dss_mtx))
return (true);
dss_base = sbrk(0);
+ off = (uintptr_t)dss_base QUANTUM_MASK;
+ if (off != 0)
+ dss_base = sbrk(QUANTUM - off);
dss_prev = dss_base;
dss_max = dss_base;
binutils ld.gold PR: http://sourceware.org/bugzilla/show_bug.cgi?id=14149
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic td-td_lock == NULL in scheduler(), csup'd 2011-02-19
On 13 Jun, Attilio Rao wrote: 2012/6/13, Svatopluk Kraus onw...@gmail.com: Hi, it looks similar to http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html Yes, that is likely the problem. However, I would really love to workaround the pid allocation race in another way than PRS_NEW because this imposes an extra-constraint, undocumented, on iterations of processes in the system. If you want to work on a patch for that, you are welcome to do so. A long time ago I had a patch that moved pid allocation and insertion into allproc to a later point in fork1() where the child had been fully initialized. It had two minor disadvantages. The first is that allproc_lock needed to be acquired and released twice. The second is that nprocs and the number of processes in allproc temporarily become inconsistent while the fork is in progress. Eventually the patch conflicts got too bad and I dropped the patch from my local tree. ___ 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 td-td_lock == NULL in scheduler(), csup'd 2011-02-19
On Wed, 13 Jun 2012, John Baldwin wrote:
On Wednesday, June 13, 2012 7:11:10 am Svatopluk Kraus wrote:
Hi,
it looks similar to
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html
Hmm, the code in question has a PRS_NEW check though.
Benjamin, can you go to the scheduler() frame and do 'p *p' and 'p *td'?
Sure.
(kgdb) frame 10
#10 0x8094b395 in scheduler (dummy=Variable dummy is not available.
) at /usr/src/sys/vm/vm_glue.c:744
744 thread_lock(td);
(kgdb) p *p
$1 = {p_list = {le_next = 0xfe006d4c1000, le_prev = 0x80ee8f60},
p_threads = {tqh_first = 0xfe003b14d8c0, tqh_last = 0xfe003b14d8d0},
p_slock = {lock_object = {lo_name = 0x80b09517 process slock,
lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4},
p_ucred = 0xfe00025e4e00, p_fd = 0x0, p_fdtol = 0x0,
p_stats = 0xfe00058a1000, p_limit = 0x0, p_limco = {c_links = {sle = {
sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0,
c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0},
p_sigacts = 0x0, p_flag = 0, p_state = PRS_NEW, p_pid = 3054, p_hash = {
le_next = 0x0, le_prev = 0xff800023df70}, p_pglist = {le_next = 0x0,
le_prev = 0x0}, p_pptr = 0x0, p_sibling = {le_next = 0x0, le_prev = 0x0},
p_children = {lh_first = 0x0}, p_mtx = {lock_object = {
lo_name = 0x80b0950a process lock, lo_flags = 21168128,
lo_data = 0, lo_witness = 0xff800021a400},
mtx_lock = 18446744071577690160}, p_ksi = 0xfe0002cee850,
p_sigqueue = {sq_signals = {__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0,
0, 0, 0}}, sq_list = {tqh_first = 0x0, tqh_last = 0xfe003b07aa20},
sq_proc = 0xfe003b07a8e0, sq_flags = 1}, p_oppid = 0, p_vmspace = 0x0,
p_swtick = 0, p_realtimer = {it_interval = {tv_sec = 0, tv_usec = 0},
it_value = {tv_sec = 0, tv_usec = 0}}, p_ru = {ru_utime = {tv_sec = 0,
tv_usec = 0}, ru_stime = {tv_sec = 0, tv_usec = 0}, ru_maxrss = 0,
ru_ixrss = 0, ru_idrss = 0, ru_isrss = 0, ru_minflt = 0, ru_majflt = 0,
ru_nswap = 0, ru_inblock = 0, ru_oublock = 0, ru_msgsnd = 0,
ru_msgrcv = 0, ru_nsignals = 0, ru_nvcsw = 0, ru_nivcsw = 0}, p_rux = {
rux_runtime = 0, rux_uticks = 0, rux_sticks = 0, rux_iticks = 0,
rux_uu = 0, rux_su = 0, rux_tu = 0}, p_crux = {rux_runtime = 0,
rux_uticks = 0, rux_sticks = 0, rux_iticks = 0, rux_uu = 0, rux_su = 0,
rux_tu = 0}, p_profthreads = 0, p_exitthreads = 0, p_traceflag = 0,
p_tracevp = 0x0, p_tracecred = 0x0, p_textvp = 0x0, p_lock = 0,
p_sigiolst = {slh_first = 0x0}, p_sigparent = 0, p_sig = 0, p_code = 0,
p_stops = 0, p_stype = 0, p_step = 0 '\0', p_pfsflags = 0 '\0',
p_nlminfo = 0x0, p_aioinfo = 0x0, p_singlethread = 0x0, p_suspcount = 0,
p_xthread = 0x0, p_boundary_count = 0, p_pendingcnt = 0, p_itimers = 0x0,
p_magic = 3203398350, p_osrel = 900033,
p_comm = sh, '\0' repeats 17 times, p_pgrp = 0xfe0002d42880,
p_sysent = 0x80e8b960, p_args = 0xfe005d3e52c0,
p_cpulimit = 9223372036854775807, p_nice = 0 '\0', p_fibnum = 0,
p_xstat = 0, p_klist = {kl_list = {slh_first = 0x0},
kl_lock = 0x806b3480 knlist_mtx_lock,
kl_unlock = 0x806b34a0 knlist_mtx_unlock,
kl_assert_locked = 0x806b3780 knlist_mtx_assert_locked,
kl_assert_unlocked = 0x806b3760 knlist_mtx_assert_unlocked,
kl_lockarg = 0xfe003b07a9d8}, p_numthreads = 1, p_md = {md_ldt = 0x0,
md_ldt_sd = {sd_lolimit = 0, sd_lobase = 0, sd_type = 0, sd_dpl = 0,
sd_p = 0, sd_hilimit = 0, sd_xx0 = 0, sd_gran = 0, sd_hibase = 0,
sd_xx1 = 0, sd_mbz = 0, sd_xx2 = 0}}, p_itcallout = {c_links = {sle = {
sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0,
c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0},
p_acflag = 0, p_peers = 0x0, p_leader = 0x0, p_emuldata = 0x0,
p_label = 0x0, p_sched = 0xfe003b07ad50, p_ktr = {stqh_first = 0x0,
stqh_last = 0xfe003b07ad10}, p_mqnotifier = {lh_first = 0x0},
p_dtrace = 0x0, p_pwait = {cv_description = 0x80b09f6a ppwait,
cv_waiters = 0}, p_dbgwait = {
cv_description = 0x80b09f71 dbgwait, cv_waiters = 0}}
(kgdb) p *td
$2 = {td_lock = 0x0, td_proc = 0xfe003b07a8e0, td_plist = {tqe_next = 0x0,
tqe_prev = 0xfe003b07a8f0}, td_runq = {tqe_next = 0x0,
tqe_prev = 0x0}, td_slpq = {tqe_next = 0x0, tqe_prev = 0x0}, td_lockq = {
tqe_next = 0x0, tqe_prev = 0x0}, td_hash = {le_next = 0x0,
le_prev = 0xff8000247b58}, td_cpuset = 0x0, td_sel = 0x0,
td_sleepqueue = 0xfe0005bdd680, td_turnstile = 0xfe003b14ea80,
td_umtxq = 0xfe0005be0780, td_tid = 100203, td_sigqueue = {sq_signals = {
__bits = {0, 0, 0, 0}}, sq_kill = {__bits = {0, 0, 0, 0}}, sq_list = {
tqh_first = 0x0, tqh_last = 0xfe003b14d970},
sq_proc = 0xfe003b07a8e0, sq_flags = 1}, td_lend_user_pri = 255 '?',
Re: jemalloc() assumes DSS is aligned
On Jun 13, 2012, at 8:31 AM, John Baldwin wrote: I tracked down a weird bug at work on the older jemalloc in FreeBSD 8/9 that a co-worker tripped over. Specifically, if you build the program below and link it with gold, the program will have an _end symbol that is on an odd address (std::nothrow results in some single-byte symbol being added to the end of the BSS). This causes the first arena allocated by jemalloc to use an odd address, and the rbt_nil structures for that arena's embedded trees (like runs_avail) to be allocated on odd addresses. This interferes with the RB trees using the low bit to distinguish red vs black. Specifically, the program ends up setting the right node of rbt_nil to an incorrect pointer value (the low bit gets cleared) resulting in an eventual segfault. Looking at phkmalloc, it always applied round_page() to the results from sbrk(). I believe that for jemalloc only the very first allocation from the DSS needs to check for misalignment, and the patch below does fix the segfault on FreeBSD 8. I have a stab at porting the change to jemalloc 3.0.0 in HEAD, but I'm not sure if it is quite correct. Also, I only made the DSS align on the quantum boundary rather than a page boundary. BTW, I filed a bug with the binutils folks as I initially thought this was a gold bug. However, POSIX doesn't make any guarantees about the return value of sbrk(), so I think gold is not broken. Hi John, Your fix for FreeBSD 7/8/9 looks correct to me. I don't currently have any development machines running anything but 10-CURRENT, so I'd be grateful if you could commit the fix, assuming it isn't much trouble for you. (I'll set up additional development installations if needed.) I don't think this is an issue for HEAD's chunk_alloc_dss(), because there is logic to always insert enough padding to allocate on chunk alignment boundaries, and also base_alloc() no longer makes any attempt to use a partial dss 'chunk'. Thanks, Jason P.S. Sorry about putting off responding to your original email for too long.___ 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 td-td_lock == NULL in scheduler(), csup'd 2011-02-19
On Wednesday, June 13, 2012 11:46:56 am Benjamin Kaduk wrote:
On Wed, 13 Jun 2012, John Baldwin wrote:
On Wednesday, June 13, 2012 7:11:10 am Svatopluk Kraus wrote:
Hi,
it looks similar to
http://lists.freebsd.org/pipermail/freebsd-current/2011-March/023829.html
Hmm, the code in question has a PRS_NEW check though.
Benjamin, can you go to the scheduler() frame and do 'p *p' and 'p *td'?
Sure.
(kgdb) frame 10
#10 0x8094b395 in scheduler (dummy=Variable dummy is not available.
) at /usr/src/sys/vm/vm_glue.c:744
744 thread_lock(td);
(kgdb) p *p
$1 = {p_list = {le_next = 0xfe006d4c1000, le_prev = 0x80ee8f60},
p_threads = {tqh_first = 0xfe003b14d8c0, tqh_last =
0xfe003b14d8d0},
p_slock = {lock_object = {lo_name = 0x80b09517 process slock,
lo_flags = 720896, lo_data = 0, lo_witness = 0x0}, mtx_lock = 4},
p_ucred = 0xfe00025e4e00, p_fd = 0x0, p_fdtol = 0x0,
p_stats = 0xfe00058a1000, p_limit = 0x0, p_limco = {c_links = {sle = {
sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0x0}}, c_time = 0,
c_arg = 0x0, c_func = 0, c_lock = 0x0, c_flags = 0, c_cpu = 0},
p_sigacts = 0x0, p_flag = 0, p_state = PRS_NEW, p_pid = 3054, p_hash = {
Hmmm, p_state == PRS_NEW. I don't understand why this loop didn't bail out
earlier then. This is the code in stock HEAD:
FOREACH_PROC_IN_SYSTEM(p) {
PROC_LOCK(p);
if (p-p_state == PRS_NEW ||
p-p_flag (P_SWAPPINGOUT | P_SWAPPINGIN | P_INMEM)) {
PROC_UNLOCK(p);
continue;
}
swtime = (ticks - p-p_swtick) / hz;
FOREACH_THREAD_IN_PROC(p, td) {
/*
* An otherwise runnable thread of a process
* swapped out has only the TDI_SWAPPED bit set.
*
*/
thread_lock(td);
Granted, my line numbers don't match up with yours (the
FOREACH_THREAD_IN_PROC() is at line 755 in HEAD vs 738 in your core).
Oh, does your subject line mean you are still running a kernel from that date?
I read it as meaning that you had just updated and gotten a crash in
top-of-tree and your previously-fine kernel was from the date in the subject.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc() assumes DSS is aligned
On Wednesday, June 13, 2012 12:29:26 pm Jason Evans wrote: On Jun 13, 2012, at 8:31 AM, John Baldwin wrote: I tracked down a weird bug at work on the older jemalloc in FreeBSD 8/9 that a co-worker tripped over. Specifically, if you build the program below and link it with gold, the program will have an _end symbol that is on an odd address (std::nothrow results in some single-byte symbol being added to the end of the BSS). This causes the first arena allocated by jemalloc to use an odd address, and the rbt_nil structures for that arena's embedded trees (like runs_avail) to be allocated on odd addresses. This interferes with the RB trees using the low bit to distinguish red vs black. Specifically, the program ends up setting the right node of rbt_nil to an incorrect pointer value (the low bit gets cleared) resulting in an eventual segfault. Looking at phkmalloc, it always applied round_page() to the results from sbrk(). I believe that for jemalloc only the very first allocation from the DSS needs to check for misalignment, and the patch below does fix the segfault on FreeBSD 8. I have a stab at porting the change to jemalloc 3.0.0 in HEAD, but I'm not sure if it is quite correct. Also, I only made the DSS align on the quantum boundary rather than a page boundary. BTW, I filed a bug with the binutils folks as I initially thought this was a gold bug. However, POSIX doesn't make any guarantees about the return value of sbrk(), so I think gold is not broken. Hi John, Your fix for FreeBSD 7/8/9 looks correct to me. I don't currently have any development machines running anything but 10-CURRENT, so I'd be grateful if you could commit the fix, assuming it isn't much trouble for you. (I'll set up additional development installations if needed.) Sure, I'm fine with doing that. I don't think this is an issue for HEAD's chunk_alloc_dss(), because there is logic to always insert enough padding to allocate on chunk alignment boundaries, and also base_alloc() no longer makes any attempt to use a partial dss 'chunk'. Ok, this was my main concern was to ensure it was fixed going forward. Thanks, Jason P.S. Sorry about putting off responding to your original email for too long. No problem, I figured the original got lost. :-P -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: est man page
se http://people.freebsd.org/~sbruno/est_man.txt Looks good. Attached a diff for some small fixes. Updated again with feedback that I've gotten. I changed the Note that est interface is automatically loaded to Note that est capabilities are automatically loaded Sean ___ 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 td-td_lock == NULL in scheduler(), csup'd 2011-02-19
On Wed, 13 Jun 2012, John Baldwin wrote: Oh, does your subject line mean you are still running a kernel from that date? I read it as meaning that you had just updated and gotten a crash in top-of-tree and your previously-fine kernel was from the date in the subject. Yes, the subject means that I'm still running the year-plus old code. Sorry to lead you on a wild goose chase... -Ben ___ 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: est man page
On Wed, 13 Jun 2012, Sean Bruno wrote: se http://people.freebsd.org/~sbruno/est_man.txt Looks good. Attached a diff for some small fixes. Updated again with feedback that I've gotten. I changed the Note that est interface is automatically loaded to Note that est capabilities are automatically loaded The only remaining problem I see is .Sh COMPATIBILITY .Nm is only found on supported Intel CPUs. est(4) is not on the supported CPUs, but EST, the feature that est(4) uses. Does supported mean supported by est(4) or supported by the CPU? Maybe Enhanced Speedstep Technology is supported by many Intel CPUs. ___ 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: est man page
On Wed, 13 Jun 2012, Warren Block wrote: On Wed, 13 Jun 2012, Sean Bruno wrote: se http://people.freebsd.org/~sbruno/est_man.txt Looks good. Attached a diff for some small fixes. Updated again with feedback that I've gotten. I changed the Note that est interface is automatically loaded to Note that est capabilities are automatically loaded The only remaining problem I see is .Sh COMPATIBILITY .Nm is only found on supported Intel CPUs. est(4) is not on the supported CPUs, but EST, the feature that est(4) uses. Does supported mean supported by est(4) or supported by the CPU? Maybe Enhanced Speedstep Technology is supported by many Intel CPUs. Oops, and trailing whitespace on lines 66 and 70. ___ 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: [CFT] Xorg 7.7 ready for testing!
On Sun, June 10, 2012 06:46, Alexander Yerenkow wrote: Okay everyone interested - listen up :) http://gits.kiev.ua/FreeBSD/FreeBSD-10-i386-2012-06-08.img.xz Here is the image, which can be dd'ed to 4g+ flash drive. It should be bootable, and contains new xorg, and some soft from ports; - seamonkey (if you want go to internet) - stellarium (it's full of stars) - blender (but it depends on devel/icu which probably built with error, or by some other reason blender produces coredump) - xterm and openbox; How to use: boot, login as root; after passwordless login you can view simple x run script with: cat ./runx.sh or you just launch it ./runx.sh If you have non-intel card, you need edit xorg.conf, and runx.sh (remove load i915kms). Load process and X launching can be a while if you have not very fast flash. I'll continue improving of infrastructure for building such testing images, helps and advises appreciated. is this expected not to work on gma500 ? I tried and got error. no X loaded. matheus -- We will call you Cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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
[head tinderbox] failure on mips/mips
TB --- 2012-06-14 01:57:56 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-06-14 01:57:56 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-06-14 01:57:56 - starting HEAD tinderbox run for mips/mips TB --- 2012-06-14 01:57:56 - cleaning the object tree TB --- 2012-06-14 01:57:56 - cvsupping the source tree TB --- 2012-06-14 01:57:56 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2012-06-14 01:58:29 - building world TB --- 2012-06-14 01:58:29 - CROSS_BUILD_TESTING=YES TB --- 2012-06-14 01:58:29 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-14 01:58:29 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-14 01:58:29 - SRCCONF=/dev/null TB --- 2012-06-14 01:58:29 - TARGET=mips TB --- 2012-06-14 01:58:29 - TARGET_ARCH=mips TB --- 2012-06-14 01:58:29 - TZ=UTC TB --- 2012-06-14 01:58:29 - __MAKE_CONF=/dev/null TB --- 2012-06-14 01:58:29 - cd /src TB --- 2012-06-14 01:58:29 - /usr/bin/make -B buildworld World build started on Thu Jun 14 01:58:30 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Thu Jun 14 02:58:28 UTC 2012 TB --- 2012-06-14 02:58:28 - cd /src/sys/mips/conf TB --- 2012-06-14 02:58:28 - /usr/sbin/config -m ADM5120 TB --- 2012-06-14 02:58:28 - skipping ADM5120 kernel TB --- 2012-06-14 02:58:28 - cd /src/sys/mips/conf TB --- 2012-06-14 02:58:28 - /usr/sbin/config -m ALCHEMY TB --- 2012-06-14 02:58:28 - skipping ALCHEMY kernel TB --- 2012-06-14 02:58:28 - cd /src/sys/mips/conf TB --- 2012-06-14 02:58:28 - /usr/sbin/config -m AP93 TB --- 2012-06-14 02:58:28 - building AP93 kernel TB --- 2012-06-14 02:58:28 - CROSS_BUILD_TESTING=YES TB --- 2012-06-14 02:58:28 - MAKEOBJDIRPREFIX=/obj TB --- 2012-06-14 02:58:28 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-06-14 02:58:28 - SRCCONF=/dev/null TB --- 2012-06-14 02:58:28 - TARGET=mips TB --- 2012-06-14 02:58:28 - TARGET_ARCH=mips TB --- 2012-06-14 02:58:28 - TZ=UTC TB --- 2012-06-14 02:58:28 - __MAKE_CONF=/dev/null TB --- 2012-06-14 02:58:28 - cd /src TB --- 2012-06-14 02:58:28 - /usr/bin/make -B buildkernel KERNCONF=AP93 Kernel build for AP93 started on Thu Jun 14 02:58:28 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_keycache.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_led.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -I/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=1 --param large-function-growth=10 --param max-inline-insns-single=1 -fno-pic -mno-abicalls -G0 -DKERNLOADADDR=0x8005 -march=mips32 -msoft-float -ffreestanding -Werror /src/sys/dev/ath/if_ath_tx.c -I/src/sys/dev/ath cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM
On Jun 12, 2012, at 1:26 PM, Konstantin Belousov wrote: On Tue, Jun 12, 2012 at 05:56:12PM +0200, Jan Sieka wrote: Both versions work indeed. I have analysed other architectures' lib/libc/arch/Symbol.map files and __flt_rounds should go into FBSD_ and *not* into FBSDprivate section. I have verified that at least one of the Perl's libraries (POSIX.so) links to __flt_rounds. Python also links to this function. So to the best of my knowledge current patch is the righteous one. Let me restate my point again. It does not matter whether some application uses the symbol. It does matter whether the symbol is considered the part of exported stable ABI, intended for use by applications. If it is, then FBSD_1.X is the right namespace, otherwise symbol should be moved to private and existing usage fixed. That particular symbol is in FBSD_1.0 for amd64, i386, ia64, powerpc, powerpc64, sparc64. It's in FBSDPrivate_1.0 for arm. It's not defined for mips at all. The latter two seem to be bugs; I just committed r237039 to fix arm. I haven't checked the situation on mips. Tim ___ 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: Possible fix for Perl failing with ../lib/auto/POSIX/POSIX.so: Undefined symbol __flt_rounds on ARM
On Jun 12, 2012, at 1:49 AM, Konstantin Belousov wrote:
On Jun 5, 2012, at 8:09 AM, Jan Sieka wrote:
After investigating the issue it appeared that __flt_rounds symbol is
not exported by libc. Applying the following patch, recompilling world
and Perl fixed the problem and allowed to use Perl on SheevaPlug:
diff --git a/lib/libc/arm/Symbol.map b/lib/libc/arm/Symbol.map
index e8c7f1d..8cdcdaf 100644
--- a/lib/libc/arm/Symbol.map
+++ b/lib/libc/arm/Symbol.map
@@ -70,6 +70,7 @@ FBSDprivate_1.0 {
__divdf3;
__floatsisf;
__floatsidf;
+ __flt_rounds;
__fixsfsi;
__fixdfsi;
__fixunssfsi;
If the symbols are used by normal programs, that I think
we should indeed guarantee ABI stability for them, and FBSD_1.3
namespace is the right namespace to use.
Why 1.3?
This is a common function across every architecture except MIPS right
now (and that's probably easily remedied), so why would it be in
a different section for different architectures?
Tim
___
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
DTrace broken on 9.0-Release?
Hi FreeBSD community,
Today I downloaded and installed FreeBSD 9.0-RELEASE and followed the
directions from http://wiki.freebsd.org/DTrace to get DTrace up and running.
The output of DTrace instrumenting a simple program, however, is not correct.
The program is as follows:
// test.cc
#includecstdlib
int main(void) {
for(int i = 0; i 5; i++) {
malloc(47);
}
}
then compiling and running DTrace as follows:
g++ test.cc -o test
dtrace -n 'pid$target::malloc:entry{ }' -c ./test
The correct output for this example is something to the tune of:
dtrace: description 'pid$target::malloc:entry' matched 2 probes
dtrace: pid 95236 has exited
CPU IDFUNCTION:NAME
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
0 188748 malloc:entry
(this from a machine with the same code running DTrace)
The DTrace session should also make an immediate exit on completion. On FreeBSD
I have the following
CPU IDFUNCTION:NAME
2 42213 malloc:entry
and the execution does either not exit on it's own or hangs, it requires a
ctrl-c.
I followed the instructions from the FreeBSD site exactly, compiling and
installing the custom kernel. I used both clang++ and g++ for compilation with
the same result. The system has even completely hung on other attempts.
Is DTrace not something that should be relied upon in FreeBSD? I have also
tried this on the latest 10-CURRENT build with the same result.
Thanks
Ryan G___
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: DTrace broken on 9.0-Release?
Hi, Would you please make sure you file a PR with exactly what you've just listed above? You've gone into great detail here, so it should be easy to reproduce. What happens if you name it 'test.c' and compile it with cc (as a C source) rather than C++? Adrian ___ 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
