Re: [7-STABLE] failure during buildworld
Horst Günther Burkhardt III wrote: > Hey everybody :) > > I'm having a small issue compiling 7-STABLE... during make buildworld, this > error > occurs: > > ===> gnu/lib/libstdc++ (depend) > ln -sf > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/cpu/generic/atomicity_mutex/atomicity.h > atomicity.cc > ln -sf /usr/src/gnu/lib/libstdc++/../../../contrib/gcc/unwind-generic.h > unwind.h > rm -f .depend > mkdep -f .depend -a-DIN_GLIBCPP_V3 -DHAVE_CONFIG_H > -I/usr/src/gnu/lib/libstdc++ > -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ > -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc > -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include > -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/include > -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/include -I. > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libmath/stubs.c > /usr/src/gnu/lib/libstdc++/../../../contrib/gcclibs/libiberty/cp-demangle.c > mkdep -f .depend -a > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/bitmap_allocator.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/pool_allocator.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/mt_allocator.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/codecvt.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/compatibility.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/complex_io.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ctype.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/debug_list.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/functexcept.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/globals_io.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios.cc > /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_failure.cc > /usr/src/gnu/lib/libstdc++/../ ../../contrib/libstdc++/src/ios_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios_locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/limits.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/list.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_init.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale_facets.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/localename.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/stdexcept.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/strstream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/tree.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/allocator-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/concept-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/fstream-inst.cc /usr/src/gnu/lib/libstdc ++/../../../contrib/libstdc++/src/ext-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ios-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/iostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/istream.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/locale-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/misc-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/ostream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/sstream-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/streambuf.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/string-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/valarray-inst.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wlocale-ins t.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/src/wstring-inst.cc atomicity.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/codecvt_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/collate_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/darwin/ctype_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/messages_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/monetary_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/numeric_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/time_members.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/io/basic_file_stdio.cc /usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/config/locale/generic/c_locale.cc /usr/src/gnu/lib/libstd
Re: current zfs tuning in RELENG_7 (AMD64) suggestions ?
>> This information is outdated. The current max in RELENG_7 for amd64 is >> ~3.75GB. Technically, RELENG_7 should allow kmem_size of up to 6G, but the sysctl variables used for tuning are 32-bit and *that* limits kmem_size to ~4G. It's been fixed in -current and can easily be fixed in RELENG_7 (if it's not fixedyet). As far as I can tell, all necessary code to support large kmem_size is already in RELENG_7. It's easy enough to allow even larger kmem_size. See attached diff that I'm using. With that diff you can set vm.kmem_size to ~16G. --Artem vm-large.diff Description: Binary data ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: current zfs tuning in RELENG_7 (AMD64) suggestions ?
On Sat, May 2, 2009 at 12:11 PM, Alan Cox wrote: > On Fri, May 1, 2009 at 6:28 PM, Freddie Cash wrote: >> On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski >> wrote: >> > On May 1, 2009, at 1:53 PM, Pete French wrote: >> >> ... >> >> The tuning isn't there to improve performance, it's there to prevent >> >> the box going titus due to a panic when the ARC gets too big, and >> >> you are missing the mian one, which is to limit the size of the ARC. >> >> On recent versions of BSD (and you are running 7.2, so thats fine) then >> >> the defaults for kmem size are fine, but you still need something like >> >> this: >> >> >> >> vfs.zfs.arc_max="256M" >> >> >> >> In there to stop the ARC growing. thats the only tuning I have on >> >> my 4 gig machine, which takes a steady stream of data and is used >> >> for taking backup snapshots. ZFS is excellent, and for me is perfectly >> >> stable, to the point where I am starting to roll it out to production >> >> machines, with the above tuning. >> >> >> > I agree, although I'm using 384 instead of 256. My systems have been >> > running in production for almost a year now w/o any ZFS issues. >> >> The exact value to use will depend on the system. Particularly on the >> amount of RAM in the system, and what kmem_max is set to. A >> "rule-of-thumb" we've been using is: >> kmem_max should be half of the amount of RAM (or 1.5 GB as that's >> the current max) > > This information is outdated. The current max in RELENG_7 for amd64 is > ~3.75GB. Nice! Good to hear. Thanks for the correction. Looking forward to testing this with 7.2. -- Freddie Cash fjwc...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
7.2-RC2 Xorg sysinstall bug
Hi, I've notice an odd issue in sysinstall with RC2. When I get to the distribution set screen I go to "Custom" and select "All" and then I remove the distribution sets I don't want. It's just quicker to unselect a small handful of sets. However after deselecting Xorg it still gets installed. Anyone have any clue what may be up? It's not an issue if for instance I don't select "All" but instead select Xorg and then unselect it on the "Custom" screen. Thanks. tom (Please CC me on replies.) -- | tmclaugh at sdf.lonestar.org tmclaugh at FreeBSD.org | | FreeBSD http://www.FreeBSD.org | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: current zfs tuning in RELENG_7 (AMD64) suggestions ?
On Fri, May 1, 2009 at 6:28 PM, Freddie Cash wrote: > On Fri, May 1, 2009 at 4:12 PM, Louis Kowolowski > wrote: > > On May 1, 2009, at 1:53 PM, Pete French wrote: > >> ... > >> The tuning isn't there to improve performance, it's there to prevent > >> the box going titus due to a panic when the ARC gets too big, and > >> you are missing the mian one, which is to limit the size of the ARC. > >> On recent versions of BSD (and you are running 7.2, so thats fine) then > >> the defaults for kmem size are fine, but you still need something like > >> this: > >> > >> vfs.zfs.arc_max="256M" > >> > >> In there to stop the ARC growing. thats the only tuning I have on > >> my 4 gig machine, which takes a steady stream of data and is used > >> for taking backup snapshots. ZFS is excellent, and for me is perfectly > >> stable, to the point where I am starting to roll it out to production > >> machines, with the above tuning. > >> > > I agree, although I'm using 384 instead of 256. My systems have been > > running in production for almost a year now w/o any ZFS issues. > > The exact value to use will depend on the system. Particularly on the > amount of RAM in the system, and what kmem_max is set to. A > "rule-of-thumb" we've been using is: > kmem_max should be half of the amount of RAM (or 1.5 GB as that's > the current max) This information is outdated. The current max in RELENG_7 for amd64 is ~3.75GB. Regards, Alan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
#0 sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available.
is this known bug? Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x8c000180 fault code = supervisor read, page not present instruction pointer = 0x20:0xc063d904 stack pointer = 0x28:0xe7704608 frame pointer = 0x28:0xe7704620 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 2013 (firefox-bin) trap number = 12 panic: page fault cpuid = 0 Uptime: 5h1m34s Physical memory: 2038 MB Dumping 194 MB: 179 163 147 131 115 99 83 (CTRL-C to abort) 67 (CTRL-C to abort) (CTRL-C to abort) (CTRL-C to abort) 51 (CTRL-C to abort) 35 19 3 kgdb: kvm_read: invalid address (0x4c414e52) kgdb: kvm_read: invalid address (0x35b2e804) kgdb: kvm_read: invalid address (0x5502) kgdb: kvm_read: invalid address (0x6a02) Reading symbols from /boot/kernel/geom_journal.ko...Reading symbols from /boot/kernel/geom_journal.ko.symbols...done. done. Loaded symbols for /boot/kernel/geom_journal.ko Reading symbols from /boot/kernel/acpi_ibm.ko...Reading symbols from /boot/kernel/acpi_ibm.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi_ibm.ko Reading symbols from /boot/kernel/acpi.ko...Reading symbols from /boot/kernel/acpi.ko.symbols...done. done. Loaded symbols for /boot/kernel/acpi.ko Reading symbols from /boot/kernel/linprocfs.ko...Reading symbols from /boot/kernel/linprocfs.ko.symbols...done. done. Loaded symbols for /boot/kernel/linprocfs.ko Reading symbols from /boot/kernel/linux.ko...Reading symbols from /boot/kernel/linux.ko.symbols...done. done. Loaded symbols for /boot/kernel/linux.ko #0 sched_switch (td=0xc579b230, newtd=Variable "newtd" is not available. ) at /usr/src/sys/kern/sched_ule.c:1944 1944cpuid = PCPU_GET(cpuid); (kgdb) 7.2-PRERELEASE FreeBSD 7.2-PRERELEASE #7: Sat May 2 17:06:46 JST 2009 -- -dikshie- ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: process hanging on 7.2-PRERELEASE
On Sat, 2 May 2009 15:45:17 +0300, Kostik Belousov wrote: > On Sat, May 02, 2009 at 02:43:52PM +0400, Max Brazhnikov wrote: > > Currently all kde4 ports marked as jobs_unsafe, because of automoc4 > > hangs. The problem can be easely reproduced building e.g. > > accessibility/kdeaccessibility4 with multiple jobs: replace > > MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port Makefile and run 'make > > MAKE_JOBS_NUMBER=16'. Build will be freezed on > > > > /usr/local/bin/cmake -E cmake_progress_report > > /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility > >-4.2.2/build/CMakeFiles 77 78 79 8081 82 83 84 85 86 87 88 89 90 91 92 93 > > 94 95 > > [ 95%] Built target kmouth > > > > # ps | grep automoc4 > > 77829 p4 S+ 0:00.27 /usr/local/bin/automoc4 > > /tank/obj/usr/ports/accessibility/kdeaccessibility4/ 77840 p4 I+ > > 0:00.00 /usr/local/bin/automoc4 > > /tank/obj/usr/ports/accessibility/kdeaccessibility4/ > > > > #gdb66 automoc4 77829 > > 0x2846fb3b in select () at select.S:2 > > 2 RSYSCALL(select) > > (gdb) bt > > #0 0x2846fb3b in select () at select.S:2 > > #1 0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0, > > exceptfds=0x0, timeout=0x0) at > > /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444 > > #2 0x281b4f3d in QProcessManager::run (this=0x287142f0) at > > io/qprocess_unix.cpp:301 #3 0x280f30e2 in QThreadPrivate::start > > (arg=0x287142f0) at thread/qthread_unix.cpp:185 #4 0x2838b68a in > > thread_start (curthread=0x28701150) at > > /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288 #5 0x in > > ?? () > > Current language: auto; currently asm > > (gdb) > > > > > > # gdb66 automoc4 77840 > > 0x28395593 in _umtx_op_err () at > > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 36 > > SYSCALL_ERR(_umtx_op) > > (gdb) bt > > #0 0x28395593 in _umtx_op_err () at > > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 #1 > > 0x283953c4 in __thr_umutex_lock (mtx=0x8054f3c, id=100416) at > > /usr/freebsd/7/src/lib/libthr/thread/thr_umtx.c:58 #2 0x28390502 in > > mutex_lock_sleep (curthread=0x28701040, m=0x8054f3c, abstime=0x0) at > > /usr/freebsd/7/src/lib/libthr/thread/thr_mutex.c:401 #3 0x283fb0ea in > > _malloc_postfork () at /usr/freebsd/7/src/lib/libc/stdlib/malloc.c:1029 > > #4 0x28393038 in _fork () at > > /usr/freebsd/7/src/lib/libthr/thread/thr_fork.c:178 #5 0x281b7381 in > > QProcessPrivate::startProcess (this=0x287720f0) at > > io/qprocess_unix.cpp:570 #6 0x2817a181 in QProcess::start > > (this=0xbfbfe1b8, progr...@0xbfbfe5dc, argumen...@0xbfbfe1b4, > > mo...@0xbfbfe1c0) at io/qprocess.cpp:1508 #7 0x08051720 in > > AutoMoc::echoColor (this=0xbfbfe5c8, m...@0xbfbfe258) at > > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:7 > >3 #8 0x0804c0a7 in AutoMoc::generateMoc (this=0xbfbfe5c8, > > sourcefi...@0x28714418, mocfilena...@0x2871441c) at > > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:5 > >69 #9 0x0804f4ae in AutoMoc::run (this=0xbfbfe5c8) at > > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:4 > >70 #10 0x080504e6 in main (argc=Cannot access memory at address 0x0 ) at > > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:1 > >14 Current language: auto; currently asm > > (gdb) > > Great. > > I think this is a missed merge of the r185514 to 7. Can you, please, > retest with that revision merged ? Great! With the patch I can't reproduce the problem! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: process hanging on 7.2-PRERELEASE
On Sat, May 02, 2009 at 02:43:52PM +0400, Max Brazhnikov wrote: > Currently all kde4 ports marked as jobs_unsafe, because of automoc4 hangs. > The problem can be easely reproduced building e.g. > accessibility/kdeaccessibility4 > with multiple jobs: replace MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port > Makefile > and run 'make MAKE_JOBS_NUMBER=16'. Build will be freezed on > > /usr/local/bin/cmake -E cmake_progress_report > /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility-4.2.2/build/CMakeFiles > 77 78 > 79 8081 82 83 84 85 86 87 88 89 90 91 92 93 94 95 > [ 95%] Built target kmouth > > # ps | grep automoc4 > 77829 p4 S+ 0:00.27 /usr/local/bin/automoc4 > /tank/obj/usr/ports/accessibility/kdeaccessibility4/ > 77840 p4 I+ 0:00.00 /usr/local/bin/automoc4 > /tank/obj/usr/ports/accessibility/kdeaccessibility4/ > > #gdb66 automoc4 77829 > 0x2846fb3b in select () at select.S:2 > 2 RSYSCALL(select) > (gdb) bt > #0 0x2846fb3b in select () at select.S:2 > #1 0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0, > exceptfds=0x0, timeout=0x0) > at /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444 > #2 0x281b4f3d in QProcessManager::run (this=0x287142f0) at > io/qprocess_unix.cpp:301 > #3 0x280f30e2 in QThreadPrivate::start (arg=0x287142f0) at > thread/qthread_unix.cpp:185 > #4 0x2838b68a in thread_start (curthread=0x28701150) at > /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288 > #5 0x in ?? () > Current language: auto; currently asm > (gdb) > > > # gdb66 automoc4 77840 > 0x28395593 in _umtx_op_err () at > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 > 36 SYSCALL_ERR(_umtx_op) > (gdb) bt > #0 0x28395593 in _umtx_op_err () at > /usr/freebsd/7/src/lib/libthr/arch/i386/i386/_umtx_op_err.S:36 > #1 0x283953c4 in __thr_umutex_lock (mtx=0x8054f3c, id=100416) at > /usr/freebsd/7/src/lib/libthr/thread/thr_umtx.c:58 > #2 0x28390502 in mutex_lock_sleep (curthread=0x28701040, m=0x8054f3c, > abstime=0x0) at /usr/freebsd/7/src/lib/libthr/thread/thr_mutex.c:401 > #3 0x283fb0ea in _malloc_postfork () at > /usr/freebsd/7/src/lib/libc/stdlib/malloc.c:1029 > #4 0x28393038 in _fork () at > /usr/freebsd/7/src/lib/libthr/thread/thr_fork.c:178 > #5 0x281b7381 in QProcessPrivate::startProcess (this=0x287720f0) at > io/qprocess_unix.cpp:570 > #6 0x2817a181 in QProcess::start (this=0xbfbfe1b8, progr...@0xbfbfe5dc, > argumen...@0xbfbfe1b4, mo...@0xbfbfe1c0) at io/qprocess.cpp:1508 > #7 0x08051720 in AutoMoc::echoColor (this=0xbfbfe5c8, m...@0xbfbfe258) at > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:73 > #8 0x0804c0a7 in AutoMoc::generateMoc (this=0xbfbfe5c8, > sourcefi...@0x28714418, mocfilena...@0x2871441c) > at > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:569 > #9 0x0804f4ae in AutoMoc::run (this=0xbfbfe5c8) at > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:470 > #10 0x080504e6 in main (argc=Cannot access memory at address 0x0 > ) at > /tank/obj/usr/ports/devel/automoc4/work/automoc4-0.9.88/kde4automoc.cpp:114 > Current language: auto; currently asm > (gdb) Great. I think this is a missed merge of the r185514 to 7. Can you, please, retest with that revision merged ? pgpuASYgMPTLz.pgp Description: PGP signature
Re: bluetooth troubleshooting
Bruce Cran wrote: > On Sat, 02 May 2009 09:18:26 +0200 > Dominic Fandrey wrote: > >> # /etc/rc.d/bluetooth onestart ubt0 >> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for >> device ubt0 # /etc/rc.d/bluetooth onestart ubt1 >> /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for >> device ubt1 >> >> This error message gives me no idea of what is wrong. The handbook >> mentions comms/hcidump for debugging, but I think this is meant >> for analyzing bluetooth traffic. >> As you can see I haven't gotten far enough to produce any traffic to >> analyse. Is someone here familiar with bluetooth and can provide >> me with a command that might reveal something about the nature >> of my problem? > > I think devd now automatically starts the Bluetooth stack when you > plug in a recognised device, so you'll only be able to use onestart > after first running onestop. > So it's already working! I was confused because the output of # hccontrol -n ubt0hci inquiry Inquiry complete. Status: No error [00] is pretty lame compared to what should appear according to the handbook: % hccontrol -n ubt0hci inquiry Inquiry result, num_responses=1 Inquiry result #0 BD_ADDR: 00:80:37:29:19:a4 Page Scan Rep. Mode: 0x1 Page Scan Period Mode: 00 Page Scan Mode: 00 Class: 52:02:04 Clock offset: 0x78ef Inquiry complete. Status: No error [00] Thanks a lot! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
process hanging on 7.2-PRERELEASE
Currently all kde4 ports marked as jobs_unsafe, because of automoc4 hangs. The problem can be easely reproduced building e.g. accessibility/kdeaccessibility4 with multiple jobs: replace MAKE_JOBS_UNSAFE with MAKE_JOBS_SAFE in port Makefile and run 'make MAKE_JOBS_NUMBER=16'. Build will be freezed on /usr/local/bin/cmake -E cmake_progress_report /tank/obj/usr/ports/accessibility/kdeaccessibility4/work/kdeaccessibility-4.2.2/build/CMakeFiles 77 78 79 8081 82 83 84 85 86 87 88 89 90 91 92 93 94 95 [ 95%] Built target kmouth # ps | grep automoc4 77829 p4 S+ 0:00.27 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/ 77840 p4 I+ 0:00.00 /usr/local/bin/automoc4 /tank/obj/usr/ports/accessibility/kdeaccessibility4/ #gdb66 automoc4 77829 GNU gdb 6.6 [GDB v6.6 for FreeBSD] Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for details. This GDB was configured as "i386-portbld-freebsd7.0"... Attaching to program: /usr/local/bin/automoc4, process 77829 Reading symbols from /usr/local/lib/qt4/libQtCore.so.4...Reading symbols from /usr/local/lib/qt4/libQtCore.so.4.4.3.debug...done. done. Loaded symbols for /usr/local/lib/qt4/libQtCore.so.4 Reading symbols from /usr/lib/libstdc++.so.6...done. Loaded symbols for /usr/lib/libstdc++.so.6 Reading symbols from /lib/libm.so.5...done. Loaded symbols for /lib/libm.so.5 Reading symbols from /lib/libgcc_s.so.1...done. Loaded symbols for /lib/libgcc_s.so.1 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /lib/libz.so.4...done. Loaded symbols for /lib/libz.so.4 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libintl.so.8...done. Loaded symbols for /usr/local/lib/libintl.so.8 Reading symbols from /usr/local/lib/libpcre.so.0...done. Loaded symbols for /usr/local/lib/libpcre.so.0 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 0x2846fb3b in select () at select.S:2 2 RSYSCALL(select) (gdb) bt #0 0x2846fb3b in select () at select.S:2 #1 0x2838d788 in __select (numfds=6, readfds=0xbf9feee8, writefds=0x0, exceptfds=0x0, timeout=0x0) at /usr/freebsd/7/src/lib/libthr/thread/thr_syscalls.c:444 #2 0x281b4f3d in QProcessManager::run (this=0x287142f0) at io/qprocess_unix.cpp:301 #3 0x280f30e2 in QThreadPrivate::start (arg=0x287142f0) at thread/qthread_unix.cpp:185 #4 0x2838b68a in thread_start (curthread=0x28701150) at /usr/freebsd/7/src/lib/libthr/thread/thr_create.c:288 #5 0x in ?? () Current language: auto; currently asm (gdb) # gdb66 automoc4 77840 GNU gdb 6.6 [GDB v6.6 for FreeBSD] Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type "show copying" to see the conditions. There is absolutely no warranty for GDB. Type "show warranty" for deta
Re: bluetooth troubleshooting
On Sat, 02 May 2009 09:18:26 +0200 Dominic Fandrey wrote: > # /etc/rc.d/bluetooth onestart ubt0 > /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for > device ubt0 # /etc/rc.d/bluetooth onestart ubt1 > /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for > device ubt1 > > This error message gives me no idea of what is wrong. The handbook > mentions comms/hcidump for debugging, but I think this is meant > for analyzing bluetooth traffic. > As you can see I haven't gotten far enough to produce any traffic to > analyse. Is someone here familiar with bluetooth and can provide > me with a command that might reveal something about the nature > of my problem? I think devd now automatically starts the Bluetooth stack when you plug in a recognised device, so you'll only be able to use onestart after first running onestop. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: How do i fix the broken FTP structure of freebsd 7.0?
Hi Glen: --- On Sun, 4/26/09, Glen Barber wrote: > From: Glen Barber > Subject: Re: How do i fix the broken FTP structure of freebsd 7.0? > To: waldoalvare...@yahoo.com > Cc: freebsd-stable@freebsd.org > Date: Sunday, April 26, 2009, 10:23 PM > On Sun, Apr 26, 2009 at 7:40 PM, wac > wrote: > > > > Thanks Glen but doing that in a remote computer is > askin for trouble and I can't step to the risk of having > that computer trashed (fixing it would cost almost as much > as renting a new one). Anyway in the forums somebody gave me > this: > > Doing what in a remote machine is asking for trouble? SSH > will not be affected. Installing a new kernel remotely. If the new one does not boots properly then I'm in trouble. Serious trouble. (I do not have local access to the console, all the time over ssh and if i reboot it over webmin just in case i make a mistake reconfiguring ssh) > > > > > > ftp://ftp-archive.freebsd.org/pub/FreeBSD-Archive/old-releases/i386/7.0-RELEASE/packages/All > > > > The problem now is that the package I need is way too > old. Let's see if i can work out to fix that. Problem is > it uses perl and perl is used by another package the hosting > company installed that depends on it. And that I really have > 0 experience with it so reinstalling a new one means > downtime. I'll try to modify dkimproxy and see what > happens. So far the newer version installed with warnings > but doesn't even start. > > > > If you need "stability" (production ready), you > (as the maintainer of > the machine) are obligated to some extent to keep it both, > up to date > and "stable". Yes and keep it safe from all those attacks i receive 24/7. Problem is upgrade is not an option for me. But that's ok, i removed old perl, old webmin, installed new perl, new webmin, new dkimproxy. Everything went ok since i carefully followed all the steps i simulated in a virtual machine here. And.. Uf. Didn't had to even reboot that one. > > Note: I use "stable" in quotes to not be > confused with -STABLE. > > AFAIK, 7.0-REL was EOL'd (or is scheduled to be). > Ports are generally > guaranteed to be installable on the latest -RELEASE version > (in this > case, 7.1-RELEASE). Now you know it. At least perl from 7-stable, webmin and dkimproxy-1.1 on top of it works just fine on top of the 7.0 release. I tested it, and works great to the point that amazes me. Anything prior to that is not a > guarantee. > Packages (as I am sure you are aware) are only built one > time -- when > X.X-RELEASE is released. There is no guarantee on > compatibility after > that point. > > -- > Glen Barber > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to > "freebsd-stable-unsubscr...@freebsd.org" ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
bluetooth troubleshooting
I've got two bluetooth devices, an internal usb bluetooth device by Broadcom and a dated AVM class1 bluetooth dongle. Both are detected by the ubt driver: ubt0: on uhub0 ubt0: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt0: Interface 1 (alt.config 4) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=64; nframes=5, buffer size=320 ubt1: on uhub3 ubt1: Interface 0 endpoints: interrupt=0x81, bulk-in=0x82, bulk-out=0x2 ubt1: Interface 1 (alt.config 5) endpoints: isoc-in=0x83, isoc-out=0x3; wMaxPacketSize=49; nframes=6, buffer size=294 However neither a device /dev/ubt0 nor /dev/ubt1 exists. # /etc/rc.d/bluetooth onestart ubt0 /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt0 # /etc/rc.d/bluetooth onestart ubt1 /etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for device ubt1 This error message gives me no idea of what is wrong. The handbook mentions comms/hcidump for debugging, but I think this is meant for analyzing bluetooth traffic. As you can see I haven't gotten far enough to produce any traffic to analyse. Is someone here familiar with bluetooth and can provide me with a command that might reveal something about the nature of my problem? BTW, is there a way to get A2DP receive running on FreeBSD? ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
