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"
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 wrote: > >> > >> O'Connor, Daniel 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, O'Connor, Daniel wrote: > >> On 19 Jul 2015, at 02:56, Simon J. Gerraty wrote: >> >> O'Connor, Daniel 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 20 Jul 2015, at 11:40, Simon J. Gerraty wrote: > > O'Connor, Daniel 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 MAKEOBJDIRPREFIX is set (was: src is on NFS)
O'Connor, Daniel 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 wrote: > O'Connor, Daniel 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 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
> 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 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
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote: > O'Connor, Daniel 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)
> On 19 Jul 2015, at 02:56, Simon J. Gerraty wrote: > > O'Connor, Daniel 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
O'Connor, Daniel 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 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 wrote:
>
>
>> On 16 Jul 2015, at 21:41, Rick Macklem 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 wrote: >> On 16 Jul 2015, at 21:41, Rick Macklem 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"
Re: -current broken when src is on NFS
> On 16 Jul 2015, at 21:41, Rick Macklem 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"
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 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: 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
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: 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 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 >> 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=revision&revision=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"
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 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
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 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=revision&revision=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 Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote: > On Fri, 18 Jan 2013 22:17:27 +0400 > Andrey Chernov 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
On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov 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 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: 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
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
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 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 ?
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
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, J"org .-.-. --... ...-- -.. . 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 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
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 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, 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... -Søren To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken, or am I?
> Make that me too ...
I diagnosed problem - sys/sys/ata.h commited by sos is probably the culprit:
% make world
...
===> 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 ioctl.c
In file included from ioctl.c:98:
/usr/obj/usr/src/i386/usr/include/sys/memrange.h:18: warning: `MDF_ACTIVE' redefined
/usr/obj/usr/src/i386/usr/include/pccard/cardinfo.h:81: warning: this is the location
of the previous
+definition
ioctl.c: In function `ioctlname':
ioctl.c:530: sizeof applied to an incomplete type
ioctl.c:530:
< if (val == ATASSMART)
---
> if (val == ((unsigned long)( (0x8000 | 0x4000 ) | (( sizeof(
>struct ata_smart ) & 0x1fff
+) << 16) | (( ( 'a' ) ) << 8) | ( ( 10 ) ))) )
% fgrep -r ata_smart /usr/src
/usr/src/sys/sys/ata.h:#define ATAGSMART_IOWR('a', 9, struct ata_smart)
/usr/src/sys/sys/ata.h:#define ATASSMART_IOWR('a', 10, struct ata_smart)
cheers,
-a
On Thu, Mar 15, 2001 at 05:56:09AM -0800, Sřren Schmidt wrote:
> sos 2001/03/15 05:56:09 PST
>
> Added files:
> sys/sys ata.h
> Log:
> Add new ATA specific file, to be used with the upcoming atacontrol.
--
Andrzej Tobola Politechnika Warszawska, IETiME
http://iem.pw.edu.pl/~san Warsaw University of Technology
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current broken, or am I?
On Thu, 15 Mar 2001 23:53:29 +0100, Andrzej Toboła <[EMAIL PROTECTED]> said: > NO. Exactly the same problem here. Make that me too ... -- Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA [EMAIL PROTECTED] [EMAIL PROTECTED] I do not feel obliged to believe that the same God who has endowed us with sense, reason, and intellect has intended us to forgo their use. -- Galileo Galilei To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current broken, or am I?
On Thu, Mar 15, 2001 at 03:52:45PM -0500, Michael Lucas wrote: > Is it just me? NO. Exactly the same problem here. -a 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: 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 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 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 . It is believed to be caused by using the operand-number constraints (e.g., "(0)") to declare input-output operands in . 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. 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 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 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 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!
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
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
possibly related data point - (was) Re: Current Broken!
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 .
# make atomic.o
cc -c -O0 -pipe -Wall -Wredundant-decls -Wnested-externs
-Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline
-Wcast-qual -fformat-extensions -ansi -nostdinc -I- -I. -I/usr/src/sys
-I/usr/src/sys/../include
-I/usr/src/sys/contrib/dev/acpica/Subsystem/Include -D_KERNEL -include
opt_global.h -elf -mpreferred-stack-boundary=2 -fomit-frame-pointer
/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'
machine/atomic.h: In function `atomic_clear_char':
machine/atomic.h:179: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_char':
machine/atomic.h:180: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_char':
machine/atomic.h:181: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_short':
machine/atomic.h:183: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_short':
machine/atomic.h:184: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_short':
machine/atomic.h:185: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_short':
machine/atomic.h:186: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_int':
machine/atomic.h:188: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_int':
machine/atomic.h:189: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_int':
machine/atomic.h:190: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_int':
machine/atomic.h:191: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_set_long':
machine/atomic.h:193: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_clear_long':
machine/atomic.h:194: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_add_long':
machine/atomic.h:195: inconsistent operand constraints in an `asm'
machine/atomic.h: In function `atomic_subtract_long':
machine/atomic.h:196: inconsistent operand constraints in an `asm'
*** Error code 1
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 ?
I cut and pasted the cc command, inserted a -E, removed the #line
directives, and captured the offending lines - since my mailer doesn't
like really long lines, I've folded them - each function previously
occupied a single line.
void
atomic_set_char (volatile u_char *p, u_char v){
__asm volatile ( "orb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void
atomic_clear_char (volatile u_char *p, u_char v){
__asm volatile ( "andb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}
void
atomic_add_char (volatile u_char *p, u_char v){
__asm volatile ( "addb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void
atomic_subtract_char (volatile u_char *p, u_char v){
__asm volatile ("subb %b2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void
atomic_set_short (volatile u_short *p, u_short v){
__asm volatile ("orw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void
atomic_clear_short (volatile u_short *p, u_short v){
__asm volatile ("andw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}
void atomic_add_short (volatile u_short *p, u_short v){
__asm volatile ("addw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_subtract_short (volatile u_short *p, u_short v){
__asm volatile ("subw %w2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_set_int (volatile u_int *p, u_int v){
__asm volatile ("orl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_clear_int (volatile u_int *p, u_int v){
__asm volatile ("andl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( ~v ));
}
void atomic_add_int (volatile u_int *p, u_int v){
__asm volatile ("addl %2,%0" : "=m" (*p) : "0" (*p), "ir" ( v ));
}
void atomic_subtract_int (volatile u_int *p, u_int v){
__asm volatile ("subl %2,%0" : "=m" (*p) : "0" (*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
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
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
