bsdgrep: does anyone see this?
Hi, On the latest -CURRENT of r227785, I found bsdgrep acts differently from GNU grep; bsdgrep -R exits at first unreadable directory. == $ bsdgrep -R ddb /etc/ /etc/defaults/rc.conf:ddb_enable="NO" # Set to YES to load ddb scripts at boot. /etc/defaults/rc.conf:ddb_config="/etc/ddb.conf"# ddb(8) config file. grep: /etc/bluetooth/hcsecd.conf: Permission denied grep: /etc/ntp: Permission denied == == $ gnugrep -R ddb /etc/ /etc/defaults/rc.conf:ddb_enable="NO" # Set to YES to load ddb scripts at boot. /etc/defaults/rc.conf:ddb_config="/etc/ddb.conf"# ddb(8) config file. gnugrep: /etc/bluetooth/hcsecd.conf: Permission denied gnugrep: /etc/ntp: Permission denied gnugrep: /etc/ppp/ppp.conf: Permission denied /etc/rc.d/ddb:# $FreeBSD: head/etc/rc.d/ddb 208307 2010-05-19 19:03:19Z dougb $ /etc/rc.d/ddb:# PROVIDE: ddb /etc/rc.d/ddb:name="ddb" /etc/rc.d/ddb:start_precmd="ddb_prestart" /etc/rc.d/ddb:ddb_prestart() /etc/rc.d/ddb: # Silently exit if ddb is not enabled /etc/rc.d/ddb: if [ -z "`sysctl -Nq debug.ddb.scripting.scripts`" ]; then /etc/rc.d/ddb:required_files="${ddb_config}" /etc/rc.d/ddb:command_args="${ddb_config}" /etc/rc.d/initrandom:# REQUIRE: dumpon ddb /etc/rc.d/savecore:# REQUIRE: dumpon ddb syslogd gnugrep: /etc/security/audit_control: Permission denied gnugrep: /etc/security/audit_user: Permission denied gnugrep: /etc/security/audit_warn: Permission denied gnugrep: /etc/ssh/ssh_host_key: Permission denied gnugrep: /etc/ssh/ssh_host_dsa_key: Permission denied gnugrep: /etc/ssh/ssh_host_rsa_key: Permission denied gnugrep: /etc/ssh/ssh_host_ecdsa_key: Permission denied /etc/ddb.conf:# $FreeBSD: src/etc/ddb.conf,v 1.1 2008/03/05 18:32:58 brooks Exp $ /etc/ddb.conf:# ``ddb'' to define debugging scripts. /etc/ddb.conf:# see ``man 4 ddb'' and ``man 8 ddb'' for details. /etc/sysctl.conf:#debug.ddb.textdump.pending=1 gnugrep: /etc/namedb/s: Permission denied gnugrep: /etc/namedb/rndc.key: Permission denied gnugrep: warning: /etc/namedb/namedb: recursive directory loop /etc/portsnap.conf:KEYPRINT=9b5feee6d69f170e3dd0a2c8e469ddbd64f13f978f2f3aede40c98633216c330 gnugrep: /etc/master.passwd: Permission denied gnugrep: /etc/nsmb.conf: Permission denied gnugrep: /etc/opieaccess: Permission denied gnugrep: /etc/spwd.db: Permission denied gnugrep: /etc/opiekeys: Permission denied /etc/rc.conf.local:ddb_enable="YES" gnugrep: /etc/malloc.conf: No such file or directory == -- kuro ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
On Mon, Nov 21, 2011 at 06:39:26PM +0100, Robert Millan wrote: > (replying with Debian hat this time) > > 2011/11/21 Kostik Belousov : > > There are some implementations that > > use FreeBSD kernel, and which could potentially benefit from providing > > its own value for __FreeBSD_kernel. > > Actually, we wouldn't be able to provide a different value for the > macro (whatever its name). Our compiler simply doesn't know which > version of the kernel it is building for. Only the headers do, but if > we define it in the headers we'd just use the FreeBSD definitions. > > Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't > expect this will change because unlike with FreeBSD, on Debian there > are strong technical limitations to making it a number. > > If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest > that it is defined as an empty macro as well? This covers the vast > majority of cases (e.g. like the ones in my initial patch which > started this discussion), and it doesn't preclude the possibility that > this macro becomes a number without breaking backward compatibility. > > OTOH once you define it as a number, it becomes relevant whether you > did it with #ifndef or with #undef, and so you have to commit to it. > > Just to make it clear: It's no problem to me if it's defined as a > number, but it doesn't help much either. At least from Debian POV it's > not worth making a big argument about. It could be a good idea from > FreeBSD POV, but please only do this if it's useful to FreeBSD. > I am fine with __FreeBSD_kernel being empty, please submit the patch. pgpwSRj8FEROM.pgp Description: PGP signature
Re: /usr/home vs /home
> In the old days home was typically a separate partition that was > mounted on /home. If you didn't have a partition the installer would > create /usr/home and symlink /home to it. The root was also typically > an independent partition, so it made sense not to clutter it up with > home directories. > Now that the default behavior is to use one big partition, the > installer defaults to /usr/home + symlink. > I've always liked the more succinct /home and was wondering if there > is any reason why not to delete the symlink and move home to / to > mimic the old many partition style? > thanks, > dave c My preference is to use the traditional /home, on a separate partition. That way, user data can be kept safe in the case of a major upgrading or revamping of the system. This principle is even applicable for MS-Windows, even if the user-data partition is not called "home". A Linux user can run two or more distributions sharing the same /home with each other, but not the same /home as for FreeBSD because of different file system. bsdinstall on FreeBSD 9.0-BETA1 changed my /home to a symlink to /usr/home, but I changed it back to my preference. I read that PC-BSD considers /usr/home to be correct. I agree with Martin Sugioarto on preparing the disks myself rather than letting the installer do it. bsdinstall only made things more difficult for partitioning the disk, not allowing enough space, and also bsdinstall's boot partition was nonfunctional for me. But I don't see any advantage to putting /, /usr, and /var on separate partitions. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/home vs /home
On 22.11.2011 11:30, "Thomas Mueller > In the old days home was typically a separate partition that was >> mounted on /home. If you didn't have a partition the installer >> would create /usr/home and symlink /home to it. The root was also >> typically an independent partition, so it made sense not to clutter >> it up with home directories. > >> Now that the default behavior is to use one big partition, the >> installer defaults to /usr/home + symlink. > >> I've always liked the more succinct /home and was wondering if >> there is any reason why not to delete the symlink and move home to >> / to mimic the old many partition style? > >> thanks, dave c > > My preference is to use the traditional /home, on a separate > partition. That way, user data can be kept safe in the case of a > major upgrading or revamping of the system. > > This principle is even applicable for MS-Windows, even if the > user-data partition is not called "home". > > A Linux user can run two or more distributions sharing the same /home > with each other, but not the same /home as for FreeBSD because of > different file system. > > bsdinstall on FreeBSD 9.0-BETA1 changed my /home to a symlink to > /usr/home, but I changed it back to my preference. > > I read that PC-BSD considers /usr/home to be correct. > > I agree with Martin Sugioarto on preparing the > disks myself rather than letting the installer do it. bsdinstall > only made things more difficult for partitioning the disk, not > allowing enough space, and also bsdinstall's boot partition was > nonfunctional for me. > > But I don't see any advantage to putting /, /usr, and /var on > separate partitions. This might not be an universal advantage, but it is good to keep the choice. For example / could reside on a small flash memory built-in on the mainboard. /usr and /homes are mounted from different fileservers and /var is on a usb flash drive inside the case, because / is already filled. mata ne, Hendrik signature.asc Description: OpenPGP digital signature
Re: /usr/home vs /home
On 11/22/11 12:08, Hendrik Hasenbein wrote: > On 22.11.2011 11:30, "Thomas Mueller >> In the old days home was typically a separate partition that was >>> mounted on /home. If you didn't have a partition the installer >>> would create /usr/home and symlink /home to it. The root was also >>> typically an independent partition, so it made sense not to clutter >>> it up with home directories. >> >>> Now that the default behavior is to use one big partition, the >>> installer defaults to /usr/home + symlink. >> >>> I've always liked the more succinct /home and was wondering if >>> there is any reason why not to delete the symlink and move home to >>> / to mimic the old many partition style? >> >>> thanks, dave c >> >> My preference is to use the traditional /home, on a separate >> partition. That way, user data can be kept safe in the case of a >> major upgrading or revamping of the system. >> >> This principle is even applicable for MS-Windows, even if the >> user-data partition is not called "home". >> >> A Linux user can run two or more distributions sharing the same /home >> with each other, but not the same /home as for FreeBSD because of >> different file system. >> >> bsdinstall on FreeBSD 9.0-BETA1 changed my /home to a symlink to >> /usr/home, but I changed it back to my preference. >> >> I read that PC-BSD considers /usr/home to be correct. >> >> I agree with Martin Sugioarto on preparing the >> disks myself rather than letting the installer do it. bsdinstall >> only made things more difficult for partitioning the disk, not >> allowing enough space, and also bsdinstall's boot partition was >> nonfunctional for me. >> >> But I don't see any advantage to putting /, /usr, and /var on >> separate partitions. > > This might not be an universal advantage, but it is good to keep the > choice. For example / could reside on a small flash memory built-in on > the mainboard. /usr and /homes are mounted from different fileservers > and /var is on a usb flash drive inside the case, because / is already > filled. > > mata ne, > Hendrik Substantially it is irrelevant where the home-directory resides as long as it doesn't have any serious performance implications or anything else. Our homes resides on a dedicated ZFS volume and are mounted on /home since many Linux systems we use for HPC duties also expect their homes "by default" at /home. But there is indeed on critical issue. In some cases where it is allowed to log in as a user even no home folder could be mounted - say due to a failure of the ZFS subsystem or due to failure of mounting from a NAS/SAN or other kind of server - the "dead" mountpoint as empty as it is resides in the "/" filesystem which is usually very small. We/I preferr to use a legacy traditional partitioning of the directory structure with fixed partitions for /, var,/ var/tmp, /usr, /usr/local, /usr/obj, /usr/src and /usr/ports. It is, indeed, a huge waste of space, but under some critical circumstances it is much easier and more healthy for the system to "repair" only one partition with a subset of data than a mega-partition containing everything. well, in such a case, with a small "/", users are able to fill up, by accident or by intention, "/" which then could end up in a stuck system (if /tmp is also residing as a folder and not a partition in /). Havin the homes in /usr/home or even /usr/local/home (latter seems more logical to me since /usr is SYSTEM, and except root's home everything else is a local issue, also the additional homes for users). Regards, Oliver ___ 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"
RLIMIT_DATA and malloc(3) use of mmap(2)
I was reminded about the patch I wrote for Igor Sysoev some time ago. The issue the patch tries to handle is that jemalloc uses mmap() instead of sbrk() for pages allocation, and thus RLIMIT_DATA limit is no longer effective to put the bounds on the process heap. Since reverting to sbrk for such purpose is worse then the issue itself, I proposed a solution of 'self-restricting malloc'. The patch adds a flag MAP_DATALIMIT to the flags argument of mmap(2), which instructs the system to account the mapping in the RLIMIT_DATA resource count. The malloc(3) also gets new option 'L' to enable passing MAP_DATALIMIT to mmap() when allocating pages. By default, the 'L' option is not activated. Now, if user wants to ensure that process heap is restricted by the ulimit -d and still use mmap() for jemalloc, he supplies the option using any mechanism. The behaviour is voluntaristic, to prevent the trashing use RLIMIT_SWAP. Do people consider the facility useful ? Any comments for the patch itself ? http://people.freebsd.org/~kib/misc/map_datalimit.1.patch pgpX3zgzJhYr5.pgp Description: PGP signature
Re: did SVN r227753 (locale changes) break something?
On 22 Nov 2011, at 00:21, Michael Butler wrote: > #0 0x283eb243 in fprintf () from /lib/libc.so.7 This looks suspicious. uselocale() does not call fprintf(). In fact, nothing in xlocale.c does - fprintf() accesses the current locale, so calling it from anywhere in the setlocale() path is likely to be problematic. > #1 0x283eb558 in uselocale () from /lib/libc.so.7 > #2 0x283eb6f9 in newlocale () from /lib/libc.so.7 > #3 0x281637f2 in msg_Subscribe () from /usr/local/lib/libvlccore.so.4 The newlocale / uselocale functions were introduced with the xlocale commit, so no existing code should be using them. If you're just reconfigured / recompiled libvlccore.so then we may be in an untested code path - I'd have to see what the parameter to newlocale() was to be able to debug this. David___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
On Monday, November 21, 2011 12:39:26 pm Robert Millan wrote: > (replying with Debian hat this time) > > 2011/11/21 Kostik Belousov : > > There are some implementations that > > use FreeBSD kernel, and which could potentially benefit from providing > > its own value for __FreeBSD_kernel. > > Actually, we wouldn't be able to provide a different value for the > macro (whatever its name). Our compiler simply doesn't know which > version of the kernel it is building for. Only the headers do, but if > we define it in the headers we'd just use the FreeBSD definitions. > > Our compiler defines __FreeBSD_kernel__ as an empty macro, I don't > expect this will change because unlike with FreeBSD, on Debian there > are strong technical limitations to making it a number. > > If __FreeBSD_kernel__ is to be defined in FreeBSD land, may I suggest > that it is defined as an empty macro as well? This covers the vast > majority of cases (e.g. like the ones in my initial patch which > started this discussion), and it doesn't preclude the possibility that > this macro becomes a number without breaking backward compatibility. > > OTOH once you define it as a number, it becomes relevant whether you > did it with #ifndef or with #undef, and so you have to commit to it. > > Just to make it clear: It's no problem to me if it's defined as a > number, but it doesn't help much either. At least from Debian POV it's > not worth making a big argument about. It could be a good idea from > FreeBSD POV, but please only do this if it's useful to FreeBSD. Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD? Most things that want to check versions that I've seen do something like this: #ifdef __FreeBSD__ #include #if __FreeBSD_version > XXX /* use new feature */ #endif #endif If __FreeBSD_version is defined when __FreeBSD_kernel__ is defined, then I think having it be empty would be ok as it would allow usage as above. Also, in that case I think __FreeBSD_kernel__ is much closer in meaning to __FreeBSD__ than to __FreeBSD_version. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: did SVN r227753 (locale changes) break something?
It's entirely possible - please can you compile libc with debug symbols? The back trace isn't very informative... David On 22 Nov 2011, at 00:21, Michael Butler wrote: > VLC (multimedia/vlc) on my -current now crashes leaving a trace like this .. > > imb@toshi:/home/imb> gdb `which vlc` vlc.core > GNU gdb 6.1.1 [FreeBSD] > Copyright 2004 Free Software Foundation, Inc. > GDB is free software, covered by the GNU General Public License, and you are > welcome to change it and/or distribute copies of it under certain conditions. > Type "show copying" to see the conditions. > There is absolutely no warranty for GDB. Type "show warranty" for details. > This GDB was configured as "i386-marcel-freebsd"...(no debugging symbols > found)... > Core was generated by `vlc'. > Program terminated with signal 11, Segmentation fault. > Reading symbols from /usr/local/lib/libvlc.so.7...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libvlc.so.7 > Reading symbols from /usr/local/lib/libvlccore.so.4...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libvlccore.so.4 > Reading symbols from /usr/local/lib/libdbus-1.so.3...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libdbus-1.so.3 > Reading symbols from /lib/libm.so.5...(no debugging symbols found)...done. > Loaded symbols for /lib/libm.so.5 > Reading symbols from /usr/local/lib/libiconv.so.3...(no debugging symbols > found)...done. > Loaded symbols for /usr/local/lib/libiconv.so.3 > Reading symbols from /lib/libthr.so.3...(no debugging symbols found)...done. > Loaded symbols for /lib/libthr.so.3 > Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done. > Loaded symbols for /lib/libc.so.7 > Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols > found)...done. > Loaded symbols for /libexec/ld-elf.so.1 > #0 0x283eb243 in fprintf () from /lib/libc.so.7 > [New Thread 28804300 (LWP 100408/vlc)] > (gdb) bt > #0 0x283eb243 in fprintf () from /lib/libc.so.7 > #1 0x283eb558 in uselocale () from /lib/libc.so.7 > #2 0x283eb6f9 in newlocale () from /lib/libc.so.7 > #3 0x281637f2 in msg_Subscribe () from /usr/local/lib/libvlccore.so.4 > #4 0x in ?? () > #5 0x28191f6f in .rodata () from /usr/local/lib/libvlccore.so.4 > #6 0x28420120 in _CurrentRuneLocale () from /lib/libc.so.7 > #7 0x in ?? () > #8 0x281a3ee0 in .got () from /usr/local/lib/libvlccore.so.4 > #9 0x288400fc in ?? () > #10 0x288400fc in ?? () > #11 0x280ca9b6 in libvlc_InternalCreate () from /usr/local/lib/libvlccore.so.4 > #12 0x281a4df4 in .bss () from /usr/local/lib/libvlccore.so.4 > #13 0x005c in ?? () > #14 0xfd66 in ?? () > #15 0x281861d4 in .rodata () from /usr/local/lib/libvlccore.so.4 > #16 0x0440 in ?? () > #17 0x0001 in ?? () > #18 0x in ?? () > #19 0x280b4ad0 in .got () from /usr/local/lib/libvlc.so.7 > #20 0xbfbfe640 in ?? () > #21 0x0002 in ?? () > #22 0xbfbfe678 in ?? () > #23 0x280a39b2 in libvlc_new () from /usr/local/lib/libvlc.so.7 > Previous frame inner to this frame (corrupt stack?) > (gdb) > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: /usr/home vs /home
On Tue, Nov 22, 2011 at 11:30 AM, <"Thomas Mueller wrote: > But I don't see any advantage to putting /, /usr, and /var on separate > partitions. > > Tom Regarding separate /usr and /var: the advantage is that you can keep /usr read-only which is also important for security reasons since modifying system binaries becomes less easy. Furthermore, you can NFS share a read-only /usr among many similar machines, while /var is a per-machine specific read-write area. -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ 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: did SVN r227753 (locale changes) break something?
On 11/22/11 08:37, David Chisnall wrote: Do you have valgrind installed? It would probably also be helpful to see the results from that. With symbols for libc .. #0 xlocale_retain (val=0x0) at atomic.h:363 363 ATOMIC_ASM(add, long, "addl %1,%0", "ir", v); [New Thread 28804300 (LWP 100592/vlc)] (gdb) bt #0 xlocale_retain (val=0x0) at atomic.h:363 #1 0x283eb568 in dupcomponent (type=3, base=Variable "base" is not available. ) at /usr/home/imb/svn/head/lib/libc/locale/xlocale.c:204 #2 0x283eb709 in newlocale (mask=Variable "mask" is not available. ) at /usr/home/imb/svn/head/lib/libc/locale/xlocale.c:250 #3 0x281637f2 in msg_Subscribe () from /usr/local/lib/libvlccore.so.4 #4 0x in ?? () #5 0x28191f6f in .rodata () from /usr/local/lib/libvlccore.so.4 #6 0x28420120 in __xlocale_global_locale () from /lib/libc.so.7 #7 0x in ?? () #8 0x281a3ee0 in .got () from /usr/local/lib/libvlccore.so.4 #9 0x288400fc in ?? () #10 0x288400fc in ?? () #11 0x280ca9b6 in libvlc_InternalCreate () from /usr/local/lib/libvlccore.so.4 #12 0x281a4df4 in .bss () from /usr/local/lib/libvlccore.so.4 #13 0x005c in ?? () #14 0xfd66 in ?? () #15 0x281861d4 in .rodata () from /usr/local/lib/libvlccore.so.4 #16 0x0440 in ?? () #17 0x0001 in ?? () #18 0x in ?? () #19 0x280b4ad0 in .got () from /usr/local/lib/libvlc.so.7 #20 0xbfbfe640 in ?? () #21 0x0002 in ?? () #22 0xbfbfe678 in ?? () #23 0x280a39b2 in libvlc_new () from /usr/local/lib/libvlc.so.7 Previous frame inner to this frame (corrupt stack?) .. and valgrind shows .. imb@toshi:/home/imb> valgrind vlc ==41007== Memcheck, a memory error detector ==41007== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al. ==41007== Using Valgrind-3.6.1 and LibVEX; rerun with -h for copyright info ==41007== Command: vlc ==41007== VLC media player 1.1.12 The Luggage (revision exported) ==41007== Invalid read of size 4 ==41007==at 0x3BC253: ??? (atomic.h:363) ==41007==by 0x3BC567: ??? (xlocale.c:204) ==41007==by 0x3BC708: newlocale (xlocale.c:250) ==41007==by 0x1347F1: msg_Create (in /usr/local/lib/libvlccore.so.4) ==41007== Address 0x0 is not stack'd, malloc'd or (recently) free'd ==41007== ==41007== ==41007== Process terminating with default action of signal 11 (SIGSEGV): dumping core ==41007== Access not within mapped region at address 0x0 ==41007==at 0x3BC253: ??? (atomic.h:363) ==41007==by 0x3BC567: ??? (xlocale.c:204) ==41007==by 0x3BC708: newlocale (xlocale.c:250) ==41007==by 0x1347F1: msg_Create (in /usr/local/lib/libvlccore.so.4) ==41007== If you believe this happened as a result of a stack ==41007== overflow in your program's main thread (unlikely but ==41007== possible), you can try to increase the size of the ==41007== main thread stack using the --main-stacksize= flag. ==41007== The main thread stack size used in this run was 16777216. ==41007== ==41007== HEAP SUMMARY: ==41007== in use at exit: 9,284 bytes in 76 blocks ==41007== total heap usage: 79 allocs, 3 frees, 9,316 bytes allocated ==41007== ==41007== LEAK SUMMARY: ==41007==definitely lost: 0 bytes in 0 blocks ==41007==indirectly lost: 0 bytes in 0 blocks ==41007== possibly lost: 554 bytes in 13 blocks ==41007==still reachable: 8,730 bytes in 63 blocks ==41007== suppressed: 0 bytes in 0 blocks ==41007== Rerun with --leak-check=full to see details of leaked memory ==41007== ==41007== For counts of detected and suppressed errors, rerun with: -v ==41007== ERROR SUMMARY: 1 errors from 1 contexts (suppressed: 0 from 0) Segmentation fault .. so it looks like a NULL pointer but I guess I need to recompile libvlc to see if it's involved, imb ___ 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: did SVN r227753 (locale changes) break something?
On 22 Nov 2011, at 14:00, Michael Butler wrote: > On 11/22/11 08:52, David Chisnall wrote: >> Please can you try this patch? ... > That works :-) > > Thanks! Fixed in head (r227818), thanks for the report! David ___ 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: ixgbe and fast interrupts
On Monday, November 21, 2011 12:36:15 pm Luigi Rizzo wrote: > On Mon, Nov 21, 2011 at 11:29:29AM -0500, John Baldwin wrote: > > On Friday, November 18, 2011 5:04:58 pm Luigi Rizzo wrote: > > > On Fri, Nov 18, 2011 at 11:16:00AM -0800, Doug Barton wrote: > > > > On 11/18/2011 09:54, Luigi Rizzo wrote: > > > > > One more thing (i am mentioning it here for archival purposes, > > > > > as i keep forgetting to test it). Is entropy harvesting expensive ? > > > > > > > > No. It was designed to be inexpensive on purpose. :) > > > > > > hmmm > > > unfortunately I don't have a chance to test it until monday > > > (probably one could see if the ping times change by modifying > > > the value of kern.random.sys.harvest.* ). > > > > > > But in the code i see the following: > > > > > > - the harvest routine is this: > > > > > > void > > > random_harvest(void *entropy, u_int count, u_int bits, u_int frac, > > > enum esource origin) > > > { > > > if (reap_func) > > > (*reap_func)(get_cyclecount(), entropy, count, bits, frac, > > > origin); > > > } > > > > > > - the reap_func seems to be bound to > > > > > > dev/random/randomdev_soft.c::random_harvest_internal() > > > > > > which internally uses a spinlock and then moves entries between > > > two lists. > > > > > > I am concerned that the get_cyclecount() might end up querying an > > > expensive device (is it using kern.timecounter.hardware ?) > > > > On modern x86 it just does rdtsc(). > > > > > So between the indirect function call, spinlock, list manipulation > > > and the cyclecounter i wouldn't be surprised it the whole thing > > > takes a microsecond or so. > > > > I suspect it is not quite that expensive. > > > > > Anyways, on monday i'll know better. in the meantime, if someone > > > wants to give it a try... in our tests between two machines and > > > ixgbe (10G) interfaces, an unmodified 9.0 kernel has a median ping > > > time of 30us with "slow" pings (say -i 0.01 or larger) and 17us with > > > a ping -f . > > > > Did you time it with harvest.interrupt disabled? > > yes, thanks for reminding me to post the results. > > Using unmodified ping (which has 1us resolution on the reports), > there is no measurable difference irrespective > of the setting of kern.random.sys.harvest.ethernet, > kern.random.sys.harvest.interrupt and kern.timecounter.hardware. > Have tried to set hw mitigation to 0 on the NIC (ixgbe on both > sides) but there is no visible effect either. I had forgotten that kern.random.sys.harvest.interrupt only matters if the interrupt handlers pass the INTR_ENTROPY flag to bus_setup_intr(). I suspect your drivers probably aren't doing that anyway. > However I don't trust my measurements because i cannot explain them. > Response times have a min of 20us (about 50 out of 5000 samples) > and a median of 27us, and i really don't understand if the low > readings are real or the result of some races. Hmm, 7 us does seem a bit much for a spread. > Ping does a gettimeofday() for the initial timestamp, and relies > on in-kernel timestamp for the response. Hmm, gettimeofday() isn't super cheap. What I do for measuring RTT is to use an optimized echo server (not the one in inetd) on the remote host and reflect packets off of that. The sender/receiver puts a TSC timestamp into the packet payload and computes a TSC delta when it receives the reflected response. I then run ministat over the TSC deltas to get RTT in TSC counts and use machdep.tsc_freq of the sending machine to convert the TSC delta values to microseconds. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On Monday, November 21, 2011 1:05:28 pm Nathan Whitehorn wrote: > On 11/21/11 11:52, John Baldwin wrote: > > On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: > >> On 11/18/11 17:09, nev...@tx.net wrote: > >>> > >>> If you are performating a manual partion in 9.0-RC2 bsdinstall and you > >>> delete any created partition except the most recently created one, the > >>> total remaining space will be miscalculated. Reproducable as shown > >>> below. > >>> > >>> Workaround: if you delete a partition that is not the last partition > >>> that was created, delete all partitions created after that partition > >>> before continuing. Order does not seem to be important. > >>> > >>> The results are similar with other hard drive sizes, with the i386 or > >>> amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go > >>> back and check install discs prior to RC1) > >>> > >>> Reproducing the miscount: > >>> > >>> A 114 GB drive is used for this example: > >>> > >>>Select Manual Partitioning > >>> > >>>Perform the first Create on the drive and select GPT > >>> > >>>Creating the first partition: "Add Partition" "size" shows 114GB > >>> > >>> Change size to 4GB, set mountpoint to / and tab to OK > >>>(agree to the boot partition creation) > >>> > >>>Create a second partition: "Add Partition" "size" shows 110GB > >>> > >>> Adjust size to 10GB, set mountpoint to /usr and tab to OK > >>> > >>>Create a third partition: "Add Partition" "size" shows 100GB > >>> > >>> Adjust size to 20GB, set mountpoint to /var, and tab to OK > >>> > >>>Create a 4th partition: "size" shows 80GB remaining > >>> > >>> Adjust size to 40GB, set mountpoint to /data, and tab to OK. > >>> > >>> There is 40 GB remaining on the drive. Now change the size of /var. > >>> First, delete the currently configured /var partition. > >>> > >>> In the Partition Editor, adding up all the lines on the screen shows > >>> 54GB (plus a 64K boot) as allocated, so there should now be 60GB > >>> remaining. But the deleted /var space has not been added back into > >>> the total. > >>> > >>> Select Create again: "Add Partition" "size" shows 40GB > >>> > >>> Adjust size to 30GB, set mountpoint as /var, tab to OK > >>> > >>> A subsequent "Create" will show that 20GB is remaining, rather than > >>> the actual remaining 30GB. Selecting any size 20GB or larger for > >>> /home will give you a 20GB partition, and then an additional create > >>> will show the 10GB. > >> > >> This isn't a bug. The partitions are laid out on disk already, and, > >> because you deleted one in the middle, the largest *contiguous* block of > >> free space is 20GB, which is what is shown and the maximum it is > >> possible to create. That's why you can make one 20 GB partition and one > >> 10 GB partition, but not a single 30 GB one. > > > > Except that this is not intuitive. If I'm laying out a disk and haven't > > committed the changes yet, it should be possible to do things like resize > > an existing partition, or have the installer realize that if you delete > > one partition the other partitions that are pending should just "move up" > > to maximize free space automatically. I ran into this when first trying > > the new installer last week where you could not modify a pending partition's > > size which I found non-intuitive. > > > > There doesn't seem to be an easy solution though. Not laying them out on > disk is extremely fragile: the installer needs to know tons of tiny > details about the partition schemes (alignment constraints, partition > numbering/lettering, available space after the header, the list is very > long) or it will break. One simple example is that whether a partition > is ad0s1 or ad0s3 depends on its order on the disk (or in the partition > table anyway). If I have an ad0s2 and s3, and delete the s2, should the > new partition be s2 or s4? That depends on a lot of things the installer > can't easily know about, and that even if it could, simulating which > would be dangerous. I think you would need to not commit to as many details up front and figure out the names and exact sizes when doing the commit if you wanted to support this (i.e. you know the user wants a partition of 4GB, another one of 2GB, and one for "rest of disk", and you only bind those to specific names and exact sizes on the final commit). -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID
On Monday, November 21, 2011 1:45:36 pm John Nielsen wrote: > This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it to a DVD. I have a computer that currently runs Windows 7 but I plan to install FreeBSD on it in the near future so I booted it up from the DVD to check the hardware/driver status. Much to my dismay, the boot loader crashed right away (register dump followed by "BTX halted") and the computer immediately rebooted. I took a video with my phone so I could capture the crash message, screenshot here: > > http://picpaste.com/pics/BTXcrash.1321899682.jpg > > I then tried tweaking a few BIOS settings and found that turning off the built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA type from "RAID" to "AHCI". Fortunately I plan to use the controller in AHCI mode for the FreeBSD installation so this won't end up being a problem for me, but I still thought it was worth reporting. Hmmm, so this is odd. It died with an Invalid TSS exception on the iret instruction at the end of the return-from-real-mode trampoline in BTX. Looking at the dump I noticed that PSL_NT is set in %eflags, so for some reason the iret was trying to do a nested task return. We shouldn't let that flag leak out of any real mode code. Try this patch perhaps: Index: btx.S === --- btx.S (revision 227815) +++ btx.S (working copy) @@ -39,6 +39,8 @@ .set PSL_RESERVED_DEFAULT,0x0002 .set PSL_T,0x0100 # Trap flag .set PSL_I,0x0200 # Interrupt enable flag + .set PSL_D,0x0400 # String instruction direction + .set PSL_NT,0x4000 # Nested task flag .set PSL_VM,0x0002 # Virtual 8086 mode flag .set PSL_AC,0x0004 # Alignment check flag /* @@ -609,8 +611,8 @@ rret_tramp: movw $MEM_ESPR-0x08,%sp # Reset stack pushl %ds # regs pushl %es pushfl # Save %eflags - cli # Disable interrupts - std # String ops dec + pushl $PSL_RESERVED_DEFAULT|PSL_D # Use clean %eflags with + popfl # string ops dec xorw %ax,%ax# Reset seg movw %ax,%ds# regs movw %ax,%es# (%ss is already 0) @@ -673,6 +675,7 @@ rret_tramp.1: xorl %ecx,%ecx # Zero testl $V86F_FLAGS,%edx # User wants flags? jz rret_tramp.3 # No movl MEM_ESPR-0x3c,%eax # Read real mode flags + andl $~(PSL_T|PSL_NT),%eax # Clear unsafe flags movw %ax,-0x08(%esi)# Update user flags (low 16) /* * Return to the user task I haven't tested it yet, so only try this from a CD install for now. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 9.0-RC2 - bsdinstall miscount of remaining diskspace after partition deletion.
On 11/22/11 07:46, John Baldwin wrote: On Monday, November 21, 2011 1:05:28 pm Nathan Whitehorn wrote: On 11/21/11 11:52, John Baldwin wrote: On Saturday, November 19, 2011 7:07:58 pm Nathan Whitehorn wrote: On 11/18/11 17:09, nev...@tx.net wrote: If you are performating a manual partion in 9.0-RC2 bsdinstall and you delete any created partition except the most recently created one, the total remaining space will be miscalculated. Reproducable as shown below. Workaround: if you delete a partition that is not the last partition that was created, delete all partitions created after that partition before continuing. Order does not seem to be important. The results are similar with other hard drive sizes, with the i386 or amd64 distributions, and with either 9.0-RC2 or 9.0-RC1 (I did not go back and check install discs prior to RC1) Reproducing the miscount: A 114 GB drive is used for this example: Select Manual Partitioning Perform the first Create on the drive and select GPT Creating the first partition: "Add Partition" "size" shows 114GB Change size to 4GB, set mountpoint to / and tab to OK (agree to the boot partition creation) Create a second partition: "Add Partition" "size" shows 110GB Adjust size to 10GB, set mountpoint to /usr and tab to OK Create a third partition: "Add Partition" "size" shows 100GB Adjust size to 20GB, set mountpoint to /var, and tab to OK Create a 4th partition: "size" shows 80GB remaining Adjust size to 40GB, set mountpoint to /data, and tab to OK. There is 40 GB remaining on the drive. Now change the size of /var. First, delete the currently configured /var partition. In the Partition Editor, adding up all the lines on the screen shows 54GB (plus a 64K boot) as allocated, so there should now be 60GB remaining. But the deleted /var space has not been added back into the total. Select Create again: "Add Partition" "size" shows 40GB Adjust size to 30GB, set mountpoint as /var, tab to OK A subsequent "Create" will show that 20GB is remaining, rather than the actual remaining 30GB. Selecting any size 20GB or larger for /home will give you a 20GB partition, and then an additional create will show the 10GB. This isn't a bug. The partitions are laid out on disk already, and, because you deleted one in the middle, the largest *contiguous* block of free space is 20GB, which is what is shown and the maximum it is possible to create. That's why you can make one 20 GB partition and one 10 GB partition, but not a single 30 GB one. Except that this is not intuitive. If I'm laying out a disk and haven't committed the changes yet, it should be possible to do things like resize an existing partition, or have the installer realize that if you delete one partition the other partitions that are pending should just "move up" to maximize free space automatically. I ran into this when first trying the new installer last week where you could not modify a pending partition's size which I found non-intuitive. There doesn't seem to be an easy solution though. Not laying them out on disk is extremely fragile: the installer needs to know tons of tiny details about the partition schemes (alignment constraints, partition numbering/lettering, available space after the header, the list is very long) or it will break. One simple example is that whether a partition is ad0s1 or ad0s3 depends on its order on the disk (or in the partition table anyway). If I have an ad0s2 and s3, and delete the s2, should the new partition be s2 or s4? That depends on a lot of things the installer can't easily know about, and that even if it could, simulating which would be dangerous. I think you would need to not commit to as many details up front and figure out the names and exact sizes when doing the commit if you wanted to support this (i.e. you know the user wants a partition of 4GB, another one of 2GB, and one for "rest of disk", and you only bind those to specific names and exact sizes on the final commit). Exactly. It requires a fundamental rewrite of the code -- something also fraught with peril because some partition schemes (VTOC8 comes to mind) have ... interesting ... rules that the partitioner would need to know about. -Nathan ___ 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: Adding disk firmware programming capability to camcontrol
Hi, Sorry for the late reply. As I mentioned in the man page, the fwdownload command currently only supports SCSI disks. "fwdownload: Program firmware of the named <> device using the image file provided." We have added firmware download command to atacontrol at work, for which I have attached a patch against 8.2 to this email. The format of the command is similar to the camcontrol counterpart: atacontrol fwdownload But ultimately we would like to add the support to program ATA/SATA disks to camcontrol as well. Nima Misaghian nmisagh...@sandvine.com > -Original Message- > From: owner-freebsd-curr...@freebsd.org [mailto:owner-freebsd- > curr...@freebsd.org] On Behalf Of Pegasus Mc Cleaft > Sent: Sunday, November 20, 2011 9:55 AM > To: freebsd-current@freebsd.org > Cc: an...@albsmeier.net; Nima Misaghian > Subject: Re: Adding disk firmware programming capability to camcontrol > > Hi Nima, > > I have tried your latest patch against current, but I am having > difficulty > getting it to work. I was wondering, is this feature limited to SCSI > drives? > I have been trying it against my SATA drives but it looks like it is > failing > on issuing a TUR. > > IE: > > feathers# camcontrol fwdownload ada5 -f JP0NB3MA.BD -s -v > Running in simulation mode > camcontrol: Device is not ready > (pass5:ahcich4:0:0:0): TEST UNIT READY. CDB: 0 0 0 0 0 0 > (pass5:ahcich4:0:0:0): CAM status: CCB request was invalid > Firmware download failed > > > I have tried issuing a TUR to all my drives to see if it was controller > or > drive specific, but all of them return the same error (The drives are > Seagate, > Hitachi and WD). > > What am I doing wrong? > > Ta > Peg > ___ > 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" atacontrol.diff Description: atacontrol.diff ___ 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: RLIMIT_DATA and malloc(3) use of mmap(2)
On Tue, Nov 22, 2011 at 07:43:57PM +0400, Maxim Dounin wrote: > Hello! > > On Tue, Nov 22, 2011 at 02:44:10PM +0200, Kostik Belousov wrote: > > > I was reminded about the patch I wrote for Igor Sysoev some time ago. > > The issue the patch tries to handle is that jemalloc uses mmap() instead > > of sbrk() for pages allocation, and thus RLIMIT_DATA limit is no longer > > effective to put the bounds on the process heap. Since reverting to sbrk > > for such purpose is worse then the issue itself, I proposed a solution > > of 'self-restricting malloc'. > > Just a little clarification for others: currently, there is no way > to *safely* limit memory usage of a process while using jemalloc > with mmap(). > > The only thing available is RLIMIT_VMEM, but it's not safe as it > may be reached on stack grow (leaving no possibility for an > application to handle this). > > > The patch adds a flag MAP_DATALIMIT to the flags argument of mmap(2), > > which instructs the system to account the mapping in the RLIMIT_DATA > > resource count. The malloc(3) also gets new option 'L' to enable > > passing MAP_DATALIMIT to mmap() when allocating pages. By default, > > the 'L' option is not activated. > > > > Now, if user wants to ensure that process heap is restricted by the > > ulimit -d and still use mmap() for jemalloc, he supplies the option > > using any mechanism. The behaviour is voluntaristic, to prevent the > > trashing use RLIMIT_SWAP. > > > > Do people consider the facility useful ? > > Yes, at least some way to safely limit process memory usage is > certainly needed. > > It's a bit sad this isn't enabled by default, but it's probably > too late for this. RLIMIT_DATA was (almost) a noop for too long > and making it work again to limit all memory allocations will > break POLA. > > > Any comments for the patch itself ? > > > > http://people.freebsd.org/~kib/misc/map_datalimit.1.patch > > Patch looks ok for me (though I'm not a VM expert). > > Another possible aproach would be to introduce separate anonymous > (private?) mmap limit, this will allow to do essentially the same > thing in a bit more consistent (IMHO) manner. This is already done in some form as the per-user swap limit. Converting swap limit to the per-process limit raises the architectural questions, due to shadow chains of the backing vm objects. In particular, we have to account the anonymous memory used for backing the changed pages from the writeable private mapping of the files. Similar issues appear due to fork(). Anyway, the patch needs testers before I will push it forward. pgpJsHif0AqVL.pgp Description: PGP signature
Re: RLIMIT_DATA and malloc(3) use of mmap(2)
Hello! On Tue, Nov 22, 2011 at 02:44:10PM +0200, Kostik Belousov wrote: > I was reminded about the patch I wrote for Igor Sysoev some time ago. > The issue the patch tries to handle is that jemalloc uses mmap() instead > of sbrk() for pages allocation, and thus RLIMIT_DATA limit is no longer > effective to put the bounds on the process heap. Since reverting to sbrk > for such purpose is worse then the issue itself, I proposed a solution > of 'self-restricting malloc'. Just a little clarification for others: currently, there is no way to *safely* limit memory usage of a process while using jemalloc with mmap(). The only thing available is RLIMIT_VMEM, but it's not safe as it may be reached on stack grow (leaving no possibility for an application to handle this). > The patch adds a flag MAP_DATALIMIT to the flags argument of mmap(2), > which instructs the system to account the mapping in the RLIMIT_DATA > resource count. The malloc(3) also gets new option 'L' to enable > passing MAP_DATALIMIT to mmap() when allocating pages. By default, > the 'L' option is not activated. > > Now, if user wants to ensure that process heap is restricted by the > ulimit -d and still use mmap() for jemalloc, he supplies the option > using any mechanism. The behaviour is voluntaristic, to prevent the > trashing use RLIMIT_SWAP. > > Do people consider the facility useful ? Yes, at least some way to safely limit process memory usage is certainly needed. It's a bit sad this isn't enabled by default, but it's probably too late for this. RLIMIT_DATA was (almost) a noop for too long and making it work again to limit all memory allocations will break POLA. > Any comments for the patch itself ? > > http://people.freebsd.org/~kib/misc/map_datalimit.1.patch Patch looks ok for me (though I'm not a VM expert). Another possible aproach would be to introduce separate anonymous (private?) mmap limit, this will allow to do essentially the same thing in a bit more consistent (IMHO) manner. Maxim Dounin ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
On Tue, Nov 22, 2011 at 11:35:15AM +0200, Kostik Belousov wrote: > I am fine with __FreeBSD_kernel being empty, please submit the patch. Here. -- Robert Millan Index: sys/sys/param.h === --- sys/sys/param.h (revision 227580) +++ sys/sys/param.h (working copy) @@ -60,6 +60,22 @@ #undef __FreeBSD_version #define __FreeBSD_version 101 /* Master, propagated to newvers */ +/* + * __FreeBSD_kernel__ indicates that this system uses the kernel of FreeBSD, + * which by definition is always true on FreeBSD. This macro is also defined + * on other systems that use the kernel of FreeBSD, such as GNU/kFreeBSD + * + * It is tempting to use this macro in userland code when we want to enable + * kernel-specific routines, and in fact it's fine to do this in code that + * is part of FreeBSD itself. However, be aware that as presence of this + * macro is still not widespread (e.g. older FreeBSD versions, 3rd party + * compilers, etc), it is STRONGLY DISCOURAGED to check for this macro in + * external applications without also checking for __FreeBSD__ as an + * alternative. + */ +#undef __FreeBSD_kernel__ +#define __FreeBSD_kernel__ + #ifdef _KERNEL #define P_OSREL_SIGWAIT 70 #define P_OSREL_SIGSEGV 74 signature.asc Description: Digital signature
Re: [PATCH] Detect GNU/kFreeBSD in user-visible kernel headers
2011/11/22 John Baldwin : > Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD? Not currently (except for kernel-space code), but if all the checks that use __FreeBSD_version are like the one you describe, I think it'd make sense. But we need to make sure that defining it wouldn't suddenly enable code that is intended for FreeBSD userland, like it happens with __FreeBSD__. It'd also have to be discussed on Debian mailing list. My first impression is that defining it could be useful in some situations. We just don't run into this kind of situation so often, so this possibility AFAIK has never been discussed. I had it in my TODO to bring it up. -- Robert Millan ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
Hi Robert, * Robert Millan , 2022 18:53: > +#undef __FreeBSD_kernel__ > +#define __FreeBSD_kernel__ So why not remove the #undef and not let the compiler define it at all? -- Ed Schouten WWW: http://80386.nl/ pgpNzLA7HWcFI.pgp Description: PGP signature
buildworld race?
Anyone seen this too? make: don't know how to make /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop *** Error code 2 Happens on amd64 and powerpc64 while doing a make -j4 buildworld. Continuing with -DNO_CLEAN -j1 completes the build. Thanks, Andreas ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
Hi Ed, 2011/11/22 Ed Schouten : >> +#undef __FreeBSD_kernel__ >> +#define __FreeBSD_kernel__ > > So why not remove the #undef and not let the compiler define it at all? Well I have no objection if the #undef is removed. I don't understand why you consider it a problem though. It's not terribly useful but if compilers can opt in and define it (usually as an empty macro), this doesn't hurt either AFAICT. The problem I described before was about compilers being forced to provide a number. Anyhow, I don't think it makes a big difference. ___ 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: buildworld race?
В Tue, 22 Nov 2011 19:35:22 +0100 Andreas Tobler пишет: > Anyone seen this too? > > make: don't know how to make > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop > *** Error code 2 > > Happens on amd64 and powerpc64 while doing a make -j4 buildworld. > Continuing with -DNO_CLEAN -j1 completes the build. > > Thanks, > Andreas I see the same thing. Now try to find what SVN revision it happened ...http://komitet-2012.com ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
On Tuesday, November 22, 2011 12:59:19 pm Robert Millan wrote: > 2011/11/22 John Baldwin : > > Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined on kFreeBSD? > > Not currently (except for kernel-space code), but if all the checks > that use __FreeBSD_version are like the one you describe, I think it'd > make sense. I can think of cases where you might want it exposed (e.g. in the parts of net-snmp that grovel around in kernel data structures and use __FreeBSD_version to figure out what the right thing to do is, possibly the same with lsof). > But we need to make sure that defining it wouldn't suddenly enable > code that is intended for FreeBSD userland, like it happens with > __FreeBSD__. Correct. I don't believe that is the case since normally one has to check for __FreeBSD__ before using __FreeBSD_version. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: buildworld race?
В Tue, 22 Nov 2011 21:20:10 +0200 Ivan Klymenko пишет: > В Tue, 22 Nov 2011 19:35:22 +0100 > Andreas Tobler пишет: > > > Anyone seen this too? > > > > make: don't know how to make > > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop > > *** Error code 2 > > > > Happens on amd64 and powerpc64 while doing a make -j4 buildworld. > > Continuing with -DNO_CLEAN -j1 completes the build. > > > > Thanks, > > Andreas > > I see the same thing. > Now try to find what SVN revision it > happened ...http://komitet-2012.com Sorry for URL :( ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
2011/11/22 John Baldwin : >> Not currently (except for kernel-space code), but if all the checks >> that use __FreeBSD_version are like the one you describe, I think it'd >> make sense. > > I can think of cases where you might want it exposed (e.g. in the parts > of net-snmp that grovel around in kernel data structures and use > __FreeBSD_version to figure out what the right thing to do is, possibly > the same with lsof). > >> But we need to make sure that defining it wouldn't suddenly enable >> code that is intended for FreeBSD userland, like it happens with >> __FreeBSD__. > > Correct. Â I don't believe that is the case since normally one has to > check for __FreeBSD__ before using __FreeBSD_version. Makes sense. I'll bring this up in debian-bsd mailing list. Thanks for the tip -- Robert Millan ___ 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: buildworld race?
On Tue, Nov 22, 2011 at 10:35 AM, Andreas Tobler wrote: > Anyone seen this too? > Yes, I've been running into this error too. Navdeep > make: don't know how to make > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop > *** Error code 2 > > Happens on amd64 and powerpc64 while doing a make -j4 buildworld. > Continuing with -DNO_CLEAN -j1 completes the build. > > Thanks, > Andreas > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: ee (easy editor) bugged on 9.0?
On Sun, Nov 20, 2011 at 11:02 PM, Stefan Bethke wrote: > Am 20.11.2011 um 14:41 schrieb Jason Edwards: > >> Some of you asked for the environmental settings. Using 'env' the >> output begins with: >> >> -- on console -- >> TERM=cons25 >> SHELL=/usr/local/bin/bash >> >> -- via SSH -- >> TERM=xterm >> SHELL=/usr/local/bin/bash >> >> Via SSH the ee editor works as it should. On the console it is bugged. > > As I suspected. Â On my fresh 90-RC1 install, I get xterm for all the console > terminals. Â You'll have to check where your /etc/ttys picks up the old > entries. Â Both stable and releng have the updated version, as far as I can > tell. Hi Stefan, I'm very sorry for not having checked properly, but you are indeed correct. I had overlooked one script which replaces the /etc/ttys which I did not suspect. Sorry for the confusion! With TERM=xterm, ee indeed works properly on the console. I wonder: is cons25 bugged or simply obsolete? Not that I want to keep cons25; just being curious. Regards, Jason Edwards ___ 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: buildworld race?
В Tue, 22 Nov 2011 19:35:22 +0100 Andreas Tobler пишет: > Anyone seen this too? > > make: don't know how to make > /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop > *** Error code 2 > > Happens on amd64 and powerpc64 while doing a make -j4 buildworld. > Continuing with -DNO_CLEAN -j1 completes the build. > > Thanks, > Andreas Problem is solved in revision 227841 http://svn.freebsd.org/changeset/base/227841 ___ 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: 0 Re: buildworld race?
On 22.11.11 22:26, Ivan Klymenko wrote: В Tue, 22 Nov 2011 19:35:22 +0100 Andreas Tobler пишет: Anyone seen this too? make: don't know how to make /usr/obj/export/devel/fbsd/src/tmp/usr/lib/libkrb5.a. Stop *** Error code 2 Happens on amd64 and powerpc64 while doing a make -j4 buildworld. Continuing with -DNO_CLEAN -j1 completes the build. Thanks, Andreas Problem is solved in revision 227841 http://svn.freebsd.org/changeset/base/227841 Confirmed and seen, thanks :) Andreas ___ 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] Detect GNU/kFreeBSD in user-visible kernel headers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/22/2011 1:21 PM, John Baldwin wrote: > On Tuesday, November 22, 2011 12:59:19 pm Robert Millan wrote: >> 2011/11/22 John Baldwin : >>> Is __FreeBSD_version defined if __FreeBSD_kernel__ is defined >>> on kFreeBSD? >> >> Not currently (except for kernel-space code), but if all the >> checks that use __FreeBSD_version are like the one you describe, >> I think it'd make sense. > > I can think of cases where you might want it exposed (e.g. in the > parts of net-snmp that grovel around in kernel data structures and > use __FreeBSD_version to figure out what the right thing to do is, > possibly the same with lsof). > >> But we need to make sure that defining it wouldn't suddenly >> enable code that is intended for FreeBSD userland, like it >> happens with __FreeBSD__. > > Correct. I don't believe that is the case since normally one has > to check for __FreeBSD__ before using __FreeBSD_version. > Let me know if I can help on the lsof front. I'm the maintainer of the FreeBSD lsof port, and have access to the developer. - -- Larry Rosenman http://www.lerctr.org/~ler Phone: +1 512-248-2683 E-Mail: l...@lerctr.org US Mail: 430 Valona Loop, Round Rock, TX 78681-3893 -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.17 (MingW32) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iQEcBAEBAgAGBQJOzCZQAAoJENC8dtAvA1zmuLoIAItbMRQhoF1OcW9DVI9A1qNj UHCUCIlqYqS16m+/xoagjrPdjNK/nrP1aU791KIyvtaVZQ4HCsrzsePHv7iyGBAQ L1APl7FXkAl7If3C+Nl2tJ+kiRrM8bp336KSoVnipm5zbCX7Zhp7ZFFNpcNGQ0V4 7LJdtqIwyWtPzTIdri/qARVnOcBEaG8OYj+N55JTVjPL6cqeSiu2uQSAw9tgGY68 SMQ22N04HGOrFPcGUaHA9A4RbM/b/au2oqFN+2ggcC84qpweJMMLn3/lNksM0vj+ N+RkpafGdkmUAomUYoGP7BqHx0RMnEC7Kkc2y6Ti3HeIwcbehQR+RN6953ELGwk= =Rpp5 -END PGP SIGNATURE- ___ 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"
Remote access to HP Proliant hardware available to fix the problem with failing booting 9.0 on ciss(4), HP SmartArray P410i
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 girgen@FreeBSD.org___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-11-22 21:46:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-22 21:46:00 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-22 21:46:00 - cleaning the object tree TB --- 2011-11-22 21:46:23 - cvsupping the source tree TB --- 2011-11-22 21:46:23 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-22 21:46:41 - building world TB --- 2011-11-22 21:46:41 - CROSS_BUILD_TESTING=YES TB --- 2011-11-22 21:46:41 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-22 21:46:41 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-22 21:46:41 - SRCCONF=/dev/null TB --- 2011-11-22 21:46:41 - TARGET=powerpc TB --- 2011-11-22 21:46:41 - TARGET_ARCH=powerpc TB --- 2011-11-22 21:46:41 - TZ=UTC TB --- 2011-11-22 21:46:41 - __MAKE_CONF=/dev/null TB --- 2011-11-22 21:46:41 - cd /src TB --- 2011-11-22 21:46:41 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 22 21:46:42 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:116: error: 'AT_NOTELF' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:116: error: (Each undeclared identifier is reported only once /src/usr.bin/procstat/procstat_auxv.c:116: error: for each function it appears in.) /src/usr.bin/procstat/procstat_auxv.c:120: error: 'AT_UID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:124: error: 'AT_EUID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:128: error: 'AT_GID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:132: error: 'AT_EGID' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-22 23:40:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-22 23:40:29 - ERROR: failed to build world TB --- 2011-11-22 23:40:29 - 5575.50 user 933.90 system 6869.42 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-11-22 22:16:15 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-22 22:16:15 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-22 22:16:15 - cleaning the object tree TB --- 2011-11-22 22:16:33 - cvsupping the source tree TB --- 2011-11-22 22:16:33 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-22 22:16:46 - building world TB --- 2011-11-22 22:16:46 - CROSS_BUILD_TESTING=YES TB --- 2011-11-22 22:16:46 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-22 22:16:46 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-22 22:16:46 - SRCCONF=/dev/null TB --- 2011-11-22 22:16:46 - TARGET=powerpc TB --- 2011-11-22 22:16:46 - TARGET_ARCH=powerpc64 TB --- 2011-11-22 22:16:46 - TZ=UTC TB --- 2011-11-22 22:16:46 - __MAKE_CONF=/dev/null TB --- 2011-11-22 22:16:46 - cd /src TB --- 2011-11-22 22:16:46 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 22 22:16:47 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:116: error: 'AT_NOTELF' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:116: error: (Each undeclared identifier is reported only once /src/usr.bin/procstat/procstat_auxv.c:116: error: for each function it appears in.) /src/usr.bin/procstat/procstat_auxv.c:120: error: 'AT_UID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:124: error: 'AT_EUID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:128: error: 'AT_GID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:132: error: 'AT_EGID' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 00:08:21 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 00:08:21 - ERROR: failed to build world TB --- 2011-11-23 00:08:21 - 5580.23 user 901.91 system 6725.95 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-11-22 23:20:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-22 23:20:12 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-22 23:20:13 - cleaning the object tree TB --- 2011-11-22 23:20:31 - cvsupping the source tree TB --- 2011-11-22 23:20:31 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-22 23:20:47 - building world TB --- 2011-11-22 23:20:47 - CROSS_BUILD_TESTING=YES TB --- 2011-11-22 23:20:47 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-22 23:20:47 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-22 23:20:47 - SRCCONF=/dev/null TB --- 2011-11-22 23:20:47 - TARGET=sparc64 TB --- 2011-11-22 23:20:47 - TARGET_ARCH=sparc64 TB --- 2011-11-22 23:20:47 - TZ=UTC TB --- 2011-11-22 23:20:47 - __MAKE_CONF=/dev/null TB --- 2011-11-22 23:20:47 - cd /src TB --- 2011-11-22 23:20:47 - /usr/bin/make -B buildworld >>> World build started on Tue Nov 22 23:20:48 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 00:12:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 00:12:29 - ERROR: failed to build world TB --- 2011-11-23 00:12:29 - 2543.18 user 569.66 system 3136.52 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on arm/arm
TB --- 2011-11-23 00:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 00:20:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-23 00:20:00 - cleaning the object tree TB --- 2011-11-23 00:20:30 - cvsupping the source tree TB --- 2011-11-23 00:20:30 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-23 00:20:45 - building world TB --- 2011-11-23 00:20:45 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 00:20:45 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 00:20:45 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 00:20:45 - SRCCONF=/dev/null TB --- 2011-11-23 00:20:45 - TARGET=arm TB --- 2011-11-23 00:20:45 - TARGET_ARCH=arm TB --- 2011-11-23 00:20:45 - TZ=UTC TB --- 2011-11-23 00:20:45 - __MAKE_CONF=/dev/null TB --- 2011-11-23 00:20:45 - cd /src TB --- 2011-11-23 00:20:45 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 00:20:46 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 01:11:26 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 01:11:26 - ERROR: failed to build world TB --- 2011-11-23 01:11:26 - 2183.43 user 665.40 system 3086.01 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ 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=revision&revision=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"
pam problems
Whatever was just changed in the libpam family, it breaks courier-authdaemond: authdaemond: in openpam_load_module(): no pam_unix.so found imb ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on ia64/ia64
TB --- 2011-11-23 01:11:27 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 01:11:27 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-23 01:11:27 - cleaning the object tree TB --- 2011-11-23 01:11:39 - cvsupping the source tree TB --- 2011-11-23 01:11:39 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-23 01:11:52 - building world TB --- 2011-11-23 01:11:52 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 01:11:52 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 01:11:52 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 01:11:52 - SRCCONF=/dev/null TB --- 2011-11-23 01:11:52 - TARGET=ia64 TB --- 2011-11-23 01:11:52 - TARGET_ARCH=ia64 TB --- 2011-11-23 01:11:52 - TZ=UTC TB --- 2011-11-23 01:11:52 - __MAKE_CONF=/dev/null TB --- 2011-11-23 01:11:52 - cd /src TB --- 2011-11-23 01:11:52 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 01:11:53 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 02:28:45 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 02:28:45 - ERROR: failed to build world TB --- 2011-11-23 02:28:45 - 3677.82 user 710.86 system 4637.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2011-11-23 00:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 00:20:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-23 00:20:00 - cleaning the object tree TB --- 2011-11-23 00:20:52 - cvsupping the source tree TB --- 2011-11-23 00:20:52 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-23 00:21:05 - building world TB --- 2011-11-23 00:21:05 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 00:21:05 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 00:21:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 00:21:05 - SRCCONF=/dev/null TB --- 2011-11-23 00:21:05 - TARGET=amd64 TB --- 2011-11-23 00:21:05 - TARGET_ARCH=amd64 TB --- 2011-11-23 00:21:05 - TZ=UTC TB --- 2011-11-23 00:21:05 - __MAKE_CONF=/dev/null TB --- 2011-11-23 00:21:05 - cd /src TB --- 2011-11-23 00:21:05 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 00:21:06 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 23 03:02:06 UTC 2011 TB --- 2011-11-23 03:02:06 - generating LINT kernel config TB --- 2011-11-23 03:02:06 - cd /src/sys/amd64/conf TB --- 2011-11-23 03:02:06 - /usr/bin/make -B LINT TB --- 2011-11-23 03:02:07 - cd /src/sys/amd64/conf TB --- 2011-11-23 03:02:07 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-23 03:02:07 - building LINT-NOINET kernel TB --- 2011-11-23 03:02:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:02:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:02:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 03:02:07 - SRCCONF=/dev/null TB --- 2011-11-23 03:02:07 - TARGET=amd64 TB --- 2011-11-23 03:02:07 - TARGET_ARCH=amd64 TB --- 2011-11-23 03:02:07 - TZ=UTC TB --- 2011-11-23 03:02:07 - __MAKE_CONF=/dev/null TB --- 2011-11-23 03:02:07 - cd /src TB --- 2011-11-23 03:02:07 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 23 03:02:07 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_init': /src/sys/dev/netmap/netmap.c:1626: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c:1634: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_fini': /src/sys/dev/netmap/netmap.c:1677: warning: format '%d' expects type 'int', but argument 2 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c: In function 'netmap_init': /src/sys/dev/netmap/netmap.c:1707: warning: format '%d' expects type 'int', but argument 2 has type 'size_t' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 03:10:37 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 03:10:37 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-23 03:10:37 - 8073.13 user 1541.72 system 10237.60 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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: loader crash / BTX halted on 9.0-RC2 DVD with AMD pseudo-RAID
On Nov 22, 2011, at 10:26 AM, John Baldwin wrote: > On Monday, November 21, 2011 1:45:36 pm John Nielsen wrote: >> This weekend I downloaded the Freebsd 9.0 RC2 amd64 ISO image and burned it > to a DVD. I have a computer that currently runs Windows 7 but I plan to > install FreeBSD on it in the near future so I booted it up from the DVD to > check the hardware/driver status. Much to my dismay, the boot loader crashed > right away (register dump followed by "BTX halted") and the computer > immediately rebooted. I took a video with my phone so I could capture the > crash message, screenshot here: >> >> http://picpaste.com/pics/BTXcrash.1321899682.jpg >> >> I then tried tweaking a few BIOS settings and found that turning off the > built-in pseudo-RAID allowed the DVD to boot normally. I changed the SATA > type > from "RAID" to "AHCI". Fortunately I plan to use the controller in AHCI mode > for the FreeBSD installation so this won't end up being a problem for me, but > I still thought it was worth reporting. > > Hmmm, so this is odd. It died with an Invalid TSS exception on the iret > instruction at the end of the return-from-real-mode trampoline in BTX. > Looking at the dump I noticed that PSL_NT is set in %eflags, so for some > reason the iret was trying to do a nested task return. We shouldn't let > that flag leak out of any real mode code. Try this patch perhaps: Thanks for looking! I put gptboot on a USB stick and tried it with and without the patch. Identical behavior in both cases to booting from the DVD (only faster)--BTX dump and an instant reboot. I didn't do a screen capture yet but will be happy to tomorrow if it will help. JN ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on mips/mips
TB --- 2011-11-23 02:28:45 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 02:28:45 - starting HEAD tinderbox run for mips/mips TB --- 2011-11-23 02:28:45 - cleaning the object tree TB --- 2011-11-23 02:28:54 - cvsupping the source tree TB --- 2011-11-23 02:28:54 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/mips/mips/supfile TB --- 2011-11-23 02:29:07 - building world TB --- 2011-11-23 02:29:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 02:29:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 02:29:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 02:29:07 - SRCCONF=/dev/null TB --- 2011-11-23 02:29:07 - TARGET=mips TB --- 2011-11-23 02:29:07 - TARGET_ARCH=mips TB --- 2011-11-23 02:29:07 - TZ=UTC TB --- 2011-11-23 02:29:07 - __MAKE_CONF=/dev/null TB --- 2011-11-23 02:29:07 - cd /src TB --- 2011-11-23 02:29:07 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 02:29:08 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O -pipe -G0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O -pipe -G0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O -pipe -G0 -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 03:22:15 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 03:22:15 - ERROR: failed to build world TB --- 2011-11-23 03:22:16 - 2321.40 user 631.99 system 3210.18 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-mips-mips.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on sparc64/sparc64
TB --- 2011-11-23 03:22:16 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 03:22:16 - starting HEAD tinderbox run for sparc64/sparc64 TB --- 2011-11-23 03:22:16 - cleaning the object tree TB --- 2011-11-23 03:22:25 - cvsupping the source tree TB --- 2011-11-23 03:22:25 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sparc64/supfile TB --- 2011-11-23 03:22:36 - building world TB --- 2011-11-23 03:22:36 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:22:36 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:22:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 03:22:36 - SRCCONF=/dev/null TB --- 2011-11-23 03:22:36 - TARGET=sparc64 TB --- 2011-11-23 03:22:36 - TARGET_ARCH=sparc64 TB --- 2011-11-23 03:22:36 - TZ=UTC TB --- 2011-11-23 03:22:36 - __MAKE_CONF=/dev/null TB --- 2011-11-23 03:22:36 - cd /src TB --- 2011-11-23 03:22:36 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 03:22:37 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 04:22:55 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 04:22:55 - ERROR: failed to build world TB --- 2011-11-23 04:22:55 - 2717.69 user 630.12 system 3639.59 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sparc64.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on powerpc/powerpc
TB --- 2011-11-23 02:50:13 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 02:50:13 - starting HEAD tinderbox run for powerpc/powerpc TB --- 2011-11-23 02:50:13 - cleaning the object tree TB --- 2011-11-23 02:50:24 - cvsupping the source tree TB --- 2011-11-23 02:50:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc/powerpc/supfile TB --- 2011-11-23 02:50:38 - building world TB --- 2011-11-23 02:50:38 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 02:50:38 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 02:50:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 02:50:38 - SRCCONF=/dev/null TB --- 2011-11-23 02:50:38 - TARGET=powerpc TB --- 2011-11-23 02:50:38 - TARGET_ARCH=powerpc TB --- 2011-11-23 02:50:38 - TZ=UTC TB --- 2011-11-23 02:50:38 - __MAKE_CONF=/dev/null TB --- 2011-11-23 02:50:38 - cd /src TB --- 2011-11-23 02:50:38 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 02:50:38 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:116: error: 'AT_NOTELF' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:116: error: (Each undeclared identifier is reported only once /src/usr.bin/procstat/procstat_auxv.c:116: error: for each function it appears in.) /src/usr.bin/procstat/procstat_auxv.c:120: error: 'AT_UID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:124: error: 'AT_EUID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:128: error: 'AT_GID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:132: error: 'AT_EGID' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 04:43:02 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 04:43:02 - ERROR: failed to build world TB --- 2011-11-23 04:43:02 - 5525.94 user 933.98 system 6768.75 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/i386
TB --- 2011-11-23 00:20:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 00:20:00 - starting HEAD tinderbox run for i386/i386 TB --- 2011-11-23 00:20:00 - cleaning the object tree TB --- 2011-11-23 00:20:53 - cvsupping the source tree TB --- 2011-11-23 00:20:53 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2011-11-23 00:21:07 - building world TB --- 2011-11-23 00:21:07 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 00:21:07 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 00:21:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 00:21:07 - SRCCONF=/dev/null TB --- 2011-11-23 00:21:07 - TARGET=i386 TB --- 2011-11-23 00:21:07 - TARGET_ARCH=i386 TB --- 2011-11-23 00:21:07 - TZ=UTC TB --- 2011-11-23 00:21:07 - __MAKE_CONF=/dev/null TB --- 2011-11-23 00:21:07 - cd /src TB --- 2011-11-23 00:21:07 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 00:21:07 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> World build completed on Wed Nov 23 02:30:39 UTC 2011 TB --- 2011-11-23 02:30:39 - generating LINT kernel config TB --- 2011-11-23 02:30:39 - cd /src/sys/i386/conf TB --- 2011-11-23 02:30:39 - /usr/bin/make -B LINT TB --- 2011-11-23 02:30:40 - cd /src/sys/i386/conf TB --- 2011-11-23 02:30:40 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-23 02:30:40 - building LINT-NOINET kernel TB --- 2011-11-23 02:30:40 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 02:30:40 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 02:30:40 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 02:30:40 - SRCCONF=/dev/null TB --- 2011-11-23 02:30:40 - TARGET=i386 TB --- 2011-11-23 02:30:40 - TARGET_ARCH=i386 TB --- 2011-11-23 02:30:40 - TZ=UTC TB --- 2011-11-23 02:30:40 - __MAKE_CONF=/dev/null TB --- 2011-11-23 02:30:40 - cd /src TB --- 2011-11-23 02:30:40 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 23 02:30:40 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET completed on Wed Nov 23 03:00:47 UTC 2011 TB --- 2011-11-23 03:00:47 - cd /src/sys/i386/conf TB --- 2011-11-23 03:00:47 - /usr/sbin/config -m LINT-NOINET6 TB --- 2011-11-23 03:00:48 - building LINT-NOINET6 kernel TB --- 2011-11-23 03:00:48 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:00:48 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:00:48 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 03:00:48 - SRCCONF=/dev/null TB --- 2011-11-23 03:00:48 - TARGET=i386 TB --- 2011-11-23 03:00:48 - TARGET_ARCH=i386 TB --- 2011-11-23 03:00:48 - TZ=UTC TB --- 2011-11-23 03:00:48 - __MAKE_CONF=/dev/null TB --- 2011-11-23 03:00:48 - cd /src TB --- 2011-11-23 03:00:48 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET6 >>> Kernel build for LINT-NOINET6 started on Wed Nov 23 03:00:48 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOINET6 completed on Wed Nov 23 03:30:59 UTC 2011 TB --- 2011-11-23 03:30:59 - cd /src/sys/i386/conf TB --- 2011-11-23 03:30:59 - /usr/sbin/config -m LINT-NOIP TB --- 2011-11-23 03:31:00 - building LINT-NOIP kernel TB --- 2011-11-23 03:31:00 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:31:00 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:31:00 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 03:31:00 - SRCCONF=/dev/null TB --- 2011-11-23 03:31:00 - TARGET=i386 TB --- 2011-11-23 03:31:00 - TARGET_ARCH=i386 TB --- 2011-11-23 03:31:00 - TZ=UTC TB --- 2011-11-23 03:31:00 - __MAKE_CONF=/dev/null TB --- 2011-11-23 03:31:00 - cd /src TB --- 2011-11-23 03:31:00 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOIP >>> Kernel build for LINT-NOIP started on Wed Nov 23 03:31:00 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything >>> Kernel build for LINT-NOIP completed on Wed Nov 23 03:59:23 UTC 2011 TB --- 2011-11-23 03:59:24 - cd /src/sys/i386/conf TB --- 2011-11-23 03:59:24 - /usr/sbin/config -m LINT-VIMAGE TB --- 2011-11-23 03:59:24 - building LINT-VIMAGE kernel TB --- 2011-11-23 03:59:24 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:59:24 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:59:24 - PATH=/usr/bin:
[head tinderbox] failure on powerpc64/powerpc
TB --- 2011-11-23 03:10:38 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 03:10:38 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2011-11-23 03:10:38 - cleaning the object tree TB --- 2011-11-23 03:10:48 - cvsupping the source tree TB --- 2011-11-23 03:10:48 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2011-11-23 03:11:01 - building world TB --- 2011-11-23 03:11:01 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 03:11:01 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 03:11:01 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 03:11:01 - SRCCONF=/dev/null TB --- 2011-11-23 03:11:01 - TARGET=powerpc TB --- 2011-11-23 03:11:01 - TARGET_ARCH=powerpc64 TB --- 2011-11-23 03:11:01 - TZ=UTC TB --- 2011-11-23 03:11:01 - __MAKE_CONF=/dev/null TB --- 2011-11-23 03:11:01 - cd /src TB --- 2011-11-23 03:11:01 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 03:11:01 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:116: error: 'AT_NOTELF' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:116: error: (Each undeclared identifier is reported only once /src/usr.bin/procstat/procstat_auxv.c:116: error: for each function it appears in.) /src/usr.bin/procstat/procstat_auxv.c:120: error: 'AT_UID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:124: error: 'AT_EUID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:128: error: 'AT_GID' undeclared (first use in this function) /src/usr.bin/procstat/procstat_auxv.c:132: error: 'AT_EGID' undeclared (first use in this function) *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 05:02:10 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 05:02:10 - ERROR: failed to build world TB --- 2011-11-23 05:02:10 - 5562.14 user 910.48 system 6691.98 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on arm/arm
TB --- 2011-11-23 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 05:10:00 - starting HEAD tinderbox run for arm/arm TB --- 2011-11-23 05:10:00 - cleaning the object tree TB --- 2011-11-23 05:10:15 - cvsupping the source tree TB --- 2011-11-23 05:10:15 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/arm/arm/supfile TB --- 2011-11-23 05:10:56 - building world TB --- 2011-11-23 05:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 05:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 05:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 05:10:56 - SRCCONF=/dev/null TB --- 2011-11-23 05:10:56 - TARGET=arm TB --- 2011-11-23 05:10:56 - TARGET_ARCH=arm TB --- 2011-11-23 05:10:56 - TZ=UTC TB --- 2011-11-23 05:10:56 - __MAKE_CONF=/dev/null TB --- 2011-11-23 05:10:56 - cd /src TB --- 2011-11-23 05:10:56 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 05:10:57 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 06:00:11 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 06:00:11 - ERROR: failed to build world TB --- 2011-11-23 06:00:11 - 2152.62 user 652.07 system 3010.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-arm-arm.full ___ 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"
[PATCH] Detect GNU/kFreeBSD in user-visible kernel headers (v2)
Here we go again :-) Out of the kernel headers that are installed in /usr/include/ hierracy, there are some which include support multiple operating systems (usually FreeBSD and other *BSD flavours). This patch adds support to detect GNU/kFreeBSD as well. In all cases, we match the same declarations as FreeBSD does (which is to be expected in kernel headers, since both systems share the same kernel). -- Robert Millan Index: sys/cam/scsi/scsi_low.h === --- sys/cam/scsi/scsi_low.h (revision 227831) +++ sys/cam/scsi/scsi_low.h (working copy) @@ -44,6 +44,8 @@ #ifndef _SCSI_LOW_H_ #define _SCSI_LOW_H_ +#include + /* * Scsi low OSDEP * (All os depend structures should be here!) @@ -53,10 +55,10 @@ #define SCSI_LOW_INTERFACE_XS #endif /* __NetBSD__ */ -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ #define SCSI_LOW_INTERFACE_CAM #define CAM -#endif /* __FreeBSD__ */ +#endif /* __FreeBSD_kernel__ */ / includes ***/ #ifdef __NetBSD__ @@ -64,7 +66,7 @@ #include #endif /* __NetBSD__ */ -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ #include #include #include @@ -75,7 +77,7 @@ #include #include -#endif /* __FreeBSD__ */ +#endif /* __FreeBSD_kernel__ */ / functions macro / #ifdef __NetBSD__ @@ -85,13 +87,13 @@ #define SCSI_LOW_BZERO(pt, size) memset((pt), 0, (size)) #endif /* __NetBSD__ */ -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ #undef MSG_IDENTIFY #define SCSI_LOW_DEBUGGER(dev) kdb_enter(KDB_WHY_CAM, dev) #define SCSI_LOW_DELAY(mu) DELAY((mu)) #define SCSI_LOW_SPLSCSI splcam #define SCSI_LOW_BZERO(pt, size) bzero((pt), (size)) -#endif /* __FreeBSD__ */ +#endif /* __FreeBSD_kernel__ */ / os depend interface structures **/ #ifdef __NetBSD__ @@ -111,7 +113,7 @@ }; #endif /* __NetBSD__ */ -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ typedef struct scsi_sense_data scsi_low_osdep_sense_data_t; struct scsi_low_osdep_interface { @@ -134,7 +136,7 @@ struct scsi_low_osdep_lun_interface { }; -#endif /* __FreeBSD__ */ +#endif /* __FreeBSD_kernel__ */ / os depend interface functions */ struct slccb; Index: sys/cam/scsi/scsi_low_pisa.h === --- sys/cam/scsi/scsi_low_pisa.h (revision 227831) +++ sys/cam/scsi/scsi_low_pisa.h (working copy) @@ -34,14 +34,16 @@ #ifndef _SCSI_LOW_PISA_H_ #define _SCSI_LOW_PISA_H_ +#include + #ifdef __NetBSD__ int scsi_low_activate_pisa(pisa_device_handle_t); int scsi_low_deactivate_pisa(pisa_device_handle_t); int scsi_low_notify_pisa(pisa_device_handle_t, pisa_event_t); #endif /* __NetBSD__ */ -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ int scsi_low_activate_pisa(struct scsi_low_softc *, int); int scsi_low_deactivate_pisa(struct scsi_low_softc *); -#endif /* __FreeBSD__ */ +#endif /* __FreeBSD_kernel__ */ #endif /* !_SCSI_LOW_PISA_H_ */ Index: sys/contrib/altq/altq/altq_var.h === --- sys/contrib/altq/altq/altq_var.h (revision 227831) +++ sys/contrib/altq/altq/altq_var.h (working copy) @@ -201,7 +201,7 @@ #define CALLOUT_STOP(c) untimeout((c)->c_func,(c)->c_arg) #define CALLOUT_INITIALIZER { NULL, NULL } #endif -#if !defined(__FreeBSD__) +#if !defined(__FreeBSD_kernel__) typedef void (timeout_t)(void *); #endif Index: sys/contrib/altq/altq/if_altq.h === --- sys/contrib/altq/altq/if_altq.h (revision 227831) +++ sys/contrib/altq/altq/if_altq.h (working copy) @@ -29,7 +29,9 @@ #ifndef _ALTQ_IF_ALTQ_H_ #define _ALTQ_IF_ALTQ_H_ -#ifdef __FreeBSD__ +#include + +#ifdef __FreeBSD_kernel__ #include /* XXX */ #include /* XXX */ #include /* XXX */ @@ -51,7 +53,7 @@ int ifq_len; int ifq_maxlen; int ifq_drops; -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ struct mtx ifq_mtx; #endif Index: sys/contrib/pf/net/if_pflog.h === --- sys/contrib/pf/net/if_pflog.h (revision 227831) +++ sys/contrib/pf/net/if_pflog.h (working copy) @@ -27,10 +27,12 @@ #ifndef _NET_IF_PFLOG_H_ #define _NET_IF_PFLOG_H_ +#include + #define PFLOGIFS_MAX 16 struct pflog_softc { -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ struct ifnet *sc_ifp; /* the interface pointer */ #else struct ifnet sc_if; /* the interface */ @@ -74,7 +76,7 @@ #define OLD_PFLOG_HDRLEN sizeof(struct old_pfloghdr) #ifdef _KERNEL -#ifdef __FreeBSD__ +#ifdef __FreeBSD_kernel__ struct pf_rule; struct pf_ruleset; struct pfi_kif; @@ -90,7 +92,7 @@ if (pflog_packet_ptr != NULL) \ pflog_packet_ptr(i,a,b,c,d,e,f,g,h);\ } while (0) -#else /* ! __FreeBSD__ */ +#else /* ! __FreeBSD_kernel__ */ #if NPFLOG > 0 #define PFLOG_PACKET(i,x,a,b,c,d,e,f,g,h) pf
[head tinderbox] failure on ia64/ia64
TB --- 2011-11-23 06:00:12 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 06:00:12 - starting HEAD tinderbox run for ia64/ia64 TB --- 2011-11-23 06:00:12 - cleaning the object tree TB --- 2011-11-23 06:00:18 - cvsupping the source tree TB --- 2011-11-23 06:00:18 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/ia64/ia64/supfile TB --- 2011-11-23 06:00:56 - building world TB --- 2011-11-23 06:00:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 06:00:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 06:00:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 06:00:56 - SRCCONF=/dev/null TB --- 2011-11-23 06:00:56 - TARGET=ia64 TB --- 2011-11-23 06:00:56 - TARGET_ARCH=ia64 TB --- 2011-11-23 06:00:56 - TZ=UTC TB --- 2011-11-23 06:00:56 - __MAKE_CONF=/dev/null TB --- 2011-11-23 06:00:56 - cd /src TB --- 2011-11-23 06:00:56 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 06:00:56 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything [...] gzip -cn /src/usr.bin/printf/printf.1 > printf.1.gz ===> usr.bin/procstat (all) cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat.c cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_args.c cc -O2 -pipe -std=gnu99 -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings -Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline -Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign -c /src/usr.bin/procstat/procstat_auxv.c cc1: warnings being treated as errors /src/usr.bin/procstat/procstat_auxv.c: In function 'procstat_auxv': /src/usr.bin/procstat/procstat_auxv.c:75: warning: cast increases required alignment of target type *** Error code 1 Stop in /src/usr.bin/procstat. *** Error code 1 Stop in /src/usr.bin. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 07:17:19 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 07:17:19 - ERROR: failed to build world TB --- 2011-11-23 07:17:19 - 3642.05 user 706.41 system 4627.20 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-ia64-ia64.full ___ 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
23 nov 2011 kl. 02:20 skrev Sean Bruno : > 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=revision&revision=227400 fixed it. > > Sean > Thanks for the heads-up! Hoping for rc2! :-) Palle___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on amd64/amd64
TB --- 2011-11-23 05:10:00 - tinderbox 2.8 running on freebsd-current.sentex.ca TB --- 2011-11-23 05:10:00 - starting HEAD tinderbox run for amd64/amd64 TB --- 2011-11-23 05:10:00 - cleaning the object tree TB --- 2011-11-23 05:10:28 - cvsupping the source tree TB --- 2011-11-23 05:10:28 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/amd64/amd64/supfile TB --- 2011-11-23 05:10:56 - building world TB --- 2011-11-23 05:10:56 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 05:10:56 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 05:10:56 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 05:10:56 - SRCCONF=/dev/null TB --- 2011-11-23 05:10:56 - TARGET=amd64 TB --- 2011-11-23 05:10:56 - TARGET_ARCH=amd64 TB --- 2011-11-23 05:10:56 - TZ=UTC TB --- 2011-11-23 05:10:56 - __MAKE_CONF=/dev/null TB --- 2011-11-23 05:10:56 - cd /src TB --- 2011-11-23 05:10:56 - /usr/bin/make -B buildworld >>> World build started on Wed Nov 23 05:10:57 UTC 2011 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: make dependencies >>> stage 4.4: building everything >>> stage 5.1: building 32 bit shim libraries >>> World build completed on Wed Nov 23 07:49:49 UTC 2011 TB --- 2011-11-23 07:49:49 - generating LINT kernel config TB --- 2011-11-23 07:49:49 - cd /src/sys/amd64/conf TB --- 2011-11-23 07:49:49 - /usr/bin/make -B LINT TB --- 2011-11-23 07:49:49 - cd /src/sys/amd64/conf TB --- 2011-11-23 07:49:49 - /usr/sbin/config -m LINT-NOINET TB --- 2011-11-23 07:49:49 - building LINT-NOINET kernel TB --- 2011-11-23 07:49:49 - CROSS_BUILD_TESTING=YES TB --- 2011-11-23 07:49:49 - MAKEOBJDIRPREFIX=/obj TB --- 2011-11-23 07:49:49 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2011-11-23 07:49:49 - SRCCONF=/dev/null TB --- 2011-11-23 07:49:49 - TARGET=amd64 TB --- 2011-11-23 07:49:49 - TARGET_ARCH=amd64 TB --- 2011-11-23 07:49:49 - TZ=UTC TB --- 2011-11-23 07:49:49 - __MAKE_CONF=/dev/null TB --- 2011-11-23 07:49:49 - cd /src TB --- 2011-11-23 07:49:49 - /usr/bin/make -B buildkernel KERNCONF=LINT-NOINET >>> Kernel build for LINT-NOINET started on Wed Nov 23 07:49:49 UTC 2011 >>> stage 1: configuring the kernel >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: making dependencies >>> stage 3.2: building everything [...] cc1: warnings being treated as errors /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_init': /src/sys/dev/netmap/netmap.c:1626: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c:1634: warning: format '%d' expects type 'int', but argument 7 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c: In function 'netmap_memory_fini': /src/sys/dev/netmap/netmap.c:1677: warning: format '%d' expects type 'int', but argument 2 has type 'size_t' [-Wformat] /src/sys/dev/netmap/netmap.c: In function 'netmap_init': /src/sys/dev/netmap/netmap.c:1707: warning: format '%d' expects type 'int', but argument 2 has type 'size_t' [-Wformat] *** Error code 1 Stop in /obj/amd64.amd64/src/sys/LINT-NOINET. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2011-11-23 07:57:52 - WARNING: /usr/bin/make returned exit code 1 TB --- 2011-11-23 07:57:52 - ERROR: failed to build LINT-NOINET kernel TB --- 2011-11-23 07:57:52 - 7973.36 user 1507.55 system 10071.61 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-amd64-amd64.full ___ 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"