Re: issue with libthr?
On 2/06/2013 3:33 PM, Waitman Gobble wrote: On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak koobs.free...@gmail.com wrote: On 2/06/2013 2:32 PM, Kubilay Kocak wrote: I wonder if Pythons regression test picks anything up: ./python -m test.regrtest Run that in $WRKSRC/portbld.static/ after building Infact, run this instead: ./python -bb -E -Wd -m test.regrtest -r -w -uall [1] http://docs.python.org/devguide/runtests.html Hi, Thanks for your reply, I appreciate it. Here are some errors.. [1053] ./python -bb -E -Wd -m test.regrtest -r -w -uall == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (trunk 178860)] == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, unicode=0, bytes_warning=2, hash_randomization=0) Using random seed 1989961 test_global ... test_rfc822 test_file test_decimal Abort (core dumped) test_dis test_memoryio test_importhooks test_netrc test_univnewlines2k test_codecencodings_tw test_property test_zipimport_support jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_distutils jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_threading test test_threading failed -- Traceback (most recent call last): File /usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py, line 307, in test_finalize_runnning_thread self.assertEqual(rc, 42) AssertionError: -10 != 42 -- Waitman Gobble San Jose California USA +1.5108307875 That last failure in test_threading I can reproduce on 10.0-CURRENT but I don't think its related. Those coredumps on the other hand. Incidentally, what OPTIONS did you build Python with? I ask cause WITH_PYMALLOC is the port and upstream default -- Ta, koobs ___ 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: Undesirable bmake behavior
today I got confronted with this little curiosity from bmake. I have
built and installed the world, and after reboot I ran 'make delete-old'
as root to get rid of accumulated stale files. This is what I got back:
Removing old files (only deletes safe to delete libs)
Old files removed
Removing old directories
Old directories removed
To remove old libraries run '/usr/obj/usr/src/make.amd64/make
delete-old-libs'.
It turns out that somehow running make in src tree finds and tries to
run a copy from .OBJDIR, if one is present, unconditionally now. I do
This simply what src/Makefile says to do, and AFAIK it has been that way
for ages.
Since delete-old is in TGTS it gets run via:
#
# Handle the user-driven targets, using the source relative mk files.
#
${TGTS}:
${_+_}@cd ${.CURDIR}; ${_MAKE} ${.TARGET}
and
$ make -dV -V _MAKE
PATH=${PATH} ${BINMAKE} -f Makefile.inc1 TARGET=${_TARGET}
TARGET_ARCH=${_TARGET_ARCH}
$ make -dV -V BINMAKE
`if [ -x ${MAKEPATH}/make ]; then echo ${MAKEPATH}/make; else echo
${MAKE}; fi` -m ${.CURDIR}/share/mk
$ make -V _MAKE
PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x
/var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make ]; then
echo /var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make;
else echo make; fi` -m /b/sjg/work/FreeBSD/current/src/share/mk -f
Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64
$
Now you may be right that that's a bad idea, but it isn't anything new.
--sjg
___
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: Supermicro 6027R-N3RF+head, usb trouble
On 6/1/2013 12:00 PM, Konstantin Belousov wrote: On Thu, May 30, 2013 at 07:15:39AM -0500, Bryan Drewery wrote: On 5/30/2013 12:07 AM, Konstantin Belousov wrote: On Wed, May 29, 2013 at 07:45:39AM -0500, Bryan Drewery wrote: On 5/29/2013 7:16 AM, Bryan Drewery wrote: On 5/29/2013 12:33 AM, Sergey V. Dyatko wrote: On Tue, 28 May 2013 13:20:53 -0500 Bryan Drewery bdrew...@freebsd.org wrote: On 4/21/2013 2:38 PM, Sergey V. Dyatko wrote: Hi, Can anybody explain why USB keyboard (and keyboard from integrated IPKVM) doesn't work when I boot with 'C606 chipset Dual 4-Port SATA/SAS Storage Control Unit' enabled in bios? Also I can't boot that box from usb memstick and FreeBSD-10.0-CURRENT-amd64-20130413-r249439-release.iso They both loose(?) device and can't find root If I disable controller in bios system can't see any sata hdd connected to it:( booting with hw.usb.ehci.no_hs=1, kern.cam.boot_delay=1 and debug.acpi.disabled=hostres without success. I setup dhcpd, tftp, nfs on my laptop and finally I install fbsd on that box, but question with kbd is open - It doesn't work.. dmesg: http://svn.freebsd.by/files/dmesg_N3RF.txt pciconf -lv: http://svn.freebsd.by/files/pciconf_N3RF.txt I would appreciate any hints I'm having this exact problem on HEAD r250991 as well. 9.1-RELEASE (disc1) seems ok though. Did you get this figured out? I added to loader.conf kern.maxbcache=128M ^ This setting is all that was needed. The VFS change was not needed. vfs.maxbufspace=134217728 also I create /boot.config with '-v' I don't know what exactly help, but now usb kbd (ipkvm) works fine for me. p.s. It is smbios.system.product=X9DRW Yes! This fix of limiting the size worked for me. USB worked on boot, kb works remotely in the IP KVM and locally as well now. For the record, this is a DELL C1100 with 72GB of ram. The symptoms match the previous posts though and the delay settings did not help. This was working on 9.1-R, something must have changed on HEAD. This is not a production system, I'm willing to try any patches or settings to help get this fixed by default. Could you get the values of sysctl kern.nbuf, kern.bio_transient_maxcnt from the boot without any tuning of the KVA usage ? # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache kern.nbuf: 472300 kern.bio_transient_maxcnt: 1024 kern.maxbcache: 0 For reference, with limiting maxbcache: # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache kern.nbuf: 7372 kern.bio_transient_maxcnt: 102 kern.maxbcache: 134217728 You did not tuned BKVASIZE nor MAXPHYS ? No. This is somewhat unexpected, but indeed reasonable. The buffer cache dutifully tried to allocate 1/10 of the RAM size for the buffer KVA. Please try the following tweak. With patch, and leaving kern.maxbcache to default, USB works as expected. Result with patch: # sysctl kern.nbuf kern.bio_transient_maxcnt kern.maxbcache kern.nbuf: 105931 kern.bio_transient_maxcnt: 1024 kern.maxbcache: 0 # cat /boot/loader.conf zfs_load=YES vfs.root.mountfrom=zfs:zroot/ROOT/head-r251224 USB on boot: uhub0: 2 ports with 2 removable, self powered uhub2: 2 ports with 2 removable, self powered uhub1: 2 ports with 2 removable, self powered uhub3: 2 ports with 2 removable, self powered uhub5: 2 ports with 2 removable, self powered uhub6: 2 ports with 2 removable, self powered Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 Root mount waiting for: usbus7 usbus3 uhub4: 6 ports with 6 removable, self powered uhub7: 6 ports with 6 removable, self powered ugen3.2: Avocent at usbus3 ukbd0: Keyboard on usbus3 kbd2 at ukbd0 Trying to mount root from zfs:zroot/ROOT/head-r251224 []... ums0: Mouse on usbus3 ums0: 3 buttons and [Z] coordinates ID=0 ums1: Mouse REL on usbus3 ums1: 3 buttons and [XYZ] coordinates ID=0 diff --git a/sys/kern/vfs_bio.c b/sys/kern/vfs_bio.c index 7bd8d7e..2f92cde 100644 --- a/sys/kern/vfs_bio.c +++ b/sys/kern/vfs_bio.c @@ -560,7 +560,8 @@ kern_vfs_bio_buffer_alloc(caddr_t v, long physmem_est) nbuf += min((physmem_est - 4096) / factor, 65536 / factor); if (physmem_est 65536) - nbuf += (physmem_est - 65536) * 2 / (factor * 5); + nbuf += min((physmem_est - 65536) * 2 / (factor * 5), + 32 * 1024 * 1024 / (factor * 5)); if (maxbcache nbuf maxbcache / BKVASIZE) nbuf = maxbcache / BKVASIZE; -- Regards, Bryan Drewery signature.asc Description: OpenPGP digital signature
Re: issue with libthr?
On Sun, 02 Jun 2013 16:43:51 +1000, Kubilay Kocak koobs.free...@gmail.com wrote: On 2/06/2013 3:33 PM, Waitman Gobble wrote: On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak koobs.free...@gmail.com wrote: On 2/06/2013 2:32 PM, Kubilay Kocak wrote: I wonder if Pythons regression test picks anything up: ./python -m test.regrtest Run that in $WRKSRC/portbld.static/ after building Infact, run this instead: ./python -bb -E -Wd -m test.regrtest -r -w -uall [1] http://docs.python.org/devguide/runtests.html Hi, Thanks for your reply, I appreciate it. Here are some errors.. [1053] ./python -bb -E -Wd -m test.regrtest -r -w -uall == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (trunk 178860)] == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, unicode=0, bytes_warning=2, hash_randomization=0) Using random seed 1989961 test_global ... test_rfc822 test_file test_decimal Abort (core dumped) test_dis test_memoryio test_importhooks test_netrc test_univnewlines2k test_codecencodings_tw test_property test_zipimport_support jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_distutils jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_threading test test_threading failed -- Traceback (most recent call last): File /usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py, line 307, in test_finalize_runnning_thread self.assertEqual(rc, 42) AssertionError: -10 != 42 -- Waitman Gobble San Jose California USA +1.5108307875 That last failure in test_threading I can reproduce on 10.0-CURRENT but I don't think its related. Those coredumps on the other hand. Incidentally, what OPTIONS did you build Python with? I ask cause WITH_PYMALLOC is the port and upstream default -- Ta, koobs Hi, The latest build has EXAMPLES, IPV6, NLS, THREADS, UCS4. I originally had the defaults, was trying different options to see if I could avoid the crash. I'll reset PYMALLOC in that case. I did try one build using PTH, it seems to cause problems with the #include pth.h in Python.h, I think I have to change that to #include pth/pth.h or something, but I read somewhere on the FreeBSD forum that one should not use that option with Python anyhow. (?) Thanks -- Waitman Gobble San Jose California USA +1.5108307875 ___ 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: issue with libthr?
On Sun, 02 Jun 2013 16:43:51 +1000, Kubilay Kocak koobs.free...@gmail.com wrote: On 2/06/2013 3:33 PM, Waitman Gobble wrote: On Sun, 02 Jun 2013 14:45:31 +1000, Kubilay Kocak koobs.free...@gmail.com wrote: On 2/06/2013 2:32 PM, Kubilay Kocak wrote: I wonder if Pythons regression test picks anything up: ./python -m test.regrtest Run that in $WRKSRC/portbld.static/ after building Infact, run this instead: ./python -bb -E -Wd -m test.regrtest -r -w -uall [1] http://docs.python.org/devguide/runtests.html Hi, Thanks for your reply, I appreciate it. Here are some errors.. [1053] ./python -bb -E -Wd -m test.regrtest -r -w -uall == CPython 2.7.5 (default, Jun 1 2013, 22:09:55) [GCC 4.2.1 Compatible FreeBSD Clang 3.3 (trunk 178860)] == FreeBSD-10.0-CURRENT-amd64-64bit-ELF little-endian == /usr/ports/lang/python27/work/Python-2.7.5/build/test_python_98332 Testing with flags: sys.flags(debug=0, py3k_warning=0, division_warning=0, division_new=0, inspect=0, interactive=0, optimize=0, dont_write_bytecode=0, no_user_site=0, no_site=0, ignore_environment=1, tabcheck=0, verbose=0, unicode=0, bytes_warning=2, hash_randomization=0) Using random seed 1989961 test_global ... test_rfc822 test_file test_decimal Abort (core dumped) test_dis test_memoryio test_importhooks test_netrc test_univnewlines2k test_codecencodings_tw test_property test_zipimport_support jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_distutils jemalloc: /usr/src/lib/libc/../../contrib/jemalloc/include/jemalloc/internal/arena.h:942: Failed assertion: arena_mapbits_allocated_get(chunk, pageind) != 0 Abort (core dumped) test_threading test test_threading failed -- Traceback (most recent call last): File /usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py, line 307, in test_finalize_runnning_thread self.assertEqual(rc, 42) AssertionError: -10 != 42 -- Waitman Gobble San Jose California USA +1.5108307875 That last failure in test_threading I can reproduce on 10.0-CURRENT but I don't think its related. Those coredumps on the other hand. Incidentally, what OPTIONS did you build Python with? I ask cause WITH_PYMALLOC is the port and upstream default -- Ta, koobs OK... you are correct, WITH_PYMALLOC was the deal with the jemalloc related errors, but I still get this : test_threading test test_threading failed -- Traceback (most recent call last): File /usr/ports/lang/python27/work/Python-2.7.5/Lib/test/test_threading.py, line 307, in test_finalize_runnning_thread self.assertEqual(rc, 42) AssertionError: -6 != 42 Re-running test 'test_threading' in verbose mode test_acquire_contended (test.test_threading.LockTests) ... ok test_acquire_destroy (test.test_threading.LockTests) ... ok test_acquire_release (test.test_threading.LockTests) ... ok test_constructor (test.test_threading.LockTests) ... ok test_different_thread (test.test_threading.LockTests) ... ok test_reacquire (test.test_threading.LockTests) ... ok test_thread_leak (test.test_threading.LockTests) ... ok test_try_acquire (test.test_threading.LockTests) ... ok test_try_acquire_contended (test.test_threading.LockTests) ... ok test_with (test.test_threading.LockTests) ... ok test__is_owned (test.test_threading.RLockTests) ... ok test_acquire_contended (test.test_threading.RLockTests) ... ok test_acquire_destroy (test.test_threading.RLockTests) ... ok test_acquire_release (test.test_threading.RLockTests) ... ok test_constructor (test.test_threading.RLockTests) ... ok test_different_thread (test.test_threading.RLockTests) ... ok test_reacquire (test.test_threading.RLockTests) ... ok test_release_unacquired (test.test_threading.RLockTests) ... ok test_thread_leak (test.test_threading.RLockTests) ... ok test_try_acquire (test.test_threading.RLockTests) ... ok test_try_acquire_contended (test.test_threading.RLockTests) ... ok test_with (test.test_threading.RLockTests) ... ok test_is_set (test.test_threading.EventTests) ... ok test_notify (test.test_threading.EventTests) ... ok test_timeout (test.test_threading.EventTests) ... ok test__is_owned (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_contended (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_destroy (test.test_threading.ConditionAsRLockTests) ... ok test_acquire_release (test.test_threading.ConditionAsRLockTests) ... ok test_constructor (test.test_threading.ConditionAsRLockTests) ... ok test_different_thread (test.test_threading.ConditionAsRLockTests) ... ok test_reacquire (test.test_threading.ConditionAsRLockTests) ... ok test_release_unacquired (test.test_threading.ConditionAsRLockTests) ... ok test_thread_leak (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire (test.test_threading.ConditionAsRLockTests) ... ok test_try_acquire_contended
Re: issue with libthr?
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote: Hi, I'm getting a ton of core dumps from Python and any software that uses Python, ie has USE_PYTHON_BUILD=yes in Makefile. hundreds of msgs in dmesg: pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped) pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped) from gdb it seems to me to be libthr related? I've noticed a couple updates in May.. wonder if it's related? I've only noticed this issue in the past week, after a complete rebuild and updated. I've been running into this issue too - python 2.7 would crash when trying to rebuild databases/tdb and databases/py-sqlite3 with backtraces similar to what you have below. The python port itself hasn't changed in a while. Reverting r250991 and rebuilding libc solves the issue for me: http://svnweb.freebsd.org/base?view=revisionrevision=250991 uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r25: Wed May 29 16:44:31 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 gdb: seamonkey (gdb) bt #0 0x0008011ee8ca in thr_kill () from /lib/libc.so.7 #1 0x00080316b585 in XRE_InstallX11ErrorHandler () from /usr/local/lib/seamonkey/libxul.so #2 0x000800f73286 in swapcontext () from /lib/libthr.so.3 #3 0x000800f72e89 in sigaction () from /lib/libthr.so.3 #4 0x71d3 in ?? () #5 0x000800f72d70 in sigaction () from /lib/libthr.so.3 Previous frame inner to this frame (corrupt stack?) python (gdb) bt #0 0x00080100d8ca in thr_kill () from /lib/libc.so.7 #1 0x0008010d2e9c in abort () from /lib/libc.so.7 #2 0x000803e4f05b in free () from /usr/local/lib/python2.7/lib-dynload/_ctypes.so #3 0x000800d9319f in pthread_mutex_destroy () from /lib/libthr.so.3 #4 0x0008010269ff in closedir () from /lib/libc.so.7 #5 0x004b545c in initposix () #6 0x0047fb75 in PyEval_EvalFrameEx () #7 0x0047d824 in PyEval_EvalCodeEx () #8 0x00484256 in _PyEval_SliceIndex () #9 0x004810cd in PyEval_EvalFrameEx () #10 0x0047d824 in PyEval_EvalCodeEx () #11 0x004d5f56 in PyFunction_SetClosure () #12 0x0041ffeb in PyObject_Call () #13 0x00482085 in PyEval_EvalFrameEx () #14 0x0047d824 in PyEval_EvalCodeEx () #15 0x00484256 in _PyEval_SliceIndex () #16 0x004810cd in PyEval_EvalFrameEx () #17 0x0047d824 in PyEval_EvalCodeEx () #18 0x00484256 in _PyEval_SliceIndex () #19 0x004810cd in PyEval_EvalFrameEx () #20 0x0047d824 in PyEval_EvalCodeEx () #21 0x00484256 in _PyEval_SliceIndex () #22 0x004810cd in PyEval_EvalFrameEx () #23 0x004841f2 in _PyEval_SliceIndex () #24 0x004810cd in PyEval_EvalFrameEx () #25 0x004841f2 in _PyEval_SliceIndex () #26 0x004810cd in PyEval_EvalFrameEx () #27 0x004841f2 in _PyEval_SliceIndex () #28 0x004810cd in PyEval_EvalFrameEx () #29 0x004841f2 in _PyEval_SliceIndex () #30 0x004810cd in PyEval_EvalFrameEx () #31 0x004841f2 in _PyEval_SliceIndex () #32 0x004810cd in PyEval_EvalFrameEx () #33 0x0047d824 in PyEval_EvalCodeEx () #34 0x0047d156 in PyEval_EvalCode () #35 0x004a1361 in PyRun_FileExFlags () #36 0x004a0eb1 in PyRun_SimpleFileExFlags () #37 0x00417549 in Py_Main () #38 0x0041692f in main () Any help/pointers much appreciated. Thank you, -- Waitman Gobble San Jose California USA +1.5108307875 ___ 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: issue with libthr?
On Sun, 2 Jun 2013 10:43:35 -0400, Mark Johnston ma...@freebsd.org wrote:
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
Hi,
I'm getting a ton of core dumps from Python and any software that uses
Python,
ie has USE_PYTHON_BUILD=yes in Makefile.
hundreds of msgs in dmesg:
pid 36637 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 36986 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 37054 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 51780 (seamonkey), uid 1001: exited on signal 11 (core dumped)
pid 83350 (python2.7), uid 0: exited on signal 6 (core dumped)
from gdb it seems to me to be libthr related? I've noticed a couple updates
in
May.. wonder if it's related? I've only noticed this issue in the past
week,
after a complete rebuild and updated.
I've been running into this issue too - python 2.7 would crash when
trying to rebuild databases/tdb and databases/py-sqlite3 with backtraces
similar to what you have below. The python port itself hasn't changed in
a while.
Reverting r250991 and rebuilding libc solves the issue for me:
http://svnweb.freebsd.org/base?view=revisionrevision=250991
Thanks for the info, I appreciate it. I had a heck of a time getting
database/py-sqlite3 to build as well.
My workaround to get it installed was to change the Makefile in WRKSRC
try:
import ctypes
ctypes.CDLL('libsqlite3.so').sqlite3_load_extension
except AttributeError:
macros.append(('SQLITE_OMIT_LOAD_EXTENSION', '1'))
it was bombing out on the 'except AttributeError:' line.
So I just changed it to
macros.append(('SQLITE_OMIT_LOAD_EXTENSION', '1'))
since I didn't have the extensions option SQLITE, if you have that option then
just delete the whole block, nothing needed.
Of course the 'better' way is to find the source of the issue. :)
--
Waitman Gobble
San Jose California USA
+1.5108307875
___
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 Sat, 2013-06-01 at 20:28 -0400, Rick Macklem wrote:
Lars Eggert wrote:
Hi,
to conclude this thread, the patch below allows one to specify an nfs
rootfs via the ROOTDEVNAME kernel option, which will be mounted when
BOOTP does not return a root-path option.
Lars
My only concern with this (mainly because I don't understand the rules
applied to boot alternatives well enough) is that a few arm configs have
both BOOTP, BOOTP_NFSROOT and ROOTDEVNAME specified, where ROOTDEVNAME
is set to ufs: I don't think this patch will break them, since I
think they'll use NFS and ignore the ROOTDEVNAME, but I'm not completely
sure. Does someone else know how HL201 boots, for example?
Lars, if you have a src commit, you can consider this reviewed by me. If
not, maybe Craig can review it and then I'll commit it.
Thanks for doing this, rick
diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c
index 2c57a91..972fb12 100644
--- a/sys/nfs/bootp_subr.c
+++ b/sys/nfs/bootp_subr.c
@@ -45,6 +45,7 @@ __FBSDID($FreeBSD$);
#include opt_bootp.h
#include opt_nfs.h
+#include opt_rootdevname.h
#include sys/param.h
#include sys/systm.h
@@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext *gctx,
struct thread *td)
rtimo = time_second +
BOOTP_SETTLE_DELAY;
printf( (got root path));
- } else
+ } else {
printf( (no root path));
+#ifdef ROOTDEVNAME
+ /*
+ * If we'll mount rootfs from
+ * ROOTDEVNAME, we can accept
+ * offers without root paths.
+ */
+ gotrootpath = 1;
+ rtimo = time_second +
+ BOOTP_SETTLE_DELAY;
+ printf( (ROOTDEVNAME));
+#endif
+ }
printf(\n);
}
} /* while secs */
@@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless *nd,
struct bootpc_ifcontext *ifctx,
p = bootpc_tag(gctx-tag, ifctx-reply, ifctx-replylen,
TAG_ROOT);
+#ifdef ROOTDEVNAME
+ /*
+ * If there was no root path in BOOTP, use the one in ROOTDEVNAME.
+ */
+ if (p == NULL) {
+ p = strdup(ROOTDEVNAME, M_TEMP);
+ if (strcmp(strsep(p, :), nfs) != 0)
+ panic(ROOTDEVNAME is not an NFS mount point);
+ }
+#endif
if (p != NULL) {
if (gctx-setrootfs != NULL) {
printf(rootfs %s (ignored) , p);
I've seen several requests over the past year for an nfs ROOTDEVNAME
along with BOOTP to work properly from ARM developers (myself included),
so I don't think we should worry about breaking existing config that
happens to be checked in but a) hasn't been tested by anyone for ages,
and b) doesn't work anyway (ROOTDEVNAME just gets ignored).
-- 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
Re: Undesirable bmake behavior
On Sat, 1 Jun 2013 21:40:57 -0700
Simon J. Gerraty s...@juniper.net wrote:
today I got confronted with this little curiosity from bmake. I have
built and installed the world, and after reboot I ran 'make
delete-old' as root to get rid of accumulated stale files. This is
what I got back:
Removing old files (only deletes safe to delete libs)
Old files removed
Removing old directories
Old directories removed
To remove old libraries run '/usr/obj/usr/src/make.amd64/make
delete-old-libs'.
It turns out that somehow running make in src tree finds and tries to
run a copy from .OBJDIR, if one is present, unconditionally now. I do
This simply what src/Makefile says to do, and AFAIK it has been that
way for ages.
Since delete-old is in TGTS it gets run via:
#
# Handle the user-driven targets, using the source relative mk files.
#
${TGTS}:
${_+_}@cd ${.CURDIR}; ${_MAKE} ${.TARGET}
and
$ make -dV -V _MAKE
PATH=${PATH} ${BINMAKE} -f Makefile.inc1 TARGET=${_TARGET}
TARGET_ARCH=${_TARGET_ARCH} $ make -dV -V BINMAKE
`if [ -x ${MAKEPATH}/make ]; then echo ${MAKEPATH}/make; else echo
${MAKE}; fi` -m ${.CURDIR}/share/mk
$ make -V _MAKE
PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x
/var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make ];
then
echo /var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make;
else echo make; fi` -m /b/sjg/work/FreeBSD/current/src/share/mk -f
Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 $
Now you may be right that that's a bad idea, but it isn't anything
new.
--sjg
Indeed, it seems this is an issue that rears it head every time we
resort to building the bootstrap make, which happens not often. bmake
just made me notice the issue, and it wasn't the cause.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: mounting root from NFS via ROOTDEVNAME
Ian Lepore wrote:
On Sat, 2013-06-01 at 20:28 -0400, Rick Macklem wrote:
Lars Eggert wrote:
Hi,
to conclude this thread, the patch below allows one to specify an
nfs
rootfs via the ROOTDEVNAME kernel option, which will be mounted
when
BOOTP does not return a root-path option.
Lars
My only concern with this (mainly because I don't understand the
rules
applied to boot alternatives well enough) is that a few arm configs
have
both BOOTP, BOOTP_NFSROOT and ROOTDEVNAME specified, where
ROOTDEVNAME
is set to ufs: I don't think this patch will break them, since
I
think they'll use NFS and ignore the ROOTDEVNAME, but I'm not
completely
sure. Does someone else know how HL201 boots, for example?
Lars, if you have a src commit, you can consider this reviewed by
me. If
not, maybe Craig can review it and then I'll commit it.
Thanks for doing this, rick
diff --git a/sys/nfs/bootp_subr.c b/sys/nfs/bootp_subr.c
index 2c57a91..972fb12 100644
--- a/sys/nfs/bootp_subr.c
+++ b/sys/nfs/bootp_subr.c
@@ -45,6 +45,7 @@ __FBSDID($FreeBSD$);
#include opt_bootp.h
#include opt_nfs.h
+#include opt_rootdevname.h
#include sys/param.h
#include sys/systm.h
@@ -870,8 +871,20 @@ bootpc_call(struct bootpc_globalcontext
*gctx,
struct thread *td)
rtimo = time_second +
BOOTP_SETTLE_DELAY;
printf( (got root path));
- } else
+ } else {
printf( (no root path));
+#ifdef ROOTDEVNAME
+ /*
+ * If we'll mount rootfs from
+ * ROOTDEVNAME, we can accept
+ * offers without root paths.
+ */
+ gotrootpath = 1;
+ rtimo = time_second +
+ BOOTP_SETTLE_DELAY;
+ printf( (ROOTDEVNAME));
+#endif
+ }
printf(\n);
}
} /* while secs */
@@ -1440,6 +1453,16 @@ bootpc_decode_reply(struct nfsv3_diskless
*nd,
struct bootpc_ifcontext *ifctx,
p = bootpc_tag(gctx-tag, ifctx-reply, ifctx-replylen,
TAG_ROOT);
+#ifdef ROOTDEVNAME
+ /*
+ * If there was no root path in BOOTP, use the one in
ROOTDEVNAME.
+ */
+ if (p == NULL) {
+ p = strdup(ROOTDEVNAME, M_TEMP);
+ if (strcmp(strsep(p, :), nfs) != 0)
+ panic(ROOTDEVNAME is not an NFS mount point);
+ }
+#endif
if (p != NULL) {
if (gctx-setrootfs != NULL) {
printf(rootfs %s (ignored) , p);
I've seen several requests over the past year for an nfs ROOTDEVNAME
along with BOOTP to work properly from ARM developers (myself
included),
so I don't think we should worry about breaking existing config that
happens to be checked in but a) hasn't been tested by anyone for ages,
and b) doesn't work anyway (ROOTDEVNAME just gets ignored).
-- Ian
Cool. Thanks. Would you like to review and/or test the above?
I'll be happy to commit it if Lars doesn't have a src commit bit. (I've
seen his posts, but can't remember if he is a committer?)
rick
___
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
