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
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
___
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
On 19 Jul, O'Connor, Daniel wrote:
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the
source tree isn't in /usr/src which makes this issue very strange
:-/
I've
On Sun, Jul 19, 2015 at 11:05:48PM -0700, Don Lewis wrote:
On 19 Jul, O'Connor, Daniel wrote:
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the
source tree
On 19 Jul 2015, at 02:56, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no
On Sat, 2015-07-18 at 10:26 -0700, Simon J. Gerraty wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no NFS) though I
O'Connor, Daniel dar...@dons.net.au wrote:
So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
Weird, I could have sworn I have set it on the command line and had it
work, but..
In most normal usage you will likely not notice a difference.
It is only when a makefile is
On 20 Jul 2015, at 04:29, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
But this did not..
make -j 8 buildworld MAKEOBJDIRPREFIX=/src/obj-amd64
Nor should it.
There are several makefiles in the tree that expect to be able to
change
O'Connor, Daniel dar...@dons.net.au wrote:
Yeah the subject is wrong (I just updated it).
I just did a build like so and it worked..
env MAKEOBJDIRPREFIX=/src/obj-amd64 make -j 8 buildworld
That's the right way to use it.
But this did not..
make -j 8 buildworld
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
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
On 20 Jul 2015, at 11:40, Simon J. Gerraty s...@juniper.net wrote:
O'Connor, Daniel dar...@dons.net.au wrote:
So, it seems MAKEOBJDIRPREFIX only works as an environmental variable
Weird, I could have sworn I have set it on the command line and had it
work, but..
In most normal usage
O'Connor, Daniel dar...@dons.net.au wrote:
However, Crochet _does_ build on the NFS client _and_ when the source
tree isn't in /usr/src which makes this issue very strange :-/
I've seen similar errors in rescue... (no NFS) though I cannot
quite recall the cause other than it seems very
On 18 Jul 2015, at 13:59, Tim Kientzle t...@kientzle.com wrote:
Crochet defaults MAKEOBJDIRPREFIX to ${WORKDIR}/obj if you have not already
set it to something else. (This avoids cross-polluting the builds if you do
regular manual cross-builds on the same machine.)
If you’re having
On Jul 16, 2015, at 9:57 PM, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
On 17 Jul 2015, at 14:27, O'Connor, Daniel dar...@dons.net.au wrote:
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The
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
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
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote:
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited
-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
-
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\
-
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
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
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
CURRENT, as of recent Revision 246285 (see below) fails and
crashes/reboots on an Ivy-Bridge platform (see below). Since the box
does not have debugging switched on (not yet, will do eventually
Monday), Last thing I see on screen is
p4tcc3: CPU Frequency Thermal Control on cpu3
then the system
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,
=== 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
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
-fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k
-Wno-uninitialized
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99
On 18.01.2013 22:37, David Wolfskill wrote:
On Fri, Jan 18, 2013 at 09:34:26PM +0300, Sergey V. Dyatko wrote:
On Fri, 18 Jan 2013 22:17:27 +0400
Andrey Chernov a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all)
cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote:
Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34
+0300:
On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov
a...@freebsd.org wrote:
=== usr.sbin/acpi/iasl (all) cc -O2 -pipe
this is the same problem as googled here:
http://groups.google.de/groups?hl=delr=ie=UTF-8oe=UTF-8frame=rightth=b2760f23e09bd704seekm=b21hoi%24b75%241%40ncc1701.cistron.net#link1
sysinstall does not like the partition table.
It does not like the geometry 119150/16/63 found by kernel.
My bios
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
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
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
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
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
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
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
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
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:
/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:
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
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
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
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,
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
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
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
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:
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:
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
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
Poul-Henning Kamp [EMAIL PROTECTED] wrote:
=== usr.bin/fetch
/flat/src/usr.bin/fetch/fetch.c: In function `main':
/flat/src/usr.bin/fetch/fetch.c:757: `vtty' undeclared (first use in this function)
Noticed this in my `make release' attempt yesterday, too.
--
cheers, Jorg
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
=== 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
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
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
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:
===
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
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
It seems Andrzej Tobola wrote:
Make that me too ...
I diagnosed problem - sys/sys/ata.h commited by sos is probably the culprit:
Its fixed, sorry, too many source trees here...
-Sren
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the
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:
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
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
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
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 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
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
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)
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 see
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
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
olatile 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), "
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
Er, this is probably the wrong fix. It sounds like the kernel 'callout'
structure is ending up visible in userland, which it shouldn't.
The build was broken by the inclusion of machine/mutex.h in
sys/sys/mbuf.h rev 1.56.
On Mon, Oct 02, 2000 at 02:24:12PM -0700, Mike Smith wrote:
The build was silently broken by AMD including sys/mbuf.h previously.
It wasn't exposed until recently. The correct fix was still to not
include sys/mbuf.h anywhere in AMD (or anywhere else in userland for
that matter).
Yes I
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
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
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] //
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.
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
I hate to spoil the moment ... but does anyone have an idea what the
fix is? g Nothing in the amd directory seems to have changed in the
past couple of weeks, so it must be somewhere else, and I'm not bright
enough to figure out where.
Yeah, somebody forgot that typedefs and structure names
I hate to spoil the moment ... but does anyone have an idea what the
fix is? g Nothing in the amd directory seems to have changed in the
past couple of weeks, so it must be somewhere else, and I'm not bright
enough to figure out where.
Yeah, somebody forgot that typedefs and structure
Mike Smith [EMAIL PROTECTED] wrote:
I hate to spoil the moment ... but does anyone have an idea what the
fix is? g Nothing in the amd directory seems to have changed in the
past couple of weeks, so it must be somewhere else, and I'm not bright
enough to figure out where.
Yeah,
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
On Sun, Oct 01, 2000 at 12:14:25PM -0700, Mike Smith wrote:
I hate to spoil the moment ... but does anyone have an idea what the
fix is? g Nothing in the amd directory seems to have changed in the
past couple of weeks, so it must be somewhere else, and I'm not bright
enough to figure
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
"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'.
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
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
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
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
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
Yesterday and today, after a cvsup and kernel build, I get a panic
very early in the boot on my laptop. What's left on the screen is a
general protection fault in kernel mode, and an attempt to trace just
causes another panic. Tomorrow I will put a serial cable on it and
get some details, but
I saw that yesterday, and fixed it by:
cd /usr/src
make includes
cd /sys/i386/conf
config -r CRITTER
cd ../../compile/CRITTER
make depend
make
In message [EMAIL PROTECTED], Christopher Masto writes:
Yesterday and today, after a cvsup and
98 matches
Mail list logo
