Re: HEADS UP: FreeBSD src repo transitioning to git this weekend
On 2020-12-17 21:53, Thomas Mueller wrote: > I hope we don't have to start signing all commits. saltstack/salt has > that policy, and it's extremely annoying. Have to? Not currently. As with all process changes, there will be community discussion around the different points. Warner I hope not! Signatures, at least in email messages, are just an annoyance as I see them. I don't even know how do sign an email message or make use of a signature in a message I receive. I have never made a commit to a repository, so would not be familiar with signatures there; imagine it would be a barrier. Tom ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" I'm not a FreeBSD committer, but on other git projects I sign my commits. AFAIK it's a good idea. I'm curious what is annoying about it? It's just adding the 'sign' tag. If you want a portable GPG key check out something like a yubikey. I'm sure there's other portable hardware options. # git commit -S -m "message" You can also set to always sign automatically, # git config --global commit.gpgsign true -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Installers for FreeBSD fail to boot HP ProBook 440 G7
On 2020-12-03 20:25, Graham Perrin wrote: Where installers for FreeBSD 12.2 and 13.0-CURRENT fail to boot, the installer for OmniOS community edition succeeds. Photographs and other details at <https://old.reddit.com/r/freebsd/comments/ir90ra/hp_probook_440_g7/gejo49g/>; "I'm advised that it's symptomatic of the kernel not loading.". ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Something to check out? That machine has Intel and NVidia gpu, you should check the BIOS settings. I have a Lenovo laptop that won't boot if it's set in BIOS to 'detect/auto', I think it's called Optimus? But my Dell that also has both boots fine although there's no selectable option in BIOS. -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Working on Zoom port
On 2020-04-13 14:59, Pete Wright wrote: On 4/12/20 12:26 PM, Eric McCorkle wrote: All, Given how Zoom is getting used a lot more these days, I've started working on a port that installs the Zoom linux client. Here is a link to my github if anyone wants to help: https://github.com/emc2/freebsd-ports/tree/zoom I'm not done yet. The zoom linux client installs a bunch of Qt libraries in its own directory. These either need to be installed with a port, or else the right configs need to be set to search for libraries there. I'm going to take a break, but I'm going to circle back to this. Thanks Eric, I remember trying to get this working several months ago via the linux compatibility layer and got stuck. i hope to take another wack at it based on your repository. in my ideal world i'd be able to get this working in a jail via, but i think just getting the bits to work is probably the most important task. i've had working solutions based on jitsi and riot.im with acceptable performance, so i suspect our webcamd bits are in good enough shape to support this. interested to see how how this effort progresses :) -pete A few things - using "latest" for the distfile isn't going to work, as soon as they update the file it will break the port. Also they ship a whole bunch of libraries without any licenses. For sure there is Apache and BSD code in there. I guess somebody could write Boston to the the GPL licenses, but the other libraries are totally a no-go without licenses. Are they using the "commerical" version of Qt? Or maybe they just got liberal with it like they did the other stuff? I think the commercial version is different than normal people have, if not now then soon. -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed compiling ittnotify_static.pico
On 2020-03-13 20:07, Waitman Gobble wrote:
On 2020-03-13 20:00, Dimitry Andric wrote:
On 13 Mar 2020, at 23:58, Waitman Gobble wrote:
On 2020-03-13 17:49, Waitman Gobble wrote:
On 2020-03-13 16:57, Bob Willcox wrote:
...
cc: error: no such file or directory:
'/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
cc: error: no input files
*** [ittnotify_static.pico] Error code 1
Anyone else seeing this? Any suggestions for a fix?
Thanks,
Bob
I've been getting the same thing since yesterday. I think the file
is actually
ittnotify_static.cpp
This is supposed to handle the rename, for some reason it's not
happening on my machine.
Makefile.inc1
# 20200310 r358851 rename of openmp's ittnotify_static.c to .cpp
.for f in ittnotify_static
@if [ -e "${OBJTOP}/lib/libomp/.depend.${f}.pico" ] && \
egrep -qw '${f}\.c'
${OBJTOP}/lib/libomp/.depend.${f}.pico; then \
echo "Removing stale dependencies for ${f}"; \
rm -f ${OBJTOP}/lib/libomp/.depend.${f}.* \
${OBJTOP}/obj-lib32/lib/libomp/.depend.${f}.* \
${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libomp/.depend.${f}.*}; \
fi
.endfor
Hm, so during your buildworld, does it show "Removing stale
dependencies
for ittnotify_static" or not? And is the .depend file there? Can you
check /usr/obj for the file .depend.ittnotify_static.pico, and list
its
permissions?
-Dimitry
OK, I'll check it out. I was looking in /usr/src and now realize my
mistake. OBJTOP should have been a queue, but I missed it.
I just did a make cleanworld, and now rebuilding. So I'll see what
happens.
The Makefile for libomp specifies the .cpp so I'm not quite sure why
it's looking for .c anyway.
'make cleanworld' solved it, build without error.
I used to always delete obj for years, but I've not done that for a
couple of years without any problems I've noticed.
--
Waitman Gobble
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed compiling ittnotify_static.pico
On 2020-03-13 20:00, Dimitry Andric wrote:
On 13 Mar 2020, at 23:58, Waitman Gobble wrote:
On 2020-03-13 17:49, Waitman Gobble wrote:
On 2020-03-13 16:57, Bob Willcox wrote:
...
cc: error: no such file or directory:
'/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
cc: error: no input files
*** [ittnotify_static.pico] Error code 1
Anyone else seeing this? Any suggestions for a fix?
Thanks,
Bob
I've been getting the same thing since yesterday. I think the file is
actually
ittnotify_static.cpp
This is supposed to handle the rename, for some reason it's not
happening on my machine.
Makefile.inc1
# 20200310 r358851 rename of openmp's ittnotify_static.c to .cpp
.for f in ittnotify_static
@if [ -e "${OBJTOP}/lib/libomp/.depend.${f}.pico" ] && \
egrep -qw '${f}\.c' ${OBJTOP}/lib/libomp/.depend.${f}.pico;
then \
echo "Removing stale dependencies for ${f}"; \
rm -f ${OBJTOP}/lib/libomp/.depend.${f}.* \
${OBJTOP}/obj-lib32/lib/libomp/.depend.${f}.* \
${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libomp/.depend.${f}.*}; \
fi
.endfor
Hm, so during your buildworld, does it show "Removing stale
dependencies
for ittnotify_static" or not? And is the .depend file there? Can you
check /usr/obj for the file .depend.ittnotify_static.pico, and list its
permissions?
-Dimitry
OK, I'll check it out. I was looking in /usr/src and now realize my
mistake. OBJTOP should have been a queue, but I missed it.
I just did a make cleanworld, and now rebuilding. So I'll see what
happens.
The Makefile for libomp specifies the .cpp so I'm not quite sure why
it's looking for .c anyway.
--
Waitman Gobble
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed compiling ittnotify_static.pico
On 2020-03-13 17:49, Waitman Gobble wrote:
On 2020-03-13 16:57, Bob Willcox wrote:
My 13.0-current system (just updated about 2 hours ago) that is
failing with this
error when trying to do a 'make makeworld'
--- ittnotify_static.pico ---
cc -target x86_64-unknown-freebsd13.0
--sysroot=/usr/obj/usr/src/amd64.amd64/tmp
-B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -fpic -DPIC -O2 -pipe
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I/usr/src/lib/libomp
-I/usr/src/contrib/llvm-project/openmp/runtime/src
-I/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify
-ffunction-sections -fdata-sections -g -MD
-MF.depend.ittnotify_static.pico -MTittnotify_static.pico -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wno-atomic-alignment
-Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-address-of-packed-member -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments-c
/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittno
tify_static.c -o ittnotify_static.pico
cc: error: no such file or directory:
'/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c'
cc: error: no input files
*** [ittnotify_static.pico] Error code 1
Anyone else seeing this? Any suggestions for a fix?
Thanks,
Bob
I've been getting the same thing since yesterday. I think the file is
actually
ittnotify_static.cpp
This is supposed to handle the rename, for some reason it's not
happening on my machine.
Makefile.inc1
# 20200310 r358851 rename of openmp's ittnotify_static.c to .cpp
.for f in ittnotify_static
@if [ -e "${OBJTOP}/lib/libomp/.depend.${f}.pico" ] && \
egrep -qw '${f}\.c' ${OBJTOP}/lib/libomp/.depend.${f}.pico;
then \
echo "Removing stale dependencies for ${f}"; \
rm -f ${OBJTOP}/lib/libomp/.depend.${f}.* \
${OBJTOP}/obj-lib32/lib/libomp/.depend.${f}.* \
${LIBCOMPAT:D${LIBCOMPAT_OBJTOP}/lib/libomp/.depend.${f}.*}; \
fi
.endfor
--
Waitman Gobble
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Build failed compiling ittnotify_static.pico
On 2020-03-13 16:57, Bob Willcox wrote: My 13.0-current system (just updated about 2 hours ago) that is failing with this error when trying to do a 'make makeworld' --- ittnotify_static.pico --- cc -target x86_64-unknown-freebsd13.0 --sysroot=/usr/obj/usr/src/amd64.amd64/tmp -B/usr/obj/usr/src/amd64.amd64/tmp/usr/bin -fpic -DPIC -O2 -pipe -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -I/usr/src/lib/libomp -I/usr/src/contrib/llvm-project/openmp/runtime/src -I/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify -ffunction-sections -fdata-sections -g -MD -MF.depend.ittnotify_static.pico -MTittnotify_static.pico -std=gnu99 -Wno-format-zero-length -fstack-protector-strong -Wno-atomic-alignment -Wsystem-headers -Werror -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Qunused-arguments-c /usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittno tify_static.c -o ittnotify_static.pico cc: error: no such file or directory: '/usr/src/contrib/llvm-project/openmp/runtime/src/thirdparty/ittnotify/ittnotify_static.c' cc: error: no input files *** [ittnotify_static.pico] Error code 1 Anyone else seeing this? Any suggestions for a fix? Thanks, Bob I've been getting the same thing since yesterday. I think the file is actually ittnotify_static.cpp -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Pkg repository is broken...
On 2020-03-07 05:10, Ronald Klop wrote: On Sat, 07 Mar 2020 01:38:55 +0100, Greg 'groggy' Lehey wrote: On Friday, 6 March 2020 at 12:29:44 +0100, Lars Engels wrote: On Wed, Mar 04, 2020 at 03:16:14PM +1100, Greg 'groggy' Lehey wrote: Any workarounds in the meantime? This must affect a lot of people, including those who use 12-: pkg: wrong architecture: FreeBSD:12.0:amd64 instead of FreeBSD:12:amd64 pkg: repository FreeBSD contains packages with wrong ABI: FreeBSD:12.0:amd64 Still broken for me on 12.1. Strange. Mine cleared up automatically the following day. It's also strange how few replies I have received. Two private messages (why?), yours, and that was it. You'd think that people would be screaming. Greg I'm not screaming because I'm settling with the situation and starting to make workarounds. And wondering where the official communication of the community is. Nothing about this situation on www.freebsd.org. All information about the situation seems scattered through the mailinglists. Things are working for me on 13-CURRENT again, but still broken on 12.1-RELEASE. See attachment. Ronald. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Did you try: pkg update -f I installed 12.1 on a new laptop yesterday, I have not experienced issues with pkg. -- Waitman Gobble ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sha256 speed
Sent from ProtonMail mobile Original Message On Jan 6, 2019, 8:17 PM, Stefan Ehmann wrote: Hello, On my Ryzen the sha256 command is much slower than openssl dgst -sha256. For large files, openssl is more than 7 times faster in practice. You can also test it with the builtin benchmarks: sha256 -t openssl speed sha256 I think the reason is that openssl supports the SHA CPU extensions whereas libmd (used by sha256) does not. Any chance we can make the base sha256 faster? I guess there is some reason why we use libmd instead of openssl. https://reviews.freebsd.org/D2651 looks related but not sure it's still relevant. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" Should probably dump sha256 anyways, blake2. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Painfully slow compilation (read: "make buildworld buildkernel") on not-so-weak system
‐‐‐ Original Message ‐‐‐
On Saturday, December 8, 2018 8:18 AM, Lev Serebryakov wrote:
> Hello Lev,
>
> Saturday, December 8, 2018, 2:13:03 PM, you wrote:
>
> > Another strange thing I noticed: when system is in such state, "top -SH"
> > shows that sometimes very low-profile processes, like clock software
> > interrupt (!) could consume large amount of CPU for short periods time. When
> > system is idle there never will be "intr{swi4: clock (0)}" consuming 55% CPU
> > for one "frame" or sshd, or screen itself.
>
> Like this. This system doesn't have any significant network traffic now —
> only one ssh connection, which is used as console. And 62.3% for network
> card. WTF?!
>
> PID USERNAME PRI NICE SIZE RES STATE C TIME WCPU COMMAND
> 20128 root 101 0 104M 74M CPU1 1 0:31 100.00% cc
> 0 root -76 - 0 4608K - 2 53:25 62.23% kernel{if_config_tqg_0}
> 11 root -60 - 0 240K WAIT 0 25:45 24.89% intr{swi4: clock (0)}
> 9 root -8 - 0 160K tx->tx 0 7:38 24.88% zfskern{txg_thread_enter}
>
> 995 root 24 0 17M 7676K select 1 2:20 12.44% sendmail
> 13791 root 24 0 24M 15M select 0 0:04 12.44% make
>
>
> -
>
> Best regards,
> Lev mailto:l...@freebsd.org
>
> freebsd-hack...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
I had super slow build for r341270, but I thought it was because I accidentally
left WITNESS option set.
I killed it after about 10 hours, booted to single user and rebuilt kernel
there.
Waitman
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error build nvidia-driver with r334555
‐‐‐ Original Message ‐‐‐ On June 3, 2018 8:21 AM, Konstantin Belousov wrote: > On Sun, Jun 03, 2018 at 05:08:34AM -0700, David Wolfskill wrote: > > > On Sun, Jun 03, 2018 at 06:48:01PM +0700, Alex V. Petrov wrote: > > > > > > > > > > > --- nvidia_subr.o --- > > > > > > nvidia_subr.c:367:26: error: 'memset' call operates on objects of type > > > > > > 'struct nv_ioctl_card_info' while the size is based on a different type > > > > > > 'struct nv_ioctl_card_info *' [-Werror,-Wsizeof > > > > > > -pointer-memaccess] > > > > > > memset(ci, 0, sizeof(ci)); > > > > > > ~~ ^~ > > > > > > nvidia_subr.c:367:26: note: did you mean to dereference the argument to > > > > > > 'sizeof' (and multiply it by the number of elements)? > > > > > > memset(ci, 0, sizeof(ci)); > > > ^~ > > > > > > > > > 1 error generated. > > > > > > *** [nvidia_subr.o] Error code 1 > > > > > > > > > > Aye; please ref. > > > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=228709 for > > > > additional details. > > > > The issue has been narrowed down to the range r334529 - r334535; I'm > > > > suspecting r334533 and/or r334534. (Not that the commits are in any way > > > > "faulty" -- merely that the nvidia-driver port may need some "evasive > > > > action" to allow for the change). > > Even not looking at the actual code, I am quite sure that the line > > nvidia_subr.c:367 should be changed to > > memset(ci, 0, sizeof(*ci)); > > This is a bug in the driver sources. > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" That solved the build problem for me. I haven't noticed any other issues with nvidia driver. Waitman Gobble Sent with ProtonMail Secure Email. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: send-pr must live
On Thu, November 20, 2014 9:25 am, Muhammad Moinur Rahman wrote: Nice idea. However I am working on reviving porttools to migrate within bugzilla system. Maybe we can share some ideas. BR, Muhammad On Thu, Nov 20, 2014 at 11:07 PM, Chris H bsd-li...@bsdforge.com wrote: Greetings, While I recognize that send-pr has pretty much become useless, with the advent of bugzilla, being made the new official FreeBSD bug reporting system. I really miss send-pr, and was hoping I could revive it, eg; integrate it with bugzilla. I had even contemplated adding a feature that would allow it to also work with local port/system building structures people often use to build, and maintain FreeBSD. Any objections to my reviving send-pr? Thank you for all your time, and consideration. --Chris ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org I liked using send-pr. It looks like Bugzilla 5.0 will have a native REST API but current versions use plugin. Also I believe Bugzilla supports an email interface so it could be possible to keep send-pr as a shell script. -- Waitman Gobble Los Altos California USA +1.510-830-7975 ___ 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: Leaving the Desktop Market
On Mon, March 31, 2014 10:46 pm, Eitan Adler wrote: Hi all, Some of you may have seen my posts entitled Story of a Laptop User and Story of a Desktop User. For those of you who did not, it can be a worthwhile read to see what life is like when using FreeBSD as a desktop. In short, it is an educational experience. While FreeBSD can be coerced to do the right thing, it is rarely there by default and often doesn't work as well as we would expect. The following are issues I haven't brought up in the past: Battery life sucks: itâs almost as if powerd wasn't running. Windows can run for five hours on my laptop while FreeBSD can barely make it two hours. I wonder what the key differences are? Likely itâs that we focus so much on performance that no one considers power. ChromeOS can run for 12 hours on some hardware; why can't we make FreeBSD run for 16? Sound configuration lacks key documentation: how can I automatically change between headphones and external speakers? You can't even do that in middle of a song at all! Trust me that you never want to be staring at an HDA pin configuration. I'll bet you couldn't even get sound streaming to other machines working if you tried. FreeBSD lacks vendor credibility: CUDA is unsupported. Dropbox hasn't released a client for FreeBSD. Nvidia Optimus doesn't function on FreeBSD. Can you imagine telling someone to purchase a laptop with the caveat: but you won't be able to use your graphics card? In any case, half of our desktop support is emulation: flash and opera only works because of the linuxulator. There really isn't any reason for vendors to bother supporting FreeBSD if we are just going to ape Linux anyways. That is why on this date I propose that we cease competing on the desktop market. FreeBSD should declare 2014 to be year of the Linux desktop and start to rip out the pieces of the OS not needed for server or embedded use. Some of you may point to PCBSD and say that we have a chance, but I must ask you: how does one flavor stand up to the thousands in the Linux world? Eitan Adler ___ 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 Hi, I don't understand the gripe about sound. OSS works well. If you install the verson in ports, audio/oss, you get a more elaborate set of tools. (you can use the tools with the OSS drivers in base, its possible to remove the base OSS system and *only* use the updated OSS system however there are some caveats that may cause serious issues with a 'user', if you don't want to get your hands dirty don't mess with that.) Anyhow, last I went through a few month period of experimenting with sound and picked up a bunch of hardware on ebay, different cards from various vendors, ie asus, creative, etc. Its possible and not too difficult to have four or five cards on the machine and use them simultaneously. I didn't notice any problem switching from speakers to headphones while music is playing. Maybe this works on other operating systems, i haven't tried. The thing about sound, the card is a digital-to-analog converter, and vice-versa. It uses PCM data. (PCM was actually first 'invented' in the 1800's - no fools joke). Digital audio/Sound has never really gotten better, it has only gotten cheaper. -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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: Leaving the Desktop Market
On Tue, April 1, 2014 11:59 am, Andreas Nilsson wrote: On Tue, Apr 1, 2014 at 7:11 PM, Matt Olander m...@ixsystems.com wrote: On Tue, Apr 1, 2014 at 12:11 AM, Jordan Hubbard j...@mail.turbofuzz.com wrote: On Apr 1, 2014, at 10:46 AM, Eitan Adler li...@eitanadler.com wrote: That is why on this date I propose that we cease competing on the desktop market. FreeBSD should declare 2014 to be year of the Linux desktop and start to rip out the pieces of the OS not needed for server or embedded use. Some of you may point to PCBSD and say that we have a chance, but I must ask you: how does one flavor stand up to the thousands in the Linux world? The fact that this posting comes out on April 1st makes me wonder if it's just an elaborate April Fool's joke, but then the notion of *BSD (or Linux, for that matter) on the Desktop is just another long-running April fool's joke, so I'm willing to postulate that two April Fools jokes would simply cancel each other out and make this posting a serious one again. :-) I'll choose to be serious and say what I'm about to say in spite of the fact that I work for the primary sponsor of PC-BSD and actually like the fact that it has created some interesting technologies like PBIs, the Jail Warden, Life-preserver and a ZFS boot environment menu. There is no such thing as a desktop market for *BSD or Linux. There never has been and there never will be. Why do you think we chose the power to serve as FreeBSD's first marketing slogan? It makes a fine server OS and it's easy to defend its role in the server room. It's also becoming easier to defend its role as an embedded OS, which is another excellent niche to pursue and I am happy to see all the recent developments there. A desktop? Unless you consider Mac OS X to be BSD on the desktop (and while they share some common technologies, it's increasingly a stretch to say that), it's just never going to happen for (at least) the following reasons: As you may imagine, I completely disagree! The Internet just had it's 20th birthday (it can't even drink yet!) and it's anyone's game. This is like trying to predict automobile technology and dominant car-makers by 1905. There's always room for competition. Take a look at what's happening right now in the auto-industry. Tesla came out of nowhere 125 years after the invention of the automobile and is doing pretty well. I bet there were a lot of people at Apple saying they couldn't compete in the music-player market, or the mobile-phone market, etc. In fact, if I look at the stats on freenas.org, we have about 350k visitors each month, with nearly 2% of them running FreeBSD and clearly using it to surf the internet. Sounds like a market to me! Seeing this I could not resist: http://windows.microsoft.com/en-US/windows/which-operating-system Long live the FreeBSD desktop, long live PC-BSD :P Let them prosper! Seriously, though. There are shortcomings, sure. But I tend to prefer the rock solid feature rich base with a somewhat shaky desktop experience than the other alternatives. Sure I would like to see a FreeBSD pulseaudio compatible sound server. And perhaps a template library for pinout configs for snd-cards. And native flash, although I say flash, no thank you Perhaps companies such as Netflix could release FreeBSD clients ahead of linux clients ;) I can also say that I recently got a friend to migrate from linux on both his home server as well as his laptop. He is very happy with the change. Cheers Andreas Cheers, -matt ___ 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 pulseaudio: I've had luck reading the raw PCM data from the /dev/dsp* devices, storing in postgres (bytea), then later playing back to /dev/dsp.. 'streaming' to another system (maybe pgsql as el intermedio?) would be pretty simple. In this scenario there is no Alsa requirement, which works for me :) -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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
question about pkgng
Hi, I updated my laptop to: # uname -a FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2 21:45:49 PST 2014 r...@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA amd64 Then updated ports to: # svn info Path: . Working Copy Root Path: /usr/ports URL: https://svn0.us-west.freebsd.org/ports/head Repository Root: https://svn0.us-west.freebsd.org/ports Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5 Revision: 342366 Node Kind: directory Schedule: normal Last Changed Author: eadler Last Changed Rev: 342366 Last Changed Date: 2014-02-02 12:48:28 -0800 (Sun, 02 Feb 2014) Then I ran 'pkg update' and 'pkg upgrade' But when I went to install a new port I received errors about boost, I used pkgng to update boost. # pkg install boost-all Updating repository catalogue The following 5 packages will be installed: Upgrading icu: 4.8.1.1_1 - 50.1.2 Installing boost-jam: 1.52.0_1 Installing boost-docs: 1.52.0 Upgrading boost-libs: 1.48.0_1 - 1.52.0_2 Installing boost-all: 1.52.0 The installation will require 190 MB more space 23 MB to be downloaded Proceed with installing packages [y/N]: y ... 1) Why didn't pkg upgrade bring boost from 1.48 to 1.52 ? 2) are other packages/ports suspect on this system? Things look different, but everything is great. Thank you, -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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: question about pkgng
On Sun, February 2, 2014 4:58 pm, Waitman Gobble wrote: Hi, I updated my laptop to: # uname -a FreeBSD akira.waitman.net 11.0-CURRENT FreeBSD 11.0-CURRENT #1: Sun Feb 2 21:45:49 PST 2014 r...@akira.waitman.net:/usr/obj/usr/src/sys/AKIRA amd64 Scratch this question, it turned out to be faster to just wipe out /usr/local and start fresh, in this case. Thanks -- Waitman Gobble San Jose California USA +1.510-830-7975 ___ 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
usb sound module loading
Hi, I have sound modules commented out in kernel config : # Sound support #device sound # Generic sound driver (required) #device snd_cmi # CMedia CMI8338/CMI8738 #device snd_csa # Crystal Semiconductor CS461x/428x #device snd_emu10kx # Creative SoundBlaster Live! and Audigy #device snd_es137x # Ensoniq AudioPCI ES137x #device snd_hda # Intel High Definition Audio #device snd_ich # Intel, NVidia and other ICH AC'97 Audio #device snd_via8233 # VIA VT8233x Audio #device snd_uaudio # USB Audio However, if i plug in a USB mic the following kernel modules are loaded automatically: 81 0x81e44000 f344 snd_uaudio.ko 92 0x81e54000 3dfdfsound.ko I do not seem to have any sound related options active in /boot/loader.conf or /etc/rc.conf This causes a problem when using ossv4.2 in ports, actually when a USB mic is plugged in ... (when using the oss v4.2 drivers, and you have them loaded into the kernel, ie 143 0x82086000 7b581osscore.ko 151 0x81e44000 4360 oss_cmpci.ko 161 0x81e49000 214a0oss_hdaudio.ko ) ... the machine instantly reboots. It would be good to either prevent sound.ko from loading, or have the machine use the oss4.2 driver instead. Any hints or suggestions appreciated. 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: usb sound module loading
On Sat, 29 Jun 2013 15:20:13 -0400, Gary Palmer gpal...@freebsd.org wrote: Check /etc/devd/usb.conf You don't mention which release you are using, but I suspect the USB config file for devd is autoloading the snd_uaudio module for you. Regards, Gary Thanks Gary. BTW I'm running FreeBSD 10.0-CURRENT #0 r252355 That /etc/devd/usb.conf file is the ticket! -- 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 Mon, 3 Jun 2013 07:55:54 -0700, Marcel Moolenaar mar...@xcllnt.net wrote:
On Jun 2, 2013, at 8:08 AM, Waitman Gobble uzi...@da3m0n8t3r.com =
wrote:
On Sun, 2 Jun 2013 10:43:35 -0400, Mark Johnston ma...@freebsd.org =
wrote:=20
=20
On Sat, Jun 01, 2013 at 12:54:14AM -0700, Waitman Gobble wrote:
=20
Hi,
=20
I'm getting a ton of core dumps from Python and any software that =
uses
Python,
ie has USE_PYTHON_BUILD=3Dyes in Makefile.
=20
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)
=20
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.
=20
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.
=20
Reverting r250991 and rebuilding libc solves the issue for me:
http://svnweb.freebsd.org/base?view=3Drevisionrevision=3D250991
=20
=20
=20
Thanks for the info, I appreciate it. I had a heck of a time getting
database/py-sqlite3 to build as well.=20
My workaround to get it installed was to change the Makefile in WRKSRC
Can you apply the following patch to /usr/ports/lang/python27, rebuild
python, re-install and then try to build databases/py-sqlite3 again?
Index: files/patch-Modules-_ctypes-libffi-fficonfig.py.in
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
--- files/patch-Modules-_ctypes-libffi-fficonfig.py.in (revision 0)
+++ files/patch-Modules-_ctypes-libffi-fficonfig.py.in (working copy)
@@ -0,0 +1,10 @@
+--- Modules/_ctypes/libffi/fficonfig.py.in.orig 2013-06-03 =
07:16:44.0 -0700
Modules/_ctypes/libffi/fficonfig.py.in2013-06-03 =
07:17:03.0 -0700
+@@ -1,7 +1,6 @@
+ ffi_sources =3D
+ src/prep_cif.c
+ src/closures.c
+-src/dlmalloc.c
+ .split()
+=20
+ ffi_platforms =3D {
It seems the root cause is a broken python build that accidentally
defines malloc(), free(), at al in _ctypes.so. A longer explanation
was sent to svn-src-head@ and svn-src-all@
I expect that the patch also fixes the other problems mentioned in
this thread. It would be great if people can verify this.
FYI,
--=20
Marcel Moolenaar
mar...@xcllnt.net
yes, that patch seems to work on my machine. After rebuilding Python with the
patch, I was able to install databases/py-sqlite3 without error, also the
www/midori port now builds and installs without crashing. I'll let you know if
I see any problems.
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
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 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
issue with libthr?
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. 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
Re: issue with libthr?
On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov kostik...@gmail.com
wrote:
You cannot even guess what is going on without a proper debug information.
Recompile and reinstall the libc/libthr/rtld with the debugging symbols
to get proper backtraces.
Anyway, two backtraces you demostrated, although not giving much useful
data, look very different. More, the second backtrace suggests that
there is either a bug in python interposing of malloc or memory corruption.
Thanks so much for your help, I'll rebuild with debug on next.
One thing I can get an instant crash is building midori, so I've been
experimenting to see where it's breaking.
It seems two things in the build script cause it wreck python:
the midori build reconstitutes a binary coded file within the script, it's a
file t.bz, which is uncompressed to become wafadmin,
inside that is a file Tools/config_c.py
there's
p.Utils.pproc.Popen in 'cmd_and_log' function
it returns:
p:
{'_child_created': True, 'returncode': 1, 'stdout': closed file 'fdopen',
mode 'rb' at 0x8037e92e0, 'stdin': None, 'pid': 62571, 'stderr': closed file
'fdopen', mode 'rb' at 0x8037e8b60, 'universal_newlines': False}
the '1' returncode causes build to fail..
Also, function def validate_c(self,kw)
*always* causes python to crash
for example, when it calls
conf.check (header_name='unistd.h')
..core dump...
Maybe this isn't useful information.. Next I'll rebuild with debug and see
about getting more info from gdb.
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 Sat, 1 Jun 2013 11:14:46 -0700 (PDT), Waitman Gobble uzi...@da3m0n8t3r.com wrote: On Sat, 1 Jun 2013 20:44:00 +0300, Konstantin Belousov kostik...@gmail.com wrote: You cannot even guess what is going on without a proper debug information. Recompile and reinstall the libc/libthr/rtld with the debugging symbols to get proper backtraces. Anyway, two backtraces you demostrated, although not giving much useful data, look very different. More, the second backtrace suggests that there is either a bug in python interposing of malloc or memory corruption. Thanks so much for your help, I'll rebuild with debug on next. Hello, Perhaps a better backtrace, from python2.7.core created when trying to install www/midori #0 thr_kill () at thr_kill.S:3 #1 0x000801184ecc in abort () at /usr/src/lib/libc/stdlib/abort.c:65 #2 0x00080464aca1 in free (mem=0x8065015b0) at /usr/ports/lang/python27/work/Python-2.7.5/Modules/_ctypes/libffi/src/dlmalloc.c:4350 #3 0x000800e4c1af in _pthread_mutex_destroy (mutex=value optimized out) at /usr/src/lib/libthr/thread/thr_mutex.c:273 #4 0x0008010e0def in closedir (dirp=0x803b2dda0) at /usr/src/lib/libc/gen/closedir.c:65 #5 0x0053d482 in posix_listdir (self=0x0, args=0x806425ae0) at ./../Modules/posixmodule.c:2543 #6 0x0057fa6e in PyCFunction_Call (func=0x801920080, arg=0x806425ae0, kw=0x0) at ./../Objects/methodobject.c:81 #7 0x004e40dd in call_function (pp_stack=0x7fff9388, oparg=1) at ./../Python/ceval.c:4021 #8 0x004dffcd in PyEval_EvalFrameEx (f=0x801a8f9a0, throwflag=0) at ./../Python/ceval.c:2666 snipped, complete backtrace at https://dx.burplex.com/backtrace.txt all ports have been rebuilt, lib_pkgchk returns no missing libraries. running FreeBSD 10.0-CURRENT #0 r251216: Sat Jun 1 03:21:48 PDT 2013 It seems that any program using Python crashes. also, Seamonkey. I do not so far notice any other issues with this system. It was working great until an update about a week ago. seamonkey (gdb) bt #0 thr_kill () at thr_kill.S:3 #1 0x00080316b585 in XRE_InstallX11ErrorHandler () from /usr/local/lib/seamonkey/libxul.so #2 0x000800f75286 in handle_signal (actp=value optimized out, sig=11, info=0x7fffb7f0, ucp=0x7fffb480) at /usr/src/lib/libthr/thread/thr_sig.c:237 #3 0x000800f74e89 in thr_sighandler (sig=11, info=value optimized out, _ucp=value optimized out) at /usr/src/lib/libthr/thread/thr_sig.c:182 #4 0x71d3 in ?? () #5 0x000800f74d70 in sigaction () at /usr/src/lib/libthr/thread/thr_sig.c:574 Previous frame inner to this frame (corrupt stack?) Current language: auto; currently asm 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
Re: issue with libthr?
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 ___ 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: Audio Hints, T520?
On Fri, 03 May 2013 22:22:01 -0700, Sean Bruno sean_br...@yahoo.com wrote: On Fri, 2013-05-03 at 22:03 -0700, Waitman Gobble wrote: what is the output of running the command 'mixer'? $ mixer Mixer vol is currently set to 95:95 Mixer pcm is currently set to 100:100 Mixer speaker is currently set to 100:100 Mixer mic is currently set to 100:100 Mixer rec is currently set to 67:67 Recording source: mic All looks well to me. Sean I agree. It looks like it should work. sorry not to have more info to help, After reading the man page for snd_hda and dev/snd/pcm/dsp.c src I don't think you *need* hints in /boot/loader.conf to make it work, but you can re-arrange 'pins' and set auto stuff, like plugging headphones in selects the device. i think. here's some stuff to check. I am *guessing* it's 'recording' from a different pin/device?? on this machine : [1070] syscntl hw.snd.default_unit hw.snd.default_unit: 3 [1071] dmesg | grep pcm3 pcm3: Realtek ALC887 (Rear Analog) at nid 20 and 24,26 on hdaa1 [1072] sysctl -a | grep nid20 dev.hdaa.1.nid20: pin: Line-out (Green Jack) dev.hdaa.1.nid20_config: 0x01014410 as=1 seq=0 device=Line-out conn=Jack ctype=1/8 loc=Rear color=Green misc=4 dev.hdaa.1.nid20_original: 0x01014410 as=1 seq=0 device=Line-out conn=Jack ctype=1/8 loc=Rear color=Green misc=4 [1073] sysctl -a | grep nid24 dev.hdaa.1.nid24: pin: Mic (Pink Jack) dev.hdaa.1.nid24_config: 0x01a19c40 as=4 seq=0 device=Mic conn=Jack ctype=1/8 loc=Rear color=Pink misc=12 dev.hdaa.1.nid24_original: 0x01a19c40 as=4 seq=0 device=Mic conn=Jack ctype=1/8 loc=Rear color=Pink misc=12 I think there's probably a pink jack on the back of the machine where i can plug up a mic. a thought, did you already experiment to see if you can record something from oss /dev/dsp devices? I browsed through the source but I don't understand, at the moment, how to 'know' which /dev/dsp maps to pcm. [1044] ls /dev/dsp* /dev/dsp0.1 /dev/dsp2.1 /dev/dsp4.1 /dev/dsp1.1 /dev/dsp3.1 /dev/dsp5.1 (based on previous matthias post) [1045] dd if=/dev/dspN of=/tmp/bite [1046] cat /tmp/bite /dev/dspOUT_DEVICE -- 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: Audio Hints, T520?
On Fri, 03 May 2013 21:14:16 -0700, Sean Bruno sean_br...@yahoo.com wrote: --=-0ChyxBdnPLit6KyXtgKU Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Speaker/headphones working great on Current. Was trying to get the microphone working, but it seems to not quite be working. =20 By not working, there is no audio detected when recording. Is there something in here that looks like a thing that I should adjust? http://people.freebsd.org/~sbruno/t520_sysctl_hdaa.txt Sean --=-0ChyxBdnPLit6KyXtgKU Content-Type: application/pgp-signature; name=signature.asc Content-Description: This is a digitally signed message part -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.13 (FreeBSD) iQEcBAABAgAGBQJRhIsTAAoJEBkJRdwI6BaHBhQIAJOFCtEILHpVtGV8F41SOnF+ umUkReVGMGvTR1wgcHWlag/gM4rB9PXksMSYsrS9/3O6RorPMVtsWEivTOscn+eC FBwhco/UsuvKB9u8QXLffj33vkHChd1aisLZaLxhRZ0GNtrqF9oPD+NYX0xrN0+S xk6a5m7+wFGOrNILPLPjI20Q3AKJ226WZiaeciOnP37Z5uszVHu/iLfz81XSX79U rCDN7uFo1j4OFPQbHHZy+lc6shdBu8W9LAiQdcLfgeNJMug5VgctWwQedjvRI+PS Kw7rLx4rmClIKOA0/in0yxeQsuBt8b92JSEoe3XFiIYFKDxxPN67Fw8UGZDoK0A= =cUpg -END PGP SIGNATURE- --=-0ChyxBdnPLit6KyXtgKU-- Hi Sean, I'm not an audio recording expert, but something to check: what is the output of running the command 'mixer'? also, there are three or four inputs marked 'mute=1', have to select the proper input for recording and it can't be muted. -- 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: rebooting nvidia + keyboard issues
On Mon, 08 Apr 2013 05:52:31 -0700, Sean Bruno seanwbr...@gmail.com wrote: patch was applied yesterday-ish to ports. Sean Awesome thanks for the info, trying it out now. thought it was the .32 patches. I didn't realize it's the updated 310.44 driver. -- 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: RE: rebooting nvidia + keyboard issues
On Wed, 3 Apr 2013 10:35:47 +0100, Thomas Sparrevohn thomas.sparrev...@btinternet.com wrote: I have had the same problem - it seems like a sysctl call provokes a overrun in a strlen call. It is not reproducible with a GENERIC kernel with debugging in my case. However a simple workaround is to compile nvidia-driver with gcc. Thanks for the info, it does seem to be working when compiled with base gcc. no reboots yet. OpenGL works again, yay. and a day after I read about AMD opening up the UVD driver, i read about nvidia opening up 3D tegra. GLEW version 1.9.0 Reporting capabilities of display :0.0, visual 0x2b Running on a GeForce GT 220/PCIe/SSE2 from NVIDIA Corporation OpenGL version 3.3.0 NVIDIA 310.32 is supported BTW looks like a new version is available: FreeBSD Display Driver â x86 Version: 313.30 Release Date: 2013.04.02 Operating System: FreeBSD x86 -- 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: RE: rebooting nvidia + keyboard issues
On Wed, 3 Apr 2013 11:07:55 -0700, Adrian Chadd adr...@freebsd.org wrote: Hi, can you guys please ensure a PR is filed with all the information you've just included? the clang team would likely love to have this much information in a bug report. Thanks! adrian OK is it good to know the two ports that i noticed didn't build with clang? Unfortunately I did not keep track of the ports, however I can make a script to iterate through all installed ports and do 'make' and see where it stops. OR Maybe there's an easier way. I'll try the nvidia port in a bit, but I think Thomas already has a good idea of what's going on. -- 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: RE: rebooting nvidia + keyboard issues
On Wed, 3 Apr 2013 10:35:47 +0100, Thomas Sparrevohn thomas.sparrev...@btinternet.com wrote: I have had the same problem - it seems like a sysctl call provokes a overrun in a strlen call. It is not reproducible with a GENERIC kernel with debugging in my case. However a simple workaround is to compile nvidia-driver with gcc. -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Waitman Gobble Sent: 31 March 2013 08:25 To: curr...@freebsd.org Subject: rebooting nvidia + keyboard issues Hi, After updating my machine tonight with uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat Mar 30 21:53:14 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 I noticed the machine rebooting randomly every 20 seconds to 5 minutes. Disabling the nvidia driver seems to fix the problem, and I was able to update after applying ports/177459 patch. The updated nvidia driver seems to have solved the rebooting issue. (it could (also?) be related to linux.ko?) If people are using the nvidia driver and are experiencing a constant reboot issue, it might be good to pop in that patch ASAP. The problem I am noticing now is keyboard related. Booting to single user mode, I cannot type anything at the login prompt with an attached USB keyboard. However in single user mode a PS2 keyboard will allow me to login. I would not say it's not working.. the keyboard functions fine until hitting the login prompt. There are no errors and everything appears to be working fine, however I cannot login. Numlock key lights on and off when pressed. Also, if I boot into multi user mode, I cannot type anything at the login prompt when a PS2 keyboard is attached. But the USB keyboard will work in mutli user mode. Thank you, -- Waitman Gobble San Jose California USA ___ 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 Thank you for the information, I'll give it a try and see what happens. I noticed two other ports that don't even seem to build with clang, but generally everything else seems to be working. I noticed a previous message from a day or two ago regarding gcc and nvidia, but I lost the message. I'm in the middle of moving my mail system to a 'more' horizontally based system, so it's kind of like building a boat around you while floating down a river. Anyhow, I read an article this morning about AMD opening up drivers, that sounds cool, going to check it out. -- 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
rebooting nvidia + keyboard issues
Hi, After updating my machine tonight with uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248937: Sat Mar 30 21:53:14 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 I noticed the machine rebooting randomly every 20 seconds to 5 minutes. Disabling the nvidia driver seems to fix the problem, and I was able to update after applying ports/177459 patch. The updated nvidia driver seems to have solved the rebooting issue. (it could (also?) be related to linux.ko?) If people are using the nvidia driver and are experiencing a constant reboot issue, it might be good to pop in that patch ASAP. The problem I am noticing now is keyboard related. Booting to single user mode, I cannot type anything at the login prompt with an attached USB keyboard. However in single user mode a PS2 keyboard will allow me to login. I would not say it's not working.. the keyboard functions fine until hitting the login prompt. There are no errors and everything appears to be working fine, however I cannot login. Numlock key lights on and off when pressed. Also, if I boot into multi user mode, I cannot type anything at the login prompt when a PS2 keyboard is attached. But the USB keyboard will work in mutli user mode. Thank you, -- Waitman Gobble San Jose California USA ___ 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: reservation of n, n (3) failed
John Baldwin j...@freebsd.org wrote .. On Thursday, March 14, 2013 1:41:04 am Waitman Gobble wrote: Hi, I swapped out the CPU on this machine today, I don't recall seeing these messages previously: acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfcd (3) failed You can ignore those. acpi is trying to reserve the addresses used for RAM as system resources, but the ram0 driver has already done so. -- John Baldwin Hi, Thank you, I appreciate the info. -- Waitman Gobble San Jose California USA ___ 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
reservation of n, n (3) failed
Hi, I swapped out the CPU on this machine today, I don't recall seeing these messages previously: acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfcd (3) failed Does anyone have an idea about what this refers to? Here's the boot log. uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 FreeBSD clang version 3.2 (tags/RELEASE_32/final 170710) 20121221 CPU: AMD FX(tm)-8350 Eight-Core Processor(4027.01-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x600f20 Family = 0x15 Model = 0x2 Stepping = 0 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x3e98320bSSE3,PCLMULQDQ,MON,SSSE3,FMA,CX16,SSE4.1,SSE4.2,POPCNT,AE SNI,XSAVE,OSXSAVE,AVX,F16C AMD Features=0x2e500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM AMD Features2=0x1ebbfffLAHF,CMP,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,I BS,XOP,SKINIT,WDT,LWP,FMA4,b17,NodeId,TBM,Topology,b23,b24 Standard Extended Features=0x8 TSC: P-state invariant, performance statistics real memory = 34359738368 (32768 MB) avail memory = 33082753024 (31550 MB) Event timer LAPIC quality 400 ACPI APIC Table: GBTGBTUACPI FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 ioapic0: Changing APIC ID to 8 ioapic0 Version 2.1 irqs 0-23 on motherboard acpi0: GBT GBTUACPI on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, bfcd (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 cpu6: ACPI CPU on acpi0 cpu7: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff irq 0,8 on acpi0 Timecounter HPET frequency 14318180 Hz quality 950 atrtc0: AT realtime clock port 0x70-0x73 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-safe frequency 3579545 Hz quality 850 Thank you, -- Waitman Gobble San Jose California USA ___ 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
libtool/ld shared libraries
Hi, I'm trying to figure out why my 10.0-CURRENT machine is having issues producing *.so shared library... [659] uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no creating libtool appending configuration tag CXX to libtool checking whether the clang++ linker (/usr/bin/ld) supports shared libraries... no checking whether the clang++ linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported [660] pkg version | grep libtool libtool-2.4.2 = (as example) my 9.1-STABLE machine is working OK. # uname -a FreeBSD do.burplex.com 9.1-STABLE FreeBSD 9.1-STABLE #0 r246923M: Sun Feb 17 18:30:48 PST 2013 da3m0n8...@do.burplex.com:/usr/obj/usr/src/sys/KAGISO amd64 checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd9.1 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes # pkg_info | grep libtool libtool-2.4.2 Generic shared library support script I kind of remember running into this in the past but I can't recall the solution.. Help or pointers appreciated! Thank you, -- Waitman Gobble San Jose California USA ___ 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: libtool/ld shared libraries
Jim Harris jimhar...@freebsd.org wrote .. On Tue, Mar 12, 2013 at 3:44 PM, Waitman Gobble uzi...@da3m0n8t3r.comwrote: Hi, I'm trying to figure out why my 10.0-CURRENT machine is having issues producing *.so shared library... [659] uname -a FreeBSD dx.burplex.com 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r248165: Mon Mar 11 18:20:30 PDT 2013 r...@dx.burplex.com:/usr/obj/usr/src/sys/FURAHA amd64 checking dynamic linker characteristics... no checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... no creating libtool appending configuration tag CXX to libtool checking whether the clang++ linker (/usr/bin/ld) supports shared libraries... no checking whether the clang++ linker (/usr/bin/ld) supports shared libraries... no checking dynamic linker characteristics... no checking how to hardcode library paths into programs... unsupported [660] pkg version | grep libtool libtool-2.4.2 = (as example) my 9.1-STABLE machine is working OK. # uname -a FreeBSD do.burplex.com 9.1-STABLE FreeBSD 9.1-STABLE #0 r246923M: Sun Feb 17 18:30:48 PST 2013 da3m0n8...@do.burplex.com:/usr/obj/usr/src/sys/KAGISO amd64 checking whether the cc linker (/usr/bin/ld) supports shared libraries... yes checking dynamic linker characteristics... freebsd9.1 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... yes checking if libtool supports shared libraries... yes # pkg_info | grep libtool libtool-2.4.2 Generic shared library support script I kind of remember running into this in the past but I can't recall the solution.. I've run into this before too. I believe it was the configure script interpreting FreeBSD 10 as FreeBSD 1, and therefore thinking shared library support wasn't available. Regards, -Jim ___ 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 oh, that's exactly what's going on, thanks! ie, freebsd1*) dynamic_linker=no ;; ld_shlibs_CXX=no etc -- Waitman Gobble San Jose California USA ___ 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: Why NOT using FreeBSD? Re: ports/169581: editors/libreoffice:
Baptiste Daroussin b...@freebsd.org wrote .. On Tue, Jul 03, 2012 at 10:59:03AM +0200, Hartmann, O. wrote: On 07/02/12 08:09, Sayetsky Anton wrote: I will test libreoffice build on 8.3-RELEASE today or tomorrow. I have both gstreamer and boost installed now. We use FreeBSD 9.0STABLE and FreeBSD 10.0-CURRENT (both amd64). devel/boost-lib gets reeled in now by editors/libreoffice by default, so it doesn't need to be installed explicitely. I saw a patch flushed in yesterday, submitted by bapt@. This patch also installs LLVM/CLANG from the ports - with ASSERTS deactivated. I have on both systems, FreeBSD 9 and 10, LLVM/CLANG 3.1 as the standard backend compiler, I guess this version has the suspected ASSERTS activated. Why another LLVM port? We already have LLVM/CLANG in the base system (9 and 19). If the ASSERTS proble is the cause for breaks reported on the list and elsewhere on the net, why isn't the maintainer still stuck on the old version? I just managed it to install the prior version on broken systems and was really lucky having LibreOffice working again. But the other day I was bothered by the next non-working version and now I have lots of notebooks remaining with NO LibreOffice on FBSD 9-STABLE. This is not what I expect from quality securing! It is simply a mess and definitely another reason and point for the thread Why NOT using FreeBSD. ___ 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 sure libreoffice is so easy to port... /me officially gives up with that libreoffice port, open for new volunteers bapt LibreOffice is pretty massive. I've spent much of the day working on building 3.6.0.0 on 10-CURRENT with gcc48 and openjdk6. I have been using AbiWord but the word-wrap is crazy. Try writing a novel with weird word breaks and moving paragraphs and it's driving me koo-koo pants. Also it does not appear to do right-left opposing margins. I was interested in building AbiWord dev on my machine but the dev team seems very MS-centric, much of a chore using their HEAD. Gnumeric works great, I have successfully interoperated, no urgent issues. on to LibreOffice... I can create and submit a port for libreoffice 3.6.0.0 if anyone is interested in trying the beta version. Might take a few days. Still working on it. At the moment, there is one small change to configure.in. It stubbornly demands libclucene-core instead of libclucene. Most of the libraries are built from ports, then using --with-system-foo in autogen.sh -- Waitman Gobble San Jose California USA -- Waitman Gobble San Jose California USA ___ 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: Java and NIO?
g...@freebsd.org wrote .. Howdy, Can someone tell me if anyone is working on this Java NIO bug? http://freebsd.1045724.n5.nabble.com/i386-159787-openjdk-1-6-nio-muti-thread-bug-td4700530.html I would like to avoid using Linux just to run Zookeeper: http://zookeeper-user.578899.n2.nabble.com/What-s-the-problem-with-nio-on-FreeBSD-td5208183.html Best, George ___ 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 Hi George, There is/was a patch from David Xu http://lists.freebsd.org/pipermail/freebsd-java/2010-August/008747.html maybe this fixes it? also looks like New I/O was updated in jdk7... but would have to check it out to see if issue still exists.. -- Waitman Gobble San Jose California USA ___ 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
