Re: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On Wed, Sep 4, 2013 at 8:45 AM, Nathan Whitehorn nwhiteh...@freebsd.org wrote:
Could you describe what this macro is supposed to do so that we can do the
porting work?
-Nathan
#define GET_STACK_USAGE(total, used)
GET_STACK_USAGE sets the variable passed in total to the total amount
of stack space available to the current thread. used is set to the
amount of stack space currently used (this does not have to have
byte-precision). Netgraph uses this to decide when to stop recursing
and instead defer to a work queue (to prevent stack overflow). I
presume that Alexander is using it in a similar way. It looks like
the amd64 version could be ported to other architectures quite easily
if you were to account for stacks that grow up and stacks that grow
down:
http://svnweb.freebsd.org/base/head/sys/amd64/include/proc.h?revision=233291view=markup
/* Get the current kernel thread stack usage. */
#define GET_STACK_USAGE(total, used) do {\
struct thread*td = curthread;\
(total) = td-td_kstack_pages * PAGE_SIZE;\
(used) = (char *)td-td_kstack +\
td-td_kstack_pages * PAGE_SIZE -\
(char *)td;\
} while (0)
___
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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 24, 2013 at 11:16 AM, Maciej Milewski m...@dat.pl wrote: I've encountered problems with installing FreeBSD-10.0-BETA1 i386 under VirtualBox. The problem is with setting/changing root password during install process. After entering password twice there is: passwd: pam_chauthtok(): error in service module Then there shows pwd_mkdb.core in current directory. The same VirtualBox machine has no problems with installing FreeBSD-9.2-RELEASE Has anyone any clues? Regards, Maciej Milewski I have seen that error when the password database in /etc is not writeable (in my case, / was mounted read-only). ___ 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: Freebsd-10.0-CURRENT problem in the bottom half
On Thu, Oct 31, 2013 at 10:00 AM, Venkata Duvvuru venkatkumar.duvv...@emulex.com wrote: 34.98% [303027] trash_ctor @ /boot/kernel/kernel This indicates that you have INVARIANTS enabled (and you're probably running GENERIC, so you also have WITNESS). These will debugging features will substantially impact performance. To do performance testing on head, you need disable these options from your kernel config: nooptions INVARIANTS nooptions WITNESS nooptions MALLOC_DEBUG_MAXZONES Also, set MALLOC_PRODUCTION=yes in /etc/make.conf. Then rebuild your world and kernel and try again. ___ 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++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
On Wed, Nov 13, 2013 at 11:31 AM, Marcus von Appen m...@freebsd.org wrote: This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? How different is this from the previous situation? As I understand it previously A_defcompiler would be linked against the system libstdc++ and B_gnuish would be linked against the gccXX port libstdc++. In my experience libstdc++ does not have good ABI stability between versions so shouldn't you have the same potential for problems? ___ 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: make release: doesn't work for me, getting
On Fri, Jun 24, 2011 at 8:47 AM, Kim Culhan w8hd...@gmail.com wrote: Attempting to run: make release resulted in 'looping' until a kernel compile directory sys/amd64/compile/* was removed. Maybe I missed something in the docs. -kim ___ 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 http://lists.freebsd.org/pipermail/freebsd-current/2011-June/025326.html ___ 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: em problem in virtualbox since the weekend
On Wed, Jul 20, 2011 at 8:33 AM, Bernhard Froehlich de...@freebsd.org wrote: I think it would be good if someone could try to reproduce that with emulators/virtualbox-ose-legacy which is 3.2.12 to get some vbox dev look into the problem again. I saw the problem this weekend on a Linux host running virtualbox 3.2.8. I can ___ 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: sched_priority: invalid priority 3990 on r225375
I've gotten the following panic twice while running recent builds of head under VirtualBox(FreeBSD 8.2 host). panic: sched_priority: invalid priority 3990: nice 0, ticks 1227873280 ftick 175669871 ltick 175679894 tick pri 3818 The crashes happened while I was running a stress test of the network stack. I have a client machine and a server machine. The client is running head with a patch that I'm trying to prove out; the server should be running with basically stock head as of r225375(I think that there's a couple of minor changes in the tree I used to build the server with, but I've gotten the crash on the client and the server, and neither have any uncommitted patches in common). The server is running several netcat instances in listen mode; the client has a script sitting in a loop starting netcat instances that connect to instances running on the server and send data from client - server. The client also has a script that changes the routing tables periodically. Both the client and the server have crashed once so far. I haven't been running any tests on actual hardware so I can't say whether this is a FreeBSD problem or a VirtualBox problem. I'm going to start running the same tests against VMs running some version of FreeBSD 8 to see if I can reproduce the problem there. In the meantime, I've made a core.txt accessible in case anybody wants to take a look. You can find it at: http://people.freebsd.org/~rstone/sched_priority/core.txt.0.bz2 Please let me know if you need any more information. ___ 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
[PATCH] dtrace crashes when trying to trace fbt probes without CTF data
I get a panic if I try to run a dtrace script that uses an fbt probe from a module that does not have CTF data. The polling patch resolves the issue for me: Index: sys/cddl/dev/fbt/fbt.c === --- sys/cddl/dev/fbt/fbt.c (revision 225756) +++ sys/cddl/dev/fbt/fbt.c (working copy) @@ -1261,7 +1261,7 @@ desc-dtargd_ndx = DTRACE_ARGNONE; /* Get a pointer to the CTF data and it's length. */ - if (linker_ctf_get(ctl, lc) != 0) + if (linker_ctf_get(ctl, lc) != 0 || lc.ctfoffp == NULL) /* No CTF data? Something wrong? *shrug* */ return; However, I'm not entirely sure whether this is the correct approach to fixing the problem(making linker_ctf_get() return an error seems to break dtrace entirely). Does anybody who has familiarity with dtrace's internals have an opinion? ___ 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: r225827 ia64 make buildworld: sendmail: cc1: warnings being treated as errors
On Wed, Sep 28, 2011 at 11:21 AM, Anton Shterenlikht me...@bristol.ac.uk wrote: cc -O2 -pipe -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/src -I/usr/src/usr.sbin/sendmail/../../contrib/sendmail/include -I. -DNEWDB -DNIS -DTCPWRAPPERS -DMAP_REGEX -DDNSMAP -DNETINET6 -DSTARTTLS -D_FFR_TLS_1 -I/usr/local/include -DSASL=2 -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c cc1: warnings being treated as errors /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:112: warning: initialization from incompatible pointer type /usr/src/usr.sbin/sendmail/../../contrib/sendmail/src/main.c:113: warning: initialization from incompatible pointer type *** Error code 1 1 error This looks like this issue: http://lists.freebsd.org/pipermail/freebsd-current/2011-September/027640.html It seems that the fix hasn't been committed yet. ___ 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: 9 hangs with idletick = 0
2011/10/12 Dag-Erling Smørgrav d...@des.no: BTW, can I suggest appropriating one of KTR_SPARE[234] and renaming it to KTR_CLOCK? I don't see why cxgb should use them, let alone all three; it should use KTR_DEV or KTR_NET instead. KTR_MALLOC has been completely unused in the tree since at least FreeBSD 6(presumably since uma went in), so that would be a better candidate to be appropriated. (Independent of that, though, I do agree that nothing in src/ should use KTR_SPAREX. Kinda defeats the purpose of SPAREX). ___ 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: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
I have run into the same issue recently. I have been testing the
following patch(on 8.2-RELEASE) and it seems to have worked for me:
--- mkmakefile.c 11:09:30.0 -0400
+++ mkmakefile.c2011-10-06 11:13:31.0 -0400
@@ -742,15 +742,16 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n.if defined(NORMAL_CTFCONVERT)
- !empty(NORMAL_CTFCONVERT)\n
- \t${NORMAL_CTFCONVERT}\n.endif, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+ fprintf(f, .if defined(NORMAL_CTFCONVERT)
+!empty(NORMAL_CTFCONVERT)\n
+\t${NORMAL_CTFCONVERT}\n.endif\n\n);
}
}
___
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
smp_rendezvous runs with interrupts and preemption enabled on unicore systems
I'm seeing issues on a unicore systems running a derivative of FreeBSD
8.2-RELEASE if something calls mem_range_attr_set. It turns out that
the root cause is a bug in smp_rendezvous_cpus. The first part of
smp_rendezvous_cpus attempts to short-circuit the non-SMP case(note
that smp_started is never set to 1 on a unicore system):
if (!smp_started) {
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
return;
}
The problem is that this runs with interrupts enabled, outside of a
critical section. My system runs with device_polling enabled with hz
set to 2500, so its quite easy to wedge the system by having a thread
run mem_range_attr_set. That has to do a smp_rendezvous, and if a
timer interrupt happens to go off half-way through the action_func and
preempt this thread, the system ends up deadlocked(although once it's
wedged, typing at the serial console stands a good chance of unwedging
the system. Go figure).
I know that smp_rendezvous was reworked substantially on HEAD, but by
inspection it looks like the bug is still present, as the
short-circuit behaviour is still there.
I am not entirely sure of the best way to fix this. Is it as simple
as doing a spinlock_enter before setup_func and a spinlock_exit after
teardown_func? It seems to boot fine, but I'm not at all confident
that I understand the nuances of smp_rendezvous to be sure that there
aren't side effects that I don't know about.
___
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: smp_rendezvous runs with interrupts and preemption enabled on unicore systems
On Mon, Oct 31, 2011 at 7:43 PM, Attilio Rao atti...@freebsd.org wrote: I'm not entirely sure why this exactly breaks though (do you see that happening with a random rendezvous callback or it is always the same?), because that just becames a simple function calling on cpu0, even if I think that there is still a bug as smp_rendezvous callbacks may expect to have interrupts and preemption disabled and the short-circuit breaks that assumption. I have only observed the problem with i686_mrstoreone(smp_rendezvous is called from i686_mrstore). I notice that i686_mrstoreone does scary things like disabling the cache and global TLB entries. My experience was that everything got very slow when i686_mrstoreone was preempted, so it easily could be the case that the system because so slow with the cache disabled that it became livelocked. I don't think that we strictly need the lock here, my preferred solution would be (only test-compiled): I tried the same thing for the SMP case, and it fixed my problem. ___ 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
[PATCH] Fix types of arguments to dtrace syscall return probes
Currently if you try to use the args[] array passed to a syscall
return probe, you get variables with the wrong type. This is because
the systrace implementation is currently using the same function to
provide the same argument types for both the entry and return probes,
which is completely wrong. For example:
# dtrace -v -l -n syscall::mmap:return
ID PROVIDERMODULE FUNCTION NAME
32159syscallmmap return
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: caddr_t
args[1]: size_t
args[2]: int
args[3]: int
args[4]: int
args[5]: off_t
The following patch[1] fixes this and provides the correct type to all
return probes. For example,
# dtrace -l -v -n syscall::mmap:return
ID PROVIDERMODULE FUNCTION NAME
2000syscall freebsd mmap return
Probe Description Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: Unknown
Argument Attributes
Identifier Names: Private
Data Semantics: Private
Dependency Class: ISA
Argument Types
args[0]: caddr_t
args[1]: caddr_t
The patch:
diff --git a/sys/cddl/dev/systrace/systrace.c b/sys/cddl/dev/systrace/systrace.c
index cc48747..31c11c2 100644
--- a/sys/cddl/dev/systrace/systrace.c
+++ b/sys/cddl/dev/systrace/systrace.c
@@ -220,8 +220,12 @@ systrace_getargdesc(void *arg, dtrace_id_t id,
void *parg, dtrace_argdesc_t *des
{
int sysnum = SYSTRACE_SYSNUM((uintptr_t)parg);
- systrace_setargdesc(sysnum, desc-dtargd_ndx, desc-dtargd_native,
- sizeof(desc-dtargd_native));
+ if (SYSTRACE_ISENTRY((uintptr_t)parg))
+ systrace_entry_setargdesc(sysnum, desc-dtargd_ndx,
+ desc-dtargd_native, sizeof(desc-dtargd_native));
+ else
+ systrace_return_setargdesc(sysnum, desc-dtargd_ndx,
+ desc-dtargd_native, sizeof(desc-dtargd_native));
if (desc-dtargd_native[0] == '\0')
desc-dtargd_ndx = DTRACE_ARGNONE;
diff --git a/sys/kern/makesyscalls.sh b/sys/kern/makesyscalls.sh
index d1162b5..1f081ce 100644
--- a/sys/kern/makesyscalls.sh
+++ b/sys/kern/makesyscalls.sh
@@ -38,6 +38,7 @@ sysinc=sysinc.switch.$$
sysarg=sysarg.switch.$$
sysprotoend=sysprotoend.$$
systracetmp=systrace.$$
+systraceret=systraceret.$$
if [ -r capabilities.conf ]; then
capenabled=`cat capabilities.conf | grep -v ^# | grep -v ^$`
@@ -46,9 +47,9 @@ else
capenabled=
fi
-trap rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4
$syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl
$sysent $sysinc $sysarg $sysprotoend $systracetmp 0
+trap rm $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4
$syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl
$sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret 0
-touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4
$syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl
$sysent $sysinc $sysarg $sysprotoend $systracetmp
+touch $sysaue $sysdcl $syscompat $syscompatdcl $syscompat4
$syscompat4dcl $syscompat6 $syscompat6dcl $syscompat7 $syscompat7dcl
$sysent $sysinc $sysarg $sysprotoend $systracetmp $systraceret
case $# in
0) echo usage: $0 input-file config-file 12
@@ -96,6 +97,7 @@ s/\$//g
sysmk = \$sysmk\
systrace = \$systrace\
systracetmp = \$systracetmp\
+ systraceret = \$systraceret\
compat = \$compat\
compat4 = \$compat4\
compat6 = \$compat6\
@@ -179,9 +181,12 @@ s/\$//g
printf \tint64_t *iarg = (int64_t *) uarg;\n systrace
printf \tswitch (sysnum) {\n systrace
- printf static void\nsystrace_setargdesc(int sysnum,
int ndx, char *desc, size_t descsz)\n{\n\tconst char *p = NULL;\n
systracetmp
+ printf static void\nsystrace_entry_setargdesc(int
sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p =
NULL;\n systracetmp
printf \tswitch (sysnum) {\n systracetmp
+ printf static void\nsystrace_return_setargdesc(int
sysnum, int ndx, char *desc, size_t descsz)\n{\n\tconst char *p =
NULL;\n systraceret
+ printf \tswitch (sysnum) {\n systraceret
+
next
}
NF == 0 || $1 ~ /^;/ {
@@ -202,6 +207,7
[PATCH] Fix kernel panics when using dtrace fbt return probes on i386
I have a patch that fixes crash when using dtrace fbt return probes on i386. dtrace implements an fbt probe by overwriting a small part of the function when the probe is active. On i386, it writes an invalid opcode. dtrace has a hook into the invalid opcode fault handler that checks whether the fault was due to an active probe; if it was, the probe fires and then the fault handler emulates the behaviour of the instruction that was replaced with the invalid opcode and returns control to the instruction after the invalid opcode. The bug is in the emulation of the leave instruction(which is replaced for an fbt return probe). The is a small window in which the emulation leaves critical state above the current stack pointer. If the CPU takes an interrupt in this window, the trap frame corrupts this state. The leave instruction is used to pop off a stack frame immediately prior to returning from a function. Because the leave emulation is running in a fault handler, it must copy the trap frame to the bottom of the stack frame that is being removed, set its stack pointer to the start of the new trap frame and then execute the iret instruction. There are actually two bugs in the current implementation. The first is that immediately before restoring the stack pointer to point to the new trap frame, the emulation must save the new stack pointer on the stack, restore the values of its scratch registers, and then load the new stack pointer back from the stack. The current implementation saves the new stack pointer at -4(%esp). If an interrupt is taking after the new stack pointer is saved at this location the trap frame will overwrite the new stack pointer. The fix for this is to instead save the new stack pointer at 8(%esp), which was part of the old trap frame that was copied forward. This is safe as we know that the trap frame must exist (so 8(%esp) can't possibly point to still-valid data from the next stack frame, for instances) and at this point we have copied the stack frame forward so we can safely overwrite the old one without any issues. The second bug is that when the new stack pointer is restored, it does not point at the new trap frame. Instead it points 8 bytes into the trap frame. The emulation code corrects for this by subtracting 8 from %esp before executing the iret. However if we take an interrupt after we have restored the new stack pointer, but before subtracting 8 from %esp, the trap frame from the interrupt will overwrite the first 8 bytes of the invalid opcode trap frame, causing us to crash when we execute the iret. The fix is to adjust the new stack pointer before saving onto the stack in the first place, so that we we restore it it is immediately valid, closing the window in which an interrupt can corrupt anything. If there are no objections to this patch I will commit it soonish. I would appreciate some review, but IMO this really needs to get in for 9.0 as a central tenet of dtrace is that it will not crash your system. Index: sys/cddl/dev/dtrace/i386/dtrace_asm.S === --- sys/cddl/dev/dtrace/i386/dtrace_asm.S (revision 227094) +++ sys/cddl/dev/dtrace/i386/dtrace_asm.S (working copy) @@ -125,11 +125,11 @@ movl8(%esp), %eax /* load calling EIP */ incl%eax/* increment over LOCK prefix */ movl%eax, -8(%ebx) /* store calling EIP */ - movl%ebx, -4(%esp) /* temporarily store new %esp */ + subl$8, %ebx/* adjust for three pushes, one pop */ + movl%ebx, 8(%esp) /* temporarily store new %esp */ popl%ebx/* pop off temp */ popl%eax/* pop off temp */ - movl-12(%esp), %esp /* set stack pointer */ - subl$8, %esp/* adjust for three pushes, one pop */ + movl(%esp), %esp/* set stack pointer */ iret/* return from interrupt */ invop_nop: /* ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Fix types of arguments to dtrace syscall return probes
On Mon, Nov 7, 2011 at 9:16 AM, Paul Ambrose ambrose...@gmail.com wrote:
diff --git a/sys/kern/kern_ctf.c b/sys/kern/kern_ctf.c
index bdff96e..2737860 100644
--- a/sys/kern/kern_ctf.c
+++ b/sys/kern/kern_ctf.c
@@ -90,7 +90,7 @@ link_elf_ctf_get(linker_file_t lf, linker_ctf_t *lc)
* ctfcnt to -1. See below.
*/
if (ef-ctfcnt 0)
- return (0);
+ return (EFTYPE);
/* Now check if we've already loaded the CTF data.. */
if (ef-ctfcnt 0) {
---
I have committed this as r227342. Thanks for the fix.
And I post another fix for the ${NORMAL_CTFCONVERT} issue, could you
check it for me?
Yes, I can take a look.
kern/160307, I check the /boot/kernel/kernel with ctfdump, and found
the kernel image has right ctf information, do you
have any idea?
Offhand, no. I'll try to find some time to look at your PRs.
___
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: config(8) does not add post-processing for source file with compile-with command in sys/conf/files
On Tue, Oct 18, 2011 at 10:21 PM, Paul Ambrose ambrose...@gmail.com wrote:
when I digged the a PR(bin/160275), I found in_proto.c and
if_ethersubr.c ( see sys/conf/files ) does not get
${NORMAL_CTFCONVERT} post-processing in Makefile
(/usr/obj/usr/src/sys/MYKERNEL/Makefile) generated by config(8), so
the objs does not contain ctf section
Here's a second attempt at this one. I think that this version is
much cleaner than the other options in this thread. If it survives a
make universe I intend to commit this:
Index: usr.sbin/config/mkmakefile.c
===
--- usr.sbin/config/mkmakefile.c(revision 227341)
+++ usr.sbin/config/mkmakefile.c(working copy)
@@ -762,16 +762,21 @@
break;
}
snprintf(cmd, sizeof(cmd),
- ${%s_%c%s}\n\t@${NORMAL_CTFCONVERT}, ftype,
+ ${%s_%c%s}\n, ftype,
toupper(och),
ftp-f_flags NOWERROR ? _NOWERROR : );
compilewith = cmd;
}
*cp = och;
if (strlen(ftp-f_objprefix))
- fprintf(f, \t%s $S/%s\n\n, compilewith, np);
+ fprintf(f, \t%s $S/%s\n, compilewith, np);
else
- fprintf(f, \t%s\n\n, compilewith);
+ fprintf(f, \t%s\n, compilewith);
+
+ if (!(ftp-f_flags NO_OBJ))
+ fprintf(f, \t@${NORMAL_CTFCONVERT}\n\n);
+ else
+ fprintf(f, \n);
}
}
___
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
[PATCH] Allow syslogd to accept multiple configuration files
I've written the following patch to allow syslogd to accept multiple
configuration files by passing multiple -f options. One use case for
this is to specify a common configuration file that applies across
multiple machines along with a second config file specific to the
local machine.
The patch can also be found at
http://people.freebsd.org/~rstone/patches/syslogd-multiconf.diff
(Oh, and before somebody asks, the reason that I converted struct
filed to use a TAILQ was that at one point I found myself typing
struct filed ***, then hit myself and refactored the code instead).
Index: syslogd.c
===
--- syslogd.c (revision 227341)
+++ syslogd.c (working copy)
@@ -114,7 +114,6 @@
#define SYSLOG_NAMES
#include sys/syslog.h
-const char *ConfFile = _PATH_LOGCONF;
const char *PidFile = _PATH_LOGPID;
const char ctty[] = _PATH_CONSOLE;
@@ -141,6 +140,13 @@
STAILQ_HEAD(, funix) funixes = { funix_default,
(funix_secure.next.stqe_next) };
+struct conf_file {
+ const char *name;
+ TAILQ_ENTRY(conf_file) next;
+};
+
+TAILQ_HEAD(, conf_file) conf_list = TAILQ_HEAD_INITIALIZER(conf_list);
+
/*
* Flags to logmsg().
*/
@@ -159,7 +165,7 @@
*/
struct filed {
- struct filed *f_next; /* next in linked list */
+ TAILQ_ENTRY(filed) f_next; /* next in linked list */
short f_type; /* entry type, see below */
short f_file; /* file descriptor */
time_t f_time; /* time this was last written */
@@ -266,7 +272,7 @@
FORW, USERS,WALL, PIPE
};
-static struct filed *Files;/* Log files that we write to */
+static TAILQ_HEAD(, filed) Files = TAILQ_HEAD_INITIALIZER(Files);
static struct filed consfile; /* Console */
static int Debug; /* debug flag */
@@ -351,6 +357,7 @@
struct timeval tv, *tvp;
struct sigaction sact;
struct funix *fx, *fx1;
+ struct conf_file *conf;
sigset_t mask;
pid_t ppid = 1, spid;
socklen_t len;
@@ -393,7 +400,11 @@
Debug++;
break;
case 'f': /* configuration file */
- ConfFile = optarg;
+ conf = malloc(sizeof(*conf));
+ if (conf == NULL)
+ errx(1, Could not alloc memory, exiting);
+ conf-name = optarg;
+ TAILQ_INSERT_TAIL(conf_list, conf, next);
break;
case 'k': /* keep remote kern fac */
KeepKernFac = 1;
@@ -497,6 +508,14 @@
setlinebuf(stdout);
}
+ if (TAILQ_EMPTY(conf_list)) {
+ conf = malloc(sizeof(*conf));
+ if (conf == NULL)
+ errx(1, Could not alloc memory, exiting);
+ conf-name = _PATH_LOGCONF;
+ TAILQ_INSERT_TAIL(conf_list, conf, next);
+ }
+
if (NumAllowed)
endservent();
@@ -989,7 +1008,7 @@
(void)sigsetmask(omask);
return;
}
- for (f = Files; f; f = f-f_next) {
+ TAILQ_FOREACH(f, Files, f_next) {
/* skip messages that are incorrect priority */
if (!(((f-f_pcmp[fac] PRI_EQ) (f-f_pmask[fac] == prilev))
||((f-f_pcmp[fac] PRI_LT) (f-f_pmask[fac] prilev))
@@ -1066,7 +1085,7 @@
{
struct filed *f;
- for (f = Files; f; f = f-f_next) {
+ TAILQ_FOREACH(f, Files, f_next) {
if ((f-f_type == F_FILE)
(f-f_flags FFLAG_NEEDSYNC)) {
f-f_flags = ~FFLAG_NEEDSYNC;
@@ -1403,7 +1422,7 @@
goto oncemore;
/* Now, look in list of active processes. */
- for (f = Files; f; f = f-f_next)
+ TAILQ_FOREACH(f, Files, f_next)
if (f-f_type == F_PIPE
f-f_un.f_pipe.f_pid == pid) {
(void)close(f-f_file);
@@ -1505,7 +1524,7 @@
was_initialized = Initialized;
Initialized = 0;/* Don't log SIGCHLDs. */
- for (f = Files; f != NULL; f = f-f_next) {
+ TAILQ_FOREACH(f, Files, f_next) {
/* flush any pending output */
if (f-f_prevcount)
fprintlog(f, 0, (char *)NULL);
@@ -1528,90 +1547,37 @@
exit(1);
}
-/*
- * INIT -- Initialize syslogd from configuration table
- */
-static void
-init(int signo)
+static int
+parse_conf(const char *conf)
{
int i;
FILE *cf;
- struct filed *f, *next, **nextp;
+ struct filed *f;
char *p;
char cline[LINE_MAX];
char prog[NAME_MAX+1];
char
Re: [PATCH] Allow syslogd to accept multiple configuration files
On Wed, Nov 9, 2011 at 11:01 AM, Brooks Davis bro...@freebsd.org wrote: Do you happen to know why the code calloc's the struct filed's with 1's? I didn't do any investigation but that's seems like an odd pattern. calloc(1, sizeof(*f)) returns an array of 1 element of size sizeof(*f) that is pre-zeroed. It's the userland equivalent of malloc(sizeof(*f), ..., M_ZERO). ___ 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: ixgbe and fast interrupts
The comments haven't kept up with the code. You are correct; in the legacy interrupt case ixgbe is using an ITHREAD, not a fast handler. ___ 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: iSCSI initiator: iscontrol cannot be stopped or killed
On Wed, Nov 23, 2011 at 7:26 PM, Mark Martinec mark.martinec+free...@ijs.si wrote: Problem: the iscontrol process starts normally and establishes a session and brings up a device, but it cannot be stopped. It does not react to a HUP signal, and neither to KILL. If you can get it back into this state, a procstat -k -k iscontrol pid would be very helpful. (the second -k is not a typo). ___ 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: array index of '-16' indexes before the beginning of the array
On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon a...@freebsd.org wrote: Looks like clang has found a real issue here: /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' indexes before the beginning of the array [-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = IRQ_DTRACE_RET; IDT_DTRACE_RET (0x20) indeed seems to be less than APIC_IO_INTS. Uh-oh, I appear to have broken this in r227290. I'll try to figure out what's actually supposed to be done here. ___ 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: array index of '-16' indexes before the beginning of the array
On Sun, Nov 27, 2011 at 6:42 PM, Andriy Gapon a...@freebsd.org wrote: Looks like clang has found a real issue here: /usr/src/sys/x86/x86/local_apic.c:311:2: warning: array index of '-16' indexes before the beginning of the array [-Warray-bounds] lapics[apic_id].la_ioint_irqs[IDT_DTRACE_RET - APIC_IO_INTS] = IRQ_DTRACE_RET; Hm, so as far as I can tell the DTrace-related code in local_apic.c is bogus. DTrace's interrupt vectors are 32 and 33, which aren't I/O vectors, so local_apic.c shouldn't need to know anything about them. I think that the right fix is to remove all of it from local_apic.c. ___ 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: WITHOUT_PROFILE=yes by default
On Fri, Dec 2, 2011 at 10:56 AM, Lyndon Nerenberg lyn...@orthanc.ca wrote: If you choose not to profile your code, that's entirely your choice. Breaking this functionality for everyone else who *does* make the effort to profile their code is a non-starter. Using profiled libs and gprof to profile your code has been obsolete in FreeBSD on i386 and amd64 for over six years now. ___ 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: WITHOUT_PROFILE=yes by default
On Fri, Dec 2, 2011 at 12:07 PM, Lyndon Nerenberg lyn...@orthanc.ca wrote: No, these days 'obsolete' seems to mean 'it does not have a sexy Flash-driven web GUI.' In this case, 'obsolete' means it's a difficult-to-use tool that requires recompiling your application, can't be used in production, doesn't work when shared libraries are in the picture, offers limited-to-no visibility into the underlying reasons why a particular code path is a hotspot and introduces large measurement errors ___ 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 c++ internal error
Is the system running out of memory? A message will go to dmesg if so.
On Aug 19, 2012 10:01 AM, Randy Bush ra...@psg.com wrote:
soekris 5501, been running fbsd since 6.x
csup Aug 18 22:38 gmt
rm -rf /usr/obj
buildworld
c++ -O2 -pipe -DIPFIREWALL_NAT -march=pentium
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/include
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/tools/clang/include
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore -I.
-I/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/../../lib/clang/include
-DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS
-D__STDC_CONSTANT_MACROS
-DLLVM_DEFAULT_TARGET_TRIPLE=\i386-unknown-freebsd9.0\
-DDEFAULT_SYSROOT=\\ -fstack-protector -fno-exceptions -c
/usr/src/lib/clang/libllvmcore/../../../contrib/llvm/lib/VMCore/Function.cpp
-o Function.o
{standard input}: Assembler messages:
{standard input}:36465: Warning: end of file not at end of a line; newline
inserted
{standard input}:36631: Error: unknown pseudo-op: `.lc798'
c++: Internal error: Killed: 9 (program cc1plus)
Please submit a full bug report.
See URL:http://gcc.gnu.org/bugs.html for instructions.
*** Error code 1
Stop in /usr/src/lib/clang/libllvmcore.
# cat /etc/make.conf
KERNCONF=SOEK0
CPUTYPE?=i586
CFLAGS+= -DIPFIREWALL_NAT
MAKE_IDEA=YES
WITHOUT_X11=yes
USA_RESIDENT=YES
# cat /etc/src.conf
WITHOUT_ATM=yes
WITHOUT_BIND=yes
WITHOUT_BLUETOOTH=yes
WITHOUT_FLOPPY=yes
WITHOUT_GAMES=yes
WITHOUT_GPIB=YES
WITHOUT_I4B=YES
WITH_IDEA=yes
WITHOUT_IPFILTER=yes
WITHOUT_IPX=yes
WITHOUT_KERBEROS=yes
WITHOUT_LPR=yes
WITHOUT_OBJC=yes
WITHOUT_PF=YES
WITHOUT_PROFILE=yes
WITHOUT_SENDMAIL=yes
WITHOUT_USB=yes
___
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: buildworld c++ internal error
Are you running make with -j something? You may have to scale that back, unfortunately. C++ compilers seem to be much more memory hungry than straight C compilers. On Aug 19, 2012 10:39 AM, Randy Bush ra...@psg.com wrote: Is the system running out of memory? A message will go to dmesg if so. bingo! thank you. pid 73951 (cc1plus), uid 0, was killed: out of swap space as this is a 8g cd card machine, i may have a problem. it's not as if i can boot a cd rom and run shrinkfs randy ___ 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
machdep.hyperthreading_allowed does not affect SMT cores
I have a Intel Sandy Bridge system that reports that it has SMT cores instead of HTT(under a derivative of FreeBSD 8.2). I'll admit that I don't at all understand the distinction between the two -- I thought that HTT was just Intel's name for SMT. In any case, is there any reason that machdep.hyperthreading_allowed should not apply to SMT cores, too? ___ 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: build failure r240669
On Tue, Sep 18, 2012 at 3:17 PM, Kim Culhan w8hd...@gmail.com wrote: Ah right sorry about that, take 2: clang -pg -O2 -pipe -DTERMIOS -DANSI_SOURCE -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl -I/ usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto -I/usr/obj/usr/src/secure/lib/libcrypto -DOPE NSSL_THREADS -DDSO_DLFCN -DHAVE_DLFCN_H -DOPENSSL_NO_IDEA -DL_ENDIAN -DOPENSSL_IA32_SSE2 -DAES_ASM -DBSAE S_ASM -DVPAES_ASM -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DMD5_ASM -DGHASH_AS M -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DWHIRLPOOL_ASM -I/usr/src/secure/lib/libcrypto/../../../crypto/op enssl/crypto/asn1 -I/usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/evp -I/usr/src/secure/li b/libcrypto/../../../crypto/openssl/crypto/modes -DNO_IDEA -std=gnu89 -Qunused-arguments -fstack-protecto r -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno -parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c /usr/src/secure/lib/libcrypto/../../../crypto/openssl/crypto/x509v3/pcy_tree.c -o pcy_tree.po /usr/src/sbin/nvmecontrol/nvmecontrol.c:77:6: error: cast from 'struct nvme_controller_data *' to 'uint32 _t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Werror,-Wcast-align] p = (uint32_t *)cdata; ^ 1 error generated. *** [nvmecontrol.o] Error code 1 1 error *** [all] Error code 2 1 error *** [sbin.all__D] Error code 2 Fixed in r240671. ___ 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: ZFS TRIM support committed to HEAD.
On Mon, Sep 24, 2012 at 1:03 PM, Steven Hartland kill...@multiplay.co.uk wrote: Ahh yes looks like ATA supports BIO_DELETE via ATA_CFA_ERASE if the drive announces ATA_PROTO_CFA, so I can only assume this is failing when it shouldn't. Might be nice to investigate what's happening and fix, but as ATA is being replaced by CAM ATA not sure its worth it? I believe that the code that you are looking at refers to a old command that is only implemented by CompactFlash cards. The ad(4) driver does not currently support the TRIM command. I have an internal patch that implements it for FreeBSD 8.2; if there's interest I could try to dig it out. ___ 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?
Or the TTL of TCP connections might be too high for the volume of connections received. Someone else on net@ reported that changing this value to more aggressively reap sockets improved performance greatly (at the cost that more connections potentially needing to be reestablished and/or getting dropped on the floor if things go too high volume). That's a different topic I think. On busy web servers it's fairly typical to have a lot of TCP sockets staying in TIME_WAIT state for extended time and the usual tuning would be to set MSL to about 2 seconds at the expense of sacrificing slow clients who can't make 3-way handshake in time (*), etc. The TTL of IP packet have nothing to do with this though, and our default (64) is saner than many other operating systems. Presumably RTT was meant here instead of TTL. ___ 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: Module is no longer loaded
You didn't build with WITH_CTF=1 ___ 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
Supermicro X8DT6 crashes in bootloader after r239066
I have a X8DT6 that appears to crash in the bootloader from HEAD. I say appears to because it's difficult to really see what the problem is; the system reboots pretty much as soon as it enters the FreeBSD boot process. The problem affects PXE booting, booting from ZFS on GPT on a SATA drive and UFS on MBR on a USB stick. The problem only occurs if I have any SATA disks plugged in. If I remove all SATA disks I can successfully PXE boot or boot from a USB key. I've tried with a couple of different SATA disks, some with GPT and some with MBR, and the reboot happens in both cases. The last things that I see on the serial console before the reboot is: DHCP..- ^[[06;07H^[[06;00HDH CP..\ ^[ [06;07H^[[05;00HCLIENT MAC ADDR: 00 25 90 92 19 94 GUID: 84F7C23B 5F21 2533 625 C 002590921994 ^[[06;00HCLIENT IP: 172.16.1.50 MASK: 255.255.255.0 DHCP IP: 1 72.16.1.1^[[07;00HGATEWAY IP: 172.16.1.1 ^[[08;00HPXE Loader 1.00^[[2JM-^@^[[01;00H^[[0 m^[[2m^[[0m^[[2;30;40m ^@^[[0m^[[2;37;40m ^[[02;00H^[[0m^[[2;30;40m So it really doesn't seem to get very far at all. I've bisected and confirmed that the problem was introduced in r239066. I tried reverting that commit locally and I can boot fine again. I took a quick look at that commit but it appears to be way over my head. I'm willing to test patches or gather more debugging information; this thing isn't going anywhere until I can get it booting. :) Ryan ___ 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: Dynamic Ticks/HZ
On Mon, Nov 5, 2012 at 4:40 AM, Joe Holden li...@rewt.org.uk wrote: doh, running kernel wasn't as GENERIC as I thought it was, looks like device polling not only breaks dynamic ticks but also reduces rx ability significantly, exactly 150,000 pps per 1000hz on igb versus 650,000 without Is this a known issue? (and if device polling isn't as useful as it once was, should it be removed?) Device polling on modern multiqueue NICs isn't very useful because you're limited to a single thread for handling packets. I have a patch that fixes this that I've let fall by the wayside. ___ 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: sysutils/lsof Author Question (for CLANG)....
It exists in a header that is generated by the FreeBSD build process. On Wed, Nov 7, 2012 at 10:27 AM, Larry Rosenman l...@lerctr.org wrote: Vic Abell (the lsof author) asked me the following: In adjusting for clang I have come up with an unanswered question. Where is the VOP_UNLOCK() macro defined? I've done a full search of all the files in /usr/src/sys and can't find its definition, but I find many, many uses. Perhaps someone on the freebsd-current list knows. Can someone help me help him? __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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
pw keeps setting /etc/group to 0600
/etc/group is supposed to be world-reable, right? Tools like groups or pw groupshow certainly seem to think so: [rstone@rstone-server ~]groups 1001 920 [rstone@rstone-server ~]ls -l /etc/group -rw--- 1 root 0 482 Nov 14 21:02 /etc/group [rstone@rstone-server ~]sudo chmod a+r /etc/group Password: [rstone@rstone-server ~]groups rstone vboxusers [rstone@rstone-server ~]sudo pw groupadd foo [rstone@rstone-server ~]ls -l /etc/group -rw--- 1 root 0 494 Nov 17 10:19 /etc/group [rstone@rstone-server ~] I'm not sure what caused the regression. I've been seeing the problem since I first installed -CURRENT on the machine a couple of weeks ago. ___ 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: pw keeps setting /etc/group to 0600
Wow. So apparently things are even more broken than I though. Let's play, What group am I in? root@group-testing:/usr/home/rstone # cd /tmp root@group-testing:/tmp # pw groupadd testing root@group-testing:/tmp # mkdir testdir root@group-testing:/tmp # chown root:testing testdir/ root@group-testing:/tmp # chmod g+rwx testdir/ root@group-testing:/tmp # pw usermod root@group-testing:/tmp # pw groupmod testing -m rstone root@group-testing:/tmp # id rstone uid=1001(rstone) gid=1001(rstone) groups=1001(rstone),0(wheel),1002(testing) root@group-testing:/tmp # exit $ id uid=1001(rstone) gid=1001 groups=1001,0 $ id rstone uid=1001(rstone) gid=1001 groups=1001 $ touch /tmp/testdir/testfile touch: /tmp/testdir/testfile: Permission denied $ ls -ld /tmp/testdir/ drwxrwxr-x 2 root 1002 512 Nov 17 11:07 /tmp/testdir/ My original complaint that /etc/group gets permissions of 0600 is a result of a bug in libutil, which bapt@ ported pw to use in r242349. The new group manipulation API using mktemp to create a temporary file, writes the new group database to the temp file and then renames the temp file to /etc/group. The problem here is that mktemp creates a file with a mode of 600, and libutil never chmods it. That should be pretty trivial to fix. I have no idea what's happening in my example above, though. Baptiste, I have to ask: how much testing did r242349 receive before it was committed? ___ 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
Spurious witness warning when destroying spin mtx
Today I saw a spurious witness warning for acquiring duplicate lock of
same type. The root cause is that when running mtx_destroy on a spinlock
that is held by the current thread, mtx_destroy calls spinlock_exit()
before calling WITNESS_UNLOCK, which opens up a window in which the CPU can
be interrupted and attempt to acquire another spinlock of the same type as
the one being destroyed. This patch should fix it:
diff --git a/sys/kern/kern_mutex.c b/sys/kern/kern_mutex.c
index 2f13863..96f43f8 100644
--- a/sys/kern/kern_mutex.c
+++ b/sys/kern/kern_mutex.c
@@ -918,16 +918,16 @@ _mtx_destroy(volatile uintptr_t *c)
else {
MPASS((m-mtx_lock (MTX_RECURSED|MTX_CONTESTED)) == 0);
+ lock_profile_release_lock(m-lock_object);
+ /* Tell witness this isn't locked to make it happy. */
+ WITNESS_UNLOCK(m-lock_object, LOP_EXCLUSIVE, __FILE__,
+ __LINE__);
+
/* Perform the non-mtx related part of mtx_unlock_spin(). */
if (LOCK_CLASS(m-lock_object) == lock_class_mtx_spin)
spinlock_exit();
else
curthread-td_locks--;
-
- lock_profile_release_lock(m-lock_object);
- /* Tell witness this isn't locked to make it happy. */
- WITNESS_UNLOCK(m-lock_object, LOP_EXCLUSIVE, __FILE__,
- __LINE__);
}
m-mtx_lock = MTX_DESTROYED
___
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: Spurious witness warning when destroying spin mtx
On Sat, Nov 24, 2012 at 10:01 AM, Attilio Rao atti...@freebsd.org wrote:
I seriously wonder why right now we don't assume the lock is unheld.
There are likely historically reasons for that, but I would like to
know which one are those and eventually fix them out.
FWIK, all the other locking primitives assume the lock is already
unheld when destroying and I think it would be good to have that for
mutexes as well.
Can you please show which lock triggers the panic you saw?
Thanks,
Attilio
It was taskqueue_free:
void
taskqueue_free(struct taskqueue *queue)
{
TQ_LOCK(queue);
queue-tq_flags = ~TQ_FLAGS_ACTIVE;
taskqueue_terminate(queue-tq_threads, queue);
KASSERT(TAILQ_EMPTY(queue-tq_active), (Tasks still running?));
KASSERT(queue-tq_callouts == 0, (Armed timeout tasks));
mtx_destroy(queue-tq_mutex);
free(queue-tq_threads, M_TASKQUEUE);
free(queue, M_TASKQUEUE);
}
___
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: Distributed audit daemon committed (was: svn commit: r243752 - in head: etc etc/defaults etc/mail etc/mtree etc/rc.d share/man/man4 usr.sbin usr.sbin/auditdistd (fwd))
On Sun, Dec 2, 2012 at 8:05 AM, Robert Watson rwat...@freebsd.org wrote: Just to follow up on this thread, since the question has come up a number of times. mergemaser -p should be run prior to installworld always, but most of the time will do very little. One of its responsibilities is to add any necessary accounts and groups depended on by base system components -- e.g., that will be referenced during installworld as part of setting file ownership and groups. I often use make installworld installkernel distribution DESTDIR=... to create bootable images (e.g. for a USB stick). What's the recommendation for that case? Manually create the auditdistd user on the build host? ___ 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: kernel module parallel build?
On Tue, Dec 4, 2012 at 10:52 AM, John Baldwin j...@freebsd.org wrote: Hmm, I certainly see the module directories being built in parallel. Some of the make jobs may not be as obvious since links are silent (no output unless there is an error). This is definitely not the behaviour that I see trying to build any version of FreeBSD. I see the same behaviour as Andre: the depend and all targets both iterate through the module directories sequentially. It never builds two module subdirectories concurrently. ___ 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: problems with threads/destructors in -current with llvm/clang
On Mon, Dec 10, 2012 at 12:35 PM, Mark Atkinson atkin...@gmail.com wrote: vex x86-IR: unhandled instruction bytes: 0xF 0xB 0x90 0x90 ==33074== valgrind: Unrecognised instruction at address 0x380434e9. ==33074==at 0x380434E9: ??? (in /usr/local/lib/valgrind/memcheck-x86-freebsd) ==33074==by 0x323C48: qt_safe_select(int, fd_set*, fd_set*, fd_set*, timeval const*) (qcore_unix.cpp:83) ==33074==by 0x2803B1: select_msecs(int, fd_set*, fd_set*, int) (qprocess_unix.cpp:998) ==33074==by 0x28021D: QProcessPrivate::waitForStarted(int) (qprocess_unix.cpp:1031) ==33074==by 0x1FFA02: QProcess::waitForStarted(int) (qprocess.cpp:1687) ==33074==by 0x1FEAEA: QProcess::waitForFinished(int) (qprocess.cpp:1752) ==33074==by 0x805487A: AutoMoc::echoColor(QString const) (kde4automoc.cpp:74) ==33074==by 0x805264F: AutoMoc::generateMoc(QString const, QString const) (kde4automoc.cpp:569) ==33074==by 0x804F13A: AutoMoc::run() (kde4automoc.cpp:470) ==33074==by 0x804AAEE: main (kde4automoc.cpp:114) Full valgrind output is at http://pastebin.com/KQTKYGX5 This sounds like a valgrind bug I reported related to sigreturn: https://bitbucket.org/stass/valgrind-freebsd/issue/4/crash-in-x86_freebsd_subst_for_sigreturn Unfortunately I don't understand the mechanics of signal handling well enough to take this to completion. ___ 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: Failed to initialize dwarf?
I have a checkout of r244047. I did a make kernel-toolchain followed by a make buildkernel and I see this warning. On Tue, Dec 18, 2012 at 7:15 AM, Dimitry Andric d...@freebsd.org wrote: On 2012-12-18 12:30, George Mitchell wrote: I checked out head Sunday and now my attempt at building a kernel says: ERROR: ctfconvert: failed to initialize DWARF: Unimplemented code at [dwarf_init_attr(400)] on every module it compiles (though it seems happy enough to keep compiling). Should I just ignore this?-- George Mitchell This problem was fixed in libdwarf in r239872; did you run make buildworld before make buildkernel? __**_ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/**mailman/listinfo/freebsd-**currenthttp://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscribe@** freebsd.org 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: Failed to initialize dwarf?
On Tue, Dec 18, 2012 at 4:56 PM, Dimitry Andric d...@freebsd.org wrote:
The question is if ctfconvert (and dependencies) are rebuilt when you do
kernel-toolchain. Can you figure out if it runs ctfconvert from base?
Aha! You're right:
[rstone@rstone-laptop vll]make buildenv
Entering world for amd64:amd64
$ which ctfconvert
/usr/bin/ctfconvert
$ which cc
/home/rstone/obj/usr/home/rstone/git/vll/tmp/usr/bin/cc
I think that this (in Makefile.incl1) might be the culprit?
# dtrace tools are required for older bootstrap env and cross-build
.if ${MK_CDDL} != no \
((${BOOTSTRAPPING} 800038 \
!(${BOOTSTRAPPING} = 700112 ${BOOTSTRAPPING} 79)) \
|| (${MACHINE} != ${TARGET} || ${MACHINE_ARCH} != ${TARGET_ARCH}))
_dtrace_tools= cddl/usr.bin/sgsmsg cddl/lib/libctf lib/libelf \
lib/libdwarf cddl/usr.bin/ctfconvert cddl/usr.bin/ctfmerge
.endif
___
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 -a causes kernel trap 12
Have you tried dropping into the debugger by setting debug.debugger_on_panic=1 instead of trying to generate a core? You might have some success generating at least a backtrace. Also it would be worth setting kern.stop_scheduler_on_panic=0 to see if that lets you generate a core. ___ 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 -a causes kernel trap 12
On Mon, Jan 7, 2013 at 7:21 PM, Ryan Stone ryst...@gmail.com wrote: Have you tried dropping into the debugger by setting debug.debugger_on_panic=1 instead of trying to generate a core? You might have some success generating at least a backtrace. Sigh, reading comprehension fail on my part. Try generating a core, I guess. Another think that you could do would be to annotate the sysctl code path to print the name of the sysctl that it is about to run to the console. ___ 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 from php/freebsd/dtrace
On Thu, Dec 29, 2011 at 12:37 PM, Oleg Ginzburg olev...@olevole.ru wrote: Hi maillist, I try to use dtrace + php/dtrace on the freebsd. In certain cases ive get Segmentation fault and don't understand what of subsystem has a problem. Yes, Userland DTrace is unfortunately still very experimental at this point. I've got a list of at least 10 outstanding bugs that I hope to start addressing early in the new year. In your case, dtrace(1) and/or libproc does not clean up after itself properly in the case of an error. I'm not entirely sure what is causing the segfault in php, though. Which version are you running? The output of uname -a would be helpful. ___ 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: Can't umount a formerly mounted drive
On Fri, Feb 3, 2012 at 9:34 AM, Derek Tattersall d...@mebtel.net wrote: I have two drives in a x86-64 machine. Drive ada2 has current on it, and drive ada1 has 9-stable on it. At some point, while running current, I mounted the /home partition from stable to copy some files and re-ipled the system into stable. every thing worked properly. Some time later I ipled current again. I then noticed that the stable /home was mounted on /mnt. I tried to umount it but the operation failed as /dev/ada1p7 was not considered mounted. Yet with out mounting I could access all the files on stable's /home, I could create and delete files. The current system was cvsup'ed on Wednesday this week, while the stable system was cvsup'ed last Sunday. Neither system has exhibited any hiccups. Can somebody explain what has happened her on the current system and how it should be corrected? Does mount list anything as being mounted on /mnt? If not, are you sure that /mnt isn't a symlink to somewhere else? Or maybe the contents of the home directory were copied to /mnt by accident? ___ 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: gstat don't work after update to 10.0-CURRENT
I believe that this was fixed in r234107 http://svn.freebsd.org/changeset/base/234107 ___ 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: incorrect npmc count
On Wed, May 9, 2012 at 1:16 AM, Peter Jeremy pe...@rulingia.com wrote: [This may be a duplicate because I forgot to update my subscription after changing address but I've also corrected a typo] (I've copied fabient@ because r233628 appears to have been the last commit in this area). I've just updated a P4 test box from r232545 to r235127 and it now panics during boot: panic: [intel,202] incorrect npmc count 35 Looking at sys/dev/hwpmc/hmpmc_intel.c line 202, the expected npmc count is 19. When I look at the actual code in pmc_intel_initialize(): pmc_mdep_alloc() initialises pmd_npmc to zero and then increments it by SOFT_NPMCS (16) in pmc_soft_initialize(). pmc_tsc_initialize() then increments it by TSC_NPMCS (1) pmc_p4_initialize() then increments it by P4_NPMCS (18) This totals 35 (as per the panic message). Can someone explain the KASSERT() that expects 19 - it boils down to KASSERT(0+16+1+18 == 1+18, ...) I gather not many people are running -current on a P4. -- Peter Jeremy That KASSERT is just out of date. The soft PMC support is quite new. I would just drop the KASSERT entirely; it really isn't adding any value. ___ 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: Is it Dtrace broken on HEAD?
On Wed, May 30, 2012 at 6:37 AM, Marcelo Araujo araujobsdp...@gmail.com wrote:
Hello fellows,
Is it Dtrace broken on HEAD?
root@controllerB:/sys/amd64/conf # dtrace -n 'syscall::open*:entry {
printf(%s %s,execname,copyinstr(arg0)); }'
*dtrace: invalid probe specifier syscall::open*:entry { printf(%s
%s,execname,copyinstr(arg0)); }: /usr/lib/dtrace/psinfo.d, line 37:
syntax error near uid_t*
root@controllerB:/sys/amd64/conf # uname -a
FreeBSD controllerB.la.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0: Tue May 29
13:54:25 CST 2012 r...@controllerb.la.com:/usr/obj/usr/src/sys/LA amd64
Best Regards,
--
Marcelo Araujo
ara...@freebsd.org
I know that I've seen this before when I've built improperly, but I
can't exactly remember what the root cause was. Do you have CTF data
in your kernel(i.e. does ctfdump /boot/kernel/kernel give output?).
If not then you forgot to build with WITH_CTF=1
___
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: identifier redefined: cpu
On Thu, Jun 7, 2012 at 4:02 AM, Andriy Gapon a...@freebsd.org wrote: I am getting the following error while trying to execute any DTrace script on a freshly updated CURRENT system (both kernel and world). Example: dtrace: failed to compile script sysctl_kern_proc.d: /usr/lib/dtrace/sched.d, line 70: identifier redefined: cpu current: inline definition previous: scalar -- Andriy Gapon Hm, I cannot reproduce this on the following system, freshly built this morning: FreeBSD vm-head 10.0-CURRENT FreeBSD 10.0-CURRENT #3 r236713: Thu Jun 7 10:30:45 EDT 2012 rstone@rstone-laptop:/home/rstone/freebsd/obj/usr/home/rstone/freebsd/head_2/sys/GENERIC amd64 I don't even have a /usr/lib/dtrace/sched.d. Do you have some local changes that is installing that? ___ 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: ctfconvert again
I am working on a fix for this. It shouldn't be too bad, as we already build a cross-ctfconvert in certain cases. I just need to get some machines running older FreeBSD versions to test on to confirm that the fix worked. Should be able to test tomorrow, assuming that I am finally able to coerce old releases of FreeBSD to build on my -CURRENT machine. ___ 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
ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter()
I have been experiencing occasional deadlocks on FreeBSD 8.2 systems using
the ULE scheduler. The root cause in every case has been that ULE's
TDQ_LOCK for cpu 0 is owned by a thread that is not running. I have been
investigating the issue, and I believe that I see the issue. The problem
occurs if the interrupt that drives statclock does not call
critical_enter() upon calling into statclock(). The lapic timer does use
critical_enter(), so default configurations would not see this. I have
local patches to use the RTC to drive statclock, and from a quick reading
of the eventtimer code in -CURRENT the same thing is possible there. The
RTC code does not call statclock within a critical section. So here's the
bug:
1) A thread with interrupts enabled, running on CPU 0, with td_owepreempt=1
and td_critnest=1 calls critical_exit():
void
critical_exit(void)
{
// ...
if (td-td_critnest == 1) {
td-td_critnest = 0;
if (td-td_owepreempt !kdb_active) {
// Irrelevant bits snipped
2) td_critnest is set to 0, and then the RTC interrupt fires.
3) rtcintr calls into statclock (8.2) or statclock_cnt(head) with
td_critnest still 0 (on head it goes through the eventtimer code, but it
ends up in statclock eventually).
4) statclock takes the thread_lock on curthread, then calls sched_clock().
sched_clock calls sched_balance();
static void
sched_balance(void)
{
// snip...
tdq = TDQ_SELF();
TDQ_UNLOCK(tdq);
sched_balance_group(cpu_top);
TDQ_LOCK(tdq);
}
TDQ_UNLOCK does a spinlock_exit which does a critical_exit. td_critnest
will be decremented back to 0 and td_owepreempt is still 1, so this
triggers a preemption. Note that this TDQ_UNLOCK is (intentionally)
unlocking the thread_lock done by statclock.
5) thread migrates to any other CPU, call it CPU n. tdq is now stale.
TDQ_LOCK takes the lock for CPU 0 (but really it's intending to re-take the
thread_lock, although a thread_lock() here would be equally incorrect --
sched_balance's caller is going to be mucking around with the TDQ when
sched_balance returns).
6) The thread returns to statclock. statclock does a thread_unlock(). The
td_lock is TDQ_LOCK(n), which we don't hold. We mangle the stat of
TDQ_LOCK(n) and leave TDQ_LOCK(0) held.
The simplest solution would be to do a critical_enter() in sched_balance,
although that would be superfluous in the normal case where the lapic timer
is driving statclock. I'm not sure if there's other code in the
eventtimers infrastructure that's assuming that a preemption or migration
is impossible while handling an event. A quick look at kern_clocksource.c
turns up worrying comments like Handle all events for specified time on
this CPU and uses of curcpu, so there may well be other issues lurking
here.
It looks to me that the safest thing to do would be to push the
critical_enter() into the eventtimer code or even all the way back to the
interrupt handlers (mirroring what the lapic code already does).
___
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: ULE can leak TDQ_LOCK() if statclock() called outside of critical_enter()
On Sun, Jan 20, 2013 at 5:29 AM, Konstantin Belousov kostik...@gmail.comwrote: Both atrtc and hpet register the interrupt handler as the filter. The filters call loop enters critical section around handlers, see kern_intr.c:intr_event_handle(). At least on HEAD it is so, and I see the same code in the 8. Huh, I missed that. However, on 8.2 ipi_bitmap_handler does not do a critical_enter() (while HEAD does), so if CPU 0 gets an IPI_STATCLOCK, we have my bug. I have DTrace data (from 8.2) showing a thread entering sched_switch() from sched_balance() when called through an IPI_STATCLOCK. I'll poke around some more in HEAD to see if there are any entry points (maybe on other architectures) that don't do a critical section, and then add the assertions that you suggested. ___ 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: installworld fails
On Tue, Jan 22, 2013 at 1:24 AM, Jason Evans jas...@freebsd.org wrote: On Jan 21, 2013, at 10:13 PM, AN a...@neu.net wrote: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #29 r245766: Tue Jan 22 00:49:02 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone seeing this? install -l s usr/src/sys /sys install: /sys/sys: Directory not empty *** [distrib-dirs] Error code 71 Yes. I haven't tracked down the cause, but doing 'rm /sys' prior to installworld is an effective workaround. Jason CC'ing Brooks, who I believe made this change. It looks as though install is using the semantics of ln -s /usr/src/sys /sys instead of ln -fs. ___ 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
Why don't we check for preemption when we unlend priority?
I'm having a problem where userland threads are running with a loaned (via
mutex priority propagation) priority even after they have released the
mutex. This is causing the low-priority userland thread to starve
high-priority interrupt threads. One scenario is(which I am seeing on
FreeBSD 8.2, but the priority lending code does not seem to have changed in
HEAD):
1) I have several swi threads that are pulling packets off of interfaces
and forwarding them. Each swi thread is pinned to a CPU.
2) A remote user initiates an scp of a large file to this machine.
3) sshd (which handles the scp) takes a mutex on its socket
4) An interrupt or taskqueue thread belonging to the driver that is
receiving the scp traffic tries to take the same mutex. It can't and so it
lends its priority to the sshd thread.
5) My swi thread is woken. It is pinned to the same CPU as sshd, but it
has a lower priority than the lent priority, so it is placed on the
runqueue.
6) The sshd thread releases the mutex. sched_unlend_prio is called to set
its priority back to a normal user priority. However, it does not check
whether any higher-priority threads are waiting in the runqueue.
7) The sshd thread is allowed to run for its full quantum (100ms). This is
easily long enough for my swi thread to start and I drop packets.
This is similar to a problem fixed by jhb@ a while ago, which was discussed
here:
http://lists.freebsd.org/pipermail/freebsd-arch/2010-December/010835.html
However in my case it is a thread at an ithread priority that is started,
not a userland realtime thread.
I don't see why sched_unlend_prio can't check for preemption. I know that
in jhb's case we didn't want to check for preemption in userret for
performance reasons. In my case, sched_unlend_prio already holds the
relevant scheduler lock (and hopefully mutex contention is a rare case
anyway), so I don't see that the same performance argument applies.
The following proof-of-concept patch for ULE resolves the starvation for
me. Any comments?
diff --git a/sys/kern/sched_ule.c b/sys/kern/sched_ule.c
index 01559ee..2659614 100644
--- a/sys/kern/sched_ule.c
+++ b/sys/kern/sched_ule.c
@@ -1586,6 +1586,22 @@ sched_pctcpu_update(struct td_sched *ts)
ts-ts_ftick = ts-ts_ltick - SCHED_TICK_TARG;
}
+static void
+sched_check_preempt(struct tdq *tdq, struct thread *td)
+{
+
+ KASSERT(TD_IS_RUNNING(td), (thread is not running));
+ TDQ_LOCK_ASSERT(tdq, MA_OWNED);
+ KASSERT(tdq == TDQ_CPU(td-td_sched-ts_cpu), (tdq does not td));
+
+ if (tdq == TDQ_SELF()) {
+ if (td-td_priority tdq-tdq_lowpri
+ sched_shouldpreempt(tdq-tdq_lowpri, td-td_priority,
0))
+ td-td_owepreempt = 1;
+ } else
+ tdq_notify(tdq, td);
+}
+
/*
* Adjust the priority of a thread. Move it to the appropriate run-queue
* if necessary. This is the back-end for several priority related
@@ -1635,8 +1651,10 @@ sched_thread_priority(struct thread *td, u_char prio)
td-td_priority = prio;
if (prio tdq-tdq_lowpri)
tdq-tdq_lowpri = prio;
- else if (tdq-tdq_lowpri == oldpri)
+ else if (tdq-tdq_lowpri == oldpri) {
tdq_setlowpri(tdq, td);
+ sched_check_preempt(tdq, td);
+ }
return;
}
td-td_priority = prio;
___
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: svn2git exporter is down on git-beta.freebsd.org?
On Sun, Jan 27, 2013 at 11:46 AM, Oliver Pinter oliver.p...@gmail.comwrote: Hi All! The svn2git exporter is down on git-beta.freebsd.org? The last update was 2013.jan.15. The mirror on GitHub is still getting updates: https://github.com/freebsd/freebsd The git beta was supposed to be re-rolled on the 15th. GitHub clearly got the update, but git-beta.freebsd.org didn't. Perhaps uqs@ forgot to do a force push? ___ 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: Kernel panic on FreeBSD 10.0-CURRENT amd64
On Tue, Mar 5, 2013 at 8:03 PM, Adam Kirchhoff adam.k.kirchh...@gmail.comwrote: I have recently installed 9.1 and attempted to upgrade to 10.0-CURRENT yesterday (largely in an effort to test the new radeon DRM code). Unfortunately, upon rebooting, I am left at kernel debugger prompt: cd0 at ata0 bus 0 scbus0 target 1 lun 0 cd0: TSSTcorp CD-ROM TS-H192C DE00 Removable CD-ROM SCSI-0 device cd0: 33.300MB/s transfers (UDMA2, ATAPI 12bytes, PIO 65534bytes) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed panic: g_read_data(): invalid length 0 cpuid = 0 KDB: enter: panic [ thread pid 13 tid 100014 ] Stopped at kdb_enter+0x3e: movq$0,kdb_why db bt Tracing pid 13 tid 100014 td 0xfe0002957490 kdb_enter() at kdb_enter+0x3e/frame 0xff800026a960 vpanic() at vpanic+0x147/frame 0xff800026a9a0 kassert_panic() at kassert_panic+0x136/frame 0xff800026aa10 g_read_data() at g_read_data+0x45/frame 0xff800026aa50 g_label_ntfs_taste() at g_label_ntfs_taste+0xde/frame 0xff800026aa90 g_label_taste() at g_label_taste+0x37b/frame 0xff800026ab60 g_new_provider_event() at g_new_provider_event+0xda/frame 0xff800026ab80 g_run_events() at g_run_events+0x167/frame 0xff800026abb0 fork_exit() at fork_exit+0x84/frame 0xff800026abf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff800026abf0 --- trap 0, rip = 0, rsp = 0xff800026acb0, rbp = 0 --- I'm no expert, but it appears to be related to the NTFS partition I have on a separate hard drive. Any ideas what the problem might be or how to debug this further? Adam ___ 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 This sounds like something that was just fixed today. Do you have r247837? http://svnweb.freebsd.org/changeset/base/247837 ___ 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
[PATCH] Add support for Exar XR17V358IV to puc(4)
I've implemented support for Exar XR17V358IV 8-port UARTs. These are quite
similar to previous Exar UARTs, with the notable exception of the strange
125MHz clock. I've done some basic testing using it as a tty at 9600 baud
and 115200 baud, but nothing really extensive. I can't seem to find any
tools for stressing out serial ports. I'm not sure if anybody has any
suggestions for this.
I plan to commit this within a couple of days if nobody has any
objections. I'll try to get it MFC'ed for 8.4-RELEASE,
The patch can be found here:
http://people.freebsd.org/~rstone/patches/exar_358.diff
I've also included it inline in case anybody wants to review it:
commit d1da80b5c90b3ae5a44db165cb032e9e86d2c804
Author: Ryan Stone rst...@freebsd.org
Date: Mon Mar 11 17:02:13 2013 -0400
add support for Exar XR17V358IV 8-port serial port to puc(4)
diff --git a/sys/dev/puc/pucdata.c b/sys/dev/puc/pucdata.c
index 6d933e8..34d6986 100644
--- a/sys/dev/puc/pucdata.c
+++ b/sys/dev/puc/pucdata.c
@@ -50,6 +50,7 @@ __FBSDID($FreeBSD$);
static puc_config_f puc_config_amc;
static puc_config_f puc_config_diva;
static puc_config_f puc_config_exar;
+static puc_config_f puc_config_exar_pcie;
static puc_config_f puc_config_icbook;
static puc_config_f puc_config_moxa;
static puc_config_f puc_config_oxford_pcie;
@@ -630,6 +631,13 @@ const struct puc_cfg puc_pci_devices[] = {
PUC_PORT_8S, 0x10, 0, -1,
},
+ { 0x13a8, 0x0358, 0x, 0,
+ Exar XR17V358IV,
+ 12500,
+ PUC_PORT_8S, 0x10, 0, -1,
+ .config_function = puc_config_exar_pcie
+ },
+
{ 0x13fe, 0x1600, 0x1602, 0x0002,
Advantech PCI-1602,
DEFAULT_RCLK * 8,
@@ -1186,6 +1194,17 @@ puc_config_exar(struct puc_softc *sc, enum
puc_cfg_cmd cmd, int port,
}
static int
+puc_config_exar_pcie(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
+intptr_t *res)
+{
+ if (cmd == PUC_CFG_GET_OFS) {
+ *res = port * 0x400;
+ return (0);
+ }
+ return (ENXIO);
+}
+
+static int
puc_config_icbook(struct puc_softc *sc, enum puc_cfg_cmd cmd, int port,
intptr_t *res)
{
___
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 gone quiet?
On Tue, Apr 16, 2013 at 3:57 PM, Navdeep Parhar n...@freebsd.org wrote: I just upgraded my kernel and userspace to head (r249552) and I notice that DTrace doesn't output anything until I hit ctrl-c. All previous hits on the probe appear lost. For example: # dtrace -n 'fbt::ether_output:entry' dtrace: description 'fbt::ether_output:entry' matched 1 probe (No output here. I waited a long time before the ctrl-c and I know the system is actively transmitting and receiving Ethernet traffic). ^C CPU IDFUNCTION:NAME 9 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry 8 29354 ether_output:entry Can anyone confirm or contradict this on a recent HEAD (around r249552 in my case)? Regards, Navdeep ___ 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 Hm, if you run with -x bufpolicy=switch does it work? It sounds as through the ring buffer policy is being set by default for you. I'm not sure how that could happen. ___ 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 of HEAD failing under 8.1-RELEASE
I am getting the following error when trying to build HEAD on an 8.1-RELEASE build machine (i386 jail on an amd64 host): === lib/clang/libllvmanalysis (all) /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp: In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*, llvm::ArrayRefllvm::Constant*, const llvm::TargetLibraryInfo*)': /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310: error: 'log2' was not declared in this scope *** [ConstantFolding.o] Error code 1 1 error *** [all] Error code 2 1 error *** [cross-tools] Error code 2 1 error *** [_cross-tools] Error code 2 1 error *** Error code 2 1 error Is there anything that I can do other than build on another machine? I don't control the build machines at $WORK so I'm not sure whether I can get them upgraded. :( ___ 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 of HEAD failing under 8.1-RELEASE
On Thu, May 2, 2013 at 7:02 PM, Dimitry Andric d...@freebsd.org wrote: On May 2, 2013, at 20:28, Ryan Stone ryst...@gmail.com wrote: I am getting the following error when trying to build HEAD on an 8.1-RELEASE build machine (i386 jail on an amd64 host): === lib/clang/libllvmanalysis (all) /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp: In function 'llvm::Constant* llvm::ConstantFoldCall(llvm::Function*, llvm::ArrayRefllvm::Constant*, const llvm::TargetLibraryInfo*)': /usr/d2/users/rstone/git/svos/lib/clang/libllvmanalysis/../../../contrib/llvm/lib/Analysis/ConstantFolding.cpp:1310: error: 'log2' was not declared in this scope ... Is there anything that I can do other than build on another machine? I don't control the build machines at $WORK so I'm not sure whether I can get them upgraded. :( In 8.1-RELEASE, there was no log2() MFC yet. Can you please try the attached diff? This fixed it. Thank you. ___ 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
Incorrect comparison of ticks in deadlkres
Currently deadlkres performs the following comparison when trying to check
for threads that have been blocked on a mutex or sleeping on an sx lock:
if (TD_ON_LOCK(td) ticks td-td_blktick) {
/* check for deadlock...*/
The test against ticks is incorrect. It results in deadlkres only
signaling a deadlock after ticks has rolled over; at 1000 hz this will take
up to 49 days. From looking at the history of the code this test appears
to be a attempt to deal with ticks rollover. However this is necessary;
later on the code calculates the amount of time that has passed with:
tticks = ticks - td-td_blktick;
ticks was designed to exploit integer underflow in the case of rollover to
guarantee that subtraction produces correct results in all cases (other
than a double rollover, of course). I am going to remove the two incorrect
tests unless somebody can point out a overflow/underflow case that I
haven't considered.
___
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: Incorrect comparison of ticks in deadlkres
On Tue, May 28, 2013 at 5:29 PM, Ian Lepore i...@freebsd.org wrote: ticks is defined as a signed integer but conceptually it is unsigned -- it increments from 0 to UINT_MAX (not INT_MAX) then rolls over. If td-td_blktick is captured while ticks = UINT_MAX and later ticks has rolled over and counted back up to 15, then ticks - td-td_blktick gives an elapsed time of 16, as it should be. Whether exploiting this property of signed overflow is elegant or ugly is in the eye of the beholder. :) If the intent of the ticks td-td_blktick is to avoid the deadlock check until after enough time has passed, then I guess it should probably be something more like (ticks - td-blktick) SOME_THRESHOLD so that it also uses the signed overflow trick. -- Ian It already does this later on to actually detect the deadlock. The test is reversed but was intended to bail and not calculate the time elapsed at all if ticks had overflowed after td_blktick was captured, but as you say this is unnecessary. ___ 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: Handle kernel module crashes
On Mon, Jun 10, 2013 at 10:18 AM, Florent Peterschmitt flor...@peterschmitt.fr wrote: Hello, It's not a problem but a question, and it's quite simple: How does FreeBSD handle crash from a single kernel module ? If the module internally crashes, does the entire system does too or FreeBSD will continue to live ? Thanks There is no separation between kernel modules and the kernel proper. A crash in a kernel module will crash the entire system. ___ 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: USB Keyboard not worked on current (r251681)
I am able to reproduce this on a Supermicro X8-something that I have. A git bisect took me down a strange path into a /projects branch. It is possible the branch got a bad merge from -CURRENT at one point; I'm still trying to narrow down where things went wrong (and even whether the branch is actually responsible or whether git got confused by the svn-git export process). ___ 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 failed on HEAD
On Fri, Jul 19, 2013 at 1:35 PM, Sam Fourman Jr. sfour...@gmail.com wrote: /usr/src/usr.bin/calendar/parsedata.c:989:17: error: null character ignored [-Werror,-Wnull-character] i = strtol (s, Try looking at this file in vi. It sounds like a '\0' has somehow been inserted into this file and corrupted it. How did you get your source 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: Boot fails @r264070
Can somebody please confirm whether setting hw.pci.enable_ari=0 in the loader fixes the issue or not. That will help me to figure out if the issue is with ARI or if I have somehow broken PCI enumeration in general (I suspect the later). ___ 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: svn commits r264007-264011: disks missing
This is fixed in r264091. Apologies for the breakage; it seems to mostly effect legacy PCI devices and my testing was on PCIe-only systems. Thanks to everyone who reported the issue and provided verbose dmesgs; that really helped me to understand the problem. ___ 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: cannot build 9.2 from an 11-current host
On Thu, Apr 3, 2014 at 9:09 PM, Benjamin Kaduk ka...@mit.edu wrote: Hi all, I've got a build machine that does package builds of net/openafs for upstream OpenAFS, and is supposed to build packages for all supported FreeBSD versions (and a few unsupported ones, too). I've recently updated to r264039M (the 'M' is reverting PCI ARI bits as discussed in a different thread), and now when I go back to build a 9.2 chroot, I find that I cannot build world: Unfortunately the bug is in 9.2-RELEASE, not 11-CURRENT. This patch fixes it, but it came in after 9.2-RELEASE: http://svnweb.freebsd.org/changeset/base/257812 ___ 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
boot2 too large when built with BTX_SERIAL=yes
I've been seeing the following build failure on HEAD when I set BTX_SERIAL=yes in make.conf btxld -v -E 0x2000 -f bin -b /usr/obj/repos/users/rstone/freebsd/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size=6c0 load=9000 entry=9010 map=16M pgctl=1:1 client: fmt=bin size=1551 text=0 data=0 bss=0 entry=0 output: fmt=bin size=1e11 text=200 data=1c11 org=0 entry=0 --- boot2 --- --- rescue.all__D --- --- init_make --- (cd /repos/users/rstone/freebsd/rescue/rescue/../../sbin/init make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/init/ depend make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/init/ init.o) --- sys.all__D --- -17 bytes available ___ 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: diskid documentation
On Mon, Jun 2, 2014 at 9:26 AM, Allan Jude allanj...@freebsd.org wrote: It also tends to sometimes hide the gpt label provider on me (not sure in which cases it does this, but it is annoying) This happens when something (e.g. zfs) happens to open the diskid provider instead of the gpt label. For me this ended up being a bit more than annoying; my swap was mounted in /etc/fstab via a gpt label so I silently lost my swap when I did an upgrade. ___ 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 deadlkres() on r267110
On Fri, Jun 6, 2014 at 10:12 AM, Glen Barber g...@freebsd.org wrote: Two machines in the cluster panic last night with the same backtrace. It is unclear yet exactly what was happening on the systems, but both are port building machines using ports-mgmt/tinderbox. Any ideas or information on how to further debug this would be appreciated. The first thing that I would do is try to figure out who holds the allproc_lock. If the lock is held exclusively then the pointer to the thread struct will be in allproc_lock.sx_lock. If the lock is held shared then it gets trickier. I'm not sure if there is a better possible way than doing a thread apply all bt in kgdb and finding which stack(s) could hold allproc_lock. ___ 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 deadlkres() on r267110
On Fri, Jun 6, 2014 at 11:33 AM, Glen Barber g...@freebsd.org wrote: #4 0x8092fa39 in fork1 (td=0xf813ae7f4920, flags=20, pages=Cannot access memory at address 0x4 ) at /usr/src/sys/kern/kern_fork.c:268 This looks like a suspicious piece of code. Could something be causing the kernel to go into an infinite loop there? ___ 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: In tree builds broken in lib/ncurses?
On Sat, Jun 14, 2014 at 9:30 PM, Steve Kargl s...@troutmask.apl.washington.edu wrote: Thanks for the pointer. The problem appears to be /usr/local/bin/ld. If I move it to ld.old and then symlink /usr/local/bin/ld to /usr/bin/ld, I can build math/lapack without a problem. I guess I'll poke around in devel/bintuils. I would see what changes have been made to the linker scripts that ld is using for FreeBSD. Several years ago I ran into a problem when building kld modules with an out-of-tree toolchain and the root cause ended up being that the linker scripts were broken and no longer provided a necessary symbol. ___ 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: tmpfs panic
On Sun, Jul 6, 2014 at 11:46 AM, Steve Wills swi...@freebsd.org wrote:
I should have noted this system is running in bhyve. Also I'm told this panic
may be related to the fact that the system is running in bhyve.
Looking at it a little more closely:
(kgdb) list *__mtx_lock_sleep+0xb1
0x809638d1 is in __mtx_lock_sleep
(/usr/src/sys/kern/kern_mutex.c:431).
426 * owner stops running or the state of the lock
changes.
427 */
428 v = m-mtx_lock;
429 if (v != MTX_UNOWNED) {
430 owner = (struct thread *)(v ~MTX_FLAGMASK);
431 if (TD_IS_RUNNING(owner)) {
432 if (LOCK_LOG_TEST(m-lock_object, 0))
433 CTR3(KTR_LOCK,
434 %s: spinning on %p held
by %p,
435 __func__, m, owner);
(kgdb)
I'm told that MTX_CONTESTED was set on the unlocked mtx and that MTX_CONTENDED
is spuriously left behind, and to ask how lock prefix is handled in bhyve. Any
of that make sense to anyone?
The mutex has both MTX_CONTESTED and MTX_UNOWNED set on it? That is a
special sentinel value that is set on a mutex when it is destroyed
(see MTX_DESTROYED in sys/mutex.h). If that is the case it looks like
you've stumbled upon some kind of use-after-free in tmpfs. I doubt
that bhyve is responsible (other than perhaps changing the timing
around making the panic more likely to happen).
___
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: DEADLKRES crash
On Mon, Aug 18, 2014 at 11:21 AM, Larry Rosenman l...@lerctr.org wrote: I got the following: borg.lerctr.org dumped core - see /var/crash/vmcore.8 Mon Aug 18 07:30:42 CDT 2014 FreeBSD borg.lerctr.org 11.0-CURRENT FreeBSD 11.0-CURRENT #63 r269784M: Sun Aug 10 12:33:07 CDT 2014 r...@borg.lerctr.org:/usr/obj/usr/src/sys/VT-LER amd64 panic: deadlkres: possible deadlock detected for 0xf8002abeb000, blocked for 1800926 ticks GNU gdb 6.1.1 [FreeBSD] Copyright 2004 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as amd64-marcel-freebsd... Unread portion of the kernel message buffer: panic: deadlkres: possible deadlock detected for 0xf8002abeb000, blocked for 1800926 ticks cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe100bff1a10 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe100bff1ac0 vpanic() at vpanic+0x126/frame 0xfe100bff1b00 panic() at panic+0x43/frame 0xfe100bff1b60 deadlkres() at deadlkres+0x35c/frame 0xfe100bff1bb0 fork_exit() at fork_exit+0x84/frame 0xfe100bff1bf0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe100bff1bf0 --- trap 0, rip = 0, rsp = 0xfe100bff1cb0, rbp = 0 --- Uptime: 7d14h14m38s The first thing that I'd like to see is (in kgdb): set $td=(struct thread)0xf8002abeb000 tid $td-td_tid bt That will show us the backtrace of the thread that was blocked for so 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: Profiling code execution on amd64?
I would suggest using hwpmc for profiling: # kldload hwpmc # pmcstat -S unhalted-cycles -O /tmp/samples.out ../penetration # pmcstat -R /tmp/samples.out -G /tmp/penetration.txt You can also get pmcstat to generate gprof-compatible output with -g, but I never use the mode so I'm really not sure what it gives you. I think that you have to run gprof on the output or something, but don't hold me to that. ___ 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: Ethernet Drivers: Question on Sending Received Packets to the FreeBSD Network Stack
On Thu, Feb 3, 2011 at 2:48 PM, Julian Elischer jul...@freebsd.org wrote: I had never considered passing a set of packets, but after my initial scoffing thoughts I realized that it would actually be a very interesting thought experiment to see if the ability to do that would be advantageous in any way. I tmay be a way to reduce some sorts of overhead if using interrupt mitigation. At $WORK we've put a rather considerable amount of effort into writing what I'd call a poor-man's version of netgraph. Originally, in fact, our application was entirely netgraph-based back when we were running on FreeBSD 4. What we ended up implementing was the minimal set of netgraph features our application needed, optimized for performance. Passing packets around in batches was one of the performance optimizations. There are some pretty big wins with that approach: amortization of locking costs and other overhead, better cache locality and it's easier to prefetch the data from packet n while processing packet n-1. If I get some time I'll see if I can get something by the way of hard numbers as to the advantages on our application. ___ 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: Process timing issue
To debug weird scheduling issues I find it helpful to start by looking at a schedgraph. schedgraph is a tool that can display a graphical representation of what the scheduler was doing over a small slice of time. The one downside is that you have to recompile your kernel to get the hooks that collect the necessary data, but it sounds like your problem is pretty easy to reproduce and so that shouldn't be a big problem. To enable the hooks, put the following in your kernel conf: options KTR options KTR_COMPILE=KTR_SCHED options KTR_MASK=KTR_SCHED options KTR_ENTIRES=(128*1024) Then rebuild and install the new kernel. Next, run your test. The instant that your test has detected the long delay, set the sysctl debug.ktr.mask to 0. The scheduler hooks record data into a ring buffer, so the interesting data can be flushed out within seconds. Clearing that sysctl will stop any further events from being logged, which means that the interesting data will stay there until you go and collect it. You can get the raw data by redirecting the output of ktrdump -ct into a file. Then from any machine with a graphical interface(FreeBSD with X installed, Windows, Mac, whatever) and python installed, run: $ python schedgraph.py /path/to/ktrdump/output You can get schedgraph.py from /usr/src/tools/sched. If you want to collect the data again, set the sysctl debug.ktr.mask back to 0x2000 to restart gathering scheduler data. Ryan ___ 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 softdep_request_cleanup difference w/ and w/o SOFTUPDATES
On Mon, Mar 28, 2011 at 6:19 AM, Aleksandr Rybalko r...@dlink.ua wrote:
Hi,
I found a difference of definition softdep_request_cleanup.
when SOFTUPDATES undefined softdep_request_cleanup take only two arguments.
Patch to fix this:
Index: sys/ufs/ffs/ffs_softdep.c
===
--- sys/ufs/ffs/ffs_softdep.c (revision 220095)
+++ sys/ufs/ffs/ffs_softdep.c (working copy)
@@ -514,9 +514,10 @@
}
int
-softdep_request_cleanup(fs, vp)
+softdep_request_cleanup(fs, vp, resource)
struct fs *fs;
struct vnode *vp;
+ int resource;
{
return (0);
If we need to change the definition, shouldn't we convert it to a C89
declaration at the same time?
___
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
sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
I'm running into a bootup crash under sched_4bsd on HEAD. The crash happens when I have a thread bound to a single CPU that isn't the BSP, and that thread is scheduled. If the AP that the thread is bound hasn't been started up, kick_other_cpu() crashes because pcpu-pc_curthread is NULL for the AP. I've put a small test kld in http://people.freebsd.org/~rstone/4bsd_bind/ that reproduces the problem. I'm not sure what the best way to address the crash is. ULE is not affected by the problem; it seems to run the swi thread on CPU 0 until CPU 1 is running. Here's a sample backtrace: Fatal trap 12: page fault while in kernel mode^M^M cpuid = 0; apic id = 00^M^M fault virtual address = 0x2fa^M^M fault code = supervisor read data, page not present^M^M instruction pointer = 0x20:0x803b473b^M^M stack pointer = 0x28:0x80a2c740^M^M frame pointer = 0x28:0x80a2c790^M^M code segment= base 0x0, limit 0xf, type 0x1b^M^M = DPL 0, pres 1, long 1, def32 0, gran 1^M^M processor eflags= resume, IOPL = 0^M^M current process = 0 (swapper)^M^M trap number = 12^M^M panic: page fault^M^M cpuid = 0^M^M KDB: stack backtrace:^M^M db_trace_self_wrapper() at 0x801cac8a = db_trace_self_wrapper+0x2a^M^M panic() at 0x8038ef92 = panic+0x182^M^M trap_fatal() at 0x8057d32d = trap_fatal+0x2ad^M^M trap() at 0x8057e01f = trap+0x29f^M^M calltrap() at 0x80561397 = calltrap+0x8^M^M --- trap 0xc, rip = 0x803b473b, rsp = 0x80a2c740, rbp = 0xfff f80a2c790 ---^M^M sched_add() at 0x803b473b = sched_add+0xeb^M^M intr_event_schedule_thread() at 0x803633e0 = intr_event_schedule_thread+0 xa0^M^M hardclock_device_poll() at 0x8037f9a5 = hardclock_device_poll+0x35^M^M hardclock() at 0x80342dd3 = hardclock+0x43^M^M lapic_handle_timer() at 0x80568033 = lapic_handle_timer+0xf3^M^M Xtimerint() at 0x80561ecc = Xtimerint+0x8c^M^M ___ 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: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
On Wed, Apr 6, 2011 at 8:36 AM, John Baldwin j...@freebsd.org wrote:
Hummm. Patching 4BSD to use the same route as ULE may be the best solution
for now if that is easiest. Alternatively, you could change 4BSD's
sched_add() to not try to kick other CPUs until smp_started is true.
At first I thought that it was a consequence of the way it does CPU
affinity, but now I see that it shortcuts if smp_started is not true.
How about something like the following for 4BSD?
--- sched_4bsd.c(revision 220222)
+++ sched_4bsd.c(working copy)
@@ -1242,14 +1242,14 @@
}
TD_SET_RUNQ(td);
- if (td-td_pinned != 0) {
+ if (smp_started td-td_pinned != 0) {
cpu = td-td_lastcpu;
ts-ts_runq = runq_pcpu[cpu];
single_cpu = 1;
CTR3(KTR_RUNQ,
sched_add: Put td_sched:%p(td:%p) on cpu%d runq, ts, td,
cpu);
- } else if (td-td_flags TDF_BOUND) {
+ } else if (smp_started (td-td_flags TDF_BOUND)) {
/* Find CPU from bound runq. */
KASSERT(SKE_RUNQ_PCPU(ts),
(sched_add: bound td_sched not on cpu runq));
@@ -1258,7 +1258,7 @@
CTR3(KTR_RUNQ,
sched_add: Put td_sched:%p(td:%p) on cpu%d runq, ts, td,
cpu);
- } else if (ts-ts_flags TSF_AFFINITY) {
+ } else if (smp_started (ts-ts_flags TSF_AFFINITY)) {
/* Find a valid CPU for our cpuset */
cpu = sched_pickcpu(td);
ts-ts_runq = runq_pcpu[cpu];
The flow control is a bit awkward because of the multiple
affinity/bound cpu cases. If somebody prefers the code to be
structured differently I'd be open to suggestions.
Ryan
___
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
[PATCH] Add syslogd option that suppresses hostname logging
I've written a short patch for syslogd that adds a -H option. Setting
that option will prevent syslogd from logging the hostname with every
log messages. If there are no objections I'm going to commit this in
the next couple of days.
Index: syslogd.c
===
--- syslogd.c (revision 220452)
+++ syslogd.c (working copy)
@@ -301,6 +301,7 @@
/* 0=no, 1=numeric, 2=names */
static int KeepKernFac;/* Keep remotely logged kernel facility */
static int needdofsync = 0; /* Are any file(s) waiting to be fsynced? */
+static int LogHost = 1;
static struct pidfh *pfh;
volatile sig_atomic_t MarkSet, WantDie;
@@ -358,7 +359,7 @@
dprintf(madvise() failed: %s\n, strerror(errno));
bindhostname = NULL;
- while ((ch = getopt(argc, argv, 468Aa:b:cCdf:kl:m:nop:P:sS:Tuv))
+ while ((ch = getopt(argc, argv, 468Aa:b:cCdf:Hkl:m:nop:P:sS:Tuv))
!= -1)
switch (ch) {
case '4':
@@ -394,6 +395,9 @@
case 'f': /* configuration file */
ConfFile = optarg;
break;
+ case 'H': /* don't log the origin hostname */
+ LogHost = 0;
+ break;
case 'k': /* keep remote kern fac */
KeepKernFac = 1;
break;
@@ -1150,12 +1154,20 @@
}
v++;
- v-iov_base = f-f_prevhost;
- v-iov_len = strlen(v-iov_base);
+ if (LogHost) {
+ v-iov_base = f-f_prevhost;
+ v-iov_len = strlen(v-iov_base);
+ v++;
+ v-iov_base = space;
+ v-iov_len = 1;
+ } else {
+ v-iov_base = nul;
+ v-iov_len = 0;
+ v++;
+ v-iov_base = nul;
+ v-iov_len = 0;
+ }
v++;
- v-iov_base = space;
- v-iov_len = 1;
- v++;
if (msg) {
wmsg = strdup(msg); /* XXX iov_base needs a `const' sibling. */
___
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
[PATCH] Call _thr_check_init() from _pthread_once
In r179417 the implementation of pthread_once in libthr was changed
from using a global pthread_mutex_t for synchronization to rolling its
own synchronization mechanism. Unfortunately, this introduced a bug.
Calling _pthread_mutex_lock implicitly ensured that _thr_check_init()
had been called. In the current version, there is no such guarantee.
This means that if your first call into libthr is pthread_once, your
executable will segfault when it tries to access curthread. This
patch resolves the issue for me:
Index: lib/libthr/thread/thr_once.c
===
--- lib/libthr/thread/thr_once.c(revision 220603)
+++ lib/libthr/thread/thr_once.c(working copy)
@@ -64,6 +64,8 @@
struct pthread *curthread;
int state;
+ _thr_check_init();
+
for (;;) {
state = once_control-state;
if (state == ONCE_DONE)
If there are no objections I'll commit this soon.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Call _thr_check_init() from _pthread_once
On Tue, Apr 19, 2011 at 10:13 PM, David Xu davi...@freebsd.org wrote: Have you tested that current code causes segfault ? anyway, I can not reproduce it on my machne. Regards, David Xu Yes, I had an application where libstdc++ was calling pthread_once while constructing a static object. As near as I can tell it's pure luck as to whether you'll hit this crash or not. If the linker happens to place a static initializer that calls pthread_once first in the list of static initializers, you crash. If instead something far more likely like pthread_mutex_lock is called first, you're fine. The backtrace for my executable was something like: #0 0x684dadd4 in _pthread_once (once_control=0x6887fdcc, init_routine=0x6883d740 __gthread_trigger()) at /usr/src/lib/libthr/thread/thr_once.c:84 #1 0x6883d992 in __gthread_active_p () at /tmp/buildutils.x86/x86-i686-pc-freebsd8/i686-pc-freebsd8/libstdc++-v3/include/i686-pc-freebsd8/bits/gthr-default.h:221 #2 __eh_globals_init () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:98 #3 __static_initialization_and_destruction_0 () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:110 #4 global constructors keyed to eh_globals.cc(void) () at gcc/libstdc++-v3/libsupc++/eh_globals.cc:146 #5 0x68848d06 in __do_global_ctors_aux () from /usr/local/mumble/lib/libstdc++.so.6 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [PATCH] Call _thr_check_init() from _pthread_once
On Tue, Apr 19, 2011 at 10:58 PM, David Xu davi...@freebsd.org wrote: But I don't touch curthread unless it is blocked by another thread. You do a THR_CLEANUP_PUSH(curthread, once_cancel_handler, once_control); before calling *init_routine. THR_CLEANUP_PUSH touches curthread-cleanup; ___ 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: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
On Wed, Apr 6, 2011 at 2:29 PM, John Baldwin j...@freebsd.org wrote:
I guess one other option would be something like this:
if (smp_started (td-td_pinned != 0 || td-td_flags
TDF_BOUND ||
ts-ts_flags TSF_AFFINITY)) {
if (td-td_pinned != 0)
cpu = td-td_lastcpu;
else if (td-td_flags TDF_BOUND) {
/* Find CPU from bound runq. */
KASSERT(...);
cpu = ts-ts_runq - runq_pcpu[0];
} else
/* Find a valid CPU for our cpuset. */
cpu = sched_pickcpu(td);
ts-ts_runq = runq_pcpu[cpu];
single_cpu = 1;
CTR3(KTR_RUNQ, ...);
} else {
/* Global runq case. */
}
This also avoids duplicating some common code to all the single_cpu cases.
--
John Baldwin
I went with this option. Does this look right?
Index: sys/kern/sched_4bsd.c
===
--- sys/kern/sched_4bsd.c (revision 220603)
+++ sys/kern/sched_4bsd.c (working copy)
@@ -1246,30 +1246,28 @@
}
TD_SET_RUNQ(td);
- if (td-td_pinned != 0) {
- cpu = td-td_lastcpu;
+ /*
+* If SMP is not started, don't obey any requested CPU pinning as that
+* CPU has either not yet started or it is curcpu. Trying to run a
+* thread on a CPU that has not yet started will panic the system.
+*/
+ if (smp_started (td-td_pinned != 0 || td-td_flags TDF_BOUND ||
+ ts-ts_flags TSF_AFFINITY)) {
+ if (td-td_pinned != 0)
+ cpu = td-td_lastcpu;
+ else if (td-td_flags TDF_BOUND) {
+ /* Find CPU from bound runq. */
+ KASSERT(SKE_RUNQ_PCPU(ts),
+ (sched_add: bound td_sched not on cpu runq));
+ cpu = ts-ts_runq - runq_pcpu[0];
+ } else
+ /* Find a valid CPU for our cpuset */
+ cpu = sched_pickcpu(td);
ts-ts_runq = runq_pcpu[cpu];
single_cpu = 1;
CTR3(KTR_RUNQ,
sched_add: Put td_sched:%p(td:%p) on cpu%d runq, ts, td,
cpu);
- } else if (td-td_flags TDF_BOUND) {
- /* Find CPU from bound runq. */
- KASSERT(SKE_RUNQ_PCPU(ts),
- (sched_add: bound td_sched not on cpu runq));
- cpu = ts-ts_runq - runq_pcpu[0];
- single_cpu = 1;
- CTR3(KTR_RUNQ,
- sched_add: Put td_sched:%p(td:%p) on cpu%d runq, ts, td,
- cpu);
- } else if (ts-ts_flags TSF_AFFINITY) {
- /* Find a valid CPU for our cpuset */
- cpu = sched_pickcpu(td);
- ts-ts_runq = runq_pcpu[cpu];
- single_cpu = 1;
- CTR3(KTR_RUNQ,
- sched_add: Put td_sched:%p(td:%p) on cpu%d runq, ts, td,
- cpu);
} else {
CTR2(KTR_RUNQ,
sched_add: adding td_sched:%p (td:%p) to gbl runq, ts,
___
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: sched_4bsd startup crash trying to run a bound thread on an AP that hasn't started
On Mon, Apr 25, 2011 at 2:58 PM, John Baldwin j...@freebsd.org wrote: Yes, I would perhaps tweak the comment to reflect the full if statement though. Maybe something like: /* * If SMP is started and the thread is pinned or otherwise limited to * a specific set of CPUs, queue the thread to a per-CPU run queue. * Otherwise, queue the thread to the global run queue. */ That looks fine, but I'm going to add a sentence explaining why the smp_started condition is necessary: /* * If SMP is started and the thread is pinned or otherwise limited to * a specific set of CPUs, queue the thread to a per-CPU run queue. * Otherwise, queue the thread to the global run queue. * * If SMP has not yet been started we must use the global run queue * as per-CPU state may not be initialized yet and we may crash if we * try to access the per-CPU run queues. */ ___ 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: time doesn't work?
[garrc...@garrcoop-fbsd ~]$ time vim nose-plist-fix.diff # monkeyed around for a few seconds... real 0m5.753s user 0m0.047s sys 0m0.019s [garrc...@garrcoop-fbsd ~/ipcvs/freebsd/src]$ time -p vim # pattered around for a few more seconds... real 12.04 user 0.07 sys 0.03 I'm not sure that this means much. user and system time measure how much *cpu* time was used. In an interactive application like vi I think that it's expected behaviour to see so little cpu time spent. ___ 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: dev.bce.X.com_no_buffers increasing and packet loss
What's the traffic look like? Jumbo, standard, short frames? Any good ideas on profiling the code? I haven't figured out how to use the CPU TSC but there is a free running timer on the device that might be usable to calculate where the driver's time is spent. Dave In my experience hwpmc is the best and easiest way to profile anything on FreeBSD. Here's something I sent to a different thread a couple of months ago explaining how to use it: 1) If device hwpmc is not compiled into your kernel, kldload hwpmc(you will need the HWPMC_HOOKS option in either case) 2) Run pmcstat to begin taking samples(make sure that whatever you are profiling is busy doing work first!): pmcstat -S unhalted-cycles -O /tmp/samples.out The -S option specifies what event you want to use to trigger sampling. The unhalted-cycles is the best event to use if your hardware supports it; pmc will take a sample every 64K non-idle CPU cycles, which is basically equivalent to sampling based on time. If the unhalted-cycles event is not supported by your hardware then the instructions event will probably be the next best choice(although it's nowhere near as good, as it will not be able to tell you, for example, if a particular function is very expensive because it takes a lot of cache misses compared to the rest of your program). One caveat with the unhalted-cycles event is that time spent spinning on a spinlock or adaptively spinning on a MTX_DEF mutex will not be counted by this event, because most of the spinning time is spent executing an hlt instruction that idles the CPU for a short period of time. Modern Intel and AMD CPUs offer a dizzying array of events. They're mostly only useful if you suspect that a particular kind of event is hurting your performance and you would like to know what is causing those events. For example, if you suspect that data cache misses are causing you problems you can take samples on cache misses. Unfortunately on some of the newer CPUs(namely the Core2 family, because that's what I'm doing most of my profiling on nowadays) I find it difficult to figure out just what event to use to profile based on cache misses. man pmc will give you an overview of pmc, and there are manpages for every CPU family supported(eg man pmc.core2) 3) After you've run pmcstat for long enough(a proper definition of long enough requires a statistician, which I most certainly am not, but I find that for a busy system 10 seconds is enough), Control-C it to stop it*. You can use pmcstat to post-process the samples into human-readable text: pmcstat -R /tmp/samples.out -G /tmp/graph.txt The graph.txt file will show leaf functions on the left and their callers beneath them, indented to reflect the callchain. It's not too easy to describe and I don't have sample output available right now. Another interesting tool for post-processing the samples is pmcannotate. I've never actually used the tool before but it will annotate the program's source to show which lines are the most expensive. This of course needs unstripped modules to work. I think that it will also work if the GNU debug link is in the stripped module pointing to the location of the file with symbols. * Here's a tip I picked up from Joseph Koshy's blog: to collect samples for a fixed period of time(say 1 minute), have pmcstat run the sleep command: pmcstat -S unhalted-cycles -O /tmp/samples.out sleep 60 ___ 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: dev.bce.X.com_no_buffers increasing and packet loss
trash_ctor and trash_dtor? You're running with INVARIANTS. ___ 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: newfs_msdos and DVD-RAM
BTW, why can't gdb find any variables? They are just stack variables whose address is easy to find. ... #14 0x8042f24e in bread (vp=Variable vp is not available. ) at /usr/src/sys/kern/vfs_bio.c:748 ... and isn't vp a variable? Maybe the bad default -O2 is destroying debugging. Kernels intended for being debugged (and that is almost all kernels) shouldn't be compiled with many optimizations. Post-gcc-3, -O2 breaks even backtraces by inlining static functions that are called only once. On amd64 those parameters aren't stack variables. They're passed in registers, and gdb is horrible at figuring things out from there. I'm not sure if the problem actually exists in gdb or if the debug info provided by gcc is incomplete. Sometimes gdb is unable to print the value of the parameter because the register has been reused and the argument's value has been lost. ___ 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: pmap_extract question
Assuming that you're using the right pmap(it looks like you are, but it depends on the thread context in which you're running), that will only work if the userland application has touched the page and faulted it in. If it's never tried to access the page it will never be mapped into the process's page tables. ___ 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 can't bring up APs on Intel LC5528(Jasper Forest)
I'm trying to bring up a new board based on Intel's Jasper Forest x86 processor. I can boot a kernel without SMP without any problems, but FreeBSD is not able to start up the Application Processors if I enable SMP. The error message that I get is: AP #2 (PHY# 2) failed! panic y/n? [y] This was a i386 kernel built from HEAD as May 2nd or so. It's not always PHY#2. Some number of APs manage to start up correctly, but one usually fails. I have observed one instance where all of the APs came up properly, so it seems as though there's some kind of race that I stand a very good chance of losing at least one time in seven tries. If I disable all but one AP through device.hints I stand a pretty good chance of successfully starting that AP and booting correctly. I've been banging my head against the wall for a while now and all indications are that the AP never starts at all. I enabled the CHECK_POINTS compile-time option and and nothing ever gets written to the CMOS for the AP that fails to start. Writing to the CMOS is the second thing that the AP does after doing a cli so it's a good bet that the AP never hits that code. Linux (version 2.6.28-11) is able to boot and start the APs just fine. My suspicion is that Linux is explicitly configuring something that FreeBSD is trusting the BIOS to do. We do have the reference board around, but we're having trouble getting the original Intel BIOS programmed into it. If we can get that working again I'll let you know whether FreeBSD can boot on it. If anybody can offer any hints or ideas for debugging this it'd be greatly appreciated, as right now I'm reduced to grasping at straws. ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
amd64 exhibits the same problem, except that it's not even polite and panics without even asking. ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
I've also tried a 6.1-derived kernel. I doubt that it was fixed for 8.0-RELEASE and then broken again on HEAD, but I'll check and be sure. My guess is that the problem is with the BIOS. We loaned our reference board to our BIOS vendor for development purposes and the BIOS they left on it is also unable to start APs. I think that my best bet to track this down is to see how the original Intel BIOS and the bad BIOS is configuring the hardware differently. I'm not very familiar with this stuff so I'm not sure what I should be looking at. MTRRs, I guess. What else? ___ 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: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
Just wanted to give everybody some closure on this issue: Through the magic of a JTAG debugger, I was able to identify that the problem was an infinite loop in the BIOS's SMI handler. I'm not sure why this didn't effect Linux -- perhaps it brought up the APs before the SMI came in. In any case, this clearly isn't a FreeBSD problem and I've punted the problem back to the BIOS vendor. Thanks to everyone who offered help and advice. ___ 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: nvidia-driver 195.22 use horribly broken on amd64 between r206173 and
I'm by no means an expert in this area, but isn't removing the locking on free a bad thing? Looking at the code, it seems that vm_page_unwire() only requires the page to be locked if it is managed. As it was acquired by contigmalloc, the page should be unmanaged so that should be ok. I am confused as to why vm_page_unwire() does not require the page to be locked if the page is unmanaged. What is synchronizing the accesses to m-wire_count? ___ 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
