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.306&r2=1.307&cvsroot=src&f=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 : > 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 /usr/home/rene/freebsd/clangbsd/lib/clang/libclanglex/../../../contrib/llvm/tools/clang/li
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.306&r2=1.307&cvsroot=src&f=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 : > > 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/libclang
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 # 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=0x1781fbff Features2=0x80182201> @@ -13,9 +12,10 @@ AMD Features2=0x1 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 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: pcibus 0 on motherboard @@ -81,7 +81,10 @@ ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode ppc0: [ITHREAD] ppbus0: on ppc0 -atrtc0: at port 0x70 irq 8 on isa0 +atrtc0: 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 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"
Re: Clock not moving in virtual machine
Rob Farmer wrote: > 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 > > # 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: > 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 Probably not related, but funny. :) So you have two CPUs? > @@ -81,7 +81,10 @@ > ppc0: Generic chipset (NIBBLE-only) in COMPATIBLE mode > ppc0: [ITHREAD] > ppbus0: on ppc0 > -atrtc0: at port 0x70 irq 8 on isa0 > +atrtc0: 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 Everything seems reasonable there. Try to collect more information: sysctl kern.timecounter sysctl kern.eventtimer vmstat -ia systat -vm 1 (presence and frequencies of interrupts) It could be a bug in emulation of some timers or bug in respective timer driver, which was not triggered before last changes. You may try switch to different timecounter by setting kern.timecounter.hardware, or different eventtimers by setting kern.eventtimer.timer1 and kern.eventtimer.timer2 sysctls. -- Alexander Motin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
