Re: CURRENT crashes with nvidia GPU BLOB : vm_radix_insert: key 23c078 is already present
On Thu, 2013-08-08 at 11:30 -0700, Adrian Chadd wrote: Can you go over some previous versions in -HEAD and see when it was introduced? -adrian On 8 August 2013 11:10, O. Hartmann ohart...@zedat.fu-berlin.de wrote: The most recent CURRENT doesn't work with the x11/nvidia-driver (which is at 319.25 in the ports and 325.15 from nVidia). After build- and installworld AND successfully rebuilding port x11/nvidia-driver, the system crashes immediately after a reboot as soon the kernel module nvidia.ko seems to get loaded (in my case, I load nvidia.ko via /etc/rc.conf.local since the nVidia BLOB doesn't load cleanly everytime when loaded from /boot/loader.conf). The crash occurs on systems with default compilation options set while building world and with settings like -O3 -march=native. It doesn't matter. FreeBSD and the port x11/nvidia-driver has been compiled with CLANG. Most recent FreeBSD revision still crashing is r254097. When vmcore is saved, I always see something like savecore: reboot after panic: vm_radix_insert: key 23c078 is already present Does anyone has any idea what's going on? Thanks for helping in advance, Oliver I'm seeing a complete deadlock on my T520 with today's current and latest portsnap'd versions of ports for the nvidia-driver updates. A little bisection and help from others seems to point the finger at Jeff's r254025 I'm getting a complete deadlock on X starting, but loading the module seems to have no ill effects. Sean signature.asc Description: This is a digitally signed message part
i386 panic
http://people.freebsd.org/~sbruno/10_i386_vmfault.txt I can never tell if stuff like this is because I'm not nerfing the system RAM correctly or if this is i386 bit-rot. I set hw.physmem=2g in loader.conf to try and get the system to boot, but I don't think I did it right? Sean signature.asc Description: This is a digitally signed message part
Re: i386 panic
Yah, I don't want to access the RAM, I just want the ridiculous box to boot. I'm content, for this test settting, to nerf myself to 4G rams. Sean On Mon, 2013-08-12 at 17:59 -0400, Super Bisquit wrote: You need to enable PAE in the kernel to access that memory. I could be wrong. On Mon, Aug 12, 2013 at 3:43 PM, Sean Bruno sean_br...@yahoo.com wrote: http://people.freebsd.org/~sbruno/10_i386_vmfault.txt I can never tell if stuff like this is because I'm not nerfing the system RAM correctly or if this is i386 bit-rot. I set hw.physmem=2g in loader.conf to try and get the system to boot, but I don't think I did it right? Sean signature.asc Description: This is a digitally signed message part
Re: i386 panic
On Mon, 2013-08-12 at 12:43 -0700, Sean Bruno wrote: http://people.freebsd.org/~sbruno/10_i386_vmfault.txt I can never tell if stuff like this is because I'm not nerfing the system RAM correctly or if this is i386 bit-rot. I set hw.physmem=2g in loader.conf to try and get the system to boot, but I don't think I did it right? Sean The 9.2RC images seem to do the same thing when nerfed to 2G of ram. So, this doesn't appear to be a new regression. stable/7 seems to be happy enough to boot up PAE i386 on it, so I think the previous suggestion of using PAE is the correct one. signature.asc Description: This is a digitally signed message part
Re: i386 panic
On Mon, 2013-08-12 at 21:36 -0600, Scott Long wrote: On Aug 12, 2013, at 1:43 PM, Sean Bruno sean_br...@yahoo.com wrote: http://people.freebsd.org/~sbruno/10_i386_vmfault.txt I can never tell if stuff like this is because I'm not nerfing the system RAM correctly or if this is i386 bit-rot. I set hw.physmem=2g in loader.conf to try and get the system to boot, but I don't think I did it right? That shouldn't happen. Maybe you've run out of kmem? It's limited to only like 400MB on i386. Or maybe you've blown out a data structure with all of those CPUs. Scott Since we can still do this on stable/7 (gross), I kind of think this is a low priority regression. Not even sure where to look, nor do I really want to. :-) If someone has a clueby4 to thwack me around with, I'd appreciate it. Sean p.s. We won't be caring about this for much longer I fear over at $DAYJOB, so if someone wants to address this I can test it for a few more months. After that, we won't care about it too much. signature.asc Description: This is a digitally signed message part
bsd patch regression?
Colin generated a patch for xen things that does some pretty typical behavior. bsdpatch really didn't handle it well and rejected some things and flat out refused to create sys/modules/xenhvm/Makefile for me. http://lists.freebsd.org/pipermail/freebsd-xen/2013-August/001697.html When applying this patch with gnupatch I get: http://people.freebsd.org/~sbruno/gnupatch.txt When applying this patch with bsdpatch I get: http://people.freebsd.org/~sbruno/bsdpatch.txt Any ideas here? signature.asc Description: This is a digitally signed message part
Interesting panic from the Yahoo builder (10-current)
Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin signature.asc Description: This is a digitally signed message part
random(4) update causes mips compile fail | mips boot fail
with nodevice random I can no longer compile for MIPS --- kernel.debug --- pseudo_rng.o:(.data+0x3c): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x44): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x74): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x78): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x84): undefined reference to `random_null_func' pseudo_rng.o:(.data+0x8c): more undefined references to `random_null_func' follow random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x40): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking. signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 18:34 +0100, Mark R V Murray wrote: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking. Can you please see if you can get the output of sysctl -a | grep random at that point? Nope, the system is stalled at that point so there's no interactivity. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 18:39 +0100, Mark R V Murray wrote: On 7 Sep 2013, at 17:43, Sean Bruno sean_br...@yahoo.com wrote: trying to enable random on my DIR-825 kernconf I get this on boot: Configuration file: /etc/cfg/hostapd.wlan0.conf Using interface wlan0 with hwaddr 00:00:88:88:22:22 and ssid TESTBRUNO Entropy device is blocking Please make a change to sys/dev/random/randomdev_soft.c; Around line 82, please change from .seeded = 0 to .seeded = 1. If that works, then your report above with the Entropy device is blocking. is trying to read random numbers before /dev/random is secure; this is a BAD security problem. M Looks like it does indeed work if that is set to 1. This DIR-825 config, should be loading random as a module, not built into the kernel due to size limitations of the kernel on this board. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 19:40 +0100, Mark R V Murray wrote: Looks like it does indeed work if that is set to 1. This DIR-825 config, should be loading random as a module, not built into the kernel due to size limitations of the kernel on this board. Hmm. I'll set it back to 1, but this is technically a security issue. Thanks for the report back, and sorry for the hassles! M -- Mark R V Murray Ok. Right now, the mips kernel doesn't build unless I have random built in, we were using it as a module previously. Sean signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
On Sat, 2013-09-07 at 19:56 +0100, Mark R V Murray wrote: Ok. Right now, the mips kernel doesn't build unless I have random built in, we were using it as a module previously. I'm testing a fix, but if you want to help out, please move the random_null_func() from randomdev.c to pseudo_rng.c in sys/dev/random. Patch enclosed. Thanks! M Closer: --- kernel.debug --- linking kernel.debug random_adaptors.o: In function `random_sysctl_active_adaptor_handler': /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): undefined reference to `random_get_active_adaptor' /home/sbruno/bsd/head/sys/dev/random/random_adaptors.c:(.text+0x2dc): relocation truncated to fit: R_MIPS_26 against `random_get_active_adaptor' *** [kernel.debug] Error code 1 signature.asc Description: This is a digitally signed message part
Re: random(4) update causes mips compile fail | mips boot fail
Nearly there - I saw that too. Proposed fix enclosed. M Compile succeeds, booted up and I still see the blocking message and the machine does not post fully. setting sys/dev/random/randomdev_soft.c .seeded = 1. allows the system to boot properly. Sean signature.asc Description: This is a digitally signed message part
Re: Interesting panic from the Yahoo builder (10-current)
On Sat, 2013-09-07 at 17:05 +0200, Davide Italiano wrote: On Fri, Sep 6, 2013 at 6:00 PM, Sean Bruno sean_br...@yahoo.com wrote: Our yBSD builder needs to mount a disk image temporarily that has a dos partition (for openstack-ish things) to put configs into it. It seems that under high stress, we can squeeze a panic out of it in namei(). Sean Unread portion of the kernel message buffer: panic: namei: nameiop contaminated with flags cpuid = 8 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe048d8e53b0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe048d8e5460 vpanic() at vpanic+0x126/frame 0xfe048d8e54a0 kassert_panic() at kassert_panic+0x136/frame 0xfe048d8e5510 namei() at namei+0x2c8/frame 0xfe048d8e5600 msdosfs_mount() at msdosfs_mount+0x556/frame 0xfe048d8e57c0 vfs_donmount() at vfs_donmount+0xc35/frame 0xfe048d8e5aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe048d8e5ae0 amd64_syscall() at amd64_syscall+0x223/frame 0xfe048d8e5bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe048d8e5bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x8000a8b68a, rsp = 0x7fffd508, rbp = 0x7fffdb30 --- Uptime: 34m55s Dumping 1140 out of 16350 MB:..2%..12%..22%..31%..41%..51%..61%..71%..82%..92% Reading symbols from /boot/modules/msdosfs.ko...done. Loaded symbols for /boot/modules/msdosfs.ko #0 doadump (textdump=1) at pcpu.h:227 227 pcpu.h: No such file or directory. in pcpu.h (kgdb) Hangup detected on fd 0 error detected on stdin Can you please print the value of cnp-cn_nameiop (or, even better, the whole struct) before the panic? Thanks, Hrm ... tried to reproduce after recompiling the kernel (turning off KDB_UNATTENDED) and its not happening now. I'll keep an eye out for it. Sean signature.asc Description: This is a digitally signed message part
Doing it wrong: Building world with lang/clang-devel
wow, that didn't work at all. :-) I set these in make.conf: CC=/usr/local/bin/clang C++=/usr/local/bin/clang++ CPP=/usr/local/bin/clang++ It exploded pretty badly: http://people.freebsd.org/~sbruno/doingitwrong.txt Any reason that this shouldn't work? $ pkg info |grep clang clang-devel-3.4.r189172C, Objective-C, and C++ compiler signature.asc Description: This is a digitally signed message part
panic: Lock lle not exclusively locked @ /usr/src/sys/kern/kern_rwlock.c:140
Got a panic this morning after updating to 10.0-ALPHA-2 today while installing ports to a clean system. I can hold the box at the db prompt for a bit if someone wants me to look at things Sean signature.asc Description: This is a digitally signed message part
Re: Doing it wrong: Building world with lang/clang-devel and lang/gcc49
On Sun, 2013-09-22 at 16:53 -0500, Brooks Davis wrote: On Sat, Sep 21, 2013 at 03:42:16PM +0400, Lev Serebryakov wrote: Hello, Sean. You wrote 20 2013 ??., 22:39:30: SB wow, that didn't work at all. :-) SB I set these in make.conf: SB CC=/usr/local/bin/clang SB C++=/usr/local/bin/clang++ SB CPP=/usr/local/bin/clang++ SB It exploded pretty badly: SB http://people.freebsd.org/~sbruno/doingitwrong.txt SB Any reason that this shouldn't work? Try XCC=/usr/local/bin/clang XCXX=/usr/local/bin/clang++ XCPP=/usr/local/bin/clang++ COMPILER_TYPE=clang It should work, at least, in theory. You will likely also need -WITHOUT_FORMAT_EXTENSIONS. -- Brooks Well, I've tried clang-devel, gcc46 and gcc49. Each one yeilds different failures and I'm really just totally confused at this point. I've set: export XCC=/usr/local/bin/gcc49 export XCXX=/usr/local/bin/g++49 export XCPP=/usr/local/bin/g++49 export CC=/usr/local/bin/gcc49 export CXX=/usr/local/bin/g++49 export CPP=/usr/local/bin/g++49 export COMPILER_TYPE=gcc and export TARGET=mips export TARGET_ARCH=mips export SRCCONF=/dev/null export SRCROOT=/home/sbruno/bsd/fbsd_head export MAKEOBJDIRPREFIX=/var/tmp export DESTDIR=/mipsbuild/$TARGET_ARCH export KERNCONF=MALTA == usr.bin/dtc (obj,depend,all,install) --- obj --- /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc created for /home/sbruno/bsd/fbsd_head/usr.bin/dtc --- .depend --- rm -f .depend CC='/usr/local/bin/gcc49' mkdep -f .depend -a -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc echo dtc: /usr/lib/libc.a /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib/libegacy.a .depend echo dtc: /usr/lib/libstdc++.a .depend make[3]: /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc/.depend, 347: ignoring stale .depend for /usr/lib/libstdc++.a --- dtc.o --- --- input_buffer.o --- --- string.o --- --- dtb.o --- --- fdt.o --- --- checking.o --- --- dtc.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc --- input_buffer.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc --- string.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc --- dtb.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc --- fdt.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc --- checking.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc --- string.o --- In file included from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.hh:35:0, from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.hh:35, from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc:33: /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:21: error: 'uint8_t' was not declared in this scope typedef std::vectoruint8_t byte_buffer; ^ /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:28: error: template argument 1 is invalid typedef std::vectoruint8_t byte_buffer; with gcc49 I get even more peculiar behavior: === gnu/usr.bin/gperf/doc (depend) make[3]: /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/.depend, 145: ignoring stale .depend for /usr/lib/libstdc++.a --- gperf --- /usr/local/bin/clang++ -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf -static -L/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o -legacy /usr/local/bin/ld: cannot find -lstdc++ clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [gperf] Error code 1 signature.asc Description: This is a digitally signed message part
Re: Doing it wrong: Building world with lang/clang-devel and lang/gcc49
On Tue, 2013-09-24 at 22:15 -0700, Sean Bruno wrote: On Sun, 2013-09-22 at 16:53 -0500, Brooks Davis wrote: On Sat, Sep 21, 2013 at 03:42:16PM +0400, Lev Serebryakov wrote: Hello, Sean. You wrote 20 2013 ??., 22:39:30: SB wow, that didn't work at all. :-) SB I set these in make.conf: SB CC=/usr/local/bin/clang SB C++=/usr/local/bin/clang++ SB CPP=/usr/local/bin/clang++ SB It exploded pretty badly: SB http://people.freebsd.org/~sbruno/doingitwrong.txt SB Any reason that this shouldn't work? Try XCC=/usr/local/bin/clang XCXX=/usr/local/bin/clang++ XCPP=/usr/local/bin/clang++ COMPILER_TYPE=clang It should work, at least, in theory. You will likely also need -WITHOUT_FORMAT_EXTENSIONS. -- Brooks Well, I've tried clang-devel, gcc46 and gcc49. Each one yeilds different failures and I'm really just totally confused at this point. I've set: export XCC=/usr/local/bin/gcc49 export XCXX=/usr/local/bin/g++49 export XCPP=/usr/local/bin/g++49 export CC=/usr/local/bin/gcc49 export CXX=/usr/local/bin/g++49 export CPP=/usr/local/bin/g++49 export COMPILER_TYPE=gcc and export TARGET=mips export TARGET_ARCH=mips export SRCCONF=/dev/null export SRCROOT=/home/sbruno/bsd/fbsd_head export MAKEOBJDIRPREFIX=/var/tmp export DESTDIR=/mipsbuild/$TARGET_ARCH export KERNCONF=MALTA == usr.bin/dtc (obj,depend,all,install) --- obj --- /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc created for /home/sbruno/bsd/fbsd_head/usr.bin/dtc --- .depend --- rm -f .depend CC='/usr/local/bin/gcc49' mkdep -f .depend -a -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc echo dtc: /usr/lib/libc.a /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib/libegacy.a .depend echo dtc: /usr/lib/libstdc++.a .depend make[3]: /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/usr.bin/dtc/.depend, 347: ignoring stale .depend for /usr/lib/libstdc++.a --- dtc.o --- --- input_buffer.o --- --- string.o --- --- dtb.o --- --- fdt.o --- --- checking.o --- --- dtc.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtc.cc --- input_buffer.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.cc --- string.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc --- dtb.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/dtb.cc --- fdt.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/fdt.cc --- checking.o --- /usr/local/bin/g++49 -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -c /home/sbruno/bsd/fbsd_head/usr.bin/dtc/checking.cc --- string.o --- In file included from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/input_buffer.hh:35:0, from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.hh:35, from /home/sbruno/bsd/fbsd_head/usr.bin/dtc/string.cc:33: /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:21: error: 'uint8_t' was not declared in this scope typedef std::vectoruint8_t byte_buffer; ^ /home/sbruno/bsd/fbsd_head/usr.bin/dtc/util.hh:53:28: error: template argument 1 is invalid typedef std::vectoruint8_t byte_buffer; with gcc49 I get even more peculiar behavior: === gnu/usr.bin/gperf/doc (depend) make[3]: /var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/.depend, 145: ignoring stale .depend for /usr/lib/libstdc++.a --- gperf --- /usr/local/bin/clang++ -O2 -pipe -I/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/include -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/home/sbruno/bsd/fbsd_head/gnu/usr.bin/gperf -static -L/var/tmp/mips.mips/home/sbruno/bsd/fbsd_head/tmp/legacy/usr/lib -o gperf bool-array.o hash-table.o input.o keyword-list.o keyword.o main.o options.o output.o positions.o search.o version.o getline.o hash.o -legacy /usr/local/bin/ld: cannot find -lstdc++ clang: error: linker command failed with exit code 1
Re: XEN additions cause failure to compile kernel
On Tue, 2013-10-01 at 17:34 +0100, John wrote: Hello list. Using latest sources: root@host0:/usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: https://svn0.eu.freebsd.org/base/releng/9.2 Relative URL: ^/releng/9.2 Repository Root: https://svn0.eu.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 255973 Node Kind: directory Schedule: normal Last Changed Author: gjb Last Changed Rev: 255896 Last Changed Date: 2013-09-26 19:10:19 +0100 (Thu, 26 Sep 2013) I'm trying to compile the XEN options on a host server on 9.2-R and get the following failure during make: [...] clang -c -O2 -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I../../.. -I../../../contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror ../../../xen/evtchn/evtchn_dev.c ../../../xen/evtchn/evtchn_dev.c:321:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_version: D_VERSION, ^~ .d_version = ../../../xen/evtchn/evtchn_dev.c:322:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_open: evtchn_open, ^~~ .d_open = ../../../xen/evtchn/evtchn_dev.c:323:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_close: evtchn_close, ^~~~ .d_close = ../../../xen/evtchn/evtchn_dev.c:324:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_read: evtchn_read, ^~~ .d_read = ../../../xen/evtchn/evtchn_dev.c:325:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_write: evtchn_write, ^~~~ .d_write = ../../../xen/evtchn/evtchn_dev.c:326:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_ioctl: evtchn_ioctl, ^~~~ .d_ioctl = ../../../xen/evtchn/evtchn_dev.c:327:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_poll: evtchn_poll, ^~~ .d_poll = ../../../xen/evtchn/evtchn_dev.c:328:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_name: evtchn, ^~~ .d_name = ../../../xen/evtchn/evtchn_dev.c:329:2: error: use of GNU old-style field designator extension [-Werror,-Wgnu-designator] d_flags: 0, ^~~~ .d_flags = 9 errors generated. *** [evtchn_dev.o] Error code 1 Stop in /usr/src/sys/amd64/compile/HOST0. root@host0:/sys/amd64/compile/HOST0 # It compiles fine without these options: options NO_ADAPTIVE_MUTEXES options NO_ADAPTIVE_RWLOCKS options NO_ADAPTIVE_SX # Xen HVM support options XENHVM device xenpci Are these options depricated now? thanks, Can you post your complete kernconf? sean signature.asc Description: This is a digitally signed message part
Re: XEN additions cause failure to compile kernel
On Tue, 2013-10-01 at 22:17 +0100, John wrote: On Tue, Oct 01, 2013 at 12:06:13PM -0700, Sean Bruno wrote: Can you post your complete kernconf? sean Hi, Here it is: Ok, so this email thread is on freebsd-current and I think you're trying to buld a XENHVM kernel for stable/9 ? What happens if you use the provided XENHVM kernconf? Sean ## cpu HAMMER ident HOST0 #makeoptionsDEBUG=-g# Build kernel with gdb(1) debug symbols #makeoptionsWITH_CTF=1 # Run ctfconvert(1) for DTrace support options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options INET6 # IPv6 communications protocols options TCP_OFFLOAD # TCP offload options SCTP# Stream Control Transmission Protocol options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_ACL # Support for access control lists options UFS_DIRHASH # Improve performance on big directories options UFS_GJOURNAL# Enable gjournal-based UFS journaling options QUOTA # Enable disk quotas for UFS options MD_ROOT # MD is a potential root device options NFSCL # New Network Filesystem Client options NFSD# New Network Filesystem Server options NFSLOCKD# Network Lock Manager options NFS_ROOT# NFS usable as /, requires NFSCL options MSDOSFS # MSDOS Filesystem options CD9660 # ISO 9660 Filesystem options PROCFS # Process filesystem (requires PSEUDOFS) options PSEUDOFS# Pseudo-filesystem framework options GEOM_PART_GPT # GUID Partition Tables. options GEOM_RAID # Soft RAID functionality. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD32# Compatible with i386 binaries options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=500 # Delay (in ms) before probing SCSI #optionsKTRACE # ktrace(1) support #optionsSTACK # stack(9) support options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. options KBD_INSTALL_CDEV# install a CDEV entry in /dev #optionsHWPMC_HOOKS # Necessary kernel hooks for hwpmc(4) #optionsAUDIT # Security event auditing #optionsMAC # TrustedBSD MAC Framework #optionsKDTRACE_FRAME # Ensure frames are compiled in #optionsKDTRACE_HOOKS # Kernel DTrace hooks #optionsINCLUDE_CONFIG_FILE # Include this file in kernel #optionsKDB # Kernel debugger related code #optionsKDB_TRACE # Print a stack trace for a panic #optionsDDB_CTF # kernel ELF linker loads CTF data options NO_ADAPTIVE_MUTEXES options NO_ADAPTIVE_RWLOCKS options NO_ADAPTIVE_SX #options XENHVM #device xenpci # Make an SMP-capable kernel by default options SMP # Symmetric MultiProcessor Kernel # CPU frequency control #device cpufreq # Bus support. device acpi device pci # Floppy drives #device fdc # ATA controllers device ahci# AHCI-compatible SATA controllers device ata # Legacy ATA/SATA controllers options ATA_CAM # Handle legacy controllers with CAM options ATA_STATIC_ID # Static device numbering #device mvs # Marvell 88SX50XX/88SX60XX/88SX70XX/SoC SATA #device siis# SiliconImage SiI3124/SiI3132/SiI3531 SATA # SCSI Controllers device ahc # AHA2940 and onboard AIC7xxx devices options AHC_REG_PRETTY_PRINT# Print register bitfields in debug
drm2/radeon dfixed_trunc() warnings
These caught my eye today, and the checks strewn about sys/dev/drm2/radeon seem completely bogus to me, but I don't have the h/w to test it at the moment. /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/rs690.c:491:37: warning: comparison of unsigned expression 0 is always false [-Wtautological-compare] if (dfixed_trunc(priority_mark02) 0) dfixed_trunc is a macro: drm_fixed.h:#define dfixed_trunc(A) ((A).full 12) that returns the output of a shift right operation ... priority_mark02 is of type union fixed20_12, single element union of type u32, so I can't see this check ever doing anything useful. But, as always, I'm probably missing something obvious. Sean signature.asc Description: This is a digitally signed message part
X related ports not finding version strings and hanging
Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be causing problems duing the update. When this happens, some prompt is waiting for me to hit enter that has scrolled past and I cannot see it. === All cairo-1.10.2_5,2 libGL-8.0.5_4 (13/35) make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' signature.asc Description: This is a digitally signed message part
Re: X related ports not finding version strings and hanging
On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be causing problems duing the update. When this happens, some prompt is waiting for me to hit enter that has scrolled past and I cannot see it. === All cairo-1.10.2_5,2 libGL-8.0.5_4 (13/35) make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' make: /usr/ports/Mk/bsd.xorg.mk line 158: warning: Couldn't read shell's output for /usr/local/bin/X -version 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild it. sean signature.asc Description: This is a digitally signed message part
[patch] Re: drm2/radeon dfixed_trunc() warnings
On Sun, 2013-10-06 at 14:39 -0700, Sean Bruno wrote: These caught my eye today, and the checks strewn about sys/dev/drm2/radeon seem completely bogus to me, but I don't have the h/w to test it at the moment. /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/rs690.c:491:37: warning: comparison of unsigned expression 0 is always false [-Wtautological-compare] if (dfixed_trunc(priority_mark02) 0) dfixed_trunc is a macro: drm_fixed.h:#define dfixed_trunc(A) ((A).full 12) that returns the output of a shift right operation ... priority_mark02 is of type union fixed20_12, single element union of type u32, so I can't see this check ever doing anything useful. But, as always, I'm probably missing something obvious. Sean Proposed patch to eliminate this check. If I understand the macro correctly, there's no way for these checks to ever do anything as bit shifting an unsigned will simply clear out the value. So, the check for 0 is completely bogus? Sean http://people.freebsd.org/~sbruno/drm2_radeon_useless.txt signature.asc Description: This is a digitally signed message part
i386-wine + 10.0
I think I built everything according to https://wiki.freebsd.org/i386-Wine and got a package out of it. I think I missed something obvious here. When I try to run simple windows things I get: err:module:load_builtin_dll failed to load .so lib for builtin Lwinex11.drv: /usr/local/lib/libXext.so.6: unsupported file layout Application tried to create a window, but no driver could be loaded. Unknown error (127). Application tried to create a window, but no driver could be loaded. Unknown error (127). err:module:load_builtin_dll failed to load .so lib for builtin Lwinex11.drv: /usr/local/lib/libXext.so.6: unsupported file layout Application tried to create a window, but no driver could be loaded. Unknown error (127). err:module:load_builtin_dll failed to load .so lib for builtin Lwinex11.drv: / FreeBSD powernoodle 10.0-ALPHA3 FreeBSD 10.0-ALPHA3 #26 r255930M: Sat Sep 28 12:22:28 PDT 2013 sbruno@powernoodle:/usr/obj/usr/src/sys/POWERNOODLE amd64 signature.asc Description: This is a digitally signed message part
Re: i386-wine + 10.0
On Sat, 2013-10-12 at 13:12 +0200, Tomasz Kowalczyk wrote: When I try to run simple windows things I get: err:module:load_builtin_dll failed to load .so lib for builtin Lwinex11.drv: /usr/local/lib/libXext.so.6: unsupported file layout Think I had to add: /usr/local/lib /usr/local/lib32 to /etc/libmap32.conf, Yepper. This was it. Thank you. Sean grumbling at ports Bruno signature.asc Description: This is a digitally signed message part
contrib/gcclibs/libssp security warning
There's an unchecked syslog call inside of libssp/ssp.c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:137:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] syslog (LOG_CRIT, msg1); ^~~~ 1 warning generated. /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:137:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] syslog (LOG_CRIT, msg1); I propose the following change: Index: contrib/gcclibs/libssp/ssp.c === --- contrib/gcclibs/libssp/ssp.c(revision 256712) +++ contrib/gcclibs/libssp/ssp.c(working copy) #ifdef HAVE_SYSLOG_H /* Only send the error to syslog if there was no tty available. */ else -syslog (LOG_CRIT, msg3); +syslog (LOG_CRIT, %s, msg3); #endif /* HAVE_SYSLOG_H */ signature.asc Description: This is a digitally signed message part
gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
gperf has some clang warnings that seem to be harmless, but annoying
regarding some of the logical operations around detecting ascii chars:
c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -Wno-c
++11-extensions -I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib
-I/usr/src/gnu/usr.bin/g
perf -c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc:284:27:
warning: '' within '||' [-Wlogical-op-parentheses]
if (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg = 'z')
^~ ~~
I propose the following change:
Index: options.cc
===
--- options.cc (revision 256712)
+++ options.cc (working copy)
@@ -281,7 +281,7 @@
{
putchar (*arg);
arg++;
- if (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg = 'z')
+ if ( (*arg = 'A' *arg = 'Z') || (*arg = 'a' *arg =
'z') )
{
putchar (*arg);
arg++;
@@ -293,7 +293,9 @@
putchar (*arg);
arg++;
}
- while (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg
= 'z' || *arg == '-');
+ while ( (*arg = 'A' *arg = 'Z') ||
+ (*arg = 'a' *arg = 'z') ||
+ (*arg == '-') );
if (*arg == '=')
{
putchar (*arg);
signature.asc
Description: This is a digitally signed message part
Re: contrib/gcclibs/libssp security warning
On Mon, 2013-10-21 at 08:44 +0200, Dimitry Andric wrote: On Oct 21, 2013, at 05:47, Sean Bruno sean_br...@yahoo.com wrote: There's an unchecked syslog call inside of libssp/ssp.c /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:137:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] syslog (LOG_CRIT, msg1); ^~~~ 1 warning generated. /usr/src/gnu/lib/libssp/../../../contrib/gcclibs/libssp/ssp.c:137:23: warning: format string is not a string literal (potentially insecure) [-Wformat-security] syslog (LOG_CRIT, msg1); I propose the following change: Index: contrib/gcclibs/libssp/ssp.c === --- contrib/gcclibs/libssp/ssp.c(revision 256712) +++ contrib/gcclibs/libssp/ssp.c(working copy) #ifdef HAVE_SYSLOG_H /* Only send the error to syslog if there was no tty available. */ else -syslog (LOG_CRIT, msg3); +syslog (LOG_CRIT, %s, msg3); #endif /* HAVE_SYSLOG_H */ Heh, this is also still in upstream gcc. :-) It should not be a real security problem, as the fail() function is only ever called twice, with predictable const char arguments. But better safe than sorry, so LGTM. -Dimitry done at svn r256866 sean signature.asc Description: This is a digitally signed message part
Re: gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
On Sun, 2013-10-20 at 23:50 -0400, Sean Bruno wrote:
gperf has some clang warnings that seem to be harmless, but annoying
regarding some of the logical operations around detecting ascii chars:
c++ -O2 -pipe -I/usr/obj/usr/src/tmp/legacy/usr/include -Wno-c
++11-extensions
-I/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib
-I/usr/src/gnu/usr.bin/g
perf
-c /usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc
/usr/src/gnu/usr.bin/gperf/../../../contrib/gperf/src/options.cc:284:27:
warning: '' within '||' [-Wlogical-op-parentheses]
if (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg =
'z')
^~ ~~
Heh, Matthew suggested the obvious in private mail, it seems that this
would be better spelled as isalpha :-)
Index: contrib/gperf/src/options.cc
===
--- contrib/gperf/src/options.cc(revision 256865)
+++ contrib/gperf/src/options.cc(working copy)
@@ -281,7 +281,7 @@
{
putchar (*arg);
arg++;
- if (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg = 'z')
+ if (isalpha(*arg))
{
putchar (*arg);
arg++;
@@ -293,7 +293,7 @@
putchar (*arg);
arg++;
}
- while (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg
= 'z' || *arg == '-');
+ while (isalpha(*arg) || *arg == '-');
if (*arg == '=')
{
putchar (*arg);
signature.asc
Description: This is a digitally signed message part
Re: gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
On Tue, 2013-10-22 at 09:47 +0100, David Chisnall wrote:
On 22 Oct 2013, at 00:43, Sean Bruno sean_br...@yahoo.com wrote:
Heh, Matthew suggested the obvious in private mail, it seems that this
would be better spelled as isalpha :-)
This looks wrong. The behaviour of isalpha() depends on the current locale.
You probably want isalpha_l(), with the C locale.
David
Took me a bit of wrangling to figure out what the proper implementation
of isalpha_l() and friends.
How about this then?
Index: options.cc
===
--- options.cc (revision 257083)
+++ options.cc (working copy)
@@ -28,6 +28,7 @@
#include string.h /* declares strcmp() */
#include ctype.h /* declares isdigit() */
#include limits.h /* defines CHAR_MAX */
+#include xlocale.h/* support for newlocale() */
#include getopt.h
#include version.h
@@ -275,13 +276,15 @@
for (int i = 0; i _argument_count; i++)
{
const char *arg = _argument_vector[i];
+ locale_t loc;
+ loc = newlocale(LC_ALL_MASK, C, 0);
/* Escape arg if it contains shell metacharacters. */
if (*arg == '-')
{
putchar (*arg);
arg++;
- if (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg = 'z')
+ if (isalpha_l(*arg, loc))
{
putchar (*arg);
arg++;
@@ -293,7 +296,7 @@
putchar (*arg);
arg++;
}
- while (*arg = 'A' *arg = 'Z' || *arg = 'a' *arg
= 'z' || *arg == '-');
+ while (isalpha_l(*arg, loc) || *arg == '-');
if (*arg == '=')
{
putchar (*arg);
signature.asc
Description: This is a digitally signed message part
Re: gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
On Thu, 2013-10-24 at 21:24 -0400, David Chisnall wrote: Don't forget the freelocale() at the end. ah, ok. I wish that there was some kind of example that I could go off of in the man page. I'm sort of trundling my way through various bits of the system to find the obvious example of how to do this correctly. This seems like a very slow way of doing what was very fast in the original code though. I'm not entirely sure what you're aiming to gain in this refactoring. David I'm simply trying to address the warnings that appear due to clang. I find the builds very noisy and if there's a better way to address this issue, I'm totally open to suggestions. sean signature.asc Description: This is a digitally signed message part
Re: gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
On Fri, 2013-10-25 at 06:38 -0400, David Chisnall wrote: I'm simply trying to address the warnings that appear due to clang. I find the builds very noisy and if there's a better way to address this issue, I'm totally open to suggestions. Well, for contrib code that isn't going to be around for much longer like gperf, the best thing to do is probably just stick -Wno-logical-op-parentheses in the CFLAGS. Alternatively, adding the brackets as it suggested to indicate precedence is simple. David Agreed. Thank you for patience in dealing with me. :-) I will go with my original patch that simply puts parens where they can be picked up and leave the flow of the code alone. http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045644.html sean signature.asc Description: This is a digitally signed message part
[PATCH] quiesce clang warnings for opie/libopie
Spent some time investigating warnings emitted by the build for libopie and such. http://people.freebsd.org/~sbruno/libopie_warns.txt Most of this is harmless and clang emits clear directives and solutions to solve these warnings. Patch attached to do just that and make the build happy. http://people.freebsd.org/~sbruno/libopie_clang_warnings.txt From my eye, it appears that opie should be tracking some other project or something? sean signature.asc Description: This is a digitally signed message part
Re: gperf/src/options.cc -- quiesce clang warnings -Wlogical-op-parentheses
On Fri, 2013-10-25 at 10:04 -0400, Sean Bruno wrote: On Fri, 2013-10-25 at 06:38 -0400, David Chisnall wrote: I'm simply trying to address the warnings that appear due to clang. I find the builds very noisy and if there's a better way to address this issue, I'm totally open to suggestions. Well, for contrib code that isn't going to be around for much longer like gperf, the best thing to do is probably just stick -Wno-logical-op-parentheses in the CFLAGS. Alternatively, adding the brackets as it suggested to indicate precedence is simple. David Agreed. Thank you for patience in dealing with me. :-) I will go with my original patch that simply puts parens where they can be picked up and leave the flow of the code alone. http://lists.freebsd.org/pipermail/freebsd-current/2013-October/045644.html sean commited at SVN r257160 sean signature.asc Description: This is a digitally signed message part
[PATCH] contrib/groff Queisce -Wdangling else
This adds proper braces to clear Clang warnings about dangling else statements in groff. There is no(intended) functional change. http://people.freebsd.org/~sbruno/groff_dangling_else.txt sean signature.asc Description: This is a digitally signed message part
Re: [PATCH] quiesce clang warnings for opie/libopie
On Fri, 2013-10-25 at 10:13 -0400, Sean Bruno wrote: Spent some time investigating warnings emitted by the build for libopie and such. http://people.freebsd.org/~sbruno/libopie_warns.txt Most of this is harmless and clang emits clear directives and solutions to solve these warnings. Patch attached to do just that and make the build happy. http://people.freebsd.org/~sbruno/libopie_clang_warnings.txt From my eye, it appears that opie should be tracking some other project or something? sean Updated to handle opieversion() and include unistd.h for getopt() http://people.freebsd.org/~sbruno/libopie_clang_warnings.txt sean signature.asc Description: This is a digitally signed message part
Re: newcons comming
On Sat, 2013-10-26 at 22:32 +0300, Aleksandr Rybalko wrote: On Sat, 26 Oct 2013 10:45:32 +0200 d...@gmx.com wrote: Suppose that Newcons gets in quickly. I use a Radeon 9600 card. Will I see something useful on my screen (with KMS and the new Xorg and things like that), or will my screen be black? Yup, you will get normal virtual terminal, but a bit bigger than 640x480. It is main reason why x11 team ask me to merge newcons ASAP. Newcons can use framebuffer provided by DRM. Try it yourself. WBW So, I'm running NEW Xorg now and KMS with an NVidia card. What should I do to test this? What are the expected results? sean signature.asc Description: This is a digitally signed message part
Re: [PATCH] contrib/groff Queisce -Wdangling else
On Sat, 2013-10-26 at 20:22 -0400, Eitan Adler wrote: On Sat, Oct 26, 2013 at 11:04 AM, Sean Bruno sean_br...@yahoo.com wrote: This adds proper braces to clear Clang warnings about dangling else statements in groff. There is no(intended) functional change. For contributed code why not just disable warnings? Fixing code is good but doing so in our repository instead of upstream doesn't help as much. I believe very strongly that the people who construct compilers know C/C ++ far better than I do, so warnings are their note to me that I'm doing it wrong. Disabling warnings is global for a section of the tree (e.g. groff/roff). I can't (easily) isolate the warnings individually, so modifications to the code after I disable the warnings will get excluded as well, effectively opening the project to crappy code that breaks things (if the warnings are causing bugs). For this specific code (groff), it switched to gpl v3 in 2009, so we won't be doing any more code drops into our tree: Revision 1.5 - (view) (download) (annotate) - [select for diffs] Sun Jan 4 14:50:51 2009 UTC (4 years, 9 months ago) by wl Branch: MAIN Changes since 1.4: +3 -3 lines Diff to previous 1.4 * */*: Update GPL2 to GPL3. Therefore, if someone isn't going to rewrite the implementations, its up to us to maintain the code we have. sean Warnings are meaningful. FreeBSD Clusteradm/Developer signature.asc Description: This is a digitally signed message part
Re: [PATCH] contrib/groff Queisce -Wdangling else [updated]
On Sat, 2013-10-26 at 11:04 -0400, Sean Bruno wrote: This adds proper braces to clear Clang warnings about dangling else statements in groff. There is no(intended) functional change. http://people.freebsd.org/~sbruno/groff_dangling_else.txt sean I've updated the patch at this link and only put in the needed parenthesis to quiesce the clang warnings. Code binary sizes appear identical after these changes. Thanks to Jiles for pointing me at unintended code changes. sean signature.asc Description: This is a digitally signed message part
Re: CURRENT issue with /dev/cs
On Mon, 2013-10-28 at 10:27 -0400, Outback Dingo wrote: cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/cs/if_cs.c ctfconvert -L VERSION -g if_cs.o cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/cs/if_cs_isa.c In file included from /usr/src/sys/dev/cs/if_cs_isa.c:48: /usr/src/sys/dev/cs/if_csvar.h:68:17: error: field has incomplete type 'struct callout' struct callout timer; ^ /usr/src/sys/dev/cs/if_csvar.h:68:9: note: forward declaration of 'struct callout' struct callout timer; ^ 1 error generated. *** Error code 1 Stop. bmake[2]: stopped in /usr/obj/usr/src/sys/GENERIC ___ 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 thanks for catching this. I've committed a fix for this at svn R257262 sean signature.asc Description: This is a digitally signed message part
libreadline rl_message() and building the same object file 6 times?
I *think* its safe to change this invocation of rl_message to omit the third argument, but I'm not 100%. Second, why on earth does a buildworld emit this warning 6 times? Its as though bmake things it needs to compile it repeatedly, and its not the only such time I've seen this across the tree. This probably means I don't know what I'm doing, but I'd like to know. sbruno@powernoodle ~/bsd/head]$ MAKEOBJDIRPREFIX=/var/tmp make -s -DNO_CLEAN buildworld /var/tmp/libreadline.txt /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); ^ 1 warning generated. /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); ^ 1 warning generated. /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x5f5): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() cc: warning: argument unused during compilation: '-L/var/tmp/home/sbruno/bsd/head/lib32/usr/lib32' /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); ^ 1 warning generated. /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); ^ 1 warning generated. /home/sbruno/bsd/head/gnu/lib/libreadline/readline/../../../../contrib/libreadline/search.c:214:24: warning: data argument not used by format string [-Wformat-extra-args] rl_message (%s, p, 0); ^ 1 warning generated. signature.asc Description: This is a digitally signed message part
Re: libreadline rl_message() and building the same object file 6 times?
On Wed, 2013-10-30 at 00:06 +0200, Konstantin Belousov wrote: Second, why on earth does a buildworld emit this warning 6 times? Its as though bmake things it needs to compile it repeatedly, and its not the only such time I've seen this across the tree. This probably means I don't know what I'm doing, but I'd like to know. It is one build for bootstrap, one for native library, and one for compat32. Each build generates non-pic and pic .o, for .a and .so lib. Total is six. Thank you for the explanation. Is there a trivial way to abort building all the objects or fail if one fails? Or is this done in parallel? sean signature.asc Description: This is a digitally signed message part
Re: libreadline rl_message() and building the same object file 6 times?
On Wed, 2013-10-30 at 22:24 +0200, Konstantin Belousov wrote: Thank you for the explanation. Is there a trivial way to abort building all the objects or fail if one fails? Or is this done in parallel? This is done automatically, no ? Bmake seems to be more advanced in this regard, e.g. my parallel kernel builds with compilation error in some module abort whole build immediately, comparing with fmake builds which run to the end. Yes, the build exits immediately if I understand what's going on correctly. My question was about building all six objects, shouldn't one error/warning be enough? Or is there no way for what I propose to happen? sean signature.asc Description: This is a digitally signed message part
[PATCH] Adjust binutils to quiesce -Wstring-plus-int
Spent some time doing string maths today. More or less, change the static char intel_syntax to an int and use it as an array index instead of doing pointer math. Sean http://people.freebsd.org/~sbruno/binutils_opcodes.txt signature.asc Description: This is a digitally signed message part
Re: Add support for Intel AMT technology on Intel Lynx Point chipset
On Wed, 2013-11-06 at 11:16 +0200, Dmitry Luhtionov wrote:
--- /usr/src/sys/dev/uart/uart_bus_pci.c.orig2013-11-01
14:45:23.0 +0200
+++ /usr/src/sys/dev/uart/uart_bus_pci.c2013-11-04 11:15:54.0
+0200
@@ -122,6 +122,7 @@
{ 0x8086, 0x8812, 0x, 0, Intel EG20T Serial Port 1, 0x10 },
{ 0x8086, 0x8813, 0x, 0, Intel EG20T Serial Port 2, 0x10 },
{ 0x8086, 0x8814, 0x, 0, Intel EG20T Serial Port 3, 0x10 },
+{ 0x8086, 0x8c3d, 0x, 0, Intel Lynx Point KT Controller, 0x10 },
{ 0x9710, 0x9820, 0x1000, 1, NetMos NM9820 Serial Port, 0x10 },
{ 0x9710, 0x9835, 0x1000, 1, NetMos NM9835 Serial Port, 0x10 },
{ 0x9710, 0x9865, 0xa000, 0x1000, NetMos NM9865 Serial Port, 0x10 },
Committed at svn r 257808
Thanks for the update!
sean
signature.asc
Description: This is a digitally signed message part
Any suggestions on how to fix this error?
cc: warning: argument unused during compilation: '-L/var/tmp/home/sbruno/bsd/head/lib32/usr/lib32' This shows up on buildworld on amd64. I'm not 100% clear where this comes from nor how to clean it out where it doesn't belong or if it even means anything. sean signature.asc Description: This is a digitally signed message part
Re: [head tinderbox] failure on amd64/amd64
[...] c++ -O2 -pipe -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Wno-c++11-extensions -I/src/gnu/usr.bin/gperf/../../../contrib/gperf/lib -I/src/gnu/usr.bin/gperf -c /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:782:11: error: format string is empty [-Werror,-Wformat-zero-length] , option.get_size_type()); ^~ /src/gnu/usr.bin/gperf/../../../contrib/gperf/src/output.cc:1910:11: error: format string is empty [-Werror,-Wformat-zero-length] , option.get_size_type()); Theoretically fixed at svn R258139. sean signature.asc Description: This is a digitally signed message part
kasserts behind invariants
I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: kasserts behind invariants
On Fri, 2013-12-13 at 14:43 -0800, Alfred Perlstein wrote: On 12/13/13 1:50 PM, Sean Bruno wrote: I guess this may have been argued before, but I don't see why we would want to hide specific things like: sys/kern/subr_lock.c /* Check for double-init and zero object. */ KASSERT(!lock_initalized(lock), (lock \%s\ %p already initialized, name, lock)); If I hadn't completely missed the fact that I had INVARIANTS activated, I'd never have found out why this vendor driver was being so completely stupid and crashing my machine. If I find things like this that I want old KASSERT behavior on (panic if true) and I don't want to run INVARIANTS, is that possible? I don't understand the question, do you want to move it from INVARIANTS to under just a plain if(condition)? -Alfred ___ In this specific instance, it would have been much better to simply panic if(condition) than silently allowing the vendor driver to do something stupid like initialize a mutex twice. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipmi(4)/isa woes
On Tue, 2011-10-11 at 15:34 -0700, Arnaud Lacombe wrote: Hi folks, I've got a machine where ipmi(4) seem to be unable to fully attach. 10-current kernel complains the following way: ipmi0: IPMI System Interface at iomem 0-0x1 on isa0 ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa ipmi0: couldn't configure I/O resource device_attach: ipmi0 attach returned 6 Been running a lot of ipmi stuff over here at big purple lately. Haven't seen this. Which h/w model/vendor gear is this? Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic at vm_page_wire with FreeBSD 9.0 Beta 3
On Fri, 2011-10-21 at 08:25 -0700, Penta Upa wrote: Attached is a test module (vmtest) and the makefile used. Uname output from the system is I only see a Makefile attached here. Can you attach the code you are using? Sean ___ 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
9.0 NFS Installs
I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. --- 8.2-RELEASE disc1.iso --- netboot# ls -l total 508 dr-xr-xr-x 14 root wheel 512 Nov 5 20:42 8.2-RELEASE -r--r--r-- 1 root wheel4958 Nov 5 20:43 ERRATA.HTM -r--r--r-- 1 root wheel3590 Nov 5 20:43 ERRATA.TXT -r--r--r-- 1 root wheel 192187 Nov 5 20:43 HARDWARE.HTM -r--r--r-- 1 root wheel 116657 Nov 5 20:43 HARDWARE.TXT -r--r--r-- 1 root wheel 19914 Nov 5 20:43 README.HTM -r--r--r-- 1 root wheel 14387 Nov 5 20:43 README.TXT -r--r--r-- 1 root wheel 105287 Nov 5 20:43 RELNOTES.HTM -r--r--r-- 1 root wheel 41124 Nov 5 20:43 RELNOTES.TXT dr-xr-xr-x 7 root wheel1024 Nov 5 20:40 boot -r--r--r-- 1 root wheel2048 Nov 5 20:43 boot.catalog -r--r--r-- 1 root wheel 39 Nov 5 20:43 cdrom.inf -r--r--r-- 1 root wheel3802 Nov 5 20:43 docbook.css dr-xr-xr-x 5 root wheel 512 Nov 5 20:41 packages --- 9.0-RELEASE bootonly.iso --- total 492 -rw-r--r-- 2 root wheel 788 Oct 18 19:24 .cshrc -rw-r--r-- 2 root wheel 251 Oct 18 19:24 .profile drwxr-xr-x 2 root wheel4096 Oct 18 19:24 .rr_moved -r--r--r-- 1 root wheel6194 Oct 18 19:24 COPYRIGHT -r--r--r-- 1 root wheel5167 Oct 18 19:24 ERRATA.HTM -r--r--r-- 1 root wheel3727 Oct 18 19:24 ERRATA.TXT -r--r--r-- 1 root wheel 199303 Oct 18 19:24 HARDWARE.HTM -r--r--r-- 1 root wheel 121623 Oct 18 19:24 HARDWARE.TXT -r--r--r-- 1 root wheel 20698 Oct 18 19:24 README.HTM -r--r--r-- 1 root wheel 15103 Oct 18 19:24 README.TXT -r--r--r-- 1 root wheel 37081 Oct 18 19:24 RELNOTES.HTM -r--r--r-- 1 root wheel 18789 Oct 18 19:24 RELNOTES.TXT drwxr-xr-x 2 root wheel6144 Oct 18 19:24 bin drwxr-xr-x 7 root wheel6144 Oct 18 19:24 boot dr-xr-xr-x 2 root wheel2048 Oct 18 19:24 dev -r--r--r-- 1 root wheel3924 Oct 18 19:24 docbook.css drwxr-xr-x 20 root wheel 12288 Oct 18 19:24 etc drwxr-xr-x 3 root wheel6144 Oct 18 19:24 lib drwxr-xr-x 3 root wheel2048 Oct 18 19:24 libexec drwxr-xr-x 2 root wheel2048 Oct 18 19:24 media drwxr-xr-x 2 root wheel2048 Oct 18 19:24 mnt dr-xr-xr-x 2 root wheel2048 Oct 18 19:24 proc drwxr-xr-x 2 root wheel2048 Oct 18 19:24 rescue drwxr-xr-x 2 root wheel2048 Oct 18 19:24 root drwxr-xr-x 2 root wheel 16384 Oct 18 19:24 sbin lrwxr-xr-x 1 root wheel 11 Oct 18 19:24 sys - usr/src/sys drwxrwxrwt 2 root wheel2048 Oct 18 19:24 tmp drwxr-xr-x 15 root wheel2048 Oct 18 19:24 usr drwxr-xr-x 23 root wheel4096 Oct 18 19:24 var ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0 NFS Installs
On Mon, 2011-11-07 at 10:29 -0800, Nathan Whitehorn wrote: On 11/07/11 11:20, Sean Bruno wrote: I noted that we no longer have the disc1.iso in this release. What should I use to populate a NFS rootfs for netinstalls? This was what I had been using(8.2-RELEASE) to populate NFS roots for netinstalls. This allowed you to boot up into something that was self-contained. The other ISO's seem to have A LOT more stuff with symlinks pointing to absolute paths all over the f/s. This isn't quite as simple to copy over to a rootfs to use as a NFS target for booting. You can just copy the whole CD over and it will work fine. The CD is basically a vanilla installed system, so you can also just set up an install somewhere (with bsdinstall jail /path/to/nfsroot, for instance). Things on the CD different from a vanilla system: - /etc/rc.local script to start the installer at boot (copied from /usr/src/release/rc.local) - Distfiles copied to /usr/freebsd-dist If you don't copy the distfiles, bsdinstall will automatically download them, but you probably don't want to do that every time. -Nathan Hah! Yes ... this is absolutely correct. I'm netbooting VMs now, excellent. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: 9.0-RC1 fails to boot (run_interrupt_driven_hooks: still waiting...)
On Sat, 2011-11-12 at 23:43 -0800, Andriy Gapon wrote: I had a Firewire card in the machine - removing it caused the problem to go away. I think that Sean has been looking for someone who can reproduce the problem and is willing to help debugging it. -- Andriy Gapon Indeed. If you can setup a machine with a kernel with device sbp and get me root on the box I'd appreciate it. Bonus points for serial console! Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Remote access to HP Proliant hardware available to fix the problem with failing booting 9.0 on ciss(4), HP SmartArray P410i
On Tue, 2011-11-22 at 14:59 -0800, Palle Girgensohn wrote: Hi, When installing 9.0 RC1 on our HP servers, we of course wanted to use gpt intead of fdisk. However, it doesn't work. First I tried gptzfsboot, it failed with an error (see this thread: http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026175.html) Second, I tried a standard gptboot, it just goes into a boot loop. Seriously, we have a couple of idle machines with ciss(4) and an iLO (for remote connections). If someone has the knowledge and time to try and fix the problems with ciss and gpt boot, we have the equipment for it. We tried with a standard vanilla zpool, no mirror or raid at all, on top of a ciss raid-5, and it failed with RC1. [trying RC2 now, but seems nothing is changed?]. Anyone up to the task of finding this culprit, we can let you into the machine remotely through the iLO. Please let me know. Best reagards Palle Girgensohn I just got done with an HP DL160G6 with a P410 raid-5 configuration in the freebsd.org cluster. I definitely had to use RC2 due to some type of disk issue. I suspect that http://svnweb.freebsd.org/base?view=revisionrevision=227400 fixed it. Sean ___ 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
NFS + SVN problem?
Not sure what this all means, but when I attempt to check out HEAD on an NFS mount in the fbsd cluster (nfs server is a netapp filer), I'm getting an odd failure error. FreeBSD bhyve.freebsd.org 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r227883: Wed Nov 23 06:08:40 PST 2011 sbr...@bhyve.freebsd.org:/usr/obj/var/tmp/temp/head/sys/GENERIC amd64 [sbruno@bhyve /dumpster/scratch/sbruno-scratch]$ svn co -q svn +ssh://svn.freebsd.org/base/head Enter passphrase for key '/home/sbruno/.ssh/id_rsa': svn: E200030: disk I/O error, executing statement 'PRAGMA synchronous=OFF;PRAGMA recursive_triggers=ON;' Mounting the filer mount with the following entry in my fstab: dumpster:/vol/volshscratch /dumpster/scratch nfs rw,soft,bg,intr,nosuid 0 0 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS + SVN problem?
On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote: I don't know if Dimitry tried this, but you could also try the nolockd option, so that byte range locking is done locally in the client and avoids the NLM. Good luck with it and please let us know how it goes, rick This seems to allow SVN 1.7 to do whatever nonsense it is trying to do. I've modified my fstab on the test host in the cluster to: dumpster:/vol/volshscratch /dumpster/scratch nfs rw,soft,intr,bg,nolockd,nosuid 0 0 Removing soft,intr had no effect. This, I suspect will be problematic for clusteradm@ if we start updating hosts in the cluster. Sean signature.asc Description: This is a digitally signed message part
Re: NFS + SVN problem?
Oh, and don't hesitate to try NFSv4. It should do the locking correctly without needing nolockd and the more testing it gets, the better.;-) rick Removing soft,intr had no effect. This, I suspect will be problematic for clusteradm@ if we start updating hosts in the cluster. Sean Doesn't look like dumpster supports V4? [tcp] dumpster:/vol/volshscratch: NFSPROC_NULL: RPC: Program/version mismatch; low version = 2, high version = 3 mount_nfs: Cannot immediately mount dumpster:/vol/volshscratch, backgrounding ___ 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
Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C)
I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? The console fills up with repeated warnings that never cease. FreeBSD testbox 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228164S: Wed Nov 30 16:19:16 PST 2011 sbruno@testbox:/tmp/foo/bsd/head/sys/GENERIC_NO_1394 amd64 [sbruno@testbox ~]$ sysctl -a |grep thermal Giant,ACPI thermal zone hw.acpi.thermal.min_runtime: 0 hw.acpi.thermal.polling_rate: 10 hw.acpi.thermal.user_override: 0 hw.acpi.thermal.tz0.temperature: -273.2C hw.acpi.thermal.tz0.active: -2 hw.acpi.thermal.tz0.passive_cooling: 1 hw.acpi.thermal.tz0.thermal_flags: 0 hw.acpi.thermal.tz0._PSV: 50.0C hw.acpi.thermal.tz0._HOT: -1 hw.acpi.thermal.tz0._CRT: 60.0C hw.acpi.thermal.tz0._ACx: 50.0C -1 -1 -1 -1 -1 -1 -1 -1 -1 hw.acpi.thermal.tz0._TC1: 4 hw.acpi.thermal.tz0._TC2: 3 hw.acpi.thermal.tz0._TSP: 60 ... dev.acpi_tz.0.%desc: Thermal Zone dev.acpi_tz.0.%driver: acpi_tz dev.acpi_tz.0.%location: handle=\_TZ_.THRM dev.acpi_tz.0.%pnpinfo: _HID=none _UID=0 dev.acpi_tz.0.%parent: acpi0 Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Console Spam: acpi_tz0: _TMP value is absurd, ignored (-73.0C) [solved]
On Wed, 2011-11-30 at 15:55 -0800, Jung-uk Kim wrote: On Wednesday 30 November 2011 06:40 pm, Andriy Gapon wrote: on 01/12/2011 01:22 Sean Bruno said the following: I have a Shuttle based intel box that appears to have some pretty bad ACPI implementation. Is there a good way to quiesce this spam? Ask on acpi@ list. Kidding :-) or not. Try hw.acpi.thermal.polling_rate=0. Adding the following line in /boot/loader.conf will disable acpi_thermal(4) completely: debug.acpi.disabled=thermal Jung-uk Kim Aye, both are my huckleberry. Thanks! Sean ___ 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
Malformed conditional (${MK_CTF} != no)
I've noted that this morning's svn update seems to be breaking pretty
badly. Is this related to the DTRACE conf changes?
[seanb@sbpi386 ~/head/sys/modules/firewire]$ make
=== firewire (all)
/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk,
line 204: Malformed conditional (${MK_CTF} != no)
/usr/home/seanb/head/sys/modules/firewire/firewire/../../../conf/kmod.mk,
line 206: if-less endif
make: fatal errors encountered -- cannot continue
*** Error code 1
Stop in /usr/home/seanb/head/sys/modules/firewire.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: est man page
On Tue, 2012-06-05 at 14:13 -0700, Sean Bruno wrote: On Tue, 2012-06-05 at 11:55 -0700, Sean Bruno wrote: allrighty, after some doc reviews by Glen, I've thwacked together a quick and dirty est(4). Any objections? http://people.freebsd.org/~sbruno/est_man.txt view via: groff -S -P-h -Wall -mtty-char -man -Tascii est_man.txt | less Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: est man page
se http://people.freebsd.org/~sbruno/est_man.txt Looks good. Attached a diff for some small fixes. Updated again with feedback that I've gotten. I changed the Note that est interface is automatically loaded to Note that est capabilities are automatically loaded Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: est man page
On Wed, 2012-06-13 at 11:06 -0700, Sean Bruno wrote: se http://people.freebsd.org/~sbruno/est_man.txt Looks good. Attached a diff for some small fixes. Updated again with feedback that I've gotten. I changed the Note that est interface is automatically loaded to Note that est capabilities are automatically loaded Sean Committed at svn r237245 ... Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Fri, 2012-09-14 at 14:27 -0700, YongHyeon PYUN wrote: All, There were lots of reports that stock bge(4) does not work on Dell Rx20/HP DL 360 G8. With the help of Broadcom and BCM5719/BCM5720 users I managed to address the issue but I had to touch very sensitive part of driver. Before committing the change to tree I'd like to know whether this change introduces regressions on old bge(4) controllers. If you're bge(4) user, please try latest WIP version at the following URL and let me know how it goes on your box. I'm especially interested in whether there is any ASF/IPMI regression on BCM570x/571x. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c Build instructions 1. Copy both if_bge.c/if_bgereg.h to /usr/src/sys/dev/bge directory 2. Copy brgphy.c /usr/src/sys/dev/mii 3. Rebuild kernel and reboot to take the change effect. You can also use the files above for for 9.1/stable/9. For stable/8 it needs slight modification and I couldn't find time to regenerate the patch. Thanks. Still going through a battery of merging and regressions here at Y! I've got most of the Dell and HP gear that would be affected by these updates running at the moment via these updates. I have some different h/w IDs for brgphy and bge(4) that I need to capture and spam over this week. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Wed, 2012-09-19 at 09:44 -0700, Sean Bruno wrote: On Fri, 2012-09-14 at 14:27 -0700, YongHyeon PYUN wrote: All, There were lots of reports that stock bge(4) does not work on Dell Rx20/HP DL 360 G8. With the help of Broadcom and BCM5719/BCM5720 users I managed to address the issue but I had to touch very sensitive part of driver. Before committing the change to tree I'd like to know whether this change introduces regressions on old bge(4) controllers. If you're bge(4) user, please try latest WIP version at the following URL and let me know how it goes on your box. I'm especially interested in whether there is any ASF/IPMI regression on BCM570x/571x. http://people.freebsd.org/~yongari/bge/if_bge.c http://people.freebsd.org/~yongari/bge/if_bgereg.h http://people.freebsd.org/~yongari/bge/brgphy.c We're starting to gather data and have a couple of machines (pciconf, ifconfig, dmesg) here that may provide some insights. Everything seems to be working at a cursory level. http://people.freebsd.org/~sbruno/new_bge/ We have seen 2 instances of one or more of the HP machines failing and dropping off the network. however, we don't have specifics yet. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Thu, 2012-09-27 at 17:09 -0700, Sean Bruno wrote: We have seen 2 instances of one or more of the HP machines failing and dropping off the network. however, we don't have specifics yet. It looks like this specific error was ACPI related, not BGE related. The C6 setting in the BIOS has the nasty side effect of somehow letting CPU's quiesce and become unwakeable. Setting the lowest Cstate in the *bios* to C3 is under test. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Call for bge(4) testers
On Tue, 2012-10-02 at 15:59 -0700, YongHyeon PYUN wrote: Sean, do you have a box with BCM5703/5704/5714/5715 controller? I have a 5704C in an HP DL380G4 here that seems to be working. I'll have to poke around further to see what else I have lying around. bge0: HP NC7782 Gigabit Server Adapter, ASIC rev. 0x002100 mem 0xfdef-0xfdef irq 25 at device 1.0 on pci3 bge0: CHIP ID 0x2100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 133 MHz miibus0: MII bus on bge0 brgphy0: BCM5704 1000BASE-T media interface PHY 1 on miibus0 brgphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge0: Ethernet address: 00:0f:20:f6:e6:23 bge1: HP NC7782 Gigabit Server Adapter, ASIC rev. 0x002100 mem 0xfdee-0xfdee irq 26 at device 1.1 on pci3 bge1: CHIP ID 0x2100; ASIC REV 0x02; CHIP REV 0x21; PCI-X 133 MHz miibus1: MII bus on bge1 brgphy1: BCM5704 1000BASE-T media interface PHY 1 on miibus1 brgphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-master, 1000baseT-FDX, 1000baseT-FDX-master, auto, auto-flow bge1: Ethernet address: 00:0f:20:f6:e6:22 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: svn MFC to stable/8
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: Hi, Hopefully someone familiar with svn can help. When I try to MFC a kernel change to stable/8, it works, but I end up with tons of mergeinfo. (It looks like every directory under sys.) Does this matter or is there a trick to avoid this? Thanks in advance for any help, rick ps: I seem to MFC fine to stable/9. I only see this for stable/8. ___ Can you post your attempted svn merge command? Sean ___ 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
[CFT]hwpmc update for sandybridge-e
So, I did the bear minimum and kind of hacked things together without understanding precisely what I was doing, and I was able to massage the sandybridge-e CPUs into giving me some basic functions. Comments or concerns before I commit this? http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Sean p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT]hwpmc update for sandybridge-e
Sure, I will separate it out. If there are no further comments, can I ask Sean to commit on my behalf? Can you do the man page to include both in the commit? Except that point seems good to me. Thanks! Fabien Thanks, Hiren I shall await your svn diff. :-) sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Removing firewire support from GENERIC
On Fri, 2012-10-19 at 07:25 -0700, Dag-Erling Smørgrav wrote: Once more, with patch. DES Ack. I think this is sensible. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT]hwpmc update for sandybridge-e
On Fri, 2012-10-19 at 00:04 -0700, hiren panchasara wrote: On Thu, Oct 18, 2012 at 10:07 AM, Sean Bruno sean...@yahoo-inc.com wrote: Sure, I will separate it out. If there are no further comments, can I ask Sean to commit on my behalf? Can you do the man page to include both in the commit? Except that point seems good to me. Thanks Fabien! Thanks! Fabien Thanks, Hiren I shall await your svn diff. :-) Here you go: http://www.strugglingcoder.info/patches/hwpmc_sbx_4.txt New diffs has man page and doesn't have sandybridge typo fix. (will submit separate patch for that). cheers, Hiren *ACK* Patching and running compile tests at this time. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [CFT]hwpmc update for sandybridge-e
On Fri, 2012-10-19 at 00:04 -0700, hiren panchasara wrote: On Thu, Oct 18, 2012 at 10:07 AM, Sean Bruno sean...@yahoo-inc.com wrote: Sure, I will separate it out. If there are no further comments, can I ask Sean to commit on my behalf? Can you do the man page to include both in the commit? Except that point seems good to me. Thanks Fabien! Thanks! Fabien Thanks, Hiren I shall await your svn diff. :-) Here you go: http://www.strugglingcoder.info/patches/hwpmc_sbx_4.txt New diffs has man page and doesn't have sandybridge typo fix. (will submit separate patch for that). cheers, Hiren Sendinglib/libpmc/Makefile Sendinglib/libpmc/libpmc.c Adding lib/libpmc/pmc.sandybridgexeon.3 Sendingsys/dev/hwpmc/hwpmc_core.c Sendingsys/dev/hwpmc/hwpmc_intel.c Sendingsys/dev/hwpmc/pmc_events.h Sendingsys/sys/pmc.h Transmitting file data ... Committed revision 241738. Sean p.s. also, svn propset foo eluded me for like 10 minutes today as I don't do that very often. remember kids: svn propset svn:keywords 'FreeBSD=%H' file ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patch: hwpmc nits
On Mon, 2012-10-22 at 10:33 -0700, hiren panchasara wrote: On Mon, Oct 22, 2012 at 9:25 AM, Jim Harris jim.har...@gmail.com wrote: On Sun, Oct 21, 2012 at 12:19 AM, hiren panchasara hiren.panchas...@gmail.com wrote: http://www.strugglingcoder.info/patches/hwpmc_nits_1.txt Fixing a few typos with this patch. Please let me know if this looks okay. Thanks, Hiren Looks good. Thanks, Jim. Sean, can you please commit this on my behalf? :-) Thanks again, Hiren Thanks, -Jim Ack Sean signature.asc Description: This is a digitally signed message part
Re: patch: hwpmc nits
On Sun, 2012-10-21 at 00:19 -0700, hiren panchasara wrote: http://www.strugglingcoder.info/patches/hwpmc_nits_1.txt Fixing a few typos with this patch. Please let me know if this looks okay. Thanks, Hiren Sendinglib/libpmc/libpmc.c Sendinglib/libpmc/pmc.ivybridge.3 Sendinglib/libpmc/pmc.sandybridge.3 Sendinglib/libpmc/pmc.sandybridgexeon.3 Sendingsys/dev/hwpmc/pmc_events.h Transmitting file data . Committed revision 241974. sean signature.asc Description: This is a digitally signed message part
Is there a FreeBSD 9+ version of this?
http://www.freebsd.org/doc/handbook/geom-mirror.html ___ 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
Dog Food tm
Was trying to use gmirror(4) or zfs(4) today to get a machine in the cluster setup with s/w raid and was completely flummoxed by the intricacies of manual setup. Chances are, I just am not smart enough to wind my way though the various how tos and wiki pages that I've been browsing to get the job done. If someone wants to work on modifying bsdinstaller to do s/w raid via one of these mechanisms, clusteradm@ can provide you a two disk SATA machine that can be used for this purpose. Sean signature.asc Description: This is a digitally signed message part
Re: Dog Food tm
On Thu, 2011-12-08 at 02:08 -0800, Peter Maloney wrote: And what problems did you run into? More or less, trying to do gmirror(4) style mirroring on GPT partitions doesn't work. See http://www.freebsd.org/doc/handbook/geom-mirror.html for the BIG RED WARNING that says why. This guide worked for me: http://wiki.freebsd.org/RootOnZFS/GPTZFSBoot/Mirror That, along with a lot of how to's, is out of date in the FreeBSD 9 world. I would suspect that my experience of attempting to setup a mirrored volume won't be unique. BSDInstaller and its predecessor Sysinstall don't have any code to create or destroy zfs(4) or geom(4) volumes. So, the amount of exposure to real users is approaching 0 in comparison to the number of people who really do use FreeBSD. I have my hands full with other projects at the moment, but I'm more than happy to grant access to a two disk SATA server if someone wants to enhance BSDInstall with zfs(4) or geom(4) volume management features. At a minimum, you *should* be able to take 2 disks and make a mirrored volume with either tool. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: NFS + SVN problem?
On Tue, 2011-12-13 at 07:53 -0800, Rick Macklem wrote: Dimitry Andric wrote: On 2011-11-23 19:26, Sean Bruno wrote: On Wed, 2011-11-23 at 09:58 -0800, Rick Macklem wrote: I don't know if Dimitry tried this, but you could also try the nolockd option, so that byte range locking is done locally in the client and avoids the NLM. Good luck with it and please let us know how it goes, rick This seems to allow SVN 1.7 to do whatever nonsense it is trying to do. I've modified my fstab on the test host in the cluster to: dumpster:/vol/volshscratch /dumpster/scratch nfs rw,soft,intr,bg,nolockd,nosuid 0 0 Removing soft,intr had no effect. This, I suspect will be problematic for clusteradm@ if we start updating hosts in the cluster. A very late addition to this: I got Subversion 1.7 to work properly over NFSv3, by making sure rpc.lockd runs on both server and client. E.g, set rpc_lockd_enable to YES in rc.conf; this is off by default, even if you have nfs_client_enable/nfs_server_enable set to YES. and rpc_statd_enable=YES on all systems, as well. Thanks for this btw. :-) Sean ___ 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
dogfooding over in clusteradm land
We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Effectively, I cannot access the directory under use and the converter application stalls out waiting for some resource that isn't clear. (Peter had posited kmem of some kind). I've upped maxvnodes a bit on the host, turned off SUJ and mounted the f/s in question with async and noatime for performance reasons. Can someone hit me up with the cluebat? I can give you direct access to the box for debuginationing. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: dogfooding over in clusteradm land [cvs2svn for ports]
On Wed, 2011-12-14 at 05:20 -0800, Sean Bruno wrote: We're seeing what looks like a syncher/ufs resource starvation on 9.0 on the cvs2svn ports conversion box. I'm not sure what resource is tapped out. Effectively, I cannot access the directory under use and the converter application stalls out waiting for some resource that isn't clear. (Peter had posited kmem of some kind). I've upped maxvnodes a bit on the host, turned off SUJ and mounted the f/s in question with async and noatime for performance reasons. Can someone hit me up with the cluebat? I can give you direct access to the box for debuginationing. Sean BTW, this project is sort of stalled out by this problem. Sean signature.asc Description: This is a digitally signed message part
Re: SVN - CVS gateway stalled?
On Wed, 2011-12-28 at 12:49 -0800, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I noticed updates come from SVN today but haven't yet seen them in CVS. Is it busted again? Clusteradm@ can take a look at this ... I think. Sean signature.asc Description: This is a digitally signed message part
Re: dogfooding over in clusteradm land
On Tue, 2012-01-03 at 04:46 -0800, Florian Smeets wrote:
Yes, the patch fixes the problem. The cvs2svn run completed this time.
9132.25 real 8387.05 user 403.86 sys
I did not see any significant syncer activity in top -S anymore.
Thanks a lot.
Florian
Currently running stable-9 + this patch on crush.freebsd.org. First run
was successful and took about 4 hours start to finish. Nicely done
folks.
diff --git a/sys/vm/vm_object.c b/sys/vm/vm_object.c
index 716916f..52fc08b 100644
--- a/sys/vm/vm_object.c
+++ b/sys/vm/vm_object.c
@@ -841,7 +841,8 @@ rescan:
if (p-valid == 0)
continue;
if (vm_page_sleep_if_busy(p, TRUE, vpcwai)) {
- if (object-generation != curgeneration)
+ if ((flags OBJPC_SYNC) != 0
+ object-generation != curgeneration)
goto rescan;
np = vm_page_find_least(object, pi);
continue;
@@ -851,7 +852,8 @@ rescan:
n = vm_object_page_collect_flush(object, p, pagerflags,
flags, clearobjflags);
- if (object-generation != curgeneration)
+ if ((flags OBJPC_SYNC) != 0
+ object-generation != curgeneration)
goto rescan;
/*
signature.asc
Description: This is a digitally signed message part
Re: Freebsd 9.0 release and dmesg
On Mon, 2012-02-06 at 09:24 -0800, JD wrote: dmesg no longer outputs the kernel messages. $ dmesg $ $ which dmesg /sbin/dmesg $what /sbin/dmesg /sbin/dmesg: So, I have no idea what version of dmesg got installed. Anyone on 9.0 Release have this problem? How to fix it? I would assume that something is writing a lot to the console? Is there any indication of this in /var/log/messages? Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: projects/mfi_head to -current next week
On Sat, 2012-03-17 at 10:31 -0700, Alex Keda wrote: On 16.03.2012 19:39, Doug Ambrisko wrote: Hi folks, I'd like to start merging mfi(4) from projects/head_mfi into -current next week. The mfi(4) driver is stable and I don't know of any issues with it now. I fixed a few issues that I knew of this past week. Several people have contributed to this. LSI did the base HW support. This update supports all current mfi based cards. It supports JBOD via creating /sys/mfisyspd* entries for each disk. When a disk is pulled from the controller the node goes away and when a disk is inserted it creates an entry. Using a fairly new MegaCli, it can also control how JBOD support works. We may need to update our port. This JBOD support is not the same as CAM pass through that some have hacked to make disks appear as da*. Several people are using this driver now so I feel it is stable enough to hit the tree. More eyes and people using this will make it better. This new HW is showing up more and more in new systems so it will make it easier for people to use FreeBSD on these machines and have it just work. Thanks to LSI for the initial HW support and all of the people that have been testing and getting it in shape to commit. Good news! How about new hardware? The only h/w that I've seen that requires this new support is the Dell H710 that is shipping with their latest servers (12G). Sean ___ 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
ports/bash4 --enable-static fails
I'm assuming that the recent jemalloc updates have broken something subtly that is now causing static symbol compilation to fail. ports/bash4 isn't the simplest case, but its the most obvious one that is in my face. http://people.freebsd.org/~sbruno/bash4_jemalloc.txt Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ports/bash4 --enable-static fails
On Thu, 2012-05-10 at 05:56 -0700, Chet Ramey wrote: On 5/10/12 12:20 AM, Craig Rodrigues wrote: Bash is trying to override the malloc() functions in libc with its own implementation in lib/malloc/malloc.c . I have seen this type of trick before 3rd party code that tries to override the libc implementation of malloc() / free() with its own. kan@ explained this to me before, but I don't know if I can explain it as well as him, because it has to do with how static linking works. :) Basically, the malloc.o object from bash, *must* have implementations of *all* the relevant functions in jemalloc_jemalloc.o in order for malloc.o to properly override jemalloc_jemalloc.o. If you have something like: jemalloc_jemalloc.o (libc) malloc.o (Bash) === = malloc() malloc() free() free() calloc() realloc() the static linker will not be able to replace jemalloc_jemalloc.o from libc with malloc.o from Bash, because calloc() and realloc() symbols in jemalloc_jemalloc.o (libc) do not exist malloc.o (Bash). Since the linker can only deal with whole objects (.o files), it will try to pull in both jemalloc_jemalloc.o and malloc.o when doing static linking. I may have got some of the details/explanation wrong, but I have fixed something similar to this in 3rd party code, when the layout of malloc() functions in libc changed between FreeBSD 4 and FreeBSD 6. This explanation is substantially correct. What you need to do is: (1) run nm or readelf on jemalloc_jemalloc.o, then run nm or readelf on malloc.o (2) Look at the symbols in both (3) Add the missing symbols to malloc.c in Bash The bash malloc includes definitions for malloc/free/realloc/calloc/cfree/ valloc/memalign. I'd be interested in knowing what other global symbols jemalloc exports. I'd also be interested in seeing how someone managed to compile the bash malloc and leave out realloc. Chet Just to kind of close the loop here, we went ahead and changed our local build of bash to do: ./configure --enable-static-link --without-bash-malloc This matches the ports implementation, so we have moved on here. Sean ___ 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
est man page
I note that x86/cpufreq/est.c has some tuneables and I have processors that seem to be not supported by est even though they appear to have Speedstep features: p4tcc0: CPU Frequency Thermal Control on cpu0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est1 attach returned 6 1. How do I generate new speed tables for est? 2. Any objections to an est(4) man page? Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: est man page
On Tue, 2012-06-05 at 11:55 -0700, Sean Bruno wrote: I note that x86/cpufreq/est.c has some tuneables and I have processors that seem to be not supported by est even though they appear to have Speedstep features: p4tcc0: CPU Frequency Thermal Control on cpu0 est1: Enhanced SpeedStep Frequency Control on cpu1 est: CPU supports Enhanced Speedstep, but is not recognized. est: cpu_vendor GenuineIntel, msr 15 device_attach: est1 attach returned 6 *ACTUALLY* this was caused by the Dell r410 that I was using having its Power Managment control set to Advanced Power Management and not OS Control. After I set that, the acpi methods in est attached correctly. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Fixing clang warnings in hwpmc
On Mon, 2013-01-07 at 16:34 -0800, hiren panchasara wrote: http://www.strugglingcoder.info/patches/hwpmc_clang_warnings.txt A trivial patch to fix a couple of clang warnings. Thanks, Hiren Ack. compiles good. Commit in progress. Sean signature.asc Description: This is a digitally signed message part
Re: Intel 82574 issue reported on Slashdot
On Fri, 2013-02-08 at 10:16 -0800, Jack Vogel wrote: For those that may have run across the story on Slashdot about this NIC, here is our statement: Recently there were a few stories published, based on a blog post by an end-user, suggesting specific network packets may cause the Intel® 82574L Gigabit Ethernet Controller to become unresponsive until corrected by a full platform power cycle. Intel was made aware of this issue in September 2012 by the blogs author. Intel worked with the author as well as the original motherboard manufacturer to investigate and determine root cause. Intel root caused the issue to the specific vendor’s mother board design where an incorrect EEPROM image was programmed during manufacturing. We communicated the findings and recommended corrections to the motherboard manufacturer. It is Intel’s belief that this is an implementation issue isolated to a specific manufacturer, not a design problem with the Intel 82574L Gigabit Ethernet controller. Intel has not observed this issue with any implementations which follow Intel’s published design guidelines. Intel recommends contacting your motherboard manufacturer if you have continued concerns or questions whether your products are impacted. Here is the link: http://communities.intel.com/community/wired/blog/2013/02/07/intel-82574l-gigabit-ethernet-controller-statement Any questions or concerns may be sent to me. Cheers, Jack Thanks for the info. I'm sure there were some *interesting* debugging sessions during this. Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ZFS problems
On Wed, Feb 27, 2013 at 2:44 PM, Steven Hartland kill...@multiplay.co.uk wrote: - Original Message - From: Derrick Dantavious Edwards I updated sources a couple of days ago and when I rebooted to continue to the upgrade process I received errors when I attempted to mount zfs filesystem. The error looked like this. zpool mount -a internal error: Invalid arugment pid 25 (zfs), uid 0, exited on signal 6 Abort trap Is your world and kernel out of sync? Regards Steve This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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 Yup, totally hit this today and was yelling at various people about it. the Kernel and the ZFS tools in userland need to be updated at the same time. Boot back into the old kernel and (cd /usr/src/cddl make install) to update the tools to a compatible version. sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on i386/i386
[...] cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Qunused-arguments -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-conversion -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -c /src/sbin/fsck_ffs/fsutil.c /src/sbin/fsck_ffs/fsutil.c:511:3: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] finishpass.tv_sec, finishpass.tv_nsec / 100); ^ /src/sbin/fsck_ffs/fsutil.c:525:7: error: format specifies type 'long' but the argument has type 'time_t' (aka 'int') [-Werror,-Wformat] readtime[i].tv_sec, readtime[i].tv_nsec / 100, ^~ 2 errors generated. *** [fsutil.o] Error code 1 Should be squished now. r248680 signature.asc Description: This is a digitally signed message part
Re: [head tinderbox] failure on ia64/ia64
On Sun, 2013-03-24 at 03:57 +, FreeBSD Tinderbox wrote: cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/ea.c cc -O2 -pipe -I/src/sbin/fsck_ffs -I/src/sbin/fsck_ffs/../mount -DRESCUE -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /src/sbin/fsck_ffs/fsutil.c cc1: warnings being treated as errors /src/sbin/fsck_ffs/fsutil.c: In function 'printIOstats': /src/sbin/fsck_ffs/fsutil.c:511: warning: format '%d' expects type 'int', but argument 2 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%4d' expects type 'int', but argument 6 has type 'time_t' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%2jd' expects type 'intmax_t', but argument 8 has type 'long long int' /src/sbin/fsck_ffs/fsutil.c:526: warning: format '%jd' expects type 'intmax_t', but argument 9 has type 'long long int' *** [fsutil.o] Error code 1 Stop in /src/sbin/fsck_ffs. *** [fsck_ffs_make] Error code 1 Seems happy now at svn r248680 signature.asc Description: This is a digitally signed message part
Re: Kernel panic CURRENT r248596 at virtualbox-ose-kmod module load
Yes - it is correctly http://svnweb.freebsd.org/ports/head/emulators/virtualbox-ose-kmod/files/patch-src-VBox-Runtime-r0drv-freebsd-memobj-r0drv-freebsd_VM_OBJECT_RENAME.c?r1=314797r2=315200 Ah, thank you. My patch definitely was not right and I was wondering where the kpanic on load/startup was coming from. :-) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: rebooting nvidia + keyboard issues
On Sun, 2013-03-31 at 00:25 -0700, Waitman Gobble wrote: I noticed the machine rebooting randomly every 20 seconds to 5 minutes. Disabling the nvidia driver seems to fix the problem, and I was able to update after applying ports/177459 patch. The updated nvidia driver seems to have solved the rebooting issue. (it could (also?) be related to linux.ko?) If people are using the nvidia driver and are experiencing a constant reboot issue, it might be good to pop in that patch ASAP patch was applied yesterday-ish to ports. Sean signature.asc Description: This is a digitally signed message part
Re: RE: rebooting nvidia + keyboard issues
On Wed, 2013-04-03 at 11:07 -0700, Adrian Chadd wrote: Hi, can you guys please ensure a PR is filed with all the information you've just included? the clang team would likely love to have this much information in a bug report. Thanks! adrian I've started a p/r for this as I get 100% reproducible panics on boot with clang compiled nvidia-driver at the point of entropy harvesting I'll get an actual panic string in a moment. Sean http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/177710 signature.asc Description: This is a digitally signed message part
Re: mirror site ftp3.za.freebsd.org
On Mon, 2013-04-15 at 11:22 +0200, Ian FREISLICH wrote: Hi For quite some time this mirror site has been unreachable. AFAICT, my ex colleagues who used to maintain it have moved on and it's now been left unmaintained. I left there in 2004 and Mark Murray who set it up left shortly thereafter. Perhaps it should be dropped from the mirror list. Ian Moving to clusteradm@ to poke at it. Sean signature.asc Description: This is a digitally signed message part
