Re: dmesg content lifetime
On Tue, 22 Nov 2022 09:12:28 -0600 (CST) Dan Mack wrote: > It seems like dmesg content ages out over time. Is there a way to > leave the contents based on a fixed memory size instead? > > Dan > I think this is how it works: the kernel message bugger is of fixed size and kernel and syslog sequences (dmesg -a) share it. The other syslog users eventually puts enough content in there to displace all of kernel messages. If the kernel stays quiet, 'dmesg' then returns nothing, as by default it filters syslog entries that do not KERN facility out, see sbin/dmesg/dmesg.c. -- Alexander Kabaev pgpERzqAOoi9r.pgp Description: Цифровая подпись OpenPGP
Re: linux64.ko fails to load in -CURRENT
On Fri, 28 Jul 2017 08:50:32 -0700 "R. Tyler Croy" <ty...@monkeypox.org> wrote: > I have noticed this over the past couple weeks with my -CURRENT > laptop that 64-bit linux compatibility is failing to load, and I'm > not entirely sure why. My current kernel is based off of r321626. > > When I run `kldload linux64` it fails with the following: > > link_elf_obj: symbol elf64_linux_vdso_fixup undefined > linker_load_file: /boot/kernel/linux64.ko - unsupported file type > > > It's unclear to me whether this is old cruft sitting around, a > regression, or something else entirely floating around my system. Any > pointer would help :) > > > Cheers > - R. Tyler Croy I am guessing you have COMPAT_LINUX in your kernel and 32bit emulation is compiled into it. This does not work for linux64, one needs to build all three required components as modules: 191 0x82221000 438d9linux.ko 203 0x82265000 7c49 linux_common.ko 211 0x8226d000 3d8f5 linux64.ko 22 1 0x822ab000 ab75 linprocfs.ko -- Alexander Kabaev pgpG8HhHCYutw.pgp Description: Цифровая подпись OpenPGP
Re: malloc() call somehow calling the rtld malloc() implementaion
On Fri, 27 Jan 2017 10:47:20 -0800 (PST)
Don Lewis <truck...@freebsd.org> wrote:
> On 27 Jan, Alexander Kabaev wrote:
> > On Fri, 27 Jan 2017 00:31:30 -0800 (PST)
> > Don Lewis <truck...@freebsd.org> wrote:
>
> >> If I create a simple test program that calls malloc() and set a
> >> breakpoint in malloc(), the breakpoint gets set in the rtld
> >> version, but the the libc version of malloc is what gets called.
> >>
> >> What the heck is going on here, and how can I fix it?
> >>
> >
> > rtld on my system does not have malloc exposed as dynamic symbol, it
> > cannot possibly be used for symbol resolution by any outside
> > module.
>
> Same here, but gdb at least seems to find it anyway.
>
> 12.0-CURRENT r311765M
>
> %nm /libexec/ld-elf.so.1
> nm: /libexec/ld-elf.so.1: no symbols
>
> %elfdump -s /libexec/ld-elf.so.1 | grep st_name | sort
> st_name:
> st_name:
> st_name: FBSD_1.0
> st_name: FBSD_1.1
> st_name: FBSD_1.2
> st_name: FBSD_1.3
> st_name: FBSD_1.4
> st_name: FBSD_1.5
> st_name: FBSDprivate_1.0
> st_name: __tls_get_addr
> st_name: _r_debug_postinit
> st_name: _rtld_addr_phdr
> st_name: _rtld_allocate_tls
> st_name: _rtld_atfork_post
> st_name: _rtld_atfork_pre
> st_name: _rtld_error
> st_name: _rtld_free_tls
> st_name: _rtld_get_stack_prot
> st_name: _rtld_is_dlopened
> st_name: _rtld_thread_init
> st_name: dl_iterate_phdr
> st_name: dladdr
> st_name: dlclose
> st_name: dlerror
> st_name: dlfunc
> st_name: dlinfo
> st_name: dllockinit
> st_name: dlopen
> st_name: dlsym
> st_name: dlvsym
> st_name: fdlopen
> st_name: r_debug_state
>
> %cd /tmp
> zipper:/tmp 508%cat malloctest.c
> #include
> volatile void *p;
> int
> main(void) {
> p = malloc(16);
> }
> %cc -g malloctest.c
> %gdb a.out
> GNU gdb 6.1.1 [FreeBSD]
> Copyright 2004 Free Software Foundation, Inc.
> GDB is free software, covered by the GNU General Public License, and
> you are welcome to change it and/or distribute copies of it under
> certain conditions. Type "show copying" to see the conditions.
> There is absolutely no warranty for GDB. Type "show warranty" for
> details. This GDB was configured as "amd64-marcel-freebsd"...
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out
>
> Breakpoint 1, main () at malloctest.c:5
> 5 p = malloc(16);
> Current language: auto; currently minimal
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: file /usr/src/libexec/rtld-elf/malloc.c,
> line 163. (gdb) cont
> Continuing.
>
> Program exited normally.
> (gdb) quit
>
> Ports gdb finds both the rtld malloc() and the libc malloc():
>
> %/usr/local/bin/gdb a.out
> GNU gdb (GDB) 7.12 [GDB v7.12 for FreeBSD]
> Copyright (C) 2016 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or later
> <http://gnu.org/licenses/gpl.html> This is free software: you are
> free to change and redistribute it. There is NO WARRANTY, to the
> extent permitted by law. Type "show copying" and "show warranty" for
> details. This GDB was configured as "x86_64-portbld-freebsd12.0".
> Type "show configuration" for configuration details.
> For bug reporting instructions, please see:
> <http://www.gnu.org/software/gdb/bugs/>.
> Find the GDB manual and other documentation resources online at:
> <http://www.gnu.org/software/gdb/documentation/>.
> For help, type "help".
> Type "apropos word" to search for commands related to "word"...
> Reading symbols from a.out...done.
> (gdb) break main
> Breakpoint 1 at 0x40076b: file malloctest.c, line 5.
> (gdb) run
> Starting program: /tmp/a.out
>
> Breakpoint 1, main () at malloctest.c:5
> 5 p = malloc(16);
> (gdb) break malloc
> Breakpoint 2 at 0x80060e9a4: malloc. (2 locations)
> (gdb) cont
> Continuing.
>
> Breakpoint 2, __malloc (size=16) at jemalloc_jemalloc.c:1636
> 1636 size_t usize JEMALLOC_CC_SILENCE_INIT(0);
gdb looks into debugging info for symbols in debug information and so
has greater visibility. Symbols gdb sees play no role in dynasmic
building, so rtld malloc somehow replacing the malloc from the program
as you suspected is really impossible.
kib@ has a better idea that is worth investigating further: is the
address on which idlc traps corresponds to TLS storage? tls alloc calls
are supposed to respect the tls section alignment though.
--
Alexander Kabaev
pgpz16Dbu9ryG.pgp
Description: Цифровая подпись OpenPGP
Re: malloc() call somehow calling the rtld malloc() implementaion
ExprValue)=16 > > Program received signal SIGBUS, Bus error. > [Switching to Thread 802616000 (LWP 101304/idlc)] > 0x00478cc2 in AstExpression::eval_bit_op (this=0x802633dc8, > ek=EK_const) at astexpression.cxx:1001 > 1001 std::auto_ptr< AstExprValue > retval(new > AstExprValue()); > > > idlc is linked to libc.so: > > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/bin/idlc: > libreg.so.3 > => > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libreg.so.3 > (0x8008b9000) libuno_sal.so.3 > => > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libuno_sal.so.3 > (0x800c0) libuno_salhelpergcc3.so.3 > => > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libuno_salhelpergcc3.so.3 > (0x80104) libm.so.5 => /lib/libm.so.5 (0x801244000) libc++.so.1 > => /usr/lib/libc++.so.1 (0x80146e000) libcxxrt.so.1 > => /lib/libcxxrt.so.1 (0x801735000) libgcc_s.so.1 > => /lib/libgcc_s.so.1 (0x801953000) libthr.so.3 => /lib/libthr.so.3 > (0x801b69000) libc.so.7 => /lib/libc.so.7 (0x801d91000) libstore.so.3 > => > /wrkdirs/usr/ports/editors/openoffice-devel/work/aoo-4.2.0/main/solver/420/unxfbsdx.pro/lib/libstore.so.3 > (0x802152000) > > > If I create a simple test program that calls malloc() and set a > breakpoint in malloc(), the breakpoint gets set in the rtld version, > but the the libc version of malloc is what gets called. > > What the heck is going on here, and how can I fix it? > rtld on my system does not have malloc exposed as dynamic symbol, it cannot possibly be used for symbol resolution by any outside module. -- Alexander Kabaev pgpPf7f_BI7sM.pgp Description: Цифровая подпись OpenPGP
Re: recent change to vim defaults?
On Wed, 18 Jan 2017 10:06:55 -0800 Pete Wright <p...@nomadlogic.org> wrote: > On 1/18/17 10:01 AM, Julian Elischer wrote: > > On 18/01/2017 5:03 PM, Raimund Sacherer wrote: > >> I have to put mouse=v to get the behavior I am used to. > >> > >> Best > > > > doesn't really work for me. > > > > vim is still taking mouse events > > > > kinda feel like it we need a "classic" vim port that is from the v7.x > codebase since i suspect the changes to mouse behaviour in v8.x is > only the beginning of lots of suspect changes to the vim codebase :/ > > i went through the code for vim the other day and couldn't figure out > a way to disable entering visual-mode via mouseclick as a compile > time option. perhaps we should preserve the expected behaviour by > updating /usr/local/etc/vim/vimrc? > > -p > > > -- > Pete Wright > p...@nomadlogic.org > nomadlogicLA What we need, IMHO, of course, is to stop jamming _example_ config file down everyone's throat. Not even Linux does install that file unchanged. -- Alexander Kabaev pgpHx_puTsrm7.pgp Description: Цифровая подпись OpenPGP
Re: slow screen updates on laptop console (i386)
On Mon, 7 Dec 2015 09:02:35 -0500 (EST) Rick Macklem <rmack...@uoguelph.ca> wrote: > Hi, > > When running FreeBSD-current on an old i386 laptop, the console > screen is intermittently slow to display output. The hesitations > can be several seconds. > Sometimes it shows up when I'm typing such that it takes seconds > for the characters to echo. > I think it is the display/output side, since I've seen it happen when > doing "more ", where the screen is stuck half way through > displaying the page for a few seconds. > > I don't see any problem when going into the machine remotely and > I don't see the problem on the other laptop I have running > FreeBSD/amd64. > > It has been happening for a while. It occurs on the oldest kernel > I have lying around (r287930, Sep. 17, 2015). > > I've tried the old "sc" driver and it seems to happen less with it, > but it still occurs. > > I'll admit I have no idea what drives doing output for the display > screen. > > Anyone have ideas w.r.t. this? > > Thanks in advance, rick Hi, maybe a stretch, but I would try selecting different eventtimer, if available. Say, I had to select HPET on my old i7 920 to make timeouts run reliably. sysctl kern.eventtimer.timer=HPET -- Alexander Kabaev pgpjgZfocKN6s.pgp Description: OpenPGP digital signature
Re: ls is broken for non-C locales due to libxo
On Wed, 17 Jun 2015 05:18:35 +0300 Andrey Chernov a...@freebsd.org wrote: Recent -current, LANG=ru_RU.KOI8-R locale. ls -t eats whole date column, just ls eats whole filenames with printable national characters inside. Long live libxo. ___ 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 Ouch, it turns out I got switched to UTF8 locale because someone silently changed the 'russian' login class. Way to go, people, way to go. I confirm that ls is indeed broken in KOI8-R locale. I should have noticed that before, has I now been sabotaged by unintentional locale switcharoo. -- Alexander Kabaev pgpeIxHWK513t.pgp Description: OpenPGP digital signature
Re: [Heads up] : You may need to update your gcc ports.
On Sun, 05 Apr 2015 12:39:46 -0500 Pedro Giffuni p...@freebsd.org wrote: Hello; I was going to add this to the UPDATING file but this file is not meant for changes affecting ports so here it goes instead: 20150415: Our libc headers are starting to use gcc-style attributes to hint the compiler about probable optimizations or errors. Unfortunately gcc from ports does some bogus fixing of our system headers and carries them internally so you may have to update your gcc ports so that they grab the complete system headers and particularly the cdefs.h file changes from r280801. This basically affects only -current users that haven't rebuilt their gcc ports in a week. Sorry for the inconvenience, 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 FWIW, I think we should just disable fixincludes step in our GCC ports with extreme prejudice. I am yet to see the case where copying our headers and stashing them away in random location is actually beneficial. -- Alexander Kabaev pgpzGNF1jGZBc.pgp Description: OpenPGP digital signature
Re: [Call for testers] DRM device-independent code update to Linux 3.8 (take #2)
On Tue, 03 Mar 2015 23:33:23 +0100 Jean-S'ebastien P'edron dumbb...@freebsd.org wrote: Hi! Here is a new patch to based on HEAD r279508: https://people.freebsd.org/~dumbbell/graphics/drm-update-38.i.patch You can apply it to a Subversion checkout using the following command: svn patch drm-update-38.i.patch There are few changes: o The panic reported by J.R. Oldroyd is fixed, but not the CP init problem. o A lock assert was added, suggested by Konstantin Belousov I had several panics (Stray timeout) with a taskqueue used by TTM, but it didn't occur in the past 6 days. Maybe it was a problem outside of DRM. I would like people to test again and report :) If something fails, please post a full dmesg, taken after loading the relevant *kms module, or the core.txt.$N file if it's a panic. Hans Petter and Ed, I couldn't reproduce neither of your problems (HDMI hotplug events storm and VT-switch misbehaviour). However, they both involve callouts, like the Stray timeout panic I had with TTM. I suspect there was a transient problem with callouts in HEAD at the same time. Could you please test again with this patch and a very recent HEAD? Thank you to everyone! -- Jean-S'ebastien P'edron Just as a data point, 'stray timeout' happens in clean -current without new patch as well. So whatever that is, it is not caused by the patch. -- Alexander Kabaev pgpg0MgLxRxxG.pgp Description: OpenPGP digital signature
Re: Future of pf / firewall in FreeBSD ? - does it have one ?
On Sun, 20 Jul 2014 10:15:36 -0400 Maxim Khitrov m...@mxcrypt.com wrote: On Sun, Jul 20, 2014 at 8:39 AM, Lars Engels lars.eng...@0x20.net wrote: On Sun, Jul 20, 2014 at 12:18:54PM +0100, krad wrote: all of that is true, but you are missing the point. Having two versions of pf on the bsd's at the user level, is a bad thing. It confuses people, which puts them off. Its a classic case of divide an conquer for other platforms. I really like the idea of the openpf version, that has been mentioned in this thread. It would be awesome if it ended up as a supported linux thing as well, so the world could be rid of iptables. However i guess thats just an unrealistic dream And you don't seem to get the point that _someone_ has to do the work. No one has stepped up so far, so nothing is going to change. Gleb believes that the majority of FreeBSD users don't want the updated syntax, among other changes, from the more recent pf versions. Developers who share his opinion are not going to volunteer to do the work. This discussion is about showing this belief to be wrong, which is the first step in the process. In my opinion, the way forward is to forget (at least temporarily) the SMP changes, bring pf in sync with OpenBSD, put a policy in place to follow their releases as closely as possible, and then try to reintroduce all the SMP work. I think the latter has to be done upstream, otherwise it'll always be a story of diverging codebases. Furthermore, if FreeBSD developers were willing to spend some time improving pf performance on OpenBSD, then Henning and other OpenBSD developers might be more receptive to changes that make the porting process easier. I am one person whose opinion Gleb got completely right - I could not care less about new syntax nor about how close or how far are we from OpenBSD, as long as pf works for my purposes and it does. This far into the thread and somebody has yet to provide a comprehensive list of the benefits that we allegedly miss, or to come up with the real benchmark result to substantiate the performance claims. Focusing on disproving anything Gleb might be believing in on the matter, while an interesting undertaking, does nothing to give you new pf you supposedly want. Doing the work and bringing it all the way to will completeness for commit - does. It was stated repeatedly by multiple people that FreeBSD's network stack is way too different from OpenBSD, we support features OpenBSD doesn't and vice versa, vimage is a good example, which throws a giant wrench into the plan of following OpenBSD 'as closely as possible', even as the expense of throwing away all of the SMP work done in pf to date. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Latest -current panic in uaudio_detach() / bus_dmamem_free()
On Mon, 23 Jun 2014 06:04:20 +0400
Andrey Chernov a...@freebsd.org wrote:
Always happens at shutdown after all buffers are synced, see
screenshot: http://i.imgur.com/8WXTMPj.png
--
http://ache.vniz.net/
Hi Andrey,
there's not to much to go on from the screenshoot alone and one would
expect more details on the crash from people with your experience :)
Please provide us with the information on the actual audio hardware
you are using, preferably in form of a dmesg output. This revision is
your culpit:
http://svnweb.freebsd.org/changeset/base/267581 and I have strong
suspicion that restoring the NULL check on dmatag in the chunk below
will cure your crash.
-- Modified: head/sys/dev/sound/pcm/buffer.c
==
--- head/sys/dev/sound/pcm/buffer.c Tue Jun 17 14:47:49
2014(r267580) +++ head/sys/dev/sound/pcm/buffer.c Tue
Jun 17 16:07:57 2014(r267581) @@ -139,10 +139,9 @@
sndbuf_free(struct snd_dbuf *b)
if (b-buf) {
if (b-flags SNDBUF_F_MANAGED) {
- if (b-dmamap)
+ if (b-buf_addr)
bus_dmamap_unload(b-dmatag,
b-dmamap);
- if (b-dmatag)
- bus_dmamem_free(b-dmatag, b-buf,
b-dmamap);
+ bus_dmamem_free(b-dmatag, b-buf, b-dmamap);
} else
free(b-buf, M_DEVBUF);
}
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Memory blackhole in 11. Possibly libc.so.7?
On Thu, 29 May 2014 09:08:10 -0400 John Baldwin j...@freebsd.org wrote: On Thursday, May 29, 2014 5:41:03 am Beeblebrox wrote: uname: FreeBSD 11.0-CURRENT #0 r266393M: Sun May 18 13:04:00 2014 amd64 I'm also loading the Radeon_kms modules SKIP I don't know if the lsof dump in single user mode will be of any help, but it seems like lib/libc.so.7 has something to do with it: Why do you think libc.so.7 has anything to do with this? wired memory is usually only allocated in the kernel, so if anything you are looking at some sort of memory leak in a driver (maybe the radeon driver?) -- John Baldwin Aren't ZFS buffers accounted as kernel wired memory? -- Alexander Kabaev signature.asc Description: PGP signature
Re: KGDB and kvm_write
On Sat, 07 Dec 2013 19:09:26 +0100 Hans Petter Selasky h...@bitfrost.no wrote: Hi, Is there a particular reason that set variable = value is not implemented when using kgbd from the command prompt? --HPS Just a thought: maybe you forgot -w on kgdb command line? -- Alexander Kabaev signature.asc Description: PGP signature
Re: Undesirable bmake behavior
On Sat, 1 Jun 2013 21:40:57 -0700
Simon J. Gerraty s...@juniper.net wrote:
today I got confronted with this little curiosity from bmake. I have
built and installed the world, and after reboot I ran 'make
delete-old' as root to get rid of accumulated stale files. This is
what I got back:
Removing old files (only deletes safe to delete libs)
Old files removed
Removing old directories
Old directories removed
To remove old libraries run '/usr/obj/usr/src/make.amd64/make
delete-old-libs'.
It turns out that somehow running make in src tree finds and tries to
run a copy from .OBJDIR, if one is present, unconditionally now. I do
This simply what src/Makefile says to do, and AFAIK it has been that
way for ages.
Since delete-old is in TGTS it gets run via:
#
# Handle the user-driven targets, using the source relative mk files.
#
${TGTS}:
${_+_}@cd ${.CURDIR}; ${_MAKE} ${.TARGET}
and
$ make -dV -V _MAKE
PATH=${PATH} ${BINMAKE} -f Makefile.inc1 TARGET=${_TARGET}
TARGET_ARCH=${_TARGET_ARCH} $ make -dV -V BINMAKE
`if [ -x ${MAKEPATH}/make ]; then echo ${MAKEPATH}/make; else echo
${MAKE}; fi` -m ${.CURDIR}/share/mk
$ make -V _MAKE
PATH=/sbin:/bin:/usr/sbin:/usr/bin `if [ -x
/var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make ];
then
echo /var/obj/current/b/sjg/work/FreeBSD/current/src/make.amd64/make;
else echo make; fi` -m /b/sjg/work/FreeBSD/current/src/share/mk -f
Makefile.inc1 TARGET=amd64 TARGET_ARCH=amd64 $
Now you may be right that that's a bad idea, but it isn't anything
new.
--sjg
Indeed, it seems this is an issue that rears it head every time we
resort to building the bootstrap make, which happens not often. bmake
just made me notice the issue, and it wasn't the cause.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Undesirable bmake behavior
Hi, today I got confronted with this little curiosity from bmake. I have built and installed the world, and after reboot I ran 'make delete-old' as root to get rid of accumulated stale files. This is what I got back: Removing old files (only deletes safe to delete libs) Old files removed Removing old directories Old directories removed To remove old libraries run '/usr/obj/usr/src/make.amd64/make delete-old-libs'. It turns out that somehow running make in src tree finds and tries to run a copy from .OBJDIR, if one is present, unconditionally now. I do not think this that is a particularly desirable and even sane behaviour - once buildworld has finished, no tool should ever try to run _anything_ from what is essentially a scratch space. Bootstrap and cross tools should only be used during corresponding stages of buildworld and by default. -- Alexander Kabaev signature.asc Description: PGP signature
Re: kernel panic - Fatal Trap 12 on boot @svn 248711
On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) AN a...@neu.net wrote: After updating to svn 248711 I am getting a kernel panic and reboot when booting my system. The last line I see while booting is: Entropy harvesting interrupts: Ethernet point to point, and then Fatal Trap 12 in kernel mode then an automatic reboot. I am currently booting into kernel.old @svn FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone else seeing this behavior? ___ 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 You run dconschat by any chance? -- Alexander Kabaev signature.asc Description: PGP signature
Re: kernel panic - Fatal Trap 12 on boot @svn 248711
On Mon, 25 Mar 2013 21:21:07 -0400 (EDT) AN a...@neu.net wrote: On Mon, 25 Mar 2013, Alexander Kabaev wrote: On Mon, 25 Mar 2013 21:06:09 -0400 (EDT) AN a...@neu.net wrote: After updating to svn 248711 I am getting a kernel panic and reboot when booting my system. The last line I see while booting is: Entropy harvesting interrupts: Ethernet point to point, and then Fatal Trap 12 in kernel mode then an automatic reboot. I am currently booting into kernel.old @svn FreeBSD FBSD10 10.0-CURRENT FreeBSD 10.0-CURRENT #38 r248401: Sat Mar 16 21:39:04 CDT 2013 root@FBSD10:/usr/obj/usr/src/sys/MYKERNEL amd64 Is anyone else seeing this behavior? ___ 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 You run dconschat by any chance? -- Alexander Kabaev Hi Alexander: No, I do not think so. How can I tell? I have never intentionally configured it. Then you probably are not running it and the and the question is moot. I would suggest trying r248712 anyway, just for kicks. If that does not help, then try with vfs.unmapped_buf_allowed=0 in loader.conf. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Fatal trap 12 with process cambio on USB attach
On Sat, 19 Jan 2013 10:10:54 -0500 Glen Barber g...@freebsd.org wrote: Hi, I am running one-day-old -CURRENT: root@nucleus:~ # uname -a FreeBSD nucleus 10.0-CURRENT FreeBSD 10.0-CURRENT #51 r245605: Fri Jan 18 11:25:40 EST 2013 root@nucleus:/usr/obj/usr/src/sys/NUCLEUS amd64 I attached a MicroSDHC flash card with a MicroSD-USB adapter, and the system crashed with a kernel page fault. I am certain the SDHC card should work, as it works in other FreeBSD machines. kgdb session follows. Please let me know if I can provide further information. Thanks, Glen This is likely the same crash that is fixed by in r245647: http://svnweb.freebsd.org/changeset/base/245647 -- Alexander Kabaev signature.asc Description: PGP signature
Re: genmodes dumping core during buildworld
On Thu, 15 Nov 2012 15:02:36 + Eggert, Lars l...@netapp.com wrote: Hi, anyone see something similar before: === usr.sbin/zic/zdump (depend) rm -f .depend mkdep -f .depend -a-DTM_GMTOFF=tm_gmtoff -DTM_ZONE=tm_zone -DSTD_INSPIRED -DPCTS -DHAVE_LONG_DOUBLE -DTZDIR=\/usr/share/zoneinfo\ -Demkdir=mkdir -I/usr/src/usr.sbin/zic/zdump/.. -I/usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/stdtime -std=gnu99 /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/zdump.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/ialloc.c /usr/src/usr.sbin/zic/zdump/../../../contrib/tzcode/zic/scheck.c echo zdump: /usr/obj/usr/src/tmp/usr/lib/libc.a .depend === usr.sbin/zzz (depend) 1 error *** [_depend] Error code 2 1 error *** [buildworld] Error code 2 1 error This is in the log: Nov 15 15:56:49 server kernel: pid 83891 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83893 (genmodes), uid 0: exited on signal 10 (core dumped) Nov 15 15:56:49 server kernel: pid 83897 (genmodes), uid 0: exited on signal 10 (core dumped) genmodes seems to be a component of gcc? Lars It also happens to be the 10 years old piece of software that has not changed in recent history. Which means that (likely) you run out of memory, your CPU overheats or something else is wrong with your computer, or (less likely) it is being mis-compiled by clang. -- Alexander Kabaev signature.asc Description: PGP signature
Re: pkgng suggestion: renaming /usr/sbin/pkg to /usr/sbin/pkg-bootstrap
On Thu, 23 Aug 2012 18:19:57 -0400 Steve Wills swi...@freebsd.org wrote: Hi, It seems to me that renaming the pkg binary in /usr/sbin/pkg to /usr/sbin/pkg-bootstrap would make sense. From a user standpoint, it is confusing that running the command gets different results the second time it is run vs. the first time. I can imagine a user saying I ran pkg, but it didn't do what they said it would. Now I run it again, and it does do what it is supposed to. Also, it would enable setting up a pkg-bootstrap man page separate from the pkg man page, without confusion about which one you're looking at. So, opinions? There may still be time to fix it for 9.1 if we can decide quickly. Thanks, Steve Remove it or rename it. Do _NOT_ make it download the package and install it silently as this is a security nightmare waiting to happen. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Segfault in rtld - dlopen RTLD_LAZY (was: Re: CFT: vlc 2.0.3 - want to know where it works and where only partly)
On Mon, 13 Aug 2012 01:13:35 +0200 Juergen Lock n...@jelal.kn-bremen.de wrote: On Sun, Aug 05, 2012 at 07:38:11PM +0200, Juergen Lock wrote: On Sun, Aug 05, 2012 at 07:13:53PM +0300, Konstantin Belousov wrote: On Sun, Aug 05, 2012 at 05:31:19PM +0200, Juergen Lock wrote: Hi kib, -current, seems we have a segfault in rtld when updating the multimedia/vlc port from the version currently in ports to the 2.0.3 CFT version from here: http://people.freebsd.org/~nox/tmp/vlc-2.0.3-006.patch (If you test the LIVEMEDIA knob you also need this update: http://people.freebsd.org/~nox/tmp/livemedia-20120404-001.patch ) Please do two things. 1. Provide me the output of readelf -a for the module that was loaded. 2. Recompile rtld with debug symbols and redo the build to get the useful backtrace from core: cd /usr/src/libexec/rtld-elf make clean make all install DEBUG_FLAGS=-g Ok, someone who got the crash will have to do this as I couln't reproduce it here (sorry forgot to say...) I just learned that the missing piece in reproducing this is the pulseaudio knob, now I finally have a bt: obj-nbuckets in core seems to disagree with that readelf thinks it should be (521 != 67). Could you please make the tarball of all the VLC libraries involved? Send the link to me and kib@, please. At the very least, can I lay my hands on libpulsesrc_plugin.so binary? -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld dropping core on recent -current
On Fri, 3 Aug 2012 11:59:37 +0300
Konstantin Belousov kostik...@gmail.com wrote:
On Thu, Aug 02, 2012 at 09:55:36PM -0400, Alexander Kabaev wrote:
It is weird that program tries to dlopen what appears to be the
binary (itself?), but that did uncover the issue. Please try
attached patch, I only very lightly tested it here.
Also available here:
http://people.freebsd.org/~kan/rtld-digest-notes.diff
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/map_object.c
b/libexec/rtld-elf/map_object.c index 509a64f..350d437 100644
--- a/libexec/rtld-elf/map_object.c
+++ b/libexec/rtld-elf/map_object.c
@@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct
stat *sb) break;
note_start = (Elf_Addr)(char *)hdr + phdr-p_offset;
note_end = note_start + phdr-p_filesz;
- digest_notes(obj, note_start, note_end);
break;
}
@@ -292,6 +291,11 @@ map_object(int fd, const char *path, const
struct stat *sb) obj-relro_page = obj-relocbase +
trunc_page(relro_page); obj-relro_size = round_page(relro_size);
+if (note_start note_end)
+{
+ digest_notes(obj, note_start, note_end);
+}
+
munmap(hdr, PAGE_SIZE);
return (obj);
This is the right fix.
Why do you need the '{}' there ?
I do not. I just automatically followed style used at work. I'll
FreeBSD-fy this before commit.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: rtld dropping core on recent -current
On Thu, 2 Aug 2012 14:39:54 -0700
Steve Kargl s...@troutmask.apl.washington.edu wrote:
% file /usr/local/bin/ppdpo
/usr/local/bin/ppdpo: ELF 32-bit LSB shared object, Intel 80386, \
version 1 (FreeBSD), dynamically linked (uses shared libs),
FreeBSD-style,\ for FreeBSD 10.0 (115), stripped
% ldd /usr/local/bin/ppdpo
/usr/local/bin/ppdpo:
/usr/local/bin/ppdpo: signal 11
It is weird that program tries to dlopen what appears to be the binary
(itself?), but that did uncover the issue. Please try attached patch,
I only very lightly tested it here.
Also available here:
http://people.freebsd.org/~kan/rtld-digest-notes.diff
--
Alexander Kabaev
diff --git a/libexec/rtld-elf/map_object.c b/libexec/rtld-elf/map_object.c
index 509a64f..350d437 100644
--- a/libexec/rtld-elf/map_object.c
+++ b/libexec/rtld-elf/map_object.c
@@ -153,7 +153,6 @@ map_object(int fd, const char *path, const struct stat *sb)
break;
note_start = (Elf_Addr)(char *)hdr + phdr-p_offset;
note_end = note_start + phdr-p_filesz;
- digest_notes(obj, note_start, note_end);
break;
}
@@ -292,6 +291,11 @@ map_object(int fd, const char *path, const struct stat *sb)
obj-relro_page = obj-relocbase + trunc_page(relro_page);
obj-relro_size = round_page(relro_size);
+if (note_start note_end)
+{
+ digest_notes(obj, note_start, note_end);
+}
+
munmap(hdr, PAGE_SIZE);
return (obj);
signature.asc
Description: PGP signature
Re: PCIe hotplug
On Sun, 22 Jul 2012 20:22:33 -0600 Scott Long sco...@samsco.org wrote: On Jul 20, 2012, at 8:04 PM, Julian Elischer wrote: Is anyone looking at PCIe hotplug support? I'm especially interested if anyone has a strategy for device re-insertion and reassociating the reinserted device with its old device_t so that it gets the same unit number.. (assumes access to a serial number or similar) Even if it is put back into a different slot. Would the PCI system be responsible for figuring out this serial number? I don't think that it can, but it's a question to answer, I guess. If it can't then it's up to the driver to generate a unique cookie that would be stored by the PCI subsystem. This cookie would have to be based off of data that can be retrieved from the PCI config space and/or VPD space, since anything more would require resource allocation, which is only allowed in the DEV_ATTACH phase, and once you've hit that phase you've already pretty much sealed the deal on unit number assignment. So what would probably happen is that the PCI layer provides a ring buffer of cookie storage and a set of accessors for the drivers. The cookies would map to a key-value pair with the device unit name and number. During probe, a driver can look at PCI config space and generate a cookie. That cookie can then be communicated up to the PCI layer for storage. Maybe the driver calls a match routine that returns a unit number on match and a store on failure, then the driver calls a set_unit_number accessor. Only the driver that wins the bid would win the unit number reassignment or cookie storage. Or maybe the driver passes the cookie up as part of its return code, and the match and unit assignment happens automatically. Drivers that don't want to participate in this simply wouldn't, and everything would continue to operate the same way. The two sticky parts are rogue/buggy drivers that abuse the api and cause a flood of cookies to be generated, and questions on when a unit number is eligible for reuse. For the first one, a ring buffer of cookies would solve the immediate problem, but you might still have some risk of drivers selectively wrapping the buffer for whatever accidental or evil purpose. For the second problem, maybe a unit number stays persistent only if the PCIe hot remove mechanism requests it, and then only until the ring-buffer wraps. Scott I do not think the whole problem as depicted by Julian is even worth solving. Why keeping any data for the device that might _never_ come back? What if the device hierarchy just starts from the PCI-e and extends upwards and user still holds on to some vestiges of a previous device chain (say, by keeping a character control device sharing the same unit number open, common practice)? Reusing unit number is much trickier then, and might not be even possible. So, before one jumps into 'how', can we agree on 'why' first? When device goes away, it is not just this device's device_t that is disappearing, it is a whole tree rooted at that device. I see no point in trying to reconstruct that. PCI-e hotplug proper is very much orthogonal to the question of unit numbering and IS worth supporting. -- Alexander Kabaev signature.asc Description: PGP signature
Re: MPSAFE VFS -- List of upcoming actions
On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: anything by SoC involved people about NTFS and certainly I don't see a plan to get XFS locked. Stupid question, but what amount of locking does XFS in FreeBSD still need? I'm one of the maintainer of XFS on Linux, and while I know FreeBSD imported a really old version compared to the current one the codebases on IRIX and later Linux never relied on any global Giant-style locking. So if there is anything to fix it would be the in the small bits of FreeBSD-specific code. When I stopped being interested in XFS, I left is marked as non-MPSAFE entirely because of the lack of proper testing and because VFS locking was still evolving, there was no officially proper way of locking the FS and no other FS in the tree was MPSAFE. At that time the only problematic area was around inode instantiation, but sereval other lockingi changes have made it into the tree since then, namely ones that deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit the code and make sure it still makse sense for today's VFS, which is not a huge amount of work. One step further woule be to take most of the XFS from under the exclusive vnode locking to improve the performance. And there is a third option - just let current XFS port die and start with newer version. -- Alexander Kabaev pgpzjQ50DAwMK.pgp Description: PGP signature
Re: MPSAFE VFS -- List of upcoming actions
On Mon, 2 Jul 2012 23:12:06 +0300 Konstantin Belousov kostik...@gmail.com wrote: On Mon, Jul 02, 2012 at 11:03:40AM -0400, Alexander Kabaev wrote: On Mon, Jul 02, 2012 at 02:12:20AM -0400, Christoph Hellwig wrote: On Sun, Jul 01, 2012 at 03:52:05PM +0200, Attilio Rao wrote: anything by SoC involved people about NTFS and certainly I don't see a plan to get XFS locked. Stupid question, but what amount of locking does XFS in FreeBSD still need? I'm one of the maintainer of XFS on Linux, and while I know FreeBSD imported a really old version compared to the current one the codebases on IRIX and later Linux never relied on any global Giant-style locking. So if there is anything to fix it would be the in the small bits of FreeBSD-specific code. When I stopped being interested in XFS, I left is marked as non-MPSAFE entirely because of the lack of proper testing and because VFS locking was still evolving, there was no officially proper way of locking the FS and no other FS in the tree was MPSAFE. At that time the only problematic area was around inode instantiation, but sereval other lockingi changes have made it into the tree since then, namely ones that deal with insmntque and also VOP_LOOKUP changes. To mark XFS MPSAFE, one needs to simply audit the code and make sure it still makse sense for today's VFS, which is not a huge amount of work. One step further woule be to take most of the XFS from under the exclusive vnode locking to improve the performance. If filesystem uses some global internal locks, that locks usually are placed after the vnode locks in global lock order, because VOP methods call into fs with vnode locked. Then, VOP_LOOKUP() usual sequence of events, when method is called with lookup directory locked, causes LOR. It appears because you lock global lock upon entry into VOP_LOOKUP(), and then need to lock the returned vnode. Dropping global lock inside VOP_LOOKUP() usually exposes races which were the reason to introduce the global lock. Having filesystem non-MPSAFE makes the LOR go away without the need to drop global lock. Example of FreeBSD native filesystem which suffered from this issue and required quite non-trivial handling is devfs. Devfs uses per-mount global lock. See devfs_allocv() and devfs_allocv_drop_refs() for the gory details. All very informative, though misplaced in case of XFS. XFS does not use global lock internally, it is quite well locked inside and exclusive _VNODE_ lock we take by default in all methods is usually unnecessary as all it does it prevents other locks in XFS proper from having any useful function. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver Since you did not provide any details, I'd have to guess and I am guessing this is an interaction between rtld and new libstdc++ that is a likely cause for the crashes. Please try with revision r233778. -- Alexander Kabaev signature.asc Description: PGP signature
Re: FreeBSD 10.0-CURRENT/amd64: clientsoftware crashes since make world of today at revision r233779
On Mon, 2 Apr 2012 10:06:38 -0400 Alexander Kabaev kab...@gmail.com wrote: On Mon, 02 Apr 2012 14:32:51 +0200 O. Hartmann ohart...@mail.zedat.fu-berlin.de wrote: Hello out there. My FreeBSD 10 box is at revision r233779. I updated the sources this morning and made a buildworld successfully. After a reboot of the box, I witness several bad issues. Firefox, for instance, is droppimng a core now when starting. Using portmaster for updates produces a lot of Segmentation faults on the screen. Othe minor clients which were working prior to the update today (last makeworl on Friday last week) aren't any more and dropping cores. Does anyone also realize this on FreeBSD 10 boxes? I use CLANG as the base compiler and also for the ports (for those which are compiling with CLANG). Regards, Oliver I guess I should correct myself, you already should have the fix in. Please collect some backtraces. -- Alexander Kabaev signature.asc Description: PGP signature
Re: how to cross-build a single application ?
On Thu, 1 Mar 2012 18:38:19 +0100 Luigi Rizzo ri...@iet.unipi.it wrote: What is the way to properly cross-build a single program (after having gone throught the 'toolchain' and possibly even a full 'buildworld') from the top-level directory of a FreeBSD source tree ? right now i do something like cd $SOURCE_ROOT make MAKEOBJDIRPREFIX=/my_obj_tree TARGET=amd64 buildworld but i seem to remember that there is a more efficient way when you want to rebuild only one program or one subtree. I think i have seen this question being answered from time to time but i can't find how now. any hints ? cheers luigi Something like this should work: cd src/ make buildenv TARGET=... cd usr.bin/blah make -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Sat, 25 Feb 2012 10:41:59 -0800 Tim Kientzle t...@kientzle.com wrote: On Feb 23, 2012, at 9:16 AM, Alexander Kabaev wrote: On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle t...@kientzle.com wrote: If I understand correctly, the libgcc in base is pretty stripped down compared to regular libgcc, because most of that stuff is in our libc instead. You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. So where is __umodsi3 supposed to be defined for ARM? In FreeBSD, libgcc refers to it but does not define it. It's defined in libc. I stumbled across this trying to link some freestanding ARM code using the native cross-compilers. The link failed if I used -nostdlib because of a handful of symbols such as this. Tim I do not know how embedded architectures split it these days and I am not even sure if we have an official ARM port in FSF GCC, but in general these belong in static portion of libgcc.a. If you'd look at bmake glue in gnu/lib/libgcc, you will see that building of __umodsi was there but was disabled by our arm folks presumably because of switch to our own complete softfloat implementation that happens to be in libc. They probably should not have disabled integer math stuff along with libgcc's incomplete floating point implementation, but I guess they had their reasons. Non-embedded architectures do not do that and for amd64/i386 each GCC import since 3.something ensured that libgcc_s.so matched one produced by upstream symbol-by-symbol. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 21:11:13 -0800 Tim Kientzle t...@kientzle.com wrote: On Feb 21, 2012, at 3:39 PM, Daniel Eischen wrote: On Tue, 21 Feb 2012, Steve Kargl wrote: 3) Add a new option to ldconfig to prepend new libraries to the hints files and fix the ports to use this option instead of -m. You don't want system binaries that want /lib/libgcc_s.so.1 to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't your option 3 do that? Why not? Would it cause problems? Is libgcc from GCC 4.6 incompatible with /lib/libgcc? If I understand correctly, the libgcc in base is pretty stripped down compared to regular libgcc, because most of that stuff is in our libc instead. So if there were compatibility problems, I'd expect those to show up when GCC 4.6 linked programs against /usr/local/.../libgcc and /lib/libc. You understand it a bit wrong, but your conclusions are correct. libgcc in base is not stripped in any way and is supposed to be identical to one coming from upstream. As long as upstream maintains backward compatibility, their library should be a perfect replacement for ours. There was a time period while FreeBSD used dynamic unwind into search using dl_iterate_phdr while upstream GCCs didn't, but that was fixed by GCC folks switching GCC to use dl_iterate_phdr on Linux and FreeBSD by default quite while ago. I am not aware of any other incompatibilities at this time. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 11:42:59 -0800 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Tue, Feb 21, 2012 at 08:57:54PM +0200, Konstantin Belousov wrote: On Tue, Feb 21, 2012 at 10:28:50AM -0800, Steve Kargl wrote: troutmask:kargl[210] halfspace /lib/libgcc_s.so.1: version GCC_4.6.0 required by /home/kargl/bin/halfspace not foundtroutmask:kargl[211] (Note, the annoying absense of a newline character after the error message, which is a completely different issue.) I see this problem on both freebsd-i386 and freebsd-amd64. troutmask:kargl[212] ldd ~/bin/halfspace /home/kargl/bin/halfspace: liblapack.so.4 = /usr/local/lib/liblapack.so.4 (0x2008c3000) libblas.so.2 = /usr/local/lib/libblas.so.2 (0x201463000) libgfortran.so.3 = /usr/local/lib/gcc46/libgfortran.so.3 (0x20175d000) libm.so.5 = /lib/libm.so.5 (0x201a7) libgcc_s.so.1 = /lib/libgcc_s.so.1 (0x201c95000) libquadmath.so.0 = /usr/local/lib/gcc46/libquadmath.so.0 (0x201ea2000) libc.so.7 = /lib/libc.so.7 (0x2020d6000) troutmask:kargl[212] ldconfig -r | grep libgcc_s 29:-lgcc_s.1 = /lib/libgcc_s.so.1 723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1 So, it appears that rtld is finding the wrong libgcc_s.so.1 or the lang/gcc port is no longer providing sufficient information for rtld to choose the correct library. I have reverted revisions 230784, 299768, and 229508 (and various combinitions of these revisions) from rtld-elf. The result does not change the above error. I can work around the problem by specifying -static during the building of my programs. Or, I can work around the problem by *explicitly* adding '-rpath /usr/local/lib' to the command line, which I have never had to do. I highly suspect that you just happen to not need a symbol from the newest namespace before. The thing to look first is the library search path in the ld.so hints, which is output at the second line of ldconfig -r. I think that you have /lib before /usr/local/lib/gcc46 in your setup. This guess is confirmed by the numeration of the two instances of gcc_s above. Either change the config, or use -rpath. AFAIR, ldconfig -m adds the directory at the end of the search list. Yes, /lib comes before /usr/local/lib/gcc46. I suppose that this is a heads up for gerald@. lang/gcc is used by the ports collections to build a large number of other ports, so others are likely to hit this issue. I tried reading rtld.c to see where the issue lies. One possibility seems to be a change in rtld.c (lines 4012-13) to remember the version mismatch, then continuing the search to see if another library with the same name but different location matches. After exhausting the list of directories in the search path, either an error is reported or a match has been found. Note, I'm still trying to parse and understand the rtld.c code, so may be what I'm suggesting is not feasible. This was suggested before in a slightly different context and at the time I was not big fan of the idea. With more ports starting to use out of tree GCC, maybe we need to revisit the idea. There are corner cases that I do not know how to handle in this approach: what happens if we have mapped system libgcc_s.so.1 already which did satisfy all the requirements and later a new library gets mapped in dynamically and requires symbol versions from newer GCC? Going with this suggestion will likely involve substantial changes into rtld dependency walking code - we'll need to make a graph traversal and collect all the version information from all the libraries that might satisfy the search before doing the final pass of loading the winning candidates, which implies at least two dependency tree passes. And, given the above, it won't even give us what we want anyway as long as there's dlopen in the picture, so I'd say it is not worth the trouble. Just changing the compiler to supply rpath on binaries it builds might be safer approach. Various GCC builds on Solaris (OpenCSW, Sunfreeware, etc) are doing this for ages and mostly manage to pull things off. Third option is of course purging _all_ toolchain components out of the tree, which is such a fine bikeshed material that I am a bit scared to bring that up. -- Alexander Kabaev signature.asc Description: PGP signature
Re: rtld or lang/gcc cannot find libgcc_s.so.1
On Tue, 21 Feb 2012 15:52:08 -0800
Steve Kargl s...@troutmask.apl.washington.edu wrote:
On Tue, Feb 21, 2012 at 06:39:36PM -0500, Daniel Eischen wrote:
On Tue, 21 Feb 2012, Steve Kargl wrote:
On Tue, Feb 21, 2012 at 05:00:53PM -0500, Diane Bruce wrote:
On Tue, Feb 21, 2012 at 10:37:15PM +0100, Dimitry Andric wrote:
On 2012-02-21 20:42, Steve Kargl wrote:
...
Yes, /lib comes before /usr/local/lib/gcc46. I suppose
that this is a heads up for gerald@. lang/gcc is used by
the ports collections to build a large number of other
ports, so others are likely to hit this issue.
Does -rpath not help ?
I already mentioned that I can add '-rpath /usr/local/lib/gcc46'
to my various projects. I can also build with -static to avoid
rtld. One can also use LD_LIBRARY_PATH.
The issue seems to be that lang/gcc will be installed after
system start, and 'ldconfig -m' appends new shared libraries
to the hints file. This means that libraries with the same
name but different locations will be found via the order of the
search path in the hints file, and one gets the wrong library.
That is, with the following
troutmask:root[256] ldconfig -r | grep libgcc_s
29:-lgcc_s.1 = /lib/libgcc_s.so.1
723:-lgcc_s.1 = /usr/local/lib/gcc46/libgcc_s.so.1
29 will be found before 723. While I can work around the
issue, lang/gcc is used by a rather large boatload of ports
during the building process and I suspect that a large
number of FreeBSD users use lang/gcc for their everyday
compiler. The question is how do we, the FreeBSD project,
deal with this issue, so that the general user base does not
get hit with it.
There are a few solutions:
1) Set ldconfig_paths in /etc/rc.conf to cause ${PORTSDIR}/lib to
be scanned before /lib and /usr/lib.
2) Use /etc/ld.so.conf to cause ${PORTSDIR}/lib to be scanned
for /lib and /usr/lib.
s/for/before/ ??
yes. sorry about the typo.
3) Add a new option to ldconfig to prepend new libraries to
the hints files and fix the ports to use this option instead
of -m.
You don't want system binaries that want /lib/libgcc_s.so.1
to use /usr/local/lib/gccXX/libgcc_s.so.1, though. Wouldn't
your option 3 do that?
Well, yes, I suppose that could be a problem. :)
4) Suggestions from people that are brighter than I.
Well, newer libgcc_s.so.1 should be backward compatible with older
ones, so that should not be the problem and if there are any, we need
to find and fix them.
[Not brighter than you, but]
o For our system libgcc, use libcc_s.so.1 (or some other
name) instead of libgcc_s.so.1?
Interesting idea. Perhaps, the port should install libgcc46_s.so.1,
and binaries installed by lang/gcc updated to use this library.
'shared' portion of libgcc was meant to _be_ shared specifically and in
general having two copies of unwind code and two copied of unwind
frames handling logic is probably not what GCC is expecting.
o Change affected ports to use -rpath when building?
I started to look into this option, but it quickly becomes
apparent that some (evil) configure hackery may be needed.
It can be done in GCC specs for all the programs that use CC driver to
to the linking. Of course, all direct LD invocations will need to be
found and fixed as well, but those were always fragile anyway.
--
Steve
___
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
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Benchmark (Phoronix): FreeBSD 9.0-RC2 vs. Oracle Linux 6.1 Server
On Wed, 04 Jan 2012 14:31:55 -0800 matt...@phoronix.com wrote: Thanks for the comment Arnaud. For comparative benchmarking on[1]Phoronix.com, Michael inva configuration 'in the way the developers or production'. This is by rule. However, i poor scores on be 'it should be tuned, is configured for a diffe The response from us to this comes in two forms. nb 1) If it is the wrong workload for the platform, do a public pos explaining and analysing the results. Highlighting the rationale fo r the concious reduction in performance (ie: journaling filesystems with ba filesystem integrity 2) If tuning can have a material impact on the results, post a t uning guide with step by step and rationale. Ie: educate the communit Michael and I have had many discussions with vendors an on this. In almost all cases, the vendor has either cha default configuration or accepted the results as valid. Asguide, Micha comparison. To dat offer. In part, thi public, but that is more of a result of a one sided d party external to a particular community (with a healthy tou journalisticly pumped compare contrast). For the FreeBSD community, who else outside of the FreeBSD community actually runs public c Matthew Not really related to the discussion on hand, but the above about the most unreadable email I am yet to read on the public mailing list. -- Alexander Kabaev signature.asc Description: PGP signature
Re: GCC debug flags cleanup
On Thu, 22 Dec 2011 12:52:45 +0100 Erik Cederstrand e...@cederstrand.dk wrote: Hi, I've created a patch that cleans up FreeBSD Makefiles that unconditionally set the -g flag for GCC. The motivation for this is that it should be possible to add or remove this flag globally via e.g. CFLAGS (it's part of my quest to produce deterministic builds). I'm not very familiar with GCC or the build infrastructure, so I'd be grateful if someone would review it and possibly commit. http://dev.affect-it.dk/gcc_debug_flags.diff Thanks, Erik___ gnu/usr.bin/cc/cc_tools/Makefile just builds tools that are used for building gcc itself and are non installed anywhere outside of $OBJDIR. I doubt disabling -g there buys you much, but having it there is also of questionable value. Verdict: could not care less either way. All of the gcc/contrib changes are useless - we are not using any of stock Makefiles. sys/amd64/conf/GENERIC - please understang _why_ it is there before you remove it. When you do, you will probably will drop the idea. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Sleeping thread (tid 100033, pid 16): panic in FreeBSD 10.0-CURRENT/amd64 r228662
On Sun, 18 Dec 2011 01:09:00 +0100 O. Hartmann ohart...@zedat.fu-berlin.de wrote: Sleeping thread (tid 100033, pid 16) owns a non sleepable lock panic: sleeping thread cpuid = 0 PID 16 is always USB on my box. You really need to give us a backtrace when you quote panics. It is impossible to make any sense of the above panic message without more context. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Panics after AHCI timeouts
On Wed, 26 Oct 2011 16:00:55 +0200 C. P. Ghost cpgh...@cordula.ws wrote: On Wed, Oct 26, 2011 at 2:27 AM, Alexander Kabaev kab...@gmail.com wrote: I do see timeouts on one of my Samsung ST3750330A disks and they definitely do not cause any panics. The weird part in my case is that disk then immediately reappears as online and mirror zpool can be rebuilt by just onlining the disk with 'zpool online pool disk' command. It seems to be happening once system has accumulated some uptime. If rebooted, it keeps running for a week or two with no issues, but then timeouts start to happen more or less reliably every single 24 hours. Does it correlate with high disk activity, i.e. with periodic(8)? On my machine, I have a feeling that timeouts occur more often at that point, than normally... and that they also occur when multiple processes access the disk simultaneously. If it's only one process, the machine (usually) doesn't hang, even when that process is copying big files back and forth for a long period of time (it's a backup process). But interleave that process with another one accessing the same disk, and poof!, almost immediately ahci timeouts. occur. Very strange... Maybe a race condition of some sort after all? No, I cannot say there is any specific correlation to IO load of the machine, timeouts I saw happen randomly and seem almost always happen as system uptime crosses two weeks boundary. I am suspecting Samsung firmware at this point. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Panics after AHCI timeouts
On Tue, 18 Oct 2011 14:28:07 +0100 Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: Alexey Shuvaev shuv...@physik.uni-wuerzburg.de To: freebsd-current@freebsd.org Sent: Tuesday, October 18, 2011 2:13 PM Subject: Re: Panics after AHCI timeouts On Tue, Oct 18, 2011 at 06:19:19AM +0800, Adrian Chadd wrote: Done, kern/161768. Question to the list: does anybody see successful recovery from AHCI timeout an a recent CURRENT? Recent means June 2011 or newer, so 9.0 branch counts also. That is, there are some kernel messages like this: ahcich0: Timeout on slot 29 port 0 ahcich0: is cs ss rs tfd 40 serr cmd fc17 but then AHCI recovers and the system does not panic? Not a recent CURRENT but on 8.2-RELEASE we have seen recovery on secondary ssd drives without a panic, but it does generally drop the disk and need a power off, power on to recover the disk properly; although we believe that's a firmware bug on the ssds Regards Steve I do see timeouts on one of my Samsung ST3750330A disks and they definitely do not cause any panics. The weird part in my case is that disk then immediately reappears as online and mirror zpool can be rebuilt by just onlining the disk with 'zpool online pool disk' command. It seems to be happening once system has accumulated some uptime. If rebooted, it keeps running for a week or two with no issues, but then timeouts start to happen more or less reliably every single 24 hours. -- Alexander Kabaev signature.asc Description: PGP signature
Re: devel/subversion: svn: Couldn't perform atomic initialization
On Sun, 03 Jul 2011 11:15:50 +0200 Hartmann, O. ohart...@zedat.fu-berlin.de wrote: On 07/02/11 20:45, Alexander Kabaev wrote: On Sat, 02 Jul 2011 09:27:42 +0200 Hartmann, O.ohart...@zedat.fu-berlin.de wrote: SKIP/ Update database/sqlite3 port to the 3.7.7.1 version committed today. Done - and it works fine. Thanks. But why 3.7.7.1 and not 3.7.7.2? Thanks, anyway. Regards, Oliver No reason other than 3.7.7.1 appears to be the latest version currently in ports. -- Alexander Kabaev signature.asc Description: PGP signature
Re: devel/subversion: svn: Couldn't perform atomic initialization
On Sat, 02 Jul 2011 09:27:42 +0200 Hartmann, O. ohart...@zedat.fu-berlin.de wrote: Hello. Since two days now I realize on several recently ports-updated servers a failure of the subversion server running on those servers. Sneaking around the internet I found several issues exactly targeting this error with an sqlite 3.7.7/3.7.7.1 issue, which has been fixed in sqlite-3.7.7.2. At this very moment, our subversion servers in question has all recently been updated and it seems, they all fail the same way. Does anyone also realize this behaviour shown below when commiting? Is there a workaround? Any help or hint is appreciated. Thanks in advance, Oliver Transmitting file data .svn: Commit failed (details follow): svn: Couldn't perform atomic initialization svn: database schema has changed svn: Your commit message was left in a temporary file: Update database/sqlite3 port to the 3.7.7.1 version committed today. -- Alexander Kabaev signature.asc Description: PGP signature
Re: Removal of ICC (intel compiler) bits from mk
On Mon, 18 Apr 2011 15:42:49 +0200 Dimitry Andric d...@freebsd.org wrote: Reviving an old thread(*), I would like to propose to finally remove the Intel C Compiler support from share/mk and other places. As mentioned in that thread, the ICC bits simply do not work anymore, and no one has volunteered to fix it for many years. Please review the attached patch, which cleans up the ICC bits. *) http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019179.html You probably also want to remove the code that uses __INTEL_COMPILER in source tree if you want to be really thorough. -- Alexander Kabaev signature.asc Description: PGP signature
Re: HEADS UP: Removal of libobjc from the base system
On Mon, 18 Apr 2011 06:37:10 -0700 (PDT) Pedro F. Giffuni giffu...@tutopia.com wrote: --- On Mon, 4/18/11, Scott Long sco...@samsco.org wrote: ... Yeah it's too outdated to be of any use. IMHO, you can axe libf2c too... Honest question here, is there a newer version of libf2c that lives in ports and is adopted by people who use fortran? The one that I find in the base system seems to be a similar match to the one in ports/devel/f2c. Is the one in the base system a pain to maintain or otherwise holding back other work, or has it been made obsolete by something in ports? Is removing it from the base system anything more than just churn? I am a moderate user of Fortran: when I need it I use gfortran instead of f2c. lang/f2c is in the ports tree, and the one port I made (tochnog) that actually depends on libf2c uses the port, not the system library. Considering we are not carrying fortran in base anymore, it would seem logical to kill libf2c, but it must be said the f2c port originates in netlib, I have no idea where the GPL'd libf2c comes from or if there is any significant difference. cheers, Pedro. We do not have f2c in tree and it was disconnected from the build even longer than that. -- Alexander Kabaev signature.asc Description: PGP signature
Re: vmware-tools-freebsd No drivers for x.org version: 7.6.5.
On Fri, 8 Apr 2011 14:03:36 +0200 Matthias Apitz g...@unixarea.de wrote: El día Friday, April 08, 2011 a las 12:17:03PM +0200, Dimitry Andric escribió: On 2011-04-08 10:42, Matthias Apitz wrote: I have FreeBSD 9-CURRENT up and running in a VMware Workstation 7.x and I tried to install the vmware-tools-freebsd of VMware to get the driver for Xorg, but it seems that X.org 7.6.5. is not supported. My other VM runs a 8-CURRENT with X.org 7.4_1 which works fine. Any idea how to solve this? Should I go back to X.org 7.4_1 in 9-CURRENT? Or should I fake the vmware-tools installer to see X.org as /.4 while it is 7.6.5? X.org 7.5 already has VMware drivers, so you can just install the x11-drivers/xf86-input-vmmouse and x11-drivers/xf86-video-vmware ports. Alternatively, run make config in x11-drivers/xorg-drivers, check the VMMOUSE and VMWARE entries, and rebuild this meta-port. Dimitry, Thanks for your kind fast answer; does this also mean that I could completely get rid of the VMware' vmware-tools-freebsd? I'm using on the 8-CURRENT system the emulators/open-vom-tools and will install them in the 9-CURRENT too. Thanks again matthias I am not Dmirty, but I will answer anyway. If you install open-vm-tools and xf86-input-vmmouse and xf86-video-vmware drivers, you won't need to bother fighting with vmware tools anymore. The open-vm-tools port installs vmware-user-suid-wrapper binary without SUID bit, you will need to fix that. Also, vmblock driver currently crashes FreeBSD-current kernel, so you will need to remove or rename /boot/modules/vmblock.ko and /usr/local/lib/vmware-tools/modules/drivers/vmblock.ko so that vmware-user-suid-wrapper does not load it for you automatically. -- Alexander Kabaev signature.asc Description: PGP signature
Re: HEADSUP: BSD iconv coming to the base system with default off
On Thu, 24 Feb 2011 22:40:48 +
Gabor Kovesdan ga...@kovesdan.org wrote:
Hi Folks,
I've got some time again to keep working on iconv. The last time I
posted a patch, there were problems with some ports but apart from
this it proved to be quite mature, so I decided to commit it to the
base system but the default setting will be disabled. It can be
enabled by setting the WITH_ICONV knob but whoever does it will take
into account that it may break some ports from being built. However,
this change will help me with future work and will also help
interested people in getting involved in the testing. The rather big
changeset is coming soon.
Regards,
Gabor Kovesdan
Hi Gabor,
for whatever historic reason I had WITH_ICONV in /etc/make.conf on my
desktop, so I got to be your guinea pig without conscious consent for
that role on my part. I did hit several issues so far:
1. mutt-devel port does not consider our implementation as 'good
enough'. It runs the test below, which returns 1, while GNU libiconv
returns 0.
| #include iconv.h
| int main()
| {
| iconv_t cd;
| char buf[4];
| char *ob;
| size_t obl;
| ob = buf, obl = sizeof(buf);
| return ((cd = iconv_open(UTF-8, UTF-8)) != (iconv_t)(-1)
| (iconv(cd, 0, 0, ob, obl) ||
|!(ob == buf obl == sizeof(buf)) ||
|iconv_close(cd)));
| }
2. The implementation of internal locking in citrus_locking.h is a
strange one. Here is why:
Do you really want to have the lock declared as static in header file?
Even is so, please note that declaring data in header file is confusing
and having three locks with the same name is not making the library any
easier to debug.
You need to use proper XXX_STATIC_INITIALIZER constant to initialize
the lock statically, instead of declaring it as static. The code only
works on FreeBSD due to luck and will break if our typedefs for
pthreads lock primitives will ever grow to be the proper structures
instead of simple pointers.
The locking in citrus_mapper.c is broken in case of parallel and
sequential mappers. The file grabs the lock and calls _mapper_open. If
mapper being loaded happens to be of a composite type, it will in turn
try to invoke _mapper_open on subordinate mappers recursively and will
deadlock waiting for the lock it already owns.
And at last, by are you using rwlock if all locking you ever do is an
exclusive one?
3. There are dangerous vestiges of iconv.dir support in citrus_iconv.c
file, _citrus_iconv_open function. You call _lookup_alias there using
an uninitialized path variable, causing every iconv-using program to
try and access garbage.db file. While there, since you are not using
iconv.dir, would it make sense to just merge iconv_std and iconv_none
into libc? Same goes to various flavors of libmapper_*.so, is thee a
reason why each comes in its own trivial shared library?
4. Most of _citrus_blah functions are internal interface between
encoders and mappers and do nto constitute public ABI we as a project
are signing on to support forever. As such, they belong in private
namespace and should not pollute FBSD1.2.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: DTrace Broken?
On Fri, 18 Feb 2011 21:50:59 -0700 Shawn Webb latt...@gmail.com wrote: Disregard. I didn't have ksh93 installed. The handbook implies that it's needed only for DTrace Toolkit, not DTrace itself. Installing ksh93 is required for DTrace proper to work. This cannot possibly be true. % sudo dtrace -l -f acl ID PROVIDERMODULE FUNCTION NAME 1840 dtmalloc acl malloc 1841 dtmalloc act free -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev signature.asc Description: PGP signature
Re: [WORKAROUND] www/seamonkey2 on CURRENT
On Sat, 29 Jan 2011 21:20:12 +0100 Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: On Fri, Jan 28, 2011 at 05:37:51PM -0800, Garrett Cooper wrote: On Fri, Jan 28, 2011 at 3:58 PM, Alexey Shuvaev shuv...@physik.uni-wuerzburg.de wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that ..o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. ls /usr/local/lib/libiconv*so* ? ~ ll /usr/local/lib/libiconv*so* lrwxr-xr-x 1 root wheel 13 Jan 27 13:14 /usr/local/lib/libiconv.so - libiconv.so.3 -r--r--r-- 1 root wheel 1078567 Jan 27 13:14 /usr/local/lib/libiconv.so.3 I'm not so lame :) On Sat, Jan 29, 2011 at 01:39:15PM -0500, Alexander Kabaev wrote: On Sat, 29 Jan 2011 13:21:44 -0500 Alexander Kabaev kab...@gmail.com wrote: On Sat, 29 Jan 2011 13:02:24 -0500 (EST) Daniel Eischen deisc...@freebsd.org wrote: On Sat, 29 Jan 2011, Alexey Shuvaev wrote: Hello! It seems www/seamonkey2 is broken on CURRENT for at least 1 month now [1]. Examining build log and reproducing it locally, the problem is in the usage of libiconv in nsNativeCharsetUtils.cpp. The linker fails to produce libxpcom_core.so although -L/usr/local/lib and -liconv are specified [2]. Examining this further I found that nsNativeCharsetUtils.o produced with [3] fails to link with libiconv alone too [4] (note still unresolved libiconv references). I'm not a compiler/linker guru and do not understand what is happening here. As a workaroud I use the attached patch which disables the usage of libiconv in nsNativeCharsetUtils.cpp. Yes, I had this problem also on -current. Does seamonkey build on recent 8.x? libxpcomio_s.a is a static library that has unresolved references to libiconv. I guess I'd expect those references to be resolved with a later -L/usr/local/lib -liconv when building the shared library (libxpcom_core.so), but they are not. My wild guess: seamonkey tries to hide symbols that are coming from different .o file (this time one from libiconv.a) and that fails with our toolchain. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20218 -- Alexander Kabaev Follow-up to myself: Nope, the fix to said bug appears in our compiler. Can you make amd64 version of nsNativeCharsetUtils. -- Alexander Kabaev ??? (It is already on amd64) Email was sent while not finished. Can you make amd64 version of nsNativeCharsetUtils.o available from somewhere along with corresponding .ii file? To get .ii file you can add -save-temps to GCC invocation used to compile nsNativeCharsetUtils.cpp. -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 23:11:43 +0100 Ulrich Spörlein u...@freebsd.org wrote: On Thu, 20.01.2011 at 15:31:03 -0500, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Just to respond to initial comment, I can live without vgrind in base just fine, provided one cna be installed from ports (looks like that is true). -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 17:11:13 -0800 Marcel Moolenaar xcl...@mac.com wrote: On Jan 20, 2011, at 12:31 PM, Alexander Kabaev wrote: On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. Actually no. The buildtools target is there to allow building programs that are not installed, but are otehrwise needed to compile a program. These are typically little tools that create source files. The bootstrap target is the to deal with compatibility in case we can't use the version on the host or we don't want to depend on the version on the host. Then it is cross-tools, or whatever build stage that builds new gcc and other tools which run on host and are used to generate the final target binaries. The point being that bootstrap-tools target is greatly abused in src, with recent addition of llvm libs making it almost pandemic. -- Alexander Kabaev signature.asc Description: PGP signature
Re: RFC vgrind in base (and buildworld)
On Thu, 20 Jan 2011 21:17:40 +0100 Ulrich Spörlein u...@freebsd.org wrote: Hello, Currently our buildworld relies on groff(1) and vgrind(1) being present in the host system. I have a patch ready that at least makes sure these are built during bootstrap-tools and completes the WITHOUT_GROFF flag. vgrind(1) is only used for two papers under share/doc and we could easily expand the results and commit them to svn directly, alleviating the need to run vgrind(1) during buildworld. OTOH, there are much more useful tools to vgrind(1) for source code formatting. So do we still have vgrind(1) users out there? Regards, Uli Why it needs to be in bootsrap tools at all? We have build tools for this exact purpose. -- Alexander Kabaev signature.asc Description: PGP signature
Re: userland weirdness between r216351 and r216738
On Sat, 1 Jan 2011 01:06:00 + Alexander Best arun...@freebsd.org wrote: i tried adding the following to CFLAGS to prevent clang from using any SSE* instructions, but it seems that doesn't work: CFLAGS=-mno-sse -mno-sse2 -mno-sse3 -mno-3dnow -mno-ssse3 returned: fatal error: error in backend: SSE register return with SSE disabled *** Error code 1 in lib/libcompiler_rt. cheers. alex I do not remember instructing anyone to do what you did. -- Alexander Kabaev signature.asc Description: PGP signature
Re: userland weirdness between r216351 and r216738
On Fri, 31 Dec 2010 22:35:05 +0100 René Ladan r...@freebsd.org wrote: Hi, somewhere between 9.0-amd64 r216351 and r216738, I've noticed some userland weirdness. Symptoms are: - pseudo-random number generator not starting, preventing ssh(d) from working - fonts in X.org (xfce4) missing or replaced - mouse only working when hald is running I don't know if the above symptoms are somehow related, or what causes them. The kernel is GENERIC without (u)lpt and umass and with these modules loaded: fdescfs.ko if_iwn.ko snd_hda.ko sound.ko umass.ko iwn5000fw.ko nvidia.ko (256.53) linux.ko cuse4bsd.ko atapicam.ko linprocfs.ko Kernel and world are compiled with FreeBSD clang version 2.8 (tags/RELEASE_28 115870) 20101007 Reverting to r216351 (kernel, world, mergemaster) brought things back to normal. I can do a binary search if desired. Did someone else also see this? Happy 2011, Rene Try backing out rtld down to version prior to this commit http://svn.freebsd.org/changeset/base/216695 . There is an issue with rtld's use of SSE on amd64 which will be fixed soon. -- Alexander Kabaev signature.asc Description: PGP signature
Re: TTY task group scheduling
On Thu, 18 Nov 2010 18:56:35 + Alexander Best arun...@freebsd.org wrote: On Thu Nov 18 10, Matthew D. Fuller wrote: On Thu, Nov 18, 2010 at 06:23:24PM + I heard the voice of Alexander Best, and lo! it spake thus: judging from the videos the changes are having a huge impact imo. Well, my (admittedly limited, and certainly anecdotal) experience is that Linux's interactive response when under heavy load was always much worse than FreeBSD's. So maybe that's just them catching up to where we already are ;) well...i tried playing back a 1080p vide files while doing `make -j64 buildkernel` and FreeBSD's interactivity seems far from perfect. One thing that just begs to be asked: since when decoding 1080p became an interactive task? -- Alexander Kabaev signature.asc Description: PGP signature
Re: symbol versioning on libgcc?
On Mon, 30 Aug 2010 13:36:03 -0400 Boris Kochergin sp...@acm.poly.edu wrote: Steve Kargl wrote: I know that several libraries in FreeBSD uses symbol versioning. In looking through src/ I was unable to determine whether symbol versioning is used on libgcc. Any guidance would be appreciated. I don't think it is. I haven't poked at any sources, but there are no FBSD* symbols in /usr/lib/libgcc_s.so, which is what's used in symbol versioning in, say, /lib/libc.so.7. -Boris And above is wrong. Just for the record. What FBSD* symbol versions have to do with the library independently versioned by FSF? -- Alexander Kabaev signature.asc Description: PGP signature
Re: Building world with clang
On Tue, 17 Aug 2010 13:32:39 +0200
Dimitry Andric dimi...@andric.com wrote:
Hi,
Since clang has gone into the tree, there has been an effort to get
head in a state where world can optionally be built with it. A
number of changes required for this have already been committed,
mainly thanks to Ed Schouten, Roman Divacky and Rui Paulo. Most of
these changes were adapted from the clangbsd project branch.
There are several other changes in the queue, pending review and/or
further enhancement, but I would like to solicit your comments about
one particular set: the changes required to let buildworld use clang
as the compiler.
Probably the most logical way to specify that you want world built
with clang, is to put CC=clang and CXX=clang++ in /etc/src.conf. Any
necessary modifications to Makefile.inc1 or bsd.*.mk can then be put
between conditionals like:
.if ${CC:T:Mclang} == clang
[...stuff specific to clang...]
.endif
so nothing will change for non-clang builds.
Now, for building clang as the bootstrap compiler, there are basically
two methods to make it use the correct headers, C startup objects, and
libraries from the object tree (${WORLDTMP}):
1) The isysroot method: build a regular version of clang, and make
sure WMAKEENV contains something like:
CC=${CC} -isysroot ${WORLDTMP} -B${WORLDTMP}/usr/lib/ \
-L${WORLDTMP}/usr/lib/
2) The tools-prefix method: build a special version of clang, that
has its default search paths for headers, startup objects and
libraries modified, to look for everything under ${WORLDTMP}.
Method 1) is used in the clangbsd project branch.
Method 2) is similar to what is used for building the in-tree gcc as
the bootstrap compiler. During the cross-tools stage, TOOLS_PREFIX is
defined to point at ${WORLDTMP}, and the bootstrap gcc's built-in
search paths get prefixed with it.
An advantage of method 1) is that it does not require any
modifications to the compiler, and basically just a few extra command
line arguments. The same method could probably even be made to work
for gcc.
However, a disadvantage is that the built-in search paths of the
bootstrap compiler are not entirely disabled by using the -isysroot,
-B and -L flags, so there is still a chance that headers, objects or
libraries outside of ${WORLDTMP} will be picked up during the world
stage.
An advantage of method 2) is that you can be 100% sure all built-in
search paths of the bootstrap compiler point to directories under
${WORLDTMP}. Of course, a disadvantage is that you have to make some
modifications to the compiler source itself.
I would like to hear your opinions about which method is preferred, or
if there may be another good way to solve the bootstrap compiler
issue.
I have also attached two patches to this mail, which can be applied to
head, to show the exact set of changes required for each method.
Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment.
--
Alexander Kabaev
signature.asc
Description: PGP signature
Re: Importing clang/LLVM into FreeBSD HEAD
On Mon, 31 May 2010 12:35:33 -0700 Garrett Cooper yanef...@gmail.com wrote: This in and of itself is an interesting prospect. Why would happen if one could drop in icc for instance :) (I realize that it's basically gcc-compatible, but can this be done today without a lot of rework and effort)? It used to possible, but people who did the work to support ICC dropped any support for their work the minute changes hit the tree and now it is impossible to say how far exactly it has rotten. -- Alexander Kabaev signature.asc Description: PGP signature
Re: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On Mon, 31 May 2010 08:18:42 -0700 Steve Kargl s...@troutmask.apl.washington.edu wrote: On Mon, May 31, 2010 at 05:07:44PM +0200, Dimitry Andric wrote: On 2010-05-31 16:49, Steve Kargl wrote: So, what exactly should we expect, if anything, to break? :) Did you build and install new boot code? ISTR that clang can't compile src/sys/boot/i386/boot0 to the required 512 bytes. No, boot0 is written in assembly, and run through the regular (GNU) assembler. Neither gcc nor clang do anything more except calling the linker. The only component (in the whole clangbsd src tree) which still needs to be compiled with gcc is boot2, which otherwise ends up just a little too big, and doesn't fit. This is being worked on, but it isn't very critical, really. Note that clangbsd automatically uses gcc for this specific code, unless you override it manually. Doesn't this imply that clang/llvm isn't quite ready for deployment. Being able to boot a complete clang/llvm compiled FreeBSD system would seem to be critical. When you say This is being worked on, do you mean clang/llvm is being changed to compile boot2 or do you mean boot2 is being changed to allow clang/lvvm to compile it? FWIW, boot2 was a problem child for each and every GCC import on my memory. Every single major GCC release has claimed better optimizations and more compact generated code and yet they all inevitably generated code which was appreciably bigger than code produced by previus GCC version. This should not be used as an excuse to hold clang at bay, provided base src still comes with working way for building the working boot2 image (gcc). -- Alexander Kabaev signature.asc Description: PGP signature
Re: HEAD can't bring up APs on Intel LC5528(Jasper Forest)
On Tue, 18 May 2010 19:40:13 -0400 Ryan Stone ryst...@gmail.com wrote: amd64 exhibits the same problem, except that it's not even polite and panics without even asking. Could you please try disabling legacy USB device support in BIOS if such an option is provided in your BIOS setup and see if that changes anything? -- Alexander Kabaev signature.asc Description: PGP signature
Re: 4 Clause license?
On Mon, 17 Nov 2003 14:48:08 -0500 Rod Taylor [EMAIL PROTECTED] wrote: The PostgreSQL group has recently had a patch submitted with a snippet of code from FreeBSDs src/bin/mkdir/mkdir.c. http://www.freebsd.org/cgi/cvsweb.cgi/src/bin/mkdir/mkdir.c?annotate=1.27 This appears to be an original UCB Copyright notice. From /usr/src/COPYRIGHT: NOTE: The copyright of UC Berkeley's Berkeley Software Distribution (BSD) source has been updated. The copyright addendum may be found at ftp://ftp.cs.berkeley.edu/pub/4bsd/README.Impt.License.Change and is included below. July 22, 1999 To All Licensees, Distributors of Any Version of BSD: As you know, certain of the Berkeley Software Distribution (BSD) source code files require that further distributions of products containing all or portions of the software, acknowledge within their advertising materials that such products contain software developed by UC Berkeley and its contributors. Specifically, the provision reads: * 3. All advertising materials mentioning features or use of this software *must display the following acknowledgement: *This product includes software developed by the University of *California, Berkeley and its contributors. Effective immediately, licensees and distributors are no longer required to include the acknowledgement within advertising materials. Accordingly, the foregoing paragraph of those BSD Unix files containing it is hereby deleted in its entirety. William Hoskins Director, Office of Technology Licensing University of California, Berkeley -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: [Bug optimization/11741] internal compiler error at gcse.c:5318]
On Sat, 08 Nov 2003 17:08:10 + Jens Rehsack [EMAIL PROTECTED] wrote: Maybe at a good time the next snapshot should be imported into freebsd to get this fix, too :-) Some ports (eg. mysql40, apache) are switchable to high optimization where a bug in gcse could cause invalid code which will be removed with the patch for this bug. Sure, I'll let the system to settle after last snapshot as it is still not clear whether or not it has broken anything. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003 16:55:00 +0100 (CET) C. Kukulies [EMAIL PROTECTED] wrote: I tried to compile a virus-scanner for Linux that allows for scanning Windoze PCs in a network for all sorts of recent viruses (RPC/DCOM and such). http://www.enyo.de/fw/software/doscan Compilation fails with the following: kukuboo2k# gmake g++ -g -O2 -Wall -I/usr/local/include -I. -I. -I./lib \ -MMD -MF src/doscan.d \ -c -o src/doscan.o src/doscan.cc In file included from src/doscan.cc:28: /usr/local/include/getopt.h:115: error: declaration of C function `int getopt() ' conflicts with /usr/include/unistd.h:377: error: previous declaration `int getopt(int, char* const*, const char*)' here gmake: *** [src/doscan.o] Error 1 I wonder where /usr/local/include comes from. If I remove that it compiles smoothly. Uhm, from you command line? What _this_ has to do with a compiler? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: g++ problem
On Thu, 6 Nov 2003 17:44:59 +0100 Marius Strobl [EMAIL PROTECTED] wrote: This happens with g++ 3.x ... This will happen with g++ 3.x, 2.x, 1.x and future 4.x too. I.e. the GCC is not at fault and the subject of the original message is misleading. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
HEADSUP: GCC 3.3.3 snapshot is coming.
Hello all, in preparation for coming code freeze I am going to import a GCC 3.3.3 post-release snapshot. This is supposed to be a minor update with no major functionality or code changes, but it does contain some fixes our sparc64 and amd64 users would like to have prior 5.2-release ships. Unortunately, some of these fixes did not make into GCC 3.3.3-release, hence the snapshot. This will take about two hours, please hold your updates until an 'all clear' message is posted here. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEADSUP: GCC 3.3.3 snapshot is coming.
On Thu, Nov 06, 2003 at 06:19:40PM -0800, Alexander Kabaev wrote: This will take about two hours, please hold your updates until an 'all clear' message is posted here. Done. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: exclusive sleep mutex mntvnode r = 0 (0xffffffff80758220) /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172
On Thu, 30 Oct 2003 10:18:43 -0800 Kris Kennaway [EMAIL PROTECTED] wrote: One of the amd64 machines died with the following. The kernel is a few weeks old, so this might already be fixed. Kris malloc() of 64 with the following non-sleepable locks held: exclusive sleep mutex mntvnode r = 0 (0x80758220) locked @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 recursed on non-recursive lock (sleep mutex) mntvnode @ /a/asami/portbuild/amd64/src-client/sys/kern/vfs_subr.c:1054 first acquired @ /a/asami/portbuild/amd64/src-client/sys/ufs/ffs/ffs_vfsops.c:1172 panic: recurse Debugger(panic) Stopped at Debugger+0x4b: xchgl %ebx,0x31599f db where Debugger() at Debugger+0x4b panic() at panic+0x169 witness_lock() at witness_lock+0x383 _mtx_lock_flags() at _mtx_lock_flags+0x9c insmntque() at insmntque+0x2a vclean() at vclean+0x35b vgonel() at vgonel+0x51 vrecycle() at vrecycle+0x5b ufs_inactive() at ufs_inactive+0x22c ufs_vnoperate() at ufs_vnoperate+0x14 vrele() at vrele+0x11a ffs_sync() at ffs_sync+0x24f sync() at sync+0xdb syscall() at syscall+0x320 Xfast_syscall() at Xfast_syscall+0xa7 --- syscall (36, FreeBSD ELF64, sync), rip = 0x402084, rsp = 0x7648, rbp = 0x3 --- db Known and being looked at. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ld not sucking in /usr/lib/crt1.o - or is it me?
On Mon, 6 Oct 2003 20:52:23 +1100 Chris Knight [EMAIL PROTECTED] wrote: If I add /usr/lib/crt1.o to the file list it works OK. Any reason why ld isn't pulling this in automatically? Feel free to correct me if I'm missing the obvious and if there's a better way of resolving this. Thanks. ld is not supposed to pull in anything except what was given to it on the command line. Why your build tries to use LD where it should be using CC is a separate question though... -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gcc 3.2.2 vs gcc 3.2.3
On Mon, 22 Sep 2003 09:43:39 -0400
Justin Smith [EMAIL PROTECTED] wrote:
make world builds and installs gcc 3.2.3? It can't be as simple as
replacing the compiler source in /usr/src with that of gcc 3.2.3 (or
is it?).
For 3.2.2-to-3.2.3 upgrade the newer sources in
/usrc/contrib/{gcc|libstdc++|libf2c|libobjc} is all you need.
--
Alexander Kabaev
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
GCC 3.3.1-RELEASE is coming
I am about to import an official GCC 3.3.1-release into our source tree. Please hold your updates until 'all clear' message is posted. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1-RELEASE is coming
On Thu, Aug 21, 2003 at 07:55:00PM -0700, Alexander Kabaev wrote: I am about to import an official GCC 3.3.1-release into our source tree. Please hold your updates until 'all clear' message is posted. Done. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
[snip] Curiosity: Why does this suppression get disabled in the imported compiler? I guess justification was to see warnings about FreeBSD's own header files. We dont want to hide warnings in them, we want to fix issues warnings report. C++ headers just a side effect of that decision. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
On Fri, Jul 18, 2003 at 07:07:55PM +0200, Michael Nottebrock wrote: Content-Description: signed data On Friday 18 July 2003 18:14, Alexander Kabaev wrote: Configure ailing due to warnings is a real bug. What do you mean now? Configure is not failing because of warnings, it is failing because of _ERRORS_, errors occur in gcc's libstdc++ bits. They _used to be warnings_ before the import. Then configure runs gcc with wrong parameters. In GCC 3.3 -pedantic implies -pedantic-error, unless -fpermissive is specified too. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
??? The info page doesn't say so. If one can't trust the GNU info pages - what a mess, considered that they refuse to maintain proper manpages either... Confused. Please enlighten me. What kind of enlightenment are you looking for? gcc mailing list address is not secret, I suggest you to take it there if you feel so inclined. GCC _do_ maintain man pages, but in the manner which makes them very inconvenient to import into FreeBSD repo. Since they are now auto-generated from texinfo sources, we now need to merge local FreeBSD changes into .texi files. Wading though merge conflicts in texi files after each import is hardly my idea of fun, but I will not stop you for trying :) -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: some ports are broken after upgrading GCC 3.3.1
On Thu, 17 Jul 2003 14:02:20 -0700 Kris Kennaway [EMAIL PROTECTED] wrote: Sorry, I missed the patch in your email. I'm not certain about your approach...can someone who understands the issues comment on it? Kris I'd rather see all varargs.h consumers be converted to stdarg.h. Old varargs GCC builtins were _removed_ altogether from the compiler sources and we should follow. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc-3.3 issues
s/gcc-3.3/ports/ issues and we are in agreement. Patches to fix broken ports are welcome. Kris is doing a fine job generating a list of what needs to be fixed with his cluster packabe building runs. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Belkin USB2serial F5U103
On Mon, 14 Jul 2003 15:57:54 +0200 Guenter Doerrhoefer [EMAIL PROTECTED] wrote: According to the release note the Belkin F5U103 should be supported. I could not get it to operate, the device is recognized but cannot be configured. Anyone got the Belkin to cooperate with 5.2-current? Hardly a bug report. Care to shed more details? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc 3.3.1
On Sat, 12 Jul 2003 06:08:57 +0400 Sergey Matveychuk [EMAIL PROTECTED] wrote: Don't forget bump __FreeBSD_version. :) What for? Bumped __FreeBSD_cc_version is enough. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: GCC 3.3.1, new warnings with limits
On Sat, 12 Jul 2003 23:13:12 -0400 Craig Rodrigues [EMAIL PROTECTED] wrote: I am guessing that the C preprocessor does not think that it is in a system header, and thus prints out the warning. We specifically disable automatic warning suppression for system headers, because we _want_ to know about them. Your Linux distribution apparently does not care. Any GCC/FreeBSD expert care to comment? ;) Short of fixing offending files in FSF libstdc++ or turning warning suppression back on for standard C++ include files selectively, I have no suggestion. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
The upcoming GCC 3.3+ upgrade
Hello everyone, Since GCC 3.2.x branch is closed in FSF repository and no further releases are planned off the 3.2 branch, it was decided that switching to a more recent and actively maintained GCC 3.3+ is necessary. The system compiler upgrade is in 5.2 TODO list. GCC 3.3+ will be a system compiler throughout RELENG_5 lifetime. Unfortunately, importing a newer GCC means that we'll have yet another ABI breakage on our hands. GCC 3.3 is more strict in C++ area and consequently some of the code that used to be OK with 3.2 will no longer compile. All C++ and C programs using old varargs.h interface will have to be changed to use stdarg.h instead. GCC 3.3 issues a lot more warnings and that will affect programs which were previously WARNS-free. I will commit fixes for most of the warnings in src tree when a new compiler will be imported. Exceptions are some contributed sources and the kernel. Warnings in contributed programs should be fixed in upstream sources and kernel warnings will need attention of people who know each respective kernel part better than me. I plan to disable -Werror for kernel for now. Once offending warnings are fixed, -Werror will be switched back on. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Support for XFS in FreeBSD?
On Wed, 02 Jul 2003 09:23:26 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Eivind Hestnes wrote: Is XFS ported to FreeBSD? If not, what's the status? [ Let's assume this isn't the usual XFS troll. Here is all the historical information about all previous discussions. If you want to discuss this yet again because you are unwilling to take this at face value, and are unwilling to read the mailing list archives, followups are set to FreeBSD-chat. All replies to all followups posted to another FreeBSD-* list will be redirected to FreeBSD-chat ] -- It is not ported. Some people have tried to start a porting project in the past, but that project has so far failed to produce anything, even a simple port of the newfs program. Well, that is a bit unfair. We haven't _released_ anything, but mkfs.xfs port was something we did first, along with the rest of xfsprogs suite. The XFS module was compiling and linking and even was able to mount XFS filesystem all the way with initial (clean) journal check, root inode retrieval, etc. Unfortunately the lack of available time resulted in this project slipping through cracks. There seems to be a new interest in getting it off the ground though. Note: SCO is suing people who have touched Linux code with code from commercial OS's derived from System V. SGI's IRIX, from which XFS comes, is derived from System V, so there is some legal risk involved to anyone doing a port: SCO may sue you, too. I don't know if this effects the projects previous statements. True, this is a danger. There was a certain amount of similarity in XFS sources between FreeBSD kernel internals and Irix interfaces which arguably can be traced to common Unix roots of both systems. SCO might consider XFS theirs some day :) -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: __thread support in -current..
On Tue, 17 Jun 2003 15:34:15 -0700 (PDT) Julian Elischer [EMAIL PROTECTED] wrote: I guess the support is in gcc as Linux and solaris use it, but is our linker close enough to what they use to be able to benefit at all from them? The __thread support is available in GCC 3.3+ only. The new compiler is likely to enter the tree at the end of this month/first week of June. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: libthr.so lib - crashes
On Tue, 10 Jun 2003 02:50:27 +0100 Bruno Afonso [EMAIL PROTECTED] wrote: Hello, I'm using -current from monday and I'm having a lot of crashes on my athlon 2.4+. So far, I've had to stop using it with mozilla 1.4b, FireBird and now it seems to crash pymol too. (python based) I think it's libth library as I don't get crashes without libthr :) How can I help you guys with this? Am I the only one having problems with these apps (ok, pymol is not widely used)? The crash simply locks the apps, and one can only kill it. There's not way to normally close it. Just from the top of my head: Drop into ddb and run look what 'ps' command reports for the stuck process. Do a 'trace pid' in DDB and see what a kernel backtrace looks like. Use gencore to grab a core of the process to see it's userland backtrace. Send all of the above to relevant people and/or threads@ mailing list. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Tue, 03 Jun 2003 18:51:59 +0300 Petri Helenius [EMAIL PROTECTED] wrote: I'm trying to upgrade RELENG_4 to RELENG_5_1 using source and make buildworld compiles a while and then stops with: Question is if this is supported and if yes, what should I do differently? Pete Got your buildworld log saved somewhere? Could you send it to me please. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: RELENG_4 to RELENG_5_1
On Tue, 3 Jun 2003 12:56:01 -0700 Crist J. Clark [EMAIL PROTECTED] wrote: Hmm, I didn't have any trouble building RELENG_5_1 on RELENG_4, but I have been getting the same failure originally quoted when building HEAD on RELENG_4 for several days now. I suggest that the original poster double-check that he has RELENG_5_1 and not HEAD. And I do have buildworld logs. I'll send in a separate mail. No need that. This is a bug and it needs to be fixed. I am working on this. Thanks for the reports. -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm-related panic with 5.1RC1
On Sun, 1 Jun 2003 11:26:12 +0200 (CEST) Martin Blapp [EMAIL PROTECTED] wrote: Hi all, I just got this panic during compile of openoffice Fatal trap 12 while in kernel mode fault virtual address = 0x68 fault code= supervisor read, page not present instruction pointer = 0x8:0xc0271f4d stack pointer = 0x10:0xe6e51ab0 frame pointer = 0x10:0xe6e51ae0 code segement = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32, gran 1 processor flags = interrupt enabled, resume, IOPL =1 current process = 22362 kernel: type 12 trap, code=0 Stopped at _mtx_lock_sleep+0x16d: movl 0x68(%ecx),%edx db trace _mtx_lock_sleep(c082f0b0,0,0,0,c0678415) at _mtx_lock_sleep+0x16d vm_map_delete(c082f000, d0d0d000, d0d11000, e6effda0, c78d5720) at vm_map_delete+0x383) vm_map_remove(c082f000, d0d0d000, d0d11000, e6e51b9c, c03b247f) at vm_map_remove+0x58) kmem_free(c082f000, d0d0d000, 3000, 0, 80) at kmem_free+0x32 cpu_thread_clean(c78d54c0, e6e51bb4,c78d54c0, c78d54c0, e6e51be4) at cpu_thread_clean+0x7f thread_free(c78d54c0, e6e51bd0, c0275839, c67a3000, c6abf030) at thread_free+0x14 thread_reap(c78d55f0) at thread_reap+0x16c thread_wait(c656b000, , 0, c03feb34,0) at thread_wait+0x55 wait1(c6569980, e6e51d10, 0, e6e51d40, c03b0dfa) at wait1+0x738 wait5(c6569980, e6e51d10, 10, c6569980, 4) at wait4+0x20 syscall(2f, 2f, 2f, bfbff074, 325) at syscall+0x2aa Xint0x80_syscall() at Xint0x80_syscall()+0x1d --- syscall (7, FreeBSD ELF32, wait4) eip = 0x807b28b, esp = 0xbfbfefbc, ebp = 0xbfbfefd8) Unfortunatly my partition was too small, so I could not get a dump. I've adjusted this now and the next time it panics I'll have one ready. Martin This is exactly the panic I am seeing on my dual-processor box. My current suspicion is that it somehow relates to the same pcb_ext being freed twice. I do not need OpenOffice to trigger the bug, on SMP configuration it happens all the time. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: policy on GPL'd drivers?
On Tue, 27 May 2003 10:49:40 -0500 David Leimbach [EMAIL PROTECTED] wrote: On Tuesday, May 27, 2003, at 10:40AM, Alexander Kabaev [EMAIL PROTECTED] wrote: On Tue, 27 May 2003 10:32:42 -0500 David Leimbach [EMAIL PROTECTED] wrote: Ugh... the network driver portion of the nforce drivers is *not* GPL'd but it has a linux only and anti-reverse engineeing clause. Dave Then using the diver on FreeBSD will be a NVidia's license violation, wouldn't it? One more reason to keep it out of the tree. Just the network driver... the audio driver in the tarball is still GPL'd. Well, network driver is a special case as it is this weird binary 'kernel' + OS shim combination which is getting popular lately. Have you thought about getting NVidia's permission to link non-GPLed shims with their binary object? A quick scan through NVidia audio driver sources suggests that the device is very similar to Intel ICH2 AC'97-based cards. Should you see is BSD-led ich.c driver can be reused instead of the Linux driver? -- Alexander Kabaev ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: buildkernel and gcc2
Out of curiosity: what on earth makes you think that compiling -current kernel using older build tools has to be supported? On Thu, 20 Mar 2003 03:21:13 + (GMT) RMH [EMAIL PROTECTED] wrote: Hello gentlemen, I have to note that currently it isn't really possible to compile -CURRENT by GCC 2.95.x in the way it has to be. Buildkernel is broken in several places by different means, however GCC 3.2.x passes them successfully, even with no warnings shown. SKIPPED Thank you for reading! --- Regards, Rhett -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
Just committed /usr/src/libexec/rtld-elf/rtld.c v1.76 should fix that. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: gcc3.2.2 import might have trashed ld-elf.so.1
On Sun, 16 Feb 2003 02:09:24 +0800 leafy [EMAIL PROTECTED] wrote: I rebuilt and installed world on Friday and reinstalled ALL my ports with 'portupgrade -ra'. I have found the exact line that will trigger the ld undefined symbol error. /usr/X11R6/bin/uic -nounload -tr tr2i18n -i htmlpageinfo.h ./htmlpageinfo.ui htmlpageinfo.cc.temp ; ret=$?; sed -e s,tr2i18n( \\ ),QString::null,g htmlpageinfo.cc.temp | sed -e s,tr2i18n( \\\, \\ ),QString::null,g | sed -e s,image\([0-9][0-9]*\)_data,img\1_htmlpageinfo,g htmlpageinfo.cc ; rm -f htmlpageinfo.cc.temp ; if test $ret = 0; then echo '#include htmlpageinfo.moc' htmlpageinfo.cc; else rm -f htmlpageinfo.cc ; exit $ret ; fi QT's uic binary does not use libwizards.so. Please take time to dig a little deeper and figure what binary exactly is failing. It is doubtful someone will be able to help you otherwise. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: usbd patch (MAXUSBDEV no more)
On Thu, 13 Feb 2003 11:13:31 -0500 (EST) Andrew R. Reiter [EMAIL PROTECTED] wrote: On Thu, 13 Feb 2003, Adam Migus wrote: :This patch makes usbd track a dynamic number of devices using a list :instead of the static array of 4 devices. It's implemented as a list :but it's very easy to change. Does this list want a lock to protect it? I am unfamiliar with usb locking at the moment, so ignore if stupid. There is nothing to be familiar with at the moment. UBS stack relies on spls on -stable and Giant on -current to protect the data access. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.2 is coming
Apparently, you caught the src tree at the bad moment. See if another cvsup/buildworld changes anything. On Mon, 10 Feb 2003 02:33:48 -0500 Rahul Siddharthan [EMAIL PROTECTED] wrote: Alexander Kabaev wrote: The import should be complete now. Please let us know if you see any problems introduced with this GCC version. cc -O -pipe -mcpu=i686 -march=i686 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/usr/src/i386/usr\ -I/usr/obj/usr/src/i386/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/usr/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -c /usr/src/contrib/gcc/cp/decl.c /usr/src/contrib/gcc/cp/decl.c: In function `cxx_init_decl_processing': /usr/src/contrib/gcc/cp/decl.c:6671: `c_size_type_node' undeclared (first use in this function) /usr/src/contrib/gcc/cp/decl.c:6671: (Each undeclared identifier is reported only once /usr/src/contrib/gcc/cp/decl.c:6671: for each function it appears in.) *** Error code 1 -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC 3.2.2 is coming
I plan to upgrade GCC to the version 3.2.2. Please hold your updates for a while. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: HEADS UP: GCC 3.2.2 is coming
The import should be complete now. Please let us know if you see any problems introduced with this GCC version. On Sun, Feb 09, 2003 at 11:39:25PM -0500, Alexander Kabaev wrote: I plan to upgrade GCC to the version 3.2.2. Please hold your updates for a while. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of cross-releases
There's still one issue to be resolved for i386 on alpha cross-releases: btxld(8) produces a binary image different from when it's run natively This might be related to the failure I've seen trying to cross-compile i386 world on sparc64. btxldr dies with 'short read' error there. Alexander, please commit your patch for gas(1). It works! It was very kind of you to develop it, and it was done incredibly fast. Thanks a lot! Not going to happen until binutils people approve it. I am not sure if the behavior I fixed was not designed to be that way. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0 RC3 usb errors
What USB devices are connected to these ports? On Tue, 14 Jan 2003 20:34:49 -0600 Cagle, John (ISS-Houston) [EMAIL PROTECTED] wrote: I've installed 5.0 RC3 on an HP ProLiant DL380 G3 (which has USB ports), and I'm constantly getting these error messages on the console: uhub0: port error, giving up port 2 uhub0: port error, restarting port 2 What USB devices are connected to these ports? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current/stable remote gdb interoperability
I've seen similar erratic behaviour myself when using gdb without -k command switch. Can it be your problem too? Also, you might want to look for sample .gdbinit files for useful gbd macros other people are using. These files are in the tree somewhere. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
HEADS UP: GCC ABI breakage
An undetected change in GCC 3.2.1-release sources, imported on December 4th, 2002, effectively caused an ABI change on FreeBSD/i386 5.x. The change in GCC source is believed to be a bug and the issue will be brought to attention of GCC developers. Necessary changes to bring our traditional calling convention back have been applied to both CURRENT and RELENG_5_0 branch. Unfortunately, this means that all the software, compiled during the breakage window and which is using functions returning structs by value, will have to be recompiled. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: mozilla-devel port on current
On Fri, 6 Dec 2002 23:26:52 +0200 Vallo Kallaste [EMAIL PROTECTED] wrote: I've built it yesterday together with a lots of other stuff. Using other -march values than i686 is unofficially claimed to be unsupported (kan@freebsd). As others I'll bet the -march=p4 is causing problems, i686 works for me. The only thing I claimed was that using -march=p4 and other options which imply SSE2 with gcc 3.2.x is asking for trouble. Judging by the number of bugfixes that were committed to GCC mainline for SSE2 related problems, I am not that far off base. AFAIK, none of those bugfixes made it back to GCC 3.2.x branch. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Trashed Disk Labels
On Fri, 29 Nov 2002 14:53:06 -0500 (EST) Wesley Morgan [EMAIL PROTECTED] wrote: On Fri, 29 Nov 2002, Kirk McKusick wrote: I have had a report of a disk label getting trashed after booting up to a kernel with the new UFS2 superblock format. I have just checked in an update to ufs/ffs/ffs_vfsops.c (version 1.198) that explicitly checks to make sure that it will not trash your disk label. I highly recommend that you update to this version, even if you are only running with UFS1 filesystems. Kirk McKusick Great! Any tools available to extract my var/db/pkg dirs from this image of my trashed UFS2 filesystem? : -- Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread! To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message I successfully used ffsfind utility to locate filesystem boundaries on a disk I trashed some time ago. I do not have the utility source available anymore, but you can track it down quite easily on google, I believe. The one I used was actually posted for NetBSD, but it compiled with minimal changes on FreeBSD and Solaris too. You will have to teach it to recognize UFS2 magic. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can I safely enable -march=pentium4 now?
On Sat, 30 Nov 2002 04:46:47 +0800 JY [EMAIL PROTECTED] wrote: Can anyone comment on this? I had a bad experience circa Nov 19, which resulted in a very unstable kernel/world combination. Has the issue been resolved? Meaning can I add CPUTYPE?=p4 in /etc/make.conf now? Thank you, JY To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message NO. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
