[CURRENT]: Broken ssh: Fssh_packet_write_wait: Connection to XXX.XXX.XXX.XXX port 22: Broken pipe

[O. Hartmann]

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

[Bryan Drewery]

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

[Outback Dingo]

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)

[Navdeep Parhar]

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)

[Don Lewis]

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)

[O'Connor, Daniel]

> 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)

[Simon J. Gerraty]

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)

[O'Connor, Daniel]

> 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)

[Simon J. Gerraty]

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

[Simon J. Gerraty]

> 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

[David Wolfskill]

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

[Ian Lepore]

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)

[O'Connor, Daniel]

> 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

[Simon J. Gerraty]

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

[O'Connor, Daniel]

> 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

[Tim Kientzle]

> 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

[O'Connor, Daniel]

> 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

[O'Connor, Daniel]

> 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

[Rick Macklem]

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"

-current broken when src is on NFS

[O'Connor, Daniel]

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: gcc in -current broken

[Pedro Giffuni]

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"

gcc in -current broken

[Michael Butler]

-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"

CURRENT: "broken pipe" / SIGNAL 13 / no X11 / OpenLDAP/nscd weirdness

[Hartmann, O.]

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?

[O. Hartmann]

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?

[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?

-- 
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"

CURRENT: Broken on > r246222?

[O. Hartmann]

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).

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=0xbfebfbff

Features2=0x3d9ae3bf
  AMD Features=0x28100800
  AMD Features2=0x1
  Standard Extended Features=0x281
  TSC: P-state invariant, performance statistics
real memory  = 17179869184 (16384 MB)
avail memory = 16221089792 (15469 MB)
Event timer "LAPIC" quality 600
ACPI APIC Table: 
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  irqs 0-23 on motherboard
kbd1 at kbdmux0
netmap: loaded module
ctl: CAM Target Layer loaded
smbios0:  at iomem 0xf04c0-0xf04de on motherboard
smbios0: Version: 2.7, BCD Revision: 2.7
cryptosoft0:  on motherboard
aesni0: No AESNI support.



signature.asc
Description: OpenPGP digital signature

-current broken on pre-PPro machines (w/ work around)

[John-Mark Gurney]

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"

Re: -current broken in acpi/iasl

[Jung-uk Kim]

-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

[Andrey Chernov]

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

[John-Mark Gurney]

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

[David Wolfskill]

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

[Sergey V. Dyatko]

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"

-current broken in acpi/iasl

[Andrey Chernov]

===> 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"

sysinstall on current broken with larger drives

[Fritz Heinrichmeyer]

this is the same problem as googled here:

http://groups.google.de/groups?hl=de&lr=&ie=UTF-8&oe=UTF-8&frame=right&th=b2760f23e09bd704&seekm=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

[Dag-Erling Smorgrav]

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

Re: Latest fetch on current broken

[Carl Schmidt]

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: Latest fetch on current broken

[Manfred Antar]

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

[Craig Rodrigues]

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

[Craig Rodrigues]

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

Latest fetch on current broken

[Manfred Antar]

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: dump on current broken -- master/slave protocol botched

[Manfred Antar]

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

Re: dump on current broken -- master/slave protocol botched

[David O'Brien]

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

dump on current broken -- master/slave protocol botched

[Manfred Antar]

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:  
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:  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:  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

Re: -current broken in lukemftpd

[David Wolfskill]

>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

-current broken in lukemftpd

[Poul-Henning Kamp]

/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: CD-ROM installation of -CURRENT broken?

[Bruce Evans]

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

Re: CD-ROM installation of -CURRENT broken?

[Brian F. Feldman]

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?

[Bruce Evans]

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

CD-ROM installation of -CURRENT broken?

[Brian Fundakowski Feldman]

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 ?

[Dag-Erling Smorgrav]

"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 ?

[Jun Kuriyama]

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 ?

[Niels Chr. Bank-Pedersen]

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

current broken ?

[Martin Heller]

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 in pcic_pci.c

[Warner Losh]

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

-current broken in pcic_pci.c

[Harti Brandt]

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 ?

[Sheldon Hearn]

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 ?

[Joerg Wunsch]

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

-current broken ?

[Poul-Henning Kamp]

===> 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

[Radoslav Vasilev]

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

[Anton Berezin]

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

[David Wolfskill]

>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

[Anton Berezin]

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

-CURRENT broken in gnu/usr.bin/perl/perl

[David Wolfskill]

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
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 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...,
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?

[Soren Schmidt]

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?

[Andrzej Tobola]

> 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?

[Michael Harnois]

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?

[Andrzej Toboła]

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?

[David Wolfskill]

>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

-current broken, or am I?

[Michael Lucas]

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: HEADS UP: current broken for a while

[Warner Losh]

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: HEADS UP: current broken for a while

[Peter Wemm]

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

[John Baldwin]

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

HEADS UP: current broken for a while

[John Baldwin]

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: possibly related data point - (was) Re: Current Broken!

[Bruce Evans]

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!

[Bruce Evans]

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!

[John Baldwin]

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!

[Steven E. Ames]

-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!

[atrens]

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!

[John Baldwin]

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!

[atrens]

quot;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){
__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

Current Broken!

[John Baldwin]

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

Re: Today -current broken on build

[David O'Brien]

On Mon, Oct 02, 2000 at 02:24:12PM -0700, Mike Smith wrote:
> 
> The build was silently broken by AMD including  previously.  
> It wasn't exposed until recently.  The correct fix was still to not 
> include  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

[Mike Smith]

The build was silently broken by AMD including  previously.  
It wasn't exposed until recently.  The correct fix was still to not 
include  anywhere in AMD (or anywhere else in userland for 
that matter).

> 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  in
> sys/sys/mbuf.h rev 1.56.   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])
> 

-- 
... 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

[David O'Brien]

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  in
sys/sys/mbuf.h rev 1.56.   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

[CHOI Junho]

> "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  Web Data Bank 
 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

[Michael Harnois]

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?  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

[David O'Brien]

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?  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

[Jordan Hubbard]

> 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

[Brian F. Feldman]

Mike Smith <[EMAIL PROTECTED]> wrote:
> > > I hate to spoil the moment ... but does anyone have an idea what the
> > > fix is?  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

[Mike Smith]

> > I hate to spoil the moment ... but does anyone have an idea what the
> > fix is?  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

[Jordan Hubbard]

> I hate to spoil the moment ... but does anyone have an idea what the
> fix is?  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

[Michael Harnois]

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?  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

[Warner Losh]

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

[Jun Kuriyama]

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

[Jordan Hubbard]

> 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

[Kris Kennaway]

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

[Mike Smith]

> 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

RE: Today -current broken on build

[Tony Johnson]

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

Today -current broken on build

[CHOI Junho]

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  Web Data Bank 
 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: Current broken in ncurses ?

[Doug Barton]

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