r255873: ahcich7: Timeout on slot 0 port 0 FLOODING kernel messages
Rebooting into CURRENT r255873 floods the kernel messages with ahcich7: Timeout on slot 0 port 0 ahcich7: is cs 0001 ss rs 0001 tfd c0 serr cmd 0004c017 What is this supposed to mean? Is this a GEOM pollution of the outer world? Regards, oh signature.asc Description: PGP signature
Re: lang/gcc not build
On Sep 25, 2013, at 15:17, Alexander Panyushkin wrote: > uname > FreeBSD 10.0-ALPHA2 #0 r255833M: Tue Sep 24 10:21:04 EEST 2013 > - > > make.conf > CFLAGS= -O2 -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe > -Qunused-parameter -Wformat -Wformat-security > CPPFLAGS+= -D_FORTIFY_SOURCE=2 > - > > > Checking multilib configuration for libgcc... > mkdir x86_64-portbld-freebsd10.0 > mkdir x86_64-portbld-freebsd10.0/libgcc > Configuring in x86_64-portbld-freebsd10.0/libgcc > configure: creating cache ./config.cache > checking for --enable-version-specific-runtime-libs... no > checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel > checking for gawk... /usr/bin/awk > checking build system type... x86_64-portbld-freebsd10.0 > checking host system type... x86_64-portbld-freebsd10.0 > checking for x86_64-portbld-freebsd10.0-ar... > /usr/local/x86_64-portbld-freebsd10.0/bin/ar > checking for x86_64-portbld-freebsd10.0-lipo... lipo > checking for x86_64-portbld-freebsd10.0-nm... > /usr/ports/lang/gcc/work/build/./gcc/nm > checking for x86_64-portbld-freebsd10.0-ranlib... > /usr/local/x86_64-portbld-freebsd10.0/bin/ranlib > checking for x86_64-portbld-freebsd10.0-strip... > /usr/local/x86_64-portbld-freebsd10.0/bin/strip > checking whether ln -s works... yes > checking for x86_64-portbld-freebsd10.0-gcc... > /usr/ports/lang/gcc/work/build/./gcc/xgcc > -B/usr/ports/lang/gcc/work/build/./gcc/ > -B/usr/local/x86_64-portbld-freebsd10.0/bin/ > -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem > /usr/local/x86_64-portbld-freebsd10.0/include -isystem > /usr/local/x86_64-portbld-freebsd10.0/sys-include > checking for suffix of object files... configure: error: in > `/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.0/libgcc': > configure: error: cannot compute suffix of object files: cannot compile Most likely, the xgcc instance cannot handle the -Qunused-parameter flag. So remove it from your custom CFLAGS (note that you should use +=, not = for CFLAGS in make.conf), and try again. If this does not help, post the config.log file. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Problem with r255775 include/mk-osreldate.sh
On Wed, Sep 25, 2013 at 12:16:47PM -0600, Ian Lepore wrote:
| On Wed, 2013-09-25 at 10:52 -0700, Doug Ambrisko wrote:
| > I don't know if others have run into this but I hit a problem with
| > include/mk-osreldate.sh. It does a set -e to exit on commands failing
| > and sources in sys/conf/newvers.sh to get various things set.
| > In newvers.sh it does a bunch of
| >
| > if [ $? -eq 0 ]; then
| > to decide what to do when it passes or fails. Unfortunately, when
| > it fails due to the "set -e" it just exits and doesn't do the
| > else clause. For me I check out a svn tree then build in a chroot.
| > In the chroot svn was failing then not creating a osreldate.h
| > resulting in the build dying. This happened on two different machines
| > of which I use this method.
| >
| > Removing the set -e in mk-osreldate.sh "fixed" my problem. It should
| > probably be reworked to not depend on set -e and print errors when things
| > fail. I guess newvers.sh could be reworked to do
| > if ; then
| > which should pass set -e.
| >
| > What do folks think? It would be good to get this fixed before MFC
| > and before 10 is released.
|
| For such a "simple" little change, this sure has been problematic.
| There are as many ways for it to fail as there are ways to arrange
| checkout-and-build workflows, apparently.
|
| I've been mostly inclined to stay away from any big changes in
| newvers.sh for fear of breaking it when it's used in some way I'm not
| familiar with (such as building a release). Sticking with that theory,
| I'd be inclined to leave it alone again, and not push the 'set -e'
| problem into its world, and instead do something like the attached.
Yes, I'd be nervous to touch newvers.sh as well.
| My thinking is that newvers.sh does a variety of things, only some of
| which are germane to the needs of mk-osreldate.h, so have mk-osreldate
| check for just what it needs, and let newvers.sh take care of its
| internal errors however it likes.
Index: include/mk-osreldate.sh
===
--- include/mk-osreldate.sh (revision 255775)
+++ include/mk-osreldate.sh (working copy)
@@ -25,8 +25,6 @@
#
# $FreeBSD$
-set -e
-
CURDIR=$(pwd)
ECHO=${ECHO:=echo}
@@ -37,6 +35,12 @@ ${ECHO} creating osreldate.h from newvers.sh
export PARAMFILE="${PARAM_H:=$CURDIR/../sys/sys/param.h}"
. "${NEWVERS_SH:=$CURDIR/../sys/conf/newvers.sh}"
+
+if [ -z "${COPYRIGHT}" -o -z "${RELDATE}" ] ; then
+${ECHO} "newvers.sh did not generate required information"
+exit 1
+fi
+
cat > $tmpfile
Re: Problem with r255775 include/mk-osreldate.sh
On Wed, 2013-09-25 at 10:52 -0700, Doug Ambrisko wrote:
> I don't know if others have run into this but I hit a problem with
> include/mk-osreldate.sh. It does a set -e to exit on commands failing
> and sources in sys/conf/newvers.sh to get various things set.
> In newvers.sh it does a bunch of
>
> if [ $? -eq 0 ]; then
> to decide what to do when it passes or fails. Unfortunately, when
> it fails due to the "set -e" it just exits and doesn't do the
> else clause. For me I check out a svn tree then build in a chroot.
> In the chroot svn was failing then not creating a osreldate.h
> resulting in the build dying. This happened on two different machines
> of which I use this method.
>
> Removing the set -e in mk-osreldate.sh "fixed" my problem. It should
> probably be reworked to not depend on set -e and print errors when things
> fail. I guess newvers.sh could be reworked to do
> if ; then
> which should pass set -e.
>
> What do folks think? It would be good to get this fixed before MFC
> and before 10 is released.
>
> Doug A.
For such a "simple" little change, this sure has been problematic.
There are as many ways for it to fail as there are ways to arrange
checkout-and-build workflows, apparently.
I've been mostly inclined to stay away from any big changes in
newvers.sh for fear of breaking it when it's used in some way I'm not
familiar with (such as building a release). Sticking with that theory,
I'd be inclined to leave it alone again, and not push the 'set -e'
problem into its world, and instead do something like the attached.
My thinking is that newvers.sh does a variety of things, only some of
which are germane to the needs of mk-osreldate.h, so have mk-osreldate
check for just what it needs, and let newvers.sh take care of its
internal errors however it likes.
-- Ian
Index: include/mk-osreldate.sh
===
--- include/mk-osreldate.sh (revision 255775)
+++ include/mk-osreldate.sh (working copy)
@@ -25,8 +25,6 @@
#
# $FreeBSD$
-set -e
-
CURDIR=$(pwd)
ECHO=${ECHO:=echo}
@@ -37,6 +35,12 @@ ${ECHO} creating osreldate.h from newvers.sh
export PARAMFILE="${PARAM_H:=$CURDIR/../sys/sys/param.h}"
. "${NEWVERS_SH:=$CURDIR/../sys/conf/newvers.sh}"
+
+if [ -z "${COPYRIGHT}" -o -z "${RELDATE}" ] ; then
+${ECHO} "newvers.sh did not generate required information"
+exit 1
+fi
+
cat > $tmpfile <___
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: and64-build i386 mtree doesn't work too (Re: r255795/i386 built on r255795/amd64 still could not start devdpassword)
Hello, Dimitry. You wrote 25 сентября 2013 г., 1:50:48: DA> I just tried buildworld TARGET=i386 on an amd64 host, and it worked just DA> fine. Are you using any make.conf or src.conf? Oh, I was too fast. It is not Ok. devd is started ok, yes. But I cannot change root password from console with: passwd: pam_chauthtok(): error in service module. And after that here is /etc/pwd.db.tmp (empty one). Password is not changed. Again, 100% reproducable. And "host" amd64 system doesn't have this problem. Both systems are r255867, built without anu /etc/make.conf or /etc/src.conf. :-\ -- // Black Lion AKA Lev Serebryakov ___ 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: and64-build i386 mtree doesn't work too (Re: r255795/i386 built on r255795/amd64 still could not start devdpassword)
Hello, Dimitry. You wrote 25 сентября 2013 г., 1:50:48: DA> I just tried buildworld TARGET=i386 on an amd64 host, and it worked just DA> fine. Are you using any make.conf or src.conf? Ok, one more full cycle (6+ hours) and it seems to work... -- // Black Lion AKA Lev Serebryakov ___ 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"
Problem with r255775 include/mk-osreldate.sh
I don't know if others have run into this but I hit a problem with include/mk-osreldate.sh. It does a set -e to exit on commands failing and sources in sys/conf/newvers.sh to get various things set. In newvers.sh it does a bunch of if [ $? -eq 0 ]; then to decide what to do when it passes or fails. Unfortunately, when it fails due to the "set -e" it just exits and doesn't do the else clause. For me I check out a svn tree then build in a chroot. In the chroot svn was failing then not creating a osreldate.h resulting in the build dying. This happened on two different machines of which I use this method. Removing the set -e in mk-osreldate.sh "fixed" my problem. It should probably be reworked to not depend on set -e and print errors when things fail. I guess newvers.sh could be reworked to do if ; then which should pass set -e. What do folks think? It would be good to get this fixed before MFC and before 10 is released. Doug A. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe0000000129b4d80, blocked for 901858 ticks
This panic was triggered by "svn up", while portmaster updates were going on: FreeBSD mech-as221.men.bris.ac.uk 10.0-ALPHA2 FreeBSD 10.0-ALPHA2 #8 r255811: Tue Sep 24 09:04:17 BST 2013 r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 - - - - - - - - - - Prior Console Output - - - - - - - - - - kdb_backtrace(0x9ffc00bfb030, 0x9ffc0045b350, 0x40c, 0x9ffc00dd20a0) at kdb_backtrace+0xc0 vpanic(0x9ffc00aec840, 0xa05cb518) at vpanic+0x260 panic(0x9ffc00aec840, 0x9ffc00aecaa0, 0xe000129b4d80, 0xdc2e2) at panic+0x80 deadlkres(0xdc2e2, 0xe000129b4d80, 0x9ffc00aef478, 0x9ffc00aec7d0) at deadlkres+0x420 fork_exit(0x9ffc00b441e0, 0x0, 0xa05cb550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic [ thread pid 0 tid 100047 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe28fb0,gp ;; db> - - - - - - - - - - - - Live Console - - - - - - - - - - - - db> show msgbuf msgbufp = 0xe040fffbdfb8 magic = 63062, size = 98232, r= 12374, w = 13109, ptr = 0xe040fffa6000, cksum= 988569 panic: deadlkres: possible deadlock detected for 0xe000129b4d80, blocked for 901858 ticks cpuid = 1 KDB: stack backtrace: db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc00bfb030, 0x9ffc0045b350, 0x40c, 0x9ffc00dd20a0) at kdb_backtrace+0xc0 vpanic(0x9ffc00aec840, 0xa05cb518) at vpanic+0x260 panic(0x9ffc00aec840, 0x9ffc00aecaa0, 0xe000129b4d80, 0xdc2e2) at panic+0x80 deadlkres(0xdc2e2, 0xe000129b4d80, 0x9ffc00aef478, 0x9ffc00aec7d0) at deadlkres+0x420 fork_exit(0x9ffc00b441e0, 0x0, 0xa05cb550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic GDB: debug ports: uart GDB: current port: uart KDB: debugger backends: ddb gdb KDB: current backend: ddb Copyright (c) 1992-2013 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 10.0-ALPHA2 #8 r255811: Tue Sep 24 09:04:17 BST 2013 r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 gcc version 4.2.1 20070831 patched [FreeBSD] WARNING: WITNESS option enabled, expect reduced performance. CPU: Madison (1500 MHz Itanium 2) Origin = "GenuineIntel" Revision = 5 Features = 0x1 real memory = 6442450944 (6144 MB) avail memory = 6298828800 (6007 MB) FPSWA Revision = 0x10012, Entry = 0xe040ffe60050 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0: ACPI Id=0, SAPIC Id=0, SAPIC Eid=0 (BSP) cpu1: ACPI Id=1, SAPIC Id=1, SAPIC Eid=0 random: initialized Event timer "ITC" frequency 15 Hz quality 1000 db> show thread Thread 100047 at 0xe00011973b00: proc (pid 0): 0x9ffc00c15828 name: deadlkres stack: 0xa05c4000-0xa05cbfff flags: 0x4 pflags: 0x20 state: RUNNING (CPU 1) priority: 108 container lock: sched lock 1 (0x9ffc00c3de80) db> db> show thread Thread 100047 at 0xe00011973b00: proc (pid 0): 0x9ffc00c15828 name: deadlkres stack: 0xa05c4000-0xa05cbfff flags: 0x4 pflags: 0x20 state: RUNNING (CPU 1) priority: 108 container lock: sched lock 1 (0x9ffc00c3de80) db> show proc Process 0 (kernel) at 0x9ffc00c15828: state: NORMAL uid: 0 gids: 0 ABI: null threads: 151 100355 D -0xe00012322900 [zil_clean] 100354 D -0xe00012322500 [zil_clean] 100347 D -0xe00011c4d100 [zfs_vn_rele_taskq] 100345 D -0xe00012329500 [zio_ioctl_intr] 100344 D -0xe00012329400 [zio_ioctl_issue] 100343 D -0xe00012329300 [zio_claim_intr] 100342 D -0xe00012329200 [zio_claim_issue] 100341 D -0xe00012329100 [zio_free_intr] 100340 D -0xe00012329000 [zio_free_issue_99] 100339 D -0xe00012329000 [zio_free_issue_98] 100338 D -0xe00012329000 [zio_free_issue_97] 100337 D -0xe00012329000 [zio_free_issue_96] 100336 D -0xe00012329000 [zio_free_issue_95] 100335 D -0xe00012329000 [zio_free_issue_94] 100334 D -0xe00012329000 [zio_free_issue_93] 100333 D -0xe00012329000 [zio_free_issue_92] 100332 D -0xe00012329000 [zio_free_issue_91] 100331 D -0xe00012329000 [zio_free_issue_90] 100330 D -0x
Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Wed, Sep 25, 2013 at 5:30 PM, Anton Shterenlikht wrote: > >From davide.itali...@gmail.com Wed Sep 25 16:12:47 2013 >> >>Can you please paste the output of 'show locks', 'show alllocks', >>'show lockedvnods' at least? >>Ideally you should provide all the informations listed here. >>http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html > > ok, I'll need to study this. > > I've in the kernel: > > # Debugging support. Always need this: > options KDB # Enable kernel debugger support. > options KDB_TRACE # Print a stack trace for a panic. > # For full debugger support use (turn off in stable branch): > options DDB # Support DDB > options GDB # Support remote GDB > options DEADLKRES # Enable the deadlock resolver > options INVARIANTS # Enable calls of extra sanity checking > options INVARIANT_SUPPORT # required by INVARIANTS > options WITNESS # Enable checks to detect deadlocks and cycles > options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed > options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones > > so I'm missing DEBUG_LOCKS, DEBUG_VFS_LOCKS and DIAGNOSTIC > from the handbook list. > > What about all debug options in GENERIC which are > not mentioned in your link? Specifically, do I need > to have DEADLKRES? > Yes, you need that option because it's DEADLKRES that triggers the panic. > I've never used trace. > Also, I'm getting a panic, so cannot run ps, I think. > You can run 'ps' from ddb prompt. As an advice I suggest you to setup textdump(4) on your machine and set up a script to gather the required informations, so that you can get those informations pretty easily for report. The manpage has detailed description about how to do this. > Thanks > > Anton -- Davide "There are no solved problems; there are only problems that are more or less solved" -- Henri Poincare ___ 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"
last.fm error
Hi! I tried to build last.fm on FreeBSD 10.0-ALPHA1 #0 r255501: Fri Sep 13 01:57:31 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 but it didn't work: /usr/local/bin/ld: ../build/last.fm/release/AbstractBootstrapper.o: undefined reference to symbol 'gzclose@@ZLIB_1.2.4.0' /usr/local/bin/ld: note: 'gzclose@@ZLIB_1.2.4.0' is defined in DSO //lib/libz.so.6 so try adding it to the linker command line //lib/libz.so.6: could not read symbols: Invalid operation collect2: ld returned 1 exit status *** [../bin/last.fm] Error code 1 make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src 1 error make[2]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862/src *** [sub-src-all-ordered] Error code 2 make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 1 error make[1]: stopped in /usr/ports/audio/last.fm/work/last.fm-1.5.4.26862 ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 Stop. make: stopped in /usr/ports/audio/last.fm ===>>> make failed for audio/last.fm ===>>> Aborting update ===>>> Killing background jobs Terminated Thanks in advance. -- Mitja --- http://redbubble.com/people/lumiwa ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: make_dev_credv: bad si_name (error=17, si_name=iscsi)
Wiadomość napisana przez Sergey Kandaurov w dniu 24 wrz
2013, o godz. 14:04:
> On 24 September 2013 15:44, Edward Tomasz Napierała wrote:
>> Wiadomość napisana przez Sergey Kandaurov w dniu 24 wrz
>> 2013, o godz. 13:00:
>>> On 24 September 2013 14:40, Sergey Kandaurov wrote:
On 24 September 2013 11:46, Sergey V. Dyatko
wrote:
> Hi,
>
> today I tried to play a bit with new iscsi
>
> r255812 isn't fully complete fix?
>
[...]
> run `kldload iscsi_initiator` and got a panic:
Something like this quick'n'dirty should work.
Compile tested only.
Index: sys/dev/iscsi_initiator/iscsi.c
===
--- sys/dev/iscsi_initiator/iscsi.c(revision 255841)
+++ sys/dev/iscsi_initiator/iscsi.c(working copy)
@@ -715,7 +715,8 @@
TUNABLE_INT_FETCH("net.iscsi_initiator.max_pdus", &max_pdus);
isc = malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
- isc->dev = make_dev(&iscsi_cdevsw, max_sessions, UID_ROOT,
GID_WHEEL, 0600, "iscsi");
+ isc->dev = make_dev_credf(MAKEDEV_CHECKNAME, &iscsi_cdevsw,
max_sessions,
+ NULL, UID_ROOT, GID_WHEEL, 0600, "iscsi");
isc->dev->si_drv1 = isc;
mtx_init(&isc->isc_mtx, "iscsi-isc", NULL, MTX_DEF);
>>>
>>> Erm, of course it shall be checked against failure.
>>
>> Sure. What do you think about this:
>>
>> Index: sys/dev/iscsi_initiator/iscsi.c
>> ===
>> --- sys/dev/iscsi_initiator/iscsi.c (revision 255834)
>> +++ sys/dev/iscsi_initiator/iscsi.c (working copy)
>> @@ -715,8 +715,14 @@ iscsi_start(void)
>> TUNABLE_INT_FETCH("net.iscsi_initiator.max_pdus", &max_pdus);
>>
>> isc = malloc(sizeof(struct isc_softc), M_ISCSI, M_ZERO|M_WAITOK);
>> - isc->dev = make_dev(&iscsi_cdevsw, max_sessions, UID_ROOT, GID_WHEEL,
>> 0600, "iscsi");
>> - isc->dev->si_drv1 = isc;
>> + isc->dev = make_dev_credf(MAKEDEV_CHECKNAME, &iscsi_cdevsw,
>> max_sessions,
>> + NULL, UID_ROOT, GID_WHEEL, 0600, "iscsi");
>> + if (isc->dev == NULL) {
>> + xdebug("iscsi_initiator: make_dev_credf failed");
>> + // XXX: don't return; otherwise it would panic on unload
>> + } else {
>> +isc->dev->si_drv1 = isc;
>> + }
>> mtx_init(&isc->isc_mtx, "iscsi-isc", NULL, MTX_DEF);
>>
>> TAILQ_INIT(&isc->isc_sess);
>>
>
> LGTM, except there is different indentation where for function calls
> each new line aligned with the first function argument.
Committed in a somewhat different form. I've also realized the new initiator
had a similar bug; could you please test both to make sure everything is right
now? 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: Doing it wrong: Building world with lang/clang-devel and lang/gcc49
On Tue, 2013-09-24 at 22:15 -0700, Sean Bruno wrote: > On Sun, 2013-09-22 at 16:53 -0500, Brooks Davis wrote: > > On Sat, Sep 21, 2013 at 03:42:16PM +0400, Lev Serebryakov wrote: > > > Hello, Sean. > > > You wrote 20 2013 ??., 22:39:30: > > > > > > SB> wow, that didn't work at all. :-) > > > > > > SB> I set these in make.conf: > > > > > > SB> CC=/usr/local/bin/clang > > > SB> C++=/usr/local/bin/clang++ > > > SB> CPP=/usr/local/bin/clang++ > > > > > > SB> It exploded pretty badly: > > > > > > SB> http://people.freebsd.org/~sbruno/doingitwrong.txt > > > > > > SB> Any reason that this shouldn't work? > > > Try > > > > > > XCC=/usr/local/bin/clang > > > XCXX=/usr/local/bin/clang++ > > > XCPP=/usr/local/bin/clang++ > > > COMPILER_TYPE=clang > > > > > > It should work, at least, in theory. > > > > You will likely also need -WITHOUT_FORMAT_EXTENSIONS. > > > > -- Brooks > > > Well, I've tried clang-devel, gcc46 and gcc49. Each one yeilds > different failures and I'm really just totally confused at this point. > > I've set: >export XCC=/usr/local/bin/gcc49 > export XCXX=/usr/local/bin/g++49 > export XCPP=/usr/local/bin/g++49 > export CC=/usr/local/bin/gcc49 > export CXX=/usr/local/bin/g++49 > export CPP=/usr/local/bin/g++49 > export COMPILER_TYPE=gcc > and > export TARGET=mips > export TARGET_ARCH=mips > export SRCCONF=/dev/null > export SRCROOT=/home/sbruno/bsd/fbsd_head > export MAKEOBJDIRPREFIX=/var/tmp > export DESTDIR=/mipsbuild/$TARGET_ARCH > export KERNCONF=MALTA > > > ==> usr.bin/dtc (obj,depend,all,install) > --- obj --- > /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc > created for /home/sbruno/bsd/fbsd_head/usr.bin/dtc > --- .depend --- > rm -f .depend > CC='/usr/local/bin/gcc49' mkdep -f .depend -a > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc > echo > dtc: /usr/lib/libc.a > /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib/libegacy.a >> > .depend > echo dtc: /usr/lib/libstdc++.a >> .depend > make[3]: > /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc/.depend, > 347: ignoring stale .depend for /usr/lib/libstdc++.a > --- dtc.o --- > --- input_buffer.o --- > --- string.o --- > --- dtb.o --- > --- fdt.o --- > --- checking.o --- > --- dtc.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc > --- input_buffer.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc > --- string.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc > --- dtb.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc > --- fdt.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc > --- checking.o --- > /usr/local/bin/g++49 -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc > --- string.o --- > In file included > from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.hh:35:0, > > from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.hh:35, > > from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc:33: > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:21: error: 'uint8_t' > was not declared in this scope > typedef std::vector byte_buffer; > ^ > /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:28: error: template > argument 1 is invalid > typedef std::vector byte_buffer; > > > > with gcc49 I get even more peculiar behavior: > > ===> gnu/usr.bin/gperf/doc (depend) > make[3]: > /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/.depend, > 145: ignoring stale .depend for /usr/lib/libstdc++.a > --- gperf --- > /usr/local/bin/clang++ -O2 -pipe > -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include > -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/../../../contrib/gperf/lib > -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf -static > -L/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib -o gperf > bool-array.o hash-table.o input.o keyword-list.o key
Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
>From davide.itali...@gmail.com Wed Sep 25 16:12:47 2013 > >Can you please paste the output of 'show locks', 'show alllocks', >'show lockedvnods' at least? >Ideally you should provide all the informations listed here. >http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html ok, I'll need to study this. I've in the kernel: # Debugging support. Always need this: options KDB # Enable kernel debugger support. options KDB_TRACE # Print a stack trace for a panic. # For full debugger support use (turn off in stable branch): options DDB # Support DDB options GDB # Support remote GDB options DEADLKRES # Enable the deadlock resolver options INVARIANTS # Enable calls of extra sanity checking options INVARIANT_SUPPORT # required by INVARIANTS options WITNESS # Enable checks to detect deadlocks and cycles options WITNESS_SKIPSPIN # Don't run witness on spinlocks for speed options MALLOC_DEBUG_MAXZONES=8 # Separate malloc(9) zones so I'm missing DEBUG_LOCKS, DEBUG_VFS_LOCKS and DIAGNOSTIC from the handbook list. What about all debug options in GENERIC which are not mentioned in your link? Specifically, do I need to have DEADLKRES? I've never used trace. Also, I'm getting a panic, so cannot run ps, I think. Thanks Anton ___ 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"
[SOLVED] Re: FreeBSD 10.0 Alpha 2 panic "kernel trap 12 with interrupts disable"
On Wed, Sep 25, 2013 at 12:42 AM, Miguel Clara wrote: > Sorry for the late reply... > > Worked like a charm! So the issue should be indeed fixed! > > > On Sun, Sep 22, 2013 at 10:25 PM, Miguel Clara wrote: > >> Interesting Idea... I wasn't aware the snapshots were from previous >> versions before the regressions, thanks for the heads up! >> >> Time to put this to the test, I'll report back after compiling r255788 >> thanks! >> >> >> >> > >>> > The link I gave to you contains a snapshot as per r255342 (which is >>> > way before the regression was introduced). You can use that, then >>> > checkout the sources via svnlite and rebuild. I don't see a reason why >>> > you cannot use that and you want to wait for ALPHA3, but alas. >>> > >>> >>> Alternatively, you can boot the snapshot and use the livecd >>> functionality to rebuild your existing kernel using your current >>> installation as a chroot(8) target. This should work fine regardless of >>> the revision of the snapshot. >>> >>> Glen >>> >>> >> > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
On Wed, Sep 25, 2013 at 11:11 AM, Anton Shterenlikht wrote: > FreeBSD mech-as221.men.bris.ac.uk 10.0-ALPHA2 FreeBSD 10.0-ALPHA2 #8 r255811: > Tue Sep 24 09:04:17 BST 2013 > r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 > > panic: deadlkres: possible deadlock detected for 0xe00012d07b00, blocked > for 902743 ticks > > cpuid = 1 > KDB: stack backtrace: > db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 > db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 > kdb_backtrace(0x9ffc00bfb030, 0x9ffc0045b350, 0x40c, > 0x9ffc00dd20a0) at kdb_backtrace+0xc0 > vpanic(0x9ffc00aec840, 0xa05cb518) at vpanic+0x260 > panic(0x9ffc00aec840, 0x9ffc00aecaa0, 0xe00012d07b00, 0xdc657) at > panic+0x80 > deadlkres(0xdc657, 0xe00012d07b00, 0x9ffc00aef478, > 0x9ffc00aec7d0) at deadlkres+0x420 > fork_exit(0x9ffc00b441e0, 0x0, 0xa05cb550) at fork_exit+0x120 > enter_userland() at enter_userland > KDB: enter: panic > [ thread pid 0 tid 100047 ] > Stopped at kdb_enter+0x92: [I2]addl r14=0xffe28fb0,gp ;; > db> > db> show msgbuf > > *skip* > > <118>Sep 24 09:36:02 mech-as221 su: mexas to root on /dev/pts/0 > lock order reversal: > 1st 0xa0005f0518b8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 > 2nd 0xe00012343000 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 > db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 > kdb_backtrace(0x9ffc00bfb030, 0x9ffc00509870) at kdb_backtrace+0xc0 > _witness_debugger(0x1, 0x9ffc00b01d10, 0x9ffc0050d240, 0xb9d, > 0x9ffc00b2e268) at _witness_debugger+0x60 > witness_checkorder(0xe00012343000, 0x9ffc00b01660, > 0x9ffc00b2e268, 0x11c, 0x0) at witness_checkorder+0x15b0 > _sx_xlock(0xe00012343000, 0x0, 0x9ffc00b2e268, 0x11c) at > _sx_xlock+0x120 > ufsdirhash_acquire(0xe000123bd308, 0xe00012343000, > 0x9ffc008d1920, 0x38b) at ufsdirhash_acquire+0x50 > ufsdirhash_remove(0xe000123bd308, 0xa00060ecbd08, 0x1d08, > 0xa0008fea51e8) at ufsdirhash_remove+0x20 > ufs_dirremove(0xe000123d8000, 0xe000129e29d8, 0x0, 0x0) at > ufs_dirremove+0x380 > ufs_remove(0xa0008fea5380, 0xe000129e29d8, 0xa1c) at ufs_remove+0xe0 > VOP_REMOVE_APV(0x9ffc00bc3180, 0xa0008fea5380, 0xe000122f8678, > 0x0, 0x9ffc005c2920, 0xa1c, 0x9ffc00dd20a0) at VOP_REMOVE_APV+0x220 > kern_unlinkat(0xe000123e1200, 0xff9c, 0x7fffee36, > 0x0, 0x0) at kern_unlinkat+0x3f0 > kern_unlink(0xe000123e1200, 0x7fffee36, 0x0) at kern_unlink+0x40 > sys_unlink(0xe000123e1200, 0xa0008fea54e8, 0x9ffc00988c80, 0x48d) > at sys_unlink+0x30 > syscall(0xe000123de940, 0x7fffee36, 0x7fffeb00, > 0xe000123e1200, 0x0, 0x0, 0x9ffc00983f20, 0x8) at syscall+0x5e0 > epc_syscall_return() at epc_syscall_return > <6>pid 52065 (conftest), uid 0: exited on signal 11 (core dumped) > > db> show thread > Thread 100047 at 0xe00011973b00: > proc (pid 0): 0x9ffc00c15828 > name: deadlkres > stack: 0xa05c4000-0xa05cbfff > flags: 0x4 pflags: 0x20 > state: RUNNING (CPU 1) > priority: 108 > container lock: sched lock 1 (0x9ffc00c3de80) > db> Can you please paste the output of 'show locks', 'show alllocks', 'show lockedvnods' at least? Ideally you should provide all the informations listed here. http://www.freebsd.org/doc/en/books/developers-handbook/kerneldebug-deadlocks.html Thanks, -- Davide "A mathematical theory is not to be considered complete until you have made it so clear that you can explain it to the first man whom you meet on the street." (D. Hilbert) ___ 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"
lang/gcc not build
uname FreeBSD 10.0-ALPHA2 #0 r255833M: Tue Sep 24 10:21:04 EEST 2013 - make.conf CFLAGS= -O2 -march=athlon64-sse3 -mtune=athlon64-sse3 -pipe -Qunused-parameter -Wformat -Wformat-security CPPFLAGS+= -D_FORTIFY_SOURCE=2 - Checking multilib configuration for libgcc... mkdir x86_64-portbld-freebsd10.0 mkdir x86_64-portbld-freebsd10.0/libgcc Configuring in x86_64-portbld-freebsd10.0/libgcc configure: creating cache ./config.cache checking for --enable-version-specific-runtime-libs... no checking for a BSD-compatible install... /usr/bin/install -c -o root -g wheel checking for gawk... /usr/bin/awk checking build system type... x86_64-portbld-freebsd10.0 checking host system type... x86_64-portbld-freebsd10.0 checking for x86_64-portbld-freebsd10.0-ar... /usr/local/x86_64-portbld-freebsd10.0/bin/ar checking for x86_64-portbld-freebsd10.0-lipo... lipo checking for x86_64-portbld-freebsd10.0-nm... /usr/ports/lang/gcc/work/build/./gcc/nm checking for x86_64-portbld-freebsd10.0-ranlib... /usr/local/x86_64-portbld-freebsd10.0/bin/ranlib checking for x86_64-portbld-freebsd10.0-strip... /usr/local/x86_64-portbld-freebsd10.0/bin/strip checking whether ln -s works... yes checking for x86_64-portbld-freebsd10.0-gcc... /usr/ports/lang/gcc/work/build/./gcc/xgcc -B/usr/ports/lang/gcc/work/build/./gcc/ -B/usr/local/x86_64-portbld-freebsd10.0/bin/ -B/usr/local/x86_64-portbld-freebsd10.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd10.0/include -isystem /usr/local/x86_64-portbld-freebsd10.0/sys-include checking for suffix of object files... configure: error: in `/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd10.0/libgcc': configure: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. [...] ===> Compilation failed unexpectedly. Try to set MAKE_JOBS_UNSAFE=yes and rebuild before reporting the failure to the maintainer. *** Error code 1 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: and64-build i386 mtree doesn't work too (Re: r255795/i386 built on r255795/amd64 still could not start devdpassword)
Hello, Dimitry.
You wrote 25 сентября 2013 г., 1:50:48:
>> LS>> Now I have r255795/i386 built on r255795/amd64 (with "make TARGET=i386
>> buildworld
>> LS>> buildkernel").
>> LS> Also, it could not start "make buildworld" by itself, as "mtree"
>> complains
>> LS> about line 2 of etc/mtree/BSD.usr.dist ("no parent node").
>> LS> It looks like, i386 world built by amd64 host is completely broken
>> somewhere
>> LS> in text processing tool.
>> So, nobody interested? Building 32 bit world on 64 bit host is not
>> supported now?
DA> I just tried buildworld TARGET=i386 on an amd64 host, and it worked just
DA> fine. Are you using any make.conf or src.conf?
Does result? installed via "DISTDIR" worked too?
I have my problems 100% reproducible, after 3 rebuilds and reinstalls (on
new FS).
I had only "MALLOC_PRODUCTION=yes" in my /etc/src.conf and only
port-related options (like OPTIONS_UNSET amd WRKDIRPREFIX) in
/etc/make.conf.
--
// Black Lion AKA Lev Serebryakov
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
panic: ia64 r255811: deadlkres: possible deadlock detected for 0xe000000012d07b00, blocked for 902743 ticks
FreeBSD mech-as221.men.bris.ac.uk 10.0-ALPHA2 FreeBSD 10.0-ALPHA2 #8 r255811: Tue Sep 24 09:04:17 BST 2013 r...@mech-as221.men.bris.ac.uk:/usr/obj/usr/src/sys/UZI ia64 panic: deadlkres: possible deadlock detected for 0xe00012d07b00, blocked for 902743 ticks cpuid = 1 KDB: stack backtrace: db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc00bfb030, 0x9ffc0045b350, 0x40c, 0x9ffc00dd20a0) at kdb_backtrace+0xc0 vpanic(0x9ffc00aec840, 0xa05cb518) at vpanic+0x260 panic(0x9ffc00aec840, 0x9ffc00aecaa0, 0xe00012d07b00, 0xdc657) at panic+0x80 deadlkres(0xdc657, 0xe00012d07b00, 0x9ffc00aef478, 0x9ffc00aec7d0) at deadlkres+0x420 fork_exit(0x9ffc00b441e0, 0x0, 0xa05cb550) at fork_exit+0x120 enter_userland() at enter_userland KDB: enter: panic [ thread pid 0 tid 100047 ] Stopped at kdb_enter+0x92: [I2]addl r14=0xffe28fb0,gp ;; db> db> show msgbuf *skip* <118>Sep 24 09:36:02 mech-as221 su: mexas to root on /dev/pts/0 lock order reversal: 1st 0xa0005f0518b8 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 2nd 0xe00012343000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self(0x9ffc000c9ec0) at db_trace_self+0x40 db_trace_self_wrapper(0x9ffc004d40b0) at db_trace_self_wrapper+0x70 kdb_backtrace(0x9ffc00bfb030, 0x9ffc00509870) at kdb_backtrace+0xc0 _witness_debugger(0x1, 0x9ffc00b01d10, 0x9ffc0050d240, 0xb9d, 0x9ffc00b2e268) at _witness_debugger+0x60 witness_checkorder(0xe00012343000, 0x9ffc00b01660, 0x9ffc00b2e268, 0x11c, 0x0) at witness_checkorder+0x15b0 _sx_xlock(0xe00012343000, 0x0, 0x9ffc00b2e268, 0x11c) at _sx_xlock+0x120 ufsdirhash_acquire(0xe000123bd308, 0xe00012343000, 0x9ffc008d1920, 0x38b) at ufsdirhash_acquire+0x50 ufsdirhash_remove(0xe000123bd308, 0xa00060ecbd08, 0x1d08, 0xa0008fea51e8) at ufsdirhash_remove+0x20 ufs_dirremove(0xe000123d8000, 0xe000129e29d8, 0x0, 0x0) at ufs_dirremove+0x380 ufs_remove(0xa0008fea5380, 0xe000129e29d8, 0xa1c) at ufs_remove+0xe0 VOP_REMOVE_APV(0x9ffc00bc3180, 0xa0008fea5380, 0xe000122f8678, 0x0, 0x9ffc005c2920, 0xa1c, 0x9ffc00dd20a0) at VOP_REMOVE_APV+0x220 kern_unlinkat(0xe000123e1200, 0xff9c, 0x7fffee36, 0x0, 0x0) at kern_unlinkat+0x3f0 kern_unlink(0xe000123e1200, 0x7fffee36, 0x0) at kern_unlink+0x40 sys_unlink(0xe000123e1200, 0xa0008fea54e8, 0x9ffc00988c80, 0x48d) at sys_unlink+0x30 syscall(0xe000123de940, 0x7fffee36, 0x7fffeb00, 0xe000123e1200, 0x0, 0x0, 0x9ffc00983f20, 0x8) at syscall+0x5e0 epc_syscall_return() at epc_syscall_return <6>pid 52065 (conftest), uid 0: exited on signal 11 (core dumped) db> show thread Thread 100047 at 0xe00011973b00: proc (pid 0): 0x9ffc00c15828 name: deadlkres stack: 0xa05c4000-0xa05cbfff flags: 0x4 pflags: 0x20 state: RUNNING (CPU 1) priority: 108 container lock: sched lock 1 (0x9ffc00c3de80) db> db> show proc Process 0 (kernel) at 0x9ffc00c15828: state: NORMAL uid: 0 gids: 0 ABI: null threads: 151 100354 D -0xe00012697000 [zil_clean] 100353 D -0xe0001230c100 [zil_clean] 100347 D -0xe00012311c00 [zfs_vn_rele_taskq] 100345 D -0xe00012313500 [zio_ioctl_intr] 100344 D -0xe00012313400 [zio_ioctl_issue] 100343 D -0xe00012313300 [zio_claim_intr] 100342 D -0xe00012313200 [zio_claim_issue] 100341 D -0xe00012313100 [zio_free_intr] 100340 D -0xe00012313000 [zio_free_issue_99] 100339 D -0xe00012313000 [zio_free_issue_98] 100338 D -0xe00012313000 [zio_free_issue_97] 100337 D -0xe00012313000 [zio_free_issue_96] 100336 D -0xe00012313000 [zio_free_issue_95] 100335 D -0xe00012313000 [zio_free_issue_94] 100334 D -0xe00012313000 [zio_free_issue_93] 100333 D -0xe00012313000 [zio_free_issue_92] 100332 D -0xe00012313000 [zio_free_issue_91] 100331 D -0xe00012313000 [zio_free_issue_90] 100330 D -0xe00012313000 [zio_free_issue_89] 100329 D -0xe00012313000 [zio_free_issue_88] 100328 D -0xe00012313000 [zio_free_issue_87] 100327
