[CURRENT]: Broken ssh: Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe
Since a couple of time now (~1 1/2 months) I'm bothered by very unreliable ssh connections betwwwn CURRENT boxes. Very often, the connection simply dies with Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe This is even worse than annoying, how to maintain systems remotely with such unreliable connections? The problem seems to be related to CURRENT, but I do not have any truthfull reference since we use only one 10.3-STABLE box. I will describe my observations, hopefully someone can make a picture out of it. The "Broken pipe" which kills poudriere sessions, buildworld (worse, if a installworld gets caught by the Broken pipe!) are between CURRENT systems, the "controling" box is a CURRENT box with X11/xterm from which I start the ssh sesseion. Connections from such X11/xterm systems no remote servers seem to be "stable" as long as I do not open a second ssh connection. But this is not much reliable, just an observation. Sometimes an open ssh connection lasts tens of minutes, even with some "noise" (output) on the terminal or relaxed (static blinking cursor awaiting further input), but in other cases, a connections dies very quickly. It seems to me that this behaviour is random. It occurs under load or on relaxed systems randomly, sometimes very quick, sometimes it lasts longer. The observation of today about the single-ssh connection is weak, but I have a strange suspicion that concurrent sessions trigger the drops faster. In any case, the ssh session seems to go "asleep" after a while: that happens randomly over a time or very quickly - I have no clue what triggers this erratic behaviour. It takes a while before the ssh connection/xterm takes input again - up to 30 seconds (even on fast, relaxed systems) or as final consequence, a "Broken pipe". Today, I made another experience. Having some autofs mounts on several systems, performance/bandwith seemed very bad/slow (both server and clients are CURRENT, most recent builds as of today). I reported earlier on this list about shaky and slow performance in conjunction with the ssh problem, but I wasn't able to figure out what causes the problem! And I'm wondering about nobody else is facing such dramatic dropouts of the ssh connections or performance issues. I think I will issue a PR on this, too. Kind regards, O. Hartmann pgplH9GB8MVXD.pgp Description: OpenPGP digital signature
Re: CURRENT BROKEN fatal error: 'config_local.h' file not found
On 2/16/16 2:55 AM, Outback Dingo wrote: > seems current is broken due to a missing file > /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: > 'config_local.h' file not found > It's fixed now. -- Regards, Bryan Drewery ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
CURRENT BROKEN fatal error: 'config_local.h' file not found
seems current is broken due to a missing file /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found CC='cc' mkdep -f .depend -a -I/usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/libelftc -I/usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/libpe -I/usr/src/usr.bin /elfcopy/../../contrib/elftoolchain/common -DWITH_PE=1 -std=gnu99 /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/archive.c /usr/src/usr.bin/elfcopy/../../co ntrib/elftoolchain/elfcopy/ascii.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/binary.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/main.c / usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/pe.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/sections.c /usr/src/usr.bin/elfcopy/../../contri b/elftoolchain/elfcopy/segments.c /usr/src/usr.bin/elfcopy/../../contrib/elftoolchain/elfcopy/symbols.c --- depend_subdir_usr.sbin --- 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/mtab/mtab_bsd.c:51: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from /usr/src/usr.sbin/amd/libamu/../../../contrib/amd/conf/umount/umount_bsd44.c:49: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. In file included from xdr_func_%undef.c:48: /usr/src/usr.sbin/amd/libamu/../include/config.h:12:10: fatal error: 'config_local.h' file not found #include "config_local.h" ^ 1 error generated. mkdep: compile failed *** [.depend] Error code 1 make[5]: stopped in /usr/src/usr.sbin/amd/libamu 1 error ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On 19 Jul, O'Connor, Daniel wrote: On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote: O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. Yeah the subject is wrong (I just updated it). I just did a build like so and it worked.. env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld But this did not.. make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable - I wonder if there is a way the make system can be changed to warn about that? At least it is documented in /usr/share/mk/bsd.obj.mk: # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the object # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable # and works properly only if set as an environment variable, # not as a global or command line variable! # # E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make' Not the most obvious place to look ... ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On Sun, Jul 19, 2015 at 11:05:48PM -0700, Don Lewis wrote: On 19 Jul, O'Connor, Daniel wrote: On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote: O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. Yeah the subject is wrong (I just updated it). I just did a build like so and it worked.. env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld But this did not.. make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable - I wonder if there is a way the make system can be changed to warn about that? At least it is documented in /usr/share/mk/bsd.obj.mk: # MAKEOBJDIRPREFIX Specifies somewhere other than /usr/obj to root the object # tree. Note: MAKEOBJDIRPREFIX is an *environment* variable # and works properly only if set as an environment variable, # not as a global or command line variable! # # E.g. use `env MAKEOBJDIRPREFIX=/somewhere/obj make' Not the most obvious place to look ... It is documented in build(7) too: MAKEOBJDIRPREFIX Defines the prefix for directory names in the tree of built objects. Defaults to /usr/obj if not defined. This variable should only be set in the environment and not via /etc/make.conf or the command line. Regards, Navdeep ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote: O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. Yeah the subject is wrong (I just updated it). I just did a build like so and it worked.. env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld But this did not.. make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 So, it seems MAKEOBJDIRPREFIX only works as an environmental variable - I wonder if there is a way the make system can be changed to warn about that? -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: -current broken when src is on NFS
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote: O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. I've been following this saga (on irc and here) as much as I have time for, and I can't escape the feeling that it is the directory structure at fault somehow, but I can't quite put my finger on it. I never (ever) build from /usr/src or use /usr/obj as an object dir (they're both empty dirs on all my machines). But one thing that is always true for me is that the source dir and its related object dir are siblings in the same parent dir. That is, it's always /any/path/here obj/ src/ Given that we have (or at least had at one time) some of those magical ... paths that cause bmake to search up the hierarchy for its .mk files, I wonder if an odd relationship between src and obj dir confuses it, or if it somehow wanders into a wrong src tree while searching? -- Ian ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
O'Connor, Daniel dar...@dons.net.au wrote: So, it seems MAKEOBJDIRPREFIX only works as an environmental variable Weird, I could have sworn I have set it on the command line and had it work, but.. In most normal usage you will likely not notice a difference. It is only when a makefile is being clever that things go south when you break its expectations. I thought there was a check in src/Makefile for that. Not so far as I can tell - it certainly gets quite far before blowing up with a non useful error message :) The check in src/Makefile is only guarding against MAKEOBJDIRPREFIX set in say make.conf, it explicitly discards the possibility of setting MAKEOBJDIRPREFIX on command line - which seems wrong. Also with bmake, you *can* usefully set MAKEOBJDIRPREFIX in a makefile since the choice of .OBJDIR can be made after make starts reading makefiles. So the current test is perhaps out dated on that score too - though only if something like auto.obj.mk is being used (-DWITH_AUTO_OBJ) which I don't think I've tested with buildworld. ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On 20 Jul 2015, at 04:29, Simon J. Gerraty s...@juniper.net wrote: O'Connor, Daniel dar...@dons.net.au wrote: But this did not.. make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 Nor should it. There are several makefiles in the tree that expect to be able to change MAKEOBJDIRPREFIX in the environment of a sub-make. When you set it on the command line like that you prevent such changes from working. Ahh.. You learn something new every day :) So, it seems MAKEOBJDIRPREFIX only works as an environmental variable Yes, it has always been documented that way. Weird, I could have sworn I have set it on the command line and had it work, but.. - I wonder if there is a way the make system can be changed to warn about that? I thought there was a check in src/Makefile for that. Not so far as I can tell - it certainly gets quite far before blowing up with a non useful error message :) -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
O'Connor, Daniel dar...@dons.net.au wrote: Yeah the subject is wrong (I just updated it). I just did a build like so and it worked.. env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld That's the right way to use it. But this did not.. make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64 Nor should it. There are several makefiles in the tree that expect to be able to change MAKEOBJDIRPREFIX in the environment of a sub-make. When you set it on the command line like that you prevent such changes from working. So, it seems MAKEOBJDIRPREFIX only works as an environmental variable Yes, it has always been documented that way. - I wonder if there is a way the make system can be changed to warn about that? I thought there was a check in src/Makefile for that. ___ 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: -current broken when src is on NFS
On Sun, Jul 19, 2015 at 10:31:36AM -0600, Ian Lepore wrote:
I've been following this saga (on irc and here) as much as I have time
for, and I can't escape the feeling that it is the directory structure
at fault somehow, but I can't quite put my finger on it.
I never (ever) build from /usr/src or use /usr/obj as an object dir
(they're both empty dirs on all my machines). But one thing that is
always true for me is that the source dir and its related object dir are
siblings in the same parent dir. That is, it's always
/any/path/here
obj/
src/
Well, as counterpoint The systems where I do FreeBSD builds are
usually set up (and have been since about 1999) so that:
* The sources reside in /usr/src.
* The file system layput is such that:
+ /usr is on a different file system from /, but these reside in
partitions 4 and 1 (respectively) of the same slice.
+ /var is a file system that resides on a partition on slice 4.
+ swap is on slice 4, partition 2.
+ /tmp is a swap-backed tmpfs. (Well, the implementation of that has
changed over the years -- used to be mfs.)
+ My home directory resides in a file system on a partition in slice
4 mounted on /common -- along with quite a few other things that do
not need to physically be on the same slice that I booted from.
+ /usr/ports is a symlink to an SVN working copy (was a CVS working
directory once upon a time) that's in the same file system as
my home directory.
+ Historically, /usr/local was also a symlink to a hierarchy in that
same file system. (I only built ports under stable, but used them
under both stable and head.)
+ /usr/obj is also a symlink to a hierarchy in that same file system
(/common) -- I had one for each slice (/common/S{1,2,3,4}).
* Each of slices 1, 2, and 3 has a / and a /usr file system (as
described above); slice 4 has those, as well as swap, /var, /common, and
(often) a few others (e.g., /repo or /bkp).
* If I'm merely booting to single-user mode, each of the 4 slices is
independent of the others, and I can boot any of them. As soon as I
start setting up swap, I become dependent on slice 4 (if I wasn't
already booted from it).
It is not at all uncommon for me to clone one slice to another using a
'dump | restore' pipeline; by having the actual contents of /usr/obj in a
separate file system, it is easy to make copying that optional -- and if
my intent is to move it (vs. copy), renaming a directory is pretty fast
and cheap.
Given that we have (or at least had at one time) some of those magical
... paths that cause bmake to search up the hierarchy for its .mk
files, I wonder if an odd relationship between src and obj dir confuses
it, or if it somehow wanders into a wrong src tree while searching?
...
Well, I suspect that if that were an issue, I'd likely have encountered
it (while muttering further deprecation against realpath all the while).
:-}
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
Those who murder in the name of God or prophet are blasphemous cowards.
See http://www.catwhisker.org/~david/publickey.gpg for my public key.
pgpsYPDXAjyiE.pgp
Description: PGP signature
Re: -current broken when src is on NFS
Given that we have (or at least had at one time) some of those magical ... paths that cause bmake to search up the hierarchy for its .mk files, I wonder if an odd relationship between src and obj dir confuses it, or if it somehow wanders into a wrong src tree while searching? Based on Daniel's latest mail, the issue would appear to be the way he was setting MAKEOBJDIRPREFIX. As for .../ src.sys.env.mk resolves that to absolute path since otherwise things like kernel builds wouldn't work - make run from within obj tree. ___ 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: -current broken when MAKEOBJDIRPREFIX is set (was: src is on NFS)
On 20 Jul 2015, at 11:40, Simon J. Gerraty s...@juniper.net wrote: O'Connor, Daniel dar...@dons.net.au wrote: So, it seems MAKEOBJDIRPREFIX only works as an environmental variable Weird, I could have sworn I have set it on the command line and had it work, but.. In most normal usage you will likely not notice a difference. It is only when a makefile is being clever that things go south when you break its expectations. I guess, buildworld is pretty clever though :) I thought there was a check in src/Makefile for that. Not so far as I can tell - it certainly gets quite far before blowing up with a non useful error message :) The check in src/Makefile is only guarding against MAKEOBJDIRPREFIX set in say make.conf, it explicitly discards the possibility of setting MAKEOBJDIRPREFIX on command line - which seems wrong. Also with bmake, you *can* usefully set MAKEOBJDIRPREFIX in a makefile since the choice of .OBJDIR can be made after make starts reading makefiles. So the current test is perhaps out dated on that score too - though only if something like auto.obj.mk is being used (-DWITH_AUTO_OBJ) which I don't think I've tested with buildworld. I know sod all about *make but as an 'end user' a seat belt to warn about this problem would be Really Nice (tm). -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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: -current broken when src is on NFS
O'Connor, Daniel dar...@dons.net.au wrote: However, Crochet _does_ build on the NFS client _and_ when the source tree isn't in /usr/src which makes this issue very strange :-/ I've seen similar errors in rescue... (no NFS) though I cannot quite recall the cause other than it seems very sensitive to MAKEOBJDIRPREFIX value. ___ 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: -current broken when src is on NFS
On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com wrote:
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already
set it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having issues with /usr/obj being on NFS, that could be a factor.
I removed NFS from the equation by building on the machine holding the source
and it still bombs out.
However, Crochet _does_ build on the NFS client _and_ when the source tree
isn't in /usr/src which makes this issue very strange :-/
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
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: -current broken when src is on NFS
On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited
from
OpenBSD and was not the behaviour of the old FreeBSD NFS client but was
default
for the new NFS client) can be enabled via:
vfs.nfs.ignore_eexist=1
You could try setting that sysctl and seeing if it makes any difference?
That is the only recent change to the NFS client that *might* affect this.
No dice :(
It's pretty weird, it bombs out if either src or obj is on NFS..
But even weirder is that if I build with crochet (a wrapper for cross
building to arm) it works. It doesn't work if I cross build manually and I
haven't been able to determine why crochet works yet.
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already set
it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having issues with /usr/obj being on NFS, that could be a factor.
Tim
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote: On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote: r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( So, it turns out NFS is not an issue.. I think it must be that it's not on /usr/src. I changed to building on the NFS server (which runs 10 but building -current should work OK) and it still bombs out. --- rescue.all__D --- make[5]: make[5]: don't know how to make /src/obj-amd64//src/FreeBSD-SVN/rescue/rescue//src/FreeBSD-SVN/bin/cat/cat.o. Stop That still doesn't explain how crochet and freebsd-wifi-build work though - I thought it was because they don't build rescue, but crochet does. Does anyone else see this? -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
-current broken when src is on NFS
I am seeing the following breakage when building -current and the source is on
NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl -DWITH_INET6
-DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Qunused-arguments -c
/src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o. Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
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: -current broken when src is on NFS
Daniel O'Conner wrote:
I am seeing the following breakage when building -current and the source is
on NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk
exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl
-DWITH_INET6 -DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments
-c /src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o.
Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited from
OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default
for the new NFS client) can be enabled via:
vfs.nfs.ignore_eexist=1
You could try setting that sysctl and seeing if it makes any difference?
That is the only recent change to the NFS client that *might* affect this.
To be honest, I have no idea what the correct behaviour for // in a pathname
is?
rick
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
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: -current broken when src is on NFS
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote: r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( To be honest, I have no idea what the correct behaviour for // in a pathname is? Nothing, they just get eaten. This isn't AmigaDOS! :) -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ 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
gcc in -current broken
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After SVN r258501, I get .. === gnu/usr.bin/cc/cc1 (all) - --- cc1-dummy --- cc -O2 -pipe -DGCCVER=\4.2\ -DIN_GCC -DHAVE_CONFIG_H - -DPREFIX=\/usr/obj/usr/src/tmp/usr\ - -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber - -std=gnu89 -I/usr/obj/usr/src/tmp/legacy/usr/include -static - -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a - -legacy /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o): In function `preprocess_file': c-ppoutput.c:(.text+0xc75): undefined reference to `_cpp_preprocess_dir_only' /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o): In function `compute_may_aliases': tree-ssa-alias.c:(.text+0x64cb): undefined reference to `strict_aliasing_warning_backend' *** [cc1-dummy] Error code 1 -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.15 (FreeBSD) iEYEARECAAYFAlKRcS4ACgkQQv9rrgRC1JIb8wCglaUhK0AjvtDvF7RW7GZT8H3d 2I0AoI57UJNDpmZebf7SYsP9QdgsfvFx =y9Yf -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: gcc in -current broken
On 23.11.2013 22:23, Michael Butler wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 After SVN r258501, I get .. === gnu/usr.bin/cc/cc1 (all) - --- cc1-dummy --- cc -O2 -pipe -DGCCVER=\4.2\ -DIN_GCC -DHAVE_CONFIG_H - -DPREFIX=\/usr/obj/usr/src/tmp/usr\ - -I/usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../cc_tools - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcc/config - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libcpp/include - -I/usr/src/gnu/usr.bin/cc/cc1/../../../../contrib/gcclibs/libdecnumber - -std=gnu89 -I/usr/obj/usr/src/tmp/legacy/usr/include -static - -L/usr/obj/usr/src/tmp/legacy/usr/lib -o cc1-dummy main.o c-parser.o c-lang.o /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libcpp/libcpp.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libdecnumber/libdecnumber.a /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../libiberty/libiberty.a - -legacy /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(c-ppoutput.o): In function `preprocess_file': c-ppoutput.c:(.text+0xc75): undefined reference to `_cpp_preprocess_dir_only' /usr/obj/usr/src/tmp/usr/src/gnu/usr.bin/cc/cc1/../cc_int/libbackend.a(tree-ssa-alias.o): In function `compute_may_aliases': tree-ssa-alias.c:(.text+0x64cb): undefined reference to `strict_aliasing_warning_backend' *** [cc1-dummy] Error code 1 Ugh... can't believe it I found the issue.. just one missing commit in gnu/../../libcpp. Will be fixed shortly. Thanks! Pedro. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
CURRENT: broken pipe / SIGNAL 13 / no X11 / OpenLDAP/nscd weirdness
The most recent CURRENT (FreeBSD 10.0-CURRENT #0 r247865: Wed Mar 6 08:52:15 CET 2013/amd64, built with CLANG and CXXFLAGS+= -stdlib=libc++ CXXFLAGS+= -std=c++11 set in /etc/src.conf, for the record) does have some serious issues and I'm wondering why others do not. The problems I face affect ALL most recent FreeBSD CURRENT boxes. It doesn't matter whether I use my customized kernel config or GENERIC. The symptoms are weird. Using system commands like top(1) give me a broken pipe on the console. Repeating the command gives me then after a while top screen as expected. Services, like OpenLDAP (which I use throughout all systems with nscd and /etc/nsswitch.conf configured), nagios, hald, dbusd or starting X11, doesn't work properly: starting or not starting seems to be a statistical game. Since some kernel modifications needs recompiling ports which provides kernel modules, like emulators/virtual-box-ose-kmod x11/nvidia-driver fail with [...] *** [do-extract] Signal 13 This happens to all ports I try to compile/recompile, but sometimes, again the gamble, a simple make in the port's directory works and I can recompile. Also strange and possibly a sort of indication for the problem is the behaviour of sudo(1): hartmann@gate: [~] sudo su - Password: hartmann@gate: [~] sudo(1) does not switch to the superuser as it is expected, sometimes I receive a broken pipe error, sometimes it works as expected. In single user mode, I can cmpile ports without problems and I do not see this broken pipe issue. To be able to compile and install a port, I need to perform*** [do-extract] Signal 13 service ldconfig start which works, so all suspicious libraries should be loaded (as a naiv guess, I thought a miscompiled shared lib could casue the problem). Well, in general for the ports problem, the SINGLEUSER mode doesn't show the problem. The X11 system isn't starting up anymore. The problem why this doesn't work seems to change: with sources/kernel prior or equal to r247839, dbusd couldn't start (obviously broken pipe ...). Sporadically non-working services, like slapd (OpenLDAP) seem to start after repeatedly issue service slapd restart, but I can not reproduce by a number the failings. Sometimes the services start at boot time on a regular basis, sometimes not. For further informations of the settings: I use TEMPFS for /var/run and /tmp. This is common to all systems (but it doesn't affect single user mode, somehow). Things which do not work or solve the problem: a) use a GENERIC kernel b) avoid either in GENERIC or CUSTOM kernel CXXFLAGS+= in /etc/src.conf c) disable nscd d) recompile ports which cause trouble or tend to be highly inresponsive: openldap24-sasl-client/server, pam_ldap, nss_ldap, sudo, dbus and hal, xdm, xorg-server, virtualbox-ose-kmod I tried to recompile for now several times the whole sources with all standard setting (no custom /etc/src.conf or make.conf, also GENERIC kernel). No salvation. I also switched off SMP via setting #kern.smp.disabled=1 since this caused earlier some trouble - but this is more a desperate move to narrow down the problem a bit. I hope someone can reproduce this problem since I think I'm not the only one who is using CURRENT in a server-like multiuser/workstation environment (not only Vbox images, jails). Regards, oh ___ 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: CURRENT: Broken on r246222?
On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote: CURRENT, as of recent Revision 246285 (see below) fails and crashes/reboots on an Ivy-Bridge platform (see below). Since the box does not have debugging switched on (not yet, will do eventually Monday), Last thing I see on screen is p4tcc3: CPU Frequency Thermal Control on cpu3 then the system run dark and reboots without any notice (kernel doesn't have debugging switched on so far, will do this after Monday). I don't think there are any known issues. Can you narrow it down to a specific commit? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: Broken on r246222?
Am 02/04/13 20:50, schrieb John Baldwin: On Sunday, February 03, 2013 11:26:53 am O. Hartmann wrote: CURRENT, as of recent Revision 246285 (see below) fails and crashes/reboots on an Ivy-Bridge platform (see below). Since the box does not have debugging switched on (not yet, will do eventually Monday), Last thing I see on screen is p4tcc3: CPU Frequency Thermal Control on cpu3 then the system run dark and reboots without any notice (kernel doesn't have debugging switched on so far, will do this after Monday). I don't think there are any known issues. Can you narrow it down to a specific commit? No, I can't. But I can now confirm, that with r246326 the problem has gone. Oliver signature.asc Description: OpenPGP digital signature
CURRENT: Broken on r246222?
CURRENT, as of recent Revision 246285 (see below) fails and crashes/reboots on an Ivy-Bridge platform (see below). Since the box does not have debugging switched on (not yet, will do eventually Monday), Last thing I see on screen is p4tcc3: CPU Frequency Thermal Control on cpu3 then the system run dark and reboots without any notice (kernel doesn't have debugging switched on so far, will do this after Monday). The box is running quite well with FreeBSD 10.0-CURRENT #1 r246222: Fri Feb 1 23:13:28 CET 2013 (amd64) but sources at: root@gate [src] svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 246285 Node Kind: directory Schedule: normal Last Changed Author: hrs Last Changed Rev: 246283 Last Changed Date: 2013-02-03 11:26:24 +0100 (Sun, 03 Feb 2013) fail. Is there a known issue with hardware like shown below? I have a bunch of more modern Sandy- and Ivy-Bridge Intel driven boxes I'd like to update next week (they run CURRENT as well) and I'm not sure by now to do so. The crash occurs with a GENERIC kernel as well as with the custom kernel (working output is the custom kernel). dmesg: CPU: Intel(R) Core(TM) i3-3220 CPU @ 3.30GHz (3300.09-MHz K8-class CPU) Origin = GenuineIntel Id = 0x306a9 Family = 0x6 Model = 0x3a Stepping = 9 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x3d9ae3bfSSE3,PCLMULQDQ,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,PCID,SSE4.1,SSE4.2,POPCNT,TSCDLT,XSAVE,OSXSAVE,AVX,F16C AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF Standard Extended Features=0x281GSFSBASE,SMEP,ENHMOVSB TSC: P-state invariant, performance statistics real memory = 17179869184 (16384 MB) avail memory = 16221089792 (15469 MB) Event timer LAPIC quality 600 ACPI APIC Table: ALASKA A M I FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 ioapic0 Version 2.0 irqs 0-23 on motherboard kbd1 at kbdmux0 netmap: loaded module ctl: CAM Target Layer loaded smbios0: System Management BIOS at iomem 0xf04c0-0xf04de on motherboard smbios0: Version: 2.7, BCD Revision: 2.7 cryptosoft0: software crypto on motherboard aesni0: No AESNI support. signature.asc Description: OpenPGP digital signature
-current broken on pre-PPro machines (w/ work around)
Just a warning to others so they don't hit the same issue I did, and spend time trying to figure it out. clang (in -current) does not compile code properly for pre-PPro machines... Compiled output includes the cmov instructions... This affects both loader, and kernel, so if you update loader, you'll see a few spins, and the machine will probably reset... if you use an older loader, your kernel will fault a/ an illegal instruction... If you want to run -current on one of these machines, make sure you set WITHOUT_CLANG_IS_CC= for *BOTH* buildworld and installworld so that you use gcc instead of clang... A bug has been filed: http://llvm.org/bugs/show_bug.cgi?id=15115 -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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
-current broken in acpi/iasl
=== usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 -- http://ache.vniz.net/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken in acpi/iasl
On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread -- wbr, tiger ___ 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: -current broken in acpi/iasl
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote: On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread ... My head (10.0-CURRENT) builds (on my laptop build machine) were uneventful; e.g.: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796 r245584M/245600: Fri Jan 18 06:07:23 PST 2013 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 And yes, I use clang. Peace, david -- David H. Wolfskill da...@catwhisker.org Taliban: Evil men with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. pgpCfXU5Sqs2v.pgp Description: PGP signature
Re: -current broken in acpi/iasl
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300: On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread Looks like this broken when jkim imported the latest ACPICA code base: https://svnweb.freebsd.org/base?view=revisionrevision=245582 I've forward the tinderbox failure to him, so hopefully he'll fix it shortly... -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: -current broken in acpi/iasl
On 18.01.2013 22:37, David Wolfskill wrote: On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote: On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread ... My head (10.0-CURRENT) builds (on my laptop build machine) were uneventful; e.g.: FreeBSD g1-227.catwhisker.org 10.0-CURRENT FreeBSD 10.0-CURRENT #796 r245584M/245600: Fri Jan 18 06:07:23 PST 2013 r...@g1-227.catwhisker.org:/usr/obj/usr/src/sys/CANARY i386 And yes, I use clang. Peace, david I have no clang bloat, it happens with good old gcc. signature.asc Description: OpenPGP digital signature
Re: -current broken in acpi/iasl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote: Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300: On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread Looks like this broken when jkim imported the latest ACPICA code base: https://svnweb.freebsd.org/base?view=revisionrevision=245582 I've forward the tinderbox failure to him, so hopefully he'll fix it shortly... It should be fixed now (r245636). Sorry for the breakage. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ+esDAAoJECXpabHZMqHOypgIAILl0S2cvEdTQWXJ4PWase07 yKA+DPHYAUx09JHbnLfEeA+KLFUz2jnX7dYR9ohSMcsnkI1/AH/z8dkFc3NLPUQw TXh1edQyXaYr0WK+3sW81Tl5thka5VwjznoJj1r/Og8Nrx/xYUYCEtpPsjDU1hW0 8T897m6MqOSZokWs4dyOt1ZWoncGRTHgC5tCzjcmAuiOTIkZ7hdLNXKu1nm+cgcy LNEvJf/d1bz6UzQ9xxCxG+HttZhi4YL8uAAYMHZtydM+Zp5yZskajyNmDkThSMhu LrUohDfMLk84DkyoAfzojr90o8tk6TujfHR+osF3oj9NkDi6o6VK0AVs1yKPg5c= =poDO -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
sysinstall on current broken with larger drives
this is the same problem as googled here: http://groups.google.de/groups?hl=delr=ie=UTF-8oe=UTF-8frame=rightth=b2760f23e09bd704seekm=b21hoi%24b75%241%40ncc1701.cistron.net#link1 sysinstall does not like the partition table. It does not like the geometry 119150/16/63 found by kernel. My bios says 1024/255/63 (wrong, only 8 GByte). Sysinstall suggests 7476/255/63 (better, 60 GByte). The partition table was created with diskpart from windows xp, btw. Any ideas? -- Fritz Heinrichmeyer mailto:[EMAIL PROTECTED] FernUniversitaet Hagen, LG ES, 58084 Hagen (Germany) tel:+49 2331/987-1166 fax:987-355 http://www-es.fernuni-hagen.de/~jfh To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
Craig Rodrigues [EMAIL PROTECTED] writes: I tracked this down further to the _fetch_writev() function in libfetch/common.c. Try this patch: Stupid, dumb bug. Of course it is only triggered by specific packet lengths which just happened not to occur during testing :( DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Latest fetch on current broken
I just did a build-install world plus new kernel with current sources as of 3pm PST Sunday the 27th fetch is broken: (src)4190}fetch -vv ftp://ftp.fokus.gmd.de/pub/unix/cdrecord/alpha//cdrtools-1.11a39.tar.gz --- ftp.fokus.gmd.de:21 looking up ftp.fokus.gmd.de connecting to ftp.fokus.gmd.de:21 220- 220-You have reached ftp.FOKUS.FRAUNHOFER.de. 220-Please login as `ftp' to access our archive. 220- 220- Hello UNKNOWN at pozo.com, 220- our local time is Mon Oct 28 00:33:25 2002. 220- 220-There are currently 0 users connected of a limit of 35. 220- 220-All transfers are logged with your username and hostname (as printed above). 220-If you don't like this policy, disconnect NOW! 220- 220 FTP server Fraunhofer FOKUS ready. USER anonymous fetch: cdrtools-1.11a39.tar.gz: Broken pipe ncftp works fine: (src)4191}ncftp ftp.fokus.gmd.de:/pub/unix/cdrecord/alpha//cdrtools-1.11a39.tar.gz You have reached ftp.FOKUS.FRAUNHOFER.de. Please login as `ftp' to access our archive. Hello UNKNOWN at pozo.com, our local time is Mon Oct 28 00:33:57 2002. There are currently 0 users connected of a limit of 35. All transfers are logged with your username and hostname (as printed above). If you don't like this policy, disconnect NOW! Receiving file: cdrtools-1.11a39.tar.gz 100% 0 1577294 bytes. ETA: 0:00 cdrtools-1.11a39.tar.gz: 1577294 bytes received in 40.24 seconds, 38.28 K/s. Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote: I noticed it when doing a portupgrade cdrtools So yes anything that uses fetch is not going to work OK, I started tracing this down. Here's how to get debugging versions: cd /usr/src/lib/libfetch make clean make DEBUG_FLAGS=-g make DEBUG_FLAGS=-g install cd /usr/src/usr.bin/fetch make clean make DEBUG_FLAGS=-g NOSHARED=yes make DEBUG_FLAGS=-g NOSHARED=yes install I traced down the broken pipe. It is happening somewhere in /usr/src/lib/libfetch/ftp.c in the _ftp_authenticate() function. I did an Ethereal capture of my ftp session, and here are the ftp protocol messages: 220 ftp.beastie.tdk.net FTP server (Version 6.00LS) ready. USER anonymous 331 Guest login ok, send your email address as password. 221 You could at least say goodbye. -- Craig Rodrigues http://www.gis.net/~craigr [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get debugging versions:
cd /usr/src/lib/libfetch
make clean
make DEBUG_FLAGS=-g
make DEBUG_FLAGS=-g install
cd /usr/src/usr.bin/fetch
make clean
make DEBUG_FLAGS=-g NOSHARED=yes
make DEBUG_FLAGS=-g NOSHARED=yes install
I tracked this down further to the _fetch_writev() function
in libfetch/common.c. Try this patch:
--- lib/libfetch/common.c.orig Sun Oct 27 22:38:16 2002
+++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
@@ -525,7 +525,7 @@
return (-1);
}
total += wlen;
- while (iovcnt 0 wlen iov-iov_len) {
+ while (iovcnt 0 wlen = iov-iov_len) {
wlen -= iov-iov_len;
iov++;
iovcnt--;
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
At 10:38 PM 10/27/2002 -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get debugging versions:
cd /usr/src/lib/libfetch
make clean
make DEBUG_FLAGS=-g
make DEBUG_FLAGS=-g install
cd /usr/src/usr.bin/fetch
make clean
make DEBUG_FLAGS=-g NOSHARED=yes
make DEBUG_FLAGS=-g NOSHARED=yes install
I tracked this down further to the _fetch_writev() function
in libfetch/common.c. Try this patch:
--- lib/libfetch/common.c.orig Sun Oct 27 22:38:16 2002
+++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
@@ -525,7 +525,7 @@
return (-1);
}
total += wlen;
- while (iovcnt 0 wlen iov-iov_len) {
+ while (iovcnt 0 wlen = iov-iov_len) {
wlen -= iov-iov_len;
iov++;
iovcnt--;
--
Craig Rodrigues
http://www.gis.net/~craigr
[EMAIL PROTECTED]
This change makes it work here
Manfred
==
|| [EMAIL PROTECTED] ||
|| Ph. (415) 681-6235 ||
==
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Latest fetch on current broken
On Sun, Oct 27, 2002 at 10:38:36PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 10:21:02PM -0500, Craig Rodrigues wrote:
On Sun, Oct 27, 2002 at 06:31:27PM -0800, Manfred Antar wrote:
I noticed it when doing a portupgrade cdrtools
So yes anything that uses fetch is not going to work
OK, I started tracing this down.
Here's how to get debugging versions:
cd /usr/src/lib/libfetch
make clean
make DEBUG_FLAGS=-g
make DEBUG_FLAGS=-g install
cd /usr/src/usr.bin/fetch
make clean
make DEBUG_FLAGS=-g NOSHARED=yes
make DEBUG_FLAGS=-g NOSHARED=yes install
I tracked this down further to the _fetch_writev() function
in libfetch/common.c. Try this patch:
--- lib/libfetch/common.c.origSun Oct 27 22:38:16 2002
+++ lib/libfetch/common.c Sun Oct 27 22:40:12 2002
@@ -525,7 +525,7 @@
return (-1);
}
total += wlen;
- while (iovcnt 0 wlen iov-iov_len) {
+ while (iovcnt 0 wlen = iov-iov_len) {
wlen -= iov-iov_len;
iov++;
iovcnt--;
Yay, this works for me. :)
--
Carl Schmidt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: dump on current broken -- master/slave protocol botched
On Wed, Jun 05, 2002 at 08:01:54PM -0700, Manfred Antar wrote: I have been using the following command to dump for months with no problem: dump 0fua /dev/nsa0 /dev/da0s1a for the past few weeks I get this: (bin)504}dump 0fua /dev/nsa0 /dev/da0s1a DUMP: Date of this level 0 dump: Wed Jun 5 19:54:04 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 67590 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: master/slave protocol botched. DUMP: The ENTIRE dump is aborted. I am seeing this also. :-( Is your world kernel in sync. I must admit my kernel is May 17 (been avoiding some suspicious problems in SMP kernels); but world is Jun 3rd. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: dump on current broken -- master/slave protocol botched
At 09:30 AM 6/6/2002 -0700, David O'Brien wrote: On Wed, Jun 05, 2002 at 08:01:54PM -0700, Manfred Antar wrote: I have been using the following command to dump for months with no problem: dump 0fua /dev/nsa0 /dev/da0s1a for the past few weeks I get this: (bin)504}dump 0fua /dev/nsa0 /dev/da0s1a DUMP: Date of this level 0 dump: Wed Jun 5 19:54:04 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 67590 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: master/slave protocol botched. DUMP: The ENTIRE dump is aborted. I am seeing this also. :-( Is your world kernel in sync. I must admit my kernel is May 17 (been avoiding some suspicious problems in SMP kernels); but world is Jun 3rd. Everything in sync and current. Dump from May 3rd works == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
dump on current broken -- master/slave protocol botched
I have been using the following command to dump for months with no problem: dump 0fua /dev/nsa0 /dev/da0s1a for the past few weeks I get this: (bin)504}dump 0fua /dev/nsa0 /dev/da0s1a DUMP: Date of this level 0 dump: Wed Jun 5 19:54:04 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 67590 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: master/slave protocol botched. DUMP: The ENTIRE dump is aborted. (bin)505} I restored dump from a tape from 5/3/2002 and it works fine : (bin)506}old.dump 0fua /dev/nsa0 /dev/da0s1a DUMP: Date of this level 0 dump: Wed Jun 5 19:56:05 2002 DUMP: Date of last level 0 dump: the epoch DUMP: Dumping /dev/da0s1a (/) to /dev/nsa0 DUMP: mapping (Pass I) [regular files] DUMP: mapping (Pass II) [directories] DUMP: estimated 68395 tape blocks. DUMP: dumping (Pass III) [directories] DUMP: dumping (Pass IV) [regular files] DUMP: DUMP: 68070 tape blocks on 1 volume DUMP: finished in 82 seconds, throughput 830 KBytes/sec DUMP: level 0 dump on Wed Jun 5 19:56:05 2002 DUMP: Closing /dev/nsa0 DUMP: DUMP IS DONE The hardware is SCSI adaptec controller: ahc0: Adaptec aic7880 Ultra SCSI adapter port 0xfc00-0xfcff mem 0xffbea000-0xffbeafff irq 10 at device 9.0 on pci0 aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs Disk: da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST19171W 0024 Fixed Direct Access SCSI-2 device da0: 20.000MB/s transfers (20.000MHz, offset 15), Tagged Queueing Enabled da0: 8683MB (17783112 512 byte sectors: 255H 63S/T 1106C) Tape drive HP DDS2: sa0 at ahc0 bus 0 target 4 lun 0 sa0: HP C1533A A907 Removable Sequential Access SCSI-2 device sa0: 10.000MB/s transfers (10.000MHz, offset 15) Manfred == || [EMAIL PROTECTED] || || Ph. (415) 681-6235 || == To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken in lukemftpd
/flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar ray `remotehost' has non-integer type /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err or before `transflag' /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: warning: d ata definition has no type or storage class ls-unmain.c: In function `ls_main': ls-unmain.c:370: `revnamecmp' undeclared (first use in this function) ls-unmain.c:370: (Each undeclared identifier is reported only once ls-unmain.c:370: for each function it appears in.) ls-unmain.c:372: `revacccmp' undeclared (first use in this function) ls-unmain.c:374: `revstatcmp' undeclared (first use in this function) ls-unmain.c:376: `revmodcmp' undeclared (first use in this function) ls-unmain.c:379: `namecmp' undeclared (first use in this function) ls-unmain.c:381: `acccmp' undeclared (first use in this function) ls-unmain.c:383: `statcmp' undeclared (first use in this function) ls-unmain.c:385: `modcmp' undeclared (first use in this function) ls-unmain.c:390: `printscol' undeclared (first use in this function) ls-unmain.c:392: `printlong' undeclared (first use in this function) ls-unmain.c:394: `printcol' undeclared (first use in this function) ls-unmain.c: In function `mastercmp': ls-unmain.c:750: `namecmp' used prior to declaration *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 1 error -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken in lukemftpd
From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Fri, 01 Mar 2002 15:07:48 +0100 /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:324: size of ar ray `remotehost' has non-integer type /flat/src/libexec/lukemftpd/../../contrib/lukemftpd/src/extern.h:327: syntax err or before `transflag' ... Confirmed. Looks as if setjmp.h (at least) was intended to have been #included (somehow), but wasn't. It's #included by contrib/lukemftpd/lukemftpd.h, but lukemftpd.h doesn't seem to be #included from anything in ls-unmain.c. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I believe it would be irresponsible (and thus, unethical) for me to advise, recommend, or support the use of any product that is or depends on any Microsoft product for any purpose other than personal amusement. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CD-ROM installation of -CURRENT broken?
On Wed, 19 Dec 2001, Brian Fundakowski Feldman wrote: Does anyone know when installation of -CURRENT from CD-ROM got broken or a solution thereof? We end up having two problems: the fixit shell doesn't work, but before that an actual installation doesn't work because sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't determined yet why this could be; anyone have clues? The 'c' partition of acd0 devices was broken for the non-DEVFS case in rev.104 of atapi-cd.c. (The errno for this is ENXIO.) DEVFS is not in GENERIC and make release doesn't seem to add it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CD-ROM installation of -CURRENT broken?
Bruce Evans [EMAIL PROTECTED] wrote: On Wed, 19 Dec 2001, Brian Fundakowski Feldman wrote: Does anyone know when installation of -CURRENT from CD-ROM got broken or a solution thereof? We end up having two problems: the fixit shell doesn't work, but before that an actual installation doesn't work because sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't determined yet why this could be; anyone have clues? The 'c' partition of acd0 devices was broken for the non-DEVFS case in rev.104 of atapi-cd.c. (The errno for this is ENXIO.) DEVFS is not in GENERIC and make release doesn't seem to add it. Well, really, all we should care about is the devfs case since anything else is meant to be deprecated; I'd rather fix this at the source... DEVFS is no longer optional, so it is in GENERIC for certain. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CD-ROM installation of -CURRENT broken?
On Thu, 20 Dec 2001, Brian F. Feldman wrote: Bruce Evans [EMAIL PROTECTED] wrote: The 'c' partition of acd0 devices was broken for the non-DEVFS case in rev.104 of atapi-cd.c. (The errno for this is ENXIO.) DEVFS is not in GENERIC and make release doesn't seem to add it. Well, really, all we should care about is the devfs case since anything else is meant to be deprecated; I'd rather fix this at the source... DEVFS is no longer optional, so it is in GENERIC for certain. Oops, DEVFS is in GENERIC, but not because it isn't optional. It is controlled by a bogus negative option (NODEVFS). The NODEVFS case has rotted a bit, but it isn't as broken as DEVFS yet. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
CD-ROM installation of -CURRENT broken?
Does anyone know when installation of -CURRENT from CD-ROM got broken or a solution thereof? We end up having two problems: the fixit shell doesn't work, but before that an actual installation doesn't work because sysinstall's attempt to mount /dev/acd0c on /dist returns ENOENT. I havne't determined yet why this could be; anyone have clues? -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current broken ?
Niels Chr. Bank-Pedersen [EMAIL PROTECTED] writes: On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote: The 'make buildworld' stops while doing the 'make depend'-stage in the usr.sbin/keyserv/ directory with an 'Error 2' . Sources 2h old , current system 24h. I think the breakage is actually pam related and occurs in usr.bin/login: This has been fixed. I didn't catch it in pre-commit tests due to source tree pollution. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
current broken ?
The 'make buildworld' stops while doing the 'make depend'-stage in the usr.sbin/keyserv/ directory with an 'Error 2' . Sources 2h old , current system 24h. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current broken ?
On Thu, Dec 06, 2001 at 02:26:31AM +0100, Martin Heller wrote: The 'make buildworld' stops while doing the 'make depend'-stage in the usr.sbin/keyserv/ directory with an 'Error 2' . Sources 2h old , current system 24h. I think the breakage is actually pam related and occurs in usr.bin/login: === usr.bin/login cd /usr/src/usr.sbin/gifconfig; make _EXTRADEPEND echo gifconfig: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === usr.sbin/ifmcstat rm -f .depend mkdep -f .depend -a-DLOGIN_ACCESS -DLOGALL -I/usr/obj/usr/src/i386/usr/include /usr/src/usr.bin/login/login.c /usr/src/usr.bin/login/login_access.c / usr/src/usr.bin/login/login_fbtab.c cd /usr/src/gnu/usr.bin/cc/c++filt; make _EXTRADEPEND rm -f .depend mkdep -f .depend -a-I/usr/obj/usr/src/i386/usr/include /usr/src/usr.sbin/ifmcstat/ifmcstat.c echo c++filt: /usr/obj/usr/src/i386/usr/lib/libc.a .depend === gnu/usr.bin/cc/doc In file included from /usr/src/usr.bin/login/login.c:78: /usr/obj/usr/src/i386/usr/include/security/pam_misc.h:10: security/pam_client.h: No such file or directory cd /usr/src/usr.sbin/ifmcstat; make _EXTRADEPEND echo ifmcstat: /usr/obj/usr/src/i386/usr/lib/libc.a /usr/obj/usr/src/i386/usr/lib/libkvm.a .depend === usr.sbin/inetd === gnu/usr.bin/cc/cc1obj mkdep: compile failed *** Error code 1 1 error *** Error code 2 1 error *** Error code 2 It appears that pam_client.h isn't pulled in from libpamc/include/security /Niels Chr. -- Niels Christian Bank-Pedersen, NCB1-RIPE. Hey, are any of you guys out there actually *using* RFC 2549? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: current broken ?
My log is: === usr.bin/login rm -f .depend mkdep -f .depend -a-DLOGIN_ACCESS -DLOGALL -I/usr/obj/usr/src/i386/usr/include /usr/src/usr.bin/login/login.c /usr/src/usr.bin/login/login_access.c /usr/src/usr.bin/login/login_fbtab.c In file included from /usr/src/usr.bin/login/login.c:78: /usr/obj/usr/src/i386/usr/include/security/pam_misc.h:10: security/pam_client.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/login. -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken in pcic_pci.c
Hi, Version 1.83 of that file breaks the GENERIC build. You probably meant to write: Index: pcic_pci.c === RCS file: /usr/ncvs/src/sys/pccard/pcic_pci.c,v retrieving revision 1.83 diff -r1.83 pcic_pci.c 262c262 if (sc-csc_intr == pcic_iw_pci || sc-func_intr == pcic_iw_pci) --- if (sc-csc_route == pcic_iw_pci || sc-func_route == pcic_iw_pci) harti -- harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken in pcic_pci.c
In message [EMAIL PROTECTED] Harti Brandt writes: : Version 1.83 of that file breaks the GENERIC build. You probably meant to : write: Just fixed. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken ?
Poul-Henning Kamp [EMAIL PROTECTED] wrote: === usr.bin/fetch /flat/src/usr.bin/fetch/fetch.c: In function `main': /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function) Noticed this in my `make release' attempt yesterday, too. -- cheers, Jorg .-.-. --... ...-- -.. . DL8DTL http://www.sax.de/~joerg/NIC: JW11-RIPE Never trust an operating system you don't have sources for. ;-) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -current broken ?
On Mon, 28 May 2001 21:45:02 +0200, Joerg Wunsch wrote: === usr.bin/fetch /flat/src/usr.bin/fetch/fetch.c: In function `main': /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function) Noticed this in my `make release' attempt yesterday, too. Fixed in rev 1.30 of fetch.c. Ciao, Sheldon. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken ?
=== usr.bin/fetch cc -O -pipe -Wall -pedantic -I/usr/obj/flat/src/i386/usr/include -c /flat/src/usr.bin/fetch/fetch.c gzip -cn /flat/src/usr.bin/fetch/fetch.1 fetch.1.gz /flat/src/usr.bin/fetch/fetch.c: In function `stat_display': /flat/src/usr.bin/fetch/fetch.c:131: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:134: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c: In function `stat_end': /flat/src/usr.bin/fetch/fetch.c:173: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c: In function `fetch': /flat/src/usr.bin/fetch/fetch.c:301: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:339: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:339: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:358: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:361: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:394: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:394: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:509: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c:509: warning: ANSI C does not support the `ll' length modifier /flat/src/usr.bin/fetch/fetch.c: In function `main': /flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function) /flat/src/usr.bin/fetch/fetch.c:757: (Each undeclared identifier is reported only once /flat/src/usr.bin/fetch/fetch.c:757: for each function it appears in.) *** Error code 1 1 error -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken at /usr/src/usr.sbin/sysinstall/keymap.c
This is supposed to be a reply to Mathew D. Fuller Yeah, I've the same problem with building the -current, so you aren't alone.Unfortunelly, I haven't managed to sort it out yes. I just wonder what's your start point, because I'm trying to update an 4.3STABLE machine, what about yours? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT broken in gnu/usr.bin/perl/perl
On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote: Just glanced through cvs-all; didn't see commits more recent than my last CVSup: CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001 Did you do another buildworld between these CVSup's? CVSup started from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 The suspected commit is [EMAIL PROTECTED] It looks like the recent BSDPAN change has a problem - I am looking into it. The error occurred during stage 4: make dependencies: === gnu/usr.bin/perl/libperl === gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 Hmm SelfLoader.pm was last modified: m133[3] ls -l SelfLoader.pm -rw-rw-r-- 1 david wheel 12043 Jun 25 2000 SelfLoader.pm It's at revision 1.1 Hmmm..., Cheers, +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT broken in gnu/usr.bin/perl/perl
Date: Wed, 2 May 2001 18:28:18 +0200 From: Anton Berezin [EMAIL PROTECTED] CVSup started from cvsup14.freebsd.org at Tue May 1 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Tue May 1 03:55:45 PDT 2001 Did you do another buildworld between these CVSup's? CVSup started from cvsup14.freebsd.org at Wed May 2 03:47:00 PDT 2001 CVSup ended from cvsup14.freebsd.org at Wed May 2 03:53:01 PDT 2001 Yes. Built OK; seemed to run OK (though I mostly run -STABLE on the box). The suspected commit is [EMAIL PROTECTED] It looks like the recent BSDPAN change has a problem - I am looking into it. OK; thanks! Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: -CURRENT broken in gnu/usr.bin/perl/perl
On Wed, May 02, 2001 at 06:28:18PM +0200, Anton Berezin wrote: On Wed, May 02, 2001 at 08:27:36AM -0700, David Wolfskill wrote: It looks like the recent BSDPAN change has a problem - I am looking into it. The error occurred during stage 4: make dependencies: === gnu/usr.bin/perl/libperl === gnu/usr.bin/perl/perl Extracting config.h (with variable substitutions) Extracting cflags (with variable substitutions) Extracting writemain (with variable substitutions) Extracting myconfig (with variable substitutions) Missing right curly or square bracket at lib/SelfLoader.pm line 69, at end of line syntax error at lib/SelfLoader.pm line 69, at EOF Compilation failed in require at /usr/libdata/perl/BSDPAN/BSDPAN/Override.pm line 17. Compilation failed in require at /usr/libdata/perl/BSDPAN/Config.pm line 37. BEGIN failed--compilation aborted at /usr/libdata/perl/BSDPAN/Config.pm line 37. Compilation failed in require at /usr/src/gnu/usr.bin/perl/perl/../../../../contrib/perl5/configpm line 430. *** Error code 255 Stop in /usr/src/gnu/usr.bin/perl/perl. *** Error code 1 The fix has been committed. Please also see a HEADS UP message on this list. Thanks, David, for reporting this. +Anton. -- May the tuna salad be with you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
-current broken, or am I?
Is it just me? ... === usr.bin/join cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/join/join .c cc -O -pipe-I/usr/obj/usr/src/i386/usr/include -o join join.o gzip -cn /usr/src/usr.bin/join/join.1 join.1.gz === usr.bin/jot cc -O -pipe -Wall -W -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/ jot/jot.c cc -O -pipe -Wall -W -I/usr/obj/usr/src/i386/usr/include -o jot jot.o gzip -cn /usr/src/usr.bin/jot/jot.1 jot.1.gz === usr.bin/kdump cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.bin/kdump/kdump.c cc -O -pipe -I/usr/src/usr.bin/kdump/../ktrace -I/usr/src/usr.bin/kdump/../.. -I/usr/obj/usr/src/i386/usr/include -c ioctl.c In file included from ioctl.c:96: /usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redef ined /usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the loc ation of the previous definition ioctl.c: In function `ioctlname': ioctl.c:528: sizeof applied to an incomplete type ioctl.c:904: sizeof applied to an incomplete type ioctl.c:1034: sizeof applied to an incomplete type ioctl.c:1882: syntax error before `;' *** Error code 1 Stop in /usr/src/usr.bin/kdump. *** Error code 1 Stop in /usr/src/usr.bin. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. -- Michael Lucas [EMAIL PROTECTED] http://www.blackhelicopters.org/~mwlucas/ Big Scary Daemons: http://www.oreillynet.com/pub/q/Big_Scary_Daemons To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken, or am I?
Date: Thu, 15 Mar 2001 15:52:45 -0500 From: Michael Lucas [EMAIL PROTECTED] Is it just me? [breakage elided -- dhw] Stop in /usr/src/usr.bin/kdump. *** Error code 1 Didn't happen for me; CVSup started at 23:47 yesterday, completed at Thu Mar 15 01:09:38 PST 2001. Built just fine; runs OK as far as I can tell. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] As a computing professional, I believe it would be unethical for me to advise, recommend, or support the use (save possibly for personal amusement) of any product that is or depends on any Microsoft product. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken, or am I?
It seems Andrzej Tobola wrote: Make that me too ... I diagnosed problem - sys/sys/ata.h commited by sos is probably the culprit: Its fixed, sorry, too many source trees here... -Sren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
HEADS UP: current broken for a while
I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: HEADS UP: current broken for a while
On 24-Jan-01 John Baldwin wrote: I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. Ok, it should be back to normal now. Sorry this took so long. Now I need to go take a long nap. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: current broken for a while
John Baldwin wrote: On 24-Jan-01 John Baldwin wrote: I'm committing another big wad of code that all depends on each other, so -current kernels are going to be broken for a while. I'll send another mail when it is back to working again. Ok, it should be back to normal now. Sorry this took so long. Now I need to go take a long nap. Normal - as in "It compiles". I would *strongly* caution anybody (even more so than usual) about using -current where a crash would be bad. A lot of new stuff went in and INVARIANTS and WITNESS are still finding some edge cases. The proc locking stuff is not yet finished, this part of the commit has the files with dependencies on changes in other files. There is more to come. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] "All of this is for nothing if we don't go to the stars" - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: current broken for a while
In message [EMAIL PROTECTED] Peter Wemm writes: : Normal - as in "It compiles". I would *strongly* caution anybody (even : more so than usual) about using -current where a crash would be bad. A lot : of new stuff went in and INVARIANTS and WITNESS are still finding some edge : cases. The proc locking stuff is not yet finished, this part of the commit : has the files with dependencies on changes in other files. There is more : to come. Will this new instability last long enough to warrant a note in UPDATING? Or is it a day or two sort of instability. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: possibly related data point - (was) Re: Current Broken!
On Thu, 7 Dec 2000 [EMAIL PROTECTED] wrote: I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . # make atomic.o cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs ... /usr/src/sys/i386/i386/atomic.c In file included from /usr/src/sys/i386/i386/atomic.c:48: machine/atomic.h: In function `atomic_set_char': machine/atomic.h:178: inconsistent operand constraints in an `asm' with any optimization, eg -O, there is _NO_ error. Makes me think the optimizer is optimizing out the offending contraints. Ouch. Probably not what was intended. Maybe this is what's biting you ? This is sort of the opposite of the bug in machine/mutex.h. It is believed to be caused by using the operand-number constraints (e.g., "(0)") to declare input-output operands in machine/atomic.h. Input-output operands and/or these constraints apparently never worked right until a recent versions of gcc introduced the "+" contraint to declare input-output operations properly. machine/atomic.h uses the new constraint. The problem seems to be that "+" contraints don't work right either. The following kludge fixes compilation of cam_periph.c: diff -c2 mutex.h~ mutex.h *** mutex.h~Sun Dec 10 19:28:53 2000 --- mutex.h Sun Dec 10 23:50:21 2000 *** *** 171,174 --- 176,180 \ __asm __volatile ( \ + " movl$" _V(MTX_UNOWNED) ",%%eax;"\ " " MPLOCKED "" \ " cmpxchgl %4,%0;"/* try easy rel */ \ *** *** 181,185 "# exitlock_norecurse"\ : "+m" (mtxp-mtx_lock),/* 0 */ \ ! "+a" (_tid) /* 1 */ \ : "gi" (type), /* 2 (input) */ \ "g" (mtxp), /* 3 */ \ --- 187,191 "# exitlock_norecurse"\ : "+m" (mtxp-mtx_lock),/* 0 */ \ ! "=a" (_tid) /* 1 */ \ : "gi" (type), /* 2 (input) */ \ "g" (mtxp), /* 3 */ \ This bug seems to have been encountered before -- I copied this inferior code from the function before the one that doesn't compile. Several other functions in machine/mutex.h also use it. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possibly related data point - (was) Re: Current Broken!
On Fri, 8 Dec 2000, John Baldwin wrote: On 08-Dec-00 [EMAIL PROTECTED] wrote: John, I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . Compiling a kernel with anything but -O for optimization is not supported. gcc has produced buggy code for the -O0 case in the past. -O0 (or plain cc without -O) is supposed to work, but no one cares enough about it to fix it every day. Fixing machine/atomic.h has been pending for many days now. My oldest saved mail about it is dated 21 July 2000, but ISTR discussing it last year. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possibly related data point - (was) Re: Current Broken!
On 08-Dec-00 [EMAIL PROTECTED] wrote: John, I'm not a constraints expert either, but I noticed that when I try to build a kernel WITHOUT any optimization, I get a failure in /usr/src/sys/i386/atomic.h . Compiling a kernel with anything but -O for optimization is not supported. gcc has produced buggy code for the -O0 case in the past. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possibly related data point - (was) Re: Current Broken!
I hit on it by accident (I normally compile with -O). That said, your claim that gcc with no optimization generates incorrect code is kind of counter-intuitive, wouldn't you say ? I think you missed my point, I was just illustrating that optimizer seems to affect (in my case apparently negate) the processing of constraints. What you take from that is up to you - I was just trying to be helpful :) Cheers, A. +-- | Andrew Atrens Nortel Networks, Ottawa, Canada. | | All opinions expressed are my own, not those of any employer. | --+ Berkeley had what we called "copycenter", which is "take it down to the copy center and make as many copies as you want". -- Kirk McKusick +----+ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current Locking up... Re: possibly related data point - (was) Re: Current Broken!
-CURRENT as of yesterday was still causing my system to lock (with 'make -j8 world'). Lock=no possibility of debugger. I have two of these systems and they behave identically. If someone with lots more debugging experience would benefit from borrowing one of the machines I'd happily send it to you. I'd really like to be use SMP stabily. -Steve - Original Message - From: "John Baldwin" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; "Andrew [SKY:ET95:EXCH]" [EMAIL PROTECTED] Sent: Friday, December 08, 2000 1:49 PM Subject: RE: possibly related data point - (was) Re: Current Broken! On 08-Dec-00 [EMAIL PROTECTED] wrote: I hit on it by accident (I normally compile with -O). That said, your claim that gcc with no optimization generates incorrect code is kind of counter-intuitive, wouldn't you say ? I've seen it do weird things with -O0 (mostly with C++). :) It's just another program. Nothing is keeping it from having bugs. :) I think you missed my point, I was just illustrating that optimizer seems to affect (in my case apparently negate) the processing of constraints. I am back now to thinking that it is a gcc bug in the -O case now as well. The constraings I removed were in fact valid, so I've put them back in, but just disabled the macros for now until gcc is fixed. What you take from that is up to you - I was just trying to be helpful :) Sorry if I came across as if I was biting your head off, that was not the intent. Cheers, A. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: possibly related data point - (was) Re: Current Broken!
On 08-Dec-00 [EMAIL PROTECTED] wrote: I hit on it by accident (I normally compile with -O). That said, your claim that gcc with no optimization generates incorrect code is kind of counter-intuitive, wouldn't you say ? I've seen it do weird things with -O0 (mostly with C++). :) It's just another program. Nothing is keeping it from having bugs. :) I think you missed my point, I was just illustrating that optimizer seems to affect (in my case apparently negate) the processing of constraints. I am back now to thinking that it is a gcc bug in the -O case now as well. The constraings I removed were in fact valid, so I've put them back in, but just disabled the macros for now until gcc is fixed. What you take from that is up to you - I was just trying to be helpful :) Sorry if I came across as if I was biting your head off, that was not the intent. Cheers, A. -- John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/ PGP Key: http://www.Baldwin.cx/~john/pgpkey.asc "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current Broken!
On 08-Dec-00 The Hermit Hacker wrote:
Just upgraded the kernel, rebooted and it hung/panic'd with:
panic: spin lock sched lock held by 0x0xc02a73el for 5 seconds
cpuid = 1; lapic.id = 0100
Debugger("panic")
I have DDB enabled, and ctl-alt-esc doesn't break to the debugger, so its
totally hung here ...
dual-cpu celeron, smp enabled ...
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
Yes. Something is broken with mutexes for the non-I386_CPU (and thus for SMP)
case in -current with the latest commit to i386/include/mutex.h. Of course,
you can revert that commit and then your kernel won't compile In the code
I've looked at so far, it looks like possibly a weird register allocation bug
in gcc and/or another weird nuance in the register constraints. In the
specific case I am looking at, the mtx_exit() of Giant in STOPEVENT in
syscall2() failed to properly release an unrecursed, uncontested Giant in
mtx_exit() and fell through to mtx_exit_hard(), which assumes that Giant is
either recursed or contested. When I disassembled the kernel and looked at the
code, gcc assumed that when it looked up curproc for the mtx_enter() operation
(which executed ok as far as I can tell), it could leave the value of curproc
cached in %edi _across_ the call to the stopevent() function. My only guess is
that %edi was clobbered during stopevent(), causing the cmpxchgl to fail, and
throwing the code into mtx_exit_hard() when it shouldn't have. :(
If anyone is an expert at register constraints, etc., please feel free to look
at the macros in src/sys/i386/include/mutex.h
--
John Baldwin [EMAIL PROTECTED] -- http://www.FreeBSD.org/~jhb/
PGP Key: http://www.baldwin.cx/~john/pgpkey.asc
"Power Users Use the Power to Serve!" - http://www.FreeBSD.org/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
possibly related data point - (was) Re: Current Broken!
ot; (*p), "ir" ( v ));
}
void atomic_set_long (volatile u_long *p, u_long v){
__asm volatile ("orl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_clear_long (volatile u_long *p, u_long v){
__asm volatile ("andl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}
void atomic_add_long (volatile u_long *p, u_long v){
__asm volatile ("addl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_subtract_long (volatile u_long *p, u_long v){
__asm volatile ("subl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
So there you have it. I'll step back now since I haven't done any x86
assembly since 1986 ... and this is readily reproduceable in -current.
Hope this helps,
Cheers,
Andrew.
On Thu, 7 Dec 2000, John Baldwin wrote:
Date: Thu, 07 Dec 2000 19:39:41 -0800 (PST)
From: John Baldwin [EMAIL PROTECTED]
To: The Hermit Hacker [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: Current Broken!
On 08-Dec-00 The Hermit Hacker wrote:
Just upgraded the kernel, rebooted and it hung/panic'd with:
panic: spin lock sched lock held by 0x0xc02a73el for 5 seconds
cpuid = 1; lapic.id = 0100
Debugger("panic")
I have DDB enabled, and ctl-alt-esc doesn't break to the debugger, so its
totally hung here ...
dual-cpu celeron, smp enabled ...
Marc G. Fournier ICQ#7615664 IRC Nick:
Scrappy
Systems Administrator @ hub.org
primary: [EMAIL PROTECTED] secondary:
scrappy@{freebsd|postgresql}.org
Yes. Something is broken with mutexes for the non-I386_CPU (and thus for SMP)
case in -current with the latest commit to i386/include/mutex.h. Of course,
you can revert that commit and then your kernel won't compile In the code
I've looked at so far, it looks like possibly a weird register allocation bug
in gcc and/or another weird nuance in the register constraints. In the
specific case I am looking at, the mtx_exit() of Giant in STOPEVENT in
syscall2() failed to properly release an unrecursed, uncontested Giant in
mtx_exit() and fell through to mtx_exit_hard(), which assumes that Giant is
either recursed or contested. When I disassembled the kernel and looked at the
code, gcc assumed that when it looked up curproc for the mtx_enter() operation
(which executed ok as far as I can tell), it could leave the value of curproc
cached in %edi _across_ the call to the stopevent() function. My only guess is
that %edi was clobbered during stopevent(), causing the cmpxchgl to fail, and
throwing the code into mtx_exit_hard() when it shouldn't have. :(
If anyone is an expert at register constraints, etc., please feel free to look
at the macros in src/sys/i386/include/mutex.h
--
+--
| Andrew Atrens Nortel Networks, Ottawa, Canada. |
| All opinions expressed are my own, not those of any employer. |
--+
Berkeley had what we called "copycenter", which is "take it down
to the copy center and make as many copies as you want".
-- Kirk McKusick
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote: Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. The build was broken by the inclusion of machine/mutex.h in sys/sys/mbuf.h rev 1.56. machine/mutex.h includes sys/sys/proc.h as of rev 1.7. sys/sys/proc.h includes sys/sys/callout.h and that's were it comes from. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Mon, Oct 02, 2000 at 02:24:12PM -0700, Mike Smith wrote: The build was silently broken by AMD including sys/mbuf.h previously. It wasn't exposed until recently. The correct fix was still to not include sys/mbuf.h anywhere in AMD (or anywhere else in userland for that matter). Yes I know. I was trying to figure out and explain why it was just now exposed. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, Oct 01, 2000 at 12:20:04AM -0500, Tony Johnson wrote: Run 4.0 or piss off... Tony, I suggest you apologise to Mr Choi for this extremely insulting message. Kris -- In God we Trust -- all others must submit an X.509 certificate. -- Charles Forsythe [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Run 4.0 or piss off... That's totally inappropriate. He's reporting a BUILD ERROR which is an occasional fact of life in -current and should be reported so that whomever broke AMD can go fix the build. He's also a developer of FreeBSD and simply reporting this to the other developers. I'm getting very tired of you, Tony. I think it's time for you to go off the air for awhile before all of us feel the same way. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
At 1 Oct 2000 04:24:14 GMT, CHOI Junho [EMAIL PROTECTED] wrote: I have cvsup'ed today, build stopped with the following error: I got same one, reported by my nightly buildworld failure. I think this happened between 9/30 00:00 JST and 10/1 00:00 JST... -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
In message [EMAIL PROTECTED] "Tony Johnson" writes: : Run 4.0 or piss off... Tony, this is an *UN*acceptible attitude. CHOI-san is reporting a problem. He didn't rail against anything, nor did he demand a fix. This is 100% acceptible. Your message, however, was rude and inappropriate. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, 01 Oct 2000 11:35:32 -0600, Warner Losh [EMAIL PROTECTED] said: Tony, this is an *UN*acceptible attitude. CHOI-san is reporting a problem. He didn't rail against anything, nor did he demand a fix. This is 100% acceptible. Your message, however, was rude and inappropriate. I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "It is dangerous to be right in matters on which the established authorities are wrong." -- Voltaire To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Mike Smith [EMAIL PROTECTED] wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. Thing is, I for one can't figure out what just changed. I've been manually following all the ways sys/callout.h would be included, and none seem to apply here. For example, sys/systm.h isn't included in any way I can tell by this amd file, and sys/callout.h isn't explicitly either. This is really annoying. So, sys/callout.h should be in #ifdef _KERNEL #endif /* _KERNEL */, but I just can't find out what broke it in the first place so I didn't want to fix anything. It would be nice to have the system Mozilla uses for this where we can pinpoint automatically what commit broke things. -- Brian Fundakowski Feldman \ FreeBSD: The Power to Serve! / [EMAIL PROTECTED]`--' To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. It wasn't clear to me if it was clashing with the internal typedef or something else - the namespace issues with gcc are a little unclear to me here (at least it's not VMS C, with a global member name space :). In any case, we can certainly revert the change if it transpires that the pollution came from elsewhere and for now, at least, -current is working again. clock.c includes a butt-load of system headers through am_defs.h and I can't immediately tell if the callout stuff is being exposed inappropriately or not. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. This commit also took a file off the vendor branch and the maintainer of src/contrib was not consulted. The committer that committed something w/o testing `make world' should have backed out their commit and then discussed that they wanted a change made in Amd or taken a different approach in their commit. -- -- David ([EMAIL PROTECTED]) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
This is better than watching the soaps. I'll be waiting anxiously for the next installment. ;) On Sun, 1 Oct 2000 12:47:16 -0700, "David O'Brien" [EMAIL PROTECTED] said: On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote: I hate to spoil the moment ... but does anyone have an idea what the fix is? g Nothing in the amd directory seems to have changed in the past couple of weeks, so it must be somewhere else, and I'm not bright enough to figure out where. Yeah, somebody forgot that typedefs and structure names can't conflict. :) I've just committed the fix. Er, this is probably the wrong fix. It sounds like the kernel 'callout' structure is ending up visible in userland, which it shouldn't. This commit also took a file off the vendor branch and the maintainer of src/contrib was not consulted. The committer that committed something w/o testing `make world' should have backed out their commit and then discussed that they wanted a change made in Amd or taken a different approach in their commit. -- -- David ([EMAIL PROTECTED]) -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] "Doing bad things is not evangelism." -- Ann Hafften To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
"WL" == Warner Losh [EMAIL PROTECTED] writes: WL this is an *UN*acceptible attitude. CHOI-san is reporting a -san is Japanese word, and I am Korean. Due to historical reason, most Korean do not want to be treated as Japanese and most of them will be angry. Please don't call me 'CHOI-san'. Equivalent word is '-nim' in Korean online community. But it should be after his given name, not surname. 'Junho-nim' is good, but you don't have to always. -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Today -current broken on build
I have cvsup'ed today, build stopped with the following error: === usr.sbin/amd/amd ... cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition of `struct callout' *** Error code 1 Stop in /usr/src/usr.sbin/amd/amd. *** Error code 1 -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: Today -current broken on build
Run 4.0 or piss off... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of CHOI Junho Sent: Saturday, September 30, 2000 11:22 PM To: [EMAIL PROTECTED] Subject: Today -current broken on build I have cvsup'ed today, build stopped with the following error: === usr.sbin/amd/amd ... cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/ src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.s bin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../. ./contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition of `struct callout' *** Error code 1 Stop in /usr/src/usr.sbin/amd/amd. *** Error code 1 -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Today -current broken on build
Run 4.0 or piss off... Actually, no. This message contains useful diagnostic information, and can be used to resolve the problem. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of CHOI Junho Sent: Saturday, September 30, 2000 11:22 PM To: [EMAIL PROTECTED] Subject: Today -current broken on build I have cvsup'ed today, build stopped with the following error: === usr.sbin/amd/amd ... cc -O -pipe -I/usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd -I. -I/usr/ src/usr.sbin/amd/amd -I/usr/src/usr.sbin/amd/amd/../include -I/usr/src/usr.s bin/amd/amd/../../../contrib/amd/include -I/usr/src/usr.sbin/amd/amd/../../. ./contrib/amd -DHAVE_CONFIG_H -I/usr/obj/usr/src/i386/usr/include -c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c /usr/src/usr.sbin/amd/amd/../../../contrib/amd/amd/clock.c:66: redefinition of `struct callout' *** Error code 1 Stop in /usr/src/usr.sbin/amd/amd. *** Error code 1 -- +++ Any opinions in this posting are my own and not those of my employers +++ CHOI Junho [EMAIL PROTECTED] [EMAIL PROTECTED] KFUG http://www.kr.FreeBSD.org Web Data Bank http://www.wdb.co.kr FreeBSD, GNU/Linux Developer http://people.FreeBSD.org/~cjh To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- ... every activity meets with opposition, everyone who acts has his rivals and unfortunately opponents also. But not because people want to be opponents, rather because the tasks and relationships force people to take different points of view. [Dr. Fritz Todt] V I C T O R Y N O T V E N G E A N C E To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current broken in ncurses ?
Am I the only one with this ? cc -O -pipe -I. -I/src/src/lib/libncurses -I/src/src/lib/libncurses/../../contrib/ncurses/ncurses -I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/net/nas/roberto/sidhe/src/src/i386/usr/include -c /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c -o comp_scan.o /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c: In function `_nc_get_token': /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: `_nc_disable_period' undeclared (first use in this function) /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: (Each undeclared identifier is reported only once /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: for each function it appears in.) *** Error code 1 Stop in /src/src/lib/libncurses. -- Ollivier ROBERT -=- Eurocontrol EEC/ITM -=- [EMAIL PROTECTED] The Postman hits! The Postman hits! You have new mail. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Current broken in ncurses ?
On Fri, 21 Jul 2000, Ollivier Robert wrote: Am I the only one with this ? cc -O -pipe -I. -I/src/src/lib/libncurses -I/src/src/lib/libncurses/../../contrib/ncurses/ncurses -I/src/src/lib/libncurses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CONFIG_H -DTERMIOS -I/net/nas/roberto/sidhe/src/src/i386/usr/include -c /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c -o comp_scan.o /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c: In function `_nc_get_token': /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: `_nc_disable_period' undeclared (first use in this function) /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: (Each undeclared identifier is reported only once /src/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/comp_scan.c:184: for each function it appears in.) *** Error code 1 Stop in /src/src/lib/libncurses. I just completed a make world here... try the usual cleaning /usr/obj and make cleandir in src and see if that helps. Good luck, Doug -- "Live free or die" - State motto of my ancestral homeland, New Hampshire Do YOU Yahoo!? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
-current broken?
Yesterday and today, after a cvsup and kernel build, I get a panic very early in the boot on my laptop. What's left on the screen is a general protection fault in kernel mode, and an attempt to trace just causes another panic. Tomorrow I will put a serial cable on it and get some details, but I'm guessing that this comes from the recent BUF_STRATEGY stuff, possibly breaking in the wd driver (which might be why there hasn't been a report yet if most everyone is using ata). I'm stuck with wd for the moment (pccard compact flash stuff), so if that's it and it hasn't been repaired by then, I'll dig into it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken?
I saw that yesterday, and fixed it by: cd /usr/src make includes cd /sys/i386/conf config -r CRITTER cd ../../compile/CRITTER make depend make In message [EMAIL PROTECTED], Christopher Masto writes: Yesterday and today, after a cvsup and kernel build, I get a panic very early in the boot on my laptop. What's left on the screen is a general protection fault in kernel mode, and an attempt to trace just causes another panic. Tomorrow I will put a serial cable on it and get some details, but I'm guessing that this comes from the recent BUF_STRATEGY stuff, possibly breaking in the wd driver (which might be why there hasn't been a report yet if most everyone is using ata). I'm stuck with wd for the moment (pccard compact flash stuff), so if that's it and it hasn't been repaired by then, I'll dig into it. -- Christopher Masto Senior Network Monkey NetMonger Communications [EMAIL PROTECTED][EMAIL PROTECTED]http://www.netmonger.net Free yourself, free your machine, free the daemon -- http://www.freebsd.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message -- Poul-Henning Kamp FreeBSD coreteam member [EMAIL PROTECTED] "Real hackers run -current on their laptop." FreeBSD -- It will take a long time before progress goes too far! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
