Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
On Tue, 1 Nov 2011, Penta Upa wrote: Yes that seems to be the problem. It will is for out of tree modules. http://www.freebsd.org/cgi/query-pr.cgi?pr=161887 . I have to verify if moving the module to /usr/src/ tree fixes the problem. Thanks, Penta On Tue, Nov 1, 2011 at 2:04 AM, K. Macy km...@freebsd.org wrote: Someone was seeing the same issue with the vmtools kmod. The only thing that might make sense is that the page lock array is defined as being a different size in your kmod as in the kernel itself so the lock corresponding to the page you're locking differs between the two files. Quoting from the PR, Andriy Gapon a...@freebsd.org wrote: A standalone module build doesn't get some important definitions from kernel config (e.g. via opt_global.h) and can be in a serious disagreement with the kernel. In particular, if a kernel is built with SMP option, but a module build doesn't have SMP defined, then they will have different definitions of PA_LOCK_COUNT and thus would work on different actual locks when manipulating the same page. I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include opt_global.h' to be passed on the command line. Is the issue just that the opt_global.h used for the kmod could be different from the actual kernel's opt_global.h, because KERNCONF was not specified and the header is generated at module-build time? In this case, clearly the onus is on the user to pass KERNCONF at module build time. (I have gotten my laptop to panic in vm_page_free() with the page lock not owned, in OpenAFS' vop_getpages implementation, but I had previously attributed this to having an old -current snapshot on my laptop and openafs sources that were using freebsd major version for API decisions (we're not converted to __FreeBSD_version, yet). If there is a real problem here, I will need to care much more.) Thanks, Ben Kaduk ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 10.0-CUR ports/security/libgcrypt fails
El día Wednesday, November 02, 2011 a las 05:44:02AM +0100, Matthias Apitz escribió: Hello, I've pulled out r226986 fromm SVN and port from CVS completely fresh on November 1st; ports/security/libgcrypt fails to build with: # make install ... -std=gnu89 -MT mpih-add1-asm.lo -MD -MP -MF .deps/mpih-add1-asm.Tpo -c mpih-add1-asm.S -fPIC -DPIC -o .libs/mpih-add1-asm.o mpih-add1-asm.S: Assembler messages: mpih-add1-asm.S:44: Error: alignment not a power of 2 mpih-add1-asm.S:79: Error: alignment not a power of 2 *** Error code 1 I have had a look into the Makefile and for the moment I could do a workaround with adding a ./configure hint: # diff Makefile Makefile.orig 36d35 CONFIGURE_ARGS+= --disable-asm matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ 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 at vm_page_wire with FreeBSD 9.0 Beta 3
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
opt_global.h' to be passed on the command line. Is the issue just that the
opt_global.h used for the kmod could be different from the actual kernel's
opt_global.h, because KERNCONF was not specified and the header is generated
at
module-build time? In this case, clearly the onus is on the user to pass
KERNCONF at module build time.
To be precise, this is what is actually passed to a compiler:
sys/conf/kmod.mk:
.if defined(KERNBUILDDIR)
CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h
.endif
where KERNBUILDDIR can be passed via environment from a kernel build:
sys/conf/kern.post.mk:
MKMODULESENV+= KERNBUILDDIR=${.CURDIR} SYSDIR=${SYSDIR}
KERNCONF does not have any meaning in a module build.
To make sure that a module build sees exactly the same kernel options as a
kernel with which the module should work, one has to either build the module
together with the kernel (within the kernel build; search for MODULES in
make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel
build directory. (Which to a certain degree implies impossibility to build a
perfect module for a pre-built binary kernel or to provide a perfect
universal pre-built module for any custom kernel)
Of course, the real problem is that modules should not care about any (or at
least some) kernel options, they should be isolated from the options via a
proper KPI/KBI (perhaps DDI or module-to-kernel interface or whatever). A
module should be able to work correctly with kernels built with different
options.
As Bruce Evans has pointed to me privately [I am not sure why privately], there
is already an example in i386 and amd64 atomic.h, where operations are inlined
for a kernel build, but presented as real (external) functions for a module
build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
I think that the same treatment could/should be applied to vm_page_*lock*
operations defined in sys/vm/vm_page.h.
Or, if the above operations are intended to be used only in the kernel proper,
then there should be some guidelines on what API should module writers use to
perform certain page manipulations like e.g. wiring a page.
P.S. Bruce has also pointed out some other potentially dangerous places with
respect to the SMP option and modules build. Most prominent is sys/sys/mutex.h
P.P.S. [and tangential] I see that many module makefiles fake up various kernel
options in a fashion similar to the following:
.if !defined(KERNBUILDDIR)
opt_compat.h:
echo #define COMPAT_FREEBSD6 1 ${.TARGET}
opt_kbd.h:
echo #define KBD_INSTALL_CDEV 1 ${.TARGET}
.endif
And handful of modules fake up opt_global.h, e.g.:
opt_global.h:
echo #define ALTQ 1 ${.TARGET}
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Compiling BETA2 with clang fails
2011/9/5 Volodymyr Kostyrko c.kw...@gmail.com: 0k, here you go. Just as you say - no -fPIC, no ccache, no anything. === libexec/atrun (all) clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/atrun.c clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/libexec/atrun/gloadavg.c clang -O2 -pipe -march=native -DATJOB_DIR=\/var/at/jobs/\ -DLFILE=\/var/at/jobs/.lockfile\ -DLOADAVG_MX=1.5 -DATSPOOL_DIR=\/var/at/spool\ -DVERSION=\2.9\ -DDAEMON_UID=1 -DDAEMON_GID=1 -DDEFAULT_BATCH_QUEUE=\'E\' -DDEFAULT_AT_QUEUE=\'c\' -DPERM_PATH=\/var/at/\ -I/usr/src/libexec/atrun/../../usr.bin/at -I/usr/src/libexec/atrun -DLOGIN_CAP -DPAM -std=gnu99 -fstack-protector -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -o atrun atrun.o gloadavg.o -lpam -lutil clang: warning: argument unused during compilation: '-std=gnu99' /usr/obj/usr/src/tmp/usr/lib/crt1.o: In function `_start1': /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x7d): undefined reference to `atexit' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x84): undefined reference to `_init_tls' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0x90): undefined reference to `atexit' /usr/src/lib/csu/i386-elf/crt1_c.c:(.text+0xad): undefined reference to `exit' atrun.o: In function `perr': /usr/src/libexec/atrun/atrun.c:(.text+0x12): undefined reference to `strlen' /usr/src/libexec/atrun/atrun.c:(.text+0x45): undefined reference to `vwarn' /usr/src/libexec/atrun/atrun.c:(.text+0x6d): undefined reference to `snprintf' /usr/src/libexec/atrun/atrun.c:(.text+0x8a): undefined reference to `vsyslog' /usr/src/libexec/atrun/atrun.c:(.text+0x9c): undefined reference to `exit' atrun.o: In function `perrx': /usr/src/libexec/atrun/atrun.c:(.text+0xd3): undefined reference to `vwarnx' /usr/src/libexec/atrun/atrun.c:(.text+0xdf): undefined reference to `exit' /usr/src/libexec/atrun/atrun.c:(.text+0xf3): undefined reference to `vsyslog' /usr/src/libexec/atrun/atrun.c:(.text+0xff): undefined reference to `exit' atrun.o: In function `main': /usr/src/libexec/atrun/atrun.c:(.text+0x160): undefined reference to `geteuid' /usr/src/libexec/atrun/atrun.c:(.text+0x174): undefined reference to `getegid' /usr/src/libexec/atrun/atrun.c:(.text+0x186): undefined reference to `setegid' /usr/src/libexec/atrun/atrun.c:(.text+0x193): undefined reference to `seteuid' [...] clang: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop in /usr/src/libexec/atrun. *** Error code 1 Stop in /usr/src/libexec. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Replying to an old thread, but FYI this problem which has been bugging me since months has gone away since the lastest clang branches/release_30 import, and it has been MFC'ed to stable/9. I can now buildworld with -march=corei7 instead of -march=core2 :) (the same should apply for -march=native) Cheers -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org - against HTML email vCards X www: http://www.gid0.org - against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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
USB3 express card panics on 9.0-RC1
I have bought a Super-speed Express Card To USB 3.0 1-Port to connect an USB3 hard disk to my Thinkpad T510, which only has USB2. Trying to hot plug the express card did nothing, but I guess that is expected. Hence, I booted with the express card already inserted, only to receive a panic upon xhci0 initialization, see below. This is on FreeBSD 9.0-RC1/amd64 with a generic kernel installed from the official DVD. I guess I could test 226803 mentioned in http://lists.freebsd.org/pipermail/freebsd-usb/2011-October/010746.html , which happened after RC1, but from the commit message, it only fixes suspend and resume. As I do not have much time now, should I test 226803, find a Linux CD to actually identify the device, or anything else? Cheers, Jan Henrik usbus0: 480 Mbps High Speed USB v2.0 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x18 fault code = supervisor write data, page not present instruction ponter = 0x20:0x806e80aa stack pointer = 0x28:0xff810ee50bc0 frame pointer = 0x28:0xff810ee50bf0 code segment= base 0x0, limit 0xf, type 0x16 = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 15 (xhci0) trap number = 12 panic: page fault cpuid = 0 Uptime = 1s Automatic reboot in 15 seconds - press a key on the console to abort ___ 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 Monday, October 31, 2011 7:43:03 pm Attilio Rao wrote:
2011/10/28 m...@freebsd.org:
On Fri, Oct 28, 2011 at 8:37 AM, Ryan Stone ryst...@gmail.com wrote:
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'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 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.
Looks like Max didn't have time to upstream this fix:
struct mtx smp_ipi_mtx;
+MTX_SYSINIT(smp_ipi_mtx, smp_ipi_mtx, smp rendezvous, MTX_SPIN);
...
static void
mp_start(void *dummy)
{
- mtx_init(smp_ipi_mtx, smp rendezvous, NULL, MTX_SPIN);
...
if (!smp_started) {
+ mtx_lock_spin(smp_ipi_mtx);
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
+ mtx_unlock_spin(smp_ipi_mtx);
return;
}
I don't think that we strictly need the lock here, my preferred
solution would be (only test-compiled):
Index: sys/kern/subr_smp.c
===
--- sys/kern/subr_smp.c (revision 226972)
+++ sys/kern/subr_smp.c (working copy)
@@ -415,13 +415,16 @@ smp_rendezvous_cpus(cpuset_t map,
{
int curcpumap, i, ncpus = 0;
+ /* Look comments in the !SMP case. */
if (!smp_started) {
+ spinlock_enter();
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
+ spinlock_exit();
return;
}
@@ -666,12 +669,18 @@ smp_rendezvous_cpus(cpuset_t map,
void (*teardown_func)(void *),
void *arg)
{
+ /*
+* In the !SMP case we just need to ensure the same initial
conditions
+* as the SMP case.
+*/
+ spinlock_enter();
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
+ spinlock_exit();
}
void
@@ -681,12 +690,15 @@ smp_rendezvous(void (*setup_func)(void *),
void *arg)
{
+ /* Look comments in the smp_rendezvous_cpus() case. */
+ spinlock_enter();
if (setup_func != NULL)
setup_func(arg);
if (action_func != NULL)
action_func(arg);
if (teardown_func != NULL)
teardown_func(arg);
+ spinlock_exit();
}
I think this is fine, and probably correct.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
10.0-CUR r226986 ports/audio/jack installs no libjack.so
Hello, I fetched 10-CUR from SVN as r226986 and /usr/ports from CVS on November 1st; The ports/audio/jack seems installing fine, but the shared lib libjack.so is missing below ports/audio/jack/work and /usr/local/lib; it is mentioned in the list -L of the package; later ports/audio/arts and ports/x11/kde3 are missing the shared lib; Any ideas? Thanks matthias -- Matthias Apitz e g...@unixarea.de - w http://www.unixarea.de/ UNIX since V7 on PDP-11, UNIX on mainframe since ESER 1055 (IBM /370) UNIX on x86 since SVR4.2 UnixWare 2.1.2, FreeBSD since 2.2.5 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: GEOM MULTIPATH rewrite
On 10/31/11 22:10, Alexander Motin wrote: Attempt to fix some GEOM MULTIPATH issues made me almost rewrite it. So I would like to present my results and request for testing and feedback. The main changes: - Improved locking and destruction process to fix crashes in many cases. - Improved automatic configuration method to make it safe by reading metadata back from all specified paths after writing to one. - Added provider size check to reduce chance of conflict with other GEOM classes. - Added manual configuration method without using on-disk metadata. - Added add and remove commands to manage paths manually. - Failed paths no longer dropped from GEOM, but only marked as FAIL and excluded from I/O operations. - Automatically restore failed paths when all others paths are marked as failed, for example, because of device-caused (not transport) errors. - Added fail and restore commands to manually control FAIL flag. - GEOM is now destroyed on last provider disconnection. IMHO it is right to do if device was completely removed. - Added optional Active/Active mode support. Unlike Active/Passive mode, load evenly distributed between all working paths. If supported by device, it allows to significantly improve performance, utilizing bandwidth of all paths. It is controlled by -A option during creation. Disabled by default now. - Improved `status` and `list` commands output. Here is slightly updated version: http://people.freebsd.org/~mav/gmultipath5.patch Changes from previous: - label command was made to check metadata on other specified devices after writing to the first one and warn if something wrong there. - add command was allowed for devices created using automatic method. It may be useful in cases when some paths are temporary not operational and can't even read metadata. In such case they could be added manually and marked failed until their time will come. - Load balancing in Active/Active mode slightly improved: if all paths have equal load, do round-robin between them. -- Alexander Motin ___ 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 at vm_page_wire with FreeBSD 9.0 Beta 3
On 11/02/2011 05:32, Andriy Gapon wrote:
[restored cc: to the original poster]
on 02/11/2011 08:10 Benjamin Kaduk said the following:
I am perhaps confused. Last I checked, bsd.kmod.mk caused '-include
opt_global.h' to be passed on the command line. Is the issue just that the
opt_global.h used for the kmod could be different from the actual kernel's
opt_global.h, because KERNCONF was not specified and the header is generated at
module-build time? In this case, clearly the onus is on the user to pass
KERNCONF at module build time.
To be precise, this is what is actually passed to a compiler:
sys/conf/kmod.mk:
.if defined(KERNBUILDDIR)
CFLAGS+= -DHAVE_KERNEL_OPTION_HEADERS -include ${KERNBUILDDIR}/opt_global.h
.endif
where KERNBUILDDIR can be passed via environment from a kernel build:
sys/conf/kern.post.mk:
MKMODULESENV+= KERNBUILDDIR=${.CURDIR} SYSDIR=${SYSDIR}
KERNCONF does not have any meaning in a module build.
To make sure that a module build sees exactly the same kernel options as a
kernel with which the module should work, one has to either build the module
together with the kernel (within the kernel build; search for MODULES in
make.conf(5)) or to manually specify KERNBUILDDIR to point to a correct kernel
build directory. (Which to a certain degree implies impossibility to build a
perfect module for a pre-built binary kernel or to provide a perfect
universal pre-built module for any custom kernel)
Of course, the real problem is that modules should not care about any (or at
least some) kernel options, they should be isolated from the options via a
proper KPI/KBI (perhaps DDI or module-to-kernel interface or whatever). A
module should be able to work correctly with kernels built with different
options.
As Bruce Evans has pointed to me privately [I am not sure why privately], there
is already an example in i386 and amd64 atomic.h, where operations are inlined
for a kernel build, but presented as real (external) functions for a module
build. You can search e.g. sys/amd64/include/atomic.h for KLD_MODULE.
I think that the same treatment could/should be applied to vm_page_*lock*
operations defined in sys/vm/vm_page.h.
*snip*
Yes, it should be. There are without question legitimate reasons for a
module to acquire a page lock.
Alan
___
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
