Re: Trouble building/upgrading 9-stable
On Oct 9, 2013, at 01:39, Johannes Totz wrote: > I'm having trouble upgrading a system running 9-stable to a new revision. > buildworld always dies with an "internal compiler error" during > lib/clang/libllvminstcombine. ... > /usr/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp:1649: > internal compiler error: in memory_address_length, at > config/i386/i386.c:13897 Since the tinderboxes for stable/9 are green, it is most likely your machine has a hardware problem. You should at least run two or three full passes of memtest on your machine: this type of error typically occurs when data in RAM gets corrupted. If you can't find any hardware problems, you could try to switch off building clang, using WITHOUT_CLANG in your src.conf. However, if your hardware cannot be trusted, all bets are off... :) -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
Re: Trouble building/upgrading 9-stable
On 09/10/2013 10:44, Dimitry Andric wrote: On Oct 9, 2013, at 01:39, Johannes Totz wrote: I'm having trouble upgrading a system running 9-stable to a new revision. buildworld always dies with an "internal compiler error" during lib/clang/libllvminstcombine. ... /usr/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp:1649: internal compiler error: in memory_address_length, at config/i386/i386.c:13897 Since the tinderboxes for stable/9 are green, it is most likely your machine has a hardware problem. You should at least run two or three full passes of memtest on your machine: this type of error typically occurs when data in RAM gets corrupted. The box has ECC RAM, and runs pure zfs. I don't know what to look out for regarding ECC errors though. There's nothing in the console log that looks suspicious. Also, trying to compile this many times will always trigger the same error, that'd make RAM fault unlikely I would have thought (think random crashes, the box is rock solid otherwise). If you can't find any hardware problems, you could try to switch off building clang, using WITHOUT_CLANG in your src.conf. Thanks, will try that! ___ 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: Installing packages from 9.2 Release DVD
On Tue, Oct 8, 2013 at 5:29 AM, Teske, Devin wrote: [ snip ] > > > Another problem is there is no any available information about this > subject > > in the Handbook installation pages ( at least I could not find any one > one > > ) . > > > > bsdconfig was just born in 9.2-R. Nobody has gotten around to documenting > it. > I'll be doing the first presentation on it at the vBSDcon [un]Conference > coming > up in a couple weeks (Oct 25-27th in Reston, VA; hosted by Verisign). Looking forward to this presentation, Devin! Devin's spot will be from 2PM - 3PM on October 26th. More information on vBSDcon can be found at http://www.vbsdcon.com/. Online registrations are available through October 23 and on-site registrations will be available through the entirety of the conference. The registration fee is USD$75. -- Take care Rick Miller ___ 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"
hast and zfs trim possibly causing some problems in 9.2
I just had a machine fall over on my for the first time in ages - one of a pair of machine we have running hast with zfs on top. I havent got any concrete evidence of what made it die as yet, but I did notice the logifles filling up with thoursands of lines like this just prior to the crash: serpentine-active hastd[1522]: [serp1] (primary) Remote request failed (Operation not supported): DELETE(26847744000, 1536). so I am guessing taht is ZFS trying to send a trim command to hast, and hast does not support it. Have disabled zfs trim now, but thought it was worth mentioning - I would have not expected zfs to be trying to issue a trim command to an underlying device which doesnt support it. These machines were rock solid under 8, and the only chnage I can see with 9 is the trim support being added. cheers, -pete. ___ 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: hast and zfs trim possibly causing some problems in 9.2
ZFS will try to send DELETE requests to the underlying storage to support TRIM. If that fails then it will disable TRIM support for that vdev. My guess would be you're just seeing hast being a bit verbose when these initial batch failures happen. Regards Steve - Original Message - From: "Pete French" To: Sent: Wednesday, October 09, 2013 3:25 PM Subject: hast and zfs trim possibly causing some problems in 9.2 I just had a machine fall over on my for the first time in ages - one of a pair of machine we have running hast with zfs on top. I havent got any concrete evidence of what made it die as yet, but I did notice the logifles filling up with thoursands of lines like this just prior to the crash: serpentine-active hastd[1522]: [serp1] (primary) Remote request failed (Operation not supported): DELETE(26847744000, 1536). so I am guessing taht is ZFS trying to send a trim command to hast, and hast does not support it. Have disabled zfs trim now, but thought it was worth mentioning - I would have not expected zfs to be trying to issue a trim command to an underlying device which doesnt support it. These machines were rock solid under 8, and the only chnage I can see with 9 is the trim support being added. cheers, -pete. ___ 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" 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. ___ 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: Trouble building/upgrading 9-stable
On 09/10/2013 11:25, Johannes Totz wrote: On 09/10/2013 10:44, Dimitry Andric wrote: On Oct 9, 2013, at 01:39, Johannes Totz wrote: I'm having trouble upgrading a system running 9-stable to a new revision. buildworld always dies with an "internal compiler error" during lib/clang/libllvminstcombine. ... /usr/src/lib/clang/libllvminstcombine/../../../contrib/llvm/lib/Transforms/InstCombine/InstCombineCompares.cpp:1649: internal compiler error: in memory_address_length, at config/i386/i386.c:13897 Since the tinderboxes for stable/9 are green, it is most likely your machine has a hardware problem. You should at least run two or three full passes of memtest on your machine: this type of error typically occurs when data in RAM gets corrupted. The box has ECC RAM, and runs pure zfs. I don't know what to look out for regarding ECC errors though. There's nothing in the console log that looks suspicious. Also, trying to compile this many times will always trigger the same error, that'd make RAM fault unlikely I would have thought (think random crashes, the box is rock solid otherwise). If you can't find any hardware problems, you could try to switch off building clang, using WITHOUT_CLANG in your src.conf. Thanks, will try that! Yeay, WITHOUT_CLANG has buildworld (and subsequent buildkernel) finish successfully. ___ 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"
