Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On 2012-11-06 23:59, Mike Jakubik wrote:> I've ran in to this issue on two different machines, both have recent stable code. The problem appears to be with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. ... 1 error *** Error code 2 1 error *** Error code 2 1 error The output you pasted looks like it was produced by a multi-threaded build, and the actual error was obscured. Can you please retry this with a single-threaded build? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On 11/07/12 09:43, Dimitry Andric wrote: > On 2012-11-06 23:59, Mike Jakubik wrote:> >> I've ran in to this issue on two different machines, both have recent >> stable code. The problem appears to be >> with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > ... >> 1 error >> *** Error code 2 >> 1 error >> *** Error code 2 >> 1 error > > The output you pasted looks like it was produced by a multi-threaded > build, and the actual error was obscured. Can you please retry this > with a single-threaded build? > > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org" > I'm not the original poster, but I've seen the same problem on 2 different machines as well. I just finished a single-threaded buildworld; it dies building boot2. svn says I'm "At revision 242695." The relevant portion of make.conf: CC=clang CXX=clang++ CPP=clang-cpp # build world without -Werror NO_WERROR= # CPUTYPE?=core2 WITH_OPTIMIZED_CFLAGS=yes ===> sys/boot/i386/boot2 (all) objcopy -S -O binary boot1.out boot1 dd if=/dev/zero of=boot2.ldr bs=512 count=1 1+0 records in 1+0 records out 512 bytes transferred in 0.21 secs (24403223 bytes/sec) clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -Qunused-arguments -S -o boot2.s.tmp /usr/src/sys/boot/i386/boot2/boot2.c clang: warning: the clang compiler does not support '-fno-unit-at-a-time' In file included from /usr/src/sys/boot/i386/boot2/boot2.c:170: /usr/src/sys/boot/i386/boot2/../../common/ufsread.c:233:17: warning: cast from 'char *' to 'struct ufs1_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp1, (struct ufs1_dinode *)blkbuf + n, ^~~~ /usr/src/sys/boot/i386/boot2/../../common/ufsread.c:236:17: warning: cast from 'char *' to 'struct ufs2_dinode *' increases required alignment from 1 to 4 [-Wcast-align] memcpy(&dp2, (struct ufs2_dinode *)blkbuf + n, ^~~~ /usr/src/sys/boot/i386/boot2/boot2.c:222:1: warning: no previous prototype for function 'main' [-Wmissing-prototypes] main(void) ^ /usr/src/sys/boot/i386/boot2/boot2.c:353:4: warning: cast from 'caddr_t' (aka 'char *') to 'Elf32_Word *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] *(Elf32_Word *)p = es[i].sh_size; ^~~ /usr/src/sys/boot/i386/boot2/boot2.c:619:8: warning: cast from 'caddr_t' (aka 'char *') to 'uint32_t *' (aka 'unsigned int *') increases required alignment from 1 to 4 [-Wcast-align] t1 = *(uint32_t *)PTOV(0x46c); ^~~ 5 warnings generated. sed -e '/align/d' -e '/nop/d' < boot2.s.tmp > boot2.s rm -f boot2.s.tmp clang -m32 -c boot2.s clang -Os -fno-guess-branch-probability -fomit-frame-pointer -fno-unit-at-a-time -mno-align-long-strings -mrtd -mregparm=3 -DUSE_XREAD -DUFS1_AND_UFS2 -DFLAGS=0x80 -DSIOPRT=0x3f8 -DSIOFMT=0x3 -DSIOSPD=9600 -I/usr/src/sys/boot/i386/boot2/../../common -I/usr/src/sys/boot/i386/boot2/../btx/lib -I. -Wall -Waggregate-return -Wbad-function-cast -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wnested-externs -Wpointer-arith -Wshadow -Wstrict-prototypes -Wwrite-strings -Winline --param max-inline-insns-single=100 -mstack-alignment=8 -mllvm -inline-threshold=3 -mllvm -enable-load-pre=false -mllvm -simplifycfg-dup-ret -ffreestanding -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -msoft-float -m32 -march=i386 -std=gnu99 -Qunused-arguments -m32 -c /usr/src/sys/boot/i386/boot2/sio.S clang: warning: the clang compiler does not support '-fno-unit-at-a-time' ld -static -N --gc-sections -nostdlib -m elf_i386_fbsd -Ttext 0x2000 -o boot2.out /misc/obj/usr/src/sys/boot/i386/boot2/../btx/lib/crt0.o boot2.o sio.o objcopy -S -O binary boot2.out boot2.bin btxld -v -E 0x2000 -f bin -b /misc/obj/usr/src/sys/boot/i386/boot2/../btx/btx/btx -l boot2.ldr -o boot2.ld -P 1 boot2.bin kernel: ver=1.02 size
Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On Wed, 2012-11-07 at 15:43 +0100, Dimitry Andric wrote: > On 2012-11-06 23:59, Mike Jakubik wrote:> > > I've ran in to this issue on two different machines, both have recent > > stable code. The problem appears to be > > with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > ... > > 1 error > > *** Error code 2 > > 1 error > > *** Error code 2 > > 1 error > > The output you pasted looks like it was produced by a multi-threaded > build, and the actual error was obscured. Can you please retry this > with a single-threaded build? > I resumed the build without -j4 and with NOCLEAN=YES and it finished successfully. I will do a clean and try again. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On Wed, 2012-11-07 at 13:45 -0500, Mike Jakubik wrote: > On Wed, 2012-11-07 at 15:43 +0100, Dimitry Andric wrote: > > On 2012-11-06 23:59, Mike Jakubik wrote:> > > > I've ran in to this issue on two different machines, both have recent > > > stable code. The problem appears to be > > > with /usr/src/gnu/usr.bin/texinfo, i am using Clang to compile. > > ... > > > 1 error > > > *** Error code 2 > > > 1 error > > > *** Error code 2 > > > 1 error > > > > The output you pasted looks like it was produced by a multi-threaded > > build, and the actual error was obscured. Can you please retry this > > with a single-threaded build? > > > > I resumed the build without -j4 and with NOCLEAN=YES and it finished > successfully. I will do a clean and try again. > Oops, i did this on the wrong server. On the right server it fails compiling boot2 just like Richard describes. Thanks. ===> sys/boot/i386/boot2 (all) -5 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On 2012-11-07 19:54, Mike Jakubik wrote: ... Oops, i did this on the wrong server. On the right server it fails compiling boot2 just like Richard describes. Thanks. ===> sys/boot/i386/boot2 (all) -5 bytes available *** Error code 1 Stop in /usr/src/sys/boot/i386/boot2. *** Error code 1 Ah yes, I got it. This is currently a problem on stable/9, for which I don't yet have an easy solution, except building boot2 with gcc for now. See the earlier thread on freebsd-stable here: http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070459.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Error compiling world (usr/src/gnu/usr.bin/texinfo) w/ Clang
On Wed, 2012-11-07 at 20:04 +0100, Dimitry Andric wrote: > Ah yes, I got it. This is currently a problem on stable/9, for which I > don't yet have an easy solution, except building boot2 with gcc for now. > > See the earlier thread on freebsd-stable here: > http://lists.freebsd.org/pipermail/freebsd-stable/2012-November/070459.html Sounds like using gcc for boot2 is the current work around till Clang 3.2 makes it in to stable. Thanks. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: mfi panic on recused on non-recusive mutex MFI I/O lock
- Original Message - From: "Steven Hartland" On Tue, Nov 06, 2012 at 12:09:42AM -, Steven Hartland wrote: | Thanks Doug, actually just finished another test run with some more | debugging in and I believe I've found the reason for the non-recusive | lock and at least some of the queuing issues. | | The non-recursive lock is due to the mfi_tbolt_reset calling | mfi_process_fw_state_chg_isr with mfi_io_lock held which in turn calls | mfi_tbolt_init_MFI_queue which tries to acquire mfi_io_lock hence | the problem. | | mfi-lock.txt attached I believe fixes this as well as what appears | to be an invalid call to mtx_unlock(&sc->mfi_io_lock) in mfi_attach | which never acquires the lock as far as can see, possibly a cut and | paste error. I don't seem to see the attachment. Yer seems like some mail fail by me there, but I've had some more locking panics during todays tests anyway, requiring additional fixes. Will update and post when I'm happy with it. OK two patches attached == zz-mfi-lock.patch == Fixes mfi panic on recused on non-recusive mutex MFI I/O lock Removes a mtx_unlock call for mfi_io_lock which is never aquired == zz-mfi-queue.patch == Fixes queuing issues where mfi_release_command blindly sets the cm_flags = 0 without first removing the command from the relavent queue. This was causing panics in the queue functions which check to ensure a command is not on another queue. Also fixed some cases where the error from mfi_mapcmd was lost and where the command was never released / dequeued in error cases. Ensure that all failures to mfi_mapcmd are logged Fixed possible null pointer exception in mfi_aen_setup if mfi_get_log_state failed. Fixed mfi_parse_entries & mfi_aen_setup not returning possible errors Corrected MFI_DUMP_CMDS calls with invalid vars SC vs sc Commands which have timed out now set cm_error to ETIMEDOUT and call mfi_complete which prevents them getting stuck in the busy queue forever. Fixed possible use of NULL pointer in mfi_tbolt_get_cmd Changed output formats to be more easily recognisable when debugging. A few style (9) fixes e.g. braced single line conditions and double blank lines -- I've just had another panic, trace below, but it doesn't seem to be related to my changes so I'd appreciate your feedback on them as they are for now. While the lock patch fixes the problems I've seen, its not clear to me why mfi_tbolt_reset is acquiring the lock and hence requiring mfi_process_fw_state_chg_isr to jump through hoops to ensure locking around queue manipulation is done correctly. Given what its doing (resetting the entire adapter) I wouldn't be surprised if it should really be acquiring the config lock. Other things I've noticed / questions * Should mfi_abort sleep even if its call to mfi_mapcmd fails? * Should mfi_get_controller_info really ignore the error from mfi_mapcmd? * Do these controllers not support none 512 byte requests? Currently all syspd requests are done assuming 512 byte sectors which the disk may not be. This will both reduce performance or potentially break totally if the firmware isn't translating it under the surface correctly. Anyway the new panic manually transcribed is:- panic: Bad linx elm 0xff0069b0fc0 next->prev != elm ... mfi_tbolt_get_cmd() mfi_build_mpt_pass_thru() mfi_tbolt_build_mpt_cmd() mfi_tbolt_send_frame() bus_dmamap_load() mfi_mapcmd() mfi_startio() mfi_syspd_strategy() g_disk_start() g_io_schedule_down() g_down_proc_body() fork_exit() fork_trampoline() Looks like mfi_cmd_tbolt_tqh has become corrupt some how, but as far as I can tell all manip is done using the TAILQ macros and under mfi_io_lock so its not obvious to me at this time why this is, any ideas? There was an obvious error in mfi_tbolt_get_cmd which is now fixed in the queue patch, where cmd can be used even if queue was empty and TAILQ_FIRST returned NULL, but I can't see this causing this panic. This is running with a debug kernel with:- options WITNESS options INVARIANTS options INVARIANT_SUPPORT options DDB options GDB options PRINTF_BUFR_SIZE=2048 options MFI_DEBUG Unfortunately I've only got this hardware till Friday unfortunately so any ideas would be most appreciated so I can get testing done before then. Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. zz-mfi-lock.patch Description: Binary data zz-mfi-queue.patch Description: Binary data ___ freebsd-stable@freebsd.org mailing list ht
dc(1) fails with "big number failure" on 2^64
Hi, I am seeing this in dc: janm@gray: dc $ dc 18446744073709551616 18446744073709551616 / ps dc: big number failure 306b06b: No such file or directory That number is 2^64. The error is coming from BN_check in bdiv(), which is complaining about the number at the top of the stack being uninitialised. Looking at the data, after the second pop in bdiv() in bdata.c, b->number->d[b->number->top - 1] == 0. After a while poking around in a debugger, it looks like the first word of the second number (a->number->d) is being allocated at the same location as the last word of the second number, it gets zeroed, and then looks uninitialised. All of this seems to be happening in the BN_* routines in openssl. I am seeing this on my builds for 9.1-RC3 and 9.0-p3, as well as the CDROM shell on the 9.1-RC3 ISO, so I'm pretty sure it isn't my build process or compiler flags. I have checked an OpenBSD 5.2 installation, and it works fine. Can anyone confirm this? Am I just seeing things? Is there an obvious fix? Thanks, Jan Mikkelsen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
