avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
on 11/07/2010 15:23 Andriy Gapon said the following:
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly and
the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
As was speculated above, the only thing really changed is section alignment
(from 128 to 4).
After making the above analysis I wondered why we require set_pcpu section
alignment at all. After all, it's not used as loaded, data from the section
gets copied into special per-cpu memory areas. So, logically, it's those
areas
that need to be aligned, not the section.
svn log and google quickly pointed me to this excellent analysis and
explanation
by bz (thanks again!):
http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
Summary: this alignment is needed to work around a bug in GNU binutils ld for
__start_SECNAME placement.
As explained by bz, ld internally generates an equivalent of the following
linker script:
...
__start_pcpu_set = ALIGN(NN);
pcpu_set : {
...
}
__stop_pcpu_set = .;
Where NN is an alignment of the first _input_ pcpu_set section found in
whichever .o file happens to be first. Not the resulting alignment of
pcpu_set
_output_ section.
Alignment requirement of input sections is based on largest alignment
requirement of section's members. So if section is empty then the required
alignment is 1. Alignment of output section, if not explicitly overridden
e.g.
via linker script, is the largest alignment of the corresponding input
sections.
I think that the problem can be fixed by making ld define __start_SECNAME like
follows:
...
pcpu_set : {
__start_pcpu_set = ABSOLUTE(.);
...
}
__stop_pcpu_set = .;
This way __start_SECNAME would always point to the actual start of the output
section.
Here's a patch that implements the idea:
http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
This is similar to what was done upstream:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306r2=1.307cvsroot=srcf=h
The code is quite different there, and approach is somewhat different, but the
idea is the same - place __start_SECNAME inside the section, not outside it.
Does anybody see any obvious or non-obvious flaw in the above analysis and the
proposed patches?
Does anyone object against me committing the ld patch and some time later the
pcpu.h patch?
My plan is to commit the ld patch tomorrow and the pcpu.h patch early next week.
P.S.
Pro-active testing is welcome! Especially if you have an unusual architecture
or use epair or both.
--
Andriy Gapon
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [TESTING]: updated clang/LLVM needs testing in ClangBSD
2010/7/14 Roman Divacky rdiva...@freebsd.org: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld And here my buildworld fails with: === lib/clang/libclanglex (depend) tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticCommonKinds.inc.h tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticLexKinds.inc.h rm -f .depend CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -DCLANG_VENDOR=\FreeBSD\ \ -DSVN_REVISION=\108243\ -DCLANG_VENDOR_SUFFIX=\\ 20100713\ /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/ScratchBuffer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/TokenConcatenation.cpp
Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
On Thu, Jul 15, 2010 at 02:25:26PM +0300, Andriy Gapon wrote:
on 11/07/2010 15:23 Andriy Gapon said the following:
on 11/07/2010 14:54 Andriy Gapon said the following:
For completeness, here is a patch that simply drops the inline assembly
and the
comment about it, and GCC-generated assembly and its diff:
http://people.freebsd.org/~avg/dpcpu/pcpu.new.patch
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.s
http://people.freebsd.org/~avg/dpcpu/dpcpu.new.diff
As was speculated above, the only thing really changed is section alignment
(from 128 to 4).
After making the above analysis I wondered why we require set_pcpu section
alignment at all. After all, it's not used as loaded, data from the section
gets copied into special per-cpu memory areas. So, logically, it's those
areas
that need to be aligned, not the section.
svn log and google quickly pointed me to this excellent analysis and
explanation
by bz (thanks again!):
http://people.freebsd.org/~bz/20090809-02-pcpu-start-align-fix.diff
Summary: this alignment is needed to work around a bug in GNU binutils ld
for
__start_SECNAME placement.
As explained by bz, ld internally generates an equivalent of the following
linker script:
...
__start_pcpu_set = ALIGN(NN);
pcpu_set : {
...
}
__stop_pcpu_set = .;
Where NN is an alignment of the first _input_ pcpu_set section found in
whichever .o file happens to be first. Not the resulting alignment of
pcpu_set
_output_ section.
Alignment requirement of input sections is based on largest alignment
requirement of section's members. So if section is empty then the required
alignment is 1. Alignment of output section, if not explicitly overridden
e.g.
via linker script, is the largest alignment of the corresponding input
sections.
I think that the problem can be fixed by making ld define __start_SECNAME
like
follows:
...
pcpu_set : {
__start_pcpu_set = ABSOLUTE(.);
...
}
__stop_pcpu_set = .;
This way __start_SECNAME would always point to the actual start of the
output
section.
Here's a patch that implements the idea:
http://people.freebsd.org/~avg/dpcpu/ld.start_sec-alignment.patch
This is similar to what was done upstream:
http://sourceware.org/cgi-bin/cvsweb.cgi/src/ld/ldlang.c.diff?r1=1.306r2=1.307cvsroot=srcf=h
The code is quite different there, and approach is somewhat different, but
the
idea is the same - place __start_SECNAME inside the section, not outside it.
Does anybody see any obvious or non-obvious flaw in the above analysis and the
proposed patches?
Does anyone object against me committing the ld patch and some time later the
pcpu.h patch?
My plan is to commit the ld patch tomorrow and the pcpu.h patch early next
week.
P.S.
Pro-active testing is welcome! Especially if you have an unusual
architecture
or use epair or both.
Is new behaviour completely identical to the behaviour of the newer
ld ? Even if yes, I think that such changes make potential import of
newer binutils harder.
pgpTCQwf8PSpI.pgp
Description: PGP signature
Re: avoid producing empty set_pcpu section [Was: elf obj load: skip zero-sized sections early]
on 15/07/2010 14:39 Kostik Belousov said the following: Is new behaviour completely identical to the behaviour of the newer ld ? No, it's not completely identical. __start_SECNAME placement would be identical, but our ld would still assign the symbol while latest upstream binutils PROVIDES it. Even if yes, I think that such changes make potential import of newer binutils harder. How? -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2010-07-15 12:35:16 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-15 12:35:16 - starting HEAD tinderbox run for mips/mips TB --- 2010-07-15 12:35:16 - cleaning the object tree TB --- 2010-07-15 12:35:28 - cvsupping the source tree TB --- 2010-07-15 12:35:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-07-15 12:35:57 - building world TB --- 2010-07-15 12:35:57 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-15 12:35:57 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-15 12:35:57 - TARGET=mips TB --- 2010-07-15 12:35:57 - TARGET_ARCH=mips TB --- 2010-07-15 12:35:57 - TZ=UTC TB --- 2010-07-15 12:35:57 - __MAKE_CONF=/dev/null TB --- 2010-07-15 12:35:57 - cd /src TB --- 2010-07-15 12:35:57 - /usr/bin/make -B buildworld /src/Makefile.inc1, line 1484: ERROR: kernel config file not found. *** Error code 1 Stop in /src. TB --- 2010-07-15 12:35:57 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-15 12:35:57 - ERROR: failed to build world TB --- 2010-07-15 12:35:57 - 2.39 user 10.01 system 41.80 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ 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
current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) -- Ståle Kristoffersen ___ 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: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 2010-07-15 at 14:34, Ståle Kristoffersen wrote: Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) Just to be complete: I also get this LOR at boot: lock order reversal: 1st 0xff80a5108b38 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:2607 2nd 0xff0002dc6000 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:283 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _sx_xlock() at _sx_xlock+0x55 ufsdirhash_acquire() at ufsdirhash_acquire+0x33 ufsdirhash_remove() at ufsdirhash_remove+0x16 ufs_dirremove() at ufs_dirremove+0x1a4 ufs_remove() at ufs_remove+0x92 VOP_REMOVE_APV() at VOP_REMOVE_APV+0x93 kern_unlinkat() at kern_unlinkat+0x2cb syscallenter() at syscallenter+0x1b5 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (10, FreeBSD ELF64, unlink), rip = 0x80072f3cc, rsp = 0x7fffdb08, rbp = 0x7fffef58 --- lock order reversal: 1st 0xff00407a4458 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:1058 2nd 0xff00407aedb8 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2090 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e __lockmgr_args() at __lockmgr_args+0xd11 vop_stdlock() at vop_stdlock+0x39 VOP_LOCK1_APV() at VOP_LOCK1_APV+0x9b _vn_lock() at _vn_lock+0x47 vget() at vget+0x7b devfs_allocv() at devfs_allocv+0x100 devfs_root() at devfs_root+0x48 vfs_donmount() at vfs_donmount+0xfb2 nmount() at nmount+0x63 syscallenter() at syscallenter+0x1b5 syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (378, FreeBSD ELF64, nmount), rip = 0x8007b2b4c, rsp = 0x7fffdd28, rbp = 0x800c09048 --- -- Ståle Kristoffersen ___ 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: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) What revision were you using? Does using current as of r209598 make a difference? Marius ___ 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: [TESTING]: updated clang/LLVM needs testing in ClangBSD
I updated clang/LLVM in clangbsd to a newer version which I believe will fix thas. can you rene (and everyone else) please retest with updated ClangBSD and report back? thank you! On Thu, Jul 15, 2010 at 01:33:04PM +0200, Ren? Ladan wrote: 2010/7/14 Roman Divacky rdiva...@freebsd.org: hi, ClangBSD was updated to LLVM/clang revision r108243 which we plan to merge into HEAD. We would like that revision to be tested as much as possible and therefore we ask you to test ClangBSD to assure that the revision we are updating to does not have some really embarassing bugs. How to do it (on i386 and amd64): 0) install fresh devel/llvm-devel port 1) svn co http://svn.freebsd.org/base/projects/clangbsd src 2) echo NO_WERROR= /etc/src.conf ; echo WERROR= /etc/src.conf 3) cd src make buildworld And here my buildworld fails with: === lib/clang/libclanglex (depend) tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Common /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticCommonKinds.inc.h tblgen -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic -gen-clang-diags-defs -clang-component=Lex /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include/clang/Basic/Diagnostic.td DiagnosticLexKinds.inc.h rm -f .depend CC='clang -isysroot /usr/obj/usr/home/rene/freebsd/clangbsd/tmp -B/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/ -L/usr/obj/usr/home/rene/freebsd/clangbsd/tmp/usr/lib/' mkdep -f .depend -a -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/include -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex -I. -I/usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -DLLVM_HOSTTRIPLE=\amd64-undermydesk-freebsd9.0\ -DCLANG_VENDOR=\FreeBSD\ \ -DSVN_REVISION=\108243\ -DCLANG_VENDOR_SUFFIX=\\ 20100713\ /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderMap.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/HeaderSearch.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Lexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/LiteralSupport.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroArgs.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/MacroInfo.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPCaching.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPDirectives.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPExpressions.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPLexerChange.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PPMacroExpansion.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PTHLexer.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Pragma.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessingRecord.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/Preprocessor.cpp /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp
Re: current + mpt = panic: Bad link elm 0xffffff80002d6480 next-prev != elm
On 2010-07-15 at 18:00, Marius Strobl wrote: On Thu, Jul 15, 2010 at 02:34:23PM +0200, Stle Kristoffersen wrote: Upgraded to from stable to current yesterday and very quickly received a panic. It did however not dump it's core, so I was unable to debug it. Today it did panic again, and I took a picture: (Sorry about the bad quality) http://folk.uio.no/stalk/mpt/IMG_1403.JPG And from the backtrace: http://folk.uio.no/stalk/mpt/IMG_1404.JPG Both times I hade the mpt0: request timed out just before the panic. I'm not sure why it's not dumping it's core (It was working under stable, and I have dumpdev=AUTO and dumpdir=/var/crash in rc.conf) What revision were you using? Not sure exactly what revision I was using, is there an easy way to figure that out? I ran cvsupdate around 13:00 CEST yesterday. Does using current as of r209598 make a difference? Downgrading now... -- Ståle Kristoffersen staal...@ifi.uio.no ___ 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
can't checkout svn on cygwin
ssA and ssa conflict $ ~/repos/fbsd/base/head/share/doc/psd svn up A15.yacc A15.yacc/ss.. A15.yacc/ssA A15.yacc/ssa A15.yacc/ssb A15.yacc/ssB A15.yacc/ssc A15.yacc/ssd A15.yacc/ss0 A15.yacc/ss1 A15.yacc/ref.bib A15.yacc/ss2 A15.yacc/ss3 A15.yacc/ss4 A15.yacc/ss5 A15.yacc/ss6 A15.yacc/ss7 A15.yacc/ss8 A15.yacc/Makefile A15.yacc/ss9 svn: In directory '15.yacc' svn: Can't open file '15.yacc/.svn/tmp/text-base/ssa.svn-base': No such file or directory -- Philip M. Gollucci (pgollu...@ridecharge.com) p: 703.549.2050x206, did: 703.579.6947 Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
On 07/15/2010 17:57, Philip M. Gollucci wrote: ssA and ssa conflict $ ~/repos/fbsd/base/head/share/doc/psd svn up A15.yacc A15.yacc/ss.. A15.yacc/ssA A15.yacc/ssa A15.yacc/ssb A15.yacc/ssB A15.yacc/ssc A15.yacc/ssd A15.yacc/ss0 A15.yacc/ss1 A15.yacc/ref.bib A15.yacc/ss2 A15.yacc/ss3 A15.yacc/ss4 A15.yacc/ss5 A15.yacc/ss6 A15.yacc/ss7 A15.yacc/ss8 A15.yacc/Makefile A15.yacc/ss9 svn: In directory '15.yacc' svn: Can't open file '15.yacc/.svn/tmp/text-base/ssa.svn-base': No such file or directory Looks to be a problem with your local .svn directory. Run the following in the psd directory. rm -rf 15.yacc svn update This should fix it up for whatever happened. If not then backup one directory rm that directory and repeat. The base repository is clean. Regards, -- jhell,v ___ 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
Clock not moving in virtual machine
Hi, I have a VPS from rootbsd.net which is running current, though I don't update it very often. I just built and installed a new world and kernel and now the clock will not move from the time the system was booted, ie: # date Thu Jul 15 16:15:58 PDT 2010 wait a minute # date Thu Jul 15 16:15:58 PDT 2010 I have an old kernel from May 27 which doesn't have this problem. I noticed some clock related stuff changing in current in the last couple of weeks and suspect that their VM setup doesn't play well with these changes (their site says they use Xen, but several boot messages refer to QEMU). Officially, I think they only support running 8.0 so I thought I would ask here if anyone has any ideas before putting in a support request. Here's a diff of the dmesgs - I can post full copies if needed but didn't want to start with a ridicously long message: --- dmesg.old 2010-07-15 17:45:20.0 -0700 +++ dmesg.new 2010-07-15 17:46:45.0 -0700 @@ -2,10 +2,9 @@ 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 #0: Thu May 27 01:26:08 PDT 2010 +FreeBSD 9.0-CURRENT #0: Thu Jul 15 16:13:28 PDT 2010 rfar...@peridot.predatorlabs.net:/usr/obj/usr/src/sys/PERIDOT i386 -Timecounter i8254 frequency 1193182 Hz quality 0 -CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.02-MHz 686-class CPU) +CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.59-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106a5 Family = 6 Model = 1a Stepping = 5 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80182201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,b31 @@ -13,9 +12,10 @@ AMD Features2=0x1LAHF TSC: P-state invariant real memory = 268435456 (256 MB) -avail memory = 252473344 (240 MB) -ACPI Error: A valid RSDP was not found (20100428/tbxfroot-309) +avail memory = 252444672 (240 MB) +ACPI Error: A valid RSDP was not found (20100702/tbxfroot-309) MPTable: _HVMCPU_ XEN +Event timer LAPIC frequency 0 Hz quality 500 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 0 package(s) x 16 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 @@ -26,7 +26,7 @@ ioapic0: Assuming intbase of 0 ioapic0 Version 1.1 irqs 0-47 on motherboard kbd1 at kbdmux0 -ACPI Error: A valid RSDP was not found (20100428/tbxfroot-309) +ACPI Error: A valid RSDP was not found (20100702/tbxfroot-309) ACPI: Table initialisation failed: AE_NOT_FOUND ACPI: Try disabling either ACPI or apic support. pcib0: Host to PCI bridge pcibus 0 on motherboard @@ -81,7 +81,10 @@ ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: Parallel port bus on ppc0 -atrtc0: AT Real Time Clock at port 0x70 irq 8 on isa0 +atrtc0: AT realtime clock at port 0x70 irq 8 on isa0 +atrtc0: [FILTER] +Event timer RTC frequency 32768 Hz quality 0 +Starting kernel event timers: LAPIC @ 200Hz, RTC @ 128Hz Timecounters tick every 5.000 msec ad0: 10240MB QEMU HARDDISK 0.10.2 at ata0-master WDMA2 SMP: AP CPU #1 Launched! Thanks, -- Rob Farmer ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
On 07/15/2010 20:09, Philip M. Gollucci wrote: On 7/15/2010 7:17 PM, jhell wrote: Looks to be a problem with your local .svn directory. Run the following in the psd directory. rm -rf 15.yacc svn update This should fix it up for whatever happened. If not then backup one directory rm that directory and repeat. I did this long before I sent the e-mail. Makes no difference. How far up the tree did you go back ? Example: cd ../ rm -rf ./* svn update My guess is that this has perpetuated all the way to the root of checkout and it might just be best to checkout the entire source once more. As more information. I can checkout that part of the tree and the entire contents for each one of the directories and there was no problem. have you run svn cleanup ? -- jhell,v ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
On 7/15/2010 8:35 PM, jhell wrote: How far up the tree did you go back ? The whole way, and I've re-checked out the whole tree again. As more information. I can checkout that part of the tree and the entire contents for each one of the directories and there was no problem. Are you doing this on a cygwin install on vista ? It works fine on *Unix have you run svn cleanup ? of course Lets pretend I'm one of the admins of svn.apache.org -- I know how to use svn. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: can't checkout svn on cygwin
On Thu, Jul 15, 2010 at 08:57:39PM -0400, Philip M. Gollucci wrote: On 7/15/2010 8:35 PM, jhell wrote: How far up the tree did you go back ? The whole way, and I've re-checked out the whole tree again. As more information. I can checkout that part of the tree and the entire contents for each one of the directories and there was no problem. Are you doing this on a cygwin install on vista ? It works fine on *Unix Then, it's not a FreeBSD problem. Try asking microsoft and the cygwin developers for help. -- Steve ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
On 7/15/2010 9:56 PM, Steve Kargl wrote: Then, it's not a FreeBSD problem. Try asking microsoft and the cygwin developers for help. I didn't say it was a freebsd problem. I know there have been time in the past where we try to keep this working on Case Insensitive systems. -- 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Philip M. Gollucci (pgollu...@p6m7g8.com) c: 703.336.9354 VP Apache Infrastructure; Member, Apache Software Foundation Committer,FreeBSD Foundation Consultant, P6M7G8 Inc. Sr. System Admin, Ridecharge Inc. Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. signature.asc Description: OpenPGP digital signature
Re: can't checkout svn on cygwin
On Thu, Jul 15, 2010 at 05:57:22PM -0400, Philip M. Gollucci wrote: ssA and ssa conflict Yeah, there used to be at least 7 examples of files differing only in case in our repository. Several of these have been fixed but it looks like there's still the following: share/doc/psd/15.yacc/ssa share/doc/psd/15.yacc/ssA share/doc/psd/15.yacc/ssb share/doc/psd/15.yacc/ssB share/man/man9/vfs_mount.9 share/man/man9/VFS_MOUNT.9 For the first two I'd propose renaming ss.. to ss_, ssA to ss10 and ssB to ss11. Index: Makefile === --- Makefile(revision 210153) +++ Makefile(working copy) @@ -2,8 +2,8 @@ # $FreeBSD$ VOLUME=psd/15.yacc -SRCS= stubs ss.. ss0 ss1 ss2 ss3 ss4 ss5 ss6 ss7 ss8 ss9 \ - ssA ssB ssa ssb ssc ssd +SRCS= stubs ss_ ss0 ss1 ss2 ss3 ss4 ss5 ss6 ss7 ss8 ss9 \ + ss10 ss11 ssa ssb ssc ssd EXTRA= ref.bib MACROS=-ms USE_REFER= I'm not sure if there's an easy way to deal with vfs_mount.9 vs VFS_MOUNT.9 though. -Ed ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
In the last episode (Jul 15), Philip M. Gollucci said: On 7/15/2010 8:35 PM, jhell wrote: How far up the tree did you go back ? The whole way, and I've re-checked out the whole tree again. As more information. I can checkout that part of the tree and the entire contents for each one of the directories and there was no problem. Are you doing this on a cygwin install on vista ? It works fine on *Unix have you run svn cleanup ? of course Lets pretend I'm one of the admins of svn.apache.org -- I know how to use svn. Until the offending files get fixed, you can try enabling NTFS case sensitivity on your Windows system: http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive -- Dan Nelson dnel...@allantgroup.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on mips/mips
TB --- 2010-07-16 03:20:35 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-07-16 03:20:35 - starting HEAD tinderbox run for mips/mips TB --- 2010-07-16 03:20:35 - cleaning the object tree TB --- 2010-07-16 03:20:35 - cvsupping the source tree TB --- 2010-07-16 03:20:35 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2010-07-16 03:21:09 - building world TB --- 2010-07-16 03:21:09 - MAKEOBJDIRPREFIX=/obj TB --- 2010-07-16 03:21:09 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-07-16 03:21:09 - TARGET=mips TB --- 2010-07-16 03:21:09 - TARGET_ARCH=mips TB --- 2010-07-16 03:21:09 - TZ=UTC TB --- 2010-07-16 03:21:09 - __MAKE_CONF=/dev/null TB --- 2010-07-16 03:21:09 - cd /src TB --- 2010-07-16 03:21:09 - /usr/bin/make -B buildworld World build started on Fri Jul 16 03:21:10 UTC 2010 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries [...] === lib/libalias/modules/cuseeme (all) cc -O -pipe -EL -G0 -std=gnu99 -Wsystem-headers -Werror -Wno-pointer-sign -c /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_cuseeme.c cc1: warnings being treated as errors In file included from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_sctp.h:83, from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_local.h:63, from /src/lib/libalias/modules/cuseeme/../../../../sys/netinet/libalias/alias_cuseeme.c:52: /obj/mips.mips/src/tmp/usr/include/machine/cpu.h: In function 'get_cyclecount': /obj/mips.mips/src/tmp/usr/include/machine/cpu.h:84: warning: implicit declaration of function 'mips_rd_count' *** Error code 1 Stop in /src/lib/libalias/modules/cuseeme. *** Error code 1 Stop in /src/lib/libalias/modules. *** Error code 1 Stop in /src/lib/libalias. *** Error code 1 Stop in /src/lib. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-07-16 03:47:54 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-07-16 03:47:54 - ERROR: failed to build world TB --- 2010-07-16 03:47:54 - 1129.48 user 289.05 system 1638.48 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: can't checkout svn on cygwin
On 7/15/2010 7:17 PM, jhell wrote: Looks to be a problem with your local .svn directory. Run the following in the psd directory. rm -rf 15.yacc svn update This should fix it up for whatever happened. If not then backup one directory rm that directory and repeat. I did this long before I sent the e-mail. Makes no difference. -- Philip M. Gollucci (pgollu...@ridecharge.com) p: 703.549.2050x206, did: 703.579.6947 Senior System Admin - RideCharge, Inc. http://ridecharge.com 1024D/DB9B8C1C B90B FBC3 A3A1 C71A 8E70 3F8C 75B8 8FFB DB9B 8C1C Work like you don't need the money, love like you'll never get hurt, and dance like nobody's watching. ___ 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
