Re: ZFS L2ARC - incorrect size and abnormal system load on r255173
Hello. Patch worked as expected - no compresion on l2, but a) l2arc couse big overhad on fs io b) after some time errors apears again. For now best choice not to use any patch on system so, for now we delete next changes from system 1) http://svnweb.freebsd.org/base?view=revision&sortby=file&revision=256889 2) http://svnweb.freebsd.org/base?view=revision&revision=255753 Yes, zpool status says cache gpt/cache0ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/cache1ONLINE 0 0 0 block size: 512B configured, 4096B native gpt/cache2ONLINE 0 0 0 block size: 512B configured, 4096B native But l2arc work as expected (no errors, no noticeable performance problem ) There is many another problem with performance on freebsd 10 after implement new vmem subsystem (at least no problem was before) but thay not corespond to l2 Don't even know what to do with situation. Vitalij Satanivskij wrote: VS> I dont apply previos patch on high load server, only on test where find that it's not disabling compression. VS> VS> Thank you for help, i will try new patch as soon as posible. VS> VS> SH> VS> SH> Have you seen any l2_io_error or l2_cksum_bad since VS> SH> applying the ashift patch? VS> SH> VS> ___ VS> freebsd-current@freebsd.org mailing list VS> http://lists.freebsd.org/mailman/listinfo/freebsd-current VS> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ 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: 10.0-BETA1 i386 on VirtualBox
On Wed, Oct 30, 2013 at 09:31:22PM -0400, Glen Barber wrote: G> > > Can any of you suggest a way to reproduce the bug on a livecd reliably? G> > G> > I'll rephrase that: G> > G> > Can anybody suggest a way to reproduce the bug on a livecd reliably, if G> > you ever met the bug before? G> > G> G> I have not been able to. I have been able to also do full G> buildworld/buildkernel within the VM, whereas Gleb would observe random G> crashes, in addition to other oddities. G> G> I'm baffled, but I have a (unconfirmed) suspicion this is a Virtualbox G> bug somewhere... :\ I have analyzed dmesgs from Boris, Maciej and mine VS a dmesg from box where 10.0-BETA2 i386 works flawlessly in VB. I failed to find any clue. It looks like we need Boris or Maciej to perform binary search through last two years of head development. :( -- Totus tuus, Glebius. ___ 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: MACHINE_CPU detection b0rked?
On Thu, 31 Oct 2013 09:53:42 +0700 Alexey Dokuchaev wrote: > Hi, > > Judging from /usr/share/mk/bsd.cpu.mk, it knows about both "core" and > "core2" and should be able to give me the list of features these CPUs > support. However, I'm puzzled: > > $ make -V MACHINE_CPU CPUTYPE=core2 > ssse3 sse3 sse2 sse i686 mmx i586 i486 > $ fmake -V MACHINE_CPU CPUTYPE=core2 > ssse3 sse3 sse2 sse i686 mmx i586 i486 > $ make -V MACHINE_CPU CPUTYPE=core > i486 > $ fmake -V MACHINE_CPU CPUTYPE=core > i486 i486 > $ uname -Um > i386 110 > > WTF? :) bsd.cpu.mk redefines CPUTYPE sometimes and that doesn't work if you pass it as a command line argument. You can only set this variable in make.conf. ___ 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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 31, 2013 at 03:35:06PM +0400, Boris Bobrov wrote: B> В сообщении от Thursday 31 of October 2013 13:49:38 Gleb написал: B> > I have analyzed dmesgs from Boris, Maciej and mine VS a dmesg from box B> > where 10.0-BETA2 i386 works flawlessly in VB. I failed to find any B> > clue. B> > B> > It looks like we need Boris or Maciej to perform binary search through B> > last two years of head development. :( B> B> 20130330-r248935 is buggy, so I've cut 7 months. B> B> I am not sure how to perform the search. snv up -r, build, copy to mounted B> .vdi, test? Or install 9.2 and start from there? Better install 9.2 and start from there. Chances that new kernel would work with old userland are much higher, than vice versa. B> Should I checkout "base" repository or something else/more? You need to checkout base/head, somewhere near date of 9.0-RELEASE, and bisect between that revision and r248935. -- Totus tuus, Glebius. ___ 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: 10.0-BETA1 i386 on VirtualBox
On 31.10.2013 01:08, Boris Bobrov wrote: > I'll rephrase that: Can anybody suggest a way to reproduce the bug on > a livecd reliably, if you ever met the bug before? Boris what error do you have on the livecd? tail /var/log/messages ? I see some oddity in view /var/log/messages: ^A at the end But the same file copied through disk -> network shows no ^A at the end. as /var and /tmp ar on md0 I suspect some kind of memory corruption. -- Pozdrawiam, Maciej Milewski messages Description: Binary data ___ 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: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.10.2013 01:08, Boris Bobrov wrote: > В сообщении от Thursday 31 of October 2013 02:01:41 Boris написал: >> В сообщении от Tuesday 29 of October 2013 15:09:57 Gleb написал: >>> Hello, >>> >>> [adding Boris to Cc, who reported same issue in private email] >>> >>> On Thu, Oct 24, 2013 at 05:16:15PM +0200, Maciej Milewski wrote: >>> M> I've encountered problems with installing FreeBSD-10.0-BETA1 i386 >>> under M> VirtualBox. >>> M> The problem is with setting/changing root password during install >>> M> process. After entering password twice there is: >>> M> >>> M> passwd: pam_chauthtok(): error in service module >>> M> >>> M> Then there shows pwd_mkdb.core in current directory. >>> M> The same VirtualBox machine has no problems with installing >>> M> FreeBSD-9.2-RELEASE >>> M> >>> M> Has anyone any clues? >>> >>> I failed to reproduce this with FreeBSD-10.0-BETA2 i386 image :( >>> It installed and booted successfully. >>> >>> Here is my host environment: >>> >>> glebius@think:~:|>pkg info -x virtual >>> virtualbox-ose-4.2.18_1 >>> virtualbox-ose-kmod-4.2.18 >>> glebius@think:~:|>uname -a >>> FreeBSD think.nginx.com 11.0-CURRENT FreeBSD 11.0-CURRENT #13 >>> r257045: Thu Oct 24 15:16:04 MSK 2013 >>> gleb...@think.nginx.com:/usr/obj/usr/src/head/sys/THINKPAD_X1 amd64 >>> >>> When trying to reproduce I used VirtualBox GUI and choosed defaults >>> in every dialog window. >>> >>> Boris and Maciej, if you use non-default configuration, can you >>> please provide more details? >> >> Hi. >> >> Can any of you suggest a way to reproduce the bug on a livecd reliably? > > I'll rephrase that: > > Can anybody suggest a way to reproduce the bug on a livecd reliably, if > you ever met the bug before? Boris what error do you have on the livecd? tail /var/log/messages ? I see some oddity in view /var/log/messages: ^@ at the end The same file copied through disk -> network shows no ^@ at the end. As /var and /tmp ar on md0/md1 I suspect some kind of memory corruption. - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJyRswACgkQPQ1pa2ELkNll/wCfeqN8k4ZW+E57tDohFGelCGTs E8IAoIB+pRVVQpugIlYEoGj7dnj5HkgX =JRp8 -END PGP SIGNATURE- ___ 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: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.10.2013 13:31, Boris Bobrov wrote: > When I do "less /var/log/messages", "less" fails with segmentation fault. It > happens on BETA1 and BETA2, but not on older 10.0 releases. I got the same with less. - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJyVrIACgkQPQ1pa2ELkNkDNACeJKj/7tJUjQ3yCusIZEFQlNJ9 NvoAn0S/zFhRNxuOf+yLcRUlDI9N6u/3 =d0l5 -END PGP SIGNATURE- ___ 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"
mystery problem with SVN update in /head
Hello, I have the following problem while updating an item in the ports tree: the SVN checkout was done on October 1; when I do now # cd /usr/ports/net # rm -r vnc # svn up vnc Updating 'vnc': Restored 'vnc' Restored 'vnc/pkg-plist' Restored 'vnc/Makefile' Restored 'vnc/distinfo' Restored 'vnc/pkg-descr' Restored 'vnc/files' Restored 'vnc/files/FreeBSD.cf-patch' Restored 'vnc/files/extra-patch-xc-config-util-printver.c' Restored 'vnc/files/vnc.def-patch' Restored 'vnc/files/extra-patch-fix_Xvnc_no_valid_address' Restored 'vnc/files/patch-unix-xc-programs-Xserver-vnc-Imakefile' Restored 'vnc/files/extra-patch-xfree86' Restored 'vnc/files/patch-unix-x0vncserver-x0vncserver.cxx' Restored 'vnc/files/patch-unix-xc-programs-Xserver-vnc-XserverDesktop.h' Restored 'vnc/files/patch-xc-programs-Xserver-vnc-vncExtInit.cc' At revision 332203. some files are missing (marked below) also a # rm -r vnc # svn co svn://svn.freebsd.org/ports/head/net/vnc does not help; only doing the checkout in an empty space like # cd /tmp # svn co svn://svn.freebsd.org/ports/head/net/vnc Avnc/pkg-plist Avnc/Makefile Avnc/distinfo Avnc/pkg-descr Avnc/files Avnc/files/patch-unix-tx-TXImage.cxx ^ Avnc/files/patch-unix-x0vncserver-x0vncserver.cxx Avnc/files/patch-common-network-TcpSocket.cxx ^ Avnc/files/patch-unix-xc-programs-Xserver-vnc-XserverDesktop.h Avnc/files/patch-xc-programs-Xserver-vnc-vncExtInit.cc Avnc/files/FreeBSD.cf-patch Avnc/files/extra-patch-xc-config-util-printver.c Avnc/files/vnc.def-patch Avnc/files/extra-patch-fix_Xvnc_no_valid_address Avnc/files/patch-unix-x0vncserver-Image.cxx ^ Avnc/files/patch-unix-xc-programs-Xserver-vnc-Imakefile Avnc/files/extra-patch-xfree86 Checked out revision 332240. brings the marked files to my disk; why is this? Thanks matthias -- Matthias Apitz | /"\ ASCII Ribbon Campaign: www.asciiribbon.org E-mail: g...@unixarea.de | \ / - No HTML/RTF in E-mail WWW: http://www.unixarea.de/ | X - No proprietary attachments phone: +49-170-4527211 | / \ - Respect for open standards ___ 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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 31, 2013 at 09:16:34AM -0400, Glen Barber wrote: > > http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/amd64/20131007/ > Wrong arch, sorry. http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/i386/20131007/ Glen pgplZzsjmMRlF.pgp Description: PGP signature
Re: 10.0-BETA1 i386 on VirtualBox
В сообщении от Thursday 31 of October 2013 13:49:38 Gleb написал: > I have analyzed dmesgs from Boris, Maciej and mine VS a dmesg from box > where 10.0-BETA2 i386 works flawlessly in VB. I failed to find any > clue. > > It looks like we need Boris or Maciej to perform binary search through > last two years of head development. :( 20130330-r248935 is buggy, so I've cut 7 months. I am not sure how to perform the search. snv up -r, build, copy to mounted .vdi, test? Or install 9.2 and start from there? Should I checkout "base" repository or something else/more? -- С наилучшими пожеланиями, Boris signature.asc Description: This is a digitally signed message part.
Re: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.10.2013 14:26, Glen Barber wrote: > On Thu, Oct 31, 2013 at 09:16:34AM -0400, Glen Barber wrote: >> http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/amd64/20131007/ >> > > Wrong arch, sorry. > > http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/i386/20131007/ > > Glen > No worries, found corect one myself :) - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJyXAAACgkQPQ1pa2ELkNnwOwCfYTUev/zs7E3sIslsCuCqZ7o+ ie4AmgK8AikXVbfIIeT2kSsZDmXarVGv =rIpl -END PGP SIGNATURE- ___ 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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 31, 2013 at 02:10:10PM +0100, Maciej Milewski wrote: > On 31.10.2013 13:31, Boris Bobrov wrote: > > When I do "less /var/log/messages", "less" fails with segmentation fault. > > It happens on > > BETA1 and BETA2, but not on older 10.0 releases. > I got the same with less. > Can you try 10.0-ALPHA5? I have VM images here: http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/amd64/20131007/ You should be able to just attach the vmdk to a Vbox VM. Glen pgpyy_o3K3Mla.pgp Description: PGP signature
Re: 10.0-BETA1 i386 on VirtualBox
В сообщении от Thursday 31 of October 2013 16:02:20 Maciej написал: > On 31.10.2013 01:08, Boris Bobrov wrote: > > В сообщении от Thursday 31 of October 2013 02:01:41 Boris написал: > >> В сообщении от Tuesday 29 of October 2013 15:09:57 Gleb написал: > >>> Hello, > >>> > >>> [adding Boris to Cc, who reported same issue in private email] > >>> > >>> On Thu, Oct 24, 2013 at 05:16:15PM +0200, Maciej Milewski wrote: > >>> M> I've encountered problems with installing FreeBSD-10.0-BETA1 > >>> i386 under M> VirtualBox. > >>> M> The problem is with setting/changing root password during > >>> install M> process. After entering password twice there is: > >>> M> > >>> M> passwd: pam_chauthtok(): error in service module > >>> M> > >>> M> Then there shows pwd_mkdb.core in current directory. > >>> M> The same VirtualBox machine has no problems with installing > >>> M> FreeBSD-9.2-RELEASE > >>> M> > >>> M> Has anyone any clues? > >>> > >>> I failed to reproduce this with FreeBSD-10.0-BETA2 i386 image :( > >>> It installed and booted successfully. > >>> > >>> Here is my host environment: > >>> > >>> glebius@think:~:|>pkg info -x virtual > >>> virtualbox-ose-4.2.18_1 > >>> virtualbox-ose-kmod-4.2.18 > >>> glebius@think:~:|>uname -a > >>> FreeBSD think.nginx.com 11.0-CURRENT FreeBSD 11.0-CURRENT #13 > >>> r257045: Thu Oct 24 15:16:04 MSK 2013 > >>> gleb...@think.nginx.com:/usr/obj/usr/src/head/sys/THINKPAD_X1 > >>> amd64 > >>> > >>> When trying to reproduce I used VirtualBox GUI and choosed defaults > >>> in every dialog window. > >>> > >>> Boris and Maciej, if you use non-default configuration, can you > >>> please provide more details? > >> > >> Hi. > >> > >> Can any of you suggest a way to reproduce the bug on a livecd > >> reliably? > > > > I'll rephrase that: > > > > Can anybody suggest a way to reproduce the bug on a livecd reliably, > > if you ever met the bug before? > > Boris what error do you have on the livecd? > tail /var/log/messages ? I see some oddity in view /var/log/messages: > ^@ at the end > The same file copied through disk -> network shows no ^@ at the end. > As /var and /tmp ar on md0/md1 I suspect some kind of memory > corruption. When I do "less /var/log/messages", "less" fails with segmentation fault. It happens on BETA1 and BETA2, but not on older 10.0 releases. -- С наилучшими пожеланиями, Boris signature.asc Description: This is a digitally signed message part.
Re: MACHINE_CPU detection b0rked?
On Thu, Oct 31, 2013 at 11:35:34AM +0100, Tijl Coosemans wrote: > bsd.cpu.mk redefines CPUTYPE sometimes and that doesn't work if you > pass it as a command line argument. You can only set this variable > in make.conf. Indeed, thanks; setting in make.conf works, however the fact that redefined variables cannot be bootstrapped from command line looks like a bug to me. ./danfe ___ 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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 31, 2013 at 05:45:32PM +0400, Boris Bobrov wrote: B> Two good news! B> B> 1. The bug disappeares if I disable VT-x/AMD-V in my virtual machine B> settings (Settings -> System -> Acceleration) and appeares if I enable it B> (thanks to Gleb for inspiration yesterday). It disappeares everywhere, on B> all revisions. B> B> 2. r244315 seems to be not buggy even with VT-x enabled. So we have to B> look somewhere between r244315 and r248935. Good news! Thanks Boris. Can you track this down to a particular revision? -- Totus tuus, Glebius. ___ 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: 10.0-BETA1 i386 on VirtualBox
On Thu, Oct 31, 2013 at 05:48:43PM +0400, Gleb Smirnoff wrote: T> B> 1. The bug disappeares if I disable VT-x/AMD-V in my virtual machine T> B> settings (Settings -> System -> Acceleration) and appeares if I enable it T> B> (thanks to Gleb for inspiration yesterday). It disappeares everywhere, on T> B> all revisions. T> B> T> B> 2. r244315 seems to be not buggy even with VT-x enabled. So we have to T> B> look somewhere between r244315 and r248935. T> T> Good news! Thanks Boris. T> T> Can you track this down to a particular revision? I have suspision that it is very close to the bhyve checkin: r245652 | neel | 2013-01-19 08:18:52 +0400 (сб, 19 янв 2013) | 9 lines Merge projects/bhyve to head. 'bhyve' was developed by grehan@ and myself at NetApp (thanks!). Special thanks to Peter Snyder, Joe Caradonna and Michael Dexter for their support and encouragement. Obtained from: NetApp since this is the code that started to utilize VT-x. Can you please check this revision and -1 revision to it? -- Totus tuus, Glebius. ___ 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: 10.0-BETA1 i386 on VirtualBox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 31.10.2013 14:26, Glen Barber wrote: > On Thu, Oct 31, 2013 at 09:16:34AM -0400, Glen Barber wrote: >> http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/amd64/20131007/ >> > > Wrong arch, sorry. > > http://ftp.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/10.0-BETA1/i386/20131007/ > > Glen > Glen, Simple less /var/log/messages works fine but passwd: in pam_sm_chauthtok(): pw_mkdb() failed passwd: pam_chauthtok(): error in service module - -- Pozdrawiam, Maciej Milewski -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iEYEARECAAYFAlJyYWAACgkQPQ1pa2ELkNkq0gCggFX1KeU9TyF5s46hjDSdSQDV 5WAAoIn56n9r83RV0kVd4QOQDJNSZQ/Q =7vZS -END PGP SIGNATURE- ___ 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 amd64/amd64
TB --- 2013-10-31 08:10:22 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-31 08:10:22 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 08:10:22 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-10-31 08:10:22 - cleaning the object tree TB --- 2013-10-31 08:12:38 - /usr/local/bin/svn stat /src TB --- 2013-10-31 08:12:41 - At svn revision 257425 TB --- 2013-10-31 08:12:42 - building world TB --- 2013-10-31 08:12:42 - CROSS_BUILD_TESTING=YES TB --- 2013-10-31 08:12:42 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-31 08:12:42 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-31 08:12:42 - SRCCONF=/dev/null TB --- 2013-10-31 08:12:42 - TARGET=amd64 TB --- 2013-10-31 08:12:42 - TARGET_ARCH=amd64 TB --- 2013-10-31 08:12:42 - TZ=UTC TB --- 2013-10-31 08:12:42 - __MAKE_CONF=/dev/null TB --- 2013-10-31 08:12:42 - cd /src TB --- 2013-10-31 08:12:42 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Oct 31 08:12:49 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Thu Oct 31 12:01:48 UTC 2013 TB --- 2013-10-31 12:01:48 - generating LINT kernel config TB --- 2013-10-31 12:01:48 - cd /src/sys/amd64/conf TB --- 2013-10-31 12:01:48 - /usr/bin/make -B LINT TB --- 2013-10-31 12:01:48 - cd /src/sys/amd64/conf TB --- 2013-10-31 12:01:48 - /usr/sbin/config -m LINT TB --- 2013-10-31 12:01:48 - building LINT kernel TB --- 2013-10-31 12:01:48 - CROSS_BUILD_TESTING=YES TB --- 2013-10-31 12:01:48 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-31 12:01:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-31 12:01:48 - SRCCONF=/dev/null TB --- 2013-10-31 12:01:48 - TARGET=amd64 TB --- 2013-10-31 12:01:48 - TARGET_ARCH=amd64 TB --- 2013-10-31 12:01:48 - TZ=UTC TB --- 2013-10-31 12:01:48 - __MAKE_CONF=/dev/null TB --- 2013-10-31 12:01:48 - cd /src TB --- 2013-10-31 12:01:48 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Thu Oct 31 12:01:48 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Thu Oct 31 12:36:49 UTC 2013 TB --- 2013-10-31 12:36:49 - cd /src/sys/amd64/conf TB --- 2013-10-31 12:36:49 - /usr/sbin/config -m LINT-NOINET TB --- 2013-10-31 12:36:49 - building LINT-NOINET kernel TB --- 2013-10-31 12:36:49 - CROSS_BUILD_TESTING=YES TB --- 2013-10-31 12:36:49 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-31 12:36:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-31 12:36:49 - SRCCONF=/dev/null TB --- 2013-10-31 12:36:49 - TARGET=amd64 TB --- 2013-10-31 12:36:49 - TARGET_ARCH=amd64 TB --- 2013-10-31 12:36:49 - TZ=UTC TB --- 2013-10-31 12:36:49 - __MAKE_CONF=/dev/null TB --- 2013-10-31 12:36:49 - cd /src TB --- 2013-10-31 12:36:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Thu Oct 31 12:36:49 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Thu Oct 31 13:08:36 UTC 2013 TB --- 2013-10-31 13:08:36 - cd /src/sys/amd64/conf TB --- 2013-10-31 13:08:36 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-10-31 13:08:36 - building LINT-NOINET6 kernel TB --- 2013-10-31 13:08:36 - CROSS_BUILD_TESTING=YES TB --- 2013-10-31 13:08:36 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-31 13:08:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-31 13:08:36 - SRCCONF=/dev/null TB --- 2013-10-31 13:08:36 - TARGET=amd64 TB --- 2013-10-31 13:08:36 - TARGET_ARCH=amd64 TB --- 2013-10-31 13:08:36 - TZ=UTC TB --- 2013-10-31 13:08:36 - __MAKE_CONF=/dev/null TB --- 2013-10-31 13:08:36 - cd /src TB --- 2013-10-31 13:08:36 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Thu Oct 31 13:08:36 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Thu Oct 31 13:40:42 UTC 2013 TB --- 2013-10-31 13:40:42 - cd /src/sys/amd64/conf TB --- 2013-10-31 13:40:42 - /usr/sbin/confi
Freebsd-10.0-CURRENT problem in the bottom half
Hi, In Freebsd 10.0-current with Emulex's OCE driver, I observe that the bottom half is hogging all the CPU which is leading to system sluggishness. I used the same hardware to check the behavior on 9.1-RELEASE, everything is fine, bottom half is not taking more than 10% of the CPU even at the line rate speed. But with half the throughput of line rate in Freebsd-10.0-current all the CPUs peak and "top -aSCHIP" shows that it's all bottom half who is eating the CPU. I also tried with Intel's 10g NIC to see if it has got the same problem and interestingly it is also having the same problem, where bottom half is hogging all the CPU. We did some profiling to check where the problem is. I'm pasting the profiling results for reference here. Observation from the results is that uma_zalloc_arg==> __mtx_lock_sleep is taking quite a bit of the CPU. We sleep at a few places in the bottom half and I think the bottom half scheduling is what is causing the problem. Please let me know if you see something very obvious from the profiling data. I'm seeing similar problem with ixgbe driver as well uma_zalloc_arg==> __mtx_lock_sleep is taking quite a bit of the CPU. Top command results are also pasted below for both 10.0-current (where the problem is seen) and 9.1-RELEASE (where the problem is not seen). 42.99% [372357] __mtx_lock_sleep @ /boot/kernel/kernel 100.0% [372357]__mtx_lock_flags 80.37% [299245] sosend_generic 100.0% [299245] soo_write 17.27% [64322] uma_zalloc_arg 50.43% [32438] m_copym 45.85% [29490] m_getm2 03.72% [2393]tcp_output 00.00% [1] oce_alloc_rx_bufs @ /boot/kernel/oce.ko 02.35% [8762] _sleep @ /boot/kernel/kernel 100.0% [8762]sbwait 00.00% [11] in_matroute 100.0% [11] rtalloc1_fib 00.00% [10] uma_zfree_arg 60.00% [6] m_freem 40.00% [4] sbdrop_internal 00.00% [3] rtalloc1_fib 100.0% [3] rtalloc_ign_fib 00.00% [3] tcp_output 100.0% [3] tcp_usr_send 00.00% [1] _cv_wait 100.0% [1] usb_process 34.98% [303027] trash_ctor @ /boot/kernel/kernel 87.44% [264956]mb_ctor_clust 100.0% [264956] uma_zalloc_arg 100.0% [264956] m_getm2 12.51% [37921] mb_ctor_mbuf 100.0% [37921] uma_zalloc_arg 48.28% [18308] m_getm2 48.18% [18272] m_copym 03.54% [1341]tcp_output 00.05% [150] mb_ctor_pack 100.0% [150]uma_zalloc_arg 96.67% [145] m_getm2 03.33% [5] oce_alloc_rx_bufs @ /boot/kernel/oce.ko 04.36% [37786]__rw_wlock_hard @ /boot/kernel/kernel 100.0% [37786] _rw_wlock_cookie 99.88% [37741] tcp_usr_send 100.0% [37741] sosend_generic 00.11% [43] in_pcblookup_hash 100.0% [43] tcp_input Top -aSCHIP with Freebsd-10.0-CURRENT (throughput 4.5 Gbps) PID USERNAME PRI NICE SIZERES STATE C TIMECPU COMMAND 0 root -920 0K 960K - 11 4:20 100.00% [kernel{oce1 taskq}] 2325 root 1030 70524K 6240K CPU55 0:39 100.00% iperf -c 12.0.238.24 -t 180 -i 3 -P 10{iperf} 0 root -920 0K 960K CPU88 5:17 99.37% [kernel{oce1 taskq}] 0 root -920 0K 960K CPU10 10 4:27 99.37% [kernel{oce1 taskq}] 0 root -920 0K 960K CPU99 3:35 98.88% [kernel{oce1 taskq}] 0 root -920 0K 960K CPU77 7:25 98.29% [kernel{oce1 taskq}] 11 root 155 ki31 0K 256K RUN12 14:55 93.90% [idle{idle: cpu12}] 11 root 155 ki31 0K 256K CPU13 13 14:48 91.70% [idle{idle: cpu13}] 11 root 155 ki31 0K 256K CPU14 14 18:35 89.79% [idle{idle: cpu14}] 11 root 155 ki31 0K 256K RUN15 20:55 87.99% [idle{idle: cpu15}] 11 root 155 ki31 0K 256K RUN 4 19:35 73.68% [idle{idle: cpu4}] 11 root 155 ki31 0K 256K RUN 0 19:47 66.89% [idle{idle: cpu0}] 11 root 155 ki31 0K 256K CPU22 18:53 64.89% [idle{idle: cpu2}] 11 root 155 ki31 0K 256K CPU66 19:55 61.18% [idle{idle: cpu6}] 11 root 155 ki31 0K 256K CPU11 18:46 55.66% [idle{idle: cpu1}] 11 root 155 ki31 0K 256K RUN 5 19:41 42.48% [idle{idle: cpu5}] 2325 root520 70524K 6240K sbwait 6 0:15 38.77% iperf -c 12.0.238.24 -t 180 -i 3 -P 10{iperf} 11 root 155 ki31 0K 256K CPU33 19:06 36.38% [idle{idle: cpu3}] 2325 root490 70524K 6240K CPU11 0:14 35.06% iperf -c 12.0.238.24 -t 180 -i 3 -P 10{iperf} 2325 root440 70524K 6240K sbwait 0 0:13 33.59% iperf -c 12.0.238.24 -t 180 -i 3 -P 10{iperf} 2325 root420 70524K 6240K sbwait 2 0:13 33.15% iperf -c 12.0.238.24 -t 180 -i 3 -P 10{iperf} 2325 root41
Re: 10.0-BETA1 i386 on VirtualBox
В сообщении от Tuesday 29 of October 2013 15:09:57 вы написали: > Hello, > > [adding Boris to Cc, who reported same issue in private email] > > On Thu, Oct 24, 2013 at 05:16:15PM +0200, Maciej Milewski wrote: > M> I've encountered problems with installing FreeBSD-10.0-BETA1 i386 > under M> VirtualBox. > M> The problem is with setting/changing root password during install > M> process. After entering password twice there is: > M> > M> passwd: pam_chauthtok(): error in service module > M> > M> Then there shows pwd_mkdb.core in current directory. > M> The same VirtualBox machine has no problems with installing > M> FreeBSD-9.2-RELEASE > M> > M> Has anyone any clues? > > I failed to reproduce this with FreeBSD-10.0-BETA2 i386 image :( > It installed and booted successfully. > ... > Boris and Maciej, if you use non-default configuration, can you please > provide more details? Two good news! 1. The bug disappeares if I disable VT-x/AMD-V in my virtual machine settings (Settings -> System -> Acceleration) and appeares if I enable it (thanks to Gleb for inspiration yesterday). It disappeares everywhere, on all revisions. 2. r244315 seems to be not buggy even with VT-x enabled. So we have to look somewhere between r244315 and r248935. -- С наилучшими пожеланиями, Boris signature.asc Description: This is a digitally signed message part.
Re: Freebsd-10.0-CURRENT problem in the bottom half
Hi, Can you please try 10-STABLE or 11-CURRENT? 10-CURRENT indicates that you're a little behind in the source tree(s). There's been a bit of work recently that may improve things in general for you. Thanks! -a On 31 October 2013 07:00, Venkata Duvvuru wrote: > Hi, > In Freebsd 10.0-current with Emulex's OCE driver, I observe that the bottom > half is hogging all the CPU which is leading to system sluggishness. I used > the same hardware to check the behavior on 9.1-RELEASE, everything is fine, > bottom half is not taking more than 10% of the CPU even at the line rate > speed. But with half the throughput of line rate in Freebsd-10.0-current all > the CPUs peak and "top -aSCHIP" shows that it's all bottom half who is eating > the CPU. I also tried with Intel's 10g NIC to see if it has got the same > problem and interestingly it is also having the same problem, where bottom > half is hogging all the CPU. > > We did some profiling to check where the problem is. I'm pasting the > profiling results for reference here. Observation from the results is that > uma_zalloc_arg==> __mtx_lock_sleep is taking quite a bit of the CPU. We sleep > at a few places in the bottom half and I think the bottom half scheduling is > what is causing the problem. Please let me know if you see something very > obvious from the profiling data. > > I'm seeing similar problem with ixgbe driver as well uma_zalloc_arg==> > __mtx_lock_sleep is taking quite a bit of the CPU. > > Top command results are also pasted below for both 10.0-current (where the > problem is seen) and 9.1-RELEASE (where the problem is not seen). > > 42.99% [372357] __mtx_lock_sleep @ /boot/kernel/kernel > 100.0% [372357]__mtx_lock_flags > 80.37% [299245] sosend_generic >100.0% [299245] soo_write > 17.27% [64322] uma_zalloc_arg >50.43% [32438] m_copym >45.85% [29490] m_getm2 >03.72% [2393]tcp_output >00.00% [1] oce_alloc_rx_bufs @ /boot/kernel/oce.ko > 02.35% [8762] _sleep @ /boot/kernel/kernel >100.0% [8762]sbwait > 00.00% [11] in_matroute >100.0% [11] rtalloc1_fib > 00.00% [10] uma_zfree_arg >60.00% [6] m_freem >40.00% [4] sbdrop_internal > 00.00% [3] rtalloc1_fib >100.0% [3] rtalloc_ign_fib > 00.00% [3] tcp_output >100.0% [3] tcp_usr_send > 00.00% [1] _cv_wait >100.0% [1] usb_process > > 34.98% [303027] trash_ctor @ /boot/kernel/kernel > 87.44% [264956]mb_ctor_clust > 100.0% [264956] uma_zalloc_arg >100.0% [264956] m_getm2 > 12.51% [37921] mb_ctor_mbuf > 100.0% [37921] uma_zalloc_arg >48.28% [18308] m_getm2 >48.18% [18272] m_copym >03.54% [1341]tcp_output > 00.05% [150] mb_ctor_pack > 100.0% [150]uma_zalloc_arg >96.67% [145] m_getm2 >03.33% [5] oce_alloc_rx_bufs @ /boot/kernel/oce.ko > > 04.36% [37786]__rw_wlock_hard @ /boot/kernel/kernel > 100.0% [37786] _rw_wlock_cookie > 99.88% [37741] tcp_usr_send >100.0% [37741] sosend_generic > 00.11% [43] in_pcblookup_hash >100.0% [43] tcp_input > > > Top -aSCHIP with Freebsd-10.0-CURRENT (throughput 4.5 Gbps) > PID USERNAME PRI NICE SIZERES STATE C TIMECPU COMMAND > 0 root -920 0K 960K - 11 4:20 100.00% [kernel{oce1 > taskq}] > 2325 root 1030 70524K 6240K CPU55 0:39 100.00% iperf -c > 12.0.238.24 -t 180 -i 3 -P 10{iperf} > 0 root -920 0K 960K CPU88 5:17 99.37% [kernel{oce1 > taskq}] > 0 root -920 0K 960K CPU10 10 4:27 99.37% [kernel{oce1 > taskq}] > 0 root -920 0K 960K CPU99 3:35 98.88% [kernel{oce1 > taskq}] > 0 root -920 0K 960K CPU77 7:25 98.29% [kernel{oce1 > taskq}] >11 root 155 ki31 0K 256K RUN12 14:55 93.90% [idle{idle: > cpu12}] >11 root 155 ki31 0K 256K CPU13 13 14:48 91.70% [idle{idle: > cpu13}] >11 root 155 ki31 0K 256K CPU14 14 18:35 89.79% [idle{idle: > cpu14}] >11 root 155 ki31 0K 256K RUN15 20:55 87.99% [idle{idle: > cpu15}] >11 root 155 ki31 0K 256K RUN 4 19:35 73.68% [idle{idle: > cpu4}] >11 root 155 ki31 0K 256K RUN 0 19:47 66.89% [idle{idle: > cpu0}] >11 root 155 ki31 0K 256K CPU22 18:53 64.89% [idle{idle: > cpu2}] >11 root 155 ki31 0K 256K CPU66 19:55 61.18% [idle{idle: > cpu6}] >11 root 155 ki31 0K 256K CPU11 18:46 55.66% [idle{idle: > cpu1}] >11 root 155 ki31 0K 256K RUN 5 19:41 42.48% [idle{idle: > cpu5}] > 2325 root520 70524K 6240K sbwait 6 0:15 38.77% iperf -c > 12.0
Problem upgrading FreeBSD 10
Hello all. Back in september I've installed a "current" (it was a FreeBSD 10, r2552041). The system is working fine. I've returned this week from a vacation and tried to upgrade to stable/10 with no success. The machine is running a zfs-mirror: # zpool status pool: system state: ONLINE scan: scrub repaired 0 in 1h45m with 0 errors on Wed Oct 9 05:16:51 2013 config: NAME STATE READ WRITE CKSUM system ONLINE 0 0 0 mirror-0 ONLINE 0 0 0 gpt/system0 ONLINE 0 0 0 gpt/system1 ONLINE 0 0 0 # uname -a FreeBSD netuno.ige.unicamp.br 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r255204: Thu Sep 5 08:29:33 BRT 2013 root@luna:/usr/obj/usr/src/sys/GENERIC amd64 After building work and kernel for a "svn://svn.freebsd.org/base/stable/10", apparently the system stops at (or imediatly after): ZFS filesystem version: 5 ZFS storage pool version: features support (5000) In the "/var/run/dmesg.boot" I have, among other lines: Copyright (c) 1992-2013 The FreeBSD Project. 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 11.0-CURRENT #1 r257434: Thu Oct 31 11:47:41 BRST 2013 root@netuno:/usr/obj/usr/src/sys/GENERIC amd64 FreeBSD clang version 3.3 (tags/RELEASE_33/final 183502) 20130610 WARNING: WITNESS option enabled, expect reduced performance. CPU: Intel(R) Core(TM) i7-4770 CPU @ 3.40GHz (3392.21-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x306c3 Family = 0x6 Model = 0x3c Stepping = 3 Features=0xbfebfbff Features2=0x7ffafbff,FMA,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,x2APIC,MOVBE,POPCNT,TSCDLT,AESNI,XSAVE,OSXSAVE,AVX,F16C,RDRAND> AMD Features=0x2c100800 AMD Features2=0x21 Standard Extended Features=0x2fbb TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16461611008 (15699 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: . Trying to mount root from zfs:system/root []... Waiting (max 60 seconds) for system process `vnlru' to stop...done Waiting (max 60 seconds) for system process `bufdaemon' to stop...done Waiting (max 60 seconds) for system process `syncer' to stop... Syncing disks, vnodes remaining...0 0 0 0 done All buffers synced. lock order reversal: 1st 0xf8000b96e7c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xf8000b40c240 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2101 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe046260 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe0462444510 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe04624445a0 __lockmgr_args() at __lockmgr_args+0x86c/frame 0xfe04624446d0 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe04624446f0 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe0462444720 _vn_lock() at _vn_lock+0xab/frame 0xfe0462444790 vget() at vget+0x70/frame 0xfe04624447e0 devfs_allocv() at devfs_allocv+0xfd/frame 0xfe0462444830 devfs_root() at devfs_root+0x43/frame 0xfe0462444860 dounmount() at dounmount+0x35a/frame 0xfe04624448e0 vfs_unmountall() at vfs_unmountall+0x61/frame 0xfe0462444910 kern_reboot() at kern_reboot+0x548/frame 0xfe0462444980 sys_reboot() at sys_reboot+0x58/frame 0xfe04624449a0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe0462444ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0462444ab0 --- syscall (55, FreeBSD ELF64, sys_reboot), rip = 0x8008600fc, rsp = 0x7fffdb58, rbp = 0x7fffdcc0 --- Uptime: 1m59s Do I have to use svn://svn.freebsd.org/base/head only ??? I've tested with the above and the single user boot has worked fine... Need more info? TIA... -- Ricardo Campos Passanezi ___ 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: Freebsd-10.0-CURRENT problem in the bottom half
On Thu, Oct 31, 2013 at 10:00 AM, Venkata Duvvuru wrote: > 34.98% [303027] trash_ctor @ /boot/kernel/kernel This indicates that you have INVARIANTS enabled (and you're probably running GENERIC, so you also have WITNESS). These will debugging features will substantially impact performance. To do performance testing on head, you need disable these options from your kernel config: nooptions INVARIANTS nooptions WITNESS nooptions MALLOC_DEBUG_MAXZONES Also, set MALLOC_PRODUCTION=yes in /etc/make.conf. Then rebuild your world and kernel and try again. ___ 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: Fatal trap 12: page fault while in kernel mode (FUSE related?)
On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev wrote: > Hi again, > > I was running out of space on my UFS partition and decided to use big NTFS > one I also have on the drive. I've mounted it with ntfs-3g and our native > fuse.ko. I needed the scratch space to built Open/LibreOffice on it *LOL*. > Well, it failed with a panic (see the excerpt from text core at the end of > this email; full debug info is available upon request). > > This is on fresh 11-CURRENT, i386. > > ./danfe > > I get a very similar panic when I attempt an rsync from a remote system to my NTFS drive. Very easy to reproduce. Something in fuse goes off the rails under active R/W activity, it seems. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.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"
error building stable/9 on FreeBSD 10
I am having trouble building stable/9 on FreeBSD 10: luigi@bsd10:~ # uname -a FreeBSD bsd10 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256420: Sun Oct 13 01:43:07 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 # ./do TREE TARGET # is a script that invokes a make in the source tree (first argument), # for a speciic target (second argument) and with a few options to # do the build in a local subtree. # Works fine building head on FreeBSD 10 and # building 9 and head on FreeBSD 9 luigi@bsd10:~ ./do RELENG_9 toolchain ... ===> gnu/usr.bin/cc/cc_tools (depend) --- genattrtab --- --- genautomata --- --- genconditions --- --- genconfig --- --- genconstants --- --- genemit --- --- genopinit --- --- genoutput --- --- genconstants --- cc -O2 -pipe -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/usr\" -I/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../cc_tools -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 -I/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/ FreeBSD/RELENG_9/tmp/legacy/usr/include -static -L/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/legacy/usr/lib -o genconstants genconstants.o rtl.o read-rtl.o ggc-none.o vec.o min-insn-modes.o gensupport.o print-rtl.o errors.o libiberty.a -lm print-rtl.o: In function `print_rtx': /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x631): undefined reference to `dump_addr' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6d1): undefined reference to `insn_file' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6e9): undefined reference to `insn_file' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6f4): undefined reference to `insn_line' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x772): undefined reference to `reg_names' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xc04): undefined reference to `dump_addr' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xc61): undefined reference to `print_node_brief' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xd39): undefined reference to `bitmap_print' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xe62): undefined reference to `real_to_decimal' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xe90): undefined reference to `real_to_hexadecimal' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xfac): undefined reference to `mode_size' /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x1027): undefined reference to `mode_size' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** [genconstants] Error code 1 make[4]: stopped in /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools any idea on what is going wrong ? cheers luigi ___ 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: Official FreeBSD Binary Packages now available for pkgng
It doesn't work with our (microsoft) proxy server, see below. root@basay:/usr/local/etc/pkg/repos # pkg update -f Updating repository catalogue pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service Unavailable pkg: No digest falling back on legacy catalog format pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service Unavailable root@basay:/usr/local/etc/pkg/repos # Eric On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery wrote: > We are pleased to announce that official binary packages are now > available for pkg, the next generation package management tool for FreeBSD. > > Pkg allows you to either use ports with portmaster/portupgrade or to > have binary remote packages without ports. > > We have binary packages available for i386 and amd64 on > 8.3,8.4,9.1,9.2,10.0 and 11 (head). > > Pkg will be the default starting in FreeBSD 10. > > The pkg_install suite of tools pkg_create(1), pkg_add(1), and > pkg_info(1) (which ports also use), are deprecated and will be > discontinued in roughly 6 months. A communication regarding the > deprecation of the pkg_install suite of tools will be sent separately in > the future. > > If you are currently not using pkg and wish to, run the following as > root. Be sure not to add WITH_PKGNG=yes to your make.conf until after > pkg is installed. > > # cd /usr/ports/ports-mgmt/pkg && make install clean > # echo WITH_PKGNG=yes >> /etc/make.conf > # pkg2ng > > You can now either continue to use ports with portmaster/portupgrade, as > before or switch to using binary packages only. > > > To use binary packages: > > 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least >1.1.4_8. If it does not, first upgrade from ports. > 2. Remove any repository-specific configuration from >/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. >If this leaves your pkg.conf empty, just remove it. > 3. mkdir -p /usr/local/etc/pkg/repos > 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: > FreeBSD: { > url: "http://pkg.FreeBSD.org/${ABI}/latest";, > mirror_type: "srv", > enabled: "yes" > } > > * Note that pkg.FreeBSD.org does not have a browsable web page on it and > does not have a DNS A record. This is intended as it is an SRV host. > pkg(8) knows how to properly use it. You can use 'pkg search' to browse > the available packages in the repository. > > Mirrors you may use instead of the global pkg.FreeBSD.org: > > pkg.eu.FreeBSD.org > pkg.us-east.FreeBSD.org > pkg.us-west.FreeBSD.org > > Your system is now ready to use packages! > > Refer to the handbook section on pkgng for usage at > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html > . > Also see 'man pkg' for examples or 'pkg help'. > > > Packages are built weekly from a snapshot of the Ports Collection every > Wednesday morning 01:00 UTC. They typically will be available in the > repository after a few days. > > Pkg 1.2 will be released in the coming month which will bring many > improvements including officially signed packages. FreeBSD 10's pkg > bootstrap now also supports signed pkg(8) installation. > > > Regards, > Bryan Drewery > on behalf of portmgr@ > > > ___ > 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" > ___ 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: newcons comming
On Fri, Oct 25, 2013 at 03:18:47PM +0300, Aleksandr Rybalko wrote: | Hello fellow hackers! | | I finally reach the point when I can work with newcons instead of | syscons on my laptop. Yes, I know it still buggy and have a lot of | style(9) problems. But we really have to get it into HEAD and 10.0 to | enable shiny new Xorg features, drivers, etc. I built the kernel from: base/user/ed/newcons/ and installed it on my new ThinkPad T530 with Intel graphics chip. In general it works better since now syspend and resume works with and without X. However, as with my prior ThinkPads I need to switch out of X to suspend and resume. So I have vidcontrol -s 1 in my /etc/rc.suspend and vidcontrol -s 9 in /etc/rc.resume. If I don't the display ends up corrupted but somewhat working. I had to kldload i915kms in /etc/rc.local since having it there at boot via /boot/loader.conf resulted in the system not booting. I need i915kms for X so I don't need to use vesa mode. The FreeBSD logo on boot is interesting but I'd prefer seeing FreeBSD boot messages to see what is happening. I'm not sure if there is a flag to disable that since I have played with it much. However, on a whole it is much improved since with i915kms and newcons when in X via vesa I couldn't switch to a non-X display since it was blank. Thanks, Doug A. ___ 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: Official FreeBSD Binary Packages now available for pkgng
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-10-31 16:47, Eric Camachat wrote: > It doesn't work with our (microsoft) proxy server, see below. > > root@basay:/usr/local/etc/pkg/repos # pkg update -f > Updating repository catalogue > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service > Unavailable > pkg: No digest falling back on legacy catalog format > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service > Unavailable > root@basay:/usr/local/etc/pkg/repos # > > Eric > > > On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery wrote: > >> We are pleased to announce that official binary packages are now >> available for pkg, the next generation package management tool for FreeBSD. >> >> Pkg allows you to either use ports with portmaster/portupgrade or to >> have binary remote packages without ports. >> >> We have binary packages available for i386 and amd64 on >> 8.3,8.4,9.1,9.2,10.0 and 11 (head). >> >> Pkg will be the default starting in FreeBSD 10. >> >> The pkg_install suite of tools pkg_create(1), pkg_add(1), and >> pkg_info(1) (which ports also use), are deprecated and will be >> discontinued in roughly 6 months. A communication regarding the >> deprecation of the pkg_install suite of tools will be sent separately in >> the future. >> >> If you are currently not using pkg and wish to, run the following as >> root. Be sure not to add WITH_PKGNG=yes to your make.conf until after >> pkg is installed. >> >> # cd /usr/ports/ports-mgmt/pkg && make install clean >> # echo WITH_PKGNG=yes >> /etc/make.conf >> # pkg2ng >> >> You can now either continue to use ports with portmaster/portupgrade, as >> before or switch to using binary packages only. >> >> >> To use binary packages: >> >> 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least >>1.1.4_8. If it does not, first upgrade from ports. >> 2. Remove any repository-specific configuration from >>/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. >>If this leaves your pkg.conf empty, just remove it. >> 3. mkdir -p /usr/local/etc/pkg/repos >> 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: >> FreeBSD: { >> url: "http://pkg.FreeBSD.org/${ABI}/latest";, >> mirror_type: "srv", >> enabled: "yes" >> } >> >> * Note that pkg.FreeBSD.org does not have a browsable web page on it and >> does not have a DNS A record. This is intended as it is an SRV host. >> pkg(8) knows how to properly use it. You can use 'pkg search' to browse >> the available packages in the repository. >> >> Mirrors you may use instead of the global pkg.FreeBSD.org: >> >> pkg.eu.FreeBSD.org >> pkg.us-east.FreeBSD.org >> pkg.us-west.FreeBSD.org >> >> Your system is now ready to use packages! >> >> Refer to the handbook section on pkgng for usage at >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html >> . >> Also see 'man pkg' for examples or 'pkg help'. >> >> >> Packages are built weekly from a snapshot of the Ports Collection every >> Wednesday morning 01:00 UTC. They typically will be available in the >> repository after a few days. >> >> Pkg 1.2 will be released in the coming month which will bring many >> improvements including officially signed packages. FreeBSD 10's pkg >> bootstrap now also supports signed pkg(8) installation. >> >> >> Regards, >> Bryan Drewery >> on behalf of portmgr@ >> >> >> ___ >> 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" >> > ___ > 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" I am guessing the proxy passes the full HTTP request, without doing the SRV lookup, and then can't find the A record. I wonder if the http+pkg:// protocol can solve this, likely will require a patch to fetch to implement the logic to do the dns lookup and make the proxies request for the real hostname - -- Allan Jude -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.16 (MingW32) Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJScsXlAAoJEJrBFpNRJZKfvGUP/juCxjR30BPycq1wsPg/p1X9 oVorgOaFYYEo5Wg13J2UNj0vkOcFjl9hIdjKh3NmzTP9VOEbJPX4/WSFJOLdxsO+ FFmmYoPywQUnfyAgIJiWbFokL4JptDduvAO98oRm+DHUtTS1yMm4bnGt+Rkt4uuH km6doAh79QuOEduTCA7Q2NLQxU2j1BFQ8dcGxMjtFbGm+o3QJX5/eToQdtCH6p/S tQ2JnfCdV34gl1S8S7RrxxPqU9P5iKy65/w3B2L/DPd4NCJTJmge9C2uUIHMG/oE +OK2ti/ya6u4WBxAJaPckCmSa72hOSp9aqTjztrhD7S2b9K3kdkMUKj9kTNViiAe D6XW+glcu/H9W2ruWzQLAJMpjfPF1I+4anufbVvKhu++ENEpV5LUEgx+Iyp5thuY ifNptmUXeoQiDHNUfrqlaT31yejY0nhlY2nGqmlnPNjLCMLo99RY5H9nPWUu/J4d 5Z0zuhT+WDjFR8t+WhXWGdIBlPvuk1Uqk+yGXKN5qIdp/J3Cs9U5Lgo4biXZP7nR 7iTNsRt4GpCTBB5fAzqSanezZGA2ekD/D9lDVwGnudXhVArKlPrCadiCbQQSkhgY CZYQ96Tp39YV9i2J98/
Re: mystery problem with SVN update in /head
On 2013-10-31 14:29, Matthias Apitz wrote: > > Hello, > > I have the following problem while updating an item in the ports tree: > > the SVN checkout was done on October 1; when I do now > > # cd /usr/ports/net > # rm -r vnc > # svn up vnc > Updating 'vnc': > Restored 'vnc' > Restored 'vnc/pkg-plist' > Restored 'vnc/Makefile' > Restored 'vnc/distinfo' > Restored 'vnc/pkg-descr' > Restored 'vnc/files' > Restored 'vnc/files/FreeBSD.cf-patch' > Restored 'vnc/files/extra-patch-xc-config-util-printver.c' > Restored 'vnc/files/vnc.def-patch' > Restored 'vnc/files/extra-patch-fix_Xvnc_no_valid_address' > Restored 'vnc/files/patch-unix-xc-programs-Xserver-vnc-Imakefile' > Restored 'vnc/files/extra-patch-xfree86' > Restored 'vnc/files/patch-unix-x0vncserver-x0vncserver.cxx' > Restored 'vnc/files/patch-unix-xc-programs-Xserver-vnc-XserverDesktop.h' > Restored 'vnc/files/patch-xc-programs-Xserver-vnc-vncExtInit.cc' > At revision 332203. > > some files are missing (marked below) > > also a > > # rm -r vnc > # svn co svn://svn.freebsd.org/ports/head/net/vnc > > does not help; only doing the checkout in an empty space like > > # cd /tmp > # svn co svn://svn.freebsd.org/ports/head/net/vnc > Avnc/pkg-plist > Avnc/Makefile > Avnc/distinfo > Avnc/pkg-descr > Avnc/files > Avnc/files/patch-unix-tx-TXImage.cxx > ^ > Avnc/files/patch-unix-x0vncserver-x0vncserver.cxx > Avnc/files/patch-common-network-TcpSocket.cxx > ^ > Avnc/files/patch-unix-xc-programs-Xserver-vnc-XserverDesktop.h > Avnc/files/patch-xc-programs-Xserver-vnc-vncExtInit.cc > Avnc/files/FreeBSD.cf-patch > Avnc/files/extra-patch-xc-config-util-printver.c > Avnc/files/vnc.def-patch > Avnc/files/extra-patch-fix_Xvnc_no_valid_address > Avnc/files/patch-unix-x0vncserver-Image.cxx > ^ > Avnc/files/patch-unix-xc-programs-Xserver-vnc-Imakefile > Avnc/files/extra-patch-xfree86 > Checked out revision 332240. > > brings the marked files to my disk; why is this? It's more interesting to look with `svn stat' if your copy has cached some local modifications or blocking conflicts from local editing. Tip: running from time to time the command `svn cleanup' should prevent this issue. http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.cleanup.html Nice side effect from `svn cleanup' > du -h -d1 /usr/ports/.svn/ 619M/usr/ports/.svn/pristine 2.0k/usr/ports/.svn/tmp 695M/usr/ports/.svn/ > find /usr/ports/.svn/ -type f | wc -l 134004 > svn cleanup > du -h -d1 /usr/ports/.svn/ 430M/usr/ports/.svn/pristine 2.0k/usr/ports/.svn/tmp 506M/usr/ports/.svn/ > find /usr/ports/.svn/ -type f | wc -l 117269 PS: If you even want to get back some more space try the command > sqlite3 .svn/wc.db "vacuum" -- Regards, olli ___ 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: Official FreeBSD Binary Packages now available for pkgng
... I still think the SRV record stuff is a bad idea. Well, I think it's a great idea - because I plan on supporting it in the next HTTP thing I write - but not having an A record is going to continue to bite things. Also, http+pkg:// isn't a defined protocol either and some strict proxies may actually reject it. You should go back to the http:// protocol. -adrian (with his HTTP hat on..) On 31 October 2013 14:04, Allan Jude wrote: > > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 2013-10-31 16:47, Eric Camachat wrote: >> It doesn't work with our (microsoft) proxy server, see below. >> >> root@basay:/usr/local/etc/pkg/repos # pkg update -f >> Updating repository catalogue >> pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service >> Unavailable >> pkg: No digest falling back on legacy catalog format >> pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service >> Unavailable >> root@basay:/usr/local/etc/pkg/repos # >> >> Eric >> >> >> On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery > wrote: >> >>> We are pleased to announce that official binary packages are now >>> available for pkg, the next generation package management tool for > FreeBSD. >>> >>> Pkg allows you to either use ports with portmaster/portupgrade or to >>> have binary remote packages without ports. >>> >>> We have binary packages available for i386 and amd64 on >>> 8.3,8.4,9.1,9.2,10.0 and 11 (head). >>> >>> Pkg will be the default starting in FreeBSD 10. >>> >>> The pkg_install suite of tools pkg_create(1), pkg_add(1), and >>> pkg_info(1) (which ports also use), are deprecated and will be >>> discontinued in roughly 6 months. A communication regarding the >>> deprecation of the pkg_install suite of tools will be sent separately in >>> the future. >>> >>> If you are currently not using pkg and wish to, run the following as >>> root. Be sure not to add WITH_PKGNG=yes to your make.conf until after >>> pkg is installed. >>> >>> # cd /usr/ports/ports-mgmt/pkg && make install clean >>> # echo WITH_PKGNG=yes >> /etc/make.conf >>> # pkg2ng >>> >>> You can now either continue to use ports with portmaster/portupgrade, as >>> before or switch to using binary packages only. >>> >>> >>> To use binary packages: >>> >>> 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least >>>1.1.4_8. If it does not, first upgrade from ports. >>> 2. Remove any repository-specific configuration from >>>/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. >>>If this leaves your pkg.conf empty, just remove it. >>> 3. mkdir -p /usr/local/etc/pkg/repos >>> 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: >>> FreeBSD: { >>> url: "http://pkg.FreeBSD.org/${ABI}/latest";, >>> mirror_type: "srv", >>> enabled: "yes" >>> } >>> >>> * Note that pkg.FreeBSD.org does not have a browsable web page on it and >>> does not have a DNS A record. This is intended as it is an SRV host. >>> pkg(8) knows how to properly use it. You can use 'pkg search' to browse >>> the available packages in the repository. >>> >>> Mirrors you may use instead of the global pkg.FreeBSD.org: >>> >>> pkg.eu.FreeBSD.org >>> pkg.us-east.FreeBSD.org >>> pkg.us-west.FreeBSD.org >>> >>> Your system is now ready to use packages! >>> >>> Refer to the handbook section on pkgng for usage at >>> > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html >>> . >>> Also see 'man pkg' for examples or 'pkg help'. >>> >>> >>> Packages are built weekly from a snapshot of the Ports Collection every >>> Wednesday morning 01:00 UTC. They typically will be available in the >>> repository after a few days. >>> >>> Pkg 1.2 will be released in the coming month which will bring many >>> improvements including officially signed packages. FreeBSD 10's pkg >>> bootstrap now also supports signed pkg(8) installation. >>> >>> >>> Regards, >>> Bryan Drewery >>> on behalf of portmgr@ >>> >>> >>> ___ >>> 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" >>> >> ___ >> 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" > I am guessing the proxy passes the full HTTP request, without doing the > SRV lookup, and then can't find the A record. > > I wonder if the http+pkg:// protocol can solve this, likely will require > a patch to fetch to implement the logic to do the dns lookup and make > the proxies request for the real hostname > > - -- > Allan Jude > -BEGIN PGP SIGNATURE- > Version: GnuPG v2.0.16 (MingW32) > Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ > > iQIcBAEBAgAGBQJScsXlAAoJEJrBFpNRJZKfvGUP/juCxjR30BPycq1wsPg/p1X9 > oVorgOaFYYEo5Wg13J
Re: Official FreeBSD Binary Packages now available for pkgng
On 10/31/2013 4:06 PM, Adrian Chadd wrote: > ... I still think the SRV record stuff is a bad idea. > > Well, I think it's a great idea - because I plan on supporting it in > the next HTTP thing I write - but not having an A record is going to > continue to bite things. I don't like it either, it's not up to portmgr. > > Also, http+pkg:// isn't a defined protocol either and some strict > proxies may actually reject it. You should go back to the http:// > protocol. It's not real. It's a client-side thing only. The "pkg+" is stripped away before the fetch. It's only intended to make people realize they can't just drop it into firefox and hit enter. 1.2 adds support for it which is coming soon, but it doesn't really change much. > > > -adrian > > (with his HTTP hat on..) > > > On 31 October 2013 14:04, Allan Jude wrote: >> > On 2013-10-31 16:47, Eric Camachat wrote: It doesn't work with our (microsoft) proxy server, see below. root@basay:/usr/local/etc/pkg/repos # pkg update -f Updating repository catalogue pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service Unavailable pkg: No digest falling back on legacy catalog format pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service Unavailable root@basay:/usr/local/etc/pkg/repos # Eric On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery > wrote: > We are pleased to announce that official binary packages are now > available for pkg, the next generation package management tool for > FreeBSD. > > Pkg allows you to either use ports with portmaster/portupgrade or to > have binary remote packages without ports. > > We have binary packages available for i386 and amd64 on > 8.3,8.4,9.1,9.2,10.0 and 11 (head). > > Pkg will be the default starting in FreeBSD 10. > > The pkg_install suite of tools pkg_create(1), pkg_add(1), and > pkg_info(1) (which ports also use), are deprecated and will be > discontinued in roughly 6 months. A communication regarding the > deprecation of the pkg_install suite of tools will be sent separately in > the future. > > If you are currently not using pkg and wish to, run the following as > root. Be sure not to add WITH_PKGNG=yes to your make.conf until after > pkg is installed. > > # cd /usr/ports/ports-mgmt/pkg && make install clean > # echo WITH_PKGNG=yes >> /etc/make.conf > # pkg2ng > > You can now either continue to use ports with portmaster/portupgrade, as > before or switch to using binary packages only. > > > To use binary packages: > > 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least >1.1.4_8. If it does not, first upgrade from ports. > 2. Remove any repository-specific configuration from >/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. >If this leaves your pkg.conf empty, just remove it. > 3. mkdir -p /usr/local/etc/pkg/repos > 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: > FreeBSD: { > url: "http://pkg.FreeBSD.org/${ABI}/latest";, > mirror_type: "srv", > enabled: "yes" > } > > * Note that pkg.FreeBSD.org does not have a browsable web page on it and > does not have a DNS A record. This is intended as it is an SRV host. > pkg(8) knows how to properly use it. You can use 'pkg search' to browse > the available packages in the repository. > > Mirrors you may use instead of the global pkg.FreeBSD.org: > > pkg.eu.FreeBSD.org > pkg.us-east.FreeBSD.org > pkg.us-west.FreeBSD.org > > Your system is now ready to use packages! > > Refer to the handbook section on pkgng for usage at > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html > . > Also see 'man pkg' for examples or 'pkg help'. > > > Packages are built weekly from a snapshot of the Ports Collection every > Wednesday morning 01:00 UTC. They typically will be available in the > repository after a few days. > > Pkg 1.2 will be released in the coming month which will bring many > improvements including officially signed packages. FreeBSD 10's pkg > bootstrap now also supports signed pkg(8) installation. > > > Regards, > Bryan Drewery > on behalf of portmgr@ > > > ___ > 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" > ___ 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" > I am gue
Re: Official FreeBSD Binary Packages now available for pkgng
Same result, neither pkg+http:// nor http+pkg:// worked with proxy server. Eric On Thu, Oct 31, 2013 at 2:09 PM, Bryan Drewery wrote: > On 10/31/2013 4:06 PM, Adrian Chadd wrote: > > ... I still think the SRV record stuff is a bad idea. > > > > Well, I think it's a great idea - because I plan on supporting it in > > the next HTTP thing I write - but not having an A record is going to > > continue to bite things. > > I don't like it either, it's not up to portmgr. > > > > > Also, http+pkg:// isn't a defined protocol either and some strict > > proxies may actually reject it. You should go back to the http:// > > protocol. > > It's not real. It's a client-side thing only. The "pkg+" is stripped > away before the fetch. It's only intended to make people realize they > can't just drop it into firefox and hit enter. > > 1.2 adds support for it which is coming soon, but it doesn't really > change much. > > > > > > > -adrian > > > > (with his HTTP hat on..) > > > > > > On 31 October 2013 14:04, Allan Jude wrote: > >> > > On 2013-10-31 16:47, Eric Camachat wrote: > It doesn't work with our (microsoft) proxy server, see below. > > root@basay:/usr/local/etc/pkg/repos # pkg update -f > Updating repository catalogue > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: > Service > Unavailable > pkg: No digest falling back on legacy catalog format > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: > Service > Unavailable > root@basay:/usr/local/etc/pkg/repos # > > Eric > > > On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery > > wrote: > > > We are pleased to announce that official binary packages are now > > available for pkg, the next generation package management tool for > > FreeBSD. > > > > Pkg allows you to either use ports with portmaster/portupgrade or to > > have binary remote packages without ports. > > > > We have binary packages available for i386 and amd64 on > > 8.3,8.4,9.1,9.2,10.0 and 11 (head). > > > > Pkg will be the default starting in FreeBSD 10. > > > > The pkg_install suite of tools pkg_create(1), pkg_add(1), and > > pkg_info(1) (which ports also use), are deprecated and will be > > discontinued in roughly 6 months. A communication regarding the > > deprecation of the pkg_install suite of tools will be sent > separately in > > the future. > > > > If you are currently not using pkg and wish to, run the following as > > root. Be sure not to add WITH_PKGNG=yes to your make.conf until after > > pkg is installed. > > > > # cd /usr/ports/ports-mgmt/pkg && make install clean > > # echo WITH_PKGNG=yes >> /etc/make.conf > > # pkg2ng > > > > You can now either continue to use ports with > portmaster/portupgrade, as > > before or switch to using binary packages only. > > > > > > To use binary packages: > > > > 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least > >1.1.4_8. If it does not, first upgrade from ports. > > 2. Remove any repository-specific configuration from > >/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. > >If this leaves your pkg.conf empty, just remove it. > > 3. mkdir -p /usr/local/etc/pkg/repos > > 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: > > FreeBSD: { > > url: "http://pkg.FreeBSD.org/${ABI}/latest";, > > mirror_type: "srv", > > enabled: "yes" > > } > > > > * Note that pkg.FreeBSD.org does not have a browsable web page on > it and > > does not have a DNS A record. This is intended as it is an SRV host. > > pkg(8) knows how to properly use it. You can use 'pkg search' to > browse > > the available packages in the repository. > > > > Mirrors you may use instead of the global pkg.FreeBSD.org: > > > > pkg.eu.FreeBSD.org > > pkg.us-east.FreeBSD.org > > pkg.us-west.FreeBSD.org > > > > Your system is now ready to use packages! > > > > Refer to the handbook section on pkgng for usage at > > > > > http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html > > . > > Also see 'man pkg' for examples or 'pkg help'. > > > > > > Packages are built weekly from a snapshot of the Ports Collection > every > > Wednesday morning 01:00 UTC. They typically will be available in the > > repository after a few days. > > > > Pkg 1.2 will be released in the coming month which will bring many > > improvements including officially signed packages. FreeBSD 10's pkg > > bootstrap now also supports signed pkg(8) installation. > > > > > > Regards, > > Bryan Drewery > > on behalf of portmgr@ > > > > > > ___ > > freebsd-current@freebsd.org mailing list > >>
Re: Official FreeBSD Binary Packages now available for pkgng
On 10/31/2013 4:25 PM, Eric Camachat wrote: > Same result, neither pkg+http:// nor http+pkg:// worked with proxy server. > Top-posting kills babies pkg+http is NOT supported in 1.1 and as I said, changes nothing. > Eric > > > On Thu, Oct 31, 2013 at 2:09 PM, Bryan Drewery wrote: > >> On 10/31/2013 4:06 PM, Adrian Chadd wrote: >>> ... I still think the SRV record stuff is a bad idea. >>> >>> Well, I think it's a great idea - because I plan on supporting it in >>> the next HTTP thing I write - but not having an A record is going to >>> continue to bite things. >> >> I don't like it either, it's not up to portmgr. >> >>> >>> Also, http+pkg:// isn't a defined protocol either and some strict >>> proxies may actually reject it. You should go back to the http:// >>> protocol. >> >> It's not real. It's a client-side thing only. The "pkg+" is stripped >> away before the fetch. It's only intended to make people realize they >> can't just drop it into firefox and hit enter. >> >> 1.2 adds support for it which is coming soon, but it doesn't really >> change much. >> >>> >>> >>> -adrian >>> >>> (with his HTTP hat on..) >>> >>> >>> On 31 October 2013 14:04, Allan Jude wrote: >>> On 2013-10-31 16:47, Eric Camachat wrote: >> It doesn't work with our (microsoft) proxy server, see below. >> >> root@basay:/usr/local/etc/pkg/repos # pkg update -f >> Updating repository catalogue >> pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: >> Service >> Unavailable >> pkg: No digest falling back on legacy catalog format >> pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: >> Service >> Unavailable >> root@basay:/usr/local/etc/pkg/repos # >> >> Eric >> >> >> On Wed, Oct 30, 2013 at 7:10 PM, Bryan Drewery >>> wrote: >> >>> We are pleased to announce that official binary packages are now >>> available for pkg, the next generation package management tool for >>> FreeBSD. >>> >>> Pkg allows you to either use ports with portmaster/portupgrade or to >>> have binary remote packages without ports. >>> >>> We have binary packages available for i386 and amd64 on >>> 8.3,8.4,9.1,9.2,10.0 and 11 (head). >>> >>> Pkg will be the default starting in FreeBSD 10. >>> >>> The pkg_install suite of tools pkg_create(1), pkg_add(1), and >>> pkg_info(1) (which ports also use), are deprecated and will be >>> discontinued in roughly 6 months. A communication regarding the >>> deprecation of the pkg_install suite of tools will be sent >> separately in >>> the future. >>> >>> If you are currently not using pkg and wish to, run the following as >>> root. Be sure not to add WITH_PKGNG=yes to your make.conf until after >>> pkg is installed. >>> >>> # cd /usr/ports/ports-mgmt/pkg && make install clean >>> # echo WITH_PKGNG=yes >> /etc/make.conf >>> # pkg2ng >>> >>> You can now either continue to use ports with >> portmaster/portupgrade, as >>> before or switch to using binary packages only. >>> >>> >>> To use binary packages: >>> >>> 1. Ensure your pkg(8) is up-to-date. 'pkg -v' should say at least >>>1.1.4_8. If it does not, first upgrade from ports. >>> 2. Remove any repository-specific configuration from >>>/usr/local/etc/pkg.conf, such as PACKAGESITE, MIRROR_TYPE, PUBKEY. >>>If this leaves your pkg.conf empty, just remove it. >>> 3. mkdir -p /usr/local/etc/pkg/repos >>> 4. Create the file /usr/local/etc/pkg/repos/FreeBSD.conf with: >>> FreeBSD: { >>> url: "http://pkg.FreeBSD.org/${ABI}/latest";, >>> mirror_type: "srv", >>> enabled: "yes" >>> } >>> >>> * Note that pkg.FreeBSD.org does not have a browsable web page on >> it and >>> does not have a DNS A record. This is intended as it is an SRV host. >>> pkg(8) knows how to properly use it. You can use 'pkg search' to >> browse >>> the available packages in the repository. >>> >>> Mirrors you may use instead of the global pkg.FreeBSD.org: >>> >>> pkg.eu.FreeBSD.org >>> pkg.us-east.FreeBSD.org >>> pkg.us-west.FreeBSD.org >>> >>> Your system is now ready to use packages! >>> >>> Refer to the handbook section on pkgng for usage at >>> >>> >> http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/pkgng-intro.html >>> . >>> Also see 'man pkg' for examples or 'pkg help'. >>> >>> >>> Packages are built weekly from a snapshot of the Ports Collection >> every >>> Wednesday morning 01:00 UTC. They typically will be available in the >>> repository after a few days. >>> >>> Pkg 1.2 will be released in the coming month which will bring many >>> improvements including officially signed packages. FreeBSD 10's pkg >>> bootstrap now also supports signed pkg(8) installation. >>> >>> >>> Regards, >>
Re: Official FreeBSD Binary Packages now available for pkgng
On 31/10/2013 21:04, Allan Jude wrote: > I wonder if the http+pkg:// protocol can solve this, likely will require > a patch to fetch to implement the logic to do the dns lookup and make > the proxies request for the real hostname It's pkg+http:// or pkg+https:// or pkg+ssh:// or -- well, you get the idea. pkg+http:// is really exactly the same as the current http:// PACKAGESITE URLs -- the new code pretty much checks that the first four characters are 'pkg+', moves the string pointer to the following character (ie the h in http://) and then carries on exactly as it works right now. We'll be accepting either form certainly throughout the lifetime of 1.2.x release, but printing a warning to switch to pkg+http:// where relevant. The reason for doing this is that according to RFC 2616 in a URL of the form http://some.add.ress/ the 'some.add.ress' bit has to be either an A or a CNAME record that can be resolved to an IP address. Since we can't change the meaning of 'http://' in URLs, we've just invented our own URL scheme. Once it is in reasonably widespread use it's pretty much going to be de-facto accepted, and we can apply to ICANN to have the scheme officially registered. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: Official FreeBSD Binary Packages now available for pkgng
On 10/31/2013 3:47 PM, Eric Camachat wrote: > It doesn't work with our (microsoft) proxy server, see below. > > root@basay:/usr/local/etc/pkg/repos # pkg update -f > Updating repository catalogue > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: Service > Unavailable > pkg: No digest falling back on legacy catalog format > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service > Unavailable > root@basay:/usr/local/etc/pkg/repos # I somewhat doubt this is a DNS or SRV issue. The pkg(8) client will do the DNS lookup and then contact the real server directly. It's more likely your proxy is just blocking the requests. Perhaps ask your administrator to add an exception for *.freebsd.org:80 :) -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: Official FreeBSD Binary Packages now available for pkgng
On 31/10/2013 21:38, Bryan Drewery wrote: > On 10/31/2013 4:25 PM, Eric Camachat wrote: >> > Same result, neither pkg+http:// nor http+pkg:// worked with proxy server. >> > > Top-posting kills babies > > pkg+http is NOT supported in 1.1 and as I said, changes nothing. Also the request that pkg(8) makes after resolving the SRV record is a bog standard HTTP GET to one of the pkg.freebsd.org servers. It's using libfetch, so all the usual environment variables to do with HTTP proxying should just work. If you do some traffic capture with eg. wireshark, you'll be able to see that for yourself, and look at the details of the HTTP packets. pkg(8) does take some care to present the modification time of any local copy of a package it is trying to download thus allowing a web server to send a 304 'Not Modified' response where relevant. However there's no recommendation on what (if any) Expires or Cache-Control headers the repo's web server should use. Personally, I just take whatever the defaults are that come with Apache on my own local repos. Which works for me just fine, but then again, I don't have any proxying to deal with in my setup. If you think that the settings used on the pkg.freebsd.org servers could be improved, then make your case -- if your arguments have merit, then I'm sure the server admins will listen. Note however that this is all server-side, and not something under the control of your local copy of pkg. Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey JID: matt...@infracaninophile.co.uk signature.asc Description: OpenPGP digital signature
Re: Official FreeBSD Binary Packages now available for pkgng
browsing www.freebsd.org worked fine. tried pkg.freebsd.org it got below. Our DNS server can resolve proxy server only. Only proxy server can resolve internet sites, this is how our company force all traffic went through proxy server. Eric Network Error (dns_server_failure) Your request could not be processed because an error occurred contacting the DNS server. The DNS server may be temporarily unavailable, or there could be a network problem. If problem persists, please open a ticket with Motorola help desk; and copy and paste this page in ticket. Date/Time: 2013-10-3122:11:37 Request: GET http://pkg.freebsd.org/ Error: (dns_server_failure) Proxy Name:proxy Proxy IP: xxx.xxx.xxx.xxx Client IP: zzz.zzz.zzz.zzz Referer URL: On Thu, Oct 31, 2013 at 2:51 PM, Bryan Drewery wrote: > On 10/31/2013 3:47 PM, Eric Camachat wrote: > > It doesn't work with our (microsoft) proxy server, see below. > > > > root@basay:/usr/local/etc/pkg/repos # pkg update -f > > Updating repository catalogue > > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/digests.txz: > Service > > Unavailable > > pkg: No digest falling back on legacy catalog format > > pkg: http://pkg.FreeBSD.org/freebsd:10:x86:64/latest/repo.txz: Service > > Unavailable > > root@basay:/usr/local/etc/pkg/repos # > > I somewhat doubt this is a DNS or SRV issue. The pkg(8) client will do > the DNS lookup and then contact the real server directly. It's more > likely your proxy is just blocking the requests. Perhaps ask your > administrator to add an exception for *.freebsd.org:80 :) > > -- > Regards, > Bryan Drewery > > ___ 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: Official FreeBSD Binary Packages now available for pkgng
On Thu, Oct 31, 2013 at 3:15 PM, Eric Camachat wrote: > browsing www.freebsd.org worked fine. > tried pkg.freebsd.org it got below. > Our DNS server can resolve proxy server only. > Only proxy server can resolve internet sites, this is how our company force > all traffic went through proxy server. > > Eric > > Network Error (dns_server_failure) > > Your request could not be processed because an error occurred contacting > the DNS server. The DNS server may be temporarily unavailable, or there > could be a network problem. > If problem persists, please open a ticket with Motorola help desk; and copy > and paste this page in ticket. > > Date/Time: 2013-10-31 22:11:37 Request: GET http://pkg.freebsd.org/ Error: > (dns_server_failure) Proxy Name:proxy > Proxy IP: xxx.xxx.xxx.xxx Client IP: zzz.zzz.zzz.zzz > Referer URL: > So, then manually specific a specific pkg mirror and by-pass the DNS SRV record resolution step. -- Freddie Cash fjwc...@gmail.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"
Re: Fatal trap 12: page fault while in kernel mode (FUSE related?)
FYI, works fine after changed to pkg0.isc.FreeBSD.org. # pkg update Updating repository catalogue digests.txz 100% 960KB 240.0KB/s 80.0KB/s 00:04 packagesite.txz 100% 5258KB 309.3KB/s 498.5KB/s 00:17 Incremental update completed, 0 packages processed: 0 packages updated, 0 removed and 21724 added. On Thu, Oct 31, 2013 at 9:59 AM, Kevin Oberman wrote: > On Tue, Oct 29, 2013 at 3:24 AM, Alexey Dokuchaev wrote: > > > Hi again, > > > > I was running out of space on my UFS partition and decided to use big > NTFS > > one I also have on the drive. I've mounted it with ntfs-3g and our > native > > fuse.ko. I needed the scratch space to built Open/LibreOffice on it > *LOL*. > > Well, it failed with a panic (see the excerpt from text core at the end > of > > this email; full debug info is available upon request). > > > > This is on fresh 11-CURRENT, i386. > > > > ./danfe > > > > I get a very similar panic when I attempt an rsync from a remote system > to > my NTFS drive. Very easy to reproduce. Something in fuse goes off the > rails under active R/W activity, it seems. > -- > R. Kevin Oberman, Network Engineer > E-mail: rkober...@gmail.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" > ___ 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 amd64/amd64
TB --- 2013-10-31 20:40:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2013-10-31 20:40:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-10-31 20:40:18 - starting HEAD tinderbox run for amd64/amd64 TB --- 2013-10-31 20:40:18 - cleaning the object tree TB --- 2013-10-31 20:42:57 - /usr/local/bin/svn stat /src TB --- 2013-10-31 20:43:00 - At svn revision 257472 TB --- 2013-10-31 20:43:01 - building world TB --- 2013-10-31 20:43:01 - CROSS_BUILD_TESTING=YES TB --- 2013-10-31 20:43:01 - MAKEOBJDIRPREFIX=/obj TB --- 2013-10-31 20:43:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-10-31 20:43:01 - SRCCONF=/dev/null TB --- 2013-10-31 20:43:01 - TARGET=amd64 TB --- 2013-10-31 20:43:01 - TARGET_ARCH=amd64 TB --- 2013-10-31 20:43:01 - TZ=UTC TB --- 2013-10-31 20:43:01 - __MAKE_CONF=/dev/null TB --- 2013-10-31 20:43:01 - cd /src TB --- 2013-10-31 20:43:01 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Thu Oct 31 20:43:07 UTC 2013 >>> 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 >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Fri Nov 1 00:31:40 UTC 2013 TB --- 2013-11-01 00:31:40 - generating LINT kernel config TB --- 2013-11-01 00:31:40 - cd /src/sys/amd64/conf TB --- 2013-11-01 00:31:40 - /usr/bin/make -B LINT TB --- 2013-11-01 00:31:40 - cd /src/sys/amd64/conf TB --- 2013-11-01 00:31:40 - /usr/sbin/config -m LINT TB --- 2013-11-01 00:31:40 - building LINT kernel TB --- 2013-11-01 00:31:40 - CROSS_BUILD_TESTING=YES TB --- 2013-11-01 00:31:40 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-01 00:31:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-01 00:31:40 - SRCCONF=/dev/null TB --- 2013-11-01 00:31:40 - TARGET=amd64 TB --- 2013-11-01 00:31:40 - TARGET_ARCH=amd64 TB --- 2013-11-01 00:31:40 - TZ=UTC TB --- 2013-11-01 00:31:40 - __MAKE_CONF=/dev/null TB --- 2013-11-01 00:31:40 - cd /src TB --- 2013-11-01 00:31:40 - /usr/bin/make -B buildkernel KERNCONF=LINT >>> Kernel build for LINT started on Fri Nov 1 00:31:40 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT completed on Fri Nov 1 01:06:08 UTC 2013 TB --- 2013-11-01 01:06:08 - cd /src/sys/amd64/conf TB --- 2013-11-01 01:06:08 - /usr/sbin/config -m LINT-NOINET TB --- 2013-11-01 01:06:08 - building LINT-NOINET kernel TB --- 2013-11-01 01:06:08 - CROSS_BUILD_TESTING=YES TB --- 2013-11-01 01:06:08 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-01 01:06:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-01 01:06:08 - SRCCONF=/dev/null TB --- 2013-11-01 01:06:08 - TARGET=amd64 TB --- 2013-11-01 01:06:08 - TARGET_ARCH=amd64 TB --- 2013-11-01 01:06:08 - TZ=UTC TB --- 2013-11-01 01:06:08 - __MAKE_CONF=/dev/null TB --- 2013-11-01 01:06:08 - cd /src TB --- 2013-11-01 01:06:08 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Fri Nov 1 01:06:09 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Fri Nov 1 01:38:25 UTC 2013 TB --- 2013-11-01 01:38:25 - cd /src/sys/amd64/conf TB --- 2013-11-01 01:38:25 - /usr/sbin/config -m LINT-NOINET6 TB --- 2013-11-01 01:38:25 - building LINT-NOINET6 kernel TB --- 2013-11-01 01:38:25 - CROSS_BUILD_TESTING=YES TB --- 2013-11-01 01:38:25 - MAKEOBJDIRPREFIX=/obj TB --- 2013-11-01 01:38:25 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-11-01 01:38:25 - SRCCONF=/dev/null TB --- 2013-11-01 01:38:25 - TARGET=amd64 TB --- 2013-11-01 01:38:25 - TARGET_ARCH=amd64 TB --- 2013-11-01 01:38:25 - TZ=UTC TB --- 2013-11-01 01:38:25 - __MAKE_CONF=/dev/null TB --- 2013-11-01 01:38:25 - cd /src TB --- 2013-11-01 01:38:25 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Fri Nov 1 01:38:25 UTC 2013 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Fri Nov 1 02:10:20 UTC 2013 TB --- 2013-11-01 02:10:20 - cd /src/sys/amd64/conf TB --- 2013-11-01 02:10:20 - /usr/sbin/confi
Re: error building stable/9 on FreeBSD 10
I had same issues, since 10 is have some CLANG changes it is not ready to cross-build 9. I think this deserve PR as major problem. 2013/10/31 Luigi Rizzo > I am having trouble building stable/9 on FreeBSD 10: > > luigi@bsd10:~ # uname -a > FreeBSD bsd10 10.0-BETA1 FreeBSD 10.0-BETA1 #0 r256420: Sun Oct 13 > 01:43:07 UTC > 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > # ./do TREE TARGET > # is a script that invokes a make in the source tree (first > argument), > # for a speciic target (second argument) and with a few options to > # do the build in a local subtree. > # Works fine building head on FreeBSD 10 and > # building 9 and head on FreeBSD 9 > > luigi@bsd10:~ ./do RELENG_9 toolchain > > > ... > ===> gnu/usr.bin/cc/cc_tools (depend) > --- genattrtab --- > --- genautomata --- > --- genconditions --- > --- genconfig --- > --- genconstants --- > --- genemit --- > --- genopinit --- > --- genoutput --- > --- genconstants --- > cc -O2 -pipe -I. -DGCCVER=\"4.2\" -DIN_GCC -DHAVE_CONFIG_H > -DPREFIX=\"/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/usr\" > -I/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../cc_tools > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcc/config > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/include > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libcpp/include > -I/usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools/../../../../contrib/gcclibs/libdecnumber > -g -DGENERATOR_FILE -DHAVE_CONFIG_H -std=gnu89 > -I/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/ > FreeBSD/RELENG_9/tmp/legacy/usr/include -static > -L/usr/home/luigi/FreeBSD/RELENG_9/../usr/obj-pico-amd64/usr/home/luigi/FreeBSD/RELENG_9/tmp/legacy/usr/lib > -o genconstants genconstants.o rtl.o read-rtl.o ggc-none.o vec.o > min-insn-modes.o gensupport.o print-rtl.o errors.o libiberty.a -lm > print-rtl.o: In function `print_rtx': > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x631): > undefined reference to `dump_addr' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6d1): > undefined reference to `insn_file' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6e9): > undefined reference to `insn_file' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x6f4): > undefined reference to `insn_line' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x772): > undefined reference to `reg_names' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xc04): > undefined reference to `dump_addr' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xc61): > undefined reference to `print_node_brief' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xd39): > undefined reference to `bitmap_print' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xe62): > undefined reference to `real_to_decimal' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xe90): > undefined reference to `real_to_hexadecimal' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0xfac): > undefined reference to `mode_size' > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_int/../../../../contrib/gcc/print-rtl.c:(.text+0x1027): > undefined reference to `mode_size' > cc: error: linker command failed with exit code 1 (use -v to see > invocation) > *** [genconstants] Error code 1 > > make[4]: stopped in > /usr/home/luigi/FreeBSD/RELENG_9/gnu/usr.bin/cc/cc_tools > > > > any idea on what is going wrong ? > > cheers > luigi > ___ > 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" > -- Regards, Alexander Yerenkow ___ 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"