Re: Do we have a CPUTYPE=native and/or generic stability problem?
Le dimanche 4 novembre 2012, Alexander Leidinger a écrit : The machine has 12 MB RAM (no swap configured), after nearly a day uptime it looks like this: ---snip--- Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other ---snip--- I would not expect an internal compiler error when I run out of RAM. Not related, but I think you should configure -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
Le lundi 5 novembre 2012, Olivier Smedts a écrit : Le dimanche 4 novembre 2012, Alexander Leidinger a écrit : The machine has 12 MB RAM (no swap configured), after nearly a day uptime it looks like this: ---snip--- Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other ---snip--- I would not expect an internal compiler error when I run out of RAM. Not related, but I think you should configure ...at least a little swap (sorry, damn smart-phone). When under memory pressure, ZFS sometimes don't have time to evict ARC memory and some MBs are written to swap instead of waiting. No real technical details -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
Le lundi 5 novembre 2012, Olivier Smedts a écrit : Le lundi 5 novembre 2012, Olivier Smedts a écrit : Le dimanche 4 novembre 2012, Alexander Leidinger a écrit : The machine has 12 MB RAM (no swap configured), after nearly a day uptime it looks like this: ---snip--- Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other ---snip--- I would not expect an internal compiler error when I run out of RAM. Not related, but I think you should configure ...at least a little swap (sorry, damn smart-phone). When under memory pressure, ZFS sometimes don't have time to evict ARC memory and some MBs are written to swap instead of waiting. No real technical details ...here, I'll leave it to ZFS or VM gurus, but I always have few dozens of MBs of my swap used even if I have lots of memory. And I promise my next reply will be made on a real computer, not on a too small touch interface with an editor which tries to replace all your english words by some of your mother tongue words. Sorry for triple posting. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sat, Nov 3, 2012 at 5:24 PM, Alexander Leidinger alexan...@leidinger.net wrote: Hi, while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. The r239708 world runs stable since I installed it (build with CPUTYPE=native). The r242511 world (no CPUTYPE set) doesn't run stable (not only the watchdogd segfault I reported in another mail some minutes ago, but also some other kind of reboot every X minutes I haven't investigated yet). Does someone run -current on a similar system on a similar revision and can comment about the stability? Not sure if your hitting the same bug, that was found in PR 112997. When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for a patch to bsd.cpu.mk. Does your system compile correctly, if you specify the CPUTYPE? Scot ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
Le dimanche 4 novembre 2012, Scot Hetzel a écrit : When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. This comes regularly in the lists. Try setting the correct CPUTYPE for your CPU, and if you want to use native somewhere, add -march=native to your CFLAGS. There's another option to use so that *.mk don't add another -march with your CPUTYPE automatically. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 04 Nov 2012 00:46:15 +0100 Dimitry Andric d...@freebsd.org wrote: On 2012-11-03 23:24, Alexander Leidinger wrote: while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. Hm, at first I thought you might be running out of RAM, but apparently that is not the case then. :) The machine has 12 MB RAM (no swap configured), after nearly a day uptime it looks like this: ---snip--- Mem: 348M Active, 599M Inact, 9281M Wired, 264K Cache, 1548M Free ARC: 7117M Total, 1607M MRU, 3996M MFU, 934K Anon, 208M Header, 1307M Other ---snip--- I would not expect an internal compiler error when I run out of RAM. The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. What does gcc detect for this CPU with -march=native? You can do: gcc -march=native -v -c -x c /dev/null 21 | grep -- -march to see what it passes to the second stage. ---snip--- # gcc -march=native -v -c -x c /dev/null 21 | grep -- -march /usr/libexec/cc1 -quiet -v -D_LONGLONG /dev/null -march=core2 -mtune=generic -quiet -dumpbase null -auxbase null -version -o /tmp//cc7kc0JI.s ---snip--- Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 4 Nov 2012 14:43:30 +0100 Olivier Smedts oliv...@gid0.org wrote: Le dimanche 4 novembre 2012, Scot Hetzel a écrit : When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. This comes regularly in the lists. This basically means we need to do something about it. Try setting the correct CPUTYPE for your CPU, and if you want to use native somewhere, add -march=native to your CFLAGS. There's another option to use so that *.mk don't add another -march with your CPUTYPE automatically. We either should bail out if someone uses native as CPUTYPE, or we should make it just work. Personally I don't have a preference for one or the other, important is that the user gets a behavior he can count on. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On Sun, 4 Nov 2012 03:43:13 -0600 Scot Hetzel swhet...@gmail.com wrote: Not sure if your hitting the same bug, that was found in PR 112997. When you set CPUTYPE?=native, bsd.cpu.mk doesn't set MACHINE_CPU to the correct values for your CPUTYPE. See http://www.freebsd.org/cgi/query-pr.cgi?pr=conf/112997 for a patch to bsd.cpu.mk. I try to get a look at it this week. Does your system compile correctly, if you specify the CPUTYPE? I haven't tried it yet. I will give it a try later. Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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
Do we have a CPUTYPE=native and/or generic stability problem?
Hi, while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. The r239708 world runs stable since I installed it (build with CPUTYPE=native). The r242511 world (no CPUTYPE set) doesn't run stable (not only the watchdogd segfault I reported in another mail some minutes ago, but also some other kind of reboot every X minutes I haven't investigated yet). Does someone run -current on a similar system on a similar revision and can comment about the stability? Bye, Alexander. -- http://www.Leidinger.netAlexander @ Leidinger.net: PGP ID = B0063FE7 http://www.FreeBSD.org netchild @ FreeBSD.org : PGP ID = 72077137 ___ 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: Do we have a CPUTYPE=native and/or generic stability problem?
On 2012-11-03 23:24, Alexander Leidinger wrote: while trying to update from r239708 to r242511 (amd64 arch) I tried to compile the world with make -j8. After a short while I got an internal error in the clang compile (this is a gcc-compiled system, I don't use clang). The CFLAGS/COPTFLAGS are -O2 -pipe. Without the -j8 it compiles just fine. Without the CPUTYPE?=native it compiles even with -j8. Hm, at first I thought you might be running out of RAM, but apparently that is not the case then. :) The CPU is an Intel(R) Xeon(R) CPU (L5630) with ECC ram. What does gcc detect for this CPU with -march=native? You can do: gcc -march=native -v -c -x c /dev/null 21 | grep -- -march to see what it passes to the second stage. The r239708 world runs stable since I installed it (build with CPUTYPE=native). The r242511 world (no CPUTYPE set) doesn't run stable (not only the watchdogd segfault I reported in another mail some minutes ago, but also some other kind of reboot every X minutes I haven't investigated yet). Does someone run -current on a similar system on a similar revision and can comment about the stability? I run r242303 on both i386 and amd64, no instability whatsoever. But I compile everything with clang, and an explicit CPU type for the processor in use, so my case is not comparable to yours, unfortunately. ___ 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
