Re: GCC update for testing
On (17/05/2012 10:44), Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log Could you check if patch fixes this issue: http://marc.info/?l=freebsd-hackersm=132348021530691w=2 I've disabled gcc from base locally since discovering it. Thanks, Gleb. It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: $ make cc -c -O2 -Os -pipe -fno-strict-aliasing -march=athlon64 -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../cam/scsi/scsi_sa.c cc1: warnings being treated as errors ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_enabled' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2727: warning: 'current_density' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2727: note: 'current_density' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here ../../../cam/scsi/scsi_sa.c:2728: warning: 'current_speed' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2728: note: 'current_speed' was declared here ../../../cam/scsi/scsi_sa.c:2725: warning: 'current_blocksize' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:2725: note: 'current_blocksize' was declared here *** Error code 1 ... Other stuff I tested (Apache OpenOffice) builds fine. cheers, Pedro. ___ 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: Chrome crashing system (amd64-10.0-CURRENT)
On Thu, May 17, 2012 at 04:12:15PM -0700, Evan Martin wrote: On Thu, May 17, 2012 at 4:08 PM, Conrad J. Sabatier conr...@cox.net wrote: Thanks. I tried those, and it still locked up. I finally just moved away ~/.config/chromium, and it started up OK. Luckily, I was able to restore pretty much everything from my synced data. It's a little surprising to me that a userspace app is able to nuke your system, but perhaps the bug is just something mundane like out of control memory allocations and it's just swapping. I just discovered while poking around again under ~/.config that my old chromium directory (that is, the directory file itself) had somehow become corrupted. This was most likely what was causing chrome to go berserk before. I'm using SU+J here, and this problem wasn't detected by fsck before. I only discovered it this evening when, after having already deleted all of the files in the directory, rmdir failed with the error message Directory not empty. After booting single-user and running fsck twice (to force it not to use the journal), looks like everything's back to normal now. -- Conrad J. Sabatier conr...@cox.net ___ 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: r235510: recent buildworld fail
On 05/17/12 00:24, Dimitry Andric wrote:
On 2012-05-16 20:48, O. Hartmann wrote: When compiling world (make
buildworld) I receive the bewlo error, which
seems very strange!
The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box.
...
/usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol
`_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in
/usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in
/usr/obj/usr/src/tmp/usr/lib/libstdc++.so
looks like a mixed up between CLANG and legacy GCC 4.2.1, as far as I
remember this error was typical for a mismatch.
Where did you read that? In any case, I think this may be a problem
with one of the settings in your make.conf, not those in src.conf,
specifically CFLAGS or CXXFLAGS. Can you please post those?
There is nothing special about the setting. I present to you the
/etc/make.conf as used when it fails. Hope its shwoing something useful.
I fear there has been something went wrong on one of the prior
installations ...
Regards,
Oliver
# $FreeBSD: src/share/examples/etc/make.conf,v 1.279 2007/01/17 12:43:06 des
Exp $
#
# NOTE: Please would any committer updating this file also update the
# make.conf(5) manual page, if necessary, which is located in
# src/share/man/man5/make.conf.5.
#
# /etc/make.conf, if present, will be read by make (see
# /usr/share/mk/sys.mk). It allows you to override macro definitions
# to make without changing your source tree, or anything the source
# tree installs.
#
# This file must be in valid Makefile syntax.
#
# There are additional things you can put into /etc/make.conf.
# You have to find those in the Makefiles and documentation of
# the source tree.
#
# Note, that you should not set MAKEOBJDIRPREFIX or MAKEOBJDIR
# from make.conf (or as command line variables to make).
# Both variables are environment variables for make and must be used as:
#
# env MAKEOBJDIRPREFIX=/big/directory make
#
#
# The CPUTYPE variable controls which processor should be targeted for
# generated code. This controls processor-specific optimizations in
# certain code (currently only OpenSSL) as well as modifying the value
# of CFLAGS to contain the appropriate optimization directive to gcc.
# The automatic setting of CFLAGS may be overridden using the
# NO_CPU_CFLAGS variable below.
# Currently the following CPU types are recognized:
# Intel x86 architecture:
# (AMD CPUs) opteron athlon64 athlon-mp athlon-xp athlon-4
# athlon-tbird athlon k8 k6-3 k6-2 k6 k5
# (Intel CPUs)core2 core nocona pentium4m pentium4 prescott
# pentium3m pentium3 pentium-m pentium2
# pentiumpro pentium-mmx pentium i486 i386
# (Via CPUs) c3 c3-2
# Alpha/AXP architecture: ev67 ev6 pca56 ev56 ev5 ev45 ev4
# AMD64 architecture: opteron, athlon64, nocona, prescott, core2
# Intel ia64 architecture: itanium2, itanium
#
# (?= allows to buildworld for a different CPUTYPE.)
#
#NO_CLANG=YES
CPUTYPE?=native
#NO_CPU_CFLAGS= # Don't add -march=cpu to CFLAGS automatically
#NO_CPU_COPTFLAGS= # Don't add -march=cpu to COPTFLAGS automatically
#
# CFLAGS controls the compiler settings used when compiling C code.
# Note that optimization settings other than -O and -O2 are not recommended
# or supported for compiling the world or the kernel - please revert any
# nonstandard optimization settings to -O or -O2 -fno-strict-aliasing
# before submitting bug reports without patches to the developers.
#
# Compiling with -fstrict-aliasing optimization breaks some [notable] ports.
# GCC turns on -fstrict-aliasing optimization at all levels above -O[1], so
# explicitly turn it off when using compiling with the -O2 optimization level.
#
#CFLAGS= -O2 -fno-strict-aliasing -pipe
CFLAGS+= -O2 -fno-strict-aliasing -pipe
#
# CXXFLAGS controls the compiler settings used when compiling C++ code.
# Note that CXXFLAGS is initially set to the value of CFLAGS. If you wish
# to add to CXXFLAGS value, += must be used rather than =. Using =
# alone will remove the often needed contents of CFLAGS from CXXFLAGS.
#
#CXXFLAGS+= -fconserve-space
#
# MAKE_SHELL controls the shell used internally by make(1) to process the
# command scripts in makefiles. Three shells are supported, sh, ksh, and
# csh. Using sh is most common, and advised. Using ksh *may* work, but is
# not guaranteed to. Using csh is absurd. The default is to use sh.
#
#MAKE_SHELL?=sh
#
# BDECFLAGS are a set of gcc warning settings that Bruce Evans has suggested
# for use in developing FreeBSD and testing changes. They can be used by
# putting CFLAGS+=${BDECFLAGS} in /etc/make.conf. -Wconversion is not
# included here due to compiler bugs, e.g., mkdir()'s mode_t argument.
#
#BDECFLAGS= -W -Wall -ansi -pedantic -Wbad-function-cast -Wcast-align \
# -Wcast-qual -Wchar-subscripts -Winline \
# -Wmissing-prototypes -Wnested-externs -Wpointer-arith \
# -Wredundant-decls
Re: SUJ file system corruption.
On 13. May 2012, at 22:35 , Tim Kientzle wrote: FYI: Saw a crash due to filesystem corruption when running SUJ. This is on a ARM AM335x system (BeagleBone) that is still pretty experimental, so I certainly cannot rule out other problems, but in case it means something to someone, here's the scenario: Reset the board to reboot (which is routine for these small embedded boards) and when it came back up it went through SUJ recovery, and then a little later the kernel panicked with this stack trace: rm: /var/run/dmesg.boot: Bad file descriptor panic: ffs_write: type 0xc1e86660 0 (0,1024) Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ 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: r235510: recent buildworld fail
On 05/17/12 00:24, Dimitry Andric wrote: On 2012-05-16 20:48, O. Hartmann wrote: When compiling world (make buildworld) I receive the bewlo error, which seems very strange! The error occured out of the blue on a FreeBSD 10.0-CURRENT/amd64 box. ... /usr/obj/usr/src/tmp/usr/bin/ld: Warning: size of symbol `_ZNSi6ignoreEv@GLIBCXX_3.4' changed from 243 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so to 211 in /usr/obj/usr/src/tmp/usr/lib/libstdc++.so looks like a mixed up between CLANG and legacy GCC 4.2.1, as far as I remember this error was typical for a mismatch. Where did you read that? In any case, I think this may be a problem with one of the settings in your make.conf, not those in src.conf, specifically CFLAGS or CXXFLAGS. Can you please post those? I tried to build the system with the legacy gcc and it turns out to fail like this: mkdep -f .depend -a -I/usr/src/lib/libc++/../../contrib/libc++/include -I/usr/src/lib/libc++/../../contrib/libcxxrt -DLIBCXXRT -std=c++0x /usr/src/lib/libc++/../../contrib/libc++/src/algorithm.cpp /usr/src/lib/libc++/../../contrib/libc++/src/bind.cpp /usr/src/lib/libc++/../../contrib/libc++/src/chrono.cpp /usr/src/lib/libc++/../../contrib/libc++/src/condition_variable.cpp /usr/src/lib/libc++/../../contrib/libc++/src/debug.cpp /usr/src/lib/libc++/../../contrib/libc++/src/exception.cpp /usr/src/lib/libc++/../../contrib/libc++/src/future.cpp /usr/src/lib/libc++/../../contrib/libc++/src/hash.cpp /usr/src/lib/libc++/../../contrib/libc++/src/ios.cpp /usr/src/lib/libc++/../../contrib/libc++/src/iostream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/locale.cpp /usr/src/lib/libc++/../../contrib/libc++/src/memory.cpp /usr/src/lib/libc++/../../contrib/libc++/src/mutex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/new.cpp /usr/src/lib/libc++/../../contrib/libc++/src/random.cpp /usr/src/lib/libc++/../../contrib/libc++/src/regex.cpp /usr/src/lib/libc++/../../contrib/libc++/src/stdexcept.cpp /usr/src/lib/libc++/../../contrib/libc++/src/string.cpp /usr/src/lib/libc++/../../contrib/libc++/src/strstream.cpp /usr/src/lib/libc++/../../contrib/libc++/src/system_error.cpp /usr/src/lib/libc++/../../contrib/libc++/src/thread.cpp /usr/src/lib/libc++/../../contrib/libc++/src/typeinfo.cpp /usr/src/lib/libc++/../../contrib/libc++/src/utility.cpp /usr/src/lib/libc++/../../contrib/libc++/src/valarray.cpp cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x cc1plus: error: unrecognized command line option -std=c++0x mkdep: compile failed *** [.depend] Error code 1 Stop in /usr/src/lib/libc++. *** [depend] Error code 1 Stop in /usr/src/lib. *** [lib__L] Error code 1 Stop in /usr/src. *** [libraries] Error code 1 Stop in /usr/src. *** [_libraries] Error code 1 Stop in /usr/src. *** [buildworld] Error code 1 ___ 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: SUJ file system corruption.
On Fri, May 18, 2012 at 10:18:47AM +, Bjoern A. Zeeb wrote: On 13. May 2012, at 22:35 , Tim Kientzle wrote: FYI: Saw a crash due to filesystem corruption when running SUJ. This is on a ARM AM335x system (BeagleBone) that is still pretty experimental, so I certainly cannot rule out other problems, but in case it means something to someone, here's the scenario: Reset the board to reboot (which is routine for these small embedded boards) and when it came back up it went through SUJ recovery, and then a little later the kernel panicked with this stack trace: rm: /var/run/dmesg.boot: Bad file descriptor panic: ffs_write: type 0xc1e86660 0 (0,1024) Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? on stable/9 and amd64 as of 2-3 months ago i am seeing these panics every time (fortunately very rare) the system needs to recover from a crash. On the subsequent reboot the system keeps crashing randomly as soon as i load disk-intensive applications (often browsers or most things that run under X11, but sometimes the crashes are even before that. I then need to reboot in single user and do a manual fsck. I tried to run fsck using the journal, but after it completes a subsequent non-journal fsck finds errors. In the end, i am not sure if it makes sense to keep the SU+J active on the disk, i am so afraid of crashes that i don't even dare anymore to run experimental kernels or modules on my main workstation! cheers luigi ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: SUJ file system corruption.
On 18. May 2012, at 10:57 , Luigi Rizzo wrote: On Fri, May 18, 2012 at 10:18:47AM +, Bjoern A. Zeeb wrote: On 13. May 2012, at 22:35 , Tim Kientzle wrote: FYI: Saw a crash due to filesystem corruption when running SUJ. This is on a ARM AM335x system (BeagleBone) that is still pretty experimental, so I certainly cannot rule out other problems, but in case it means something to someone, here's the scenario: Reset the board to reboot (which is routine for these small embedded boards) and when it came back up it went through SUJ recovery, and then a little later the kernel panicked with this stack trace: rm: /var/run/dmesg.boot: Bad file descriptor panic: ffs_write: type 0xc1e86660 0 (0,1024) Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? on stable/9 and amd64 as of 2-3 months ago i am seeing these panics Hmm, if you are on a 2-3 month old stable/9 please update; there have been quite a few su+j bug fixes. If it means you have been seeing them for the 2-3 last months and are on an up-to-date stable/9 please get the attention of Kirk, Jeff and maybe Peter Holm and Kostik. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: FreeBSD 10 prognostication...
Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to jettison two thirds of its code base and start from scratch. Apple is not involved in FreeBSD development. No Mac OS X or Darwin version includes FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). Troll *is* right there in the name! DES -- Dag-Erling Smørgrav - d...@des.no (mailto:d...@des.no) ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus
pwd_mkdb -p /etc/master.passwd Cheers, Matthew Dr Matthew J Seaman MA, D.Phil. That did it! Now I can login as nonroot and startx. I found pwd_mkdb in my searching, but would not have known to use '-p'. I might have done pwd_mkdb /etc/master.passwd from Doug Barton do...@freebsd.org: Carefully? :) Seriously ... always use the -P option, and/or add PRESERVE_FILES in your mergemaster rc file. Watch the changes carefully. If you have to, do the updates in more than one pass using the -r option for subsequent runs. Do the simple ones first, then go back and do the ones that you have to think harder about. I recommend against using the -U option. It's not rocket science, it's just like any other system administration task, it requires careful attention. Doug That seems like a good idea, using -P option to be able to go back to something good if one screws up. From 'man mergemaster': The mergemaster utility is a Bourne shell script which is designed to aid you in updating the various configuration and other files associated with FreeBSD. It is HIGHLY recommended that you back up your /etc directory before beginning this process. So I could make a second backup of /etc before the second mergemaster invocation, after installworld. There are lots of files to merge/edit, and one can easily become tired and make mistakes. We're only human and not infallible. Tom ___ 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: ACPI 'driver bug: Unable to set devclass'
On Thursday, May 17, 2012 11:33:56 am Andriy Gapon wrote: on 17/05/2012 17:05 John Baldwin said the following: On Wednesday, May 16, 2012 4:07:43 pm John Baldwin wrote: Oh, whoops. Actually, the right way to do this I think is bus_hint_device_unit() (and/or, not make the unit number in cpuX mean anything at all, but use a separate ivar to track what PCPU_GET(cpuid) a given cpuX device corresponds to). I think the last approach is really the right way to fix this. I haven't been able to try this yet, but I have a first cut at www.freebsd.org/~jhb/patches/acpi_cpu.patch The patch has not been compile-tested? :) I've updated it with a run-tested version. -- John Baldwin ___ 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: updating from r231158 to 234465: mounting from ufs:/dev/ad4s1a failed with error 19
On Wednesday, May 16, 2012 11:30:19 am Anton Shterenlikht wrote: er.. yes, of course it helped. My problem was that I couldn't boot. So, I presumed the very existence of dmesg.boot showed that your patches (both of them) work fine. But, sorry, I could've been more explicit. All seems to work, including sound and wireless. Hmm. Can you try one more thing. Can you boot an unmodified kernel (no patches) but set 'hw.pci.enable_io_modes=0' from the loader? -- John Baldwin ___ 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: GCC update for testing
On 05/18/12 02:08, Gleb Kurtsou wrote: On (17/05/2012 10:44), Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log Could you check if patch fixes this issue: http://marc.info/?l=freebsd-hackersm=132348021530691w=2 I've disabled gcc from base locally since discovering it. Thanks, Gleb. No joy :(. Sorry: ./gcc-test1 src2.c:16:test_fail: Assertion failed: addr-sin_addr.s_addr == ntohl(INADDR_ANY) Abort ___ 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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Tue, May 1, 2012 at 8:18 PM, Gustau Pérez i Querol gpe...@entel.upc.edu wrote: So the problem seems to be not related to jemalloc or malloc. As the experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem has do to with some differences between head and stable. When we get more hints where the problem is, I will post them in a new thread in freebsd-current@. Gus has been away for a while, but before disappearing he found a workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So I had a look around, and found this NetBSD bug report: http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-atexit_mutex-should-be-fully-recursive.html Since qdbus crashes after exit(3) here too, that might be an explanation. Or, at least, something related. kib@ and kan@ are CCed as per avg@ suggestion. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: Upgrade from source to RC1: problems with /etc : lost users and dbus: resent by mistake
pwd_mkdb -p /etc/master.passwd Cheers, Matthew Dr Matthew J Seaman MA, D.Phil. That did it! Now I can login as nonroot and startx. (snip) Sorry, I didn't mean to send this old message again! I changed this message to send to freebsd-stable list, saved under a different name, but accidentally sent the old message instead of the new one! Tom ___ 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: GCC update for testing
Hi again; On 05/17/12 11:44, Dimitry Andric wrote: On 2012-05-17 17:44, Pedro Giffuni wrote: Hi; I took a bunch of patches that were merged into the GCC 4.1 branch (under GPLv2) and prepared a patch for merging them into our base gcc. These are supposed to be bug fixes only. You can get the patch here: http://people.freebsd.org/~pfg/patches/patch-contrib-gcc And, for those really interested, the log is here: http://people.freebsd.org/~pfg/patches/gcc41-pr-log It may be my imagination but the patch seems to be causing more warnings than usual and it breaks the kernel here: ... ../../../cam/scsi/scsi_sa.c: In function 'samount': ../../../cam/scsi/scsi_sa.c:1887: warning: 'comp_supported' may be used uninitialized in this function ../../../cam/scsi/scsi_sa.c:1888: warning: 'write_protect' may be used uninitialized in this function These warnings seem wrong, upon casual inspection of the code. In any case, if you compile the same file with gcc 4.7, they don't appear. :) Any idea which particular gcc fix is responsible for them? As a workaround, we could set all those variable to some reasonable value, but that feels like a cheap trick to me... But I'd rather just not import the fix that causes those warnings. Ugh... It appears the patch was fine after all: the warnings were somehow triggered by optimizations in my /etc/make.conf file. I will test it further before committing. Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
RE: FreeBSD 10 prognostication...
Its not that bad. PCBSD (with FreeBSD 9.0 inside) has a relatively decent GUI setup, with several viable GUI choices. Oleg -Original Message- From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd-curr...@freebsd.org] On Behalf Of Hamell, Rick (SPARQ) Sent: Thursday, May 17, 2012 8:23 PM To: Vance Siemens Cc: Dag-Erling Smørgrav; freebsd-current@freebsd.org; freebsd-c...@freebsd.org; Vincent Hoffman Subject: Re: FreeBSD 10 prognostication... What, 8bit color ANSI isn't GUI enough? But seriously, it feels like it works even worse then it did a decade ago. Rick Hamell Sent from my iPhone On May 17, 2012, at 4:20 PM, Vance Siemens vance.siem...@gmail.com wrote: Eh, sorry. I got excited at the prospect of downloading FreeBSD from the App Store and having the installer just work in a modern GUI. You have to admit, FreeBSD is lacking in this area. It would be a boon. On Wed, May 16, 2012 at 7:18 AM, Dag-Erling Smørgrav d...@des.no wrote: Vance Siemens vance.siem...@gmail.com writes: Can you share a brief overview of what's wrong with it? Umm, it's about as factual as The Onion, except not as funny. FreeBSD never had to jettison two thirds of its code base and start from scratch. Apple is not involved in FreeBSD development. No Mac OS X or Darwin version includes FreeBSD. FreeBSD and Mac OS X will never merge. FreeBSD was never acquired by WinDriver Systems or by anyone else, although a company named WindRiver Systems (makers of the embedded operating system VxWorks, not of Windows video drivers) did at one point acquire BSDI, which had previously acquired Walnut Creek CD-ROM, which was heavily involved in the early history of both FreeBSD and Slackware Linux. The remains of Walnut Creek CD-ROM and BSDI are now known as FreeBSD Mall and iXsystems (of PC-BSD and FreeNAS fame). DES -- Dag-Erling Smørgrav - d...@des.no ___ freebsd-c...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-chat To unsubscribe, send any mail to freebsd-chat-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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Fri, May 18, 2012 at 07:01:25PM +0200, Alberto Villa wrote: On Tue, May 1, 2012 at 8:18 PM, Gustau P?rez i Querol gpe...@entel.upc.edu wrote: So the problem seems to be not related to jemalloc or malloc. As the experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem has do to with some differences between head and stable. When we get more hints where the problem is, I will post them in a new thread in freebsd-current@. Gus has been away for a while, but before disappearing he found a workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So I had a look around, and found this NetBSD bug report: http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-atexit_mutex-should-be-fully-recursive.html Since qdbus crashes after exit(3) here too, that might be an explanation. Or, at least, something related. kib@ and kan@ are CCed as per avg@ suggestion. You provided zero information. The reference to NetBSD is completely meaningless, we drop atexit_mutex when calling registered atexit handlers. At least bother to provide useful bug report if you suspect a bug in base system and want it fixed. pgp0sGxGE8Xls.pgp Description: PGP signature
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
on 18/05/2012 20:01 Alberto Villa said the following: On Tue, May 1, 2012 at 8:18 PM, Gustau Pérez i Querol gpe...@entel.upc.edu wrote: So the problem seems to be not related to jemalloc or malloc. As the experimental 4.8.1 devel/dbus-qt4 port works fine in stable, the problem has do to with some differences between head and stable. When we get more hints where the problem is, I will post them in a new thread in freebsd-current@. Gus has been away for a while, but before disappearing he found a workaround to be building devel/dbus-qt4 with -fno-use-cxa-atexit. So I had a look around, and found this NetBSD bug report: http://www.archivum.info/fa.netbsd.bugs/2007-12/00070/lib-37654-libc's-atexit_mutex-should-be-fully-recursive.html Since qdbus crashes after exit(3) here too, that might be an explanation. Or, at least, something related. kib@ and kan@ are CCed as per avg@ suggestion. Alberto, you have add new people to the discussion, but unfortunately too little of the original context is present here... That is, this email doesn't even include a description of an actual problem. Could you please provide the useful context either as a link to a mailing list archive or in some other equally useful way? Thank you! -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On Fri, May 18, 2012 at 11:28 PM, Andriy Gapon a...@freebsd.org wrote: you have add new people to the discussion, but unfortunately too little of the original context is present here... That is, this email doesn't even include a description of an actual problem. Could you please provide the useful context either as a link to a mailing list archive or in some other equally useful way? Sorry, Gmail showed the thread with all the history, but I see that in the archives it's considered as two different conversations. Here's the original thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033547.html I think I understand that the NetBSD problem is not related to our case, Also, Gustau told me that he narrowed the problem down to __pthread_cxa_finalize. He will add new information very soon, anyway. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Sat, May 19, 2012 at 12:16:59AM +0200, Alberto Villa wrote: On Fri, May 18, 2012 at 11:28 PM, Andriy Gapon a...@freebsd.org wrote: you have add new people to the discussion, but unfortunately too little of the original context is present here... That is, this email doesn't even include a description of an actual problem. Could you please provide the useful context either as a link to a mailing list archive or in some other equally useful way? Sorry, Gmail showed the thread with all the history, but I see that in the archives it's considered as two different conversations. Here's the original thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-April/033547.html I think I understand that the NetBSD problem is not related to our case, Also, Gustau told me that he narrowed the problem down to __pthread_cxa_finalize. He will add new information very soon, anyway. Well, there is still not much to read. And, http://pastebin.com/ryBXtqGF. shows 'Unknown Paste ID!'. That said, why do you think that the problem is in system and not in the application ? The fact that the issue does not manifests itself under stable/9 is not enough to arrive at this conclusion. pgpbvpMe6D9v5.pgp Description: PGP signature
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On Sat, May 19, 2012 at 12:37 AM, Konstantin Belousov kostik...@gmail.com wrote: Well, there is still not much to read. And, http://pastebin.com/ryBXtqGF. shows 'Unknown Paste ID!'. Eh, sorry, Gus will provide updated data. That said, why do you think that the problem is in system and not in the application ? The fact that the issue does not manifests itself under stable/9 is not enough to arrive at this conclusion. We thought it because it suddenly appeared, but neither me nor Gus are sure of this. We asked for help because this is affecting the whole Qt update, and as a kde@ member this is a major concern for me (and many others, I guess). Whether the issue will be found in the system or in the application is mostly of no interest. That said, if there is no information to examine at the moment, let's just wait for Gus mail. Sorry for the noise, then. -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ 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: RFC: jemalloc: qdbus sigsegv in malloc_init
On Sat, May 19, 2012 at 12:49:02AM +0200, Alberto Villa wrote: On Sat, May 19, 2012 at 12:37 AM, Konstantin Belousov kostik...@gmail.com wrote: Well, there is still not much to read. And, http://pastebin.com/ryBXtqGF. shows 'Unknown Paste ID!'. Eh, sorry, Gus will provide updated data. That said, why do you think that the problem is in system and not in the application ? The fact that the issue does not manifests itself under stable/9 is not enough to arrive at this conclusion. We thought it because it suddenly appeared, but neither me nor Gus are sure of this. We asked for help because this is affecting the whole Qt update, and as a kde@ member this is a major concern for me (and many others, I guess). Whether the issue will be found in the system or in the application is mostly of no interest. That said, if there is no information to examine at the moment, let's just wait for Gus mail. Sorry for the noise, then. How to reproduce the issue locally ? (I do not want to install all KDE to my test box). pgpRfrNUfMFpK.pgp Description: PGP signature
Re: RFC: jemalloc: qdbus sigsegv in malloc_init
On Sat, May 19, 2012 at 12:52 AM, Konstantin Belousov kostik...@gmail.com wrote: How to reproduce the issue locally ? (I do not want to install all KDE to my test box). Just build devel/dbus-qt4 on 10-CURRENT and run qdbus. It should crash (should you have D-Bus running, which you probably don't have, it would first print all D-Bus connections and then crash on exit). -- Alberto Villa, FreeBSD committer avi...@freebsd.org http://people.FreeBSD.org/~avilla ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[head tinderbox] failure on i386/i386
TB --- 2012-05-18 20:30:00 - tinderbox 2.9 running on freebsd-current.sentex.ca TB --- 2012-05-18 20:30:00 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2012-05-18 20:30:00 - starting HEAD tinderbox run for i386/i386 TB --- 2012-05-18 20:30:00 - cleaning the object tree TB --- 2012-05-18 20:30:00 - cvsupping the source tree TB --- 2012-05-18 20:30:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2012-05-18 20:38:35 - building world TB --- 2012-05-18 20:38:35 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 20:38:35 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 20:38:35 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 20:38:35 - SRCCONF=/dev/null TB --- 2012-05-18 20:38:35 - TARGET=i386 TB --- 2012-05-18 20:38:35 - TARGET_ARCH=i386 TB --- 2012-05-18 20:38:35 - TZ=UTC TB --- 2012-05-18 20:38:35 - __MAKE_CONF=/dev/null TB --- 2012-05-18 20:38:35 - cd /src TB --- 2012-05-18 20:38:35 - /usr/bin/make -B buildworld World build started on Fri May 18 20:38:36 UTC 2012 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Fri May 18 22:57:37 UTC 2012 TB --- 2012-05-18 22:57:37 - generating LINT kernel config TB --- 2012-05-18 22:57:37 - cd /src/sys/i386/conf TB --- 2012-05-18 22:57:37 - /usr/bin/make -B LINT TB --- 2012-05-18 22:57:37 - cd /src/sys/i386/conf TB --- 2012-05-18 22:57:37 - /usr/sbin/config -m LINT TB --- 2012-05-18 22:57:37 - building LINT kernel TB --- 2012-05-18 22:57:37 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 22:57:37 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 22:57:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 22:57:37 - SRCCONF=/dev/null TB --- 2012-05-18 22:57:37 - TARGET=i386 TB --- 2012-05-18 22:57:37 - TARGET_ARCH=i386 TB --- 2012-05-18 22:57:37 - TZ=UTC TB --- 2012-05-18 22:57:37 - __MAKE_CONF=/dev/null TB --- 2012-05-18 22:57:37 - cd /src TB --- 2012-05-18 22:57:37 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Fri May 18 22:57:38 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT completed on Fri May 18 23:30:51 UTC 2012 TB --- 2012-05-18 23:30:51 - cd /src/sys/i386/conf TB --- 2012-05-18 23:30:51 - /usr/sbin/config -m LINT-NOINET TB --- 2012-05-18 23:30:51 - building LINT-NOINET kernel TB --- 2012-05-18 23:30:51 - CROSS_BUILD_TESTING=YES TB --- 2012-05-18 23:30:51 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-18 23:30:51 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-18 23:30:51 - SRCCONF=/dev/null TB --- 2012-05-18 23:30:51 - TARGET=i386 TB --- 2012-05-18 23:30:51 - TARGET_ARCH=i386 TB --- 2012-05-18 23:30:51 - TZ=UTC TB --- 2012-05-18 23:30:51 - __MAKE_CONF=/dev/null TB --- 2012-05-18 23:30:51 - cd /src TB --- 2012-05-18 23:30:51 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET Kernel build for LINT-NOINET started on Fri May 18 23:30:51 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET completed on Sat May 19 00:01:38 UTC 2012 TB --- 2012-05-19 00:01:38 - cd /src/sys/i386/conf TB --- 2012-05-19 00:01:38 - /usr/sbin/config -m LINT-NOINET6 TB --- 2012-05-19 00:01:38 - building LINT-NOINET6 kernel TB --- 2012-05-19 00:01:38 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 00:01:38 - MAKEOBJDIRPREFIX=/obj TB --- 2012-05-19 00:01:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2012-05-19 00:01:38 - SRCCONF=/dev/null TB --- 2012-05-19 00:01:38 - TARGET=i386 TB --- 2012-05-19 00:01:38 - TARGET_ARCH=i386 TB --- 2012-05-19 00:01:38 - TZ=UTC TB --- 2012-05-19 00:01:38 - __MAKE_CONF=/dev/null TB --- 2012-05-19 00:01:38 - cd /src TB --- 2012-05-19 00:01:38 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 Kernel build for LINT-NOINET6 started on Sat May 19 00:01:38 UTC 2012 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything Kernel build for LINT-NOINET6 completed on Sat May 19 00:33:12 UTC 2012 TB --- 2012-05-19 00:33:12 - cd /src/sys/i386/conf TB --- 2012-05-19 00:33:12 - /usr/sbin/config -m LINT-NOIP TB --- 2012-05-19 00:33:12 - building LINT-NOIP kernel TB --- 2012-05-19 00:33:12 - CROSS_BUILD_TESTING=YES TB --- 2012-05-19 00:33:12
Re: SUJ file system corruption.
On May 18, 2012, at 3:18 AM, Bjoern A. Zeeb wrote: On 13. May 2012, at 22:35 , Tim Kientzle wrote: FYI: Saw a crash due to filesystem corruption when running SUJ. This is on a ARM AM335x system (BeagleBone) that is still pretty experimental, so I certainly cannot rule out other problems, but in case it means something to someone, here's the scenario: Reset the board to reboot (which is routine for these small embedded boards) and when it came back up it went through SUJ recovery, and then a little later the kernel panicked with this stack trace: rm: /var/run/dmesg.boot: Bad file descriptor panic: ffs_write: type 0xc1e86660 0 (0,1024) Can you tell us if this was HEAD, stable/9 or 9.0-RELEASE? Apologies: This was with the armv6 projects tree, which is not quite CURRENT. Tim ___ 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
