Re: iwn(4) hangs after r257133
On Sun, Nov 10, 2013 at 02:01:12PM -0800, Adrian Chadd wrote: Yes. So one of the.. unfortunately broken things in iwn is the ampdu tx code doesn't do retransmits. So if amrr picks a rate that fails to transmit everything, the driver doesn't retransmit them. It frees them. Now when amrr is enabled the hardware will retry at lower rates until something succeeds. But it still doesn't retransmit things. I believe it should be. So yes its more broken with Mrr disabled. But enabling mrr doesn't fix it. It just makes it less broken. Someone needs to implement ampdu retransmit. The latest iwn code in head at least tells the rate selection code that a total ampdu tx failure occured. This BTW is one of the hangs I fixed - if you hit a point where you never successfully transmitted an ampdu at a rate the rate would never be decreased. Now to be clear. I won't be in implementing ampdu retransmit. I'll maybe fix last multi rate retry once the new hardware support is in. I would really appreciate help here with these. Everyone with iwn hardware will appreciate it :) In the mean time, wouldn't it make sense to disable ampdu tx in iwn then? Or to disallow the combination Mrr + ampdu? Stefan ___ 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: iwn(4) hangs after r257133
On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ 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: iwn(4) hangs after r257133
On Sun, Nov 10, 2013 at 05:14:58AM -0800, Adrian Chadd wrote: yup, same info as brandon. :) http://pastebin.com/MwfL06z7 Stefan On 10 November 2013 04:17, Stefan Farfeleder stef...@freebsd.org wrote: On Sat, Nov 09, 2013 at 08:29:30PM -0600, Brandon Gooch wrote: Turns out that not enabling MRR causes my Intel Ultimate N WiFi Link 5300 to hang after only a few moments of use. For now, I've just reverted only those aspects of r257133, enabling MRR and keeping the rate index lookup, which seems to do something on my hardware at least (I assume it's not the right thing based on Adrian's analysis, but it works never-the-less). Has anyone else hit this with Intel WiFi hardware? Also, what needs to be done to have MRR working properly? Hi, I have problems with iwn (Intel WiFi Link 5100) as well. Unlike my previous problems, it associates properly and works fine, at first. But then, after some minutes, the link quality somehow deteriorates and I see serious packet drops. Usually it gets back to normal some minutes later, but restarting the interface fixes the problem. I don't think it's a problem with the signal itself, because other devices next to the notebook work just fine during that intervals. Adrian, do you have any ideas, or some data you want from me? Stefan ___ 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: iwn(4) hangs after r257133
On Sun, Nov 10, 2013 at 10:48:48AM -0800, Adrian Chadd wrote: Right near the end there you have 'status 83' which means 'transmit failed, long retry hit' (the status codes are in if_iwnreg.h somewhere.) The retry count hit 16, which is the max set for the frame. rate=80 (hex) is MCS0. So, you're seeing retransmits and failures at MCS0, which is a bad sign. But, notice how AMRR increased it to MCS2 at a couple stages, and that _always_ fails. But AMRR waits for 10 frame transmits before it adjusts the rate up or down. So yes, we do need to enable MRR again on iwn for things to behave better. There are other issues when you start doing larger amounts of traffic but I'll cover those later.what? If someone wants to take a crack at correctly implementing the link quality table stuff again then please let me know. As I said before, the link quality table setup code is mostly sane. The problem is actually correctly setting 'linkq' to start at the selected rate, as linkq is an index into that table, not the initial rate. Hi, after some trial and error I found out that disabling AMPDU makes my iwn0 usable again. Now I actually see the rate as reported by `list sta' going up and down (mostly between 54M and 121M). Before it was always fixed at 135M. Could this be related? Stefan ___ 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 panic on cold boot
I'd like to report that my notebook is now booting fine again with r248646. Stefan ___ 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
sysctl panic on cold boot
Hi, since r247617 my notebook consistently crashes with a page fault when I turn it on. If I then reboot from the debugger, the system will boot just fine. The last known working revision is r247186. I tried backing out r247561 as this last touched kern_sysctl.c, but to no avail. This is on amd64. As can be seen below, gdb isn't really a big help. Does anyone know what's going on? [...] 118Entropy harvesting: interrupts ethernet point_to_point Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x1011e fault code = supervisor read data, page not present instruction pointer = 0x20:0x804a15c0 stack pointer = 0x28:0xff811561c670 frame pointer = 0x28:0xff811561c6e0 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 47 (sysctl) Reading symbols from /boot/kernel/if_iwn.ko...Reading symbols from /boot/kernel/if_iwn.ko.symbols...done. done. Loaded symbols for /boot/kernel/if_iwn.ko Reading symbols from /boot/kernel/iwn5000fw.ko...Reading symbols from /boot/kernel/iwn5000fw.ko.symbols...done. done. Loaded symbols for /boot/kernel/iwn5000fw.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 doadump (textdump=0) at pcpu.h:229 229 pcpu.h: No such file or directory. in pcpu.h (kgdb) bt #0 doadump (textdump=0) at pcpu.h:229 #1 0x802c0bbe in db_dump (dummy=value optimized out, dummy2=0, dummy3=0, dummy4=0x0) at /usr/src/sys/ddb/db_command.c:543 #2 0x802c06ba in db_command (last_cmdp=value optimized out, cmd_table=value optimized out, dopager=1) at /usr/src/sys/ddb/db_command.c:449 #3 0x802c0472 in db_command_loop () at /usr/src/sys/ddb/db_command.c:502 #4 0x802c2dc0 in db_trap (type=value optimized out, code=0) at /usr/src/sys/ddb/db_main.c:231 #5 0x804cad23 in kdb_trap (type=12, code=0, tf=value optimized out) at /usr/src/sys/kern/subr_kdb.c:654 #6 0x806fd1c5 in trap_fatal (frame=0xff811561c5c0, eva=value optimized out) at /usr/src/sys/amd64/amd64/trap.c:867 #7 0x806fd466 in trap_pfault (frame=0x0, usermode=0) at /usr/src/sys/amd64/amd64/trap.c:698 #8 0x806fccba in trap (frame=0xff811561c5c0) at /usr/src/sys/amd64/amd64/trap.c:463 #9 0x806e6eb3 in calltrap () at exception.S:228 #10 0x804a15c0 in sysctl_sysctl_next_ls (lsp=value optimized out, name=0xff811561ca44, namelen=value optimized out, next=0xff811561c85c, len=0xff811561c8c4, level=4) at /usr/src/sys/kern/kern_sysctl.c:745 ---Type return to continue, or q return to quit--- #11 0x804a16ce in sysctl_sysctl_next_ls (lsp=0xfe0002a335b0, name=0xff811561ca40, namelen=value optimized out, next=0xff811561c858, len=0xff811561c8c4, level=3) at /usr/src/sys/kern/kern_sysctl.c:772 #12 0x804a16ce in sysctl_sysctl_next_ls (lsp=0xfe0002a335b0, name=0xff811561ca3c, namelen=value optimized out, next=0xff811561c854, len=0xff811561c8c4, level=2) at /usr/src/sys/kern/kern_sysctl.c:772 #13 0x804a16ce in sysctl_sysctl_next_ls (lsp=0xfe0002a335b0, name=0xff811561ca38, namelen=value optimized out, next=0xff811561c850, len=0xff811561c8c4, level=1) at /usr/src/sys/kern/kern_sysctl.c:772 #14 0x804a1513 in sysctl_sysctl_next (oidp=value optimized out, arg1=0xff811561ca38, arg2=4, req=0xff811561c968) at /usr/src/sys/kern/kern_sysctl.c:794 #15 0x804a090d in sysctl_root (arg1=value optimized out, arg2=value optimized out) at /usr/src/sys/kern/kern_sysctl.c:1493 #16 0x804a0ea8 in userland_sysctl (td=value optimized out, name=0xff811561ca30, namelen=value optimized out, old=value optimized out, oldlenp=value optimized out, inkernel=value optimized out, new=value optimized out, newlen=value optimized out, retval=value optimized out, flags=358730064) at /usr/src/sys/kern/kern_sysctl.c:1603 ---Type return to continue, or q return to quit--- #17 0x804a0c94 in sys___sysctl (td=0xfe0006037920, uap=0xff811561cb40) at /usr/src/sys/kern/kern_sysctl.c:1529 #18 0x806fd88e in amd64_syscall (td=0xfe0006037920, traced=0) at subr_syscall.c:134 #19 0x806e719b in Xfast_syscall () at exception.S:387 #20 0x00080094a30a in ?? () Previous frame inner to this frame (corrupt stack?) Current language: auto; currently minimal (kgdb) f 10 #10 0x804a15c0 in sysctl_sysctl_next_ls (lsp=value optimized out, name=0xff811561ca44,
Re: sysctl panic on cold boot
On Thu, Mar 21, 2013 at 06:00:01AM -0700, Steve Kargl wrote: On Thu, Mar 21, 2013 at 09:28:38AM +0100, Stefan Farfeleder wrote: since r247617 my notebook consistently crashes with a page fault when I turn it on. If I then reboot from the debugger, the system will boot just fine. The last known working revision is r247186. I tried backing out r247561 as this last touched kern_sysctl.c, but to no avail. This is on amd64. As can be seen below, gdb isn't really a big help. Does anyone know what's going on? See the thread started by David Wolfskill, yesterday. Title contains Silent reboots on ... Loaded symbols for /boot/kernel/iwn5000fw.ko Reading symbols from /boot/modules/nvidia.ko...done. Loaded symbols for /boot/modules/nvidia.ko His problem involved loading nvidia.ko. Thanks. I will try booting without nvidia. FWIW, my X and the nvidia driver are working just fine if the system managed to boot. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 11, 2013 at 12:39:44AM +0100, Dimitry Andric wrote: On 2013-01-08 09:58, Stefan Farfeleder wrote: On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: ... After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. your patch seems to work just fine. No crashes whatsoever so far. Thank you. I have committed a slighly cleaned-up version of this hack in r245272, so until this is fixed by upstream, everybody will at least have a correctly functioning libgcc on amd64. Since this issue can potentially also occur on stable/9, I will MFC the fix too, after a few days timeout. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Tue, Jan 08, 2013 at 12:21:12AM +0100, Dimitry Andric wrote: On 2013-01-06 17:03, Stefan Farfeleder wrote: On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: ... The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Can you please try the attached patch, which is a very horrid, atrocious hack, and will only work for amd64. Then rebuild libgcc with clang, and please try if this fixes at least some of the crashes... This is at least the direction I'm looking at. It seems that in some cases with __builtin_eh_return(), llvm does not see that registers can be clobbered, and it doesn't save and restore them. After a lot of splitting up of unwind-dw2.c, I arrived at _Unwind_Resume which when compiled by clang caused the crashes, but when compiled by gcc ran OK. Hi Dimitry, your patch seems to work just fine. No crashes whatsoever so far. Thank you. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 04:51:11PM +, David Chisnall wrote: On 6 Jan 2013, at 16:48, Nathan Whitehorn wrote: No. It's completely broken at all optimization levels. There do not appear to be any flags that change the behavior. Building unwind-dw2.c either with gcc or with the previous import of clang in our tree does fix it, however. Do you have an LLVM PR# for this that I can follow? There's http://llvm.org/bugs/show_bug.cgi?id=8541 which I think should be reopened. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME=libgcc_s.so.1 SHLIBDIR?= /lib +CC=gcc + .include bsd.own.mk # # libgcc is linked in last and thus cannot depend on ssp symbols coming ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Jan 06, 2013 at 03:59:59PM +0100, Dimitry Andric wrote: On 2013-01-06 15:17, Stefan Farfeleder wrote: On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote: Here's a minimal test case that reproduces the bug: [...] Until someone fixes this bug, could we apply something like this as a work-around? Stefan Index: gnu/lib/libgcc/Makefile === --- gnu/lib/libgcc/Makefile (revision 245055) +++ gnu/lib/libgcc/Makefile (working copy) @@ -6,6 +6,8 @@ SHLIB_NAME= libgcc_s.so.1 SHLIBDIR?=/lib +CC=gcc + .include bsd.own.mk I think this is a bit overkill approach. We still don't know what the exact cause of the problem is, and this just papers over it. It seems unwise to install a known-to-be-broken libgcc by default, even though the exact cause is not known yet. Also, ince the bug is only reproducible by compiling the testcase with g++, could you not compile your crashing programs with clang instead, for now? :-) The bug also affects ports software, e.g., I also experienced strange rtorrent segfaults that are now gone. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 10:23:34PM +0200, Konstantin Belousov wrote: Thank you for digging more. In fact, it is more likely that there is some bug or incompatibility in c++ unwinder than in the libgcc itself, but as you noted, a compiler bug is also possible. Anyway, I was mostly looking could the backtrace starts in rtld. Rtld bug also cannot be excluded at this stage, but it not much likely. FWIW, the diff between working and non-working assembler can be found at http://people.freebsd.org/~stefanf/tmp/libgcc_s.s.diff . Not that I expect much from that. Stefan ___ 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
Unbreaking gdb's catch throw
Hi, gdb's command 'catch throw' is broken on FreeBSD head. While it does set a breakpoint on __cxa_throw, the function seems to be never entered when an exception is thrown. Does someone know how to fix this? It used to work a couple of months ago. Stefan ___ 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: Unbreaking gdb's catch throw
On Fri, Jan 04, 2013 at 12:38:44PM +, David Chisnall wrote:
Is this on 9.1? In -CURRENT and 9.1, libstdc++ is a filter library, and
libsupc++ or or libcxxrt are the filtee. This means that the __cxa_throw
symbol appears to be in libstdc++ (for symbol versioning purposes), but is
actually in the ABI library. If you tell gdb to put the breakpoint on
__cxa_throw itself, then it should tell you that there are multiple
definitions and ask which one you want (if it doesn't, it's a gdb bug).
This is on 10.0-CURRENT r244738 amd64. The commands 'b __cxa_throw' and
'catch throw' seemd to be identical, and gdb does not ask about multiple
versions of __cxa_throw.
To be honest, I don't care exactly whose bug it is, I want it to work again :D
$ cat throw.cc
int main(void)
{
throw 1;
}
$ c++ -g throw.cc
$ gdb a.out
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...
(gdb) b main
Breakpoint 1 at 0x4007f9: file throw.cc, line 3.
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw.cc:3
3 throw 1;
(gdb) b __cxa_throw
Breakpoint 2 at 0x800898d34
(gdb) c
Continuing.
terminate called after throwing an instance of 'int'
Program received signal SIGABRT, Aborted.
0x000800e52fca in kill () from /lib/libc.so.7
Stefan
___
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: Unbreaking gdb's catch throw
On Fri, Jan 04, 2013 at 12:54:03PM +, David Chisnall wrote: As a work-around, you can put the breakpoint on _Unwind_RaiseException instead. This will work for any language, not just C++ (e.g. it will notice Objective-C or gcj-compiled Java exceptions). Thank you, that works for me. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Wed, Jan 02, 2013 at 02:59:50PM +0100, Stefan Farfeleder wrote:
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote:
I have been playing with Stefan's testcase for a while now, and while I
can reproduce the crashes, I am still at a loss about the cause. It
does seem to have something to do with throwing exceptions, but I am
still not sure whether I am looking at a bug in boost, gcc, clang, or
libgcc...
Do you happen to have a smaller testcase, by any chance?
Not yet, but I'll try to come up with something smaller.
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Fri, Jan 04, 2013 at 08:14:38PM +0200, Konstantin Belousov wrote:
On Fri, Jan 04, 2013 at 04:49:41PM +0100, Stefan Farfeleder wrote:
Here's a minimal test case that reproduces the bug:
$ cat throw-crash.cc
#include stdexcept
void f2(void) {
std::string s;
throw std::runtime_error(foo);
}
void f1(void) {
f2();
}
int main(void) {
try {
std::string s1, s2;
f1();
return 0;
} catch (const std::exception ) {
return 1;
}
}
$ g++ -O2 -finline-limit=0 throw-crash.cc
$ ./a.out
zsh: bus error (core dumped) ./a.out
What is the backtrace ?
Compile the system libraries (ld-elf, libc, libgcc etc) with the
debugging information and obtain the backtrace once more.
I'm afraid the backtrace is not really interesting:
Program received signal SIGBUS, Bus error.
std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
69 _Atomic_word __result = *__mem;
(gdb) bt
#0 std::string::_Rep::_M_dispose (this=0x7fffd62fe8, __a=@0x7fffd628)
at atomicity.h:69
#1 0x00080089d168 in ~basic_string (this=0x7fffd62fe8)
at basic_string.h:482
#2 0x00401038 in main () at throw-crash.cc:16
I think the stack is somehow corrupted after the exception was
performed. As with the original test case, loading an old libgcc_s.so.1
instead makes the program run correctly.
It seems the std::string destructor is called with an invalid this
pointer for s2:
(gdb) r
Starting program: /usr/home/stefan/scratch/a.out
Breakpoint 1, main () at throw-crash.cc:12
12 int main(void) {
(gdb) b _Unwind_RaiseException
Breakpoint 2 at 0x800d420b4
(gdb) c
Continuing.
Breakpoint 2, 0x000800d420b4 in _Unwind_RaiseException ()
from /lib/libgcc_s.so.1
(gdb) f 2
#2 0x00400f51 in f2 () at throw-crash.cc:5
5 throw std::runtime_error(foo);
(gdb) p s
$1 = (string *) 0x7fffd600
(gdb) up
#3 0x00400fe2 in main () at throw-crash.cc:15
15 f1();
(gdb) p s1
$2 = (string *) 0x7fffd650
(gdb) p s2
$3 = (string *) 0x7fffd640
(gdb) b 'std::basic_stringchar, std::char_traitschar, std::allocatorchar
::~basic_string()'
Breakpoint 3 at 0x80089d154: file basic_string.h, line 482.
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd600) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd640) at basic_string.h:279
279 _M_data() const
(gdb) c
Continuing.
Breakpoint 3, ~basic_string (this=0x7fffd60f) at basic_string.h:279
279 _M_data() const
So, the address of s2 is 0x7fffd640, but the dtor is called with
0x7fffd60f which is also very unaligned. I think this is the reason
for the crash.
Stefan
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: clang 3.2 RC2 miscompiles libgcc?
On Sun, Dec 30, 2012 at 11:17:10PM +0100, Dimitry Andric wrote: I have been playing with Stefan's testcase for a while now, and while I can reproduce the crashes, I am still at a loss about the cause. It does seem to have something to do with throwing exceptions, but I am still not sure whether I am looking at a bug in boost, gcc, clang, or libgcc... Do you happen to have a smaller testcase, by any chance? Not yet, but I'll try to come up with something smaller. Stefan ___ 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
clang 3.2 RC2 miscompiles libgcc?
Hi,
I noticed that most of my C++ applications in recent versions of FreeBSD
head suddenly crash without me recompiling them. I tracked it down to
r243830 which imported a new clang version. The new clang seems to
compile libgcc in a wrong or at least incompatible way with what gcc
expects. In fact, the breakage only occurs with libgcc compiled by a
post-r243830 clang and an application compiled with g++ -O2. For me, the
crash happens with boost::program_options, but I'm not sure if that is
necessary for the crash.
$ cat po.cc
#include boost/program_options.hpp
int main(void) {
namespace po = boost::program_options;
const char *argv[] = { a.out, -x, 0 };
po::options_description options(Options);
options.add_options()(bla, );
try {
po::variables_map vm;
po::store(po::parse_command_line(2, argv, options), vm);
notify(vm);
return 0;
} catch (const std::exception ex) {
return 1;
}
}
$ g++ -O2 -I /usr/local/include -L /usr/local/lib -lboost_program_options po.cc
$ ./a.out
zsh: segmentation fault (core dumped) ./a.out
$ ldd ./a.out
./a.out:
libboost_program_options.so =
/usr/local/lib/libboost_program_options.so (0x800821000)
libstdc++.so.6 = /usr/lib/libstdc++.so.6 (0x800a7e000)
libm.so.5 = /lib/libm.so.5 (0x800d7c000)
libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x800f9e000)
libc.so.7 = /lib/libc.so.7 (0x8011ab000)
libthr.so.3 = /lib/libthr.so.3 (0x801523000)
$ ls /usr/home/stefan/scratch/r243829
libgcc_s.so.1
$ LD_LIBRARY_PATH=/usr/home/stefan/scratch/r243829 ./a.out
$ valgrind ./a.out
==47491== Memcheck, a memory error detector
==47491== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==47491== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==47491== Command: ./a.out
==47491==
==47491== Invalid read of size 8
==47491==at 0x405DAA: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x2800ef8 is 24 bytes inside a block of size 27 alloc'd
==47491==at 0x1009FB6: malloc (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==47491==by 0x213F95A: operator new(unsigned long) (in
/usr/lib/libsupc++.so.1)
==47491==by 0x14F08D2: ??? (in /usr/lib/libstdc++.so.6)
==47491==by 0x14EDCFD: std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string(std::string const, unsigned long,
unsigned long) (in /usr/lib/libstdc++.so.6)
==47491==by 0x1234B12:
boost::program_options::detail::cmdline::parse_short_option(std::vectorstd::string,
std::allocatorstd::string ) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x123843A:
boost::detail::function::function_obj_invoker1boost::_bi::bind_tstd::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
boost::_mfi::mf1std::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
boost::program_options::detail::cmdline, std::vectorstd::string,
std::allocatorstd::string ,
boost::_bi::list2boost::_bi::valueboost::program_options::detail::cmdline*,
boost::arg1 , std::vectorboost::program_options::basic_optionchar,
std::allocatorboost::program_options::basic_optionchar ,
std::vectorstd::string, std::allocatorstd::string
::invoke(boost::detail::function::function_buffer, std::vectorstd::string,
std::allocatorstd::string ) (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x12367C1: boost::program_options::detail::cmdline::run() (in
/usr/local/lib/libboost_program_options.so.4)
==47491==by 0x4051D5:
boost::program_options::basic_command_line_parserchar::run() (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x405B7A: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491==
==47491== Jump to the invalid address stated on the next line
==47491==at 0x782D: ???
==47491==by 0x405DBF: boost::program_options::basic_parsed_optionschar
boost::program_options::parse_command_linechar(int, char const* const*,
boost::program_options::options_description const, int,
boost::function1std::pairstd::string, std::string, std::string const) (in
/usr/home/stefan/scratch/a.out)
==47491==by 0x401E7D: main (in /usr/home/stefan/scratch/a.out)
==47491== Address 0x782d is not stack'd, malloc'd or (recently) free'd
Re: clang 3.2 RC2 miscompiles libgcc?
On Thu, Dec 27, 2012 at 09:15:01AM -0600, Nathan Whitehorn wrote: On 12/27/12 09:07, Stefan Farfeleder wrote: Hi, I noticed that most of my C++ applications in recent versions of FreeBSD head suddenly crash without me recompiling them. I tracked it down to r243830 which imported a new clang version. The new clang seems to compile libgcc in a wrong or at least incompatible way with what gcc expects. In fact, the breakage only occurs with libgcc compiled by a post-r243830 clang and an application compiled with g++ -O2. For me, the crash happens with boost::program_options, but I'm not sure if that is necessary for the crash. I've seen what I think is the same thing due to a miscompilation of unwind-dw2.c that caused crashes related to cross-shared-object exception handling. It seems to have been fixed with the 3.2 release but I haven't tested it too thoroughly yet. Thanks for the confirmation. The cross-dso requirement would explain why my simpler approaches to reproduce it didn't work. But for me there's no difference between RC2 and release (FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221), both cause my applications to crash. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Clang as default compiler November 4th
On Thu, Sep 13, 2012 at 09:10:24AM -0700, Steve Kargl wrote: clang -O2 -pipe -march=opteron -O0 -lm test-cexp.c -o test-cexp test-cexp.c:49:14: warning: pragma STDC FENV_ACCESS ON is not supported, ignoring pragma [-Wunknown-pragmas] #pragma STDC FENV_ACCESSON [...] So, clang does not support #pragma STDC FENV_ACCESS ON. That (IMHO) is a show stopper for clang as the default compiler, because at least msun/src/e_sqrtl.c uses this pragma. Neither does gcc, AFAIK (http://gcc.gnu.org/c99status.html). It just silently ignores the pragma. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Tue, May 08, 2012 at 03:59:42PM -0700, Jason Evans wrote: On May 8, 2012, at 2:58 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote: On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Was the assertion failure easily reproducible with inkscape? Yes, it crashed everytime before showing the GUI. The backtrace goes like this: [snip] sbrk() is being used rather than mmap(). Unless mmap() is failing (which would surprise me), this indicates that you are using a version of libc that's old enough to have the bug I fixed in r234569. I'm afraid the backtrace was somehow corrupted. Here's a new one from a libc compiled with -g: (gdb) bt #0 0x00080ad760ac in thr_kill () at thr_kill.S:3 #1 0x00080ae22548 in abort () at /usr/src/lib/libc/stdlib/abort.c:77 #2 0x00080ad9f57d in arena_chunk_validate_zeroed (chunk=0x188d3, run_ind=6) at jemalloc_arena.c:182 #3 0x00080ada1c51 in arena_run_split (arena=0x8104000c0, run=Variable run is not available. ) at jemalloc_arena.c:318 #4 0x00080ada3624 in arena_run_alloc (arena=0x8104000c0, size=4096, large=false, zero=false) at jemalloc_arena.c:524 #5 0x00080ada3ffc in arena_bin_malloc_hard (arena=0x8104000c0, bin=0x810400298) at jemalloc_arena.c:1128 #6 0x00080ada432d in __jemalloc_arena_tcache_fill_small (arena=0x8104000c0, tbin=0x810806068, binind=2, prof_accumbytes=Variable prof_accumbytes is not available. ) at jemalloc_arena.c:1250 #7 0x00080ad9394f in __jemalloc_tcache_alloc_small_hard (tcache=Variable tcache is not available. ) at jemalloc_tcache.c:32 #8 0x00080ad93d70 in __jemalloc_tcache_alloc_small (tcache=0x810806000, size=32, zero=false) at tcache.h:340 #9 0x00080ada73a0 in malloc (size=32) at jemalloc_jemalloc.c:807 #10 0x00080a6a283d in operator new () from /usr/lib/libstdc++.so.6 #11 0x000803300dcf in sigc::internal::trackable_callback_list::add_callback () from /usr/local/lib/libsigc-2.0.so.0 #12 0x007a5664 in sp_style_new_from_object () Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote: On 05/08/12 00:46, Jason Evans wrote: How recent is your system? This problem should have been fixed by r234569, so if you're still seeing problems after that revision, there's another problem we need to figure out. (By the way, it's possible for an application to trigger this assertion, but unlikely.) My system is r235115. I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Stefan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: jemalloc: jemalloc_arena.c:182: Failed assertion: p[i] == 0
On Tue, May 08, 2012 at 02:47:59PM -0700, Jason Evans wrote: On May 8, 2012, at 2:37 PM, Stefan Farfeleder wrote: On Tue, May 08, 2012 at 12:48:17PM -0400, Steve Wills wrote: On 05/08/12 00:46, Jason Evans wrote: How recent is your system? This problem should have been fixed by r234569, so if you're still seeing problems after that revision, there's another problem we need to figure out. (By the way, it's possible for an application to trigger this assertion, but unlikely.) My system is r235115. I hit the same assertion with r235052 and inkscape. I'm now using MALLOC_PRODUCTION and it works again. Was the assertion failure easily reproducible with inkscape? Yes, it crashed everytime before showing the GUI. The backtrace goes like this: (gdb) bt #0 0x00080ad760ac in thr_kill () from /lib/libc.so.7 #1 0x00080ae22548 in abort () from /lib/libc.so.7 #2 0x00080ad9f57d in sbrk () from /lib/libc.so.7 #3 0x00080ada1c51 in sbrk () from /lib/libc.so.7 #4 0x00080ada3624 in sbrk () from /lib/libc.so.7 #5 0x00080ada3ffc in sbrk () from /lib/libc.so.7 #6 0x00080ada432d in sbrk () from /lib/libc.so.7 #7 0x00080ad9394f in syscall () from /lib/libc.so.7 #8 0x00080ad93d70 in syscall () from /lib/libc.so.7 #9 0x00080ada73a0 in malloc () from /lib/libc.so.7 #10 0x00080a6a283d in operator new () from /usr/lib/libstdc++.so.6 #11 0x007af660 in sigc::internal::typed_slot_repsigc::bind_functor-1, sigc::pointer_functor3SPObject*, SPObject*, SPStyle*, void, SPStyle*, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil, sigc::nil ::dup () #12 0x0008033016b4 in sigc::slot_base::slot_base () from /usr/local/lib/libsigc-2.0.so.0 #13 0x006f0a77 in std::listsigc::slot_base, std::allocatorsigc::slot_base ::insert () #14 0x00080330084a in sigc::internal::signal_impl::insert () from /usr/local/lib/libsigc-2.0.so.0 #15 0x000803300893 in sigc::internal::signal_impl::connect () from /usr/local/lib/libsigc-2.0.so.0 #16 0x000803300a44 in sigc::signal_base::connect () #17 0x007a8635 in SPIPaint::read () [...] Stefan ___ 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
da0 takes a long time to appear
Hi, I recently had to replace the enclosure of an external USB harddisk (WD E1U1E Elements). With the new one (Trekstor DataStation maxi n.u 3,5), it now takes over one minute between the detection of umass0 and da0. After that it works fine. Is this delay due to the hardware or is the kernel at fault? Any debug information I should provide? I'm running head r234133. Apr 16 14:43:35 mole kernel: ugen7.2: TrekStor at usbus7 Apr 16 14:43:35 mole kernel: umass0: Bulk Only Interface on usbus7 Apr 16 14:44:49 mole kernel: da0 at umass-sim0 bus 0 scbus6 target 0 lun 0 Apr 16 14:44:49 mole kernel: da0: TrekStor DS maxi m.u\00092\000H 100 Fixed Direct Access SCSI-2 device Apr 16 14:44:49 mole kernel: da0: 40.000MB/s transfers Apr 16 14:44:49 mole kernel: da0: 953869MB (1953525168 512 byte sectors: 255H 63S/T 121601C) Stefan ___ 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: recent update breaks some ports
On Wed, Apr 11, 2012 at 11:27:55PM +0200, Stefan Farfeleder wrote: On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov 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: 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. Attaching gdb to a hanging evince process yields this: Sorry, I forgot that make install strips debug info. Here are the traces with actual debug info: 0x000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x000807f7c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x000807f72431 in __thr_rwlock_wrlock (rwlock=Variable rwlock is not available. ) at /usr/src/lib/libthr/thread/thr_umtx.c:296 #2 0x000807f78473 in _thr_rtld_wlock_acquire (lock=0x808189b00) at thr_umtx.h:194 #3 0x0008006676a9 in wlock_acquire (lock=0x800877760, lockstate=0x7f5fa570) at /usr/src/libexec/rtld-elf/rtld_lock.c:213 #4 0x000800664a6e in dlopen_object (name=0x80ac87632 libsupc++.so.1, fd=-1, refobj=0x8007e2400, lo_flags=0, mode=1) at /usr/src/libexec/rtld-elf/rtld.c:2517 #5 0x000800664e2c in load_filtee1 (obj=0x8007e2400, needed=0x8007e1b80, flags=0) at /usr/src/libexec/rtld-elf/rtld.c:1679 #6 0x000800664e86 in load_filtees (obj=0x8007e2400, flags=0, lockstate=Variable lockstate is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:1692 #7 0x0008006651bb in symlook_obj (req=0x7f5fa720, obj=0x8007e2400) at /usr/src/libexec/rtld-elf/rtld.c:3421 #8 0x000800665337 in symlook_list (req=0x7f5fa7a0, objlist=Variable objlist is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:3335 #9 0x000800665521 in symlook_global (req=0x7f5faaf0, donelist=0x7f5faa90) at /usr/src/libexec/rtld-elf/rtld.c:3247 #10 0x0008006658ef in symlook_default (req=0x7f5faaf0, refobj=0x8007e0c00) at /usr/src/libexec/rtld-elf/rtld.c:3286 #11 0x000800665bed in find_symdef (symnum=266, refobj=0x8007e0c00, defobj_out=0x7f5fab90, flags=0, cache=0x80079a000, lockstate=0x7f5fac30) at /usr/src/libexec/rtld-elf/rtld.c:1416 #12 0x00080066065b in reloc_non_plt (obj=0x8007e0c00, obj_rtld=Variable obj_rtld is not available. ) at /usr/src/libexec/rtld-elf/amd64/reloc.c:155 #13 0x0008006634e7 in relocate_objects (first=Variable first is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:2185 #14 0x000800664c96 in dlopen_object (name=0x80a497100 /usr/local/lib/evince/3/backends/libpdfdocument.so, fd=Variable fd is not available. ) at /usr/src/libexec/rtld-elf/rtld.c:2543 #15 0x0008006657b4 in rtld_dlopen (name=0x80a497100 /usr/local/lib/evince/3/backends/libpdfdocument.so, fd=-1, mode=258) at /usr/src/libexec/rtld-elf/rtld.c:2491 #16 0x000806ba376b in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #17 0x000800cb5097 in ev_module_get_path () from /usr/local/lib/libevdocument.so.3 #18 0x000806dd866c in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.0 #19 0x000800cac949 in ev_backends_manager_get_document () from /usr/local/lib/libevdocument.so.3 #20 0x000800cb13f5 in ev_document_factory_add_filters () from /usr/local/lib/libevdocument.so.3 #21 0x000800cb15d4 in ev_document_factory_get_document () from /usr/local/lib/libevdocument.so.3 #22 0x000800ee77b9 in ev_job_load_new () from /usr/local/lib/libevview.so.3 #23 0x000800ee90f5 in ev_job_scheduler_push_job () from /usr/local/lib/libevview.so.3 #24 0x000807259274 in g_thread_create_full () from /usr/local/lib/libglib-2.0.so.0 #25 0x000807f70cdd in thread_start (curthread=0x808f1e400) at /usr/src/lib/libthr/thread/thr_create.c:284 #26 0x in ?? () Error accessing memory address 0x7f5fb000: Bad address. and: 0x000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 37 RSYSCALL_ERR(_umtx_op) (gdb) bt #0 0x000802e3c9ac in _umtx_op_err () at /usr/src/lib/libthr/arch/amd64/amd64/_umtx_op_err.S:37 #1 0x000802e3262f in _thr_umtx_timedwait_uint (mtx=Variable mtx is not available. ) at /usr/src/lib/libthr/thread/thr_umtx.c:212 #2 0x000802e3b09d in cond_wait_common (cond=Variable cond is not available. ) at /usr/src/lib/libthr/thread/thr_cond.c:243 #3 0x000800bfbf23 in metronom_sync_loop (this_gen=Variable this_gen is not available. ) at metronom.c:871 #4 0x000802e30cdd in thread_start (curthread=0x804c0b400) at /usr/src/lib/libthr/thread/thr_create.c:284 #5 0x in ?? () Error accessing memory address 0x7f7fc000: Bad address. Stefan
Re: recent update breaks some ports
On Thu, Apr 12, 2012 at 01:39:28PM +0300, Konstantin Belousov wrote: On Thu, Apr 12, 2012 at 09:12:50AM +0200, Stefan Farfeleder wrote: On Wed, Apr 11, 2012 at 11:27:55PM +0200, Stefan Farfeleder wrote: On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov 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: 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. Attaching gdb to a hanging evince process yields this: [snip] This is supposedly fixed by r234170. Thanks, works for me! ___ 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: recent update breaks some ports
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. Stefan ___ 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: recent update breaks some ports
On Wed, Apr 11, 2012 at 03:53:38PM +0300, Konstantin Belousov 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: 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. Attaching gdb to a hanging evince process yields this: (gdb) bt #0 0x000807f7c9ac in __error () from /lib/libthr.so.3 #1 0x000807f72431 in pthread_getschedparam () from /lib/libthr.so.3 #2 0x000807f78473 in pthread_kill () from /lib/libthr.so.3 #3 0x0008006676a9 in _rtld_thread_init () from /libexec/ld-elf.so.1 #4 0x000800664a6e in dlclose () from /libexec/ld-elf.so.1 #5 0x000800664e2c in dlclose () from /libexec/ld-elf.so.1 #6 0x000800664e86 in dlclose () from /libexec/ld-elf.so.1 #7 0x0008006651bb in dlclose () from /libexec/ld-elf.so.1 #8 0x000800665337 in dlclose () from /libexec/ld-elf.so.1 #9 0x000800665521 in dlclose () from /libexec/ld-elf.so.1 #10 0x0008006658ef in dlopen () from /libexec/ld-elf.so.1 #11 0x000800665bed in dlopen () from /libexec/ld-elf.so.1 #12 0x00080066065b in __tls_get_addr () from /libexec/ld-elf.so.1 #13 0x0008006634e7 in _rtld_addr_phdr () from /libexec/ld-elf.so.1 #14 0x000800664c96 in dlclose () from /libexec/ld-elf.so.1 #15 0x0008006657b4 in dlclose () from /libexec/ld-elf.so.1 #16 0x000806ba376b in g_module_open () from /usr/local/lib/libgmodule-2.0.so.0 #17 0x000800cb5097 in ev_module_get_path () from /usr/local/lib/libevdocument.so.3 #18 0x000806dd866c in g_type_module_use () from /usr/local/lib/libgobject-2.0.so.0 #19 0x000800cac949 in ev_backends_manager_get_document () from /usr/local/lib/libevdocument.so.3 #20 0x000800cb13f5 in ev_document_factory_add_filters () from /usr/local/lib/libevdocument.so.3 #21 0x000800cb15d4 in ev_document_factory_get_document () from /usr/local/lib/libevdocument.so.3 #22 0x000800ee77b9 in ev_job_load_new () from /usr/local/lib/libevview.so.3 #23 0x000800ee90f5 in ev_job_scheduler_push_job () from /usr/local/lib/libevview.so.3 #24 0x000807259274 in g_thread_create_full () from /usr/local/lib/libglib-2.0.so.0 #25 0x000807f70cdd in pthread_create () from /lib/libthr.so.3 #26 0x in ?? () Error accessing memory address 0x7f5fb000: Bad address. For xine it's this: (gdb) bt #0 0x000802e3c9ac in __error () from /lib/libthr.so.3 #1 0x000802e3262f in pthread_getschedparam () from /lib/libthr.so.3 #2 0x000802e3b09d in pthread_cond_signal () from /lib/libthr.so.3 #3 0x000800bfbf23 in metronom_sync_loop (this_gen=Variable this_gen is not available. ) at metronom.c:871 #4 0x000802e30cdd in pthread_create () from /lib/libthr.so.3 #5 0x in ?? () Error accessing memory address 0x7f7fc000: Bad address. I hope this helps. Stefan ___ 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: recent update breaks some ports
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). Stefan ___ 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
eventtimers hiccups
Hi, since the new eventtimers code was committed, my notebook (Dell Precision m4400) sometimes hangs for 10-30 seconds, mostly during load. In these periods I can move the mouse pointer but time (as perceived by time(1)) seems to be halted. This is accompanied by lots of calcru: runtime went backwards message, though sometimes they only show up when shutting down. I now set kern.eventtimer.periodic=1 and have not experienced such freezes since then. But it would be nice if the default settigs would work. Is there something I could do to help fixing this? BTW, I'm not using powerd. sysctl kern.eventtimer gives this output: kern.eventtimer.choice: HPET(450) HPET1(440) HPET2(440) HPET3(440) LAPIC(400) i8254(100) RTC(0) kern.eventtimer.et.LAPIC.flags: 15 kern.eventtimer.et.LAPIC.frequency: 0 kern.eventtimer.et.LAPIC.quality: 400 kern.eventtimer.et.HPET.flags: 3 kern.eventtimer.et.HPET.frequency: 14318180 kern.eventtimer.et.HPET.quality: 450 kern.eventtimer.et.HPET1.flags: 3 kern.eventtimer.et.HPET1.frequency: 14318180 kern.eventtimer.et.HPET1.quality: 440 kern.eventtimer.et.HPET2.flags: 3 kern.eventtimer.et.HPET2.frequency: 14318180 kern.eventtimer.et.HPET2.quality: 440 kern.eventtimer.et.HPET3.flags: 3 kern.eventtimer.et.HPET3.frequency: 14318180 kern.eventtimer.et.HPET3.quality: 440 kern.eventtimer.et.RTC.flags: 17 kern.eventtimer.et.RTC.frequency: 32768 kern.eventtimer.et.RTC.quality: 0 kern.eventtimer.et.i8254.flags: 1 kern.eventtimer.et.i8254.frequency: 1193182 kern.eventtimer.et.i8254.quality: 100 kern.eventtimer.periodic: 1 kern.eventtimer.timer: HPET kern.eventtimer.idletick: 0 kern.eventtimer.singlemul: 2 Cheers, Stefan Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 9.0-CURRENT #41 r216198: Sun Dec 5 14:02:37 CET 2010 ste...@mole.fafoe.narf.at:/usr/obj/usr/src/sys/MOLE amd64 CPU: Intel(R) Core(TM)2 Duo CPU T9600 @ 2.80GHz (2793.06-MHz K8-class CPU) Origin = GenuineIntel Id = 0x1067a Family = 6 Model = 17 Stepping = 10 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x408e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,XSAVE AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 4294967296 (4096 MB) avail memory = 4036313088 (3849 MB) Event timer LAPIC quality 400 ACPI APIC Table: DELL M09 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: DELL M09 on motherboard Timecounter HPET frequency 14318180 Hz quality 900 Event timer HPET frequency 14318180 Hz quality 450 Event timer HPET1 frequency 14318180 Hz quality 440 Event timer HPET2 frequency 14318180 Hz quality 440 Event timer HPET3 frequency 14318180 Hz quality 440 acpi0: reservation of 0, 9f000 (3) failed acpi0: reservation of 10, df351c00 (3) failed Timecounter ACPI-fast frequency 3579545 Hz quality 1000 acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_ec0: Embedded Controller: GPE 0x11 port 0x930,0x934 on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xdf00-0xdf7f mem 0xf500-0xf5ff,0xe000-0xefff,0xf200-0xf3ff irq 16 at device 0.0 on pci1 pci0: simple comms at device 3.0 (no driver attached) atapci0: Intel ATA controller port 0xef78-0xef7f,0xef70-0xef73,0xef80-0xef87,0xef74-0xef77,0xef90-0xef9f irq 18 at device 3.2 on pci0 ata2: ATA channel 0 on atapci0 ata3: ATA channel 1 on atapci0 pci0: simple comms, UART at device 3.3 (no driver attached) em0: Intel(R) PRO/1000 Network Connection 7.1.8 port 0xefe0-0xefff mem 0xf6fe-0xf6ff,0xf6fdb000-0xf6fdbfff irq 22 at device 25.0 on pci0 em0: Using an MSI interrupt em0: Ethernet address: 00:24:e8:e4:17:93 uhci0: Intel 82801I (ICH9) USB controller port 0x6f60-0x6f7f irq 20 at device 26.0 on pci0 usbus0: Intel 82801I (ICH9) USB controller on uhci0 uhci1: Intel 82801I (ICH9) USB controller port 0x6f80-0x6f9f irq 21 at device 26.1 on pci0 usbus1: Intel 82801I (ICH9) USB controller on uhci1 uhci2: Intel 82801I (ICH9) USB controller port 0x6fa0-0x6fbf irq 22 at device 26.2 on pci0 usbus2: Intel 82801I (ICH9) USB controller on uhci2 ehci0: Intel 82801I (ICH9) USB 2.0 controller mem 0xfed1c400-0xfed1c7ff irq 22 at device 26.7 on pci0 usbus3: EHCI version 1.0 usbus3: Intel 82801I (ICH9) USB 2.0 controller on ehci0 hdac0: Intel 82801I High Definition
Re: eventtimers hiccups
On Fri, Dec 24, 2010 at 04:49:50PM +0200, Alexander Motin wrote:
Have you tried to look on what happens with your HPET interrupts during
the problem? Is it timer hardware/driver problem, or something else?
Have you tried to use LAPIC timer? - it has no race window between start
and completion that may potentially stop HPET timer in some situations.
Have you tried to enable kern.eventtimer.idletick?
The best diagnostic would be to get KTR dump at the moment when problem
begins. You should build kernel with
options KTR
options ALQ
options KTR_ALQ
options KTR_COMPILE=(KTR_SPARE2)
options KTR_ENTRIES=131072
options KTR_MASK=(KTR_SPARE2)
and as soon as problem begins (before logs wrapped) you should run
`ktrdump -c -o dump`.
Also you may try in file acpi_hpet.c change line
if (fdiv 5000) {
to the
if (fdiv 5) {
.
Hi Alexander,
thanks for your suggestions. I'll try them out and report then. It might
take some time though.
Stefan
___
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: calcru: runtime went backwards
On Sat, Oct 30, 2010 at 03:19:04PM -0400, David Rhodus wrote: I haven't seen much of this since 5.x days. Anyone else see calcru messages lately ? Yes, I am seeing those as well in the last weeks, accompanied with sporadic hangs of a few seconds. For now I've been to lazy to investigate further, but I assume it's somehow connected to recent timecounter changes. Stefan ___ 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] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: From: Jacques A. Vidrine [EMAIL PROTECTED] The application is broken. You must only check errno if you get an error indication from the library call. errno is only meaningful after a syscall error. Wrong, counter-example: strtol(). Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] libc_r bug: successful close(2) sets errno to ENOTTY
On Mon, Nov 24, 2003 at 03:33:49PM -0700, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Stefan Farfeleder [EMAIL PROTECTED] writes: : On Mon, Nov 24, 2003 at 07:05:02PM +0100, boyd, rounin wrote: : From: Jacques A. Vidrine [EMAIL PROTECTED] : The application is broken. You must only check errno if you get an : error indication from the library call. : : errno is only meaningful after a syscall error. : : Wrong, counter-example: strtol(). errno is meaningful for syscalls after an error (the original message). The fact that other functions also dink with errno is not relevant to that statement. I read boyd's statement as a contradiction to Jacques' one (only after syscall error vs. after library call error). If that's a misinterpretation, I'm sorry. Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: Assertion td-td_turnstile != NULL failed
Hi,
this panic just happened on an i386 SMP box that was idle except for
generating tons of checking stopevent 2 with the following
non-sleepable locks held messages. Its sources are are just a few
hours old.
%%
checking stopevent 2 with the following non-sleepable locks held:
exclusive sleep mutex sigacts r = 0 (0xc6b6caa8) locked @
/freebsd/frog/src/sys/kern/subr_trap.c:260
panic: Assertion td-td_turnstile != NULL failed at
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
cpuid = 0;
Debugger(panic)
Stopped at Debugger+0x4e: xchgl %ebx,in_Debugger.0
db t
Debugger(c070b63e,0,c070ab4a,e041ca58,100) at Debugger+0x4e
panic(c070ab4a,c070e631,c070e401,1b5,c0793a40) at panic+0x148
turnstile_wait(c6938240,c078f4a0,c68bc140,1cc,c078f4a0) at turnstile_wait+0x29c
_mtx_lock_sleep(c078f4a0,0,c0723748,df,c29a8b04) at _mtx_lock_sleep+0x111
_mtx_lock_flags(c078f4a0,0,c0723748,df,bf80) at _mtx_lock_flags+0x98
vm_fault(c078be80,0,2,8,c29a9780) at vm_fault+0x5a
trap_pfault(e041cc2c,0,0,e041cc1c,0) at trap_pfault+0xf6
trap(18,10,10,0,e041cca8) at trap+0x2f3
calltrap() at calltrap+0x5
--- trap 0xc, eip = 0xc06babb3, esp = 0xe041cc6c, ebp = 0xe041cc90 ---
intr_execute_handlers(c07782a4,e041cca8,e041ccec,c06ccc4e,7) at
intr_execute_handlers+0x23
atpic_handle_intr(7) at atpic_handle_intr+0x41
Xatpic_intr7() at Xatpic_intr7+0x1e
--- interrupt, eip = 0xc06befe5, esp = 0xe041ccec, ebp = 0xe041ccec ---
cpu_idle_default(e041cd14,c0528bcc,c078f4a0,2,c07092f6) at cpu_idle_default+0x5
cpu_idle(c078f4a0,2,c07092f6,53,c0528b90) at cpu_idle+0x28
idle_proc(0,e041cd48,c070919e,311,0) at idle_proc+0x3c
fork_exit(c0528b90,0,e041cd48) at fork_exit+0xb4
fork_trampoline() at fork_trampoline+0x8
--- trap 0x1, eip = 0, esp = 0xe041cd7c, ebp = 0 ---
db call doadump
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
Dump complete
0xf
db r
cpu_reset called on cpu#0
%%
GDB tells this:
%%
GNU gdb 5.2.1 (FreeBSD)
Copyright 2002 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 i386-undermydesk-freebsd...
panic: Assertion td-td_turnstile != NULL failed at
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
panic messages:
---
panic: Assertion td-td_turnstile != NULL failed at
/freebsd/frog/src/sys/kern/subr_turnstile.c:437
cpuid = 0;
Dumping 1023 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 464 480 496 512 528 544 560 576 592 608 624 640 656 672 688 704
720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 992 1008
---
#0 doadump () at /freebsd/frog/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) bt
#0 doadump () at /freebsd/frog/src/sys/kern/kern_shutdown.c:240
#1 0xc046ea8d in db_fncall (dummy1=1016, dummy2=0, dummy3=331,
dummy4=0xe041c894 ) at /freebsd/frog/src/sys/ddb/db_command.c:548
#2 0xc046e82a in db_command (last_cmdp=0xc077c140, cmd_table=0x0,
aux_cmd_tablep=0xc072fe2c, aux_cmd_tablep_end=0xc072fe30)
at /freebsd/frog/src/sys/ddb/db_command.c:346
#3 0xc046e938 in db_command_loop ()
at /freebsd/frog/src/sys/ddb/db_command.c:472
#4 0xc0471679 in db_trap (type=3, code=0)
at /freebsd/frog/src/sys/ddb/db_trap.c:73
#5 0xc06b5343 in kdb_trap (type=3, code=0, regs=0xe041c9d4)
at /freebsd/frog/src/sys/i386/i386/db_interface.c:171
#6 0xc06c9eae in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1066357942, tf_esi = 1, tf_ebp =
-532559328, tf_isp = -532559360, tf_ebx = 0, tf_edx = 0, tf_ecx = 1, tf_eax = 18,
tf_trapno = 3, tf_err = 0, tf_eip = -1066707410, tf_cs = 8, tf_eflags = 134, tf_esp =
-1066237866, tf_ss = -1066355138})
at /freebsd/frog/src/sys/i386/i386/trap.c:580
#7 0xc06b6c48 in calltrap () at {standard input}:94
#8 0xc053cd18 in panic (fmt=0xc070ab4a Assertion %s failed at %s:%d)
at /freebsd/frog/src/sys/kern/kern_shutdown.c:534
#9 0xc0561a6c in turnstile_wait (ts=0xc6938240, lock=0xc078f4a0,
owner=0xc68bc140) at /freebsd/frog/src/sys/kern/subr_turnstile.c:469
---Type return to continue, or q return to quit---
#10 0xc05338a1 in _mtx_lock_sleep (m=0xc078f4a0, opts=0,
file=0xc0723748 /freebsd/frog/src/sys/vm/vm_fault.c, line=223)
at /freebsd/frog/src/sys/kern/kern_mutex.c:476
#11 0xc0533458 in _mtx_lock_flags (m=0xc078f4a0,
Re: ifconfig bug
On Sat, Nov 15, 2003 at 11:54:20AM -0800, Lars Eggert wrote: shouldn't this work? # ifconfig em0 inet 128.9.168.58 netmask 255.255.240.0 \ ether 00:07:e9:0a:26:52 ifconfig: ether: bad value This is with today's -current, but this may have been around longer - I hadn't tried it before today. Using two commands to set MAC and IP addresses works fine, but it needs to be one command for rc.conf. ifconfig accepts only one value for the address family per invocation, you can't mix inet and ether. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 06:01:34PM +1100, Bruce Evans wrote:
POSIX requires in addition [u]int{8,16,32}_t, and [u]int64_t if 64 bit
integer types exist. It says that the existence of int8_t implies
that a byte is 8 bits and CHAR_BIT is 8. I'm not sure what prevents
int8_t being smaller than char.
It follows from the fact int8_t isn't allowed to contain padding bits and
from 6.2.6.1 saying:
Values stored in non-bit-field objects of any other object type consist of n ×
CHAR_BIT bits, where n is the size of an object of that type, in bytes.
Stefan
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Fri, Oct 31, 2003 at 04:43:37PM +0100, Erik Trulsson wrote: Perhaps not smaller in terms of the sizeof operator, but why can't one have a 16-bit char, and an int8_t which occupies 16 bits, but only uses 8 of them - the other 8 being padding? 7.18.1.1 Exact-width integer types 1 The typedef name intN_t designates a signed integer type with width N, no padding bits, and a two's complement representation. Thus, int8_t denotes a signed integer type with a width of exactly 8 bits. Where in C99 does it say that uint8_t can't have padding bits? I can't find anything in n869.txt to that effect. As far as I can tell, the only type that is not allowed to have any padding bits or trap representations is unsigned char. uint8_t is int8_t's corresponding unsigned type. This means sizeof(uint8_t) == sizeof(int8_t), thus uint8_t can't have padding bits either. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone object to the following change in libc?
On Tue, Oct 28, 2003 at 04:07:13PM +, Richard Tobin wrote: I think ISO-C is pretty clear here. It would be wise to raise this on comp.std.c which is read by several of the ISO C standard authors. Things that seem pretty clear often turn out not to be... This topic is discussed almost once per year in comp.std.c, see e.g. http://groups.google.com/groups?selm=esvRTfAyaFy2Ewgv%40on-the-train.demon.co.uk for a reply from a member of JTC1/SC22/WG14. FreeBSD's *scanf() implementation seems to be just fine. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
panic: pmap_enter: attempted pmap_enter on 4MB page
opa = origpte PG_FRAME; 1895 1896if (origpte PG_PS) 1897panic(pmap_enter: attempted pmap_enter on 4MB page); 1898 1899/* 1900 * Mapping has not changed, must be protection or wiring change. 1901 */ (kgdb) info locals pa = 454402048 pte = (pt_entry_t *) 0xbfca03b8 opa = 0 origpte = 1546661872 newpte = 0 mpte = 0xc1b3a0b8 (kgdb) q %% Do you need anything else? Stefan Farfeleder ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Question about genassym, locore.s and 0-sized arrays (showstopper for an icc compiled kernel)
On Thu, Sep 04, 2003 at 11:28:58AM -0500, Dan Nelson wrote: In the last episode (Sep 04), Alexander Leidinger said: - If we depend on it: how hard would it be to rewrite it to not depend on 0-sized arrays (and does someone volunteer to rewrite it)? It would be nice if someone could point me to the source if it isn't an easy task, my contact @Intel is willing to convince the developers to change icc, but he has to present a persuasive argument to development to pursue a solution. If you're talking FreeBSD 5, you should be able to simply subsitute a C99 flexible array member (basically replace [0] with []) and get the same effect. 0-length arrays are a gcc extension: But even with flexible array members you cannot create an object with size 0. The struct must have at least one additional member and you cannot use sizeof on the flexible array member itself as its type is incomplete. Cheers, Stefan ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sun, Jul 13, 2003 at 01:25:45PM -0500, David Leimbach wrote: On Sunday, July 13, 2003, at 1:11PM, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Jilles Tjoelker [EMAIL PROTECTED] writes: : The compiler moans about (T)(-1) = 0 as well. Is the assumption that : (unsigned type)(-1) is never zero valid? yes. There are no known machines where -1 == 0 for types of different signs. Further, the C standard says that it must behave as if it is a two's complement machine, and I think that C++ says so too. I am pretty certain you can do one's compliment in the C99 standard, and that some of that is implementation/platform dependant. snip You seem to be confused. While signed integers certainly can use the one's complement representation, the conversion of an negative value to an unsigned type is a different matter. The relevant quote from C99 is: 6.3.1.3 Signed and unsigned integers 2 Otherwise, if the new type is unsigned, the value is converted by repeatedly adding or subtracting one more than the maximum value that can be represented in the new type until the value is in the range of the new type.49) Regards, Stefan Farfeleder ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: isnan() with gcc 3.2.2 on FreeBSD 5.0-C
On Mon, Mar 31, 2003 at 02:46:05PM +0800, Ying-Chieh Liao wrote:
the following code snippet works fine with gcc 2.95.4 on RELENG_4
but failed on my -current
code
#include iostream
#include cmath
using namespace std;
int main(void)
{
cout isnan(1.0) endl;
return 0;
}
/code
err
test.cpp: In function `int main()':
test.cpp:8: `isnan' undeclared (first use this function)
test.cpp:8: (Each undeclared identifier is reported only once for each function
it appears in.)
/err
what's wrong with my system ? or what can I do for it ?
The isnan() macro is a new feature of C99 and thus not (yet) part of
C++. Nevertheless you can use -D_GLIBCPP_USE_C99 to include this and
some other non-standard C++ features.
Regards,
Stefan Farfeleder
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)!
On Fri, Mar 14, 2003 at 07:11:35AM +0900, Jun Kuriyama wrote: I got this message after upgrading my world to as of Thu Mar 13 10:38:11 JST 2003. devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! devstat_end_transaction: HELP!! busy_count for ad1 is 0 (-1)! ... What does this mean? There's a patch from phk at http://phk.freebsd.dk/patch/ken.patch which works for me (though it breaks gkrellm :) Cheers, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: UMASS USB bug? (getting the Sony disk-on-key device working)
On Thu, Dec 19, 2002 at 04:25:40PM -0800, Nate Lawson wrote:
if (csio-ccb_h.flags CAM_CDB_POINTER) {
cmd = (unsigned char *) csio-cdb_io.cdb_ptr;
} else {
cmd = (unsigned char *) csio-cdb_io.cdb_bytes;
}
The is extraneous. Not sure why this doesn't bomb horribly later.
Because cdb_bytes is an array not a pointer. The expression
csio-cdb_io.cdb_bytes points to the whole array and has the type
u_int8_t (*)[IOCDBLEN], when cast to unsigned char *, the value will be
the same as just csio-cdb_io.cdb_bytes.
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, Nov 07, 2002 at 03:40:27AM -0800, Dag-Erling Smorgrav wrote:
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different
type arg (arg 3)
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different
type arg (arg 4)
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different
type arg (arg 3)
Since I've seen this particular error at least 10 times and it is
getting boring, here's an untested patch. Note that it requires the
currently latest version 1.90 of subr_prf.c. A '-' that should probably
be a '=' is fixed too.
Regards,
Stefan Farfeleder
Index: aic79xx.c
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx.c,v
retrieving revision 1.4
diff -u -r1.4 aic79xx.c
--- aic79xx.c 26 Sep 2002 22:53:59 - 1.4
+++ aic79xx.c 7 Nov 2002 14:23:40 -
-4203,7 +4203,7
}
#ifdef AHD_DEBUG
if ((ahd_debug AHD_SHOW_MEMORY) != 0) {
- printf(%s: scb size = 0x%x, hscb size - 0x%x\n,
+ printf(%s: scb size = 0x%zx, hscb size = 0x%zx\n,
ahd_name(ahd), sizeof(struct scb),
sizeof(struct hardware_scb));
}
-4597,8 +4597,8
}
#ifdef AHD_DEBUG
if ((ahd_debug AHD_SHOW_MEMORY) != 0)
- printf(%s: ahd_sglist_allocsize = 0x%x\n, ahd_name(ahd),
- ahd_sglist_allocsize(ahd));
+ printf(%s: ahd_sglist_allocsize = 0x%llx\n, ahd_name(ahd),
+ (unsigned long long)ahd_sglist_allocsize(ahd));
#endif
scb_data-init_level++;
Re: alpha tinderbox failure
On Thu, Nov 07, 2002 at 08:28:30AM -0700, Scott Long wrote: On Thu, Nov 07, 2002 at 04:22:07PM +0100, Stefan Farfeleder wrote: Since I've seen this particular error at least 10 times and it is getting boring, here's an untested patch. Note that it requires the currently latest version 1.90 of subr_prf.c. A '-' that should probably be a '=' is fixed too. As I've told others, this file is shared with the Linux version of the driver, so any changes must be compatible with Linux printk(). We'll have a proper fix in the next code drop of this driver. Fine. Also, why does the '=' need to be changed to '-' ? It's the other way round. printf(%s: scb size = 0x%x, hscb size - 0x%x\n, ^ this should be '='? Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: libstdc++ does not contain fabsl symbol
On Tue, Oct 22, 2002 at 12:40:38PM -0700, Terry Lambert wrote: Kris Kennaway wrote: /usr/src/contrib/gperf/src/bool-array.icc:81: warning: rand() does not produce high-quality random numbers and should not generally be used /usr/obj/usr/src/i386/usr/lib/libstdc++.so: undefined reference to `fabsl' *** Error code 1 This is because we lack the long double fabsl(long double); in -lm and math.h. OK, thanks for tracking it down. This looks like an important omission that should be fixed for 5.0-R. Is it? What standard defines this thing, which g++ has as a built-in? Alternately, the use could avoid adding the -fno-builtin, and the problem would go away. ISO C99 7.12.7.2 The fabs functions Synopsis #include math.h double fabs(double x); float fabsf(float x); long double fabsl(long double x); Description The fabs functions compute the absolute value of a floating-point number x. Returns The fabs functions return | x |. Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Wed, Oct 09, 2002 at 04:07:45PM -0700, Terry Lambert wrote:
Stefan Farfeleder wrote:
Is it just a warning or does it pose a real problem?
I think the problem with the current code is that knote_{en,de}queue can
be executed in parallel (on another CPU, spl*() can't prevent that, can
it?) with kqueue_scan and that kq-kq_head thus can be corrupted.
Or am I totally wrong?
My patch would have worked, in that case, since it would ensure
one marker entry with a unique stack address per simultaneous
scanner.
It has to be that the queue itself is being deleted out from
under it: the problem is not the scan, nor the insert or the
delete.
Most likely, this is for an object whose queue is not tracked
by process, or for a process queue that's being examined by
another process (e.g. kevent's on fork/exit/etc.).
You can verify this for your own satisfaction by looking at the
pointer manipulation order for the insertion and deletion; the
insertion sets the next pointer before setting the pointer to
the inserted object, and the deletion sets the pointer that
used to point to the deleted object to the delete object's next,
before deleting the object. Thus, traversals in progress should
not result in an error.
Imagine this scenario where CPU 0 inserts a knote kn1 (the marker) in
knote_scan and CPU 1 kn2 in kqueue_enqueue:
CPU 0 | CPU 1
+---
kn1-kn_tqe.tqe_next = NULL;|
|
+---
kn1-kn_tqe.tqe_prev = | kn2-kn_tqe.tqe_next = NULL;
kq_head.tqh_last; |
+---
*kq_head.tqh_last = kn1;| kn2-kn_tqe.tqe_prev =
| kq_head.tqh_last;
+---
kq_head.tqh_last = | *kq_head.tqh_last = kn2;
kn1-kn_tqe.tqe_next; |
+---
| kq_head.tqh_last =
| kn2-kn_tqe.tqe_next;
The marker would never appear on the queue.
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Tue, Oct 08, 2002 at 09:26:29PM -0700, Don Lewis wrote:
On 8 Oct, Stefan Farfeleder wrote:
On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
Following the advice from the spl* man page I turned the spl* calls to a
mutex and was surprised to see it working. My SMP -current survived a 'make
-j16 buildworld' with make using kqueue() (which it did not a single
time out of 30 times before). Further testings will follow tomorrow.
Building 6 worlds in a row with -j ranging from 4 to 128 didn't crash
it.
However, WITNESS complains (only once) about this:
lock order reversal
1st 0xc662140c kqueue mutex (kqueue mutex) @
/freebsd/current/src/sys/kern/kern_event.c:714
2nd 0xc6727d00 pipe mutex (pipe mutex) @
/freebsd/current/src/sys/kern/sys_pipe.c:1478
That's pretty similar to the lock order reversal I've seen in the pipe
code and it's interaction with sigio, which is not suprising since
pipeselwakeup() calls both pgsigio() and KNOTE(), often while the pipe
lock is held. Correctly fixing this doesn't look easy ...
Is it just a warning or does it pose a real problem?
I think the problem with the current code is that knote_{en,de}queue can
be executed in parallel (on another CPU, spl*() can't prevent that, can
it?) with kqueue_scan and that kq-kq_head thus can be corrupted.
Or am I totally wrong?
@Poul: Since you are the only person who reported a kernel crash too,
does the version with the mutex work for you?
Regards,
Stefan Farfelder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: [PATCH] Re: Junior Kernel Hacker page updated...
On Mon, Oct 07, 2002 at 03:48:45AM -0700, Terry Lambert wrote:
*** OK, it's very hard to believe you didn't break into the
*** debugger and manually call pnaic to get this to happen.
You're right, this is exactly what I did.
I can't personally repeat the problem, so you're elected to do
the legwork on this one. 8-(.
Following the advice from the spl* man page I turned the spl* calls to a
mutex and was surprised to see it working. My SMP -current survived a 'make
-j16 buildworld' with make using kqueue() (which it did not a single
time out of 30 times before). Further testings will follow tomorrow.
However, WITNESS complains (only once) about this:
lock order reversal
1st 0xc662140c kqueue mutex (kqueue mutex)
/freebsd/current/src/sys/kern/kern_event.c:714
2nd 0xc6727d00 pipe mutex (pipe mutex) /freebsd/current/src/sys/kern/sys_pipe.c:1478
Regards,
Stefan Farfeleder
Index: sys/eventvar.h
===
RCS file: /home/ncvs/src/sys/sys/eventvar.h,v
retrieving revision 1.4
diff -u -r1.4 eventvar.h
--- sys/eventvar.h 18 Jul 2000 19:31:48 - 1.4
+++ sys/eventvar.h 8 Oct 2002 16:06:46 -
-35,6 +35,7
struct kqueue {
TAILQ_HEAD(kqlist, knote) kq_head; /* list of pending event */
int kq_count; /* number of pending events */
+ struct mtx kq_mtx; /* protect kq_head */
struct selinfo kq_sel;
struct filedesc *kq_fdp;
int kq_state;
Index: kern/kern_event.c
===
RCS file: /home/ncvs/src/sys/kern/kern_event.c,v
retrieving revision 1.46
diff -u -r1.46 kern_event.c
--- kern/kern_event.c 3 Oct 2002 06:03:26 - 1.46
+++ kern/kern_event.c 8 Oct 2002 19:22:27 -
-375,7 +375,7
if (error)
goto done2;
kq = malloc(sizeof(struct kqueue), M_KQUEUE, M_WAITOK | M_ZERO);
- TAILQ_INIT(kq-kq_head);
+ mtx_init(kq-kq_mtx, kqueue mutex, NULL, MTX_DEF);
FILE_LOCK(fp);
fp-f_flag = FREAD | FWRITE;
fp-f_type = DTYPE_KQUEUE;
-709,13 +709,15
error = 0;
goto done;
}
+ splx(s);
+ mtx_lock(kq-kq_mtx);
TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
while (count) {
kn = TAILQ_FIRST(kq-kq_head);
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
if (kn == marker) {
- splx(s);
+ mtx_unlock(kq-kq_mtx);
if (count == maxevents)
goto retry;
goto done;
-737,10 +739,10
if (kn-kn_flags EV_ONESHOT) {
kn-kn_status = ~KN_QUEUED;
kq-kq_count--;
- splx(s);
+ mtx_unlock(kq-kq_mtx);
kn-kn_fop-f_detach(kn);
knote_drop(kn, td);
- s = splhigh();
+ mtx_lock(kq-kq_mtx);
} else if (kn-kn_flags EV_CLEAR) {
kn-kn_data = 0;
kn-kn_fflags = 0;
-751,19 +753,19
}
count--;
if (nkev == KQ_NEVENTS) {
- splx(s);
+ mtx_unlock(kq-kq_mtx);
error = copyout(kq-kq_kev, ulistp,
sizeof(struct kevent) * nkev);
ulistp += nkev;
nkev = 0;
kevp = kq-kq_kev;
- s = splhigh();
+ mtx_lock(kq-kq_mtx);
if (error)
break;
}
}
TAILQ_REMOVE(kq-kq_head, marker, kn_tqe);
- splx(s);
+ mtx_unlock(kq-kq_mtx);
done:
if (nkev != 0)
error = copyout(kq-kq_kev, ulistp,
-887,6 +889,7
}
}
FILEDESC_UNLOCK(fdp);
+ mtx_destroy(kq-kq_mtx);
free(kq, M_KQUEUE);
fp-f_data = NULL;
-1051,14 +1054,14
knote_enqueue(struct knote *kn)
{
struct kqueue *kq = kn-kn_kq;
- int s = splhigh();
KASSERT((kn-kn_status KN_QUEUED) == 0, (knote already queued));
+ mtx_lock(kq-kq_mtx);
TAILQ_INSERT_TAIL(kq-kq_head, kn, kn_tqe);
kn-kn_status |= KN_QUEUED;
kq-kq_count++;
- splx(s);
+ mtx_unlock(kq-kq_mtx);
kqueue_wakeup(kq);
}
-1066,14 +1069,14
knote_dequeue(struct knote *kn)
{
struct kqueue *kq = kn-kn_kq;
- int s = splhigh();
KASSERT(kn-kn_status KN_QUEUED, (knote not queued));
+ mtx_lock(kq-kq_mtx);
TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
kn-kn_status = ~KN_QUEUED;
kq-kq_count--;
- splx(s
Re: [PATCH] Re: Junior Kernel Hacker page updated...
= 2, tf_eip = 134641975, tf_cs = 31,
tf_eflags = 514, tf_esp = -1077941412, tf_ss = 47})
at /freebsd/current/src/sys/i386/i386/trap.c:1050
#22 0xc02eb7bd in Xint0x80_syscall () at {standard input}:141
---Can't read userspace from dump, or kernel process---
(kgdb) frame 19
#19 0xc01a1212 in kqueue_scan (fp=0x0, maxevents=4, ulistp=0xbfbfeb90,
tsp=0xc754f828, td=0xc6426b60)
at /freebsd/current/src/sys/kern/kern_event.c:717
717 KASSERT(kn != NULL, (TAILQ_FIRST returned NULL));
(kgdb) info locals
kq = (struct kqueue *) 0xc754f800
kevp = (struct kevent *) 0xc754f828
atv = {tv_sec = 0, tv_usec = 0}
rtv = {tv_sec = 434, tv_usec = -1070420864}
ttv = {tv_sec = 1, tv_usec = -1070411616}
kn = (struct knote *) 0x0
marker = {kn_link = {sle_next = 0xc01b0d37}, kn_selnext = {
sle_next = 0xc0368a20}, kn_tqe = {tqe_next = 0x0, tqe_prev = 0xc6650ac8},
kn_kq = 0xc6426bcc, kn_kevent = {ident = 3344374324, filter = -30080,
flags = 49206, fflags = 3224546432, data = 431, udata = 0xe2c9dca0},
kn_status = 16, kn_sfflags = -1070167424, kn_sdata = 8, kn_ptr = {
p_fp = 0xc032ac80, p_proc = 0xc032ac80}, kn_fop = 0x1af, kn_hook = 0x3}
count = 4
timeout = 0
nkev = 0
error = 0
(kgdb) p *kq
$2 = {kq_head = {tqh_first = 0x0, tqh_last = 0xc754f800}, kq_count = 1,
kq_sel = {si_thrlist = {tqe_next = 0x0, tqe_prev = 0x0}, si_thread = 0x0,
si_note = {slh_first = 0x0}, si_flags = 0}, kq_fdp = 0xc7571a00,
kq_state = 0, kq_kev = {{ident = 23, filter = -1, flags = 1, fflags = 0,
data = 69, udata = 0x80cd800}, {ident = 23, filter = -1, flags = 1,
fflags = 0, data = 164, udata = 0x80cd800}, {ident = 27, filter = -1,
flags = 1, fflags = 0, data = 218, udata = 0x80cf800}, {ident = 19,
filter = -1, flags = 1, fflags = 0, data = 182, udata = 0x80cc800}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}, {
ident = 0, filter = 0, flags = 0, fflags = 0, data = 0, udata = 0x0}}}
(kgdb) q
frog# ^Dexit
Script done on Mon Oct 7 11:32:50 2002
I'm confused why marker - if it was removed by TAILQ_REMOVE - hasn't
kn_tqe.tqe_next and kn_tqe.tqe_prev set to (void *)-1.
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker page updated...
On Fri, Oct 04, 2002 at 04:33:17PM -0400, John Baldwin wrote:
I wrote:
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0x8
fault code = supervisor read, page not present
instruction pointer = 0x8:0xc01a1212
stack pointer = 0x10:0xe5226c14
frame pointer = 0x10:0xe5226ca0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 56525 (make)
kernel: type 12 trap, code = 0
Stopped atkqueue_scan+0x242: cmpl $0,0x8(%ebx)
db trace
kqueue_scan(c6472bf4,4,bfbfebc0,0,c70ecea0) at kqueue_scan+0x242
kevent(c70ecea0,e5226d10,c0351d80,418,6) at kevent+0x1e1
syscall(2f,2f,2f,818d780,818d960) at syscall+0x2be
%%%
Even better, pop up gdb on kernel.debug and do
'l *kqueue_scan+0x242' to look at the offending line of code.
addr2line can also be useful here similarly.
(kgdb) l *kqueue_scan+0x242
0xc01a1212 is in kqueue_scan
(/freebsd/current/src/sys/kern/kern_event.c:716).
711 }
712
713 TAILQ_INSERT_TAIL(kq-kq_head, marker, kn_tqe);
714 while (count) {
715 kn = TAILQ_FIRST(kq-kq_head);
translates to: mov(%edi),%ebx
716 TAILQ_REMOVE(kq-kq_head, kn, kn_tqe);
translates to: cmpl $0x0,0x8(%ebx)
This line causes the page fault because %ebx is 0.
je fe3 kqueue_scan+0x253
mov0x8(%ebx),%edx
[...]
717 if (kn == marker) {
718 splx(s);
719 if (count == maxevents)
720 goto retry;
I've added this after line 715:
716 if (kn == NULL) {
717 Debugger(TAILQ_FIRST returns NULL);
718 }
and after 4 freezes, I really came into ddb in line 717. However, when
trying to produce a dump, this occured:
db panic
panic: from debugger
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks... panic: bremfree: bp 0xd2a42990 not locked
boot() called on cpu#1
Uptime: 10m13s
pfs_vncache_unload(): 1 entries remaining
Dumping 1023 MB
ata0: resetting devices
ata0: mask=03 ostat0=50 ostat2=00
ad0: ATAPI 00 00
ata0-slave: ATAPI 00 00
ata0: mask=03 stat0=50 stat1=00
ad0: ATA 01 a5
ata0: devices=01
and I had to reboot without a dump :-(
Regards,
Stefan Farfeleder
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Junior Kernel Hacker page updated...
)
fe9: 8b 43 0cmov0xc(%ebx),%eax
fec: 8b 53 08mov0x8(%ebx),%edx
fef: 89 10 mov%edx,(%eax)
if (kn == marker) {
ff1: 8d 45 b4lea0xffb4(%ebp),%eax
ff4: 39 c3 cmp%eax,%ebx
ff6: 75 18 jne1010 kqueue_scan+0x280
splx(s);
[...]
%%%
This seems to indicate that TAILQ_FIRST returns a null pointer and
TAILQ_REMOVE tries to dereference it, doesn't it? Maybe 'count' is not 0
though it should be?
Regards,
Stefan Farfeleder
Index: job.c
===
RCS file: /home/ncvs/src/usr.bin/make/job.c,v
retrieving revision 1.43
diff -u -r1.43 job.c
--- job.c 29 Sep 2002 00:20:28 - 1.43
+++ job.c 4 Oct 2002 10:58:52 -
-106,6 +106,7
#include sys/stat.h
#include sys/file.h
#include sys/time.h
+#include sys/event.h
#include sys/wait.h
#include err.h
#include errno.h
-237,9 +238,13
* (2) a job can only be run locally, but
* nLocal equals maxLocal */
#ifndef RMT_WILL_WATCH
+#ifdef USE_KQUEUE
+static int kqfd; /* File descriptor obtained by kqueue() */
+#else
static fd_set outputs;/* Set of descriptors of pipes connected to
* the output channels of children */
#endif
+#endif
STATIC GNode *lastNode; /* The node for which output was most recently
* produced. */
-692,7 +697,7
if (usePipes) {
#ifdef RMT_WILL_WATCH
Rmt_Ignore(job-inPipe);
-#else
+#elif !defined(USE_KQUEUE)
FD_CLR(job-inPipe, outputs);
#endif
if (job-outPipe != job-inPipe) {
-1267,10 +1272,22
* position in the buffer to the beginning and mark another
* stream to watch in the outputs mask
*/
+#ifdef USE_KQUEUE
+ struct kevent kev[2];
+#endif
job-curPos = 0;
#ifdef RMT_WILL_WATCH
Rmt_Watch(job-inPipe, JobLocalInput, job);
+#elif defined(USE_KQUEUE)
+ EV_SET(kev[0], job-inPipe, EVFILT_READ, EV_ADD, 0, 0, job);
+ EV_SET(kev[1], job-pid, EVFILT_PROC, EV_ADD | EV_ONESHOT,
+ NOTE_EXIT, 0, NULL);
+ if (kevent(kqfd, kev, 2, NULL, 0, NULL) != 0) {
+ /* kevent() will fail if the job is already finished */
+ if (errno != EBADF errno != ESRCH)
+ Punt(kevent: %s, strerror(errno));
+ }
#else
FD_SET(job-inPipe, outputs);
#endif /* RMT_WILL_WATCH */
-2229,10 +2246,16
Job_CatchOutput()
{
int nfds;
+#ifdef USE_KQUEUE
+#define KEV_SIZE 4
+struct keventkev[KEV_SIZE];
+int i;
+#else
struct timeval timeout;
fd_set readfds;
LstNode ln;
Job *job;
+#endif
#ifdef RMT_WILL_WATCH
int pnJobs; /* Previous nJobs */
#endif
-2262,6 +2285,27
}
#else
if (usePipes) {
+#ifdef USE_KQUEUE
+ if ((nfds = kevent(kqfd, NULL, 0, kev, KEV_SIZE, NULL)) == -1) {
+ Punt(kevent: %s, strerror(errno));
+ } else {
+ for (i = 0; i nfds; i++) {
+ if (kev[i].flags EV_ERROR) {
+ warnc(kev[i].data, kevent);
+ continue;
+ }
+ switch (kev[i].filter) {
+ case EVFILT_READ:
+ JobDoOutput(kev[i].udata, FALSE);
+ break;
+ case EVFILT_PROC:
+ /* Just wake up and let Job_CatchChildren() collect the
+* terminated job. */
+ break;
+ }
+ }
+ }
+#else
readfds = outputs;
timeout.tv_sec = SEL_SEC;
timeout.tv_usec = SEL_USEC;
-2282,6 +2326,7
}
Lst_Close(jobs);
}
+#endif /* !USE_KQUEUE */
}
#endif /* RMT_WILL_WATCH */
}
-2408,6 +2453,12
}
if (signal(SIGWINCH, SIG_IGN) != SIG_IGN) {
(void) signal(SIGWINCH, JobPassSig);
+}
+#endif
+
+#ifdef USE_KQUEUE
+if ((kqfd = kqueue()) == -1) {
+ Punt(kqueue: %s, strerror(errno));
}
#endif
Index: job.h
===
RCS file: /home/ncvs/src/usr.bin/make/job.h,v
retrieving revision 1.18
diff -u -r1.18 job.h
--- job.h 26 Sep 2002 01:39:22 - 1.18
+++ job.h 4 Oct 2002 10:55:11 -
-50,6 +50,7
#defineTMPPAT /tmp/makeXX
+#ifndef USE_KQUEUE
/*
* The SEL_ constants determine the maximum amount of time spent in select
* before coming out to see if a child has finished. SEL_SEC is the number of
-57,6 +58,7
*/
#define
Re: Junior Kernel Hacker page updated...
On Sat, Sep 14, 2002 at 12:17:53PM +0200, Poul-Henning Kamp wrote:
This is just to note that I have updated the JKH page with a lot of new
stuff, so if your coding-pencil itches:
http://people.freebsd.org/~phk/TODO/
|Make -j improvement
|
|make(1) with -j option uses a select loop to wait for events, and every
|100msec it drops out to look for processes exited etc. A pure make
|buildworld on a single-CPU machine is up to 25% faster that the best
|make -j N buildworld time on the same hardware. Changing to timeout
|to be 10msec improves things about 10%.
|I think that make(1) should use kqueue(2) instead, since that would
|eliminate the need for timeouts.
Ok, here's what I came up with. However, with the patch applied, each
'make buildworld' on a SMP machine throws tons of
/freebsd/current/src/sys/vm/uma_core.c:1307: could sleep with filedesc structure
locked from /freebsd/current/src/sys/kern/kern_event.c:959
at me and freezes badly at some point (no breaking into ddb possible).
This is totally repeatable. Is anybody able to reproduce (and maybe
fix) this?
Regards,
Stefan Farfeleder
Index: job.c
===
RCS file: /home/ncvs/src/usr.bin/make/job.c,v
retrieving revision 1.43
diff -u -r1.43 job.c
--- job.c 29 Sep 2002 00:20:28 - 1.43
+++ job.c 2 Oct 2002 21:34:51 -
-64,9 +64,8
* Job_CatchOutput Print any output our children have produced.
* Should also be called fairly frequently to
* keep the user informed of what's going on.
- * If no output is waiting, it will block for
- * a time given by the SEL_* constants, below,
- * or until output is ready.
+ * If no output is waiting, it will block until
+ * a child terminates or until output is ready.
*
* Job_InitCalled to intialize this module. in addition,
* any commands attached to the .BEGIN target
-107,6 +106,8
#include sys/file.h
#include sys/time.h
#include sys/wait.h
+#include sys/event.h
+#include sys/time.h
#include err.h
#include errno.h
#include fcntl.h
-237,8 +238,7
* (2) a job can only be run locally, but
* nLocal equals maxLocal */
#ifndef RMT_WILL_WATCH
-static fd_set outputs;/* Set of descriptors of pipes connected to
-* the output channels of children */
+static int kqfd; /* File descriptor obtained by kqueue() */
#endif
STATIC GNode *lastNode; /* The node for which output was most recently
-692,8 +692,6
if (usePipes) {
#ifdef RMT_WILL_WATCH
Rmt_Ignore(job-inPipe);
-#else
- FD_CLR(job-inPipe, outputs);
#endif
if (job-outPipe != job-inPipe) {
(void) close(job-outPipe);
-1265,14 +1263,25
/*
* The first time a job is run for a node, we set the current
* position in the buffer to the beginning and mark another
-* stream to watch in the outputs mask
+* stream to watch in the outputs mask. The termination of this
+* job and the availability of new data in the pipe are
+* registered in the kqueue.
*/
+ struct kevent kev[2];
+
job-curPos = 0;
#ifdef RMT_WILL_WATCH
Rmt_Watch(job-inPipe, JobLocalInput, job);
#else
- FD_SET(job-inPipe, outputs);
+ EV_SET(kev[0], job-inPipe, EVFILT_READ, EV_ADD, 0, 0, job);
+ EV_SET(kev[1], job-pid, EVFILT_PROC, EV_ADD | EV_ONESHOT,
+ NOTE_EXIT, 0, NULL);
+ if (kevent(kqfd, kev, 2, NULL, 0, NULL) != 0) {
+ /* kevent() will fail if the job is already finished */
+ if (errno != EBADF errno != ESRCH)
+ Punt(kevent: %s, strerror(errno));
+ }
#endif /* RMT_WILL_WATCH */
}
-2229,12 +2238,12
Job_CatchOutput()
{
int nfds;
-struct timeval timeout;
-fd_set readfds;
-LstNode ln;
-Job *job;
#ifdef RMT_WILL_WATCH
int pnJobs; /* Previous nJobs */
+#else
+struct keventkev[4]; /* 4 is somewhat arbitrary */
+size_t kevsize = sizeof(kev) / sizeof(kev[0]);
+int i;
#endif
(void) fflush(stdout);
-2262,25 +2271,20
}
#else
if (usePipes) {
- readfds = outputs;
- timeout.tv_sec = SEL_SEC;
- timeout.tv_usec = SEL_USEC;
-
- if ((nfds = select(FD_SETSIZE, readfds, (fd_set *) 0,
- (fd_set *) 0, timeout)) = 0)
- return;
- else
Re: stage 2 build of contrib/file breaks upgrade from 4.7PRE to CURRENT.
[CC'ing David O'Brien as he did the update to 3.39] On Tue, Sep 17, 2002 at 09:38:10AM -0700, Lars Eggert wrote: Robert Suetterlin wrote: I currently upgraded my 4.4 to 4.7-PRE and now tried to get from there to -CURRENT. Unfortunately ``make buildworld'' fails during stage 2 when building ``usr.bin/file'': usr/src/usr.bin/file/../../contrib/file/file.h:45: stdint.h: No such file or directory FYI I'm seeing the exact same error trying to build -CURRENT under 4.6-RELEASE (just cvs updated). Add me to the list. Culprit is src/usr.bin/file/config.h which unconditionally defines HAVE_STDINT_H though RELENG_4 is missing it. Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Problem compiling -current on 4.6-RELEASE
On Thu, Jul 25, 2002 at 11:45:21AM +0200, Martin Bundgaard wrote: ... === gnu/usr.bin/tar rm -f tar addext.o argmatch.o backupfile.o basename.o dirname.o error.o exclude.o full-write.o getdate.o getline.o getopt.o getopt1.o getstr.o hash.o human.o mktime.o modechange.o prepargs.o print-copyr.o quotearg.o safe-read.o save-cwd.o savedir.o unicodeio.o xgetcwd.o xmalloc.o xstrdup.o xstrtoul.o xstrtoumax.o buffer.o compare.o create.o delete.o extract.o incremen.o list.o mangle.o misc.o names.o rtapelib.o tar.o update.o tar.1.gz tar.1.cat.gz rm: tar: is a directory ... The tar directory should really be in the attic. I guess you forgot to use -P when using cvs update/checkout. Cheers, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
