Re: alpha tinderbox failure
On Thu, 2003-02-13 at 03:28, Dag-Erling Smorgrav wrote: === agp /h/des/src/sys/pci/agp_i810.c: In function `agp_i810_match': /h/des/src/sys/pci/agp_i810.c:112: `AGP_I85X_CAPID' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:112: (Each undeclared identifier is reported only once /h/des/src/sys/pci/agp_i810.c:112: for each function it appears in.) /h/des/src/sys/pci/agp_i810.c:113: `AGP_I855_GME' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:116: `AGP_I855_GM' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:119: `AGP_I852_GME' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:122: `AGP_I852_GM' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c: In function `agp_i810_attach': /h/des/src/sys/pci/agp_i810.c:342: `AGP_I855_GCC1' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:343: `AGP_I855_GCC1_GMS' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:344: `AGP_I855_GCC1_GMS_STOLEN_1M' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:347: `AGP_I855_GCC1_GMS_STOLEN_4M' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:350: `AGP_I855_GCC1_GMS_STOLEN_8M' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:353: `AGP_I855_GCC1_GMS_STOLEN_16M' undeclared (first use in this function) /h/des/src/sys/pci/agp_i810.c:356: `AGP_I855_GCC1_GMS_STOLEN_32M' undeclared (first use in this function) *** Error code 1 I'm very sorry about this, I committed only one of the two files. It should be fixed now. As a side note, do any of these AGP chipsets apply to sparc64, alpha, ia64? -- Eric Anholt[EMAIL PROTECTED] http://people.freebsd.org/~anholt/ [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Eric Anholt writes: As a side note, do any of these AGP chipsets apply to sparc64, alpha, ia64? The alpha UP1000 has an amd-751 chipset and should be able to use the amd agp module. I tried it shortly after it was brought into the tree a few years ago, and it locked the box solid. I was never motivated to debug it. That machine is now headless. I'd be quite happy, from a compile-time and disk-space perspective to have you not build these on alpha. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes: -- Kernel build for LINT started on Sun Jan 19 03:36:18 PST 2003 -- === vinum Makefile, line 4437: warning: duplicate script for target geom_bsd.o ignored /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer target type /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is not compiled with LINT cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant conversion *** Error code 1 Fixed. Peter fixed the same problem elsewhere, but must have missed this one. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
In message: [EMAIL PROTECTED] Kris Kennaway [EMAIL PROTECTED] writes: : On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote: : : === vinum : Makefile, line 4437: warning: duplicate script for target geom_bsd.o [...] : /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] : /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': : /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] : /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] : /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] : cc1: warnings being treated as errors : /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': : /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] : *** Error code 1 : : Am I the only one who thinks that the error message truncation makes : it difficult to see the error? Yes. At the very least we should also truncate the /h/des/src from the front which gives 10 more characters. However, even that might not be enough... Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Kris Kennaway [EMAIL PROTECTED] writes: Am I the only one who thinks that the error message truncation makes it difficult to see the error? You're right. I implemented truncation to avoid having ten lines turn into fifty due to very long gcc command lines, but I didn't think about error messages. I'll fix this ASAP. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Kris Kennaway [EMAIL PROTECTED] writes:
Am I the only one who thinks that the error message truncation makes
it difficult to see the error?
BTW, the complete log is always available in ~des/public_html (and
hence on the web: http://people.freebsd.org/~des/{alpha,i386}.log).
The full error message was:
=== vinum
Makefile, line 4437: warning: duplicate script for target geom_bsd.o ignored
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and
is not compiled with LINT
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from pointer
target type
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and
is not compiled with LINT
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is broken and is
not compiled with LINT
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe':
/h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit constant
conversion
*** Error code 1
Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1
Stop in /h/des/src.
*** Error code 1
Stop in /h/des/src.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote: === vinum Makefile, line 4437: warning: duplicate script for target geom_bsd.o [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] *** Error code 1 Am I the only one who thinks that the error message truncation makes it difficult to see the error? Kris msg50451/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
On 2003-01-17 16:24, Kris Kennaway [EMAIL PROTECTED] wrote: On Fri, Jan 17, 2003 at 04:16:14PM -0800, Dag-Erling Smorgrav wrote: === vinum Makefile, line 4437: warning: duplicate script for target geom_bsd.o [...] /h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...] /h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize': /h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...] /h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...] /h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...] cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_isa.c: In function `adv_isa_probe': /h/des/src/sys/dev/advansys/adv_isa.c:232: warning: overflow in implicit [...] *** Error code 1 Am I the only one who thinks that the error message truncation makes it difficult to see the error? I'm not a kernel hacker, so I might be a bit confused by this because of my lack of kernel foo, but it *is* a bit difficult to read. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 01:33:14AM -0800, David O'Brien wrote: Agreed. I'd love to hear from fanf what the changes are to unifdef that causes this change in exit code. I accidentally cocked up the exit codes in my first major revision of unifdef. It so happens that a few days later markm ripped out the Perl and Tcl support from vi, which meant that it started using unifdef in its build. The incorrect exit value happened to be 0 instead of 1 so things were happy until I restored the odd documented behaviour in my second major revision. Apologies for the disruption. I did check the uses of unifdef in the tree (including vi and telnet), but I didn't realise that ignored errors would cause problems. Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: WIND: VARIABLE OR NORTHEAST 2 OR 3. FAIR. GOOD. MODERATE. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
--
Kernel build for LINT started on Mon Jan 6 03:35:12 PST 2003
--
=== vinum
Makefile, line 4445: warning: duplicate script for target geom_bsd.o [...]
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver i [...]
/h/des/src/sys/dev/pdq/pdq.c: In function `pdq_initialize':
/h/des/src/sys/dev/pdq/pdq.c:1606: warning: cast discards qualifiers from [...]
/h/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver i [...]
/h/des/src/sys/pci/simos.c:30:2: warning: #warning The simos driver is b [...]
cc1: warnings being treated as errors
/h/des/src/sys/security/mac_lomac/mac_lomac.c: In function `mac_lomac_ass [...]
/h/des/src/sys/security/mac_lomac/mac_lomac.c:1070: warning: passing arg [...]
/h/des/src/sys/security/mac_lomac/mac_lomac.c:1081: warning: int format, [...]
*** Error code 1
These new truncated lines only make problems harder to solve.
Anyway, the problem is the 5th argument to vn_extattr_get() should be
an int *, but it's passing a size_t *. It looks like most consumers
of vn_extattr_get() would prefer a size_t *, so maybe the interface
should be changed.
This patch should resolve the problem without changing
vn_extattr_get()'s interface:
%%%
Index: mac_lomac.c
===
RCS file: /work/repo/src/sys/security/mac_lomac/mac_lomac.c,v
retrieving revision 1.6
diff -u -r1.6 mac_lomac.c
--- mac_lomac.c 10 Dec 2002 16:20:33 - 1.6
+++ mac_lomac.c 6 Jan 2003 15:53:02 -
@@ -49,6 +49,7 @@
#include sys/malloc.h
#include sys/mount.h
#include sys/proc.h
+#include sys/stdint.h
#include sys/systm.h
#include sys/sysproto.h
#include sys/sysent.h
@@ -1067,7 +1068,7 @@
bzero(temp, buflen);
error = vn_extattr_get(vp, IO_NODELOCKED, MAC_LOMAC_EXTATTR_NAMESPACE,
- MAC_LOMAC_EXTATTR_NAME, buflen, (char *)temp, curthread);
+ MAC_LOMAC_EXTATTR_NAME, (int *)buflen, (char *)temp, curthread);
if (error == ENOATTR || error == EOPNOTSUPP) {
/* Fall back to the fslabel. */
mac_lomac_copy_single(source, dest);
@@ -1077,8 +1078,9 @@
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
- printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
- buflen);
+ printf(
+ mac_lomac_associate_vnode_extattr: bad size %ju\n,
+ (uintmax_t)buflen);
return (EPERM);
}
bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Mon, 6 Jan 2003, Mike Barcroft wrote:
These new truncated lines only make problems harder to solve.
Anyway, the problem is the 5th argument to vn_extattr_get() should be an
int *, but it's passing a size_t *. It looks like most consumers of
vn_extattr_get() would prefer a size_t *, so maybe the interface should
be changed.
I think the problem originated because uio_resid is 'int', but iovec's
len is size_t. I agree the right answer is to use size_t as the argument
to vn_extattr_{get,set}(). Will that cause type problems with the resid
field, however?
Robert N M Watson FreeBSD Core Team, TrustedBSD Projects
[EMAIL PROTECTED] Network Associates Laboratories
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Mike Barcroft [EMAIL PROTECTED] writes:
@@ -1077,8 +1078,9 @@
if (buflen != sizeof(temp)) {
if (buflen != sizeof(temp) - sizeof(temp.ml_auxsingle)) {
- printf(mac_lomac_associate_vnode_extattr: bad size %d\n,
- buflen);
+ printf(
+ mac_lomac_associate_vnode_extattr: bad size %ju\n,
+ (uintmax_t)buflen);
return (EPERM);
}
bzero(temp.ml_auxsingle, sizeof(temp.ml_auxsingle));
Oops, I forgot we have %z in printf(9) now. That would obviously be
better.
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Gerhard Sittig [EMAIL PROTECTED] wrote: Although the above case is special from what I learnt in another message in this thread (I managed to delete it after seeing it so I cannot quote it here). ISTR that the non zero exit status comes from a tool with the following convention: 0 is absolutely OK, 1 is not perfect but still plausible enough to get accepted most of the time, and 2 is a real error, never OK. I believe that unifdef got its exit status values from diff. (The use of the word trouble in the DIAGNOSTICS section is indicative.) Tony. -- f.a.n.finch [EMAIL PROTECTED] http://dotat.at/ CAPE WRATH TO RATTRAY HEAD INCLUDING ORKNEY: VARIABLE 1 OR 2 LOCALLY 3 OR 4. ISOLATED WINTRY SHOWERS. MAINLY GOOD. MODERATE DECAYING SLIGHT. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 06:00:26PM +1100, Bruce Evans wrote: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis ... No; it would be more profitable to teach programmers to not ignore errors. whereintheworld is perfectly non-broken in not ignoring them. These *** Error messages (not to mention other error ouput from makeworld) also make it harder for human readers to see the actual errors. Agreed. I'd love to hear from fanf what the changes are to unifdef that causes this change in exit code. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, 2003/01/05 at 01:33:14 -0800, David O'Brien wrote:
On Sun, Jan 05, 2003 at 06:00:26PM +1100, Bruce Evans wrote:
=== usr.bin/vi
*** Error code 1 (ignored)
*** Error code 1 (ignored)
=== usr.bin/vis
..
No; it would be more profitable to teach programmers to not ignore errors.
whereintheworld is perfectly non-broken in not ignoring them. These
*** Error messages (not to mention other error ouput from makeworld)
also make it harder for human readers to see the actual errors.
Agreed. I'd love to hear from fanf what the changes are to unifdef that
causes this change in exit code.
According to the man page, this is the correct behaviour:
The unifdef utility exits 0 if the output is an exact copy of the input,
1 if not, and 2 if in trouble.
The exit status code in unifdef seems to have been broken before for a
while.
The vi Makefile just was sloppy in checking for the exit code; it
should probably check for 1 and exclude 0 also, like:
--- Makefile29 Jul 2002 09:40:16 - 1.38
+++ Makefile5 Jan 2003 13:20:49 -
@@ -75,10 +75,12 @@
# unifdef has some *weird* exit codes, sigh! RTFM unifdef(1)...
ex_notcl.c: ex_tcl.c
- -unifdef -UHAVE_TCL_INTERP ${SRCDIR}/ex/ex_tcl.c ${.TARGET}
+ ! { unifdef -UHAVE_TCL_INTERP ${SRCDIR}/ex/ex_tcl.c ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
ex_noperl.c: ex_perl.c
- -unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c ${.TARGET}
+ ! { unifdef -UHAVE_PERL_INTERP ${SRCDIR}/ex/ex_perl.c ${.TARGET} || \
+ [ $$? -ne 1 ] ; }
CLEANFILES+= ex_notcl.c ex_noperl.c
---
(there's probably a more elegant way to do this, my sh is a bit
rusty).
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Sun, Jan 05, 2003 at 18:00 +1100, Bruce Evans wrote: On Sat, 4 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Peter Wemm writes: No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. I think it would be more profitable to teach whereintheworld about the (ignored) string, wouldn't it ? No; it would be more profitable to teach programmers to not ignore errors. Amen! :] Although the above case is special from what I learnt in another message in this thread (I managed to delete it after seeing it so I cannot quote it here). ISTR that the non zero exit status comes from a tool with the following convention: 0 is absolutely OK, 1 is not perfect but still plausible enough to get accepted most of the time, and 2 is a real error, never OK. So the exit code of 1 is more of a warning than an error. Ignoring _any_ non zero exit status in the Makefile is an error. The rule should instead accept success and warning messages as success while bailing out on the errors. This can be done with shell syntax as I have seen in some small test: $ sh -c 'exit 0'; [ $? -le 1 ] $ echo $? 0 $ sh -c 'exit 1'; [ $? -le 1 ] $ echo $? 0 $ sh -c 'exit 2'; [ $? -le 1 ] $ echo $? 1 $ sh -c 'exit 3'; [ $? -le 1 ] $ echo $? 1 This means: adding the [ $? -le 1 ] test to the Makefile rule and *not* ignoring the command's (sequence's) exit status will prevent the acceptable warning from stopping the build while real errors do break the build as one would expect from make(1). And the mentioned tool (sorry, I don't remember its name) is still able to warn those who are interested (release builders?). virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s get gpg key [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Can someone please fix whereintheworld to grok the new make regression test output, so it doesn't get confused and dump the entire world output in the emails? Kris msg49629/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
Kris Kennaway wrote: --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can someone please fix whereintheworld to grok the new make regression test output, so it doesn't get confused and dump the entire world output in the emails? No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Fs2IWry0BWjoQKURAjkGAKDHg95MMoekBGd8JE9YiLJ6yZGMzgCff6zU 5p6oDcHQCz1j82XpAElV24w= =DfCz -END PGP SIGNATURE- --AhhlLboLdkugWU4S-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message 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: alpha tinderbox failure
Peter Wemm wrote: Kris Kennaway wrote: --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can someone please fix whereintheworld to grok the new make regression test output, so it doesn't get confused and dump the entire world output in the emails? No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. Specifically, unifdef has been changed and now causes this failure: unifdef -UHAVE_TCL_INTERP /home/src/usr.bin/vi/../../contrib/nvi/ex/ex_tcl.c ex_notcl.c *** Error code 1 (ignored) unifdef -UHAVE_PERL_INTERP /home/src/usr.bin/vi/../../contrib/nvi/ex/ex_perl.c ex_noperl.c *** Error code 1 (ignored) rm -f .depend The error codes were not there before. This is what is upsetting whereintheworld. Interestingly, unifdef is not being cross built and is being run from /usr/bin. There is a build tool missing here. Otherwise all the tinderbox builds would be doing this.. The ones (like ia64) that have a slightly older installed world are using the old unifdef binary from /usr/bin, which do not cause this error code. Kris --AhhlLboLdkugWU4S Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.6 (GNU/Linux) Comment: For info see http://www.gnupg.org iD8DBQE+Fs2IWry0BWjoQKURAjkGAKDHg95MMoekBGd8JE9YiLJ6yZGMzgCff6zU 5p6oDcHQCz1j82XpAElV24w= =DfCz -END PGP SIGNATURE- --AhhlLboLdkugWU4S-- To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message 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 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: alpha tinderbox failure
In message [EMAIL PROTECTED], Peter Wemm writes: Peter Wemm wrote: Kris Kennaway wrote: --AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Can someone please fix whereintheworld to grok the new make regression test output, so it doesn't get confused and dump the entire world output in the emails? No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. I think it would be more profitable to teach whereintheworld about the (ignored) string, wouldn't it ? -- 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: alpha tinderbox failure
On Sat, 4 Jan 2003 [EMAIL PROTECTED] wrote: In message [EMAIL PROTECTED], Peter Wemm writes: No, it isn't the regression tests. It is this here in the start of stage 4: === usr.bin/vi *** Error code 1 (ignored) *** Error code 1 (ignored) === usr.bin/vis As soon as 'whereintheworld' sees an 'error code', it starts dumping that entire block to the end. If you care to find and fix the build in vi, that would solve it. I think it would be more profitable to teach whereintheworld about the (ignored) string, wouldn't it ? No; it would be more profitable to teach programmers to not ignore errors. whereintheworld is perfectly non-broken in not ignoring them. These *** Error messages (not to mention other error ouput from makeworld) also make it harder for human readers to see the actual errors. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
According to Dag-Erling Smorgrav: Date: Wed, 1 Jan 2003 03:42:27 -0800 (PST) From: Dag-Erling Smorgrav [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: alpha tinderbox failure It is still generating multi-thousands mails, please fix des. -- Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED] FreeBSD keltia.freenix.fr 5.0-CURRENT #80: Sun Jun 4 22:44:19 CEST 2000 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
=== vinum
Makefile, line 4453: warning: duplicate script for target geom_bsd.o ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc':
/h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different type
arg (arg 5)
/h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg (arg
6)
/h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type
arg (arg 6)
/h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different type
arg (arg 7)
*** Error code 1
Proposed fix:
%%%
Index: isp_pci.c
===
RCS file: /work/repo/src/sys/dev/isp/isp_pci.c,v
retrieving revision 1.89
diff -u -r1.89 isp_pci.c
--- isp_pci.c 11 Oct 2002 17:28:01 - 1.89
+++ isp_pci.c 1 Jan 2003 14:56:25 -
@@ -1538,9 +1538,10 @@
cto-rsp.m0.ct_dataseg[cto-ct_seg_count].ds_count =
dm_segs[segcnt].ds_len;
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
- isp_prt(isp, ISP_LOGTDEBUG1, isp_send_ctio2: ent0[%d]0x%x:%d,
- cto-ct_seg_count, dm_segs[segcnt].ds_addr,
- dm_segs[segcnt].ds_len);
+ isp_prt(isp, ISP_LOGTDEBUG1,
+ isp_send_ctio2: ent0[%d]0x%lx:%lu,
+ cto-ct_seg_count, (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
}
while (segcnt nseg) {
@@ -1567,9 +1568,10 @@
crq-req_dataseg[seg].ds_base = dm_segs[segcnt].ds_addr;
crq-req_dataseg[seg].ds_count = dm_segs[segcnt].ds_len;
isp_prt(isp, ISP_LOGTDEBUG1,
- isp_send_ctio2: ent%d[%d]%x:%u,
+ isp_send_ctio2: ent%d[%d]%lx:%lu,
cto-ct_header.rqs_entry_count-1, seg,
- dm_segs[segcnt].ds_addr, dm_segs[segcnt].ds_len);
+ (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
cto-ct_seg_count++;
}
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
I already know this- I just hadn't checked it in a change because I was
trying to get one of my alphas current. Sam Leffler brought it to my
attention the other day.
This is for LINT, btw.
Also- is casting to 'long' for bus_addr_t and bus_size_t the best idea?
Shouldn't it be cast to the maximum width integer (long long)?
-matt
On Wed, 1 Jan 2003, Mike Barcroft wrote:
Dag-Erling Smorgrav [EMAIL PROTECTED] writes:
=== vinum
Makefile, line 4453: warning: duplicate script for target geom_bsd.o ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/isp/isp_pci.c: In function `tdma_mkfc':
/h/des/src/sys/dev/isp/isp_pci.c:1543: warning: unsigned int format, different
type arg (arg 5)
/h/des/src/sys/dev/isp/isp_pci.c:1543: warning: int format, different type arg
(arg 6)
/h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different
type arg (arg 6)
/h/des/src/sys/dev/isp/isp_pci.c:1572: warning: unsigned int format, different
type arg (arg 7)
*** Error code 1
Proposed fix:
%%%
Index: isp_pci.c
===
RCS file: /work/repo/src/sys/dev/isp/isp_pci.c,v
retrieving revision 1.89
diff -u -r1.89 isp_pci.c
--- isp_pci.c 11 Oct 2002 17:28:01 - 1.89
+++ isp_pci.c 1 Jan 2003 14:56:25 -
@@ -1538,9 +1538,10 @@
cto-rsp.m0.ct_dataseg[cto-ct_seg_count].ds_count =
dm_segs[segcnt].ds_len;
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
- isp_prt(isp, ISP_LOGTDEBUG1, isp_send_ctio2: ent0[%d]0x%x:%d,
- cto-ct_seg_count, dm_segs[segcnt].ds_addr,
- dm_segs[segcnt].ds_len);
+ isp_prt(isp, ISP_LOGTDEBUG1,
+ isp_send_ctio2: ent0[%d]0x%lx:%lu,
+ cto-ct_seg_count, (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
}
while (segcnt nseg) {
@@ -1567,9 +1568,10 @@
crq-req_dataseg[seg].ds_base = dm_segs[segcnt].ds_addr;
crq-req_dataseg[seg].ds_count = dm_segs[segcnt].ds_len;
isp_prt(isp, ISP_LOGTDEBUG1,
- isp_send_ctio2: ent%d[%d]%x:%u,
+ isp_send_ctio2: ent%d[%d]%lx:%lu,
cto-ct_header.rqs_entry_count-1, seg,
- dm_segs[segcnt].ds_addr, dm_segs[segcnt].ds_len);
+ (unsigned long)dm_segs[segcnt].ds_addr,
+ (unsigned long)dm_segs[segcnt].ds_len);
cto-rsp.m0.ct_xfrlen += dm_segs[segcnt].ds_len;
cto-ct_seg_count++;
}
%%%
Best regards,
Mike Barcroft
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Wed, Nov 27, 2002 at 03:42:01AM -0800, Dag-Erling Smorgrav wrote: -- Kernel build for LINT started on Wed Nov 27 03:35:42 PST 2002 -- === vinum Makefile, line 4450: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/cardbus/cardbus.c: In function `cardbus_read_ivar': /h/des/src/sys/dev/cardbus/cardbus.c:954: warning: suggest parentheses around comparison in operand of *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 We're certainly progressing here! :-) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg47604/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
On Fri, Nov 22, 2002 at 01:02:36PM -0800, Dag-Erling Smorgrav wrote: Fri Nov 22 13:00:03 PST 2002 ... U lib/libpthread/arch/i386/i386/thr_enter_uts.S U lib/libpthread/arch/i386/i386/thr_switch.S U release/scripts/print-cdrom-packages.sh U share/man/man5/make.conf.5 ? sys/alpha/conf/LINT U sys/boot/forth/loader.conf U sys/dev/acpica/acpi_pcib_acpi.c U sys/dev/pci/pci_pci.c U sys/dev/pci/pcib_private.h cvs [update aborted]: cannot make directory include: File exists Same fix needed..remove and check out tree again to fix breakage from the failed initial bluetooth import. Kris msg47250/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
On Friday, 15 November 2002 at 12:05:22 -0800, Archie Cobbs wrote: Dag-Erling Smorgrav wrote: === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 I'm getting tired of this email. Any objections to the patch below? This may happen during the build of Vinum, but it's nothing really to do with Vinum. As such, I don't object :-) But it seems that others have issues, and I won't comment on them. Greg -- See complete headers for address and phone numbers To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav wrote:
=== vinum
Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in':
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format,
different type arg (arg 2)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out':
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
different type arg (arg 2)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
different type arg (arg 4)
/h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format,
different type arg (arg 5)
*** Error code 1
I'm getting tired of this email. Any objections to the patch below?
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
Index: aic79xx_osm.c
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx_osm.c,v
retrieving revision 1.3
diff -u -r1.3 aic79xx_osm.c
--- aic79xx_osm.c 31 Aug 2002 06:51:15 - 1.3
+++ aic79xx_osm.c 15 Nov 2002 20:01:24 -
@@ -1927,7 +1927,7 @@
if (count = 0)
count = 1;
while (--count = 0) {
- db_printf(%04x (M)%x: \t, addr,
+ db_printf(%04lx (M)%x: \t, (u_long)addr,
ahd_inb(ahd_ddb_softc, MODE_PTR));
switch (size) {
case 1:
@@ -1986,9 +1986,9 @@
ahd_outl(ahd_ddb_softc, addr, new_value);
break;
}
- db_printf(%04x (M)%x: \t0x%x\t=\t0x%x,
- addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
- old_value, new_value);
+ db_printf(%04lx (M)%x: \t0x%lx\t=\t0x%lx,
+ (u_long)addr, ahd_inb(ahd_ddb_softc, MODE_PTR),
+ (u_long)old_value, (u_long)new_value);
addr += size;
}
db_skip_to_eol();
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Fri, 15 Nov 2002, Archie Cobbs wrote: Dag-Erling Smorgrav wrote: === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] On Fri, 15 Nov 2002, Archie Cobbs wrote: Dag-Erling Smorgrav wrote: === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Fri, 15 Nov 2002, Juli Mallett wrote: * De: Nate Lawson [EMAIL PROTECTED] [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] On Fri, 15 Nov 2002, Archie Cobbs wrote: Dag-Erling Smorgrav wrote: === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? WERROR= you mean. :) -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
* De: Nate Lawson [EMAIL PROTECTED] [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? WERROR= you mean. :) No, I'm referring to a flag in the files list to not include the WERROR var in that file's compilation line. -- Juli Mallett [EMAIL PROTECTED] OpenDarwin, Mono, FreeBSD Developer. ircd-hybrid Developer, EFnet addict. FreeBSD on MIPS-Anything on FreeBSD. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On 15-Nov-2002 Nate Lawson wrote: On Fri, 15 Nov 2002, Juli Mallett wrote: * De: Nate Lawson [EMAIL PROTECTED] [ Data: 2002-11-15 ] [ Subjecte: Re: alpha tinderbox failure ] On Fri, 15 Nov 2002, Archie Cobbs wrote: Dag-Erling Smorgrav wrote: === vinum Makefile, line 4441: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_in': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1931: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c: In function `ahd_ddb_out': /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 2) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx_osm.c:1991: warning: unsigned int format, different type arg (arg 5) *** Error code 1 I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? WERROR= you mean. :) He means 'nowerror' in sys/conf/files FWIW, the correct patch would be to use %j and uintmax_t, not longs. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: alpha tinderbox failure
On Fri, 15 Nov 2002, John Baldwin wrote: He means 'nowerror' in sys/conf/files Since this doesn't generate errors on i386, would it be counterproductive to put it in the global files? FWIW, the correct patch would be to use %j and uintmax_t, not longs. I believe this was not done due to Linux compat issues but I'm not sure. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On 15-Nov-2002 Nate Lawson wrote: On Fri, 15 Nov 2002, John Baldwin wrote: He means 'nowerror' in sys/conf/files Since this doesn't generate errors on i386, would it be counterproductive to put it in the global files? Yes. Hence it has not been done. FWIW, the correct patch would be to use %j and uintmax_t, not longs. I believe this was not done due to Linux compat issues but I'm not sure. C99 is a bit recent I guess. We just started supporting it ourselves. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: alpha tinderbox failure
On Fri, Nov 15, 2002 at 04:43:16PM -0500, John Baldwin wrote: On 15-Nov-2002 Nate Lawson wrote: On Fri, 15 Nov 2002, John Baldwin wrote: He means 'nowerror' in sys/conf/files Since this doesn't generate errors on i386, would it be counterproductive to put it in the global files? Yes. Hence it has not been done. FWIW, the correct patch would be to use %j and uintmax_t, not longs. I believe this was not done due to Linux compat issues but I'm not sure. C99 is a bit recent I guess. We just started supporting it ourselves. Guys, We understand this problem and apologize for not addressing it yet. As many of you know, we are coming off of a highly compressed and stressful developemnt cycle and just haven't had the time to push out fixes for this and many other things. Our plan is to address these driver next week. If you can't wait until then, just go ahead and disconnect the drivers from the alpha tinderbox and move on. As was pointed out though, this is only the tip of the iceberg of warnings in /sys/dev. Scott -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: alpha tinderbox failure
John Baldwin wrote: I'm getting tired of this email. Any objections to the patch below? aic7xxx is vendor-supported and changing it takes it off their p4 branch. I think gibbs@ has some patches to fix this but there are many more problems in other drivers that follow it in the build. DES, can you take LINT out temporarily from the alpha tinderbox? Can't that file just be marked nowerror for now? WERROR= you mean. :) He means 'nowerror' in sys/conf/files FWIW, the correct patch would be to use %j and uintmax_t, not longs. Thanks, I've adjusted the patch to use %jx and uintmax_t instead, in case we still want to commit it. I'll leave it uncommitted until there is general agreement to do so. Thanks, -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Wednesday 13 November 2002 22.57, Dag-Erling Smorgrav wrote: === lib/libc /h/des/src/lib/libc/gen/_pthread_stubs.c:59: conflicting types for `__thr_jtable' /h/des/src/lib/libc/include/libc_private.h:106: previous declaration of `__thr_jtable' *** Error code 1 Stop in /h/des/src/lib/libc. *** Error code 1 Hi, I have the exact same problem on an i386. Checked out the source yesterday (20021113). //David Holm To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, 14 Nov 2002, David Holm wrote: On Wednesday 13 November 2002 22.57, Dag-Erling Smorgrav wrote: === lib/libc /h/des/src/lib/libc/gen/_pthread_stubs.c:59: conflicting types for `__thr_jtable' /h/des/src/lib/libc/include/libc_private.h:106: previous declaration of `__thr_jtable' *** Error code 1 Stop in /h/des/src/lib/libc. *** Error code 1 Hi, I have the exact same problem on an i386. Checked out the source yesterday (20021113). These should be fixed. There was a period fo a couple of hours where it was broke. I did a buildworld on beast earlier and it worked. cvsup and try again. Let me know if it doesn't work. -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, Nov 07, 2002 at 03:40:27AM -0800, Dag-Erling Smorgrav wrote:
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different
type arg (arg 3)
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different
type arg (arg 4)
/h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata':
/h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different
type arg (arg 3)
Since I've seen this particular error at least 10 times and it is
getting boring, here's an untested patch. Note that it requires the
currently latest version 1.90 of subr_prf.c. A '-' that should probably
be a '=' is fixed too.
Regards,
Stefan Farfeleder
Index: aic79xx.c
===
RCS file: /home/ncvs/src/sys/dev/aic7xxx/aic79xx.c,v
retrieving revision 1.4
diff -u -r1.4 aic79xx.c
--- aic79xx.c 26 Sep 2002 22:53:59 - 1.4
+++ aic79xx.c 7 Nov 2002 14:23:40 -
-4203,7 +4203,7
}
#ifdef AHD_DEBUG
if ((ahd_debug AHD_SHOW_MEMORY) != 0) {
- printf(%s: scb size = 0x%x, hscb size - 0x%x\n,
+ printf(%s: scb size = 0x%zx, hscb size = 0x%zx\n,
ahd_name(ahd), sizeof(struct scb),
sizeof(struct hardware_scb));
}
-4597,8 +4597,8
}
#ifdef AHD_DEBUG
if ((ahd_debug AHD_SHOW_MEMORY) != 0)
- printf(%s: ahd_sglist_allocsize = 0x%x\n, ahd_name(ahd),
- ahd_sglist_allocsize(ahd));
+ printf(%s: ahd_sglist_allocsize = 0x%llx\n, ahd_name(ahd),
+ (unsigned long long)ahd_sglist_allocsize(ahd));
#endif
scb_data-init_level++;
Re: alpha tinderbox failure
On Thu, Nov 07, 2002 at 04:22:07PM +0100, Stefan Farfeleder wrote: On Thu, Nov 07, 2002 at 03:40:27AM -0800, Dag-Erling Smorgrav wrote: /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_alloc': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 3) /h/des/src/sys/dev/aic7xxx/aic79xx.c:4208: warning: unsigned int format, different type arg (arg 4) /h/des/src/sys/dev/aic7xxx/aic79xx.c: In function `ahd_init_scbdata': /h/des/src/sys/dev/aic7xxx/aic79xx.c:4601: warning: unsigned int format, different type arg (arg 3) Since I've seen this particular error at least 10 times and it is getting boring, here's an untested patch. Note that it requires the currently latest version 1.90 of subr_prf.c. A '-' that should probably be a '=' is fixed too. As I've told others, this file is shared with the Linux version of the driver, so any changes must be compatible with Linux printk(). We'll have a proper fix in the next code drop of this driver. Also, why does the '=' need to be changed to '-' ? Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, Nov 07, 2002 at 08:28:30AM -0700, Scott Long wrote: On Thu, Nov 07, 2002 at 04:22:07PM +0100, Stefan Farfeleder wrote: Since I've seen this particular error at least 10 times and it is getting boring, here's an untested patch. Note that it requires the currently latest version 1.90 of subr_prf.c. A '-' that should probably be a '=' is fixed too. As I've told others, this file is shared with the Linux version of the driver, so any changes must be compatible with Linux printk(). We'll have a proper fix in the next code drop of this driver. Fine. Also, why does the '=' need to be changed to '-' ? It's the other way round. printf(%s: scb size = 0x%x, hscb size - 0x%x\n, ^ this should be '='? Regards, Stefan Farfeleder To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav wrote: -- stage 4: building everything.. -- === share/doc/usd/13.viref out of memory *** Error code 255 This is because the kernel was old on beast (fixing now), but thats not the point. We're always going to get this, so the -static workaround probably needs to remain, or we are using the wrong groff binary or something. 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: alpha tinderbox failure
Dag-Erling Smorgrav writes: === share/doc/usd/13.viref out of memory *** Error code 255 Can you update the kernel and rtld on this machine as indicated in UPDATING? Otherwise, we'll see this same failure forever. Also, is there any way I can talk you out of building LINT on alpha in your tinderbox, or at least talk you into building it without WARNS? (there are several hundred pointer/integer with different size casts in various ILP32-centric drivers, and several hundred printf format warnings, so LINT will always fail and the alpha tinderbox will just by crying wolf and annoying people). Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Wed, Oct 23, 2002 at 05:29:40PM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: OK, to summarize things. There was a single problem with two symptoms: 1) groff, if built dynamically, could not be run by ld-elf.so; 2) groff, if built statically, always failed with ``out of memory'', apparently due to the same bug. Static hack is safe to delete because: 1. groff that is built as part of the bootstrap-tools during buildworld will be built static anyway (see -DNOSHARED in BMAKE in Makefile.inc1) 2. if you have a vulnerable kernel and rtld-elf, static linkage does not address the problem -- you get spurious ``out of memory'' even if you link groff statically. If you agree, please feel free to commit the backout of the hack yourself -- I'm going to leave the computer now. :-) Removed. Please review the following UPDATING entry: --- UPDATING3 Sep 2002 06:13:43 - 1.217 +++ UPDATING23 Oct 2002 21:24:44 - @@ -22,6 +22,19 @@ integrity. Re-enabling write caching can substantially improve performance. +20021023: + Alphas with kernels from between 20020902 and 20021022 and/or + rtld (ld-elf.so.1) older than 20021022 may experience problems + with groff while doing a buildworld (kernel: out of memory, + rtld: too few PT_LOAD segments). + + So, to successfully upgrade your Alpha, you must either + upgrade your kernel and rtld first (which might be a bit + tricky), or avoid running the bootstrapped groff during the + transitional buildworld. To avoid running groff during the + transitional upgrade run make buildworld with -DNOMAN, + -DNO_SHAREDOCS, and -DNO_LPR. + 20020831: gcc has been upgraded to 3.2. It is not all binary compatible with earlier versions of gcc for c++ programs. All c++ Note: I have NOT tested this, beyond verifying that a kernel from Sep 02 works fine. What commit is responsible for a breakage, this one? : peter 2002/09/03 14:18:17 PDT : : Modified files: : sys/kern imgact_elf.c : Log: : Make the text segment locating heuristics from rev 1.121 more reliable : so that it works on the Alpha. This defines the segment that the entry : point exists in as 'text' and any others (usually one) as data. : : Submitted by: tmm : Tested on: i386, alpha : : Revision ChangesPath : 1.125 +10 -15src/sys/kern/imgact_elf.c Also I have verified (on beast) that previous version of Groff (1.17.1) does not have this problem -- groff has two PT_LOAD segments. Anyone cares to explain what's going on here? Why when I remove -fno-exceptions it creates two PT_LOAD segments, why it does not affect previous version of Groff? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45130/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: ... +20021023: + Alphas with kernels from between 20020902 and 20021022 and/or + rtld (ld-elf.so.1) older than 20021022 may experience problems + with groff while doing a buildworld (kernel: out of memory, + rtld: too few PT_LOAD segments). + + So, to successfully upgrade your Alpha, you must either + upgrade your kernel and rtld first (which might be a bit + tricky), or avoid running the bootstrapped groff during the + transitional buildworld. To avoid running groff during the + transitional upgrade run make buildworld with -DNOMAN, + -DNO_SHAREDOCS, and -DNO_LPR. + 20020831: gcc has been upgraded to 3.2. It is not all binary compatible with earlier versions of gcc for c++ programs. All c++ Note: I have NOT tested this, beyond verifying that a kernel from Sep 02 works fine. What commit is responsible for a breakage, this one? : peter 2002/09/03 14:18:17 PDT : : Modified files: : sys/kern imgact_elf.c : Log: : Make the text segment locating heuristics from rev 1.121 more reliable : so that it works on the Alpha. This defines the segment that the entry More or less.. The data, text and vmem limit checking in general. Matt's initial commit on 20020830 broke Alpha totally, so the earliest kernel that would both exhibit the problem and could get to the point of attempting to build world would be from 20020903.I'll update my proposed UPDATING entry with the 20020903 date so as to be more exact. Assuming I do that, do you agree that its accurate enough to be helpful? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Thu, Oct 24, 2002 at 09:12:26AM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: ... +20021023: + Alphas with kernels from between 20020902 and 20021022 and/or + rtld (ld-elf.so.1) older than 20021022 may experience problems + with groff while doing a buildworld (kernel: out of memory, + rtld: too few PT_LOAD segments). + + So, to successfully upgrade your Alpha, you must either + upgrade your kernel and rtld first (which might be a bit + tricky), or avoid running the bootstrapped groff during the + transitional buildworld. To avoid running groff during the + transitional upgrade run make buildworld with -DNOMAN, + -DNO_SHAREDOCS, and -DNO_LPR. + 20020831: gcc has been upgraded to 3.2. It is not all binary compatible with earlier versions of gcc for c++ programs. All c++ Note: I have NOT tested this, beyond verifying that a kernel from Sep 02 works fine. What commit is responsible for a breakage, this one? : peter 2002/09/03 14:18:17 PDT : : Modified files: : sys/kern imgact_elf.c : Log: : Make the text segment locating heuristics from rev 1.121 more reliable : so that it works on the Alpha. This defines the segment that the entry More or less.. The data, text and vmem limit checking in general. Matt's initial commit on 20020830 broke Alpha totally, so the earliest kernel that would both exhibit the problem and could get to the point of attempting to build world would be from 20020903.I'll update my proposed UPDATING entry with the 20020903 date so as to be more exact. Assuming I do that, do you agree that its accurate enough to be helpful? Yes. It may be worth specifying which files/revisions are responsible for a fix -- it might be useful for those who attempt to fix their kernel/rtld first. One thing I'm still missing is why groff binary now comes with only one PT_LOAD segment, and why this is Alpha specific? And why if I checkout old, -D2002/10/10 contrib/groff and gnu/usr.bin/groff and compile gnu/usr.bin/groff/src/roff/groff on the same machine (I tried it on beast.freebsd.org), it produces two PT_LOAD segments? (These are actually two things.) Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45141/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Alexander Kabaev writes: I hope this problem is fixed now. Let me know if I am sadly mistaken about that :) Thanks! It seems to fix it when building groff directly from the src directory (eg, after your kernel change, yesterday's binaries work). I'm building the world now. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Wed, Oct 23, 2002 at 09:59:14AM -0400, Andrew Gallatin wrote:
Alexander Kabaev writes:
I hope this problem is fixed now. Let me know if I am sadly mistaken
about that :)
Thanks!
It seems to fix it when building groff directly from the src
directory (eg, after your kernel change, yesterday's binaries work).
I'm building the world now.
Nice. I was going to ask Peter to upgrade beast with this fix, but
now that you've already tested it, I'd like to back out the hack in
groff/src/roff/groff/Makefile, if there are no objections.
What do we do with NO_CPU_CFLAGS? Should we special-case groff or
${MACHINE_ARCH} = alpha in bsd.cpu.mk?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg44808/pgp0.pgp
Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes:
On Wed, Oct 23, 2002 at 09:59:14AM -0400, Andrew Gallatin wrote:
Alexander Kabaev writes:
I hope this problem is fixed now. Let me know if I am sadly mistaken
about that :)
Thanks!
It seems to fix it when building groff directly from the src
directory (eg, after your kernel change, yesterday's binaries work).
I'm building the world now.
Nice. I was going to ask Peter to upgrade beast with this fix, but
now that you've already tested it, I'd like to back out the hack in
groff/src/roff/groff/Makefile, if there are no objections.
What do we do with NO_CPU_CFLAGS? Should we special-case groff or
${MACHINE_ARCH} = alpha in bsd.cpu.mk?
I wasn't clear enough.. The static binaries built yesterday with
NO_CPU_CFLAGS now appear to work. The problem was apparently
something to do with the kernel exec code in the face of having one
PLT_LOAD segment.
I have not yet attempted a shared binary (as I have not installed the
new rtld). I'll try building a shared binary after the buildworld
completes, and back out the earlier hack assuming it works.
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan, Buildworld completed, and as I installed it, I was reminded of a problem that I *always* have on this machine when I do a make installworld: === lib/libncurses install -C -o root -g wheel -m 444 libncurses.a /usr/lib install -C -o root -g wheel -m 444 libncurses_p.a /usr/lib install -s -o root -g wheel -m 444 libncurses.so.5 /usr/lib ln -fs libncurses.so.5 /usr/lib/libncurses.so install -C -o root -g wheel -m 444 curses.h term.h termcap.h unctrl.h /usr/src/ lib/libncurses/../../contrib/ncurses/include/ncurses_dll.h /usr/include /usr/include/ncurses.h - curses.h ln -s /usr/src/lib/libncurses/../../contrib/ncurses/man/curs_addstr.3x curs_adds tr.3 ln: curs_addstr.3: File exists *** Error code 1 Stop in /usr/src/lib/libncurses. *** Error code 1 Stop in /usr/src/lib. *** Error code 1 Stop in /usr/src. Do you have any idea what's going on here? I've (previously) gone so far as to rm -rf /usr/src and do a fresh checkout. That doesn't seem to help. The only way I can get installworld to complete is to use make with a -k flag.. All fs'es are mounted with noatime, could that have something to do with it? Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: Nice. I was going to ask Peter to upgrade beast with this fix, but now that you've already tested it, I'd like to back out the hack in groff/src/roff/groff/Makefile, if there are no objections. OK.. with the new rtld, a shared groff works. Before you backout the static hack, can you explain the upgrading implications? Since both a new rtld and a new kernel are required to be able to buildworld from an alpha older than yesterday, do we just note that in UPDATING, or do we somehow build groff statically in the early phase, so that a the early stages of buildworld will not depend on having a updated rtld? Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Wed, Oct 23, 2002 at 01:35:30PM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: Nice. I was going to ask Peter to upgrade beast with this fix, but now that you've already tested it, I'd like to back out the hack in groff/src/roff/groff/Makefile, if there are no objections. OK.. with the new rtld, a shared groff works. Before you backout the static hack, can you explain the upgrading implications? Since both a new rtld and a new kernel are required to be able to buildworld from an alpha older than yesterday, do we just note that in UPDATING, or do we somehow build groff statically in the early phase, so that a the early stages of buildworld will not depend on having a updated rtld? OK, to summarize things. There was a single problem with two symptoms: 1) groff, if built dynamically, could not be run by ld-elf.so; 2) groff, if built statically, always failed with ``out of memory'', apparently due to the same bug. Static hack is safe to delete because: 1. groff that is built as part of the bootstrap-tools during buildworld will be built static anyway (see -DNOSHARED in BMAKE in Makefile.inc1) 2. if you have a vulnerable kernel and rtld-elf, static linkage does not address the problem -- you get spurious ``out of memory'' even if you link groff statically. If you agree, please feel free to commit the backout of the hack yourself -- I'm going to leave the computer now. :-) So, to successfully upgrade your Alpha, you must either upgrade your kernel and rtld first (which might be a bit tricky), or to avoid running the bootstrapped groff during the transitional buildworld. All consumers of groff are manpages and share/doc documents, with only one nasty exception -- usr.sbin/lpr/SMM.doc/Makefile, so it should be possible to buildworld with -DNOMAN, -DNO_SHAREDOCS, and -DNO_LPR to achieve this -- avoid running groff during the transitional upgrade. PS. Someone could tell me what is different with Alpha so that it produces only one PT_LOAD segment, compared to i386? Just wondering... Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg44828/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
On Wed, Oct 23, 2002 at 01:08:58PM -0400, Andrew Gallatin wrote:
Ruslan,
Buildworld completed, and as I installed it, I was reminded of a
problem that I *always* have on this machine when I do a
make installworld:
=== lib/libncurses
install -C -o root -g wheel -m 444 libncurses.a /usr/lib
install -C -o root -g wheel -m 444 libncurses_p.a /usr/lib
install -s -o root -g wheel -m 444 libncurses.so.5 /usr/lib
ln -fs libncurses.so.5 /usr/lib/libncurses.so
install -C -o root -g wheel -m 444 curses.h term.h termcap.h unctrl.h
/usr/src/
lib/libncurses/../../contrib/ncurses/include/ncurses_dll.h
/usr/include
/usr/include/ncurses.h - curses.h
ln -s /usr/src/lib/libncurses/../../contrib/ncurses/man/curs_addstr.3x
curs_adds tr.3
ln: curs_addstr.3: File exists
*** Error code 1
Stop in /usr/src/lib/libncurses.
*** Error code 1
Stop in /usr/src/lib.
*** Error code 1
Stop in /usr/src.
Do you have any idea what's going on here? I've (previously) gone so
far as to rm -rf /usr/src and do a fresh checkout. That doesn't seem
to help. The only way I can get installworld to complete is to use
make with a -k flag..
All fs'es are mounted with noatime, could that have something to do
with it?
The command you're are seeing (ln -s) is supposed to be run at
buildworld time. ``make -n all-man'' should produce no output
in that directory. If it does, then make(1) thinks something
is out-of-date. This means that either buildworld did not make
it (but it apparently did), or make(1) is somehow confused thinking
that curs_addstr.3 is out-of-date. The latter is usually due to a
system time being set incorrectly (either when building or installing),
or source files having modification time set to the future, causing
them to always be considered new by make(1). You could check it
by comparing the modtimes of
/usr/src/contrib/ncurses/man/curs_addstr.3x
and
${.OBJDIR}/curs_addstr.3
but since the latter is just a symlink to the former, I have no
idea what's going on here. It may be a bug in the kernel.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg44839/pgp0.pgp
Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: but since the latter is just a symlink to the former, I have no idea what's going on here. It may be a bug in the kernel. A comedy of errors. Nearly my entire source tree is dated 1934 -- I'd been dual booting with an old linux kernel that scewed up my clock. I think what must have happened is that I updated a few files to 1934, introduced the initial failure, re-checked out my tree and made nearly everything be from 1934, then corrected the date sometime more recently. In any case, its all local pilot error. Thanks for your detailed explaination. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: OK, to summarize things. There was a single problem with two symptoms: 1) groff, if built dynamically, could not be run by ld-elf.so; 2) groff, if built statically, always failed with ``out of memory'', apparently due to the same bug. Static hack is safe to delete because: 1. groff that is built as part of the bootstrap-tools during buildworld will be built static anyway (see -DNOSHARED in BMAKE in Makefile.inc1) 2. if you have a vulnerable kernel and rtld-elf, static linkage does not address the problem -- you get spurious ``out of memory'' even if you link groff statically. If you agree, please feel free to commit the backout of the hack yourself -- I'm going to leave the computer now. :-) Removed. Please review the following UPDATING entry: --- UPDATING3 Sep 2002 06:13:43 - 1.217 +++ UPDATING23 Oct 2002 21:24:44 - @@ -22,6 +22,19 @@ integrity. Re-enabling write caching can substantially improve performance. +20021023: + Alphas with kernels from between 20020902 and 20021022 and/or + rtld (ld-elf.so.1) older than 20021022 may experience problems + with groff while doing a buildworld (kernel: out of memory, + rtld: too few PT_LOAD segments). + + So, to successfully upgrade your Alpha, you must either + upgrade your kernel and rtld first (which might be a bit + tricky), or avoid running the bootstrapped groff during the + transitional buildworld. To avoid running groff during the + transitional upgrade run make buildworld with -DNOMAN, + -DNO_SHAREDOCS, and -DNO_LPR. + 20020831: gcc has been upgraded to 3.2. It is not all binary compatible with earlier versions of gcc for c++ programs. All c++ Note: I have NOT tested this, beyond verifying that a kernel from Sep 02 works fine. Thanks, Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Trying it now on beast. Will keep you updated. I seem to have already found what seems to be a culprit, but it barfs differently here. Thanks, Drew stage 4: building everything.. -- === share/doc/usd/13.viref out of memory *** Error code 255 -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45020/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Well, I tried this on beast. It is easily reproduceable. It turned out that if you build groff with -DNO_CPU_CFLAGS (the way it is built during the bootstrap-tools stage of buildworld), it fails with the `out of memory' error in contrib/groff/src/libs/libgroff/new.cc. To reproduce, it is only necessary to build the following dirs, in order, with -DNO_CPU_CFLAGS: gnu/usr.bin/groff/src/libs/libgroff gnu/usr.bin/groff/src/roff/groff And then run groff from the latter as follows: groff -V More fun. Groff is built with -fno-rtti and -fno-exceptions: : RCS file: /home/ncvs/src/gnu/usr.bin/groff/Attic/Makefile.cfg,v : Working file: Makefile.cfg : head: 2.13 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 36;selected revisions: 1 : description: : : revision 2.7 : date: 1999/04/04 16:44:33; author: obrien; state: Exp; lines: +2 -1 : This is old C++ code -- no need for rtti or exceptions. If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? I am Cc:ing our GCC gurus in a hope they can shed a light on this. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45034/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes: If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? Interesting. I wonder of the lack of exceptions is what's confusing ld? As to mpcu: On alphas, the compiler has more chance to make mistakes if its compiled for CPUs ev56 which do not support byte/word instructions. In those cases, it needs to generate shifty/masky code to pull 8 and 16 bit values out of 32-bit loads and stores. This has a history of being more error prone. Eg, some complex ports work on stable at high optimization levels with -mcpu=ev56 which don't work without -mpcu. If we have to, we can always compile groff as -mcpu=ev56 because we emulate these instructions in the kernel on older machines. That would make groff run about like molases in January on older machines, though, as each byte/word instruction would generate an illegal instruction trap and that trap would be handled by the alpha trap handler.. Drew To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, Oct 22, 2002 at 10:45:52AM -0400, Andrew Gallatin wrote: Ruslan Ermilov writes: If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? Interesting. I wonder of the lack of exceptions is what's confusing ld? Seems so. With -fno-exceptions and last delta to groff/Makefile backed out: $ roff/groff/groff -V /usr/libexec/ld-elf.so.1: roff/groff/groff: too few PT_LOAD segments The same, but without -fno-exceptions: $ roff/groff/groff -V troff -Tps | grops I wonder if the follwing commit might be relevant to the -DNOSHARED issue with groff: : kan 2002/10/19 16:03:35 PDT : : Modified files: : libexec/rtld-elf rtld.c : Log: : Change the symbol lookup order to search RTLD_GLOBAL objects : before referencing object's DAG. This makes it possible for : C++ exceptions to work across shared libraries and brings : us closer to the search order used by Solaris/Linux. : : Reviewed by:jdp : Approved by:obrien : MFC after: 1 month : : Revision ChangesPath : 1.68 +12 -12src/libexec/rtld-elf/rtld.c As to mpcu: On alphas, the compiler has more chance to make mistakes if its compiled for CPUs ev56 which do not support byte/word instructions. In those cases, it needs to generate shifty/masky code to pull 8 and 16 bit values out of 32-bit loads and stores. This has a history of being more error prone. Eg, some complex ports work on stable at high optimization levels with -mcpu=ev56 which don't work without -mpcu. If we have to, we can always compile groff as -mcpu=ev56 because we emulate these instructions in the kernel on older machines. That would make groff run about like molases in January on older machines, though, as each byte/word instruction would generate an illegal instruction trap and that trap would be handled by the alpha trap handler.. Can't we make it the default in GCC, or in share/mk/bsd.cpu.mk? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45039/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, Oct 22, 2002 at 05:29:29PM +0300, Ruslan Ermilov wrote: On Mon, Oct 21, 2002 at 02:10:01PM -0400, Andrew Gallatin wrote: Ruslan, Can you help with this, please? I think you're the best candidate since you know so much about the build system and you are the groff maintainer. I've found that if I just cd to /usr/src/share/doc and do a 'make' groff works like a charm. But from inside make buildworld, groff a) emits 'out of memory warnings' on each file processed b) produces empty output files c) eventually dies, killing the build Assuming that I installed the version of groff made by buildworld, along with libc.so, libm.so, and libstdc++.so (all built by buildworld) prior to running make in /usr/src/share/doc, can you please explain what's different about groff in the buildworld case? I'm tearing my hair out trying to figure out what broke. Well, I tried this on beast. It is easily reproduceable. It turned out that if you build groff with -DNO_CPU_CFLAGS (the way it is built during the bootstrap-tools stage of buildworld), it fails with the `out of memory' error in contrib/groff/src/libs/libgroff/new.cc. To reproduce, it is only necessary to build the following dirs, in order, with -DNO_CPU_CFLAGS: gnu/usr.bin/groff/src/libs/libgroff gnu/usr.bin/groff/src/roff/groff And then run groff from the latter as follows: groff -V More fun. Groff is built with -fno-rtti and -fno-exceptions: : RCS file: /home/ncvs/src/gnu/usr.bin/groff/Attic/Makefile.cfg,v : Working file: Makefile.cfg : head: 2.13 : branch: : locks: strict : access list: : keyword substitution: kv : total revisions: 36;selected revisions: 1 : description: : : revision 2.7 : date: 1999/04/04 16:44:33; author: obrien; state: Exp; lines: +2 -1 : This is old C++ code -- no need for rtti or exceptions. If you remove -fno-exceptions from gnu/usr.bin/groff/Makefile.inc and recompile libgroff and groff, it seems to work (I did not check it thoroughly). But I think this only has a side effect, because Groff does not seem to have any exception code (please correct me if I am wrong), and why the hell it should depend on -mcpu, if any? I am Cc:ing our GCC gurus in a hope they can shed a light on this. Yeah, it only seems to work if you remove -fno-exceptions. It only makes ``groff -V'' work, but full groff invocations continue to fail with ``out of memory'' during the buildworld. So we apparently need to compile Groff with -mcpu=ev56, as Andrew suggested (I did not check will it help or not, and I do not have any more time today for this). But removing -fno-exceptions has a good impact on rtld(1) issue. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg45042/pgp0.pgp Description: PGP signature
Re: Groff problems (was Re: alpha tinderbox failure)
Ruslan Ermilov writes:
Well, I tried this on beast. It is easily reproduceable.
It turned out that if you build groff with -DNO_CPU_CFLAGS
(the way it is built during the bootstrap-tools stage of
buildworld), it fails with the `out of memory' error in
contrib/groff/src/libs/libgroff/new.cc. To reproduce, it
is only necessary to build the following dirs, in order,
with -DNO_CPU_CFLAGS:
gnu/usr.bin/groff/src/libs/libgroff
gnu/usr.bin/groff/src/roff/groff
And then run groff from the latter as follows:
groff -V
More fun. Groff is built with -fno-rtti and -fno-exceptions:
FWIW, the out of memory is because it is attempting to malloc
a huge amount of ram. Apparently mistakenly:
(gdb) break /usr/src/contrib/groff/src/libs/libgroff/new.cc:45
Breakpoint 1 at 0x12000c9cc: file
/usr/src/contrib/groff/src/libs/libgroff/new.cc, line 45.
(gdb) r
Starting program: /usr/src/gnu/usr.bin/groff/src/roff/groff/groff
Breakpoint 1, operator new(unsigned long) (size=4832141312)
at /usr/src/contrib/groff/src/libs/libgroff/new.cc:45
45if (p == 0) {
(gdb) p/x size
$1 = 0x12004a000
(gdb)
Note that 0x12004a000 looks quite a bit like an address in the data
segment. The stack looks like this (its happening before main is entered):
(gdb) where
#0 operator new(unsigned long) (size=4832141312)
at /usr/src/contrib/groff/src/libs/libgroff/new.cc:45
#1 0x12000d528 in operator new[](unsigned long) ()
#2 0x12000c1ac in search_path (this=0x120035930, envvar=0x0,
standard=0x12002b8b1 /usr/share/groff_font, add_home=1,add_current=0)
at /usr/src/contrib/groff/src/libs/libgroff/searchpath.cc:39
#3 0x12000aec4 in __static_initialization_and_destruction_0 (__initialize_p=1,
__priority=65535)at /usr/src/contrib/groff/src/libs/libgroff/fontfile.cc:34
#4 0x12000af30 in _GLOBAL__I__ZN4font3resE ()at
/usr/src/contrib/groff/src/libs/libgroff/fontfile.cc:34
#5 0x12002a0b8 in __do_global_ctors_aux ()
#6 0x12150 in _init ()
#7 0x12228 in _start ()
The code calling new is this bit of c++ code:
(gdb) frame 2
#2 0x12000c1ac in search_path (this=0x120035930, envvar=0x0,
standard=0x12002b8b1 /usr/share/groff_font, add_home=1,
add_current=0)
at /usr/src/contrib/groff/src/libs/libgroff/searchpath.cc:39
39dirs = new char[((e *e) ? strlen(e) + 1 : 0)
(gdb) l
34if (add_home)
35 home = getenv(HOME);
36char *e = 0;
37if (envvar)
38 e = getenv(envvar);
39dirs = new char[((e *e) ? strlen(e) + 1 : 0)
40+ (add_current ? 1 + 1 : 0)
41+ ((home *home) ? strlen(home) + 1 : 0)
42+ ((standard *standard) ? strlen(standard) : 0)
43+ 1];
I have no idea what 'e' is, gdb doesn't like things declared in the
middle of a scope, apparently.
Drew
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Anyone cares to post a ktrace? -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
On Tue, 22 Oct 2002 11:39:43 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: Anyone cares to post a ktrace? -- Alexander Kabaev If this is a case of a brk(2) failing, then I have a patch in testing to fix that. Give me some time to finish. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
Alexander Kabaev writes: On Tue, 22 Oct 2002 11:39:43 -0400 Alexander Kabaev [EMAIL PROTECTED] wrote: Anyone cares to post a ktrace? -- Alexander Kabaev If this is a case of a brk(2) failing, then I have a patch in testing to fix that. Give me some time to finish. I've appended a trace. Drew 1447 ktrace RET ktrace 0 1447 ktrace CALL execve(0x11fff963,0x11fff700,0x11fff718) 1447 ktrace NAMI ./groff 1447 groffRET execve 0 1447 groffCALL fstat(0x1,0x11ffefa0) 1447 groffRET fstat 0 1447 groffCALL readlink(0x12002da88,0x11ffef80,0x3f) 1447 groffNAMI /etc/malloc.conf 1447 groffRET readlink -1 errno 2 No such file or directory 1447 groffCALL mmap(0,0x2000,0x3,0x1002,0x,0,0) 1447 groffRET mmap 1073741824/0x4000 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL write(0x1,0x11ffec60,0xc) 1447 groffGIO fd 1 wrote 12 bytes size = 0x16 1447 groffRET write 12/0xc 1447 groffCALL break(0x12004a000) 1447 groffRET break -1 errno 12 Cannot allocate memory 1447 groffCALL write(0x2,0x12002b9df,0xe) 1447 groffGIO fd 2 wrote 14 bytes out of memory 1447 groffRET write 14/0xe 1447 groffCALL exit(0x) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Groff problems (was Re: alpha tinderbox failure)
I hope this problem is fixed now. Let me know if I am sadly mistaken about that :) -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, Oct 15, 2002 at 03:39:46AM -0700, Dag-Erling Smorgrav wrote: -- Kernel build for LINT started on Tue Oct 15 03:35:01 PDT 2002 -- === vinum Makefile, line 4244: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors Poul, Can you please remove the geom_bsd.c script from either sys/conf/files or all of sys/conf/files.*? Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg44706/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
Ruslan Ermilov wrote: --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2002 at 03:39:46AM -0700, Dag-Erling Smorgrav wrote: -- Kernel build for LINT started on Tue Oct 15 03:35:01 PDT 2002 -- =3D=3D=3D vinum Makefile, line 4244: warning: duplicate script for target geom_bsd.o = ignored cc1: warnings being treated as errors =20 Poul, Can you please remove the geom_bsd.c script from either sys/conf/files or all of sys/conf/files.*? This is not the cause of the problem. The build is not disturbed by this config(8) bug. The reason for the failure is that the alpha bus_sppace code does not have the function that ahd needs. It either needs to be implemented or ahd needs to be removed from the alpha build. ahd works on ia64 and sparc64, so dont add it to the i386-only section. However, there are hundreds more failures after this. Fixing this one just gets us to the next failure. 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: alpha tinderbox failure
On Tue, Oct 15, 2002 at 07:54:50AM -0700, Peter Wemm wrote: Ruslan Ermilov wrote: --+g7M9IMkV8truYOl Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Oct 15, 2002 at 03:39:46AM -0700, Dag-Erling Smorgrav wrote: -- Kernel build for LINT started on Tue Oct 15 03:35:01 PDT 2002 -- =3D=3D=3D vinum Makefile, line 4244: warning: duplicate script for target geom_bsd.o = ignored cc1: warnings being treated as errors =20 Poul, Can you please remove the geom_bsd.c script from either sys/conf/files or all of sys/conf/files.*? This is not the cause of the problem. The build is not disturbed by this config(8) bug. The reason for the failure is that the alpha bus_sppace code does not have the function that ahd needs. It either needs to be implemented or ahd needs to be removed from the alpha build. ahd works on ia64 and sparc64, so dont add it to the i386-only section. However, there are hundreds more failures after this. Fixing this one just gets us to the next failure. I did not say it was the reason for a failure, I asked Poul to remove the offending lines to eliminate the quoted warning. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg44708/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
I got the same error on my laptop after cvsuping today. Been reluctant to after all the talk of recompiles and the kde stability problems, but gave in after trying to install a port and remembering they switched it back to tgz On Sun, 2002-10-13 at 03:56, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Oct 13 03:49:21 PDT 2002 -- === vinum /h/des/src/sys/kern/kern_mib.c:116: `_KPOSIX_VERSION' undeclared here (not in a function) /h/des/src/sys/kern/kern_mib.c:116: initializer element is not constant /h/des/src/sys/kern/kern_mib.c:116: (near initialization for `sysctl___kern_posix1version.oid_arg2') *** Error code 1 Stop in /h/des/obj/h/des/src/sys/GENERIC. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. 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: alpha tinderbox failure
nm looks like it was just fixed. I'll give it another whirl :) sorry On Sun, 2002-10-13 at 03:56, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Sun Oct 13 03:49:21 PDT 2002 -- === vinum /h/des/src/sys/kern/kern_mib.c:116: `_KPOSIX_VERSION' undeclared here (not in a function) /h/des/src/sys/kern/kern_mib.c:116: initializer element is not constant /h/des/src/sys/kern/kern_mib.c:116: (near initialization for `sysctl___kern_posix1version.oid_arg2') *** Error code 1 Stop in /h/des/obj/h/des/src/sys/GENERIC. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. 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: alpha tinderbox failure
Dag-Erling Smorgrav wrote: === vinum cc1: warnings being treated as errors /h/des/src/sys/ufs/ffs/ffs_snapshot.c: In function `ffs_snapshot': /h/des/src/sys/ufs/ffs/ffs_snapshot.c:531: warning: int format, different type arg (arg 2) *** Error code 1 Should be fixed now. Maxime To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Jeff Roberson writes:
On Tue, 8 Oct 2002, Dag-Erling Smorgrav wrote:
Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach':
/h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant
conversion
*** Error code 1
Any progress on this?
This particular message is caused by alpha's
#define BUS_SPACE_UNRESTRICTED (~0UL)
Clashing with int nsegments:
/* XXX Should probably allow specification of alignment */
int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt,
bus_size_t boundary, bus_addr_t lowaddr,
bus_addr_t highaddr, bus_dma_filter_t *filtfunc,
void *filtfuncarg, bus_size_t maxsize, int nsegments,
bus_size_t maxsegsz, int flags, bus_dma_tag_t *dmat);
Sparc64 has the same problem. ia64 gets around it by just making
BUS_SPACE_UNRESTRICTED an int:
#define BUS_SPACE_UNRESTRICTED (~0)
I'd like to do the same for alpha. I think this is valid, as
BUS_SPACE_UNRESTRICTED seems to be used exlusively as an argument
to bus_dma_tag_create(... nsegments = BUS_SPACE_UNRESTRICTED...)
I'd also like to add a bus_space_subregion(). Please review the
appended patch. I'm running it with no ill effects, and it makes
alpha get a bit further on in LINT. (until it dies on printf format
warnings). Its going to be a bear to get a clean lint with Werror.
All those crusty old isa drivers casting pointers to integers make
me feel a bit overwhelmed.
It would be nice if des could remove LINT from the tinderbox builds
until LINT has a chance of compiling. Right now people are ignoring
the alpha tinderbox failure messages. Eventually, it will fail for a
reason besides useless LINT garbage, and everybody will ignore it.
Drew
Index: include/bus.h
===
RCS file: /home/ncvs/src/sys/alpha/include/bus.h,v
retrieving revision 1.11
diff -u -r1.11 bus.h
--- include/bus.h 4 Oct 2002 20:40:39 - 1.11
+++ include/bus.h 9 Oct 2002 00:06:39 -
@@ -88,7 +88,27 @@
/* The largest address space known so far is 40 bits */
#define BUS_SPACE_MAXADDR 0xFUL
-#define BUS_SPACE_UNRESTRICTED (~0UL)
+#define BUS_SPACE_UNRESTRICTED (~0)
+
+/*
+ * Get a new handle for a subregion of an already-mapped area of bus space.
+ */
+
+static __inline int bus_space_subregion(bus_space_tag_t t,
+ bus_space_handle_t bsh,
+ bus_size_t offset, bus_size_t size,
+ bus_space_handle_t *nbshp);
+
+static __inline int
+bus_space_subregion(bus_space_tag_t t __unused, bus_space_handle_t bsh,
+ bus_size_t offset, bus_size_t size __unused,
+ bus_space_handle_t *nbshp)
+{
+
+ *nbshp = bsh + offset;
+ return (0);
+}
+
struct alpha_busspace;
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Wed, 9 Oct 2002, Andrew Gallatin wrote: Jeff Roberson writes: On Tue, 8 Oct 2002, Dag-Erling Smorgrav wrote: Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Any progress on this? This particular message is caused by alpha's #define BUS_SPACE_UNRESTRICTED (~0UL) Clashing with int nsegments: Sparc64 has the same problem. ia64 gets around it by just making BUS_SPACE_UNRESTRICTED an int: #define BUS_SPACE_UNRESTRICTED (~0) I'd like to do the same for alpha. I think this is valid, as BUS_SPACE_UNRESTRICTED seems to be used exlusively as an argument to bus_dma_tag_create(... nsegments = BUS_SPACE_UNRESTRICTED...) Yes, I looked into this before and agree this is a valid approach. It's likely the number of segments never exceeds 32, let alone 2^31. I'd also like to add a bus_space_subregion(). Please review the appended patch. I'm running it with no ill effects, and it makes alpha get a bit further on in LINT. (until it dies on printf format warnings). Its going to be a bear to get a clean lint with Werror. All those crusty old isa drivers casting pointers to integers make me feel a bit overwhelmed. I can spend a little time cleaning that up as things progress. The patch looks fine. It would be nice if des could remove LINT from the tinderbox builds until LINT has a chance of compiling. Right now people are ignoring the alpha tinderbox failure messages. Eventually, it will fail for a reason besides useless LINT garbage, and everybody will ignore it. Ok by me. -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Andrew Gallatin wrote: Jeff Roberson writes: On Tue, 8 Oct 2002, Dag-Erling Smorgrav wrote: Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Any progress on this? This particular message is caused by alpha's #define BUS_SPACE_UNRESTRICTED (~0UL) Clashing with int nsegments: /* XXX Should probably allow specification of alignment */ int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt, bus_size_t boundary, bus_addr_t lowaddr, bus_addr_t highaddr, bus_dma_filter_t *filtfunc, void *filtfuncarg, bus_size_t maxsize, int nsegments, bus_size_t maxsegsz, int flags, bus_dma_tag_t *dmat); Sparc64 has the same problem. ia64 gets around it by just making BUS_SPACE_UNRESTRICTED an int: #define BUS_SPACE_UNRESTRICTED (~0) I'd like to do the same for alpha. I think this is valid, as BUS_SPACE_UNRESTRICTED seems to be used exlusively as an argument to bus_dma_tag_create(... nsegments = BUS_SPACE_UNRESTRICTED...) I'd also like to add a bus_space_subregion(). Please feel free to change the workaround that I did. I wasn't sure if changing the type of BUS_SPACE_UNRESTRICTED was safe. 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: alpha tinderbox failure
On Wed, 9 Oct 2002, Nate Lawson wrote: On Wed, 9 Oct 2002, Andrew Gallatin wrote: ... Clashing with int nsegments: Sparc64 has the same problem. ia64 gets around it by just making BUS_SPACE_UNRESTRICTED an int: #define BUS_SPACE_UNRESTRICTED (~0) I'd like to do the same for alpha. I think this is valid, as BUS_SPACE_UNRESTRICTED seems to be used exlusively as an argument to bus_dma_tag_create(... nsegments = BUS_SPACE_UNRESTRICTED...) Yes, I looked into this before and agree this is a valid approach. It's likely the number of segments never exceeds 32, let alone 2^31. However, it is likely that the number of segments exeeds ~0 (which is -1 on normal 2's complement machines). bus_dma_tag_create() has a bogus interface. It takes an int nsegments arg but corrupts it immediately to a u_int nsegments struct member. BUS_SPACE_UNRESTRICTED seems to be used as a generic (null) limit in at least the isp driver. It is not clear that ~0 has the correct overflow and sign extension behaviour for this. ~0UL works better as a generic limit. It even points to the bogus interface. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 8 Oct 2002, Dag-Erling Smorgrav wrote: Makefile, line 4194: warning: duplicate script for target geom_bsd.o ignored cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant conversion *** Error code 1 Any progress on this? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, Oct 01, 2002 at 01:11:04AM -0700, Dag-Erling Smorgrav wrote: === bin/sh cc1: warnings being treated as errors /h/des/src/bin/sh/mksyntax.c: In function `digit_convert': /h/des/src/bin/sh/mksyntax.c:396: warning: int format, different type arg (arg 3) *** Error code 1 Stop in /h/des/src/bin/sh. *** Error code 1 Already fixed. This gives me a good excuse to axe the printf() clone in output.c, too. Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote:
--
Rebuilding the temporary build tree
--
stage 1: bootstrap tools
--
stage 2: cleaning up the object tree
--
stage 2: rebuilding the object tree
--
stage 2: build tools
--
stage 3: cross tools
--
stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/include
--
stage 4: building libraries
--
stage 4: make dependencies
--
stage 4: building everything..
--
Kernel build for GENERIC started on Thu Sep 26 15:20:27 PDT 2002
--
Kernel build for GENERIC completed on Thu Sep 26 15:50:41 PDT 2002
--
Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002
--
=== vinum
cc1: warnings being treated as errors
/h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach':
/h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit constant
conversion
*** Error code 1
Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1
Stop in /h/des/src.
*** Error code 1
Stop in /h/des/src.
I don't understand why this error occurs since the types all seem to
match.
Relevant lines from src/sys/dev/advansys/adv_pci.c:
/* Allocate a dmatag for our transfer DMA maps */
/* XXX Should be a child of the PCI bus dma tag */
error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1,
/*boundary*/0,
/*lowaddr*/ADV_PCI_MAX_DMA_ADDR,
/*highaddr*/BUS_SPACE_MAXADDR,
/*filter*/NULL, /*filterarg*/NULL,
/*maxsize*/BUS_SPACE_MAXSIZE_32BIT,
/*nsegments*/BUS_SPACE_UNRESTRICTED,
/*maxsegsz*/ADV_PCI_MAX_DMA_COUNT,
/*flags*/0,
197 - adv-parent_dmat);
Yet in src/sys/alpha/include/bus.h:
typedef struct bus_dma_tag *bus_dma_tag_t;
...
int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt,
bus_size_t boundary, bus_addr_t lowaddr,
bus_addr_t highaddr, bus_dma_filter_t *filtfunc,
void *filtfuncarg, bus_size_t maxsize, int
nsegments,
bus_size_t maxsegsz, int flags, bus_dma_tag_t
*dmat);
And advlib.h:
struct adv_softc {
...
bus_dma_tag_tparent_dmat;
}
Everything seems to line up, why the warning?
-Nate
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Nate Lawson wrote: On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/h/des/src/alpha/usr/i nclude -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 26 15:20:27 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 26 15:50:41 PDT 2002 -- Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit co nstant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. I don't understand why this error occurs since the types all seem to match. Relevant lines from src/sys/dev/advansys/adv_pci.c: /* Allocate a dmatag for our transfer DMA maps */ /* XXX Should be a child of the PCI bus dma tag */ error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1, /*boundary*/0, /*lowaddr*/ADV_PCI_MAX_DMA_ADDR, /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_32BIT, /*nsegments*/BUS_SPACE_UNRESTRICTED, /*maxsegsz*/ADV_PCI_MAX_DMA_COUNT, /*flags*/0, 197 - adv-parent_dmat); Yet in src/sys/alpha/include/bus.h: typedef struct bus_dma_tag *bus_dma_tag_t; ... int bus_dma_tag_create(bus_dma_tag_t parent, bus_size_t alignemnt, bus_size_t boundary, bus_addr_t lowaddr, bus_addr_t highaddr, bus_dma_filter_t *filtfunc, void *filtfuncarg, bus_size_t maxsize, int nsegments, bus_size_t maxsegsz, int flags, bus_dma_tag_t *dmat); gcc is telling you the wrong line. The problem is here: int nsegments; vs: /*nsegments*/BUS_SPACE_UNRESTRICTED, note that: bus.h:#define BUS_SPACE_UNRESTRICTED(~0UL) 0x will not fit in an int. 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: alpha tinderbox failure
On Thu, 26 Sep 2002, Peter Wemm wrote: Nate Lawson wrote: On Thu, 26 Sep 2002, Dag-Erling Smorgrav wrote: Kernel build for LINT started on Thu Sep 26 15:50:41 PDT 2002 -- === vinum cc1: warnings being treated as errors /h/des/src/sys/dev/advansys/adv_pci.c: In function `adv_pci_attach': /h/des/src/sys/dev/advansys/adv_pci.c:197: warning: overflow in implicit co nstant conversion *** Error code 1 Stop in /h/des/obj/h/des/src/sys/LINT. *** Error code 1 Stop in /h/des/src. *** Error code 1 Stop in /h/des/src. I don't understand why this error occurs since the types all seem to match. Relevant lines from src/sys/dev/advansys/adv_pci.c: /* Allocate a dmatag for our transfer DMA maps */ /* XXX Should be a child of the PCI bus dma tag */ error = bus_dma_tag_create(/*parent*/NULL, /*alignment*/1, /*boundary*/0, /*lowaddr*/ADV_PCI_MAX_DMA_ADDR, /*highaddr*/BUS_SPACE_MAXADDR, /*filter*/NULL, /*filterarg*/NULL, /*maxsize*/BUS_SPACE_MAXSIZE_32BIT, /*nsegments*/BUS_SPACE_UNRESTRICTED, /*maxsegsz*/ADV_PCI_MAX_DMA_COUNT, /*flags*/0, 197 - adv-parent_dmat); gcc is telling you the wrong line. The problem is here: int nsegments; vs: /*nsegments*/BUS_SPACE_UNRESTRICTED, note that: bus.h:#define BUS_SPACE_UNRESTRICTED(~0UL) 0x will not fit in an int. I looked at this some more. Would it be ok to make it (~0) since we'll never need 64 bits worth of nsegments? -Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 17 Sep 2002, Dag-Erling Smorgrav wrote:
--
Kernel build for LINT started on Tue Sep 17 15:31:39 PDT 2002
--
=== vinum
./aicasm: 877 instructions used
./aicasm: 658 instructions used
In file included from /h/des/src/sys/dev/dgb/dgb.c:89:
/h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or
directory
/h/des/src/sys/dev/dgb/dgb.c:92:2: #error The dgb device requires the old isa
compatibility shims
/h/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory
/h/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken
and is not compiled with LINT
/h/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory
/h/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or
directory
In file included from /h/des/src/sys/dev/ncv/ncr53c500.c:86:
/h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or
directory
/h/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or
directory
In file included from /h/des/src/sys/dev/ncv/ncr53c500_pccard.c:63:
/h/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or
directory
/h/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory
/h/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory
/h/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory
...
/h/des/src/sys/pci/simos.c:57:2: #error The simos device requires the old pci
compatibility shims
/h/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory
mkdep: compile failed
*** Error code 1
Stop in /h/des/obj/h/des/src/sys/LINT.
*** Error code 1
Here is a simple hack for killing broken devices which were (now
nominally) configured in a previous line. Something like this should
be used to avoid moving correctly placed devices in /sys/conf/NOTES
to many MD NOTES files just because they are broken for 1 arch, or
even to put almost all devices in /sys/conf/NOTES and kill selected
ones in MD notes files. Options could be killed similarly. A non-hackish
version would use a new keyword. A slightly less hackish version could
use a count of -1. config somehow already handles devices that are
configured more than once reasonably allthough it adds them more than
once in newdev().
%%%
Index: config.y
===
RCS file: /home/ncvs/src/usr.sbin/config/config.y,v
retrieving revision 1.56
diff -u -2 -r1.56 config.y
--- config.y27 Aug 2001 05:11:53 - 1.56
+++ config.y18 Sep 2002 13:21:49 -
@@ -263,6 +263,16 @@
newdev(char *name, int count)
{
- struct device *np;
+ struct device *np, *pp;
+ for (pp = NULL, np = curp; np != NULL; pp = np, np = np-d_next) {
+ if (strcmp(name, np-d_name) == 0) {
+ printf(device %s repeated; forgetting it\n);
+ if (pp == NULL)
+ curp = np-d_next;
+ else
+ pp-d_next = np-d_next;
+ return;
+ }
+ }
np = (struct device *) malloc(sizeof *np);
memset(np, 0, sizeof(*np));
%%%
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Dag-Erling Smorgrav wrote: Kernel build for LINT started on Wed Sep 18 15:43:20 PDT 2002 -- === vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /h/des/src/sys/dev/dgb/dgb.c:89: /h/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /h/des/src/sys/dev/dgb/dgb.c:92:2: #error The dgb device requires the old is a compatibility shims I've fixed all this initial group so that 'make depend' runs. And naturally, there are some real horrors once we get to the actual compile. The next run should be interesting. :-] 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: alpha tinderbox failure
JKH task: go through conf/NOTES and move devices that don't (or could never) build on alpha to i386/conf/NOTES. At the end of this, LINT should build on alpha and i386. BTW, I would think there should be a pc98/conf/NOTES that most stuff moved out of the global notes should go into as well as i386. Anyone up for this? -Nate On Wed, 11 Sep 2002, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Wed Sep 11 06:11:26 PDT 2002 -- Kernel build for GENERIC completed on Wed Sep 11 07:16:38 PDT 2002 -- Kernel build for LINT started on Wed Sep 11 07:16:40 PDT 2002 -- === vinum ./aicasm: 877 instructions used ./aicasm: 658 instructions used In file included from /var/tmp/des/src/sys/dev/dgb/dgb.c:89: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/dgb/dgb.c:92:2: #error The dgb device requires the old isa compatibility shims /var/tmp/des/src/sys/dev/iicbus/iic.c:42:25: machine/iic.h: No such file or directory /var/tmp/des/src/sys/dev/lmc/if_lmc.c:32:2: warning: #warning The lmc driver is broken and is not compiled with LINT /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:81:33: machine/physio_proc.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500.c:86: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:55:27: machine/dvcfg.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/ncv/ncr53c500_pccard.c:63: /var/tmp/des/src/sys/dev/ncv/ncr53c500hw.h:39:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:80:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp.c:81:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/nsp/nsp_pccard.c:52:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/smbus/smb.c:41:25: machine/smb.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:78:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30.c:79:33: machine/physio_proc.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_pccard.c:57:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/stg/tmc18c30_isa.c:65:27: machine/dvcfg.h: No such file or directory /var/tmp/des/src/sys/dev/usb/ukbd.c:419:21: ukbdmap.h: No such file or directory In file included from /var/tmp/des/src/sys/dev/wl/if_wl.c:218: /var/tmp/des/src/sys/i386/isa/isa_device.h:43:31: opt_compat_oldisa.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:224:35: machine/if_wl_wavelan.h: No such file or directory /var/tmp/des/src/sys/dev/wl/if_wl.c:227:2: #error The wl device requires the old isa compatibility shims /var/tmp/des/src/sys/kern/subr_prof.c:62:30: machine/asmacros.h: No such file or directory /var/tmp/des/src/sys/kern/subr_prof.c:232:2: #error /var/tmp/des/src/sys/kern/subr_prof.c:243:2: #error /var/tmp/des/src/sys/pci/meteor.c:149:2: warning: #warning The meteor driver is broken and is not compiled with LINT /var/tmp/des/src/sys/pci/simos.c:57:2: #error The simos device requires the old pci compatibility shims /var/tmp/des/src/sys/dev/syscons/syscons.c:117:18: font.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/obj/var/tmp/des/src/sys/LINT. *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. To
Re: alpha tinderbox failure
On 11-Sep-2002 Nate Lawson wrote: JKH task: go through conf/NOTES and move devices that don't (or could never) build on alpha to i386/conf/NOTES. At the end of this, LINT should build on alpha and i386. I already did this before when I first created sys/alpha/conf/NOTES. It did build at one time. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ 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: alpha tinderbox failure
Is CVSup stale on this machine or is it not rebuilding LINT from NOTES? On Thu, 5 Sep 2002, Dag-Erling Smorgrav wrote: -- Rebuilding the temporary build tree -- stage 1: bootstrap tools -- stage 2: cleaning up the object tree -- stage 2: rebuilding the object tree -- stage 2: build tools -- stage 3: cross tools -- stage 4: populating /home/des/tinderbox/alpha/obj/var/tmp/des/src/alpha/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- Kernel build for GENERIC started on Thu Sep 5 06:11:44 PDT 2002 -- Kernel build for GENERIC completed on Thu Sep 5 07:16:08 PDT 2002 -- Kernel build for LINT started on Thu Sep 5 07:16:09 PDT 2002 -- === LINT config: Error: device apm_saver is unknown config: Error: device cy is unknown config: Error: device cy does not take a count config: 3 errors WARNING: kernel contains GPL contaminated ext2fs filesystem FYI: static unit limits for vcoda are set: NVCODA=4 FYI: static unit limits for dgb are set: NDGB=1 FYI: static unit limits for card are set: NCARD=1 FYI: static unit limits for meteor are set: NMETEOR=1 *** Error code 1 Stop in /var/tmp/des/src. *** Error code 1 Stop in /var/tmp/des/src. 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: alpha tinderbox failure
On Thu, 5 Sep 2002, Nate Lawson wrote: Is CVSup stale on this machine or is it not rebuilding LINT from NOTES? LINT never even config'ed on alphas. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Is someone going to address this? If not, I will. Jeff To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 3 Sep 2002 04:23:39 -0700 (PDT) Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === usr.bin/getconf Virtual memory exhausted in `operator new' *** Error code 1 This one I can reproduce. Will fix soon. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, Sep 03, 2002 at 07:59:18AM -0400, Alexander Kabaev wrote: On Tue, 3 Sep 2002 04:23:39 -0700 (PDT) Dag-Erling Smorgrav [EMAIL PROTECTED] wrote: === usr.bin/getconf Virtual memory exhausted in `operator new' *** Error code 1 This one I can reproduce. Will fix soon. I was able to build/install world yesterday on alpha, but I get the same error message now with libiconv: [69]cicely9# /usr/bin/gperf -t -L ANSI-C -H aliases_hash -N aliases_lookup -G -W aliases -7 -C -k '1,3-11,$' -i 1 lib/aliases.gperf lib/aliases.h Virtual memory exhausted in `operator new' Exit 1 [70]cicely9# Do you think this is the same reason? -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. -- Alexander Kabaev To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure
Alexander Kabaev wrote:
On Tue, 3 Sep 2002 04:23:39 -0700 (PDT)
Dag-Erling Smorgrav [EMAIL PROTECTED] wrote:
=== usr.bin/getconf
Virtual memory exhausted in `operator new'
*** Error code 1
This one I can reproduce. Will fix soon.
Here's a clue:
peter@beast[8:06am]~-130 cat foo.c
int main(int ac, char *av[])
{
char *a = new char[1];
}
peter@beast[8:07am]~-131 c++ -o foo foo.c
peter@beast[8:07am]~-132 ./foo
peter@beast[8:08am]~-133 c++ -static -o foo foo.c
peter@beast[8:08am]~-134 ./foo
Abort
peter@beast[8:09am]~-147 ktrace ./foo
Abort
peter@beast[8:09am]~-148 kdump
34729 ktrace RET ktrace 0
34729 ktrace CALL execve(0x11fff947,0x11fff758,0x11fff768)
34729 ktrace NAMI ./foo
34729 foo RET execve 0
34729 foo CALL readlink(0x12000a154,0x11fff628,0x3f)
34729 foo NAMI /etc/malloc.conf
34729 foo RET readlink -1 errno 2 No such file or directory
34729 foo CALL mmap(0,0x2000,0x3,0x1002,0x,0,0)
34729 foo RET mmap 1610612736/0x16000
34729 foo CALL break(0x12003)
34729 foo RET break -1 errno 12 Cannot allocate memory
...
versus dynamic:
peter@beast[8:10am]~-152 ktrace ./foo
peter@beast[8:11am]~-153 kdump | more
35056 ktrace RET ktrace 0
35056 ktrace CALL execve(0x11fff947,0x11fff758,0x11fff768)
35056 ktrace NAMI ./foo
35056 ktrace NAMI /usr/libexec/ld-elf.so.1
35056 foo RET execve 0
35056 foo CALL mmap(0,0x1590,0x3,0x1000,0x,0,0)
35056 foo RET mmap 1610792960/0x16002c000
35056 foo CALL munmap(0x16002c000,0x1590)
35056 foo RET munmap 0
35056 foo CALL __sysctl(0x11fff478,0x2,0x16012ccf8,0x11fff488,0,0)
35056 foo RET __sysctl 0
35056 foo CALL mmap(0,0x8000,0x3,0x1002,0x,0,0)
35056 foo RET mmap 1610792960/0x16002c000
[.. lots of ld.so stuff trimmed ...]
35056 foo CALL sigprocmask(0x3,0x16012d158,0)
35056 foo RET sigprocmask 0
35056 foo CALL readlink(0x16024204c,0x11fff628,0x3f)
35056 foo NAMI /etc/malloc.conf
35056 foo RET readlink -1 errno 2 No such file or directory
35056 foo CALL mmap(0,0x2000,0x3,0x1002,0x,0,0)
35056 foo RET mmap 1611612160/0x1600f4000
35056 foo CALL break(0x120014000)
35056 foo RET break 0
35056 foo CALL break(0x120018000)
35056 foo RET break 0
35056 foo CALL exit(0)
ie: we have this which works:
35056 foo CALL break(0x120014000)
35056 foo RET break 0
vs:
34729 foo CALL break(0x12003)
34729 foo RET break -1 errno 12 Cannot allocate memory
It doesn't appear to be a resource limit though:
peter@beast[8:17am]~-172 cat foo.c
char buf[100];
int main(int ac, char *av[])
{
char *a = new char[1];
}
peter@beast[8:17am]~-173 c++ -o foo foo.c
peter@beast[8:17am]~-174 ktrace ./foo
peter@beast[8:18am]~-175 kdump | grep break
36947 foo CALL break(0x120108000)
36947 foo RET break 0
36947 foo CALL break(0x12010c000)
36947 foo RET break 0
How strange..
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: alpha tinderbox failure - kernel is broken.
Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat Aug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Modified files: sys/sys resource.h sys/vm vm_mmap.c vm_unix.c Log: Part I of RLIMIT_VMEM implementation. Implement core functionality for a new resource limit that covers a process's entire VM space, including mmap()'d space. (Part II will be additional code to check RLIMIT_VMEM during exec() but it needs more fleshing out). PR: kern/18209 Submitted by: Andrey Alekseyev [EMAIL PROTECTED], Dmitry Kim [EMAIL PROTECTED] MFC after: 7 days Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Modified files: sys/kern imgact_elf.c sys/compat/svr4 svr4_misc.c svr4_resource.c Log: Implement data, text, and vmem limit checking in the elf loader and svr4 compat code. Clean up accounting for multiple segments. Part 1/2. Submitted by: Andrey Alekseyev [EMAIL PROTECTED] (with some modifications) MFC after: 3 days Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. 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: alpha tinderbox failure - kernel is broken.
On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote: Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat Aug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/alpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. I was running -current from 2002/08/11 before without any sign about this kind of problem. Building libiconv failed reproduceable for me, but booting an 2002/08/11 kernel made me build the port. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
Bernd Walter wrote: On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote: Alexander Kabaev wrote: On Tue, 3 Sep 2002 16:56:52 +0200 Bernd Walter [EMAIL PROTECTED] wrote: Do you think this is the same reason? Yes. Folks, it is a *kernel* problem: peter@ashburton[6:38pm]~-111 cc -v Using built-in specs. Configured with: FreeBSD/alpha system compiler Thread model: posix gcc version 3.1 [FreeBSD] 20020509 (prerelease) peter@ashburton[6:38pm]~-112 c++ -static -o foo foo.c peter@ashburton[6:39pm]~-113 ./foo Abort(core dumped) peter@ashburton[6:39pm]~-114 uname -a FreeBSD ashburton.netplex.com.au 5.0-CURRENT FreeBSD 5.0-CURRENT #15: Sat A ug 31 16:02:39 PDT 2002 [EMAIL PROTECTED]:/home/src/sys/a lpha/compile/ASHBURTON alpha gcc-3.2.1 is not at fault. If it isn't kernel, it is library related. But Matt Dillon did commit a couple of changes in this area very recently. I think we should be looking around here: dillon 2002/06/25 17:29:28 PDT Revision ChangesPath 1.18 +3 -1 src/sys/sys/resource.h 1.149 +7 -0 src/sys/vm/vm_mmap.c 1.40 +5 -0 src/sys/vm/vm_unix.c dillon 2002/08/30 11:09:46 PDT Revision ChangesPath 1.50 +2 -3 src/sys/compat/svr4/svr4_misc.c 1.11 +1 -1 src/sys/compat/svr4/svr4_resource.c 1.121 +33 -10src/sys/kern/imgact_elf.c Probably the later one, the timing is about right. I was running -current from 2002/08/11 before without any sign about this kind of problem. Building libiconv failed reproduceable for me, but booting an 2002/08/11 kernel made me build the port. Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves the problem. It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed. 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: alpha tinderbox failure - kernel is broken.
: Building libiconv failed reproduceable for me, but booting an : 2002/08/11 kernel made me build the port. : :Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves :the problem. : :It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed. : :Cheers, :-Peter :-- :Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] Hold on, let me review the issue. Those changes were supposed to be low impact. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
:
:Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves
:the problem.
:
:It should probably be backed out and un-MFC'ed. *definately* un-MFC'ed.
:
: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
I have an alpha, let me try to reproduce this (it may take a while).
The datasize limit is fairly straight forward, either the failure
is for real or there is an accounting problem somewhere.
What happens if you replace this check in imgact_elf.c with a
printf of the conditional clauses instead of generating a failure?
+ if (data_size
+ imgp-proc-p_rlimit[RLIMIT_DATA].rlim_cur ||
+ text_size maxtsiz ||
+ data_size + text_size
+ imgp-proc-p_rlimit[RLIMIT_VMEM].rlim_cur) {
+ error = ENOMEM;
+ goto fail;
+ }
Does that unbreak it? That would tell us which clause is causing
the failure. You can probably do this faster then I can build
a new world and kernel for my alpha.
-Matt
Matthew Dillon
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
From the ktrace output it looks like the alpha is confused about
the datasize limit calculation. The program data appears to start
at the 4G mark so it is likely that the confusion is with the
'data_addr' variable whos calculation was changed slightly.
In that rev data_addr was set to the first data segment's address.
In the original code the data_addr was set to the last data segment's
address.
Try making the following change, from:
if (prot VM_PROT_WRITE) {
data_size += seg_size;
if (data_addr == 0)
data_addr = seg_addr;
} else {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
To:
if (prot VM_PROT_WRITE) {
data_size += seg_size;
data_addr = seg_addr;
} else {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
And see if that fixes the problem. I'm not sure why the alpha
is separating its first and last data segments by 4G of VM, some
debugging would be helpful:
if (prot VM_PROT_WRITE) {
printf(LOAD DATASEG %p %ld\n, (void *)seg_addr,
seg_size);
data_size += seg_size;
if (data_addr == 0)
data_addr = seg_addr;
} else {
printf(LOAD TEXTSEG %p %ld\n, (void *)seg_addr,
seg_size);
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
}
-Matt
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
On Tue, 2002/09/03 at 09:37:14 -0700, Peter Wemm wrote:
Bernd Walter wrote:
On Tue, Sep 03, 2002 at 09:01:07AM -0700, Peter Wemm wrote:
I was running -current from 2002/08/11 before without any sign about
this kind of problem.
Building libiconv failed reproduceable for me, but booting an
2002/08/11 kernel made me build the port.
Yes, imgact_elf.c rev 1.121 is the culprit. Reverting that change solves
the problem.
I have attached a patch which, I believe, should fix the problem. I
have no alpha box, so I cannot test kernel patches beyond compiling
them, so be warned, all below is just a theory, and the patch might of
course be broken (so keep kernel.old around :).
The problem was caused by the fact that on static executable, the text
segment is writable on alpha, so the heuristic prot VM_PROT_WRITE in
the ELF image activator will regard everything as a data segment. This
has the (non-fatal) effect that the program text size is regarded to
be 0.
Much more fatal, however, is that obreak() assumes that all data
segments start on consecutive pages (see below). Newer binutils will
however place the data segment on the next 64k page at the same offset
after the text segment (probably to make it easier for the OS to use
super pages), so that holes of more than a page size can occur.
obreak() will calculate the heap end address by taking the start
of the program data and adding the current data size.
The data size of a process is initially set by the image activator;
the ELF one sums up the number of 8k-pages actually needed to hold the
data. Now, if a hole happens to be between the segments that the
image activator thinks to hold data, (start address + number of used
pages) does of course not suffice to calculate the end address any
more.
The result is that the vm_map_insert() in obreak() can collide with
program segments when trying to insert a mapping starting with the old
address (that was calculated incorrectly), so it will fail, causing
ENOMEM to be returned.
For dynamic executables, this does not occur because the text segment
is not writable; the dynamic section, which is writable and executable
(because of the plt) starts after the hole and is directly followed by
the rest of the data.
The attached patch does just change the heuristics used to detect
text segments to look for executable segments (using an idea from
Peter). This results in the fact that dynamic section is viewed as
text, which should not break anything.
This way, it should be possible to avoid the hole currently; a real
fix would be to add a new vmspace field to represent the heap size
including holes which could then be used by obreak(), while vm_dsize
would only be used for statistics (which is however difficult to
maintain when shrinking below the initial size with brk()).
Can somebody who is feeling adventurous and has an alpha box please
test whether this fixes it for now?
Thanks,
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: kern/imgact_elf.c
===
RCS file: /home/ncvs/src/sys/kern/imgact_elf.c,v
retrieving revision 1.124
diff -u -r1.124 imgact_elf.c
--- kern/imgact_elf.c 2 Sep 2002 17:27:30 - 1.124
+++ kern/imgact_elf.c 3 Sep 2002 17:10:21 -
@@ -738,14 +738,14 @@
* to distinguish between the two for the purpose
* of limit checking and vmspace fields.
*/
- if (prot VM_PROT_WRITE) {
- data_size += seg_size;
- if (data_addr == 0)
- data_addr = seg_addr;
- } else {
+ if (prot VM_PROT_EXECUTE) {
text_size += seg_size;
if (text_addr == 0)
text_addr = seg_addr;
+ } else {
+ data_size += seg_size;
+ if (data_addr == 0)
+ data_addr = seg_addr;
}
/*
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: alpha tinderbox failure - kernel is broken.
:The attached patch does just change the heuristics used to detect :text segments to look for executable segments (using an idea from :Peter). This results in the fact that dynamic section is viewed as :text, which should not break anything. :This way, it should be possible to avoid the hole currently; a real :fix would be to add a new vmspace field to represent the heap size :including holes which could then be used by obreak(), while vm_dsize :would only be used for statistics (which is however difficult to :maintain when shrinking below the initial size with brk()). : :Can somebody who is feeling adventurous and has an alpha box please :test whether this fixes it for now? : :Thanks, : - Thomas Excellent Thomas! Thanks for tracking this down. Your patch looks far better then mine if the circumstances of the failure are as you believe. As soon as we get verification that your patch solves the problem, I will commit / MFC cycle it. I am also still somewhat worried about the data segment start address and I am wondering if I should remove the if (data_addr == 0) and instead unconditionally set data_addr to the last data segment loaded (which is what the original code did). -Matt To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
