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 remot
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
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/li
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 w
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 error
> 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
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" t
> 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
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 sho
> 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 Da
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 f
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
> q
> 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
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 MAKEOBJDIRP
> 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
> 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 returni
> 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 e
> 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 a
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
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 -Wmissin
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/
-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/g
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
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 even
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 i
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 an
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
-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
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/ias
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-pro
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
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
===> 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/
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 bio
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 Smo
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 go
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
>>
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
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
ma
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
<
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/ns
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
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:
>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
/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: warni
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.
>
> W
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 install
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
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
de
"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
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:
/us
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/logi
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
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
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_
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.
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
===> 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
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 Unsubs
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
>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
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
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
CVSu
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 th
> 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 i
On Thu, 15 Mar 2001 23:53:29 +0100, Andrzej Toboła <[EMAIL PROTECTED]> said:
> NO. Exactly the same problem here.
Make that me too ...
--
Michael D. Harnois, Redeemer Lutheran Church, Washburn, IA
[EMAIL PROTECTED] [EMAIL PROTECTED]
I do not feel obliged to believe
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
>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 fi
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
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
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.
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
ne
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/pgpke
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 kern
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
> ...
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 jus
TED]>
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 optimizati
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) t
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.
ear_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"
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
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 tr
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
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
> "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 'CHO
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
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
> 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 le
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.
>
> > 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 st
> 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 name
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 inapp
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
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]>
> 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 ge
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 Unsubsc
0 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/us
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
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/
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 -DTERMIO
1 - 100 of 103 matches
Mail list logo
