Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
> On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
> > > Bmake bits for Gcc 3.1.
> >
> > This also vanished my YACC building fixes and broke world while
> > attempting to build `cc1plus' in a cross-tools stage. The changes
> > below fix this and CLEANFILES.
>
> These changes are wrong.
>
These changes have been verified to produce the same binaries
(except for cc1plus which is just broken without them), and
they are equivalent to what was already in -CURRENT before
your WIP_GCC31 merge commit.
> > RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
> ...
> > -c-parse.c: c-parse.in
> > +c-parse.y: c-parse.in
> > sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \
> > -e "/^ifc$$/d" \
> > -e "/^end ifc$$/d" \
> > - ${GCCDIR}/c-parse.in > c-parse.y
> > - ${YACC} -o c-parse.c.in c-parse.y
> > - sed -e "s/malloc/xmalloc/g" \
> > + -e "s/malloc/xmalloc/g" \
> > -e "s/realloc/xrealloc/g" \
> > - c-parse.c.in >c-parse.c
> > + ${.ALLSRC} > ${.TARGET}
>
> The malloc usage is in the Byacc output, not the input.
>
There's no difference, [b]yacc just copies C code blocks intact.
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
msg38170/pgp0.pgp
Description: PGP signature
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote: > On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote: > > On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote: > > > > Bmake bits for Gcc 3.1. > > > > > > This also vanished my YACC building fixes and broke world while > > > attempting to build `cc1plus' in a cross-tools stage. The changes > > > below fix this and CLEANFILES. > > > > These changes are wrong. > > > These changes have been verified to produce the same binaries > (except for cc1plus which is just broken without them), and > they are equivalent to what was already in -CURRENT before > your WIP_GCC31 merge commit. There is NO way you've bootstrapped GCC 3.1 using these patches. Remember a full bootstrap is a `make world ; make buildworld'. # cc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.1 20020509 (prerelease) # cd /usr/src/gnu/usr.bin/cc # make ===> cc_fbsd ... ===> cc_tools ... ===> cc_int ... cc -O -pipe -march=k6 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\" -I/usr/obj/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools -I/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc/config -I. -c c-parse.c c-parse.c:3047:29: attempt to use poisoned "realloc" c-parse.c:3048:16: attempt to use poisoned "malloc" c-parse.c:3053:31: attempt to use poisoned "realloc" c-parse.c:3054:18: attempt to use poisoned "malloc" *** Error code 1 I say again, the malloc usage is not in c-parse.in, it is in the parser driver produced by Byacc. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote: > > The malloc usage is in the Byacc output, not the input. > There's no difference, [b]yacc just copies C code blocks intact. No. Byacc copies C code blocks from the input grammer intact. It also adds more C code to the output. See src/usr.bin/yacc/skeleton.c. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
(add To: [EMAIL PROTECTED])
From: Garrett Rooney <[EMAIL PROTECTED]>
Subject: Re: Who broke 'make clean' for ports ?
Date: Sat, May 11, 2002 at 02:31:32AM JST
> there's a circular dependency that was just introduced to gettext.
> gettext now depends on expat, which depends on gmake, which depends on
> gettext.
Recently, I wrote a patch for bsd.port.mk that checks circular dependency.
If a dependency loop is found, it gives you a warning and
does not invoke 'make' process any further.
Someone, please test the patch below.
If no problem is found, I will send-pr(8).
Index: bsd.port.mk
===
RCS file: /home/ncvs/ports/Mk/bsd.port.mk,v
retrieving revision 1.411
diff -u -u -r1.411 bsd.port.mk
--- bsd.port.mk 27 Apr 2002 11:22:59 - 1.411
+++ bsd.port.mk 8 May 2002 17:13:40 -
@@ -684,6 +684,16 @@
.else
PORTSDIR?= /usr/ports
.endif
+.if exists(/bin/realpath)
+PORTSDIR!= /bin/realpath ${PORTSDIR}
+.else
+PORTSDIR_IS_SYMLINK!= if [ -L ${PORTSDIR} ]; then echo "yes" ; fi
+. if ${PORTSDIR_IS_SYMLINK} == "yes"
+. error"PORTSDIR" must not be a symlink
+. endif
+. undef PORTSDIR_IS_SYMLINK
+.endif
+
LOCALBASE?=${DESTDIR}/usr/local
X11BASE?= ${DESTDIR}/usr/X11R6
LINUXBASE?=${DESTDIR}/compat/linux
@@ -3068,11 +3078,20 @@
@${ALL-DEPENDS-LIST}
ALL-DEPENDS-LIST= \
+ parents="${PARENTS} ${.CURDIR}"; \
checked="${PARENT_CHECKED}"; \
- for dir in $$(${ECHO_CMD} "${FETCH_DEPENDS} ${BUILD_DEPENDS} ${LIB_DEPENDS}
${RUN_DEPENDS}" | ${TR} '\040' '\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//')
$$(${ECHO_CMD} ${DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/:.*//'); do \
+ for dir in $$( { ${ECHO_CMD} "${FETCH_DEPENDS} ${BUILD_DEPENDS} ${LIB_DEPENDS}
+${RUN_DEPENDS}" | ${TR} '\040' '\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//' ;
+${ECHO_CMD} ${DEPENDS} | ${TR} '\040' '\012' | ${SED} -e 's/:.*//'; } | sort -u); do \
if [ -d $$dir ]; then \
- if (${ECHO_CMD} $$checked | ${GREP} -qwv "$$dir"); then \
- child=$$(cd $$dir; ${MAKE} PARENT_CHECKED="$$checked"
all-depends-list); \
+ for p in $$parents; do \
+ if [ "$$p" = "$$dir" ]; then \
+ ${ECHO_MSG} "Dependency loop:" >&2; \
+ ${ECHO_MSG} "${.CURDIR} => $$p" >&2; \
+ ${ECHO_MSG} "" >&2; \
+ exit 1;\
+ fi; \
+ done; \
+ if $$( for c in $$checked; do if [ "$$dir" = "$$c" ]; then
+exit 1; fi ; done ); then \
+ child=$$(cd $$dir; ${MAKE} PARENTS="$$parents"
+PARENT_CHECKED="$$checked" all-depends-list); \
for d in $$child; do ${ECHO_CMD} $$d; done; \
${ECHO_CMD} $$dir; \
checked="$$dir $$child $$checked"; \
@@ -3155,11 +3174,20 @@
if [ "${CHILD_DEPENDS}" ]; then \
${ECHO_CMD} "${PKGNAME} ${.CURDIR}"; \
fi; \
+ parents="${PARENTS} ${.CURDIR}"; \
checked="${PARENT_CHECKED}"; \
- for dir in $$(${ECHO_CMD} "${LIB_DEPENDS} ${RUN_DEPENDS}" | ${TR} '\040'
'\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//') $$(${ECHO_CMD} ${DEPENDS} | ${TR}
'\040' '\012' | ${SED} -e 's/:.*//'); do \
+ for dir in $$( { ${ECHO_CMD} "${LIB_DEPENDS} ${RUN_DEPENDS}" | ${TR} '\040'
+'\012' | ${SED} -e 's/^[^:]*://' -e 's/:.*//' ; ${ECHO_CMD} ${DEPENDS} | ${TR} '\040'
+'\012' | ${SED} -e 's/:.*//'; } | sort -u); do \
if [ -d $$dir ]; then \
- if (${ECHO_CMD} $$checked | ${GREP} -qwv "$$dir"); then \
- childout=$$(cd $$dir; ${MAKE} CHILD_DEPENDS=yes
PARENT_CHECKED="$$checked" package-depends-list); \
+ for p in $$parents; do \
+ if [ "$$p" = "$$dir" ]; then \
+ ${ECHO_MSG} "Dependency loop:" >&2; \
+ ${ECHO_MSG} "${.CURDIR} => $$p" >&2; \
+ ${ECHO_MSG} "" >&2; \
+ exit 1;\
+ fi; \
+ done; \
+ if $$( for c in $$checked; do if [ "$$dir" = "$$c" ]; then
+exit 1; fi ; done ); then \
+ childout=$$(cd $$dir; ${MAKE} CHILD_DEPENDS=yes
+PARENTS="$$parents" PARENT_CHECKED="$$checked" package-depends-list); \
set -- $$childout; \
childname=""; childdir=""; \
while [ $$\# != 0 ]; do \
@@ -3173,7 +3201,7 @@
else \
${EC
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
Ruslan Ermilov wrote:
> On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
> > On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
> > > > Bmake bits for Gcc 3.1.
> > > =20
> > > This also vanished my YACC building fixes and broke world while
> > > attempting to build `cc1plus' in a cross-tools stage. The changes
> > > below fix this and CLEANFILES.
> >=20
> > These changes are wrong.
> > =20
> These changes have been verified to produce the same binaries
> (except for cc1plus which is just broken without them), and
> they are equivalent to what was already in -CURRENT before
> your WIP_GCC31 merge commit.
I dont think you've tested them properly. They will not work.
> > > RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
> > ...
> > > -c-parse.c: c-parse.in
> > > +c-parse.y: c-parse.in
> > > sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \
> > > -e "/^ifc$$/d" \
> > > -e "/^end ifc$$/d" \
> > > - ${GCCDIR}/c-parse.in > c-parse.y
> > > - ${YACC} -o c-parse.c.in c-parse.y
> > > - sed -e "s/malloc/xmalloc/g" \
> > > + -e "s/malloc/xmalloc/g" \
> > > -e "s/realloc/xrealloc/g" \
> > > - c-parse.c.in >c-parse.c
> > > + ${.ALLSRC} > ${.TARGET}
> >=20
> > The malloc usage is in the Byacc output, not the input.
> >=20
> There's no difference, [b]yacc just copies C code blocks intact.
Do not forget the driver code. There are malloc/calloc calls in the byacc
generated c-parse.c.. There are no malloc/calloc calls in the c-parse.in
file (see for yourself). If you actually test this, you will get a failure
due to 'poisoned' malloc/calloc/etc calls.
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: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 01:00:27AM -0700, David O'Brien wrote:
> On Sat, May 11, 2002 at 10:44:11AM +0300, Ruslan Ermilov wrote:
> > On Fri, May 10, 2002 at 04:41:53PM -0700, David O'Brien wrote:
> > > On Fri, May 10, 2002 at 06:04:27PM +0300, Ruslan Ermilov wrote:
> > > > > Bmake bits for Gcc 3.1.
> > > >
> > > > This also vanished my YACC building fixes and broke world while
> > > > attempting to build `cc1plus' in a cross-tools stage. The changes
> > > > below fix this and CLEANFILES.
> > >
> > > These changes are wrong.
> > >
> > These changes have been verified to produce the same binaries
> > (except for cc1plus which is just broken without them), and
> > they are equivalent to what was already in -CURRENT before
> > your WIP_GCC31 merge commit.
>
> There is NO way you've bootstrapped GCC 3.1 using these patches.
> Remember a full bootstrap is a `make world ; make buildworld'.
>
> # cc -v
> Using built-in specs.
> Configured with: FreeBSD/i386 system compiler
> Thread model: posix
> gcc version 3.1 20020509 (prerelease)
> # cd /usr/src/gnu/usr.bin/cc
> # make
> ===> cc_fbsd
> ...
> ===> cc_tools
> ...
> ===> cc_int
> ...
> cc -O -pipe -march=k6 -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\"/usr\"
> -I/usr/obj/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools
> -I/usr/src/gnu/usr.bin/for_ru/cc1/../cc_tools
> -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc
> -I/usr/src/gnu/usr.bin/for_ru/cc1/../../../../contrib/gcc/config -I.
> -c c-parse.c
> c-parse.c:3047:29: attempt to use poisoned "realloc"
> c-parse.c:3048:16: attempt to use poisoned "malloc"
> c-parse.c:3053:31: attempt to use poisoned "realloc"
> c-parse.c:3054:18: attempt to use poisoned "malloc"
> *** Error code 1
>
>
> I say again, the malloc usage is not in c-parse.in, it is in the parser
> driver produced by Byacc.
>
OK, now that you've explained it:
%%%
Index: cc1/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1/Makefile,v
retrieving revision 1.26
diff -u -r1.26 Makefile
--- cc1/Makefile10 May 2002 08:54:45 - 1.26
+++ cc1/Makefile11 May 2002 09:33:44 -
@@ -2,7 +2,7 @@
.include "../Makefile.inc"
-.PATH: ../cc_tools ${GCCDIR}
+.PATH: ${GCCDIR}
PROG= cc1
SRCS= main.c c-parse.c c-lang.c c-decl.c
@@ -17,17 +17,20 @@
#---
# C parser
-.ORDER: c-parse.c
-c-parse.c: c-parse.in
+
+YFLAGS=# don't need y.tab.h
+
+c-parse-in.y: c-parse.in
sed -e "/^ifobjc$$/,/^end ifobjc$$/d" \
-e "/^ifc$$/d" \
-e "/^end ifc$$/d" \
- ${GCCDIR}/c-parse.in > c-parse.y
- ${YACC} -o c-parse.c.in c-parse.y
+ ${.ALLSRC} > ${.TARGET}
+
+c-parse.c: c-parse-in.c
sed -e "s/malloc/xmalloc/g" \
-e "s/realloc/xrealloc/g" \
- c-parse.c.in >c-parse.c
+ ${.ALLSRC} > ${.TARGET}
-CLEANFILES+= c-parse.c c-parse.y # insurance
+CLEANFILES= c-parse-in.y c-parse-in.c c-parse.c
.include
Index: cc1obj/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1obj/Makefile,v
retrieving revision 1.20
diff -u -r1.20 Makefile
--- cc1obj/Makefile 10 May 2002 08:54:46 - 1.20
+++ cc1obj/Makefile 11 May 2002 09:33:44 -
@@ -2,7 +2,7 @@
.include "../Makefile.inc"
-.PATH: ../cc_tools ${GCCDIR}/objc ${GCCDIR}
+.PATH: ${GCCDIR}/objc ${GCCDIR}
PROG= cc1obj
SRCS= objc-parse.c objc-act.c objc-lang.c main.c c-decl.c
@@ -17,18 +17,21 @@
#---
# objc parser
-.ORDER: objc-parse.c
-objc-parse.c: c-parse.in
+
+YFLAGS=# don't need y.tab.h
+
+objc-parse-in.y: c-parse.in
sed -e "/^ifc$$/,/^end ifc$$/d" \
-e "/^ifobjc$$/d" \
-e "/^end ifobjc$$/d" \
- ${GCCDIR}/c-parse.in > objc-parse.y
- ${YACC} -o objc-parse.c.in objc-parse.y
+ ${.ALLSRC} > ${.TARGET}
+
+objc-parse.c: objc-parse-in.c
sed -e "s/malloc/xmalloc/g" \
-e "s/realloc/xrealloc/g" \
- objc-parse.c.in >objc-parse.c
+ ${.ALLSRC} > ${.TARGET}
-CLEANFILES+= objc-parse.c objc-parse.y # insurance
+CLEANFILES= objc-parse-in.y objc-parse-in.c objc-parse.c
#---
Index: cc1plus/Makefile
===
RCS file: /home/ncvs/src/gnu/usr.bin/cc/cc1plus/Makefile,v
retrieving revision 1.27
diff -u -r1.27 Makefile
--- cc1plus/Makefile10 May 2002 08:54:46 - 1.27
+++ cc1plus/Makefile11 May 2002 09:33:44 -
@@ -5,7 +5,7 @@
.PATH: ${GCCDIR}/cp ${GCCDIR}
PROG= cc1plus
-SRCS= parse.y cfns.h
+SRCS= parse.c parse.h cfns.h
SRCS+= main.c cp-lang.c
SRCS+= call.c
[panic] pb in ATA ? Or elsewhere ?
Hello,
I just got the following panic during resume. It is current just before gcc
3.1 went in.
FreeBSD sidhe.freenix.org FreeBSD 5.0-CURRENT #6: Thu May 9 17:14:15 CEST 2002
roberto@sidhe:/local/src/src/sys/i386/compile/SIDHE i386
Here is the trace: I'll keep the dump in case anyone want something from
it.
panicstr: bremfree: bp 0xc7405d80 not locked
panic messages:
---
panic: ata_dmasetup: transfer active on this device!
syncing disks... panic: bremfree: bp 0xc7405d80 not locked
Uptime: 14h17m42s
Dumping 255 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
...
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc017e53d in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc017e6d5 in panic (fmt=0xc026fd99 "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:490
#3 0xc01aa811 in bremfree (bp=0xc7405d80) at ../../../kern/vfs_bio.c:619
#4 0xc01abf47 in vfs_bio_awrite (bp=0xc7405d80)
at ../../../kern/vfs_bio.c:1593
#5 0xc020c118 in ffs_fsync (ap=0xcf10e990) at
../../../ufs/ffs/ffs_vnops.c:219
#6 0xc020a93e in ffs_sync (mp=0xcda98000, waitfor=2, cred=0xc7373f00,
td=0xc0298cc0) at vnode_if.h:441
#7 0xc01b8c71 in sync (td=0xc0298cc0, uap=0x0)
at ../../../kern/vfs_syscalls.c:1224
#8 0xc017e1fb in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc017e6d5 in panic (
fmt=0xc0260720 "ata_dmasetup: transfer active on this device!")
at ../../../kern/kern_shutdown.c:490
#10 0xc013d014 in ata_dmastart (atadev=0xc7376930, data=0xc94de000 "",
count=16384, dir=1) at ../../../dev/ata/ata-dma.c:1286
#11 0xc013e98e id_transfer (request=0xcfa26c00) at ../../../dev/ata/ata-disk.c:490
#12 0xc0132e67 in ata_start (ch=0xc7376900) at ../../../dev/ata/ata-all.c:678
#13 0xc013e462 in adstrategy (bp=0xc7493270) at ../../../dev/ata/ata-disk.c:301
#14 0xc018cecd in diskstrategy (bp=0xc7493270) at ../../../kern/subr_disk.c:376
#15 0xc015bf60 in spec_strategy (ap=0xcf10ead8) at ../../../fs/specfs/spec_vnops.c:497
#16 0xc015b839 in spec_vnoperate (ap=0xcf10ead8) at ../../../fs/specfs/spec_vnops.c:121
#17 0xc02137b5 in ufs_strategy (ap=0xcf10eb24) at vnode_if.h:762
#18 0xc0213fb5 in ufs_vnoperate (ap=0xcf10eb24) at ../../../ufs/ufs/ufs_vnops.c:2662
#19 0xc020c4a3 in ufs_bmaparray (vp=0xcecb80f0, bn=36, bnp=0xcf10eb80,
runp=0xcf10ec10, runb=0xcf10ec14) at vnode_if.h:762
#20 0xc020c1f0 in ufs_bmap (ap=0xcf10ebb4) at ../../../ufs/ufs/ufs_bmap.c:86
#21 0xc0213fb5 in ufs_vnoperate (ap=0xcf10ebb4) at ../../../ufs/ufs/ufs_vnops.c:2662
#22 0xc0225bf7 in vnode_pager_haspage (object=0xcecad840, pindex=146,
before=0xcf10ec14, after=0xcf10ec10) at vnode_if.h:744
#23 0xc021781f in vm_fault_additional_pages (m=0xc069bc98, rbehind=0,
rahead=1, marray=0xcf10ec9c, reqpage=0xcf10ec68)
at ../../../vm/vm_pager.h:167
#24 0xc0216e17 in vm_fault (map=0xcececb7c, vaddr=135114752,
fault_type=2 '\002', fault_flags=8) at ../../../vm/vm_fault.c:482
#25 0xc024be8e in trap_pfault (frame=0xcf10ed48, usermode=1, eva=135118592)
at ../../../i386/i386/trap.c:716
#26 0xc024b9ff in trap (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = -1077936660, tf_esi = -1077936676, tf_ebp = -1077936684,
tf_isp = -820974220, tf_ebx = 3, tf_edx = 0, tf_ecx = 0,
tf_eax = -1077936528, tf_trapno = 12, tf_err = 6, tf_eip = 134512864,
tf_cs = 31, tf_eflags = 66178, tf_esp = -1077936708, tf_ss = 47})
at ../../../i386/i386/trap.c:312
#27 0x80480e0 in ?? ()
--
Ollivier ROBERT -=- FreeBSD: The Power to Serve! -=- [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
[panic] USB related panic
FreeBSD sidhe.freenix.org FreeBSD 5.0-CURRENT #6: Thu May 9 17:14:15 CEST 2002
[EMAIL PROTECTED]:/local/src/src/sys/i386/compile/SIDHE i386
Sony VAIO Z600TEK, current just before gcc 3.1.
Having tested the usb subsystem a few weeks ago (it hung during resume), I
decided to try after the latest fixes from Joe. kldload usb; kldload ums
and I plugged my optical mouse (see below the messages).
Then I suspend/resume the machine. This time it didn't hung (thanks Joe!)
but the mouse wasn't functionning. Killing and restarting usbd gave
nothing. I then decided to kill moused: instant panic...
Joe, any idea?
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xdeadc0de
fault code = supervisor read, page not present
instruction pointer = 0x8:0xce8fd9f7
stack pointer = 0x10:0xce7f6ac8
frame pointer = 0x10:0xce7f6adc
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 536 (moused)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc7496f60 not locked
Uptime: 30m26s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc017e53d in boot (howto=260) at ../../../kern/kern_shutdown.c:346
#2 0xc017e6d5 in panic (fmt=0xc026fd99 "bremfree: bp %p not locked")
at ../../../kern/kern_shutdown.c:490
#3 0xc01aa811 in bremfree (bp=0xc7496f60) at ../../../kern/vfs_bio.c:619
#4 0xc01abf47 in vfs_bio_awrite (bp=0xc7496f60)
at ../../../kern/vfs_bio.c:1593
#5 0xc020c118 in ffs_fsync (ap=0xce7f6980) at
../../../ufs/ffs/ffs_vnops.c:219
#6 0xc020a93e in ffs_sync (mp=0xcda98000, waitfor=2, cred=0xc7373f00,
td=0xc0298cc0) at vnode_if.h:441
#7 0xc01b8c71 in sync (td=0xc0298cc0, uap=0x0)
at ../../../kern/vfs_syscalls.c:1224
#8 0xc017e1fb in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#9 0xc017e6d5 in panic (fmt=0xc0289b3e "%s")
at ../../../kern/kern_shutdown.c:490
#10 0xc024c1e2 in trap_fatal (frame=0xce7f6a88, eva=3735929054)
at ../../../i386/i386/trap.c:826
#11 0xc024bf2d in trap_pfault (frame=0xce7f6a88, usermode=0, eva=3735929054)
at ../../../i386/i386/trap.c:740
#12 0xc024bb73 in trap (frame={tf_fs = -1070858216, tf_es = -830537712,
tf_ds = 16, tf_edi = -34, tf_esi = -833817856, tf_ebp = -830510372,
tf_isp = -830510412, tf_ebx = -830098048, tf_edx = 0, tf_ecx = 4,
tf_eax = -559038242, tf_trapno = 12, tf_err = 0, tf_eip = -829433353,
tf_cs = 8, tf_eflags = 66182, tf_esp = -833817856, tf_ss = -833298432})
at ../../../i386/i386/trap.c:426
#13 0xce8fd9f7 in ?? ()
#14 0xce900969 in ?? ()
#15 0xce900b34 in ?? ()
#16 0xce8fd9c5 in ?? ()
#17 0xce8fd6f0 in ?? ()
#18 0xce7bca11 in ?? ()
#19 0xce7bca8e in ?? ()
#20 0xc015c201 in spec_close (ap=0xce7f6b90)
at ../../../fs/specfs/spec_vnops.c:617
#21 0xc015b839 in spec_vnoperate (ap=0xce7f6b90)
at ../../../fs/specfs/spec_vnops.c:121
#22 0xc01beb20 in vn_close (vp=0xce50, flags=7, cred=0xce85b380,
td=0xce7f2728) at vnode_if.h:183
#23 0xc01bf726 in vn_closefile (fp=0xce39ad98, td=0xce7f2728)
at ../../../kern/vfs_vnops.c:798
#24 0xc0169c8a in fdrop_locked (fp=0xce39ad98, td=0xce7f2728)
at ../../../sys/file.h:225
#25 0xc016946f in fdrop (fp=0xce39ad98, td=0xce7f2728)
at ../../../kern/kern_descrip.c:1635
#26 0xc016943c in closef (fp=0xce39ad98, td=0xce7f2728)
at ../../../kern/kern_descrip.c:1621
#27 0xc0168e2d in fdfree (td=0xce7f2728) at
../../../kern/kern_descrip.c:1375
#28 0xc016d8bf in exit1 (td=0xce7f2728, rv=0) at
../../../kern/kern_exit.c:201
#29 0xc016d642 in sys_exit (td=0xce7f2728, uap=0xce7f6d20)
at ../../../kern/kern_exit.c:109
#30 0xc024c46b in syscall (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 0, tf_esi = -1, tf_ebp = -1077938896, tf_isp = -830509708,
tf_ebx = 672189240, tf_edx = 672188640, tf_ecx = -1077938384,
tf_eax = 1, tf_trapno = 12, tf_err = 2, tf_eip = 671786631, tf_cs = 31,
tf_eflags = 647, tf_esp = -1077938940, tf_ss = 47})
at ../../../i386/i386/trap.c:1019
#31 0xc024002d in syscall_with_err_pushed ()
#32 0x8049f31 in ?? ()
#33
#34 0x8049843 in ?? ()
#35 0x8049843 in ?? ()
#36 0x8048de9 in ?? ()
-=-=-=-
May 11 13:50:32 sidhe kernel: uhci0: p
ort 0xfca0-0xfcbf irq 9 at device 7.2 on pci0
May 11 13:50:32 sidhe kernel: usb0: on
uhci0
May 11 13:50:32 sidhe kernel: usb0: USB revision 1.0
May 11 13:50:32 sidhe kernel: uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.
00, addr 1
May 11 13:50:32 sidhe kernel: uhub0: 2 ports with 2 removable, self powered
May 11 13:50:34 sidhe kernel: uhub1: Philips Semiconductors hub, class 9/0, rev
1.10/1.10, addr 2
May 11 1
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
KOMATSU Shinichiro wrote: > > (add To: [EMAIL PROTECTED]) > > From: Garrett Rooney <[EMAIL PROTECTED]> > Subject: Re: Who broke 'make clean' for ports ? > Date: Sat, May 11, 2002 at 02:31:32AM JST > > > there's a circular dependency that was just introduced to gettext. > > gettext now depends on expat, which depends on gmake, which depends on > > gettext. > > Recently, I wrote a patch for bsd.port.mk that checks circular dependency. > If a dependency loop is found, it gives you a warning and > does not invoke 'make' process any further. > > Someone, please test the patch below. > If no problem is found, I will send-pr(8). I don't think that we really need such patch. In 99.% of cases it would just waste CPU cycles. Circular dependency is a bug and as such it doesn't need to be a supported "special case". -Maxim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
* Maxim Sobolev <[EMAIL PROTECTED]> [2002-05-11 15:00]:
> KOMATSU Shinichiro wrote:
> >
> > (add To: [EMAIL PROTECTED])
> >
> > From: Garrett Rooney <[EMAIL PROTECTED]>
> > Subject: Re: Who broke 'make clean' for ports ?
> > Date: Sat, May 11, 2002 at 02:31:32AM JST
> >
> > > there's a circular dependency that was just introduced to gettext.
> > > gettext now depends on expat, which depends on gmake, which depends on
> > > gettext.
> >
> > Recently, I wrote a patch for bsd.port.mk that checks circular dependency.
> > If a dependency loop is found, it gives you a warning and
> > does not invoke 'make' process any further.
> >
> > Someone, please test the patch below.
> > If no problem is found, I will send-pr(8).
> I don't think that we really need such patch. In 99.% of cases it
> would just waste CPU cycles. Circular dependency is a bug and as such
> it doesn't need to be a supported "special case".
But it might be a good idea to incorporate this functionality into
${PORTSDIR}/devel/portlint.
Regards,
Olli
--
Institute for Software Technology & Institute for Information Systems
Department of Computing Science, Federal Armed Forces University Munich
--- http://ist.unibw-muenchen.de/People/obraun/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
buildworld seems broken (very early in process)
OK; I managed to get -CURRENT built yesterday, but the breakage I'm now seeing is ... different. It's not a matter of warnings, anyway: cc -O -pipe -D__FBSDID=__RCSID -static -o yacc closure.o error.o lalr.o lr0.o main.o mkpar.o output.o reader.o skeleton.o symtab.o verbose.o warshall.o sh /usr/src/tools/install.sh -c -s -o root -g wheel -m 555 yacc /usr/obj/usr/src/i386/usr/bin sh /usr/src/tools/install.sh -c -o root -g wheel -m 555 /usr/src/usr.bin/yacc/yyfix.sh /usr/obj/usr/src/i386/usr/bin/yyfix /usr/obj/usr/src/i386/usr/bin/byacc -> /usr/obj/usr/src/i386/usr/bin/yacc cd /usr/src/usr.bin/colldef; make obj; make depend; make all; make DESTDIR=/usr/obj/usr/src/i386 install /usr/obj/usr/src/i386/usr/src/usr.bin/colldef created for /usr/src/usr.bin/colldef yacc -d /usr/src/usr.bin/colldef/parse.y cp y.tab.c parse.c lex -t -8 -i /usr/src/usr.bin/colldef/scan.l > scan.c rm -f .depend mkdep -f .depend -a-I. -I/usr/src/usr.bin/colldef -I/usr/src/usr.bin/colldef/../../lib/libc/locale -DCOLLATE_DEBUG -DYY_NO_UNPUT -D__FBSDID=__RCSID parse.c scan.c cc: parse.c: No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/src/usr.bin/colldef. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. CVSup history of late: freebeast(5.0-C)[7] tail /var/log/cvsup-history.log CVSup begin from cvsup14.freebsd.org at Wed May 8 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Wed May 8 03:53:48 PDT 2002 CVSup begin from cvsup14.freebsd.org at Wed May 8 12:03:54 PDT 2002 CVSup ended from cvsup14.freebsd.org at Wed May 8 12:10:35 PDT 2002 CVSup begin from cvsup14.freebsd.org at Thu May 9 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Thu May 9 03:53:44 PDT 2002 CVSup begin from cvsup14.freebsd.org at Fri May 10 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Fri May 10 03:56:26 PDT 2002 CVSup begin from cvsup14.freebsd.org at Sat May 11 03:47:02 PDT 2002 CVSup ended from cvsup14.freebsd.org at Sat May 11 03:54:26 PDT 2002 freebeast(5.0-C)[8] And yes, after the usual "cvs update," I saw that UPDATING was updated, saw the comment that reinforced obrien's message to -current yesterday about coping with CVS repository weirdness, and took the recommended action as a preemptive strike, so src/contrib/gcc should be clean -- though it appears I didn't get that far Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] Microsoft products -- for those times when reliability just doesn't matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Current compile error at kerverosIV/lib
Recent current compilation causes the following error; : : : (snip) cc -O2 -pipe -DENCRYPTION -DAUTHENTICATION -DSRA -I/usr/src/kerberosIV/lib/libtelnet/../../../crypto/telnet -DKRB4 -I/usr/src/kerberosIV/lib/libtelnet/../../../crypto/kerberosIV/lib/krb -I/usr/src/kerberosIV/lib/libtelnet/../../include -Wall -DHAVE_CONFIG_H -I/usr/local/obj/usr/src/kerberosIV/lib/libtelnet/../../include -DBINDIR=\"/usr/bin\" -DSBINDIR=\"/usr/sbin\" -DLIBEXECDIR=\"/usr/libexec\" -Werror -Wall -Wno-format-y2k -Wno-uninitialized -c /usr/src/crypto/telnet/libtelnet/kerberos.c -o kerberos.o cc1: warnings being treated as errors /usr/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /usr/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /usr/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /usr/src/kerberosIV/lib. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Some ports fail on -current because ${BINOWN} and ${BINGRP} seems to be not defined
This is presumably fallout from the /usr/share/mk rearrangement, but rev 1.306 of /usr/share/mk/bsd.port.mk should fix this. Oh, hey, are the failing ports all ones that use bsd.port.pre.mk and bsd.port.post.mk? I guess bsd.port.pre.mk needs the same fix as bsd.port.mk does. Bill To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pam su
On 11-May-2002 Galen Sampson wrote: > Hello all, > > After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a > mergemaster I am seeing the following on the console when I su: Don't mergemaster until after you've installworld'd. > Is this normal? Welcome to current. It will go away when you get things back in sync again. -- 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: Some ports fail on -current because ${BINOWN} and ${BINGRP} seems to be not defined
* Bill Fenner <[EMAIL PROTECTED]> [2002-05-11 17:12]: > This is presumably fallout from the /usr/share/mk rearrangement, but > rev 1.306 of /usr/share/mk/bsd.port.mk should fix this. on my -current box it doesn't. The world was build last Saturday 2002-05-04, including rev 1.306 of /usr/share/mk/bsd.port.mk: $FreeBSD: src/share/mk/bsd.port.mk,v 1.306 2002/04/19 07:43:50 ru Exp $ > Oh, hey, are the failing ports all ones that use bsd.port.pre.mk and > bsd.port.post.mk? no, e.g. /usr/ports/audio/cam fails and uses bsd.port.mk. Regards, Olli -- Institute for Software Technology & Institute for Information Systems Department of Computing Science, Federal Armed Forces University Munich --- http://ist.unibw-muenchen.de/People/obraun/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
alpha tinderbox failure
-- >>> 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 >/tmp/des/obj/alpha/.amd_mnt/freefall/host/d/home/des/tinderbox/src/alpha/usr/include -- >>> stage 4: building libraries -- ===> libkdb ... /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function `kdb_encrypt_key': /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type ===> libkrb ===> libtelnet cc1: warnings being treated as errors /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src/kerberosIV/lib. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. *** Error code 1 Stop in /.amd_mnt/freefall/host/d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
re: alpha tinderbox failure
> ===> libtelnet
> cc1: warnings being treated as errors
> /.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:
>In function
> `kerberos4_cksum':
>
>/.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496:
> warning:
> unreachable code at beginning of switch statement
> *** Error code 1
%%%
int
kerberos4_cksum(unsigned char *d, int n)
{
int ck = 0;
/*
* A comment is probably needed here for those not
* well versed in the "C" language. Yes, this is
* supposed to be a "switch" with the body of the
* "switch" being a "while" statement. The whole
* purpose of the switch is to allow us to jump into
* the middle of the while() loop, and then not have
* to do any more switch()s.
*
* Some compilers will spit out a warning message
* about the loop not being entered at the top.
*/
switch (n&03)
while (n > 0) {
case 0:
ck ^= (int)*d++ << 24;
--n;
case 3:
ck ^= (int)*d++ << 16;
--n;
case 2:
ck ^= (int)*d++ << 8;
--n;
case 1:
ck ^= (int)*d++;
--n;
}
return(ck);
}
%%%
Thanks.
Regards.
P.S. JFYI. :-)
--
Hiten Pandya
http://storm.uk.FreeBSD.org/~hiten
Finger [EMAIL PROTECTED] for PGP public key
-- 4FB9 C4A9 4925 CF97 9BF3 ADDA 861D 5DBD E4E3 03C3
msg38186/pgp0.pgp
Description: PGP signature
Re: alpha tinderbox failure
Hiten Pandya <[EMAIL PROTECTED]> writes:
> > ===> libtelnet
> > cc1: warnings being treated as errors
> >
>/.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:
>In function
> > `kerberos4_cksum':
> >
>/.amd_mnt/freefall/host/d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496:
> warning:
> > unreachable code at beginning of switch statement
> > *** Error code 1
>
>
> %%%
> int
> kerberos4_cksum(unsigned char *d, int n)
> {
> int ck = 0;
>
> /*
>* A comment is probably needed here for those not
>* well versed in the "C" language. Yes, this is
>* supposed to be a "switch" with the body of the
>* "switch" being a "while" statement. The whole
>* purpose of the switch is to allow us to jump into
>* the middle of the while() loop, and then not have
>* to do any more switch()s.
>*
>* Some compilers will spit out a warning message
>* about the loop not being entered at the top.
>*/
> switch (n&03)
> while (n > 0) {
> case 0:
> ck ^= (int)*d++ << 24;
> --n;
> case 3:
> ck ^= (int)*d++ << 16;
> --n;
> case 2:
> ck ^= (int)*d++ << 8;
> --n;
> case 1:
> ck ^= (int)*d++;
> --n;
> }
> return(ck);
> }
> %%%
Hmm, does this mean Duff's Device is not valid C?
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote: > > I say again, the malloc usage is not in c-parse.in, it is in the parser > > driver produced by Byacc. > > > OK, now that you've explained it: I'll look this patch over carefully, but at first glance it all seems like stylistic changes. Does it fix a bug, or you just don't like how I did things? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
fatal trap 21 panic in today's current
I get the following panic (hand transribed): Fatal trap 21: FPU bounds check fault while in kernel mode instruction pointer = 0x8:0xc02433f5 stack pointer= 0x10:c040fc60 frame pointer= 0x10:c040fc7c code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags = interrupt enabled, IOPL = 0 current process = 0 (swapper) kernel: type 21 trap, code=0 stopped at bios16+0x1b1: movl $0x16,%edx A trace at the DB> prompt gives bios16 pnpbios_identity bus_generic_probe isa_probe_children configure mi_startup begin I did not get a dump because a "continue" at DB> actually permitted the machine to complete the boot process. Note, this panic occurs if I have hint.acpi.0.disable="1" set in /boot/loader.conf. The machine would not boot with ACPI enabled in the May 2002 time frame. If I comment out hint.acpi.0.disable the machine boots fine, so it appears that ACPI can no longer be disabled. dmesg included below. Finally, yes I updated world, kernel, and kernel modules with the new gcc. -- Steve http://troutmask.apl.washington.edu/~kargl/ Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Wed May 1 16:49:56 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/TROUTMASK Preloaded elf kernel "/boot/kernel/kernel" at 0xc03d7000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc03d70a8. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc03d7154. Preloaded elf module "/boot/kernel/snd_ds1.ko" at 0xc03d7200. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc03d72ac. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 141190 Hz CPU: AMD Athlon(tm) Processor (1000.04-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044 real memory = 402587648 (393152K bytes) avail memory = 386912256 (377844K bytes) Pentium Pro MTRR support enabled VESA: v1.2, 4096k memory, flags:0x0, mode table:0xc00c1bdf (c0001bdf) VESA: S3 Incorporated. 86C325 Using $PIR table, 9 entries at 0xc00fddd0 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0 acpi_cpu0: on acpi0 acpi_button0: on acpi0 acpi_button1: on acpi0 acpi_pcib0: port 0x6000-0x607f,0x5000-0x500f,0x4080-0x40ff,0x4000-0x407f,0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 isab0: at device 7.0 on pci0 isa0: on isab0 xl0: <3Com 3c905-TX Fast Etherlink XL> port 0xdc00-0xdc3f irq 11 at device 8.0 on pci0 xl0: Ethernet address: 00:60:97:98:38:65 miibus0: on xl0 nsphy0: on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pcm0: mem 0xd900-0xd9007fff irq 11 at device 11.0 on pci0 ahc0: port 0xe000-0xe0ff mem 0xd9008000-0xd9008fff irq 15 at device 13.0 on pci0 aic7880: Ultra Single Channel A, SCSI Id=7, 16/253 SCBs pci0: at device 17.0 (no driver attached) atspeaker0 port 0x61 on acpi0 fdc0: port 0x3f7,0x3f0-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A ppc0 port 0x378-0x37f irq 7 on acpi0 ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xc8000-0xcc7ff,0xc-0xc7fff on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <8 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% sa0 at ahc0 bus 0 target 5 lun 0 sa0: Removable Sequential Access SCSI-2 device sa0: 5.000MB/s transfers (5.000MHz, offset 15) cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 4.237MB/s transfers (4.237MHz, offset 15) cd0: cd present [785028 x 512 byte records] da2 at ahc0 bus 0 target 3 lun 0 da2: Fixed Direct Access SCSI-2 device da2: 10.000MB/s transfers (10.000MHz, offset 8) da2: 699MB (1431760 512 byte sectors: 64H 32S/T 699C) da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-3 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C) Mounting root from ufs:/dev/da0s1a cd1 at ahc0 bus 0 target 6 lun 0 cd1: Removable CD-ROM SCSI-2 device cd1: 10.000MB/s transfers (10.000MHz, offs
-current and vmware2
seems something broke in the networking side of things using host-only networking.. vmnet1 doesn;t show up any more.. If I have a moment I'll look for it but if anyone has familiarity with it feel free to get there forst.. oh yeah.. it doesn't compile any more either... -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: fatal trap 21 panic in today's current
Dang. I sent the wrong dmesg output. The correct dmesg follows. Note the broken ACPI. Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat May 11 09:34:09 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/HOTRATS Preloaded elf kernel "/boot/kernel/kernel" at 0xc0427000. Preloaded elf module "/boot/kernel/linux.ko" at 0xc04270a8. Preloaded elf module "/boot/kernel/miibus.ko" at 0xc0427154. Preloaded elf module "/boot/kernel/if_rl.ko" at 0xc0427200. Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc04272ac. Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc0427358. Preloaded elf module "/boot/kernel/agp.ko" at 0xc042740c. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04274b4. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1210791436 Hz CPU: AMD Athlon(tm) Processor (1210.79-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x642 Stepping = 2 Features=0x183f9ff AMD Features=0xc044 real memory = 134217728 (131072K bytes) avail memory = 126021632 (123068K bytes) Pentium Pro MTRR support enabled VESA: v2.0, 8128k memory, flags:0x0, mode table:0xc03262c2 (122) VESA: ATI MACH64 Using $PIR table, 9 entries at 0xc00f1720 ACPI-0224: *** Warning: Invalid table signature \M-0\M^Q\M-~\M-G found ACPI-0181: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATUR E ACPI: table load failed: AE_BAD_SIGNATURE npx0: on motherboard npx0: INT 16 interface pcib0: at pcibus 0 on motherboard pci0: on pcib0 agp0: mem 0xe600-0xe7ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 0.0 (no driver attached) isab0: at device 4.0 on pci0 isa0: on isab0 pci0: at device 4.1 (no driver attached) pci0: at device 4.2 (no driver attached) pci0: at device 4.3 (no driver attached) pci0: at device 4.4 (no driver attached) ahc0: port 0x9400-0x94ff mem 0xe300-0xe3000fff i rq 12 at device 10.0 on pci0 aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs pcm0: port 0x9000-0x90ff irq 10 at device 11.0 on pci 0 rl0: port 0x8800-0x88ff mem 0xe280-0xe28000ff ir q 15 at device 13.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode lock order reversal 1st 0xc8ea85a4 rl0 (network driver) @ /usr/src/sys/pci/if_rl.c:855 2nd 0xc02a9580 allproc (allproc) @ /usr/src/sys/kern/kern_fork.c:309 rl0: Ethernet address: 00:00:c5:b3:45:24 miibus0: on rl0 rlphy0: on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci0: at device 17.0 (no driver attached) sc0: on isa0 sc0: VGA <8 virtual consoles, flags=0x200> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 atkbdc0: at port 0x64,0x60 on isa0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 fdc0: at port 0x3f7,0x3f 0-0x3f5 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: <1440-KB 3.5" drive> on fdc0 drive 0 ppc0: at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold ppbus0: IEEE1284 device found /NIBBLE/ECP/ECP_RLE Probing for PnP devices on ppbus0: ppbus0: ENHANCED PCL5,PJL,POSTSCRIPT lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1 at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A Timecounters tick every 10.000 msec Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/da0s2a cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 10.000MB/s transfers (10.000MHz, offset 15) cd0: Attempt to query device size failed: NOT READY, Medium not present da1 at ahc0 bus 0 target 1 lun 0 da1: Fixed Direct Access SCSI-2 device da1: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da1: 4148MB (8496960 512 byte sectors: 255H 63S/T 528C) da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 10.000MB/s transfers (10.000MHz, offset 15), Tagged Queueing Enabled da0: 8761MB (17942584 512 byte sectors: 255H 63S/T 1116C) -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > seems something broke in the networking side of things using host-only > networking.. vmnet1 doesn;t show up any more.. Does vmware2 crash when it is started? I was recently trying vmware2 on FreeBSD-CURRENT, but gaveup because it tried to load the if_tap driver if I am right, and kldload was just stuck. Regards. -- Hiten __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
patch to add athlon to bsd.cpu.mk
This applies to post gcc 3.1 upgrades.
--
Steve
http://troutmask.apl.washington.edu/~kargl/
--- bsd.cpu.mk.orig Sat May 11 11:57:01 2002
+++ bsd.cpu.mk Sat May 11 12:00:49 2002
@@ -22,7 +22,7 @@
. elif ${CPUTYPE} == "pentium"
CPUTYPE = i586
. elif ${CPUTYPE} == "athlon"
-CPUTYPE = k7
+CPUTYPE = athlon
. endif
.endif
@@ -32,8 +32,8 @@
.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS)
. if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
-_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
+. if ${CPUTYPE} == "athlon"
+_CPUCFLAGS = -march=athlon
. elif ${CPUTYPE} == "k6-2"
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == "k6"
@@ -83,8 +83,8 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. if ${CPUTYPE} == "athlon"
+MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6-2"
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6"
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
Hiten Pandya wrote: > > --- Julian Elischer <[EMAIL PROTECTED]> wrote: > > seems something broke in the networking side of things using host-only > > networking.. vmnet1 doesn;t show up any more.. > > Does vmware2 crash when it is started? I was recently trying vmware2 on > FreeBSD-CURRENT, but gaveup because it tried to load the if_tap driver if > I am right, and kldload was just stuck. yeah I just tracked it doen to if_tap not working as a module any more... don't know what broke it but it's not showing up in /dev/ (devfs) any more and not creating interfaces.. > > Regards. > > -- Hiten > > __ > Do You Yahoo!? > LAUNCH - Your Yahoo! Music Experience > http://launch.yahoo.com -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bsd.port.mk dependency loop checking patch (Re: Who broke 'make clean' for ports ?)
On Sat, May 11, 2002 at 04:00:53PM +0300, Maxim Sobolev wrote: > KOMATSU Shinichiro wrote: > > > > (add To: [EMAIL PROTECTED]) > > > > From: Garrett Rooney <[EMAIL PROTECTED]> > > Subject: Re: Who broke 'make clean' for ports ? > > Date: Sat, May 11, 2002 at 02:31:32AM JST > > > > > there's a circular dependency that was just introduced to gettext. > > > gettext now depends on expat, which depends on gmake, which depends on > > > gettext. > > > > Recently, I wrote a patch for bsd.port.mk that checks circular dependency. > > If a dependency loop is found, it gives you a warning and > > does not invoke 'make' process any further. > > > > Someone, please test the patch below. > > If no problem is found, I will send-pr(8). > > I don't think that we really need such patch. In 99.% of cases it > would just waste CPU cycles. Circular dependency is a bug and as such > it doesn't need to be a supported "special case". Actually it would be useful to have this functionality somewhere. I recently spent a couple of hours trying to track down a circular dependency I had introduced via a bsd.port.mk patch. The main symptom was that the make_index script would just go into a loop and exhaust memory. I ended up finding it by adding all sorts of debugging printfs to the perl script, but this was pretty ugly. Kris msg38195/pgp0.pgp Description: PGP signature
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote: > This applies to post gcc 3.1 upgrades. Thanks! Committed. Note that GCC 3.1 also supports SSE instructions. (I think SSE2 will be in 3.2, or did that make it into 3.1 recently??) If anyone has other _tested_ updates for Alpha (ev6 support), Pentium-IV, please let me know. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote: > This applies to post gcc 3.1 upgrades. Eek, actually there was no reason to remove K7. It should still be accepted as an alias for "athlon". Your patch broke existing settings, including mine. :-( "Be liberal in what you accept, and strict in what you output". To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote:
> -. if ${CPUTYPE} == "k7"
> -_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
> +. if ${CPUTYPE} == "athlon"
> +_CPUCFLAGS = -march=athlon
AFAIK the k7 is a valid name for the athlon (marchitecture name).
Don't break backwards compatibility here.
Kris
msg38198/pgp0.pgp
Description: PGP signature
Re: -current and vmware2
--- Julian Elischer <[EMAIL PROTECTED]> wrote: > yeah > > I just tracked it doen to if_tap not working as a module any more... > > don't know what broke it but it's not showing up in /dev/ (devfs) any more > and not creating interfaces.. Exactly the same problem, but when kldload is called, it doesn't let go off the controling terminal. and doesn't let a reboot kill it; and sometimes the machine doesnt agree to reboot i.e. leading to a manual reboot. Regards, -- Hiten __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Perl scripts that need rewriting - Progress!
> On Thursday 09 May 2002 02:33 pm, Mark Murray wrote: > > Hi > > > > The response to the perl-script rewriting project has been > > very hearteningly _fantastic_! > > > > Here is the list as it stands. The gaps are fairly obvious (and > > probably mostly not critical in the short term): > > > > /usr/bin/afmtodit > > ill take this rewrite You got it! :-) M -- o Mark Murray \_ O.\_Warning: this .sig is umop ap!sdn To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
embellish of bsd.cpu.mk
[bogus From: address, because people cannot be bothered to respect Reply-To:]
What do people think of this patch to embellish bsd.cpu.mk?
I also changed pN to be the more canonical pentiumN (with pN aliases of
course).
Index: bsd.cpu.mk
===
RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
retrieving revision 1.9
diff -u -r1.9 bsd.cpu.mk
--- bsd.cpu.mk 11 May 2002 20:18:54 - 1.9
+++ bsd.cpu.mk 11 May 2002 20:31:28 -
@@ -6,6 +6,9 @@
.if ${MACHINE_ARCH} == "i386"
CPUTYPE ?= i386
.elif ${MACHINE_ARCH} == "alpha"
+if !defined(CPUTYPE)
+CPUTUNE ?= ev56
+.endif
CPUTYPE ?= ev4
.elif ${MACHINE_ARCH} == "ia64"
CPUTYPE ?= itanium
@@ -17,12 +20,30 @@
# between e.g. i586 and pentium)
.if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "pentiumpro"
-CPUTYPE = i686
-. elif ${CPUTYPE} == "pentium"
+. if ${CPUTYPE} == "pentium"
CPUTYPE = i586
-. elif ${CPUTYPE} == "athlon"
-CPUTYPE = k7
+. elif ${CPUTYPE} == "i686"
+CPUTYPE = pentiumpro
+. elif ${CPUTYPE} == "p2"
+CPUTYPE = pentium2
+. elif ${CPUTYPE} == "p3"
+CPUTYPE = pentium3
+. elif ${CPUTYPE} == "p4"
+CPUTYPE = pentium4
+. elif ${CPUTYPE} == "k7"
+CPUTYPE = athlon
+. elif ${CPUTYPE} == "duron"
+CPUTYPE = athlon
+. endif
+.elif ${MACHINE_ARCH} == "alpha"
+. if ${CPUTYPE} == "21264a"
+CPUTYPE = ev67
+. if ${CPUTYPE} == "21264"
+CPUTYPE = ev6
+. elif ${CPUTYPE} == "21164pc"
+CPUTYPE = pca56
+. elif ${CPUTYPE} == "21164a"
+CPUTYPE = ev56
. endif
.endif
@@ -36,7 +57,7 @@
.if !defined(NO_CPU_CFLAGS) || !defined(NO_CPU_COPTFLAGS)
. if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
+. if ${CPUTYPE} == "athlon"
_CPUCFLAGS = -march=athlon
. elif ${CPUTYPE} == "k6-2"
_CPUCFLAGS = -march=k6
@@ -44,13 +65,13 @@
_CPUCFLAGS = -march=k6
. elif ${CPUTYPE} == "k5"
_CPUCFLAGS = -march=pentium
-. elif ${CPUTYPE} == "p4"
-_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == "p3"
-_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == "p2"
-_CPUCFLAGS = -march=pentiumpro
-. elif ${CPUTYPE} == "i686"
+. elif ${CPUTYPE} == "pentium4"
+_CPUCFLAGS = -march=pentium4
+. elif ${CPUTYPE} == "pentium3"
+_CPUCFLAGS = -march=pentium3
+. elif ${CPUTYPE} == "pentium2"
+_CPUCFLAGS = -march=pentium2
+. elif ${CPUTYPE} == "pentiumpro"
_CPUCFLAGS = -march=pentiumpro
. elif ${CPUTYPE} == "i586/mmx"
_CPUCFLAGS = -march=pentium
@@ -60,6 +81,8 @@
_CPUCFLAGS = -march=i486
. endif
. elif ${MACHINE_ARCH} == "alpha"
+. if ${CPUTYPE} == "ev67"
+_CPUCFLAGS = -mcpu=ev67
. if ${CPUTYPE} == "ev6"
_CPUCFLAGS = -mcpu=ev6
. elif ${CPUTYPE} == "pca56"
@@ -75,6 +98,9 @@
. endif
. endif
.endif
+.if ${MACHINE_ARCH} == "alpha" && defined(CPUTUNE)
+_CPUCFLAGS += -mtune=${CPUTUNE}
+.endif
# NB: COPTFLAGS is handled in /usr/src/sys/conf/Makefile.
@@ -87,17 +113,17 @@
# presence of a CPU feature.
.if ${MACHINE_ARCH} == "i386"
-. if ${CPUTYPE} == "k7"
-MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
+. if ${CPUTYPE} == "athlon"
+MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6-2"
MACHINE_CPU = 3dnow mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k6"
MACHINE_CPU = mmx k6 k5 i586 i486 i386
. elif ${CPUTYPE} == "k5"
MACHINE_CPU = k5 i586 i486 i386
-. elif ${CPUTYPE} == "p4"
+. elif ${CPUTYPE} == "pentium4"
MACHINE_CPU = sse i686 mmx i586 i486 i386
-. elif ${CPUTYPE} == "p3"
+. elif ${CPUTYPE} == "pentium3"
MACHINE_CPU = sse i686 mmx i586 i486 i386
. elif ${CPUTYPE} == "p2"
MACHINE_CPU = i686 mmx i586 i486 i386
@@ -113,7 +139,9 @@
MACHINE_CPU = i386
. endif
.elif ${MACHINE_ARCH} == "alpha"
-. if ${CPUTYPE} == "ev6"
+. if ${CPUTYPE} == "ev67"
+MACHINE_CPU = ev67 ev6 ev56 pca56 ev5 ev45 ev4
+. elif ${CPUTYPE} == "ev6"
MACHINE_CPU = ev6 ev56 pca56 ev5 ev45 ev4
. elif ${CPUTYPE} == "pca56"
MACHINE_CPU = pca56 ev56 ev5 ev45 ev4
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 01:08:35PM -0700, Kris Kennaway wrote:
> On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote:
> > -. if ${CPUTYPE} == "k7"
> > -_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
> > +. if ${CPUTYPE} == "athlon"
> > +_CPUCFLAGS = -march=athlon
>
> AFAIK the k7 is a valid name for the athlon (marchitecture name).
> Don't break backwards compatibility here.
>
info gcc
`-mcpu=CPU-TYPE'
Tune to CPU-TYPE everything applicable about the generated code,
except for the ABI and the set of available instructions. The
choices for CPU-TYPE are `i386', `i486', `i586', `i686',
`pentium', `pentium-mmx', `pentiumpro', `pentium2', `pentium3',
`pentium4', `k6', `k6-2', `k6-3', `athlon', `athlon-tbird',
`athlon-4', `athlon-xp' and `athlon-mp'.
There is no -mk7 switch not -mcpu=k7. I tried
both with a Hello World program.
kargl[146] gcc -mcpu=k7 a.c
cc1: bad value (k7) for -mcpu= switch
kargl[147] gcc -mk7 a.c
cc1: invalid option `k7'
kargl[148] gcc -march=k7 a.c
cc1: bad value (k7) for -march= switch
cc1: bad value (k7) for -mcpu= switch
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 01:08:35PM -0700, Kris Kennaway wrote:
> On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote:
> > -. if ${CPUTYPE} == "k7"
> > -_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
> > +. if ${CPUTYPE} == "athlon"
> > +_CPUCFLAGS = -march=athlon
>
> AFAIK the k7 is a valid name for the athlon (marchitecture name).
> Don't break backwards compatibility here.
Nope. Athlon(tm) is the correct name, just like there really isn't a
"i586". I just posted a patch for review. Being the originator of
bsd.cpu.mk, I hope you review it.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 01:33:38PM -0700, Steve Kargl wrote:
> On Sat, May 11, 2002 at 01:08:35PM -0700, Kris Kennaway wrote:
> > On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote:
> > > -. if ${CPUTYPE} == "k7"
> > > -_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
> > > +. if ${CPUTYPE} == "athlon"
> > > +_CPUCFLAGS = -march=athlon
> >
> > AFAIK the k7 is a valid name for the athlon (marchitecture name).
> > Don't break backwards compatibility here.
> >
>
> There is no -mk7 switch not -mcpu=k7. I tried
> both with a Hello World program.
You missed the point. We've accepted CPUTYPE=k7 for ages, including
in -stable. Your patch removes this, thereby breaking backwards
compatibility for no good reason.
Kris
msg38204/pgp0.pgp
Description: PGP signature
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote:
> [bogus From: address, because people cannot be bothered to respect Reply-To:]
>
> What do people think of this patch to embellish bsd.cpu.mk?
> I also changed pN to be the more canonical pentiumN (with pN aliases of
> course).
>
> Index: bsd.cpu.mk
> ===
> RCS file: /home/ncvs/src/share/mk/bsd.cpu.mk,v
> retrieving revision 1.9
> diff -u -r1.9 bsd.cpu.mk
> --- bsd.cpu.mk11 May 2002 20:18:54 - 1.9
> +++ bsd.cpu.mk11 May 2002 20:31:28 -
> @@ -6,6 +6,9 @@
> .if ${MACHINE_ARCH} == "i386"
> CPUTYPE ?= i386
> .elif ${MACHINE_ARCH} == "alpha"
> +if !defined(CPUTYPE)
> +CPUTUNE ?= ev56
> +.endif
> CPUTYPE ?= ev4
What is this for?
Kris
msg38205/pgp0.pgp
Description: PGP signature
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote:
> @@ -87,17 +113,17 @@
> # presence of a CPU feature.
>
> .if ${MACHINE_ARCH} == "i386"
> -. if ${CPUTYPE} == "k7"
> -MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
> +. if ${CPUTYPE} == "athlon"
> +MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
This one should probably be left as k7; MACHINE_CPU is the variable
that is supposed to be used by applications to selectively enable
optimizations (so changing the name of the keyword from k7 to athlon
would break selection). On the other hand, there probably aren't any
applications which have athlon-specific optimizations yet.
Kris
msg38206/pgp0.pgp
Description: PGP signature
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote: > > What do people think of this patch to embellish bsd.cpu.mk? > I also changed pN to be the more canonical pentiumN (with pN aliases of > course). > Do we need PPC and Sparc flags? -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 01:46:32PM -0700, Kris Kennaway wrote:
> On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote:
>
> > @@ -87,17 +113,17 @@
> > # presence of a CPU feature.
> >
> > .if ${MACHINE_ARCH} == "i386"
> > -. if ${CPUTYPE} == "k7"
> > -MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
> > +. if ${CPUTYPE} == "athlon"
> > +MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
>
> This one should probably be left as k7; MACHINE_CPU is the variable
> that is supposed to be used by applications to selectively enable
> optimizations (so changing the name of the keyword from k7 to athlon
> would break selection). On the other hand, there probably aren't any
> applications which have athlon-specific optimizations yet.
>
GMP and ATLAS have athlon specific optimizations. These are
the reason I tried to add athlon. Sorry about botching the
k7 change.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
RE: pam su
On Sat, 11 May 2002, John Baldwin wrote: > On 11-May-2002 Galen Sampson wrote: > > Hello all, > > > > After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a > > mergemaster I am seeing the following on the console when I su: > > Don't mergemaster until after you've installworld'd. Yeah, I bumped into this on the TrustedBSD branch lately also. It goes side by side with the "don't installworld until you mergemaster" rule. And the very basic rule which is "Don't run -CURRENT unless you not only want to shoot your feet, but have hot spares so you can shoot them with a lower recovery time". > > Is this normal? > > Welcome to current. It will go away when you get things back in sync > again. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 01:46:32PM -0700, Kris Kennaway wrote:
> On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote:
>
> > @@ -87,17 +113,17 @@
> > # presence of a CPU feature.
> >
> > .if ${MACHINE_ARCH} == "i386"
> > -. if ${CPUTYPE} == "k7"
> > -MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
> > +. if ${CPUTYPE} == "athlon"
> > +MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
>
> This one should probably be left as k7; MACHINE_CPU is the variable
> that is supposed to be used by applications to selectively enable
> optimizations (so changing the name of the keyword from k7 to athlon
> would break selection).
Should we have "k7 athlon duron" there?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Solved -- was Re: buildworld seems broken (very early in process)
Well, the reason no one else encountered the problem I had was that no one else did something quite so stupid :-( I had managed to botch the sources for /bin/cp during yesterday's build (in a misdirected effort to avoid the warnings) in such a way that the resulting program executed with a return code of 0, but merely failed (at least in some cases) to copy anything. Since /bin/cp is a fairly low-level program that is just kinda expected to work, the result was singualrly unpleasant. I'm building the "cross tools" (which is *much* further than I got before) as I type I was about to make an attempt at a humorous comment about the creativity involved in that partictular instantiation of breakage... but at the moment, I'm just relieved :-} Here's hoping that no one else does this, or that if it is done, this might help the poor soul to recognize, diagnose, and fix the problem. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] Microsoft products -- for those times when reliability just doesn't matter. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
I know that for at least a little while, the rtc driver was left behind by KSE and devfs. I had a locally updated copy, but I seem to have lost it. I seem to recall that there was some confusion about calling the make_dev() from the device attach, so it never appeared in devfs... Unfortunately, -CURRENT moves a bit faster than something like that does unless it's actively maintained in the tree. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services On Sat, 11 May 2002, Julian Elischer wrote: > > seems something broke in the networking side of things using host-only > networking.. vmnet1 doesn;t show up any more.. > > If I have a moment I'll look for it but if anyone has familiarity with it > feel free to get there forst.. > > oh yeah.. it doesn't compile any more either... > > -- > ++ __ _ __ > | __--_|\ Julian Elischer | \ U \/ / hard at work in > | / \ [EMAIL PROTECTED] +-->x USA\ a very strange > | ( OZ)\___ ___ | country ! > +- X_.---._/presently in San Francisco \_/ \\ > v > > 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: embellish of bsd.cpu.mk
[bogus From: address, because people cannot be bothered to respect Reply-To:] On Sat, May 11, 2002 at 01:43:10PM -0700, Kris Kennaway wrote: > > +if !defined(CPUTYPE) > > +CPUTUNE ?= ev56 > > +.endif > > CPUTYPE ?= ev4 > > What is this for? Unlike i386, but catering to ev4 Alpha's; we strongly pessimize modern ones. I would almost suggest we default to ev56.. but do see enough pre-ev56 people email the Alpha list that I know we shouldn't. -mtune still uses only instructions at the mcpu level, but the scheduler uses mtune's CPU's preferences. While I do my own world builds, I like to use packages. Would be nice if we had > ev4 versions of them. CPUTUNE is a wild-ass idea; and maybe it isn't ready to go in. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
At 11:18 AM -0700 5/11/02, Julian Elischer wrote: >seems something broke in the networking side of things using >host-only networking.. vmnet1 doesn't show up any more.. > >If I have a moment I'll look for it but if anyone has >familiarity with it feel free to get there forst.. > >oh yeah.. it doesn't compile any more either... Is this something that just recently broke? I managed to cvsup -current *just* before the new gcc went in, and the vmware2 port is still working for me. However, the last time I compiled vmware2 itself was back on April 10th. I do not remember any problems compiling it before, so I suspect that is related to the new version of gcc. If this is your first attempt to get vmware2 working on -current, there are a few tricks to getting it to work right which the port does not know about yet. The main thing is to check /compat/linux/dev and see what you have for rtc, vmmon, and vmnet1. All of these should be symlinks pointing back to /dev, but rtc and one of the other ones (vmnet1?) are still done via a typical mknod. So, first thing you need to do is: /compat/linux/dev rm rtc vmnet1 ln -s /dev/rtc ln -s /dev/vmnet1 and reboot. Really the port should check for devfs, and do this automatically if that's active. I keep thinking I should try to write a patch for that. That should get vmware to work. When you start a virtual machine, you'll probably still get an error about the rtc device. Me, I just ignore that, because I don't need rtc when running Win2K as the guest OS. But somebody did post a patch to freebsd-current which was supposed to fix that problem. I should dig that patch up and try it out. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pam su
Hello, --- Robert Watson <[EMAIL PROTECTED]> wrote: > > On Sat, 11 May 2002, John Baldwin wrote: > > > On 11-May-2002 Galen Sampson wrote: > > > Hello all, > > > > > > After a 'make buildworld -DNO_WERROR` with sources today (05/10/02) and a > > > mergemaster I am seeing the following on the console when I su: > > > > Don't mergemaster until after you've installworld'd. > > Yeah, I bumped into this on the TrustedBSD branch lately also. It goes > side by side with the "don't installworld until you mergemaster" rule. > And the very basic rule which is "Don't run -CURRENT unless you not only > want to shoot your feet, but have hot spares so you can shoot them with a > lower recovery time". > All is well now. It turns out I ran the following sequence: buildworld (failed), buildworld -DNO_WERROR, shutdown now, buildkernel -DNO_WERROR, installkernel, installworld, shutdown -r now (su error after reboot), mergemaster (still error), and after a restart all was well. Don't mind shooting myself in the feet...just interested in the development process of large projects. I'm a senior CS major graduating in June. This is just a hobby. Galen > > > Is this normal? > > > > Welcome to current. It will go away when you get things back in sync > > again. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > [EMAIL PROTECTED] NAI Labs, Safeport Network Services > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Pthreads
Hello all, Experiencing some troubles with pthreads building ports. An example: configure: error: --with-pthreads specified for a system without pthread suppor t ===> Script "configure" failed unexpectedly. Please report the problem to [EMAIL PROTECTED] [maintainer] and attach the "/usr/ports/www/mozilla/work/mozilla/config.log" including the output of the failure of your make command. Also, it might be a good idea to provide an overview of all packages installed on your system (e.g. an `ls /var/db/pkg`). *** Error code 1 Stop in /usr/ports/www/mozilla. Others seem effected as well. Build system is "FreeBSD 5.0-CURRENT #0: Fri May 10 21:04:46 PDT 2002" with source from 10am that day. Galen __ Do You Yahoo!? LAUNCH - Your Yahoo! Music Experience http://launch.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
RE: pam su
On Sat, 11 May 2002, Galen Sampson wrote: > > > Don't mergemaster until after you've installworld'd. > > > > Yeah, I bumped into this on the TrustedBSD branch lately also. It goes > > side by side with the "don't installworld until you mergemaster" rule. > > And the very basic rule which is "Don't run -CURRENT unless you not only > > want to shoot your feet, but have hot spares so you can shoot them with a > > lower recovery time". > > All is well now. It turns out I ran the following sequence: buildworld > (failed), buildworld -DNO_WERROR, shutdown now, buildkernel -DNO_WERROR, > installkernel, installworld, shutdown -r now (su error after reboot), > mergemaster (still error), and after a restart all was well. > > Don't mind shooting myself in the feet...just interested in the > development process of large projects. I'm a senior CS major graduating > in June. This is just a hobby. Yeah, part of the gist of my message was that occasionally, there's no "right" upgrade path, you just have to slog through until your system appears to run normally again :-). Occasionally there are cycles of dependencies for upgrades -- you need a new users to install the files, but you don't get the new user until you run mergemaster. Or, you need a new binary to install a file via mergemaster, but you can't install the binary until mergemaster has created the config file for it. Last night I shot myself in the feet on my notebook by upgrading it to a recent -CURRENT with the trustedbsd_mac branch. The binary format for MAC labels changed, so init wouldn't exec, so the system would panic. If I booted the old kernel, because world was upgraded, all binaries setting credentials seg-faulted. Good stuff, experimental code. :-). Fortunately, it usually doesn't work out this way. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 02:17:40PM -0700, David O'Brien wrote:
> On Sat, May 11, 2002 at 01:46:32PM -0700, Kris Kennaway wrote:
> > On Sat, May 11, 2002 at 01:33:09PM -0700, David O'Brien wrote:
> >
> > > @@ -87,17 +113,17 @@
> > > # presence of a CPU feature.
> > >
> > > .if ${MACHINE_ARCH} == "i386"
> > > -. if ${CPUTYPE} == "k7"
> > > -MACHINE_CPU = k7 3dnow mmx k6 k5 i586 i486 i386
> > > +. if ${CPUTYPE} == "athlon"
> > > +MACHINE_CPU = athlon 3dnow mmx k6 k5 i586 i486 i386
> >
> > This one should probably be left as k7; MACHINE_CPU is the variable
> > that is supposed to be used by applications to selectively enable
> > optimizations (so changing the name of the keyword from k7 to athlon
> > would break selection).
>
> Should we have "k7 athlon duron" there?
MACHINE_CPU is a list of chipset features supported by the CPU.
Unless there's any difference in the chipset features implemented by
athlon and duron (which cannot be described better by specific labels
like 3dnow or mmx), then there should just be one token to identify
them.
Having both "k7" and "athlon" would be pointless too since the
application makefile is supposed to do things like
.if ${MACHINE_CPU:M3dnow}
[enable 3dnow optimizations]
.endif
and if there are two "competing" tokens to identify the athlon CPU
instruction set then there's confusion about how to test for it.
Kris
msg38218/pgp0.pgp
Description: PGP signature
Re: alpha tinderbox failure
< said: > It is ugly. I'm not sure if it's non-standard too. Duff's device was valid in C89. I can't speak for whether C99 has broken this. That's not necessarily a bad thing, since most of the time people use it to prove how 'leet they are rather than for an actual performance improvement. (I'd be surprised if any compiler newer than PCC actually produced better code for it.) -GAWollman To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: embellish of bsd.cpu.mk
On Sat, May 11, 2002 at 02:28:14PM -0700, David O'Brien wrote: > On Sat, May 11, 2002 at 01:43:10PM -0700, Kris Kennaway wrote: > > > +if !defined(CPUTYPE) > > > +CPUTUNE ?= ev56 > > > +.endif > > > CPUTYPE ?= ev4 > > > > What is this for? > > Unlike i386, but catering to ev4 Alpha's; we strongly pessimize modern > ones. I would almost suggest we default to ev56.. but do see enough > pre-ev56 people email the Alpha list that I know we shouldn't. > > -mtune still uses only instructions at the mcpu level, but the scheduler > uses mtune's CPU's preferences. > > While I do my own world builds, I like to use packages. Would be nice if > we had > ev4 versions of them. > > CPUTUNE is a wild-ass idea; and maybe it isn't ready to go in. I don't think it should go in. For example, we do exactly the same thing for i386 packages, which are optimized for running on i386'es (i.e. "no higher CPU instructions or instruction scheduling") even though it's certainly the least-used CPU by users of FreeBSD. There's no reason in principle we can't build multiple sets of packages with different values of CPUTYPE, except for two things: a) Disk space on ftp-master and on the mirror sites b) Build resources for the alpha cluster (it takes 3-4 days to do a single package run, so if we start multiplying that by different CPU generations it becomes annoying) Kris msg38220/pgp0.pgp Description: PGP signature
Re: Pthreads
On Sat, May 11, 2002 at 02:38:39PM -0700, Galen Sampson wrote: > Hello all, > > Experiencing some troubles with pthreads building ports. An example: This is probably due to the gcc upgrade which you should have read about. Kris msg38221/pgp0.pgp Description: PGP signature
Re: alpha tinderbox failure
Giorgos Keramidas <[EMAIL PROTECTED]> writes: > On 2002-05-11 18:34, Dag-Erling Smorgrav wrote: > > Hmm, does this mean Duff's Device is not valid C? > It is ugly. I'm not sure if it's non-standard too. My impression > until now was that jumping from an outter block 'inside' a contained > block is not a Good Thing(TM). Note that the switch cases also lack a > 'break' and are falling through. All of them! Yes, this is intentional. > This makes me wonder that happens the second time the loop runs. Does > the code start the second iteration at the beginning of the while > body? Or does it start at where the loop was entered the first time > (the proper 'case' of the switch statement)? At the top of the loop. This is a classic, if somewhat obscure, construct, named Duff's Device after Tom Duff, who devised it as a way of unrolling an I/O loop on a machine that had memory-mapped I/O. See the comp.lang.c FAQ for additional details. I think the proper way to silence this warning is to move the top of the while loop into 'case 0'. 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 2002-05-11 18:34, Dag-Erling Smorgrav wrote:
> Hiten Pandya <[EMAIL PROTECTED]> writes:
> > /*
> > * A comment is probably needed here for those not
> > * well versed in the "C" language. Yes, this is
> > * supposed to be a "switch" with the body of the
> > * "switch" being a "while" statement. The whole
> > * purpose of the switch is to allow us to jump into
> > * the middle of the while() loop, and then not have
> > * to do any more switch()s.
> > *
> > * Some compilers will spit out a warning message
> > * about the loop not being entered at the top.
> > */
> > switch (n&03)
> > while (n > 0) {
> > case 0:
> > ck ^= (int)*d++ << 24;
> > --n;
> > case 3:
> > ck ^= (int)*d++ << 16;
> > --n;
> > case 2:
> > ck ^= (int)*d++ << 8;
> > --n;
> > case 1:
> > ck ^= (int)*d++;
> > --n;
> > }
> > return(ck);
>
> Hmm, does this mean Duff's Device is not valid C?
It is ugly. I'm not sure if it's non-standard too. My impression
until now was that jumping from an outter block 'inside' a contained
block is not a Good Thing(TM). Note that the switch cases also lack a
'break' and are falling through. All of them!
This makes me wonder that happens the second time the loop runs. Does
the code start the second iteration at the beginning of the while
body? Or does it start at where the loop was entered the first time
(the proper 'case' of the switch statement)?
- Giorgos
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
On Sat, May 11, 2002 at 11:18:40AM -0700, Julian Elischer wrote: > > seems something broke in the networking side of things using host-only > networking.. vmnet1 doesn;t show up any more.. > VMWare is working fine on -CURRENT from May 7th. As Garance A Drosihn has pointed out, the vmware startup script needs to be adjusted in order to first create vmnet1 device node under /dev first and device nodes in /compat/linux/dev should be re-created to match device numbers reported by devfs. FreeBSD kan.dnsalias.net 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Tue May 7 23:44:37 EDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/KAN i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[panic] panic during probe with a gcc 3.1 kernel
I just tried to compile and boot a new kernel. It has been compiled with gcc 3.1, just recently imported. Having -march=pentiumpro or not doesn't change anything. I load 3 modules (if_wi, random, vesa). May 12 01:16:21 sidhe kernel: cardbus0: on pccbb0 May 12 01:16:21 sidhe kernel: pccard0: <16-bit PCCard bus> on pccbb0 May 12 01:16:21 sidhe kernel: pci_cfgintr_linked: linked (61) to hard-routed irq 9 May 12 01:16:21 sidhe kernel: pci_cfgintr: 0:12 INTA routed to irq 9 May 12 01:16:21 sidhe kernel: May 12 01:16:21 sidhe kernel: May 12 01:16:21 sidhe kernel: Fatal trap 21: FPU bounds check fault while in kernel mode May 12 01:16:21 sidhe kernel: instruction pointer = 0x8:0xc023e56c May 12 01:16:21 sidhe kernel: stack pointer = 0x10:0xc039ac60 May 12 01:16:21 sidhe kernel: frame pointer = 0x10:0xc039ac7c May 12 01:16:21 sidhe kernel: code segment = base 0x0, limit 0xf, type 0x1b May 12 01:16:21 sidhe kernel: = DPL 0, pres 1, def32 1, gran 1 May 12 01:16:21 sidhe kernel: processor eflags = interrupt enabled, IOPL = 0 May 12 01:16:21 sidhe kernel: current process = 0 (swapper) It panics during probe inside bios16... Any idea? ddb> trace bios16 pnpbios_identify bus_generic_probe isa_probe_children configure mi_startup begin -- 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: [panic] panic during probe with a gcc 3.1 kernel
On Sun, May 12, 2002 at 01:28:29AM +0200, Ollivier Robert wrote: > I just tried to compile and boot a new kernel. It has been compiled with > gcc 3.1, just recently imported. Having -march=pentiumpro or not doesn't > change anything. > > I load 3 modules (if_wi, random, vesa). > > It panics during probe inside bios16... Any idea? > > ddb> trace > bios16 > pnpbios_identify > bus_generic_probe > isa_probe_children > configure > mi_startup > begin > I reported this earlier today. I had hint.acpi.0.disable="1" in /boot/loader.conf to disable ACPI. If I comment out this hint, the system boots, but I end up with the following in dmesg. Using $PIR table, 9 entries at 0xc00f1720 ACPI-0224: *** Warning: Invalid table signature \M-0\M^Q\M-~\M-G found ACPI-0181: *** Error: AcpiLoadTables: Could not load RSDT: AE_BAD_SIGNATURE ACPI-0213: *** Error: AcpiLoadTables: Could not load tables: AE_BAD_SIGNATURE ACPI: table load failed: AE_BAD_SIGNATURE -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 tinderbox failure
-- >>> 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 /tmp/des/obj/i386/d/home/des/tinderbox/src/i386/usr/include -- >>> stage 4: building libraries -- ===> libkdb ... /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c: In function `kdb_encrypt_key': /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 1 of `des_pcbc_encrypt' from incompatible pointer type /d/home/des/tinderbox/src/crypto/kerberosIV/lib/kdb/krb_kdb_utils.c:200: warning: passing arg 2 of `des_pcbc_encrypt' from incompatible pointer type ===> libkrb ===> libtelnet cc1: warnings being treated as errors /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c: In function `kerberos4_cksum': /d/home/des/tinderbox/src/crypto/telnet/libtelnet/kerberos.c:496: warning: unreachable code at beginning of switch statement *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib/libtelnet. *** Error code 1 Stop in /d/home/des/tinderbox/src/kerberosIV/lib. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. *** Error code 1 Stop in /d/home/des/tinderbox/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: patch to add athlon to bsd.cpu.mk
On Sat, May 11, 2002 at 01:35:05PM -0700, David O'Brien wrote:
> On Sat, May 11, 2002 at 01:08:35PM -0700, Kris Kennaway wrote:
> > On Sat, May 11, 2002 at 12:12:16PM -0700, Steven G. Kargl wrote:
> > > -. if ${CPUTYPE} == "k7"
> > > -_CPUCFLAGS = -march=k6 # gcc doesn't support athlon yet, but it will
> > > +. if ${CPUTYPE} == "athlon"
> > > +_CPUCFLAGS = -march=athlon
> >
> > AFAIK the k7 is a valid name for the athlon (marchitecture name).
> > Don't break backwards compatibility here.
>
> Nope. Athlon(tm) is the correct name, just like there really isn't a
> "i586". I just posted a patch for review. Being the originator of
> bsd.cpu.mk, I hope you review it.
So if I have an athlon-xp do I set CPUTYPE to athlon and it handles
everything for me and selects the correct one or athlon-xp?
--
David W. Chapman Jr.
[EMAIL PROTECTED] Raintree Network Services, Inc.
[EMAIL PROTECTED] FreeBSD Committer
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current and vmware2
Garance A Drosihn wrote: > > At 11:18 AM -0700 5/11/02, Julian Elischer wrote: [...] > > If this is your first attempt to get vmware2 working on > -current, there are a few tricks to getting it to work > right which the port does not know about yet. I've done this before.. the build failure is that the makefiles are out of date with the general ports makefiles. [...] As far as the failure to work goes, the new code is trying to make a tap device that is caled vmnet1 but the tap device has been broken by soemone re: devfs. [...] -- ++ __ _ __ | __--_|\ Julian Elischer | \ U \/ / hard at work in | / \ [EMAIL PROTECTED] +-->x USA\ a very strange | ( OZ)\___ ___ | country ! +- X_.---._/presently in San Francisco \_/ \\ v To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cvs commit: src/gnu/lib/csu Makefile src/gnu/lib/libgcc Makefile src/gnu/lib/libiberty Makefile src/gnu/lib/libobjc Makefile src/gnu/lib/libstdc++ Makefile config.h src/gnu/lib/libsupc++ Makefile src/gnu/usr.bin/cc Makefile Makefile.fe Makefile.inc ...
On Sat, May 11, 2002 at 10:33:03AM -0700, David O'Brien wrote: > On Sat, May 11, 2002 at 12:35:38PM +0300, Ruslan Ermilov wrote: > > > I say again, the malloc usage is not in c-parse.in, it is in the parser > > > driver produced by Byacc. > > > > > OK, now that you've explained it: > > I'll look this patch over carefully, but at first glance it all seems > like stylistic changes. Does it fix a bug, or you just don't like how I > did things? > The changes are mostly _not_ stylistic like .ORDER with one argument not making any sense. The reason of this patch is as before -- to avoid redefining system Yacc building rules. The changes also fix the -j buildworld breakage in gnu/usr.bin/cc/cc1plus: # cd gnu/usr.bin/cc/cc1plus # make -j8 depend make: don't know how to make y.tab.h. Stop There're also some unrelated changes sitting in my tree like removing old cruft, which I will submit later when the dust settles down. 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 msg38230/pgp0.pgp Description: PGP signature
