Update on ports on 10.0
Since the release has been pushed back some more since the last mail, we do have some time to test a possible fix for the issues we're seeing with libtool on FreeBSD 10.0. However, fixing libtool is only part of the problem as hundreds, if not thousands, of ports roll their own detection and need to be fixed individually. We are currently running a fixed libtool (ports/161404) to assess how many ports are fixed by this patch and how many need to be patches manually before deciding how to move forward. Other options include the big find/grep/awk solution that has been posted several times and fiddling with uname to go to FreeBSD 9.99 for a while, while ports can be fixed. Hopefully, we can move forward in a day or two, but needless to say this needs a lot of testing both on 10.0 and earlier releases so we are sure we don't break backwards compatability, especially on 9.0 that is soon to be released. For those that cannot wait a few days, several patches have been proposed on the lists, of which dougb's seems most complete, so I recommend applying one of those locally. Please note that these are not tested widely and may break when the final fix is committed. To conclude with some fun facts, only 232 ports break on HEAD currently. Unfortunately, some of these are pretty high profile and prevent almost 19.000 other ports from building, leaving only slighty more than 3000 ports to build successfully. Erwin -- Erwin Lansing http://droso.org Prediction is very difficult especially about the futureer...@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: subversion-freebsd dependencies
2011/10/6 Lev Serebryakov l...@freebsd.org: Huh? It is something new for me (maintainer). What is recommended method? I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can just drop sqlite.c from sqlite-source over to Subversion's sqlite-amalgamation/ directory. http://svn.apache.org/repos/asf/subversion/trunk/INSTALL -- chs, ___ 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-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, lin
On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while compiling this error: Abort trap (core dumped) Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. This just happened after the last update and reboot (did make world). Is this a bug? If yes, should I do a PR or is it already known? If not a bug, what is it? 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
FreeBSD 9.0/10.0 amd64 (CLANG): mysterious client crahses when typing left/right arrow key
Since yesterday after a make world on both FreeBSD versions I realize a strange behaviour in several GTK clients (gq for instance, freshly installed yesterday) and Firefox and Thunderbird (they have not been recompiled now for days). This behaviour occured earlier this year on FreeBSD 9.0-CURRENT, around July. I tried to install FreeBSD Current compiled with CLANG on a Core-i5 driven notebook with option --mtune=native, --mtune=i7 or even avoid using --mtune= and then it occured that the whole system was crap, since typing of TAB key immediately exited the shell or typing the arrow keys resulted in the same. This happened NOT when system got compiled with --mtune=core2 on that Core-i5 driven Notebook (Dell Latitude E6510)! I didn't test this behaviour on that notebook yet, but whill this night. The notebook have had a GENERIC kernel that time when the problem occured, now I use on all boxes custom kernel and these lines seem to be specificially for the terminal emulation: # Console options options MAXCONS=8 # maximum No. of consoles options SC_ALT_MOUSE_IMAGE # simplified mouse cursor in text mode options SC_DFLT_FONT# compile font in makeoptions SC_DFLT_FONT=cp850 options SC_DISABLE_KDBKEY # disable `debug' key options SC_DISABLE_REBOOT # disable reboot key sequence options SC_HISTORY_SIZE=512 # number of history buffer lines #optionsSC_MOUSE_CHAR=0x3 # char code for text mode mouse cursor options SC_PIXEL_MODE # add support for the raster text mode options SC_NORM_ATTR=(FG_GREEN|BG_BLACK) options SC_NORM_REV_ATTR=(FG_YELLOW|BG_GREEN) options SC_KERNEL_CONS_ATTR=(FG_RED|BG_BLACK) options SC_KERNEL_CONS_REV_ATTR=(FG_BLACK|BG_RED) #optionsSC_CUT_SPACES2TABS # convert leading spaces into tabs #optionsSC_CUT_SEPCHARS=\x09\ # set of characters that delimit words # (default is single space - \x20\) #optionsSC_TWOBUTTON_MOUSE # Enable experimental features of the syscons terminal emulator (teken). options TEKEN_UTF8 # UTF-8 output handling #optionsTEKEN_CONS25# cons25-style terminal emulation # Enable VESA #optionsX86BIOS #optionsVESA Any idea? 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
Re: Update on ports on 10.0
On Oct 11, 2011 5:07 PM, Erwin Lansing er...@freebsd.org wrote: Since the release has been pushed back some more since the last mail, we do have some time to test a possible fix for the issues we're seeing with libtool on FreeBSD 10.0. [snip] to move forward. Other options include the big find/grep/awk solution that has been posted several times and fiddling with uname to go to FreeBSD 9.99 for a while, while ports can be fixed. I would vote for a prominent message in the places people who run -CURRENT are meant to pay attention to (this mailing list and UPDATING and the ports equivalents). The message should point people to a web site (wiki?) with the latest news on how to report and provide patches for fixes with guidance on typical solutions. After all, this is -CURRENT and it's users are meant to be contributing fixes and are not expected to require their hands to be held. This I believe would be a good method to leverage the community so as to distribute the fixup problem. In particular the hack of 9.99 is likely to cause more problems and should be avoided. My 2¢ ___ 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: System headers with clang?
On 2011-10-09 19:32, Larry Rosenman wrote:
I had gotten a PR about sysutils/lsof not compiling with clang. I had
Vic Abell check it out, and the problem is NOT with lsof per se, but
with the system headers.
Is there a project afoot to update the system headers to make them clang
compilable?
The problem isn't that clang can't compile the system headers, but
normally these don't get included from userspace. And they certainly
won't work as expected when you define _KERNEL in userspace, as the lsof
port foolishly does. It probably can't be avoided in such a tool, though.
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:190:
In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36:
/usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function
'KASSERT' is invalid in C99
[-Wimplicit-function-declaration]
KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp));
^
/usr/src/sys/sys/buf.h:388:33: warning: expression result unused
[-Wunused-value]
KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp));
^
These are more or less harmless warnings, as long as nobody calls a
function that uses KASSERT. They occur because lsof's headers don't
include sys/param.h and sys/systm.h before sys/ufs/ufs/ufsmount.h.
...
In file included from ckkv.c:43:
In file included from ./../lsof.h:195:
In file included from ./../dlsof.h:432:
In file included from /usr/include/string.h:45:
/usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs'
int ffs(int) __pure2;
^
/usr/include/machine/cpufunc.h:140:24: note: expanded from:
#defineffs(x) __builtin_ffs(x)
^
/usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int
(unsigned int)'
This is because the amd64 system headers redefine ffs to __builtin_ffs,
after which it conflicts with the declaration in /usr/include/strings.h.
On i386, ffs is not redefined, but I have no idea why.
In any case, gcc does not complain about the incompatible redeclaration,
which may be a bug, or just stupid luck, depending on your POV. :)
I've attached a fix for the lsof port, which also makes it build on
10.0-CURRENT (this was easy to fix here, as lsof uses its own
hand-rolled configuration script). Let me know if it works for you.
Index: sysutils/lsof/files/patch-Configure
===
RCS file: sysutils/lsof/files/patch-Configure
diff -N sysutils/lsof/files/patch-Configure
--- /dev/null 1 Jan 1970 00:00:00 -
+++ sysutils/lsof/files/patch-Configure 11 Oct 2011 11:44:44 -
@@ -0,0 +1,72 @@
+--- Configure.orig 2011-08-15 18:15:56.0 +0200
Configure 2011-10-11 13:30:37.0 +0200
+@@ -1428,7 +1428,7 @@
+ 3.5*)
+ LSOF_VERS=3050
+ ;;
+- 3*)
++ 3.*)
+ LSOF_VERS=3050
+ echo !!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR
+ echo !!!WARNING!!! Configuring for FreeBSD 3.5
+@@ -1481,7 +1481,7 @@
+ LSOF_TSTBIGF=
+ LSOF_VERS=4110
+ ;;
+- 4*)
++ 4.*)
+ LSOF_VERS=4100
+ echo !!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR
+ echo !!!WARNING!!! Configuring for FreeBSD 4.10
+@@ -1510,7 +1510,7 @@
+ LSOF_TSTBIGF=
+ LSOF_VERS=5050
+ ;;
+- 5*)
++ 5.*)
+ LSOF_VERS=5050
+ echo !!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR
+ echo !!!WARNING!!! Configuring for FreeBSD 5.5
+@@ -1535,7 +1535,7 @@
+ LSOF_TSTBIGF=
+ LSOF_VERS=6040
+ ;;
+- 6*)
++ 6.*)
+ LSOF_VERS=6000
+ echo !!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR
+ echo !!!WARNING!!! Configuring for FreeBSD 6.0
+@@ -1560,7 +1560,7 @@
+ LSOF_TSTBIGF=
+ LSOF_VERS=7040
+ ;;
+- 7*)
++ 7.*)
+ LSOF_VERS=7000
+ echo !!!WARNING!!! Unsupported FreeBSD version: $LSOF_VSTR
+ echo !!!WARNING!!! Configuring for FreeBSD 7.0
+@@ -1577,10 +1577,14 @@
+ LSOF_TSTBIGF=
+ LSOF_VERS=8020
+ ;;
+- 9*)
++ 9.*)
+ LSOF_TSTBIGF=
+ LSOF_VERS=9000
+ ;;
++ 10.*)
++ LSOF_TSTBIGF=
++ LSOF_VERS=1
++ ;;
+ *)
+ echo Unknown FreeBSD release: `uname -r`
+ echo Assuming FreeBSD 2.x
+@@ -1684,7 +1688,7 @@
+ LSOF_CFGF=$LSOF_CFGF -DHASVMLOCKH
+ fi # }
+ ;;
+-
4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000)
++
4000|4010|4020|4030|4040|4050|4060|4070|4080|4090|4100|4110|5000|5010|5020|5030|5040|5050|6000|6010|6020|6030|6040|7000|7010|7020|7030|7040|8000|8010|8020|9000|1)
+ if test -r ${LSOF_INCLUDE}/nfs/rpcv2.h # {
+ then
+
Re: FreeBSD-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c,
On 2011-10-11 11:44, O. Hartmann wrote: On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while compiling this error: Abort trap (core dumped) Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. This just happened after the last update and reboot (did make world). Is this a bug? If yes, should I do a PR or is it already known? If not a bug, what is it? Looks like a problem in GNU sort, caused by something unknown. Can you figure out what input it asserts on? Which specific ports cause it? ___ 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: Strange ZFS filesystem corruption
On Oct 4, 2011, at 12:09 PM, Olivier Smedts wrote: 2011/10/3 Paul Mather p...@gromit.dlib.vt.edu: I know ZFS does not have a fsck utility (because it doesn't need one:), but does anyone know of any way of fixing this corruption short of destroying the pool, creating a new one, and restoring from backup? Is there some way of exporting and re-importing the pool that has the side-effect of doing some kind of fsck-like repairing of subtle corruption like this? But there is the ZFS debugger, zdb ! I can't really help you with that because I never had a corrupted zpool, but if you search on the lists for up to a year or so, you'll find some useful commands to inspect and destroy corrupted objects. Usage: zdb [-CumdibcsDvhL] poolname [object...] zdb [-div] dataset [object...] zdb -m [-L] poolname [vdev [metaslab...]] zdb -R poolname vdev:offset:size[:flags] zdb -S poolname zdb -l [-u] device zdb -C Dataset name must include at least one separator character '/' or '@' If dataset name is specified, only that dataset is dumped If object numbers are specified, only those objects are dumped Options to control amount of output: -u uberblock -d dataset(s) -i intent logs -C config (or cachefile if alone) -h pool history -b block statistics -m metaslabs -c checksum all metadata (twice for all data) blocks -s report stats on zdb's I/O -D dedup statistics -S simulate dedup to measure effect -v verbose (applies to all others) -l dump label contents -L disable leak tracking (do not load spacemaps) -R read and display block from a device Below options are intended for use with other options (except -l): -A ignore assertions (-A), enable panic recovery (-AA) or both (-AAA) -F attempt automatic rewind within safe range of transaction groups -U cachefile_path -- use alternate cachefile -X attempt extreme rewind (does not work with dataset) -e pool is exported/destroyed/has altroot/not in a cachefile -p path -- use one or more with -e to specify path to vdev dir -P print numbers parsable -t txg -- highest txg to use when searching for uberblocks Specify an option more than once (e.g. -bb) to make only that option verbose Default is to dump everything non-verbosely I tried your suggestion and ran the command zdb -ccv backups to try and check the consistency of the troublesome backups pool. This is what I ended up with: = Traversing all blocks to verify checksums and verify nothing leaked ... [[...]] leaked space: vdev 0, offset 0x900b5557600, size 82944 leaked space: vdev 0, offset 0x900b556e400, size 23040 leaked space: vdev 0, offset 0x900b5553a00, size 9216 leaked space: vdev 0, offset 0x900b5540800, size 23040 leaked space: vdev 0, offset 0x900b550ea00, size 16896 leaked space: vdev 0, offset 0x900b54e2c00, size 9216 leaked space: vdev 0, offset 0x900b50f5600, size 6144 leaked space: vdev 0, offset 0x900b558dc00, size 70656 leaked space: vdev 0, offset 0x900b5580400, size 44544 leaked space: vdev 0, offset 0x900b55bd000, size 82944 leaked space: vdev 0, offset 0x900b55d6200, size 15360 leaked space: vdev 0, offset 0x900b55dd400, size 33792 leaked space: vdev 0, offset 0x900b55d2c00, size 6144 leaked space: vdev 0, offset 0x900b55a0800, size 95232 leaked space: vdev 0, offset 0x900b55f5400, size 6144 leaked space: vdev 0, offset 0x900b5716c00, size 6144 leaked space: vdev 0, offset 0x900b56e8400, size 6144 leaked space: vdev 0, offset 0x900b573b800, size 6144 leaked space: vdev 0, offset 0x900b5748a00, size 10752 leaked space: vdev 0, offset 0x900b58b5e00, size 3072 leaked space: vdev 0, offset 0x900b589de00, size 6144 leaked space: vdev 0, offset 0x900b575fe00, size 7680 leaked space: vdev 0, offset 0x900b5734600, size 15360 leaked space: vdev 0, offset 0x900b55e8200, size 43008 leaked space: vdev 0, offset 0x900b58ca200, size 27648 leaked space: vdev 0, offset 0x900b591d600, size 3072 leaked space: vdev 0, offset 0x900b591fa00, size 12288 leaked space: vdev 0, offset 0x900b5904a00, size 6144 leaked space: vdev 0, offset 0x900b594f400, size 53760 leaked space: vdev 0, offset 0x900b5939200, size 3072 leaked space: vdev 0, offset 0x900b5960800, size 4608 leaked space: vdev 0, offset 0x900b5966e00, size 3072 leaked space: vdev 0, offset 0x900b5963200, size 9216 leaked space: vdev 0, offset 0x900b595de00, size 4608 leaked space: vdev 0, offset 0x900b5928400, size 3072 leaked space: vdev 0, offset 0x900c9a93200, size 4608 leaked space: vdev 0, offset 0x900c9a8d800, size 21504 leaked space: vdev 0, offset 0x900c9afa400, size 3072 leaked space: vdev 0, offset 0x900c9af4a00, size 21504 leaked space: vdev 0, offset 0x900b5977000, size 9216 leaked space: vdev 0, offset 0x900b58b7000, size 75264 leaked space: vdev 0, offset 0x900b5575600, size 38400
Re: gptzfsboot error using HP Smart Array P410i Controller
Has this issue been resolved somehow? Sane method to build gptzfsboot that will run on HP's P410i? Daniel ___ 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: System headers with clang?
On Tue, 11 Oct 2011, Dimitry Andric wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. ... In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:190: In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function 'KASSERT' is invalid in C99 [-Wimplicit-function-declaration] KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp)); ^ /usr/src/sys/sys/buf.h:388:33: warning: expression result unused [-Wunused-value] KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp)); ^ These are more or less harmless warnings, as long as nobody calls a function that uses KASSERT. They occur because lsof's headers don't include sys/param.h and sys/systm.h before sys/ufs/ufs/ufsmount.h. ... In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:432: In file included from /usr/include/string.h:45: /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' int ffs(int) __pure2; ^ /usr/include/machine/cpufunc.h:140:24: note: expanded from: #defineffs(x) __builtin_ffs(x) ^ /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' This is because the amd64 system headers redefine ffs to __builtin_ffs, after which it conflicts with the declaration in /usr/include/strings.h. On i386, ffs is not redefined, but I have no idea why. In any case, gcc does not complain about the incompatible redeclaration, which may be a bug, or just stupid luck, depending on your POV. :) I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. I will NOT accept the change. -- 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 ___ 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: System headers with clang?
On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. ___ 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: System headers with clang?
On 10/11/2011 8:51 AM, Dimitry Andric wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. -- 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 ___ 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: subversion-freebsd dependencies
On Tue, 11 Oct 2011, Christer Solskogen wrote: 2011/10/6 Lev Serebryakov l...@freebsd.org: Huh? It is something new for me (maintainer). What is recommended method? I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can just drop sqlite.c from sqlite-source over to Subversion's sqlite-amalgamation/ directory. http://svn.apache.org/repos/asf/subversion/trunk/INSTALL Talk to bapt@; he had a PR out which used the amalgamation sources (I couldn't seem to find it yesterday when I looked through the PR database). -Garrett___ 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: System headers with clang?
On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman l...@lerctr.org wrote: On 10/11/2011 8:51 AM, Dimitry Andric wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. Are asking that clang become bug compatible with gcc or that gcc be fixed to present the same errors as clang does? As a casual observer I really don't expect either to happen soon. (I suspect gcc being fixed SLIGHTLY more likely.) By it's very nature lsof does a lot of the sort of kernel interaction that is normally considered to be unacceptable and requires lots of kludges and hacks to do them. I am simply baffled as to why this issue is so different other then that it is dependent on the compiler used and not the differences between kernels and kernel interfaces. On the other hand, I have not done real kernel programming in years...not since I was writing kernel code in assembly for VMS about 20 years ago, so maybe I am missing some subtleties about this. -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.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: System headers with clang?
On Tue, 11 Oct 2011, Kevin Oberman wrote: On Tue, Oct 11, 2011 at 6:59 AM, Larry Rosenman l...@lerctr.org wrote: On 10/11/2011 8:51 AM, Dimitry Andric wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) In any case, isn't lsof's dlsof.h header full of special cases already? What does it matter to add another one? Besides, even if you fix it in the system headers now, at compile time you cannot be sure if the user has the correct version of them installed anyway, so you would still have to work around the problem. We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. Period. Are asking that clang become bug compatible with gcc or that gcc be fixed to present the same errors as clang does? As a casual observer I really don't expect either to happen soon. (I suspect gcc being fixed SLIGHTLY more likely.) No, just asking that the same headers not generate ERRORS where gcc doesn't Extra Warnings are fine. the big one here is the _builtin_ffs() one about signed vs unsigned. By it's very nature lsof does a lot of the sort of kernel interaction that is normally considered to be unacceptable and requires lots of kludges and hacks to do them. I am simply baffled as to why this issue is so different other then that it is dependent on the compiler used and not the differences between kernels and kernel interfaces. It's not. It's just that this seems(!) to be a trivial issue to fix for the folks adding/wanting clang to process all ports. On the other hand, I have not done real kernel programming in years...not since I was writing kernel code in assembly for VMS about 20 years ago, so maybe I am missing some subtleties about this. -- 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 ___ 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
MPSAFE tty and lastcomm output
Hi, Does anyone see this on -CURRENT (and stable/9)? It doesn't look so smart output to me. I was aware of this issue first back in Aug 2009. == $ tty; lastcomm tty|head -1 /dev/pts/12 tty - user pts/120.002 secs Tue Oct 11 20:41 == OK, As this was run on pts/12, nothing is wrong. == $ script /dev/null tty; lastcomm tty|head -1; lastcomm tty|head -1 Script started, output file is /dev/null /dev/pts/13 Script done, output file is /dev/null tty - user pts/130.001 secs Tue Oct 11 20:46 tty - user #C:0x8b 0.001 secs Tue Oct 11 20:46 == Please look at the second entry of lastcomm. These two entries should describe the identical tty(1) process, and a tty field in the second entry does not look good. It looks stored accounting information is correct, but lastcomm failed to represent device name gently after it has been destroyed. Funnier case: == $ jot 1000|while read n; do script /dev/null tty /dev/tty done /dev/null 21 ; wait; lastcomm tty|head == And you'll see variety of output. Some devices are still alive and others has been destroyed. Without head(1) you'll see a swarm of them, of course. (After this one-liner, my tty always goes mad and have to reset(1) to be back sane. This is another issue though.) -- 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: FreeBSD-9.0-BETA3/amd64 (CLANG): Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c,
Hi! There is an open pr on this bug: http://www.freebsd.org/cgi/query-pr.cgi?pr=gnu/93629 2011/10/11 Dimitry Andric d...@freebsd.org: On 2011-10-11 11:44, O. Hartmann wrote: On my lab's server, a FreeBSD 9 box (9.0-BETA3 FreeBSD 9.0-BETA3 #40 r226245: Tue Oct 11 10:01:29 CEST 2011), I receive for some ports while compiling this error: Abort trap (core dumped) Assertion failed: (mblength != (size_t)-1 mblength != (size_t)-2), function inittables_mb, file /usr/src/gnu/usr.bin/sort/../../../contrib/gnu-sort/src/sort.c, line 706. This just happened after the last update and reboot (did make world). Is this a bug? If yes, should I do a PR or is it already known? If not a bug, what is it? Looks like a problem in GNU sort, caused by something unknown. Can you figure out what input it asserts on? Which specific ports cause it? ___ freebsd-po...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-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: System headers with clang?
I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. To echo a word someone else just used, I'm baffled as to why you would hold such a position. Regards, -- -Chuck ___ 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: MPSAFE tty and lastcomm output
Hi name, * poyop...@puripuri.plala.or.jp poyop...@puripuri.plala.or.jp, 20111011 14:20: It looks stored accounting information is correct, but lastcomm failed to represent device name gently after it has been destroyed. Yes, exactly. Our struct acct uses a dev_t to store the controlling TTY. This is obviously completely broken on 8+, because we garbage collect pseudo-terminals. Still, one could argue it has always been broken, because even before the new TTY layer it would break when unplugging USB-to-serial converters or performing a reboot. I think the only way to fix this, is by updating the acct structure to write a string representation of the device name. Best regards, -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpqyFabywpmx.pgp Description: PGP signature
Re: System headers with clang?
On Oct 12, 2011 3:25 AM, Larry Rosenman l...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? ___ 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: System headers with clang?
On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. To echo a word someone else just used, I'm baffled as to why you would hold such a position. Regards, -- -Chuck ___ 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: System headers with clang?
On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, Larry Rosenman l...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. -- 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 ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud ___ 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: subversion-freebsd dependencies
Hello, Christer. You wrote 11 октября 2011 г., 11:52:00: I'm not sure how Subversion 1.6.x is about this, but in 1.7 you can just drop sqlite.c from sqlite-source over to Subversion's sqlite-amalgamation/ directory. http://svn.apache.org/repos/asf/subversion/trunk/INSTALL I don't want to use this way, as it will create hidden dependency. What if vulnerability is found tomorrow for sqlite? It is not a solution to have some sqlite.c taken from arbitrary source. It is better to fix sqlite3 port. -- // Black Lion AKA Lev Serebryakov l...@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: System headers with clang?
On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andricd...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. And it **NEEDS** to know what the structures are. That is unless someone(tm) writes the Kernel interfaces to get the info. -- 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 ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) KASSERT() (from `sys/systm.h') is kernel only, any userland code seeing it is not using the header properly. I'd be a strong proponent of: #ifdef _KERNEL #error You are NOT meant to define _KERNEL in userland application #endif So this has nothing to do about smartness, but correctness. - Arnaud ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenman l...@lerctr.org wrote: On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andricd...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. And it **NEEDS** to know what the structures are. No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. That is unless someone(tm) writes the Kernel interfaces to get the info. Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud ___ 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: System headers with clang?
On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenmanl...@lerctr.org wrote: On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andricd...@freebsd.orgwrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. And it **NEEDS** to know what the structures are. No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. Therein lies the rub. In order to do it's job, it DOES need to grovel around in kernel only structures. That is unless someone(tm) writes the Kernel interfaces to get the info. Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud This is not going to fix things until/unless someone(tm) takes the bull by the horns, and writes a userland-kernel interface to get ALL the data that lsof currently gathers from groveling around in /dev/kmem. I don't have the skills nor time to do that. We can go around and around on this topic, but until/unless either the clang headers/built-ins are changed to match the system/kernel headers, or someone(tm) writes the interfaces, clang will NOT be supported to compile sysutils/lsof. -- 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 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
9.0-BETA3 - network scripts problem
I install 9.0-BETA3 i386, set next rc.conf configurations: mail# grep -E hostname|ifconfig /etc/rc.conf ifconfig_em0=inet 91.227.17.15 netmask 255.255.255.0 hostname=mail.AeroStarContract.ru mail# after reboot with plugged LAN cable, I have this strange network configuration: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a4 inet 91.227.16.17 netmask 0xff00 broadcast 91.227.16.17 media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a5 inet 91.227.16.17 netmask 0xff00 broadcast 91.227.16.17 media: Ethernet autoselect status: no carrier ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536 if I unplug network cable and reboot - network configurations is correct: em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a4 inet 91.227.17.15 netmask 0xff00 broadcast 91.227.17.255 media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a5 media: Ethernet autoselect status: no carrier ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536 lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 91.227.16.17 - is IP for DNS A record for mail.AeroStarContract.ru if I run /etc/rc.d/netif start with plugged cable - network configurations reset to first listing. If cable unplugged - to second. if I change hostname to non-existent: mail# grep -E hostname|ifconfig /etc/rc.conf ifconfig_em0=inet 91.227.17.15 netmask 255.255.255.0 hostname=mail.AeroStarContract-bad.ru mail# reboot with/without LAN cable get good network configurations. change A DNS record for mail.AeroStarContract.ru from 91.227.16.17 to 91.227.16.27 get this configurations, with plugged cable: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a4 inet 91.227.16.27 netmask 0xff00 broadcast 91.227.16.27 media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a5 inet 91.227.16.27 netmask 0xff00 broadcast 91.227.16.27 media: Ethernet autoselect status: no carrier ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536 with unplugged - all correct. setting A record to 91.227.17.15 (as in rc.conf) get this, with plugged cable: lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST metric 0 mtu 16384 options=3RXCSUM,TXCSUM inet 127.0.0.1 netmask 0xff00 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a4 inet 91.227.17.15 netmask 0xff00 broadcast 91.227.17.15 media: Ethernet autoselect (1000baseT full-duplex) status: active em1: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0 mtu 1500 options=209bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,WOL_MAGIC ether 00:30:48:71:11:a5 inet 91.227.17.15 netmask 0xff00 broadcast 91.227.17.15 media: Ethernet autoselect status: no carrier ipfw0: flags=8801UP,SIMPLEX,MULTICAST metric 0 mtu 65536 with unplugged - all correct. = DNS zone AeroStarContract.ru use our DNS servers, used in resolv.conf: mail# more /etc/resolv.conf nameserver 91.227.16.10 nameserver 91.227.17.11 mail# I think, it try find hostname in DNS (DNS server in some network with server) and use finded IP to set all interfaces. It's serious mistake, because I find it when server first booting and set to interface IP used in another server =)) All names, IP addresses and another information - is real. ___ freebsd-current@freebsd.org mailing list
Re: System headers with clang?
On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman l...@lerctr.org wrote: On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, Larry Rosenman l...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Thanks! -Garrett ___ 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: System headers with clang?
2011/10/11 Garrett Cooper yaneg...@gmail.com: On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman l...@lerctr.org wrote: On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, Larry Rosenman l...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. René ___ 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: System headers with clang?
On Tue, Oct 11, 2011 at 11:40 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Oct 11, 2011 at 9:51 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-10-11 15:31, Larry Rosenman wrote: On Tue, 11 Oct 2011, Dimitry Andric wrote: ... I've attached a fix for the lsof port, which also makes it build on 10.0-CURRENT (this was easy to fix here, as lsof uses its own hand-rolled configuration script). Let me know if it works for you. Unless the headers are fixed, Vic Abell (lsof Author) will NOT support it. We need to get clang/system headers to allow warning free compilation just like GCC does. The system headers compile without warning, if you use them as intended (e.g. from the kernel), which lsof obviously doesn't do. There is no easy workaround here, except by modifying lsof. For example, the warning about KASSERT is because lsof's headers don't include the required headers for this macro. And gcc is apparently not smart enough to generate warnings for this. :) KASSERT() (from `sys/systm.h') is kernel only, any userland code seeing it is not using the header properly. I'd be a strong proponent of: #ifdef _KERNEL #error You are NOT meant to define _KERNEL in userland application #endif So this has nothing to do about smartness, but correctness. net-snmp suffers from this as well because it pokes around some kernel structures and data types to gather statistics related to IPv6, routing, etc in order to fulfill MIB-II compliance. Part of the bits are present, but not all of them, and I would really like for the need to muck around in _KERNEL to go away... Similarly, we have several utilities in base that muck around in _KERNEL that really shouldn't IMHO. Thanks, -Garrett ___ 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: System headers with clang?
On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. Yes, but instead Linux encourages mucking around with /proc and /sys, which have varying levels of formatting and provided output. The data needs to be exported properly via sysctl. If it's not done that way to userland, then the API/KPI is flawed and needs to be revised. Thanks, -Garrett ___ 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 for ports on 10-current
Doug Barton do...@freebsd.org writes:
http://dougbarton.us/bam.patch
[...]
+.if ${OSVERSION} = 100 !defined(NO_AUTOTOOLS_FIX)
Being not limited to GNU_CONFIGURE, is it a feature?
Also, there are a few ports that either set WRKSRC instead of
BUILD_WRKSRC or extract several distfiles. Why not use WRKDIR then?
# lang/python27, it does not use devel/libffi (ports/146823)
WRKSRC/../Modules/_ctypes/libffi/configure:freebsd1*)
WRKSRC/../Modules/_ctypes/libffi/configure:freebsd1*)
___
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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:21 PM, René Ladan r...@freebsd.org wrote: 2011/10/11 Garrett Cooper yaneg...@gmail.com: On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenman l...@lerctr.org wrote: On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, Larry Rosenman l...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swiger cswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) - Arnaud ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:04 PM, Larry Rosenman l...@lerctr.org wrote: On 10/11/2011 1:52 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 2:39 PM, Larry Rosenmanl...@lerctr.org wrote: On 10/11/2011 1:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andricd...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. - Arnaud Then lsof would NOT be compilable / usable at all, as it delves into /dev/kmem to get information. AFAIK, Linux is capable of supporting lsof in a backward compatible manner, without exposing its internal guts. FWIW, KVM is a bad kernel/userland interface, as it does not guarantee backward compatibility. And it **NEEDS** to know what the structures are. No, not kernel-only structure. Now, if these structure are not meant to be kernel only, move them out of _KERNEL area, but beware of backward compatibility issue in the future. Therein lies the rub. In order to do it's job, it DOES need to grovel around in kernel only structures. That is unless someone(tm) writes the Kernel interfaces to get the info. Yes, this is the core of the problem and a classical chicken/eggs problem solves the very wrongest way. At some point, I thought to modify the build system to pass kernel's headers through unifdef(1), but I quickly forgot about that: % git grep 'define _KERNEL' * | grep -v '^sys' | wc -l 27 - Arnaud This is not going to fix things until/unless someone(tm) takes the bull by the horns, and writes a userland-kernel interface to get ALL the data that lsof currently gathers from groveling around in /dev/kmem. I don't have the skills nor time to do that. What are those interfaces exactly ? How is it done in Linux ? Thanks, - Arnaud ___ 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: System headers with clang?
On 10/11/11 12:36 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 3:21 PM, René Ladanr...@freebsd.org wrote: 2011/10/11 Garrett Cooperyaneg...@gmail.com: On Tue, Oct 11, 2011 at 10:55 AM, Larry Rosenmanl...@lerctr.org wrote: On Wed, 12 Oct 2011, Matt Thyer wrote: On Oct 12, 2011 3:25 AM, Larry Rosenmanl...@lerctr.org wrote: I didn't say bug for bug, just not generate stupid errors like the ffs one. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity. Chuck Swigercswi...@mac.com wrote: On Oct 11, 2011, at 6:59 AM, Larry Rosenman wrote: We will NOT support clang as the compiler for lsof unless the system headers work the same way as gcc's do. That apparently means you won't support clang then, because it's not intended to be (or ever going to be) fully bug-for-bug compatible with GCC. In this case, at least, clang is reporting legitimate issues which should be fixed, even if folks continue to build lsof with GCC from now until the end of days. The elegant solution would be to avoid this problem altogether by re-implementation of lsof using interfaces into the kernel that provide the required information. bsdof anyone? lsof is PORTABLE and available on LOTS of platforms. We have fstat, but lsof can be used between differing OS's. We've also asked for Kernel interfaces before, but no one volunteered to make the KPI for them. I'm sure if someone(tm) (not me, insufficient knowledge) was to make interfaces for ALL that lsof needs, Vic would implement it as it would make his life easier. It would be nice in general if there were sysctls for accessing this data as even utilities in base have libkvm magic sprinkled around with pointer magic by default instead of using the sysctl analogs (I'm referring to ifconfig, netstat, etc), and as noted by some.. using libkvm on live memory could be potentially; the only valid usage I can really think of is when dealing with . What data does Vic need to grab from the kernel in order to get the file descriptor data? Just a quick note that FreeBSD 9 and later also have libprocstat which could be a nice interface. I haven't looked at the details yet though. libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischer jul...@freebsd.org wrote: On 10/11/11 12:36 PM, Arnaud Lacombe wrote: [...] libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE kernel together and have all utilities working. If not, you cannot claim to support backward compatibility, even if you do on a subset of kernel/userland interface. That said, this is just my personal opinion. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. then the job was done bad. I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). Let me emphasize again that it is only my personal opinion :-) - Arnaud ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 3:24 PM, Garrett Cooper yaneg...@gmail.com wrote: On Tue, Oct 11, 2011 at 11:36 AM, Arnaud Lacombe lacom...@gmail.com wrote: Hi, On Tue, Oct 11, 2011 at 8:00 AM, Dimitry Andric d...@freebsd.org wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. #ifdef _KERNEL/#endif protected part of system headers shall NEVER be accessed by userland. It is a fault to have them present in /usr/include. Linux got it right there, all those part are removed upon headers' installation. Yes, but instead Linux encourages mucking around with /proc and /sys, which have varying levels of formatting and provided output. At least, interfaces exist (/proc and /sys) and the data are formatted enough (ASCII text) to abstract the underlying binary format. The data needs to be exported properly via sysctl. If it's not done that way to userland, then the API/KPI is flawed and needs to be revised. just exporting raw data would not do the job; it can already be done with KVM. What is needed is a defined ABI (ie. interface, data and format) between the kernel and userland. I'm not even considering it being stable for now, this would be the subject of another thread. NetBSD has done the interesting move of using property list for kernel/userland structure encoding. I haven't looked for a while so I'm not sure how much interface are now using them. - Arnaud ___ 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-BETA3 (r225759) without ACPI raise a page fault
On Saturday, October 08, 2011 5:29:12 am Henri Hennebert wrote: Hello, On my configuration, If I boot 9.0-BETA3 (r225759) without ACPI, the kernel encounter a page fault before the end of the boot. A photo of the screen can be found at: http://verbier.restart.be/xfer/dsc00042.jpg This is likely an old bug (since 5.0) where the PnP BIOS of some machines does causes a GP# during boot. You will just have to use ACPI (it is more accurate for modern systems anyway). -- 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: System headers with clang?
Am 11.10.2011 15:31, schrieb Larry Rosenman: On Tue, 11 Oct 2011, Dimitry Andric wrote: On 2011-10-09 19:32, Larry Rosenman wrote: I had gotten a PR about sysutils/lsof not compiling with clang. I had Vic Abell check it out, and the problem is NOT with lsof per se, but with the system headers. Is there a project afoot to update the system headers to make them clang compilable? The problem isn't that clang can't compile the system headers, but normally these don't get included from userspace. And they certainly won't work as expected when you define _KERNEL in userspace, as the lsof port foolishly does. It probably can't be avoided in such a tool, though. Point #1: some of the headers have special requirements, like inclusion order, or thereabouts. Since these are kernel headers, you need to abide by their rules. Violated here: ... In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:190: In file included from /usr/src/sys/ufs/ufs/ufsmount.h:36: /usr/src/sys/sys/buf.h:388:2: warning: implicit declaration of function 'KASSERT' is invalid in C99 [-Wimplicit-function-declaration] KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp)); ^ I *suppose* KASSERT is meant as a macro, but even if it's not, ... /usr/src/sys/sys/buf.h:388:33: warning: expression result unused [-Wunused-value] KASSERT(bp-b_bufobj != NULL, (bwrite: no bufobj bp=%p, bp)); ^ These are more or less harmless warnings, as long as nobody calls a function that uses KASSERT. They occur because lsof's headers don't include sys/param.h and sys/systm.h before sys/ufs/ufs/ufsmount.h. ...I'd say that's an lsof, rather than kernel or clang, bug. ... In file included from ckkv.c:43: In file included from ./../lsof.h:195: In file included from ./../dlsof.h:432: In file included from /usr/include/string.h:45: /usr/include/strings.h:47:6: error: conflicting types for '__builtin_ffs' int ffs(int) __pure2; ^ /usr/include/machine/cpufunc.h:140:24: note: expanded from: #defineffs(x) __builtin_ffs(x) ^ /usr/include/strings.h:47:6: note: '__builtin_ffs' is a builtin with type 'int (unsigned int)' This is because the amd64 system headers redefine ffs to __builtin_ffs, after which it conflicts with the declaration in /usr/include/strings.h. On i386, ffs is not redefined, but I have no idea why. Arguably __builtin_ffs() is inconsistently defined if it expects an unsigned int argument. POSIX demands int for ffs()'s argument. The builtin should match that. I can't currently point fingers at the culprit for lack of research/information. Chances are -fno-builtin helps. We need to get clang/system headers to allow warning free compilation just like GCC does. Then make sure that your code is correct. NOTE: GCC defaults to C89 with GNU extensions, clang defaults to C99. To know how GCC treats your code in C99 mode, try gcc -pedantic-error -std=c99 (or possibly -pedantic without -error suffix if there are bogus warnings) and see if it's really clang -- or rather the code... You can override options for either in the port, see http://wiki.freebsd.org/PortsAndClang#Problems_with_fixes and look for USE_CSTD. It won't make your (Vic's) code future proof, but may help for the nonce - or not. Of course Vic is free in writing arbitrarily nonportable code, but before he or you go(es) pointing fingers, check if you're using kernel headers properly and requesting compilation in the right language, and if the code is actually conformant. ___ 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
ipmi(4)/isa woes
Hi folks,
I've got a machine where ipmi(4) seem to be unable to fully attach.
10-current kernel complains the following way:
ipmi0: IPMI System Interface at iomem 0-0x1 on isa0
ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa
ipmi0: couldn't configure I/O resource
device_attach: ipmi0 attach returned 6
Now, 6 is ENXIO, which match the following resource allocation failure:
if (info.offset == 1) {
sc-ipmi_io_rid = 0;
sc-ipmi_io_res[0] = bus_alloc_resource(dev, type,
sc-ipmi_io_rid, info.address, info.address + count - 1,
count, RF_ACTIVE);
if (sc-ipmi_io_res[0] == NULL) {
device_printf(dev, couldn't configure I/O resource\n);
return (ENXIO);
}
}
Has anyone encountered this issue ?
Thanks,
- Arnaud
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipmi(4)/isa woes
Hi,
On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi folks,
I've got a machine where ipmi(4) seem to be unable to fully attach.
10-current kernel complains the following way:
ipmi0: IPMI System Interface at iomem 0-0x1 on isa0
ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa
ipmi0: couldn't configure I/O resource
device_attach: ipmi0 attach returned 6
Actually, I can bypass this issue by enabling acpi(4):
ipmi0: IPMI System Interface port 0xca2,0xca3 on acpi0
ipmi0: KCS mode found at io 0xca2 on acpi
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
pmtimer0 on isa0
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
However, the driver fails right after with:
ipmi0: Timed out waiting for GET_DEVICE_ID
and thus never complete its startup... :(
- Arnaud
Now, 6 is ENXIO, which match the following resource allocation failure:
if (info.offset == 1) {
sc-ipmi_io_rid = 0;
sc-ipmi_io_res[0] = bus_alloc_resource(dev, type,
sc-ipmi_io_rid, info.address, info.address + count - 1,
count, RF_ACTIVE);
if (sc-ipmi_io_res[0] == NULL) {
device_printf(dev, couldn't configure I/O resource\n);
return (ENXIO);
}
}
Has anyone encountered this issue ?
Thanks,
- Arnaud
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipmi(4)/isa woes
On Tue, Oct 11, 2011 at 3:53 PM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi,
On Tue, Oct 11, 2011 at 6:34 PM, Arnaud Lacombe lacom...@gmail.com wrote:
Hi folks,
I've got a machine where ipmi(4) seem to be unable to fully attach.
10-current kernel complains the following way:
ipmi0: IPMI System Interface at iomem 0-0x1 on isa0
ipmi0: KCS mode found at mem 0x0 alignment 0x1 on isa
ipmi0: couldn't configure I/O resource
device_attach: ipmi0 attach returned 6
Actually, I can bypass this issue by enabling acpi(4):
ipmi0: IPMI System Interface port 0xca2,0xca3 on acpi0
ipmi0: KCS mode found at io 0xca2 on acpi
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
pmtimer0 on isa0
ipmi1: IPMI System Interface on isa0
device_attach: ipmi1 attach returned 16
However, the driver fails right after with:
ipmi0: Timed out waiting for GET_DEVICE_ID
and thus never complete its startup... :(
- Arnaud
Now, 6 is ENXIO, which match the following resource allocation failure:
if (info.offset == 1) {
sc-ipmi_io_rid = 0;
sc-ipmi_io_res[0] = bus_alloc_resource(dev, type,
sc-ipmi_io_rid, info.address, info.address + count - 1,
count, RF_ACTIVE);
if (sc-ipmi_io_res[0] == NULL) {
device_printf(dev, couldn't configure I/O resource\n);
return (ENXIO);
}
}
Has anyone encountered this issue ?
You might need to define a hint to use the KCS interface via
device.hints. I don't remember the incantation exactly, but I think it
was required for some Dells. ipmi(4) should have more info.
Failing that, a BMC upgrade/downgrade might be required (some vendors
don't test out BMC firmware upgrades really well, esp. in FreeBSD).
HTH,
-Garrett
___
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
crash in sb-concurrency tests after r216641 on x86-64/freebsd9/sb-thread
After r216641 sbcl built with sb-thread dies on mailbox tests. It also dies when I try to complete a symbol in slime. The workaround seems to be to revert libthr to r216640. http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/154050 http://svn.freebsd.org/changeset/base/216641 http://www.freshports.org/lang/sbcl # or see ports/161444 for sbcl-1.0.52 Any clue whether it's a FreeBSD bug or a SBCL bug? I've Bcc'd sbcl-bugs@ in case it's the latter one. $ cd lang/sbcl $ rm files/patch-disable-failing-tests $ make # it should fail $ cd $(make -V WRKSRC) $ SBCL_HOME=contrib/ ./src/runtime/sbcl \ --core output/sbcl.core --no-userinit --no-sysinit \ --eval (require 'sb-concurrency) \ --eval (asdf:oos 'asdf:test-op :sb-concurrency-tests) This is SBCL 1.0.52, an implementation of ANSI Common Lisp. More information about SBCL is available at http://www.sbcl.org/. SBCL is free software, provided as is, with absolutely no warranty. It is mostly in the public domain; some portions are provided under BSD-style licenses. See the CREDITS and COPYING files in the distribution for more information. Doing 16 pending tests of 16 tests total. SB-CONCURRENCY-TEST::QUEUE.1 SB-CONCURRENCY-TEST::QUEUE.2 SB-CONCURRENCY-TEST::QUEUE.3 SB-CONCURRENCY-TEST::QUEUE.4 SB-CONCURRENCY-TEST::QUEUE.5 SB-CONCURRENCY-TEST::QUEUE.T.1 SB-CONCURRENCY-TEST::QUEUE.T.2 SB-CONCURRENCY-TEST::QUEUE.T.3 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.1 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.2 SB-CONCURRENCY-TEST::MAILBOX-TRIVIA.3 SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-SINGLE-CONSUMER SB-CONCURRENCY-TEST::MAILBOX.SINGLE-PRODUCER-MULTIPLE-CONSUMERS FFatal error 'thread was already on queue.' at atal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) FaFtfatal error encounteredalal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in tal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (erf in SBCL pid 1993rfatal error encounteredFatal error 'thread was already on queue.' at line infatal error encountered222 in file /usr/src/lib/libthr/thread/thr_cond.c (errnole /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) o = 0) (tid 34384826368) in SBCL pid 1993= 0F)fatal error encounteredaFFataltfatal error encounteredatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) error 'thread was already on queue.' aa in SBCL pid 1993t lFataFl error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) l error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) ine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) : (tid 34384824320) in SBCL pid 1993fatal error encounteredfatal error encounteredfatal error encountered in SBCL pid 1993fatal error encounteredfatal error encountered in SBCL pid 1993(tid 34384815104): SIGABRT received. atal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) fatal error encountered(tid 34384823296)SIGABRT received. : (tid 34384822272) in SBCL pid 1993 in SBCL pid 1993 in SBCL pid 1993(tid 34384828416) in SBCL pid 1993(tid 34384813056)FFaFatal error 'thread was already on queue.' t at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) al error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) aFatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 Fatal error 'thread was already on queue.' at lFine 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (errno = 0) Fatal error 'thread was already on queue.' at line 222 in file /usr/src/lib/libthr/thread/thr_cond.c (err in SBCL pid 1993: SIGABRT received. :
Re: System headers with clang?
On 10/11/11 12:57 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischerjul...@freebsd.org wrote: On 10/11/11 12:36 PM, Arnaud Lacombe wrote: [...] libprocstat is _itself_ a problem: % git grep 'define _KERNEL' . [...] lib/libprocstat/cd9660.c:#define _KERNEL lib/libprocstat/nwfs.c:#define _KERNEL lib/libprocstat/smbfs.c:#define _KERNEL lib/libprocstat/udf.c:#define _KERNEL lib/libprocstat/zfs.c:#define _KERNEL [...] ok, I admit this is all FS related stuff :) but at least it comes with the system so it matches. no, you should be able to run a FreeBSD 1.0 userland and a 9-RELEASE kernel together and have all utilities working. If not, you cannot claim to support backward compatibility, even if you do on a subset of kernel/userland interface. That said, this is just my personal opinion. we've been looking for the 'right' way to do this since, hmmm, 1988 that I remember and I bet before that too. then the job was done bad. I didn't say we DID it I said we've been looking for the right answer. libkvm was a small step... you really don't want to know what was done before that. I've run FreeBSD 1.1 on a freeBSD 8 jail so I know what you mean, you have to put some things like 'ps' and ifconfig, and 'netstat' into it (statically compiled) or you can't get anywhere but even if there was a differnt interface, the likelyhood of it still being valid after 19 years pretty small. I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). actually due to libkvm there are actually a lot of programs that will work over the 7-8 boundary... a lot more than used to. between, say 2 and 3. Let me emphasize again that it is only my personal opinion :-) Yep but its shared.. Unfortunately the problem is actually trickier than first appears. My own attempt at it can be seen with netgraph, where we instituted a text based config scheme, and in geom where PHK made an XML config scheme. - Arnaud ___ 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: System headers with clang?
Hi, On Tue, Oct 11, 2011 at 9:09 PM, Julian Elischer jul...@freebsd.org wrote: On 10/11/11 12:57 PM, Arnaud Lacombe wrote: Hi, On Tue, Oct 11, 2011 at 3:42 PM, Julian Elischerjul...@freebsd.org wrote: On 10/11/11 12:36 PM, Arnaud Lacombe wrote: [...] I will repeat myself here, but I ran what-was-to-become-Linux-v3.2 kernel on a 4 years old openwrt image and still had a functional system. Comparatively, I could not mix FreeBSD 7-STABLE userland and 8-STABLE kernel, The 8-STABLE kernel even changed the FS enough to make FreeBSD 7 unable to boot (even single user). actually due to libkvm there are actually a lot of programs that will work over the 7-8 boundary... a lot more than used to. between, say 2 and 3. Let me emphasize again that it is only my personal opinion :-) Yep but its shared.. Unfortunately the problem is actually trickier than first appears. My own attempt at it can be seen with netgraph, where we instituted a text based config scheme, and in geom where PHK made an XML config scheme. it would seem that any attempt to solves that problem somehow ends-up to hierarchically text-encode/decode the binary data, Linux /proc / /sys text file-based interface, the netgraph encoding (which I admit is really powerful once dominated), phk's XML config scheme, NetBSD Apple property list :) - Arnaud ___ 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: flash for 9-beta3
Hi Folks, Sorry if this is unrelated but in 9.0-BETA3 about:plugins in chromium and firefox both show both flash and acrobat plugins, but I see these NSPlugin Wrapper errors in the console when I start the browser from the command line. *** NSPlugin Wrapper *** ERROR: failed to initialize plugin-side RPC client connection After some google searching it seems it has to do with a compile/runtime time change in the linux syscall interface. I experimented with the changing the linux osrelease sysctl but it hasn't fixed the issue for me. ~ Ali On Mon, Oct 10, 2011 at 8:00 PM, Nenhum_de_Nos math...@eternamente.info wrote: On Mon, October 10, 2011 18:38, Phil Oleson wrote: On 10/10/11 15:30, Nenhum_de_Nos wrote: On Sun, October 9, 2011 13:39, Nenhum_de_Nos wrote: On Sat, October 8, 2011 20:03, Doug Barton wrote: On 10/08/2011 14:53, Warren Block wrote: nspluginwrapper needs to be run as the end user. The pkg-message tells them to do that. ops, haven't seen it though. all the ports cleaned by the clean part of the command got on my way :( I did, no good though. FF still says no plugins. is it FF 7 compatible ? matheus I ran into this recently. Though I have not figured out a more correct fix.. add this to your .bashrc: export MOZ_PLUGIN_PATH=/usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox or.. .cshrc setenv MOZ_PLUGIN_PATH /usr/local/lib/browser_plugins/symlinks/gecko19:/usr/local/lib/npapi/symlinks/firefox and flash will work with the newer firefox. -Phil. thanks Phil, but no good to me :/ Both dirs don't exist, and I tried exporting to browser_plugins dir also ... thanks, matheus -- We will call you cygnus, The God of balance you shall be A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? http://en.wikipedia.org/wiki/Posting_style ___ 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: x11/nvidia-driver / Compilation has failed
On Thu, Oct 06, 2011 at 01:35:14AM +, Nali Toja wrote: Ali Mashtizadeh mashtiza...@gmail.com writes: 2011/8/31 Alexey Dokuchaev da...@freebsd.org: On Mon, Aug 29, 2011 at 02:59:48PM +0200, Olivier Smedts wrote: 2011/8/29 ken k...@tydfam.jp: Could I test your patch for nvidia-driver, too? I cannot find your patch in this mail. I took the patch in : http://lists.freebsd.org/pipermail/freebsd-current/2011-August/026515.html And it worked for me. Should be fixed in the port itself now (also updated to 280.13). Is there any reason I should still be hitting this bug when building on 9-STABLE? With Linux compatibility disabled I can build the driver, but the kernel refuses to load it saying it's incompatible with my kernel version. Only if you're using 285.05.09 with the port. And it'd affect both /stable/9 and /head users. // from src/nv-freebsd.h: #if __FreeBSD_version = 900041 #include sys/capability.h #else #define fget(td, fd, cap, fp) fget(td, fd, fp) #endif Can you commit below tiny change? It should make testing the new version a bit easier for people who are impatient to wait for the next port update. That version also includes tunable support similar to ports/156386. Port was updated to serve the most recent release from NVidia, 285.05.09. Please test and report of any issues. Thanks, ./danfe ___ 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
