Re:
2013/1/30 AN a...@neu.net: With all due respect to developers, are these changes tested at all before they are added to the codebase? Won't sound respectful if the problem is not related to that commit. Which compiler are you using for the base system, and for ports ? (more specifically for the virtualbox ports) I had the same kind of errors when compiling virtualbox with gcc46, not the one in base. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r246057: buildworld fails with: /usr/obj/usr/src/tmp/usr/lib/libc++.so: undefined reference to `std::bad_alloc::~bad_alloc()'
On 31 Jan 2013, at 04:37, O. Hartmann wrote: First, I suspected the c++ option -std=c++11 I issued in /etc/src.conf when building the sources - I did this before without any problems. Then, leaving the build without -std=c++11 option, I get the following error below and compilation stops. Maybe this reveals the real issue. The revision of the OS I compile on and where it fails is FreeBSD 10.0-CURRENT #2 r245995: Sun Jan 27 19:56:47 CET 2013. This is maybe of any help. If you are going to compile with -stdlib=libc++ and not -std=c++11, then you probably need to add -Wno-c++11-extensions. Some C++11isms have crept into the libc++ headers. I think some have been fixed upstream, so I'll do a new import soon and see. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re:
On 30 Jan 2013, at 21:23, AN wrote: VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found GLIBCXX_3.4.15 is the symbol version of the libstdc++ that ships with gcc 4.6. You are trying to compile something against a (newer) libstdc++ from ports and then run it linked against the (older) libstdc++ from the base system. Oddly enough, this doesn't work. David signature.asc Description: Message signed with OpenPGP using GPGMail
Re: buildworld error
On 01/31/13 05:43, O. Hartmann wrote: Am 01/31/13 05:06, schrieb Jesse: z On 1/31/13, Jesse je...@glx.me wrote: i set these in make.conf: CXXFLAGS+=-stdlib=libc++ CXXFLAGS+=-std=c++11 i comment them and rebuild world ok but it works at previous revision. On 1/30/13, Dimitry Andric d...@freebsd.org wrote: On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ 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 see the very same issue and reported this already. Since I'm not a professional developer, I'm not quite sure what and how to report the issue in exactly and accurate. In my case, this issue came out of the blue. I also have set CXXFLAGS+= -stdlib=libc++ -std=c++11 but in /etc/src.conf. Commenting out -std=c++11 makes the build of world fail with something like [...] fatal error: too many errors emitted, stopping now [-ferror-limit=] In file included from /usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597: /usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error: inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions] [...] which sounds strange to me, since I completely erase /usr/obj before building and I do not use a ccache or any other similar facility. Regards, Oliver I can confirm, that disabling CXXFLAGS+= -stdlib=libc++ -std=c++11 completely solves the problem. Using -stdlib=libc++ building the system's sources decalres CURRENT broken. signature.asc Description: OpenPGP digital signature
Re: mounting root from NFS via ROOTDEVNAME
Hi, On Jan 30, 2013, at 22:43, Craig Rodrigues rodr...@crodrigues.org wrote: What you need to do is, before the FreeBSD kernel boots, your loader needs to export some environment variables. This will trigger the various behaviors in the FreeBSD mount code. the loader can export some environment variables (this is how I get the serial console working.) So as I suggested before, you should continue with: (1) Have /usr/home/elars/dst/etc/fstab with: # Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro00 Done. (2) From your loader, you need to export this environment variable, so that the kernel can get it with getenv(). You need at least: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Done. Now, there are some other environment variables you need to export from the loader. boot.netif.ip boot.netif.netmask boot.netif.gateway boot.nfsroot.server boot.nfsroot.path Done. I also ripped out all the BOOTP* options from the kernel. However, this still fails: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Loader variables: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Manual root filesystem specification: fstype:device [options] Mount device using filesystem fstype and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) empty lineAbort manual input mountroot I did a tcpdump and no traffic shows up on the correct interface (em4). I guess I need to set yet another loader environment variable to indicate which interface I'd like to use. Looking at the source, I only see boot.netif.name, but setting that to em4 doesn't help either. Any further ideas? Thanks, Lars ___ 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: mounting root from NFS via ROOTDEVNAME
Done. I also ripped out all the BOOTP* options from the kernel. However, this still fails: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Loader variables: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Manual root filesystem specification: fstype:device [options] Mount device using filesystem fstype and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) empty lineAbort manual input mountroot I did a tcpdump and no traffic shows up on the correct interface (em4). I guess I need to set yet another loader environment variable to indicate which interface I'd like to use. Looking at the source, I only see boot.netif.name, but setting that to em4 doesn't help either. Any further ideas? Thanks, Lars Just a shot in the dark, did you actually tell it to do the root mount ro, or try with the nfs share as rw? Best regards Andreas ___ 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: mounting root from NFS via ROOTDEVNAME
On 31.01.2013 12:27, Eggert, Lars wrote: Hi, On Jan 30, 2013, at 22:43, Craig Rodrigues rodr...@crodrigues.org wrote: What you need to do is, before the FreeBSD kernel boots, your loader needs to export some environment variables. This will trigger the various behaviors in the FreeBSD mount code. the loader can export some environment variables (this is how I get the serial console working.) So as I suggested before, you should continue with: (1) Have /usr/home/elars/dst/etc/fstab with: # Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro00 Done. (2) From your loader, you need to export this environment variable, so that the kernel can get it with getenv(). You need at least: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Done. Now, there are some other environment variables you need to export from the loader. boot.netif.ip boot.netif.netmask boot.netif.gateway boot.nfsroot.server boot.nfsroot.path Done. I also ripped out all the BOOTP* options from the kernel. However, this still fails: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Loader variables: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Manual root filesystem specification: fstype:device [options] Mount device using filesystem fstype and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) empty lineAbort manual input mountroot I did a tcpdump and no traffic shows up on the correct interface (em4). I guess I need to set yet another loader environment variable to indicate which interface I'd like to use. Looking at the source, I only see boot.netif.name, but setting that to em4 doesn't help either. Any further ideas? The interface doesn't have a name during loader stage. The kernel finds the interface to use based on the MAC address. You should set boot.netif.hwaddr as well in the kernel environment. -- Andre ___ 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: mounting root from NFS via ROOTDEVNAME
On Jan 31, 2013, at 12:45, Andreas Nilsson andrn...@gmail.com wrote: Just a shot in the dark, did you actually tell it to do the root mount ro, or try with the nfs share as rw? ro Lars ___ 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: mounting root from NFS via ROOTDEVNAME
On Jan 31, 2013, at 12:53, Andre Oppermann an...@freebsd.org wrote: The interface doesn't have a name during loader stage. The kernel finds the interface to use based on the MAC address. You should set boot.netif.hwaddr as well in the kernel environment. Done, no change. Here is what's in my loader environment: boot.netif.netmask 255.255.255.0 boot.netif.gateway 10.11.12.13 boot.nfsroot.server 10.11.12.13 boot.nfsroot.path/usr/home/elars/dst boot.netif.ip10.11.12.15 boot.netif.name em4 boot.netif.hwaddrxx:xx:xx:xx:xx:xx vfs.root.mountfrom nfs:10.11.12.13:/usr/home/elars/dst And here is what I see during boot: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Lars ___ 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: buildworld error
yes, that may be the reason. I write a simple c++ program in the built-complete system. and compile it: clang++ hello.cpp -std=c++11 -stdlib=libc++ -o hello it reports undefined reference to bad_alloc errors message same as someones discuss in this mail list. I find that it is because -stdlib=libc++ will link /usr/lib/libc++.so. If compile and link the c++ code like this it reports no error: clang++ hello.cpp -c -o hello.o -std=c++11 -stdlib=libc++ clang++ hello.o -o hello /usr/lib/libc++.a The second command will force clang++ to link the static libc++ instead of the shared lib. I think the current src build the libc++.so by false. Maybe libc++.so lacks some object files to wrap. ar -tv /usr/lib/libc++.a will print all of the necessary object files. On Thu, Jan 31, 2013 at 7:20 PM, O. Hartmann ohart...@zedat.fu-berlin.dewrote: On 01/31/13 05:43, O. Hartmann wrote: Am 01/31/13 05:06, schrieb Jesse: z On 1/31/13, Jesse je...@glx.me wrote: i set these in make.conf: CXXFLAGS+=-stdlib=libc++ CXXFLAGS+=-std=c++11 i comment them and rebuild world ok but it works at previous revision. On 1/30/13, Dimitry Andric d...@freebsd.org wrote: On 2013-01-30 10:37, Jesse wrote: I just update /usr/src and make buildworld. The building proccess stop as errors: === lib/clang/libllvmx86asmparser (all) === lib/clang/libllvmx86codegen (all) === lib/clang/libllvmx86desc (all) === lib/clang/libllvmx86disassembler (all) === lib/clang/libllvmx86info (all) === lib/clang/libllvmx86instprinter (all) === lib/clang/libllvmx86utils (all) === lib/clang/libllvmdebuginfo (all) === lib/clang/libllvmexecutionengine (all) === lib/clang/libllvminterpreter (all) === lib/clang/libllvmjit (all) === lib/clang/libllvmmcdisassembler (all) === lib/clang/libllvmmcjit (all) === lib/clang/libllvmruntimedyld (all) === lib/clang/include (all) 1 error *** [everything] Error code 2 1 error *** [buildworld] Error code 2 1 error Because you are making buildworld with -j, the actual error message is not visible. Try searching back in the log to find the actual error, and post that. Alternatively, make buildworld without -j. ___ 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 see the very same issue and reported this already. Since I'm not a professional developer, I'm not quite sure what and how to report the issue in exactly and accurate. In my case, this issue came out of the blue. I also have set CXXFLAGS+= -stdlib=libc++ -std=c++11 but in /etc/src.conf. Commenting out -std=c++11 makes the build of world fail with something like [...] fatal error: too many errors emitted, stopping now [-ferror-limit=] In file included from /usr/src/lib/atf/libatf-c++/../../../contrib/atf/atf-c++/detail/application.cpp:42: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/iostream:38: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/ios:216: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/__locale:15: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/string:434: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/algorithm:594: In file included from /usr/obj/usr/src/tmp/usr/include/c++/v1/memory:597: /usr/obj/usr/src/tmp/usr/include/c++/v1/__functional_base:22:1: error: inline namespaces are a C++11 feature [-Werror,-Wc++11-extensions] [...] which sounds strange to me, since I completely erase /usr/obj before building and I do not use a ccache or any other similar facility. Regards, Oliver I can confirm, that disabling CXXFLAGS+= -stdlib=libc++ -std=c++11 completely solves the problem. Using -stdlib=libc++ building the system's sources decalres CURRENT broken. ___ 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
panic: LK_RETRY set with incompatible flags
Hi. Got this assertion on idle NFS server while `ls -la /.zfs/shares/' issued on NFS client. kern/vfs_vnops.c:_vn_lock() KASSERT((flags LK_RETRY) == 0 || error == 0, (LK_RETRY set with incompatible flags (0x%x) or an error occured (%d), panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) What does that mean and how is it possible? As you can see, both parts of assertion failed. 11 is EDEADLK 0x200400: LK_RETRY LK_UPGRADE Tracing pid 2943 tid 101532 td 0xfe004f5b7000 kdb_enter() at kdb_enter+0x3e/frame 0xff848e45ef50 vpanic() at vpanic+0x147/frame 0xff848e45ef90 kassert_panic() at kassert_panic+0x136/frame 0xff848e45f000 _vn_lock() at _vn_lock+0x70/frame 0xff848e45f070 zfs_lookup() at zfs_lookup+0x392/frame 0xff848e45f100 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xff848e45f240 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xff848e45f260 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff848e45f2b0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e45f2d0 lookup() at lookup+0x548/frame 0xff848e45f350 nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e45f400 nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e45f6b0 nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e45f8a0 nfssvc_program() at nfssvc_program+0x482/frame 0xff848e45fa00 svc_run_internal() at svc_run_internal+0x1e9/frame 0xff848e45fba0 svc_thread_start() at svc_thread_start+0xb/frame 0xff848e45fbb0 fork_exit() at fork_exit+0x84/frame 0xff848e45fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff848e45fbf0 --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffd488, rbp = 0x7fffd730 --- db show lockedvnods Locked vnodes 0xfe02e21b11d8: tag zfs, type VDIR usecount 4, writecount 0, refcount 4 mountedhere 0 flags (VI_ACTIVE) v_object 0xfe02d9f2eb40 ref 0 pages 0 lock type zfs: EXCL by thread 0xfe004f5b7000 (pid 2943, nfsd, tid 101532) -- wbr, pluknet ___ 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: panic: LK_RETRY set with incompatible flags
on 31/01/2013 15:29 Sergey Kandaurov said the following: Hi. Got this assertion on idle NFS server while `ls -la /.zfs/shares/' issued on NFS client. kern/vfs_vnops.c:_vn_lock() KASSERT((flags LK_RETRY) == 0 || error == 0, (LK_RETRY set with incompatible flags (0x%x) or an error occured (%d), panic: LK_RETRY set with incompatible flags (0x200400) or an error occured (11) What does that mean and how is it possible? As you can see, both parts of assertion failed. 11 is EDEADLK 0x200400: LK_RETRY LK_UPGRADE LK_SHARED, not LK_UPGRADE. Apparently the thread already holds an exlusive lock on the vnode, which you confirm below. Tracing pid 2943 tid 101532 td 0xfe004f5b7000 kdb_enter() at kdb_enter+0x3e/frame 0xff848e45ef50 vpanic() at vpanic+0x147/frame 0xff848e45ef90 kassert_panic() at kassert_panic+0x136/frame 0xff848e45f000 _vn_lock() at _vn_lock+0x70/frame 0xff848e45f070 zfs_lookup() at zfs_lookup+0x392/frame 0xff848e45f100 zfs_freebsd_lookup() at zfs_freebsd_lookup+0x6d/frame 0xff848e45f240 VOP_CACHEDLOOKUP_APV() at VOP_CACHEDLOOKUP_APV+0xc2/frame 0xff848e45f260 vfs_cache_lookup() at vfs_cache_lookup+0xcf/frame 0xff848e45f2b0 VOP_LOOKUP_APV() at VOP_LOOKUP_APV+0xc2/frame 0xff848e45f2d0 lookup() at lookup+0x548/frame 0xff848e45f350 nfsvno_namei() at nfsvno_namei+0x1a5/frame 0xff848e45f400 nfsrvd_lookup() at nfsrvd_lookup+0x13a/frame 0xff848e45f6b0 nfsrvd_dorpc() at nfsrvd_dorpc+0xca5/frame 0xff848e45f8a0 nfssvc_program() at nfssvc_program+0x482/frame 0xff848e45fa00 svc_run_internal() at svc_run_internal+0x1e9/frame 0xff848e45fba0 svc_thread_start() at svc_thread_start+0xb/frame 0xff848e45fbb0 fork_exit() at fork_exit+0x84/frame 0xff848e45fbf0 fork_trampoline() at fork_trampoline+0xe/frame 0xff848e45fbf0 --- trap 0xc, rip = 0x800883e9a, rsp = 0x7fffd488, rbp = 0x7fffd730 --- db show lockedvnods Locked vnodes 0xfe02e21b11d8: tag zfs, type VDIR usecount 4, writecount 0, refcount 4 mountedhere 0 flags (VI_ACTIVE) v_object 0xfe02d9f2eb40 ref 0 pages 0 lock type zfs: EXCL by thread 0xfe004f5b7000 (pid 2943, nfsd, tid 101532) -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: mounting root from NFS via ROOTDEVNAME
On Jan 31, 2013, at 12:53, Andre Oppermann an...@freebsd.org wrote: The interface doesn't have a name during loader stage. The kernel finds the interface to use based on the MAC address. You should set boot.netif.hwaddr as well in the kernel environment. Done, no change. Here is what's in my loader environment: boot.netif.netmask 255.255.255.0 boot.netif.gateway 10.11.12.13 boot.nfsroot.server 10.11.12.13 boot.nfsroot.path/usr/home/elars/dst boot.netif.ip10.11.12.15 boot.netif.name em4 boot.netif.hwaddrxx:xx:xx:xx:xx:xx vfs.root.mountfrom nfs:10.11.12.13:/usr/home/elars/dst And here is what I see during boot: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Lars a shot in the dark, but is /usr/home/elars/dst properly exported? danny ___ 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: mounting root from NFS via ROOTDEVNAME
On Jan 31, 2013, at 15:54, Daniel Braniss da...@cs.huji.ac.il wrote: a shot in the dark, but is /usr/home/elars/dst properly exported? Yep, the NFS mount works fine when I use BOOTP with a root-path option Lars ___ 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: mounting root from NFS via ROOTDEVNAME
Lars Eggert wrote: Hi, On Jan 30, 2013, at 22:43, Craig Rodrigues rodr...@crodrigues.org wrote: What you need to do is, before the FreeBSD kernel boots, your loader needs to export some environment variables. This will trigger the various behaviors in the FreeBSD mount code. the loader can export some environment variables (this is how I get the serial console working.) So as I suggested before, you should continue with: (1) Have /usr/home/elars/dst/etc/fstab with: # Options Dump Pass 10.11.12.13:/usr/home/elars/dst/ / nfs ro 0 0 Done. (2) From your loader, you need to export this environment variable, so that the kernel can get it with getenv(). You need at least: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst Done. Now, there are some other environment variables you need to export from the loader. boot.netif.ip boot.netif.netmask boot.netif.gateway boot.nfsroot.server boot.nfsroot.path Done. I also ripped out all the BOOTP* options from the kernel. Here is the complete list of environment variables from the comment in sys/nfs/nfs_diskless.c: * The loader is expected to export the following environment variables: 149 * 150 * boot.netif.name name of boot interface 151 * boot.netif.ip IP address on boot interface 152 * boot.netif.netmask netmask on boot interface 153 * boot.netif.gateway default gateway (optional) 154 * boot.netif.hwaddr hardware address of boot interface 155 * boot.nfsroot.server IP address of root filesystem server 156 * boot.nfsroot.path path of the root filesystem on server 157 * boot.nfsroot.nfshandle NFS handle for root filesystem on server 158 * boot.nfsroot.nfshandlelen and length of this handle (for NFSv3 only) 159 * boot.nfsroot.options NFS options for the root filesystem Note that boot.nfsroot.nfshandle and boot.nfsroot.nfshandlelen are not easy to get. pxeboot does a Mount RPC against the NFS server to get them. (Probably the easiest way to find out what they are is to capture packets while doing a mount of the same path and then looking at the capture via wireshark.) For this method to work, you have to specify options NFS_BOOT, but not the BOOTP* ones for the kernel. However, this still fails: Trying to mount root from nfs:10.11.12.13:/usr/home/elars/dst []... mountroot: waiting for device 10.11.12.13:/usr/home/elars/dst ... Mounting from nfs:10.11.12.13:/usr/home/elars/dst failed with error 19. Loader variables: vfs.root.mountfrom=nfs:10.11.12.13:/usr/home/elars/dst As far as I can see, the current code does not know how to turn this into a root file handle via a Mount RPC. I think a non-trivial patch to sys/nfs/bootp_subr.c would be required. As such, the only other way to make it work is to use options NFS_ROOT and specify the root file handle in the environment variables, as above. (If I recall correctly, the root file handle is specified as a string of hex digits, but look in the code in sys/nfs/nfs_diskless.c to confirm this.) rick Manual root filesystem specification: fstype:device [options] Mount device using filesystem fstype and with the specified (optional) option list. eg. ufs:/dev/da0s1a zfs:tank cd9660:/dev/acd0 ro (which is equivalent to: mount -t cd9660 -o ro /dev/acd0 /) ? List valid disk boot devices . Yield 1 second (for background tasks) empty line Abort manual input mountroot I did a tcpdump and no traffic shows up on the correct interface (em4). I guess I need to set yet another loader environment variable to indicate which interface I'd like to use. Looking at the source, I only see boot.netif.name, but setting that to em4 doesn't help either. Any further ideas? Thanks, Lars ___ 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: Trouble with recent auto-tuning changes
On 28.01.2013 20:20, Alan Cox wrote: On 01/28/2013 08:22, Ian Lepore wrote: On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote: On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore i...@freebsd.org wrote: I ran into a panic while attempting to un-tar a large file on a DreamPlug (arm-based system) running -current. The source and dest of the un-tar is the root filesystem on sdcard, and I get this: panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated Just before the panic I see the tar process get hung in a nokva wait. 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h. In r245575 the init order for mbuf limits was changed from SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the results of sizing kernel memory. Unfortunately, the process of sizing kernel memory relies on the mbuf limits; in kmeminit(): vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; Since r245575, nmbclusters is zero when this line of code runs. If I manually plugin 32768 (the number tunable_mbinit() comes up with for this platform) in that line, the panic stops happening. So we've got two problems here... one is the circular dependency in calculating the mbuf limits. The other is the fact that some non-trivial amount of kernel memory we're allowing for mbufs is actually being used for other things. That is, if my system was actually using all the mbufs that tunable_mbinit() allowed for, then this panic while untarring a huge file would still have happened. All of this is factually correct. However, it's a red herring. The real problem is that arm, unlike every other architecture in the tree, does not enable auto-sizing of the kmem map based on the physical memory size. Specifically, you'll find VM_KMEM_SIZE_SCALE defined in arch/include/vmparam.h on every other architecture, just not on arm. This auto-sizing overrides the value of VM_KMEM_SIZE. Aha. I'll investigate what other architectures do with that and try to get the same thing going for arm. i386 or (32-bit) MIPS would be the most similar. Also, I would encourage you to look for other definitions that those architectures have that arm doesn't. As physical memory sizes continue to grow on arm-based systems, they may require other changes in vmparam.h and the machine-dependent param.h that were made on those other architectures year ago. Ian, The patch below should do the trick. Can you please test? If you have any questions about any of the definitions, feel free to e-mail me. Alan P.S. When I get a little more free time, I intend to get in touch with Andre to address the apparent circular dependency. For now just know that unless that circular dependency is combined with a lack of kmem map auto-sizing, like arm, it's basically harmless. I'm working myself through it and will post a patch shortly that untangles a lot of the obscure VM initialization stuff and moves it into the modern SYSINIT world. -- Andre Index: arm/include/vmparam.h === --- arm/include/vmparam.h (revision 246082) +++ arm/include/vmparam.h (working copy) @@ -134,13 +134,16 @@ #endif #define VM_MAX_KERNEL_ADDRESS 0x + /* * Virtual size (bytes) for various kernel submaps. */ - #ifndef VM_KMEM_SIZE -#define VM_KMEM_SIZE(12*1024*1024) +#define VM_KMEM_SIZE (12*1024*1024) #endif +#ifndef VM_KMEM_SIZE_SCALE +#define VM_KMEM_SIZE_SCALE (2) +#endif #define MAXTSIZ(16*1024*1024) #ifndef DFLDSIZ ___ 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:
On Thu, 31 Jan 2013, Olivier Smedts wrote: 2013/1/30 AN a...@neu.net: With all due respect to developers, are these changes tested at all before they are added to the codebase? Won't sound respectful if the problem is not related to that commit. Which compiler are you using for the base system, and for ports ? (more specifically for the virtualbox ports) I had the same kind of errors when compiling virtualbox with gcc46, not the one in base. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Hi Olivier: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix # c++ -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix I also have installed as ports: # pkg info |grep gcc gcc-4.7.3.20130119 GNU Compiler Collection 4.7 gcc-4.6.4.20130125 GNU Compiler Collection 4.6 gcc-aux-20120614_1 Version of GCC 4.7 with full Ada support gccmakedep-1.0.2 Create dependencies in makefiles using 'gcc -M' Here is: # cat /etc/make.conf # added by use.perl 2012-12-05 00:36:53 PERL_VERSION=5.16.2 #.include /usr/local/etc/port_sites.conf QT4_OPTIONS= QGTKSTYLE MALLOC_PRODUCTION=yes OVERRIDE_LINUX_BASE_PORT=f10 I do not have anything in src.conf I rebuilt Vbox with both gcc-4.6.4.20130125 and gcc-4.7.3.20130119, and I get the same failure which is: # VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found If I build Vbox with gcc4.2.1 it fails with: 6 warnings and 2 errors generated. kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC/src-client/ConsoleImpl2.o] Error 1 The failing command: @c++ -c -O2 -fPIC -g -pipe -pedantic -Wshadow -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long -Wno-long-long -Wno-delete-non-virtual-dtor -Wno-variadic-macros -Wno-long-long -Wno-non-virtual-dtor -Wshadow -fshort-wchar -fpermissive -fexceptions -frtti -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility-inlines-hidden -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -m64 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Main/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/Main/ -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/string -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/nsprpub -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/ipcd -I/usr/local/include/libpng -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ -DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ -DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ -DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DPIC -DIN_RING3 -DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DIN_RING3 -DVBOX_WITH_SYS_V_IPC_SESSION_WATCHER -DVBOX_WITH_RAW_MODE -DVBOX_WITH_NETFLT -DVBOX_WITH_CROGL -DVBOX_WITH_GUEST_PROPS -DVBOX_WITH_GUEST_CONTROL -DVBOX_WITH_USB_CARDREADER -DVBOX_WITH_HOSTNETIF_API -DVBOX_WITH_NEW_SYS_V_KEYGEN -DVBOX_COM_INPROC -DVBOX_WITH_VRDP_VIDEO_CHANNEL -DVBOX_WITH_HGCM -DVBOX_WITH_ALSA -DVBOX_WITH_E1000 -DVBOX_WITH_VIRTIO
Panic when closing lid on CURRENT with netbook
I updated my Asus EEEPC netbook from sources earlier on this month to yesterday's sources, and whenever I shut the lid it now panics with use after free (0xcacacaca) in AcpiEvNotifyDispatch. I understand that ACPICA was updated recently, so my guess is that this is the root cause (was the fix for this r246042?). I was wondering if this is a known issue. Have coredumps if needed. Thanks, -Garrett ___ 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: Trouble with recent auto-tuning changes
On Thu, 2013-01-31 at 18:13 +0100, Andre Oppermann wrote: On 28.01.2013 20:20, Alan Cox wrote: On 01/28/2013 08:22, Ian Lepore wrote: On Mon, 2013-01-28 at 00:09 -0600, Alan Cox wrote: On Sun, Jan 27, 2013 at 12:11 PM, Ian Lepore i...@freebsd.org wrote: I ran into a panic while attempting to un-tar a large file on a DreamPlug (arm-based system) running -current. The source and dest of the un-tar is the root filesystem on sdcard, and I get this: panic: kmem_malloc(4096): kmem_map too small: 12582912 total allocated Just before the panic I see the tar process get hung in a nokva wait. 12582912 is the value of VM_KMEM_SIZE from arm/include/vmparam.h. In r245575 the init order for mbuf limits was changed from SI_SUB_TUNABLES to SI_SUB_KMEM so that mbuf limits could be based on the results of sizing kernel memory. Unfortunately, the process of sizing kernel memory relies on the mbuf limits; in kmeminit(): vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; Since r245575, nmbclusters is zero when this line of code runs. If I manually plugin 32768 (the number tunable_mbinit() comes up with for this platform) in that line, the panic stops happening. So we've got two problems here... one is the circular dependency in calculating the mbuf limits. The other is the fact that some non-trivial amount of kernel memory we're allowing for mbufs is actually being used for other things. That is, if my system was actually using all the mbufs that tunable_mbinit() allowed for, then this panic while untarring a huge file would still have happened. All of this is factually correct. However, it's a red herring. The real problem is that arm, unlike every other architecture in the tree, does not enable auto-sizing of the kmem map based on the physical memory size. Specifically, you'll find VM_KMEM_SIZE_SCALE defined in arch/include/vmparam.h on every other architecture, just not on arm. This auto-sizing overrides the value of VM_KMEM_SIZE. Aha. I'll investigate what other architectures do with that and try to get the same thing going for arm. i386 or (32-bit) MIPS would be the most similar. Also, I would encourage you to look for other definitions that those architectures have that arm doesn't. As physical memory sizes continue to grow on arm-based systems, they may require other changes in vmparam.h and the machine-dependent param.h that were made on those other architectures year ago. Ian, The patch below should do the trick. Can you please test? Yep, that fixed the problem with untarring the large file. Here are some before/after numbers from sysctl, converted from bytes to KBytes for readability: vm.kmem_size_scale: 0 2 vm.kmem_map_free: 5740246440 vm.kmem_map_size: 6548 7176 vm.kmem_size: 12288253616 real memory = 536870912 (512 MB) avail memory = 516718592 (492 MB) -- Ian ___ 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
PATCH: display MSI-X table and pba offsets from pciconf -c
Hi,
The following patch teaches pciconf(8) to display the table and pba
offsets when it displays the MSI-X capability.
The new output format will look like:
cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
OR
cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
0x14[0x1000] enabled
Any objections to committing the patch?
best
Neel
Index: usr.sbin/pciconf/cap.c
===
--- cap.c (revision 246087)
+++ cap.c (working copy)
@@ -449,22 +449,30 @@
static void
cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
{
- uint32_t val;
+ uint32_t val, table_offset, pba_offset;
uint16_t ctrl;
int msgnum, table_bar, pba_bar;
ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ table_offset = val ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
- pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ pba_offset = val ~PCIM_MSIX_BIR_MASK;
+
printf(MSI-X supports %d message%s , msgnum,
(msgnum == 1) ? : s);
- if (table_bar == pba_bar)
- printf(in map 0x%x, table_bar);
- else
- printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
+ if (table_bar == pba_bar) {
+ printf(in map 0x%x[0x%x][0x%x],
+ table_bar, table_offset, pba_offset);
+ } else {
+ printf(in maps 0x%x[0x%x] and 0x%x[0x%x],
+ table_bar, table_offset, pba_bar, pba_offset);
+ }
if (ctrl PCIM_MSIXCTRL_MSIX_ENABLE)
printf( enabled);
}
___
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: PATCH: display MSI-X table and pba offsets from pciconf -c
On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu neeln...@gmail.com wrote:
Hi,
The following patch teaches pciconf(8) to display the table and pba
offsets when it displays the MSI-X capability.
The new output format will look like:
cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
OR
cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
0x14[0x1000] enabled
Any objections to committing the patch?
Functionally I think this is a good addition. More information from
pciconf the better.
Other comments below.
best
Neel
Index: usr.sbin/pciconf/cap.c
===
--- cap.c (revision 246087)
+++ cap.c (working copy)
@@ -449,22 +449,30 @@
static void
cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
{
- uint32_t val;
+ uint32_t val, table_offset, pba_offset;
Variables should be in alphabetical order.
uint16_t ctrl;
int msgnum, table_bar, pba_bar;
ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
Newline added intentionally?
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ table_offset = val ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
- pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
Looks like these two lines only have whitespace difference.
+ pba_offset = val ~PCIM_MSIX_BIR_MASK;
+
printf(MSI-X supports %d message%s , msgnum,
(msgnum == 1) ? : s);
- if (table_bar == pba_bar)
- printf(in map 0x%x, table_bar);
- else
- printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
+ if (table_bar == pba_bar) {
+ printf(in map 0x%x[0x%x][0x%x],
+ table_bar, table_offset, pba_offset);
+ } else {
+ printf(in maps 0x%x[0x%x] and 0x%x[0x%x],
+ table_bar, table_offset, pba_bar, pba_offset);
+ }
Seems like at least for the case where the table and pba are behind
different BARs, this will exceed 80 characters. So maybe the maps always
go on a new line? Similar to what's done at the end of cap_express for
printing the link speed.
if (ctrl PCIM_MSIXCTRL_MSIX_ENABLE)
printf( enabled);
}
___
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:
2013/1/31 AN a...@neu.net: On Thu, 31 Jan 2013, Olivier Smedts wrote: 2013/1/30 AN a...@neu.net: With all due respect to developers, are these changes tested at all before they are added to the codebase? Won't sound respectful if the problem is not related to that commit. Which compiler are you using for the base system, and for ports ? (more specifically for the virtualbox ports) I had the same kind of errors when compiling virtualbox with gcc46, not the one in base. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Hi Olivier: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix The answers are in your reply : # c++ -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix So c++ is clang, not base gcc. I also have installed as ports: # pkg info |grep gcc gcc-4.7.3.20130119 GNU Compiler Collection 4.7 gcc-4.6.4.20130125 GNU Compiler Collection 4.6 gcc-aux-20120614_1 Version of GCC 4.7 with full Ada support gccmakedep-1.0.2 Create dependencies in makefiles using 'gcc -M' Here is: # cat /etc/make.conf # added by use.perl 2012-12-05 00:36:53 PERL_VERSION=5.16.2 #.include /usr/local/etc/port_sites.conf QT4_OPTIONS= QGTKSTYLE MALLOC_PRODUCTION=yes OVERRIDE_LINUX_BASE_PORT=f10 I do not have anything in src.conf I rebuilt Vbox with both gcc-4.6.4.20130125 and gcc-4.7.3.20130119, and I get the same failure which is: # VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found If I build Vbox with gcc4.2.1 it fails with: 6 warnings and 2 errors generated. kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC/src-client/ConsoleImpl2.o] Error 1 The failing command: @c++ -c -O2 -fPIC -g -pipe -pedantic -Wshadow -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long -Wno-long-long -Wno-delete-non-virtual-dtor -Wno-variadic-macros -Wno-long-long -Wno-non-virtual-dtor -Wshadow -fshort-wchar -fpermissive -fexceptions -frtti -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility-inlines-hidden -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -m64 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Main/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/Main/ -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/string -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/nsprpub -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/ipcd -I/usr/local/include/libpng -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ -DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ -DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ -DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DPIC -DIN_RING3 -DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DIN_RING3 -DVBOX_WITH_SYS_V_IPC_SESSION_WATCHER -DVBOX_WITH_RAW_MODE -DVBOX_WITH_NETFLT -DVBOX_WITH_CROGL -DVBOX_WITH_GUEST_PROPS -DVBOX_WITH_GUEST_CONTROL -DVBOX_WITH_USB_CARDREADER -DVBOX_WITH_HOSTNETIF_API
Re:
On Fri, 1 Feb 2013, Olivier Smedts wrote: 2013/1/31 AN a...@neu.net: On Thu, 31 Jan 2013, Olivier Smedts wrote: 2013/1/30 AN a...@neu.net: With all due respect to developers, are these changes tested at all before they are added to the codebase? Won't sound respectful if the problem is not related to that commit. Which compiler are you using for the base system, and for ports ? (more specifically for the virtualbox ports) I had the same kind of errors when compiling virtualbox with gcc46, not the one in base. -- Olivier Smedts _ ASCII ribbon campaign ( ) e-mail: oliv...@gid0.org- against HTML email vCards X www: http://www.gid0.org- against proprietary attachments / \ Il y a seulement 10 sortes de gens dans le monde : ceux qui comprennent le binaire, et ceux qui ne le comprennent pas. Hi Olivier: FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #33 r246130: Wed Jan 30 15:00:08 EST 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 # cc -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix The answers are in your reply : # c++ -v FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 Target: x86_64-unknown-freebsd10.0 Thread model: posix So c++ is clang, not base gcc. I also have installed as ports: # pkg info |grep gcc gcc-4.7.3.20130119 GNU Compiler Collection 4.7 gcc-4.6.4.20130125 GNU Compiler Collection 4.6 gcc-aux-20120614_1 Version of GCC 4.7 with full Ada support gccmakedep-1.0.2 Create dependencies in makefiles using 'gcc -M' Here is: # cat /etc/make.conf # added by use.perl 2012-12-05 00:36:53 PERL_VERSION=5.16.2 #.include /usr/local/etc/port_sites.conf QT4_OPTIONS= QGTKSTYLE MALLOC_PRODUCTION=yes OVERRIDE_LINUX_BASE_PORT=f10 I do not have anything in src.conf I rebuilt Vbox with both gcc-4.6.4.20130125 and gcc-4.7.3.20130119, and I get the same failure which is: # VirtualBox VirtualBox: Error -610 in supR3HardenedMainInitRuntime! VirtualBox: dlopen(/usr/local/lib/virtualbox/VBoxRT.so,) failed: /usr/lib/libstdc++.so.6: version GLIBCXX_3.4.15 required by /usr/local/lib/virtualbox/VBoxRT.so not found If I build Vbox with gcc4.2.1 it fails with: 6 warnings and 2 errors generated. kmk: *** [/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC/src-client/ConsoleImpl2.o] Error 1 The failing command: @c++ -c -O2 -fPIC -g -pipe -pedantic -Wshadow -Wshadow -Wall -Wextra -Wno-missing-field-initializers -Wno-unused -Wno-trigraphs -fdiagnostics-show-option -Wno-long-long -Wno-long-long -Wno-delete-non-virtual-dtor -Wno-variadic-macros -Wno-long-long -Wno-non-virtual-dtor -Wshadow -fshort-wchar -fpermissive -fexceptions -frtti -O2 -mtune=generic -fno-omit-frame-pointer -fno-strict-aliasing -fvisibility-inlines-hidden -fvisibility=hidden -DVBOX_HAVE_VISIBILITY_HIDDEN -DRT_USE_VISIBILITY_DEFAULT -m64 -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/src/VBox/Main/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/VBoxC -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/obj/Main/ -I/usr/include -I/usr/X11R6/include -I/usr/local/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/string -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/xpcom -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/nsprpub -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release/bin/sdk/bindings/xpcom/include/ipcd -I/usr/local/include/libpng -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/include -I/usr/ports/emulators/virtualbox-ose/work/VirtualBox-4.2.6/out/freebsd.amd64/release -DVBOX -DVBOX_WITH_DEBUGGER -DVBOX_OSE -DVBOX_WITH_64_BITS_GUESTS -DVBOX_WITH_HARDENING -DRT_OS_FREEBSD -D__FREEBSD__ -DRT_ARCH_AMD64 -D__AMD64__ -DRTPATH_APP_PRIVATE=\/usr/local/share/virtualbox-ose\ -DRTPATH_APP_PRIVATE_ARCH=\/usr/local/lib/virtualbox\ -DRTPATH_SHARED_LIBS=\/usr/local/lib/virtualbox\ -DRTPATH_APP_DOCS=\/usr/local/share/doc/virtualbox-ose\ -DPIC -DIN_RING3 -DUNICODE -DNDEBUG=1 -DVBOX_WITH_XPCOM -DIN_RING3 -DVBOX_WITH_SYS_V_IPC_SESSION_WATCHER -DVBOX_WITH_RAW_MODE -DVBOX_WITH_NETFLT -DVBOX_WITH_CROGL -DVBOX_WITH_GUEST_PROPS -DVBOX_WITH_GUEST_CONTROL -DVBOX_WITH_USB_CARDREADER -DVBOX_WITH_HOSTNETIF_API -DVBOX_WITH_NEW_SYS_V_KEYGEN -DVBOX_COM_INPROC
Re: PATCH: display MSI-X table and pba offsets from pciconf -c
Hi Jim,
On Thu, Jan 31, 2013 at 3:13 PM, Jim Harris jim.har...@gmail.com wrote:
On Thu, Jan 31, 2013 at 3:52 PM, Neel Natu neeln...@gmail.com wrote:
Hi,
The following patch teaches pciconf(8) to display the table and pba
offsets when it displays the MSI-X capability.
The new output format will look like:
cap 11[70] = MSI-X supports 10 messages in map 0x1c[0x0][0x2000] enabled
OR
cap 11[70] = MSI-X supports 10 messages in maps 0x10[0x0] and
0x14[0x1000] enabled
Any objections to committing the patch?
Functionally I think this is a good addition. More information from pciconf
the better.
Other comments below.
best
Neel
Index: usr.sbin/pciconf/cap.c
===
--- cap.c (revision 246087)
+++ cap.c (working copy)
@@ -449,22 +449,30 @@
static void
cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
{
- uint32_t val;
+ uint32_t val, table_offset, pba_offset;
Variables should be in alphabetical order.
Ok.
uint16_t ctrl;
int msgnum, table_bar, pba_bar;
ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
Newline added intentionally?
Yes.
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ table_offset = val ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
- pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
Looks like these two lines only have whitespace difference.
Yes, there was trailing whitespace there previously.
+ pba_offset = val ~PCIM_MSIX_BIR_MASK;
+
printf(MSI-X supports %d message%s , msgnum,
(msgnum == 1) ? : s);
- if (table_bar == pba_bar)
- printf(in map 0x%x, table_bar);
- else
- printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
+ if (table_bar == pba_bar) {
+ printf(in map 0x%x[0x%x][0x%x],
+ table_bar, table_offset, pba_offset);
+ } else {
+ printf(in maps 0x%x[0x%x] and 0x%x[0x%x],
+ table_bar, table_offset, pba_bar, pba_offset);
+ }
Seems like at least for the case where the table and pba are behind
different BARs, this will exceed 80 characters. So maybe the maps always go
on a new line? Similar to what's done at the end of cap_express for
printing the link speed.
Ok, the new format will look like:
cap 11[70] = MSI-X supports 10 messages, enabled
Table in map 0x1c[0x0], PBA in map 0x1c[0x2000]
Updated patch at the end of the email.
best
Neel
if (ctrl PCIM_MSIXCTRL_MSIX_ENABLE)
printf( enabled);
}
Index: usr.sbin/pciconf/cap.c
===
--- usr.sbin/pciconf/cap.c (revision 246087)
+++ usr.sbin/pciconf/cap.c (working copy)
@@ -449,24 +449,28 @@
static void
cap_msix(int fd, struct pci_conf *p, uint8_t ptr)
{
- uint32_t val;
+ uint32_t pba_offset, table_offset, val;
+ int msgnum, pba_bar, table_bar;
uint16_t ctrl;
- int msgnum, table_bar, pba_bar;
ctrl = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_CTRL, 2);
msgnum = (ctrl PCIM_MSIXCTRL_TABLE_SIZE) + 1;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_TABLE, 4);
table_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ table_offset = val ~PCIM_MSIX_BIR_MASK;
+
val = read_config(fd, p-pc_sel, ptr + PCIR_MSIX_PBA, 4);
- pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
- printf(MSI-X supports %d message%s , msgnum,
- (msgnum == 1) ? : s);
- if (table_bar == pba_bar)
- printf(in map 0x%x, table_bar);
- else
- printf(in maps 0x%x and 0x%x, table_bar, pba_bar);
- if (ctrl PCIM_MSIXCTRL_MSIX_ENABLE)
- printf( enabled);
+ pba_bar = PCIR_BAR(val PCIM_MSIX_BIR_MASK);
+ pba_offset = val ~PCIM_MSIX_BIR_MASK;
+
+ printf(MSI-X supports %d message%s%s\n, msgnum,
+ (msgnum == 1) ? : s,
+ (ctrl PCIM_MSIXCTRL_MSIX_ENABLE) ? , enabled : );
+
+ printf( );
+ printf(Table in map 0x%x[0x%x], PBA in map 0x%x[0x%x],
+ table_bar, table_offset, pba_bar, pba_offset);
}
static void
___
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: x220 notes
On Thu, Jan 31, 2013 at 8:56 AM, Thomas Mueller mueller6...@bellsouth.net wrote: Excerpt from Andrey Fesenko f0and...@gmail.com: And other problems. 1) wi-fi standart rtl8192cu - not work change AR5B95 - work n-mode (thanks Adrian Chadd :) need hack BIOS dev.acpi_ibm.0.wlan: 1 - read only hardware switch work, not send mesage What did you try to make rtl8192cu work? Did you try NDIS? I have Hiro USB wireless adapter with rtl8191s chip, am still trying, on and off, to get it to work. OpenBSD has urtwn driver that should work, ported to NetBSD, but why not FreeBSD? ALso, there is a Linux driver. Tom NDIS failed to raise working version. Win driver terrible ~5 firmware and other. urtwn such as usb devices and no porting FreeBSD only dirty hack http://lists.freebsd.org/pipermail/freebsd-wireless/2012-November/002539.html just wanted to get wi-fi n-mode :) actively developed now like only ath. ___ 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
hwpmc support for haswell
Hi, I've prepared a patch to add core and uncore events support for haswell processor. I do not have the hardware to test this. It applies cleanly and compiles fine though. http://www.strugglingcoder.info/patches/hwpmc_hw.txt This is initial version of patch and manpage is still missing. I will add it in a few days. Any help in testing is appreciated. Thanks, Hiren ___ 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: hwpmc support for haswell
On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara hiren.panchas...@gmail.com wrote: Hi, I've prepared a patch to add core and uncore events support for haswell processor. I do not have the hardware to test this. It applies cleanly and compiles fine though. http://www.strugglingcoder.info/patches/hwpmc_hw.txt This is initial version of patch and manpage is still missing. I will add it in a few days. Any help in testing is appreciated. Thanks, Hiren It seems Intel won't release this before June (at least to my knowledge). I would claim it'll be difficult to real test this before that date unless someone has prerelease hardware. Thanks Davide ___ 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: hwpmc support for haswell
On Thu, Jan 31, 2013 at 5:47 PM, Davide Italiano dav...@freebsd.org wrote: On Fri, Feb 1, 2013 at 2:17 AM, hiren panchasara hiren.panchas...@gmail.com wrote: Hi, I've prepared a patch to add core and uncore events support for haswell processor. I do not have the hardware to test this. It applies cleanly and compiles fine though. http://www.strugglingcoder.info/patches/hwpmc_hw.txt This is initial version of patch and manpage is still missing. I will add it in a few days. Any help in testing is appreciated. Thanks, Hiren It seems Intel won't release this before June (at least to my knowledge). I would claim it'll be difficult to real test this before that date unless someone has prerelease hardware. Indeed. I've posted it here just to let larger audience know and avoid possible duplicate work. We will wait till we get the hardware to test with. Thanks, Hiren Thanks Davide ___ 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
