IPSEC crashes after r253088
After r253088, systems with IPSEC and KSTACK_PAGES 4 crashes on
booting into multi-user mode.
The crash is due to sysctl -a in /etc/rc.d/initrandom ended up with
kernel stack overflow.
The problem is what we have in sys/net/vnet.h:
#define SYSCTL_VNET_PCPUSTAT(parent, nbr, name, type, array, desc) \
static int \
array##_sysctl(SYSCTL_HANDLER_ARGS) \
{ \
type s; \
CTASSERT((sizeof(type) / sizeof(uint64_t)) == \
(sizeof(VNET(array)) / sizeof(counter_u64_t))); \
COUNTER_ARRAY_COPY(VNET(array), s, sizeof(type) / sizeof(uint64_t));\
if (req-newptr)\
COUNTER_ARRAY_ZERO(VNET(array), \
sizeof(type) / sizeof(uint64_t)); \
return (SYSCTL_OUT(req, s, sizeof(type))); \
} \
SYSCTL_VNET_PROC(parent, nbr, name, CTLTYPE_OPAQUE | CTLFLAG_RW, NULL, \
0, array ## _sysctl, I, desc)
where type is struct ipsecstat which is 12560 bytes of size (larger than
3 pages) of size when processing net.inet.ipsec.ipsecstats.
--
-|-__ YAMAMOTO, Taku
| __ t...@tackymt.homeip.net
- A chicken is an egg's way of producing more eggs. -
___
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] to fix slow gen2 Intel video (i830, i845, i85x, i865) with KMS
Hi all,
A good news to owners of i830, i845, i852, i855 and i865 (a.k.a. gen2),
who've got frustrated with the bad performance with KMS.
I managed to track down the root cause of the slowness of gen2 with KMS and
finally fixed it.
The attached one-liner patch is the fix.
(It was my surprise that the actual problem lied in agp rather than i915kms.)
--
-|-__ YAMAMOTO, Taku
| __ t...@tackymt.homeip.net
- A chicken is an egg's way of producing more eggs. -
--- sys/dev/agp/agp_i810.c.orig 2013-01-20 16:18:33.382363986 +0900
+++ sys/dev/agp/agp_i810.c 2013-01-25 05:47:17.046570619 +0900
@@ -2228,7 +2228,7 @@ agp_i830_chipset_flush(device_t dev)
bus_write_4(sc-sc_res[0], AGP_I830_HIC, hic | (1 31));
for (i = 0; i 2 /* 1 sec */; i++) {
hic = bus_read_4(sc-sc_res[0], AGP_I830_HIC);
- if ((hic (1 31)) != 0)
+ if ((hic (1 31)) == 0)
break;
DELAY(50);
}
___
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
apache22 fails to start since r242184
Has anyone noticed this with head since r242184? % sudo service apache22 start Performing sanity check on apache22 configuration: Syntax OK Starting apache22. setfib: NO: invalid FIB (max 0) /usr/local/etc/rc.d/apache22: WARNING: failed to start apache22 I injected the following lines into run_rc_command() in /etc/rc.subr: case $_fib in [nN][oO]) unset _fib;; esac now things are back to normal, though of course I know this isn't the right way to go... -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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 development audio system: KLANG
I think it should be forwarded to -multimedia@. Other than that, it's nice to hear about! On Sun, 12 Aug 2012 13:13:56 +0200 O. Hartmann ohart...@zedat.fu-berlin.de wrote: A few days ago, I stumbled into sthis at Phoronix: http://www.phoronix.com/scan.php?page=news_itempx=MTE1NzY The above link didn't work for me... KLANG is supposed to be an exchange audio system for the kernel, replacing several userland backed systems. Phoronix also claims this approach is supposed to support the FreeBSD kernel and yes, I'd like to see something been developed not even for Linux these days. On the website of KLANG, located here, http://klang.eudyptula.org/ I couldn't find much of information regarding FreeBSD. But I'd like to draw attention towards this for FreeBSD people, if they didn't already have noticed. It is like in science - no spreading of informations makes it hard to discover what's going on ... I'm not sorry for the noise, Don't worry, generating a noise is the primary goal for sound systems :) -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: FYI: SIGBUS with world built by clang
On Thu, 5 Jul 2012 00:14:14 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: On Wed, 04 Jul 2012 17:08:30 +0200 Dimitry Andric d...@freebsd.org wrote: On 2012-07-04 16:33, Taku YAMAMOTO wrote: For people having SIGBUS with clang-build world + gcc-build binaries, In short words, for any libraries (and never forget about rtld-elf!) which are potentially called from arbitrary binaries, compile them with either -mstackrealign or -mstack-alignment=8! The detail is as follows. I've observed that clang carelessly expects the stack being aligned at 16 byte boundary. Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* align the stack on 16-byte boundaries is basically broken. Or are you experiencing this on i386? Even there, 16-byte alignment would be much better in combination with SSE instructions (which arent' enabled by default, btw). Oops, I had to be clear about that! Yes, the experiment was took on i386 (actually -march=pentium4). Note that you would get the same issue with newer versions of gcc, which will also assume this alignment. Interesting, but the base gcc we currently have won't on i386, I think. (I occationally get bitten by similar problem when using -ftree-vectorize) As far as I understand the rules, $esp % 16 must be zero before call instruction is executed. I googled and found that it is enforced by MacOS X ABI for IA32 but i386 SysV ABI defines otherwise (8 bytes instead of 16 bytes). i386 csu explicitely aligns the stack before calling into C land, everything else should be the C compiler own offence :). Unfortunately it is difficult when we have to deal with binaries produced by random compilers, such as Win32 app via wine, mplayer with win32-codecs, etc. ;) JITs, like Java and mono, also have possibility to become victims if they emit native codes without paying attention to the stack alignment, though I'm not sure. Just my random thoughts, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: FYI: SIGBUS with world built by clang
On Thu, 5 Jul 2012 23:11:31 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Fri, Jul 06, 2012 at 04:15:18AM +0900, Taku YAMAMOTO wrote: On Thu, 5 Jul 2012 00:14:14 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Thu, Jul 05, 2012 at 12:32:01AM +0900, Taku YAMAMOTO wrote: On Wed, 04 Jul 2012 17:08:30 +0200 Dimitry Andric d...@freebsd.org wrote: On 2012-07-04 16:33, Taku YAMAMOTO wrote: For people having SIGBUS with clang-build world + gcc-build binaries, In short words, for any libraries (and never forget about rtld-elf!) which are potentially called from arbitrary binaries, compile them with either -mstackrealign or -mstack-alignment=8! The detail is as follows. I've observed that clang carelessly expects the stack being aligned at 16 byte boundary. Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* align the stack on 16-byte boundaries is basically broken. Or are you experiencing this on i386? Even there, 16-byte alignment would be much better in combination with SSE instructions (which arent' enabled by default, btw). Oops, I had to be clear about that! Yes, the experiment was took on i386 (actually -march=pentium4). Note that you would get the same issue with newer versions of gcc, which will also assume this alignment. Interesting, but the base gcc we currently have won't on i386, I think. (I occationally get bitten by similar problem when using -ftree-vectorize) As far as I understand the rules, $esp % 16 must be zero before call instruction is executed. I googled and found that it is enforced by MacOS X ABI for IA32 but i386 SysV ABI defines otherwise (8 bytes instead of 16 bytes). No, SysV ABI only requires 4-byte alignment for the stack on i386. (snip) Oh, I stand corrected. Thank you :) -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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
FYI: SIGBUS with world built by clang
For people having SIGBUS with clang-build world + gcc-build binaries,
In short words, for any libraries (and never forget about rtld-elf!)
which are potentially called from arbitrary binaries,
compile them with either -mstackrealign or -mstack-alignment=8!
The detail is as follows.
I've observed that clang carelessly expects the stack being aligned at
16 byte boundary.
For example, the following code:
#include stdarg.h
#include stdio.h
int
foo(const char *format,...)
{
int ret;
va_list ap;
FILE f = {};
va_start(ap, format);
ret = vfprintf(f, format, ap);
va_end(ap);
return ret;
}
which turns into:
pushl %ebp
movl%esp, %ebp
subl$264, %esp # imm = 0x108
xorps %xmm0, %xmm0
movaps %xmm0, -40(%ebp)
movaps %xmm0, -56(%ebp)
(snip; lots of movaps insns follows)
which results in SIGBUS if %esp - 4 is not at 16 byte boundary.
(Note: movaps expects the address aligned to 16 bytes!)
This problem becomes visible when such functions get called from binaries
compiled with other compilers which don't care about stack alignment.
If the above code is compiled by clang with -mstackrealign:
pushl %ebp
movl%esp, %ebp
andl$-16, %esp
subl$272, %esp # imm = 0x110
xorps %xmm0, %xmm0
movaps %xmm0, 224(%esp)
movaps %xmm0, 208(%esp)
(snip; lots of movaps insns follows)
it tries to align the stack prior to allocating local variables thus no
problem.
If the above code is compiled by clang with -mstack-alignment=8:
pushl %ebp
movl%esp, %ebp
pushl %esi
subl$252, %esp
leal-240(%ebp), %esi
movl%esi, (%esp)
movl$232, 8(%esp)
movl$0, 4(%esp)
calll memset
(snip)
it calls memset instead of a bunch of movaps to clear the storage thus no
problem, of course.
# I don't know why clang doesn't utilize rep stosl, though.
Pros and cons:
-mstackrealign
Pros: no function calls to memset
probably faster because of SSE
Cons: use of SSE means the need of saving FP registers
potentially more stack consumption
-mstack-alignment=#
Pros: normal and predictive stack consumption
don't spill SSE registers; no extra overhead on context switching
Cons: depends on memset
--
-|-__ YAMAMOTO, Taku
| __ t...@tackymt.homeip.net
- A chicken is an egg's way of producing more eggs. -
___
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: FYI: SIGBUS with world built by clang
On Wed, 04 Jul 2012 17:08:30 +0200 Dimitry Andric d...@freebsd.org wrote: On 2012-07-04 16:33, Taku YAMAMOTO wrote: For people having SIGBUS with clang-build world + gcc-build binaries, In short words, for any libraries (and never forget about rtld-elf!) which are potentially called from arbitrary binaries, compile them with either -mstackrealign or -mstack-alignment=8! The detail is as follows. I've observed that clang carelessly expects the stack being aligned at 16 byte boundary. Eh, this is a requirement of the amd64 ABI. Any compiler that *doesn't* align the stack on 16-byte boundaries is basically broken. Or are you experiencing this on i386? Even there, 16-byte alignment would be much better in combination with SSE instructions (which arent' enabled by default, btw). Oops, I had to be clear about that! Yes, the experiment was took on i386 (actually -march=pentium4). Note that you would get the same issue with newer versions of gcc, which will also assume this alignment. Interesting, but the base gcc we currently have won't on i386, I think. (I occationally get bitten by similar problem when using -ftree-vectorize) -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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
A suspicious warning in sys/boot/zfs/zfsimpl.c
When I built the world as of r237813, clang reported a warning which caught my attention. === sys/boot/zfs (all) clang -O2 -pipe -march=pentium4 -DBOOTPROG=\zfsloader\ -I/usr/src/sys/boot/zfs/../common -I/usr/src/sys/boot/zfs/../.. -I. -I/usr/src/sys/boot/zfs/../../../lib/libstand -I/usr/src/sys/boot/zfs/../../cddl/boot/zfs -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -Wformat -Wall -DNDEBUG -std=gnu99 -Qunused-arguments -c /usr/src/sys/boot/zfs/zfs.c -o zfs.o In file included from /usr/src/sys/boot/zfs/zfs.c:48: /usr/src/sys/boot/zfs/zfsimpl.c:2033:19: warning: array index 264 is past the end of the array (which contains 192 elements) [-Warray-bounds] memcpy(path, dn.dn_bonus[sizeof(znode_phys_t)], ^ /usr/src/sys/boot/zfs/../../cddl/boot/zfs/zfsimpl.h:788:2: note: array 'dn_bonus' declared here uint8_t dn_bonus[DN_MAX_BONUSLEN - sizeof (blkptr_t)]; ^ I don't have a zfs-powered machine, so I'm not sure whether this warning is false-positive or not. -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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 system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
On Fri, 22 Jun 2012 08:22:19 +0200 Hans Petter Selasky hsela...@c2i.net wrote: (snip) I would be more than glad to open up an office to certify USB devices for use with FreeBSD :-) My elder colleague often told me that it is the easiest and well-working way to check whether the one is certified to work for Mac OS X to get USB mass storage devices which work with *BSD :) Just my 5 yen, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: Follow-up: Re: recent update breaks some ports
I'm glad to report that your patch fixes not only wlock-within-wlock cases but also rlock-within-wlock cases properly! On Wed, 11 Apr 2012 22:42:39 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Thu, Apr 12, 2012 at 04:04:11AM +0900, Taku YAMAMOTO wrote: (snip) The following is the first occurence of rlock-within-wlock incident. Hardware watchpoint 2: lock_place[0].count_rw Old value = 0 New value = 1 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire () from /libexec/ld-elf.so.1 #2 0x2806fccb in _rtld_bind () from /libexec/ld-elf.so.1 #3 0x28069dc9 in _rtld_bind_start () from /libexec/ld-elf.so.1 #4 0x290c3000 in ?? () #5 0x0148 in ?? () #6 0x29356318 in ?? () from /usr/lib/libsupc++.so.1 #7 0x28f503e0 in _thr_once_init () from /home/taku/work/build/biotite/usr/src/lib/libthr/libthr.so.3 #8 0x in ?? () #9 0x00200202 in ?? () #10 0x290c3000 in ?? () #11 0x0148 in ?? () #12 0x2935eae0 in __gxx_personality_v0 () from /usr/lib/libsupc++.so.1 #13 0x2935f5c5 in __cxa_get_globals () from /usr/lib/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in ?? () from /usr/lib/libsupc++.so.1 #17 0x280714c9 in lock_release () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) Unortunately, this trace is not usefule, it seems that you need to recompile rtld/libc/libthr with debugging symbols to get the issue fixed. I retook the latter execution path with debugging symbols, without your patch for the record. Hardware watchpoint 3: lock_place[0].count_rw Old value = 0 New value = 1 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire (lock=0x2807efbc, lockstate=0xbfbfdb70) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #2 0x2806fccb in _rtld_bind (obj=0x290c3000, reloff=328) at /usr/src/libexec/rtld-elf/rtld.c:642 #3 0x28069dc9 in _rtld_bind_start () at /usr/src/libexec/rtld-elf/i386/rtld_start.S:81 #4 0x290c3000 in ?? () #5 0x0148 in ?? () #6 0x29356318 in .rel.plt () from /home/taku/lib/debug/libsupc++.so.1 #7 0x in ?? () #8 0x00200206 in ?? () #9 0x290c3000 in ?? () #10 0x0148 in ?? () #11 0x2935eae0 in __static_initialization_and_destruction_0 (__initialize_p=Variable __initialize_p is not available. ) at gthr-default.h:188 #12 0x2935f5c5 in __cxa_get_globals () from /home/taku/lib/debug/libsupc++.so.1 #13 0x290c2710 in ?? () #14 0xbfbfdc48 in ?? () #15 0x29356325 in _init () from /home/taku/lib/debug/libsupc++.so.1 #16 0x280714c9 in lock_release (lock=0x280714c9, lockstate=0x2807d2a4) at /usr/src/libexec/rtld-elf/rtld_lock.c:219 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Hardware watchpoint 3: lock_place[0].count_rw Old value = 1 New value = 2 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire (lock=0x2807efbc, lockstate=0xbfbfdb70) at /usr/src/libexec/rtld-elf/rtld_lock.c:197 #2 0x2806fccb in _rtld_bind (obj=0x290c3000, reloff=64) at /usr/src/libexec/rtld-elf/rtld.c:642 #3 0x28069dc9 in _rtld_bind_start () at /usr/src/libexec/rtld-elf/i386/rtld_start.S:81 #4 0x290c3000 in ?? () #5 0x0040 in ?? () #6 0x00018747 in ?? () #7 0x00018747 in ?? () #8 0x29362f8c in __new_handler () from /home/taku/lib/debug/libsupc++.so.1 #9 0x00200246 in ?? () #10 0x290c3000 in ?? () #11 0x0040 in ?? () #12 0x2935eaf8 in __static_initialization_and_destruction_0 (__initialize_p=Variable __initialize_p is not available. ) at gthr-default.h:189 #13 0x2935f5c5 in __cxa_get_globals () from /home/taku/lib/debug/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in _init () from /home/taku/lib/debug/libsupc++.so.1 #17 0x280714c9 in lock_release (lock=0x280714c9, lockstate=0x2807d2a4) ---Type return to continue, or q return to quit--- at /usr/src/libexec/rtld-elf/rtld_lock.c:219 Previous frame inner to this frame (corrupt stack?) (gdb) c Continuing. Hardware watchpoint 3: lock_place[0].count_rw Old value = 2 New value = 3 0x28f5275d in _thr_rtld_rlock_acquire (lock=0x28f63680) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f5275d in _thr_rtld_rlock_acquire
Re: recent update breaks some ports
On Wed, 11 Apr 2012 15:53:38 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Wed, Apr 11, 2012 at 01:34:01PM +0200, Stefan Farfeleder wrote:
On Tue, Apr 10, 2012 at 08:31:53AM +0200, Stefan Farfeleder wrote:
On Tue, Apr 10, 2012 at 01:44:02AM -0400, AN wrote:
FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #7 r234042: Sun Apr 8
17:36:38 EDT 2012 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64
After a recent update on Sunday to r234042 I am having a problem with 2
ports:
gedit
evince
(using Gnome2 - ports tree up to date)
My last update (before this past Sun build/install world) was 2 weeks
ago,
so it was definitely a change made in the last 2 weeks.
Gedit will not start from the command line, or the applications menu.
There is no error message on the command line. Evince will start,
however
when you try to open a document the program freezes.
I have tried to:
make deinstall
make clean
make install clean
for both ports but they are still broken. I would appreciate any help.
I'm experiencing that too (r234038), xine also no longer starts (hangs
at splash screen).
FWIW backing out r233749 fixes evince and xine for me.
Please recompile at least rtld/libc/libthr with debugging symbols and get
a backtrace from the hung process.
My wild guess tells me that the rtld_bind_lock gets held recursively
when resolving filtered symbol.
The attached band-aid patch supports the guess.
I have the world/kernel as of r234038 and have difficulty to launch XFce's
xfdesktop-settings (w/ im-scim.so which loads libstdc++), where every threads
of xfdesktop-settings stuck into either urdlck or uwrlck states.
I have to admit that the attached patch is something like 3-minute-hacking
quality, but it at least avoids the stall.
--
-|-__ YAMAMOTO, Taku
| __ t...@tackymt.homeip.net
- A chicken is an egg's way of producing more eggs. -
--- lib/libthr/thread/thr_rtld.c.orig 2011-01-23 09:17:50.657791000 +0900
+++ lib/libthr/thread/thr_rtld.c2012-04-12 02:48:05.091322596 +0900
@@ -52,6 +52,10 @@ static void _thr_rtld_wlock_acquire(void
struct rtld_lock {
struct urwlock lock;
+ struct pthread * volatile owner;
+ int nested;
+ int count_rw; /* total rlock-within-wlock incidents */
+ int count_ww; /* total wlock-within-wlock incidents */
char_pad[CACHE_LINE_SIZE - sizeof(struct urwlock)];
};
@@ -106,6 +110,15 @@ _thr_rtld_lock_destroy(void *lock)
errno = errsave;\
}
+#define HANDLE_NESTED_ACQ(statfield) { \
+ if ((l-lock.rw_state URWLOCK_WRITE_OWNER) != 0 \
+ l-owner == curthread) {\
+ l-nested++;\
+ l-statfield++; \
+ return; \
+ } \
+ }
+
static void
_thr_rtld_rlock_acquire(void *lock)
{
@@ -117,6 +130,7 @@ _thr_rtld_rlock_acquire(void *lock)
SAVE_ERRNO();
l = (struct rtld_lock *)lock;
+ HANDLE_NESTED_ACQ(count_rw);
THR_CRITICAL_ENTER(curthread);
while (_thr_rwlock_rdlock(l-lock, 0, NULL) != 0)
;
@@ -135,9 +149,11 @@ _thr_rtld_wlock_acquire(void *lock)
SAVE_ERRNO();
l = (struct rtld_lock *)lock;
+ HANDLE_NESTED_ACQ(count_ww);
THR_CRITICAL_ENTER(curthread);
while (_thr_rwlock_wrlock(l-lock, NULL) != 0)
;
+ l-owner = curthread;
RESTORE_ERRNO();
}
@@ -154,6 +170,14 @@ _thr_rtld_lock_release(void *lock)
l = (struct rtld_lock *)lock;
state = l-lock.rw_state;
+ if ((state URWLOCK_WRITE_OWNER) != 0) {
+ if (l-nested == 0)
+ l-owner = NULL;
+ else {
+ l-nested--;
+ return;
+ }
+ }
if (_thr_rwlock_unlock(l-lock) == 0) {
if ((state URWLOCK_WRITE_OWNER) == 0)
curthread-rdlock_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
Follow-up: Re: recent update breaks some ports
The following is the first occurence of wlock-within-wlock incident when I run xfdesktop-settings under gdb. Hardware watchpoint 3: lock_place[0].count_ww Old value = 0 New value = 1 0x28f52522 in _thr_rtld_wlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:152 152 HANDLE_NESTED_ACQ(count_ww); (gdb) bt #0 0x28f52522 in _thr_rtld_wlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:152 #1 0x280719c1 in wlock_acquire () from /libexec/ld-elf.so.1 #2 0x2806eb15 in dlopen_object () from /libexec/ld-elf.so.1 #3 0x2806ef1b in load_filtee1 () from /libexec/ld-elf.so.1 #4 0x2806ef7d in load_filtees () from /libexec/ld-elf.so.1 #5 0x2806f318 in symlook_obj () from /libexec/ld-elf.so.1 #6 0x2806f421 in symlook_list () from /libexec/ld-elf.so.1 #7 0x2806fa0b in symlook_default () from /libexec/ld-elf.so.1 #8 0x2806fc1a in find_symdef () from /libexec/ld-elf.so.1 #9 0x2806a426 in reloc_non_plt () from /libexec/ld-elf.so.1 #10 0x2806d453 in relocate_objects () from /libexec/ld-elf.so.1 #11 0x2806ee6d in dlopen_object () from /libexec/ld-elf.so.1 #12 0x2806f862 in rtld_dlopen () from /libexec/ld-elf.so.1 #13 0x28d2a6b0 in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #14 0x28406894 in gtk_im_context_simple_new () from /usr/local/lib/libgtk-x11-2.0.so.0 The following is the first occurence of rlock-within-wlock incident. Hardware watchpoint 2: lock_place[0].count_rw Old value = 0 New value = 1 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 133 HANDLE_NESTED_ACQ(count_rw); (gdb) bt #0 0x28f526fd in _thr_rtld_rlock_acquire (lock=0x28f63600) at /usr/src/lib/libthr/thread/thr_rtld.c:133 #1 0x28071291 in rlock_acquire () from /libexec/ld-elf.so.1 #2 0x2806fccb in _rtld_bind () from /libexec/ld-elf.so.1 #3 0x28069dc9 in _rtld_bind_start () from /libexec/ld-elf.so.1 #4 0x290c3000 in ?? () #5 0x0148 in ?? () #6 0x29356318 in ?? () from /usr/lib/libsupc++.so.1 #7 0x28f503e0 in _thr_once_init () from /home/taku/work/build/biotite/usr/src/lib/libthr/libthr.so.3 #8 0x in ?? () #9 0x00200202 in ?? () #10 0x290c3000 in ?? () #11 0x0148 in ?? () #12 0x2935eae0 in __gxx_personality_v0 () from /usr/lib/libsupc++.so.1 #13 0x2935f5c5 in __cxa_get_globals () from /usr/lib/libsupc++.so.1 #14 0x290c2710 in ?? () #15 0xbfbfdc48 in ?? () #16 0x29356325 in ?? () from /usr/lib/libsupc++.so.1 #17 0x280714c9 in lock_release () from /libexec/ld-elf.so.1 Previous frame inner to this frame (corrupt stack?) -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: Changes to sbin/init/init.c (r233944) makes x11/xdm impossible to start from /etc/ttys
Thanks a lot to investigate this problem so deeply. I have, maybe related, a bit strange phenomenon among xdm, too. I have a bit different setup than others: I'm using modified x11/gdm/files/gdm.in to launch xdm. The problem is, when I start xdm manually from ttyvX like this: exec sudo service xdm start xdm won't start, while doing like this: sudo service xdm start; sleep 10; exit xdm starts happily. To emulate this symptom for those who don't use rc.d/xdm, in ttyvX: exec sudo sh -c (sleep 10; /usr/local/bin/xdm) (The amount to sleep may differ if some race conditions are involved.) I guess the root cause seems to reside in accessing revoke(2)-ed (or possibly, about to be revoke(2)-ed) tty. I hope my shallow observation can shed some lights from different perspective. -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - Post Scriptum: In my environment and/or setup, xdm auto-starts fine 100% times via rc.d on system startup. ___ 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 tinderbox] failure on i386/i386
Suppose some bit error of memory or storage of the tinderbox machine? On Sat, 24 Mar 2012 05:41:28 GMT FreeBSD Tinderbox tinder...@freebsd.org wrote: (snip) /src/sys/dev/arcmsr/arcmsr.h:43:2: error: invalid preprocessing directive #denine 'f'(0x66) ^ 'n'(0x6e) = 0x08 /src/sys/dev/arcmsr/arcmsr.h:52:2: error: invalid preprocessing directive #defino 'e'(0x65) ^ 'o'(0x6f) = 0x0a /src/sys/dev/arcmsr/arcmsr.h:93:2: error: invalid preprocessing directive #lefine 'd'(0x64) ^ 'l'(0x6c) = 0x08 /src/sys/dev/arcmsr/arcmsr.h:118:2: error: invalid preprocessing directive #tefine 'd'(0x64) ^ 't'(0x74) = 0x10 /src/sys/dev/arcmsr/arcmsr.h:138:2: error: invalid preprocessing directive #denine /src/sys/dev/arcmsr/arcmsr.h:148:2: error: invalid preprocessing directive #dofine 'e'(0x65) ^ 'o'(0x6f) = 0x0a FYI, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: [Solved] FreeBSD 9-Beta3 on X300 2 problems
On Tue, 27 Sep 2011 13:06:21 +0100
Gavin Atkinson gavin.atkin...@ury.york.ac.uk wrote:
On Tue, 2011-09-27 at 19:53 +0800, Adrian Chadd wrote:
Hans,
Why haven't those patches been committed?
This patch is an absolute hack, and shouldn't be committed as it is.
I would, however, appreciate some help in determining the correct
solution. The solution may well involve not suspending/resuming hpet(4)
or the other timers on the normal DEVICE_SUSPEND()/DEVICE_RESUME() path
but instead doing them as the last thing to be suspended, or it may
Like the attached patches do?
instead involve reworking the USB code (and potentially other code) to
not need to sleep during suspend/resume. I don't know the right
solution, but would really like to work with somebody who does.
Please also see the thread Choosing between DELAY(useconds) and
pause() on -current.
Gavin
___
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
--
-|-__ YAMAMOTO, Taku
| __ t...@tackymt.homeip.net
- A chicken is an egg's way of producing more eggs. -
--- sys/kern/subr_bus.c.orig2010-12-02 13:28:01.0 +0900
+++ sys/kern/subr_bus.c 2010-12-08 12:37:05.524727855 +0900
@@ -3385,15 +3385,13 @@ int
bus_generic_suspend(device_t dev)
{
int error;
- device_tchild, child2;
+ device_tchild;
- TAILQ_FOREACH(child, dev-children, link) {
+ TAILQ_FOREACH_REVERSE(child, dev-children, device_list, link) {
error = DEVICE_SUSPEND(child);
if (error) {
- for (child2 = TAILQ_FIRST(dev-children);
-child2 child2 != child;
-child2 = TAILQ_NEXT(child2, link))
- DEVICE_RESUME(child2);
+ while ((child = TAILQ_NEXT(child, link)) != NULL)
+ DEVICE_RESUME(child);
return (error);
}
}
--- sys/dev/acpica/acpi.c.orig 2010-07-16 08:24:06.0 +0900
+++ sys/dev/acpica/acpi.c 2010-07-21 20:10:59.056243391 +0900
@@ -1702,7 +1702,7 @@ acpi_probe_order(ACPI_HANDLE handle, int
*order = 1;
else if (acpi_MatchHid(handle, PNP0C01) || acpi_MatchHid(handle,
PNP0C02))
*order = 2;
-else if (acpi_MatchHid(handle, PNP0C09))
+else if (acpi_MatchHid(handle, PNP0C09) || acpi_MatchHid(handle,
PNP0103))
*order = 3;
else if (acpi_MatchHid(handle, PNP0C0F))
*order = 4;
___
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: `hw.acpi.thermal.tz0.temperature' disappeared
This patch works. FreeBSD 9.0-CURRENT #1: Tue Apr 19 10:52:58 MSD 2011 # sysctl hw.acpi.thermal hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: 67.5C hw.acpi.thermal.tz0.active: -1 hw.acpi.thermal.tz0.passive_cooling: 0 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: -1 hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 90.0C hw.acpi.thermal.tz0._ACx: -1 hw.acpi.thermal.tz0._TC1: -1 hw.acpi.thermal.tz0._TC2: -1 hw.acpi.thermal.tz0._TSP: -1 We should have 10 _ACx values like this: hw.acpi.thermal.tz0._ACx: -1 -1 -1 -1 -1 -1 -1 -1 -1 -1 I haven't seen meaningful values these days, though. IMHO the BIOS writers don't rely on OSes being stable enough not to toast the core ;) -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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: TTY task group scheduling
On Thu, 18 Nov 2010 21:30:16 +0100 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: On 11/18/10 19:55, Lucius Windschuh wrote: 2010/11/18 Andriy Gapona...@freebsd.org: [Grouping of processes into TTY groups] Well, I think that those improvements apply only to a very specific usage pattern and are greatly over-hyped. But there are serious issue if you use FreeBSD as a desktop OS with SMP and SCHED_ULE, or? Because currently, my machine is barely usable if a compile job with parallelism is running. Movies stutter, Firefox hangs. And even nice -n 20 doesn't do the job in every case, as +20 seems not to be the idle priority anymore?!? And using idprio 1 $cmd as a workaround is, well, a kludge. I am not sure if TTY grouping is the right solution, if you look at potentially CPU-intensive GUI applications that all run on the same TTY (or no TTY at all? Same problem). Maybe, we could simply enhance the algorithm that decides if a task is interactive? That would also improve the described situation. Regards, Lucius Stuttering Response, being stuck for over 20 seconds also happens when I start updating the OS' sources via svn. This happens on all boxes, some of them do have 8 cores (ob two CPUs) and plenty of RAM. Heavy disk I/O, doesn't matter on UFS2 or ZFS, also brings boxes to stutter, those phenomena are most seen when you interact with the machine via X11 clients. I think it's hard to realize if a server only does console I/O, but console also seems to be stuck sometimes. It would be worth checking this with some 'benchmark'. X11 in its kind of oldish incarnation on FreeBSD seems to contribute most to those slowdowns, what so ever. I guess schedulers can hardly distinguish heavy disk I/Os from nanosleep()s and user-interactions; schedulers think both as voluntary sleep. To make the matters worse, the current implementation of SCHED_ULE reassigns ts_slice on sched_wakeup() no matter how short the sleep was. I have a dumb local hack to grant ts_slice proportional to the duration the waking thread slept rather than unconditionally reset to sched_slice. --- sys/kern/sched_ule.c.orig +++ sys/kern/sched_ule.c @@ -1928,12 +1928,16 @@ sched_wakeup(struct thread *td) u_int hzticks; hzticks = (ticks - slptick) SCHED_TICK_SHIFT; + if (hzticks SCHED_SLP_RUN_MAX) + hzticks = SCHED_SLP_RUN_MAX; ts-ts_slptime += hzticks; + /* Grant additional slices after we sleep. */ + ts-ts_slice += hzticks / tickincr; + if (ts-ts_slice sched_slice) + ts-ts_slice = sched_slice; sched_interact_update(td); sched_pctcpu_update(ts); } - /* Reset the slice value after we sleep. */ - ts-ts_slice = sched_slice; sched_add(td, SRQ_BORING); } -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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
Followup: if_em.c prevents the 2nd time resuming
PR filed as kern/146614. http://www.freebsd.org/cgi/query-pr.cgi?pr=146614 -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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
if_em.c prevents the 2nd time resuming
Greetings, I found a bug in if_em.c which triggers a panic when resuming from the 2nd suspend. (sleep, wakeup, sleep and wakeup will result to a panic) It seems it has got introduced by r206001 (head) or r206211 (stable/8). I guess the following change mistakenly slipped into em_resume() which is completely bogus (suppose these lines should go into em_detach()?): @@ -769,6 +774,9 @@ struct adapter *adapter = device_get_softc(dev); struct ifnet *ifp = adapter-ifp; + if (adapter-led_dev != NULL) + led_destroy(adapter-led_dev); + EM_CORE_LOCK(adapter); em_init_locked(adapter); em_init_manageability(adapter); Should I file a PR? Virtually yours, -- -|-__ YAMAMOTO, Taku | __ t...@tackymt.homeip.net - A chicken is an egg's way of producing more eggs. - ___ 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] fixes of tcp_hostcache.c
Greetings, I found two calls of bcopy() in tcp_hostcache.c got the source and the destination pointer wrongly. # Perhaps the author got confused with memcpy(), I guess. The fix is attached as a patch against tcp_hostcache.c as of revision 1.2. Please review and incorporate the patch to the tree because the bug makes hostcache useless with TCPv6 and/or brings TTCP (RFC1644) meaningless. Especially the bug renders it unusable to use TCPv6 and TTCP together. # To confirm this: sysctl net.inet.tcp.rfc1644=1; telnet ::1 Best regards, Taku -- -|-__YAMAMOTO, Taku [EMAIL PROTECTED] | __ --- sys/netinet/tcp_hostcache.c.origSat Nov 29 01:33:03 2003 +++ sys/netinet/tcp_hostcache.c Tue Dec 2 10:17:57 2003 @@ -377,7 +377,7 @@ */ bzero(hc_entry, sizeof(*hc_entry)); if (inc-inc_isipv6) - bcopy(hc_entry-ip6, inc-inc6_faddr, sizeof(hc_entry-ip6)); + bcopy(inc-inc6_faddr, hc_entry-ip6, sizeof(hc_entry-ip6)); else hc_entry-ip4 = inc-inc_faddr; hc_entry-rmx_head = hc_head; @@ -474,7 +474,7 @@ hc_entry-rmx_hits++; hc_entry-rmx_expire = tcp_hostcache.expire; /* start over again */ - bcopy(tao, hc_entry-rmx_tao, sizeof(*tao)); + bcopy(hc_entry-rmx_tao, tao, sizeof(*tao)); THC_UNLOCK(hc_entry-rmx_head-hch_mtx); } ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: System freeze running -current
Hi all,
On Sat, 4 Jan 2003 17:55:25 +
Trent Nelson [EMAIL PROTECTED] wrote:
No. However, it happened to me today shorty after I issued a sysctl
-w hw.acpi.cpu.economy_speed=8. (Why does it default to 4 anyway?)
It reminded me of my tiny local patch.
--- src/sys/dev/acpica/acpi_cpu.c.orig Thu Oct 17 02:28:52 2002
+++ src/sys/dev/acpica/acpi_cpu.c Mon Dec 23 12:58:28 2002
@@ -328,7 +328,7 @@
if (speed CPU_MAX_SPEED) {
/* mask the old CLK_VAL off and or-in the new value */
- clk_val = CPU_MAX_SPEED cpu_duty_offset;
+ clk_val = (CPU_MAX_SPEED - 1) cpu_duty_offset;
p_cnt = ~clk_val;
p_cnt |= (speed cpu_duty_offset);
Virtually yours,
Taku
--
YAMAMOTO, Taku [EMAIL PROTECTED]
Digital circuits are made from analog parts.
-- Don Vonada
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Melco LPC4-CLX-CB support in 5.0-Current NEWCARD
At Tue, 15 Jan 2002 03:08:53 -0800 (PST), Shizuka Kudo wrote: Dear all, Does anyone have tested whether this card works with current 5.0 NEWCARD? I tried it on a Thinkpad 600X with current 5.0 cvsupped yestersday and received a kernel: found-vendor=0x10ec, dev=0x8138, revid=0x10 (snip) It may work with device rl. (see /sys/pci/if_rlreg.h) -- YAMAMOTO, Taku [EMAIL PROTECTED] Member of Advanced Computer and Communication Studies Society (ACCESS for short), Information Processing Center, Saitama Univ. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
