Re: Softupdates reliability?

[Wilko Bulte]

As Rodney W. Grimes wrote ...
> > On Tue, 24 Aug 1999, Richard Tobin wrote:
> > 
> > > > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0

> The original K6-2's off the line where all 100MHz parts, it was later when
> AMD found that some people where sticking these in 66MHz boards and trying
> to run them with a 66MHz FSB and having troubles that AMD started to test
> the parts for 66MHz operation, they had to make some changes in the I/O
> buffers and then qualify a new part number and those are the ones stamped 66.
>  Aka AMD 6K86-2-P300/66 vs AMD 6K86-2-P300/100 for those who know what a
> real AMD part number is.

Rod, 

Do I understand you correctly that I should get a 66Mc variant for my Asus
T2P4 because a 100Mc is unlikely to work? Or are the newer 100Mc chips also
coping OK with 66Mc FSB? 

(I'm aware of the slight hardware hack required to make a T2P4 accept a K6-2.
What would be the fastest K6-2 running ok with a 66 FSB? And is this
potential upgrade worthwhile, with K6-2 going here for around 80-90$ or so?)

Thanks,
Wilko
-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Softupdates reliability?

[Amancio Hasty]

PIII 450Mhz are going for about $175 see http://www.pricewatch.com . Heck , at 
that
price get two 8)

Enjoy

-- 

 Amancio Hasty
 [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: SIO "lost interrupt" status in current?

[George Michaelson]

I wasn't using the DMA, 32-bit, multi-block-16 flags on wdc. Added that.
still got the drops..

I removed the ed0 ISA card from the kernel, seemed to reduce freq. still 
dropped.

I then tried harder to look for a correlation. doing virtual desktop pans
caused every drop every time. small incremental moves fine, but a complete
X11 redraw triggers things.

I'd say I have the X11 bug.

If I can do any useful debug (since I can re-create this) let me know. If
this is a dead horse, I can live with it.

cheers and thanks for advice!

-George


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

make release and DOC failures (diskless doc)

[John W. DeBoskey]

Hi,

   the following has been happenning for some time now... is anyone
else seeing this, or is it time to turn of doc again?

Thanks,
John

cd /usr/doc/en_US.ISO_8859-1 ; make afterdistribute DESTDIR=/R/stage/trees/bin
===> en_US.ISO_8859-1/articles
cd /usr/doc/en_US.ISO_8859-1/articles ; make afterdistribute DESTDIR=/R/stage/trees/bin
===> en_US.ISO_8859-1/articles/diskless-x
make: don't know how to make distribute. Stop
*** Error code 2

Stop in /usr/doc/en_US.ISO_8859-1/articles.
*** Error code 1

Stop in /usr/doc/en_US.ISO_8859-1.
*** Error code 1

Stop in /usr/doc.
*** Error code 1



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

New combo patch avail

[Matthew Dillon]

A new combo patch is now avaiable:

http://www.backplane.com/FreeBSD4/
first section, multipatch-2.diff hotlink.

The fixes are too numerous to mention.  Portions of the patch may be
committed by Alan or dg at any time so anyone who uses the above should
beware.  Also included is other work discussed by Alan, DG, and I, not
classified as a 'bug fix', such as the removal of vnode->v_lastr.

This patch should be considered experimental, mainly due to the BOOTP
related patches which mess around with the rootfsid.

There may be slight (temporary) degredation in I/O performance due 
to lack of tuning of the new sequential detection code.

The patch includes everything not committed to date including bug fixes
to NFS, VN, CCD, BOOTP, mmap/dirty lockups, and so on.  Performance 
improvements to NFS, mmap (faults), and certain filesystem I/O ops have
also been made.

-Matt




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Martin Cracauer]

In <[EMAIL PROTECTED]>, Daniel Eischen wrote: 
> Richard Cownie wrote:
> > On Sat, 21 Aug 1999, David O'Brien wrote:
> > > Are you saying 4.17 is better than 4.18 for debugging C++?  Or are you
> > > saying you didn't know FreeBSD comes with gdb:
> >
> > gdb-4.18 is badly broken on all platforms (at least for C++).  You can't
> > call methods from the gdb command line, and also it frequently freezes
> > to the point where you have to kill the window.  gdb-4.17 is much better
> > for C++. 
> 
> There's a port for gdb-4.17 sitting on my ftp site at:
> 
>   ftp://ftp.pcnet.com/users/eischen/FreeBSD/gdb-4.17-port.tar.gz
> 
> The port includes changes made to the gdb in our base system
> (then, Mar 1999, it was gdb-4.15 I believe).  I haven't made
> any further updates to it since.  You're welcome to play around
> with it.

Did anyone of you took care that you can build an aout gdb on an ELF
FreeBSD system? 

I don't mean a gdb that is aout, but one that can debug aout binaries.

That would be most useful to have as a port. Just step to
`/usr/ports/devel/aout-gdb && make install` and it uses
/usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it
can't use native sources. The modula-3 port does something in that
line, uses /usr/src if it can.

Martin
-- 
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
BSD User Group Hamburg, Germany http://www.bsdhh.org/


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Daniel Eischen]

> Did anyone of you took care that you can build an aout gdb on an ELF
> FreeBSD system? 
>
> I don't mean a gdb that is aout, but one that can debug aout binaries.

I thought the gdb in our base system could debug aout binaries.  Or
am I sadly mistaken.

> That would be most useful to have as a port. Just step to
> `/usr/ports/devel/aout-gdb && make install` and it uses
> /usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it
> can't use native sources. The modula-3 port does something in that
> line, uses /usr/src if it can.

I haven't tested the port on aout.  The main reason I did the port
was to make an Ada-aware version of gdb.  The GNAT maintainers
release patches to a specific version of gdb (in this case gdb-4.17),
so basing a port of gdb on what's in our base system was a bad
idea.  The gdb port I mentioned wasn't the Ada-aware gdb port, it
was just a step to get there.

Dan Eischen
[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: gdb-4.17 in FreeBSD 4.0-CURRENT

[Martin Cracauer]

In <[EMAIL PROTECTED]>, Daniel Eischen wrote: 
> > Did anyone of you took care that you can build an aout gdb on an ELF
> > FreeBSD system? 
> >
> > I don't mean a gdb that is aout, but one that can debug aout binaries.
> 
> I thought the gdb in our base system could debug aout binaries.  Or
> am I sadly mistaken.

You can compile it so that the gdb binary is aout 
(`cd /usr/src/gnu/usr.bin/binutils && make OBJFORMAT=aout), but that's
still a debugger that debugs ELF binaries.

It can't handle aout binaries unless you explicitly configure it to do
so and this ability seems to be broken by the FreeBSD-specific
changes.
 
> > That would be most useful to have as a port. Just step to
> > `/usr/ports/devel/aout-gdb && make install` and it uses
> > /usr/src/gnu/usr.bin/gdb or fetches some other source by itself if it
> > can't use native sources. The modula-3 port does something in that
> > line, uses /usr/src if it can.
> 
> I haven't tested the port on aout.  The main reason I did the port
> was to make an Ada-aware version of gdb.  The GNAT maintainers
> release patches to a specific version of gdb (in this case gdb-4.17),
> so basing a port of gdb on what's in our base system was a bad
> idea.  The gdb port I mentioned wasn't the Ada-aware gdb port, it
> was just a step to get there.

Well, on second thinking the idea to build from /usr/src might not
save much.

You need the binutils libraries and friends as aout, so it might be
easier to start from a source that carries everything you need with
it and link it statically.

Martin
-- 
%
Martin Cracauer <[EMAIL PROTECTED]> http://www.cons.org/cracauer/
  Tel.: (private) +4940 5221829 Fax.: (private) +4940 5228536


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Softupdates reliability?

[Rodney W. Grimes]

> As Rodney W. Grimes wrote ...
> > > On Tue, 24 Aug 1999, Richard Tobin wrote:
> > > 
> > > > > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
> 
> > The original K6-2's off the line where all 100MHz parts, it was later when
> > AMD found that some people where sticking these in 66MHz boards and trying
> > to run them with a 66MHz FSB and having troubles that AMD started to test
> > the parts for 66MHz operation, they had to make some changes in the I/O
> > buffers and then qualify a new part number and those are the ones stamped 66.
> >  Aka AMD 6K86-2-P300/66 vs AMD 6K86-2-P300/100 for those who know what a
> > real AMD part number is.
> 
> Rod, 
> 
> Do I understand you correctly that I should get a 66Mc variant for my Asus
> T2P4 because a 100Mc is unlikely to work? Or are the newer 100Mc chips also
> coping OK with 66Mc FSB? 

Yes, you stand a far better chance of making this hack work with a 66MHz
part.No the newer std parts are not designed to run with a 66MHz FSB,
you should always order them as /66.  Note that AMD has stopped making
these chips due to low demand for them (with 100MHz boards <$80 USA the
price/performance is usually worth it for most folks.)

> (I'm aware of the slight hardware hack required to make a T2P4 accept a K6-2.
> What would be the fastest K6-2 running ok with a 66 FSB? And is this
> potential upgrade worthwhile, with K6-2 going here for around 80-90$ or so?)

I've got about 8 of the T2P4's here and I'm not going to bother with it,
they are all getting replaced with 100MHz boards...  and 450MHz chips
that have now fallen to <$82 US.  And I pick up 1MB L2 cache while I'm
at it :-)

-- 
Rod Grimes - KD7CAX - (RWG25)[EMAIL PROTECTED]


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

RE: New combo patch avail

[Mark J. Taylor]

Since I am currently experimenting with BOOTP in -current, I patched ONLY
vfs_conf.c and vfs_subr.c with your rootfsid changes.  Works fine in a BOOTP
configuration.  -current sources are as of last night.

I can now boot a -current system from only a floppy disk with a (kgzipped) kernel
on it!


(plus some patches (see below) to rc.diskless1 where it (bogusly) temporarily
 mounts /usr, since it is already there (it should check for "-d /usr/bin" first),
 and rc.diskless2 to mfs a /var/msgs dir)



-Mark Taylor



Index: rc.diskless1
===
RCS file: /FreeBSD/CVS/src/etc/rc.diskless1,v
retrieving revision 1.1
diff -c -2 -r1.1 rc.diskless1
*** rc.diskless11999/02/09 17:17:18 1.1
--- rc.diskless11999/08/25 16:24:32
***
*** 48,57 
  #  retargeted /etc/fstab.  See instructions in /usr/share/examples/diskless.
  #
- set `/bin/df /`
- nfs_root=$8
- mount_nfs -o ro ${nfs_root}/usr /usr
  
! chkerr $? "mount of /usr"
  
  #  Figure out our interface and IP.
  #
--- 48,61 
  #  retargeted /etc/fstab.  See instructions in /usr/share/examples/diskless.
  #
  
! nfs_root=""
! if [ ! -d /usr/bin ]; then
!   set `/bin/df /`
!   nfs_root=$8
!   mount_nfs -o ro ${nfs_root}/usr /usr
  
+   chkerr $? "mount of /usr"
+ fi
+ 
  #  Figure out our interface and IP.
  #
***
*** 62,66 
  echo "Interface $bootp_ifc IP-Address $bootp_ipa"
  
! umount /usr
  
  # retarget /conf/ME
--- 66,72 
  echo "Interface $bootp_ifc IP-Address $bootp_ipa"
  
! if [ ! -z $nfs_root ]; then
!   umount /usr
! fi
  
  # retarget /conf/ME




Index: rc.diskless2
===
RCS file: /FreeBSD/CVS/src/etc/rc.diskless2,v
retrieving revision 1.2
diff -c -2 -r1.2 rc.diskless2
*** rc.diskless21999/02/10 18:08:16 1.2
--- rc.diskless21999/08/25 16:26:56
***
*** 14,17 
--- 14,18 
  mount_mfs -s ${var_tmp_sectors:=65536} -T qp120at dummy /var/tmp
  mount_mfs -s ${var_spool_sectors:=65536} -T qp120at dummy /var/spool
+ mount_mfs -s ${var_msgs_sectors:=2048} -T qp120at dummy /var/msgs
  chmod 755 /var/run
  chmod 755 /var/db



On 25-Aug-99 Matthew Dillon wrote:
> A new combo patch is now avaiable:
> 
>   http://www.backplane.com/FreeBSD4/
>   first section, multipatch-2.diff hotlink.
> 
> The fixes are too numerous to mention.  Portions of the patch may be
> committed by Alan or dg at any time so anyone who uses the above should
> beware.  Also included is other work discussed by Alan, DG, and I, not
> classified as a 'bug fix', such as the removal of vnode->v_lastr.
> 
> This patch should be considered experimental, mainly due to the BOOTP
> related patches which mess around with the rootfsid.
> 
> There may be slight (temporary) degredation in I/O performance due 
> to lack of tuning of the new sequential detection code.
> 
> The patch includes everything not committed to date including bug fixes
> to NFS, VN, CCD, BOOTP, mmap/dirty lockups, and so on.  Performance 
> improvements to NFS, mmap (faults), and certain filesystem I/O ops have
> also been made.
> 
>   -Matt
> 


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "The Matrix" screensaver, v.0.2

[Jordan K. Hubbard]

> But it's not going into the tree, no.  I think Kevin's point and the 
> experiences we had with Hasbro should already have convinced people of 
> that much.

I think people are being almost clinically paranoid here.  Hasbro and
folks got upset over TRADEMARK infringement, e.g. from using a name
they had trademarked.  I rather doubt that Warner Bros.  have managed
to trademark the name "matrix" since it's already a common english
word.  "Boggle" and "Tetris" don't fall into that category.

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: RE: New combo patch avail

[Matthew Dillon]

:Since I am currently experimenting with BOOTP in -current, I patched ONLY
:vfs_conf.c and vfs_subr.c with your rootfsid changes.  Works fine in a BOOTP
:configuration.  -current sources are as of last night.
:
:I can now boot a -current system from only a floppy disk with a (kgzipped) kernel
:on it!
:
:
:(plus some patches (see below) to rc.diskless1 where it (bogusly) temporarily
: mounts /usr, since it is already there (it should check for "-d /usr/bin" first),
: and rc.diskless2 to mfs a /var/msgs dir)

Yah, there's a lot of bogosity in the rc.diskless stuff -- it kinda got
stale and needs a major update.  My latest rc.diskless stuff avoids
mounting /var R+W, which means all the NFS mounts are RO now except for
the swap mount.

Hopefully I'll get back to it soon.  I'll save your patch.

Oh shoot, I just realized I forgot the utility support portions in the
multi-patch #2 (e.g. the updated vnconfig utility).  Ugh.

-Matt


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "The Matrix" screensaver, v.0.2

[Mike Smith]

> > But it's not going into the tree, no.  I think Kevin's point and the 
> > experiences we had with Hasbro should already have convinced people of 
> > that much.
> 
> I think people are being almost clinically paranoid here.  Hasbro and
> folks got upset over TRADEMARK infringement, e.g. from using a name
> they had trademarked.  I rather doubt that Warner Bros.  have managed
> to trademark the name "matrix" since it's already a common english
> word.  "Boggle" and "Tetris" don't fall into that category.

The issue with boggle and tetris wasn't the name, it was "look and feel".
That's the same issue here; the "matrix" screensaver mimics the 
"distinctive likeness" of a portion of WB's entertainment product, and 
being a screensaver (rather than, say, a car component) it's also an 
"entertainment product".


-- 
\\  The mind's the standard   \\  Mike Smith
\\  of the man.   \\  [EMAIL PROTECTED]
\\-- Joseph Merrick   \\  [EMAIL PROTECTED]




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

newfs of a ccd failing?

[Mark J. Taylor]

I've had this problem since at least FreeBSD 3.1-RELEASE (it works in
2.2.7/2.2.8).  Same problem in 3.2-RELEASE and -current (as of last night).

Can someone reproduce this error?  I can't believe that you can't newfs
a ccd...  did I miss something?



spiffy# ./ccdtest.sh 
[snip]
newfs /dev/rccd0c
Warning: 16 sector(s) in last cylinder unallocated
/dev/rccd0c:204784 sectors in 50 cylinders of 1 tracks, 4096 sectors
100.0MB in 4 cyl groups (16 c/g, 32.00MB/g, 6272 i/g)
super-block backups (for fsck -b #) at:
 32, 65568, 131104, 196640
newfs: ioctl (WDINFO): No such process
newfs: /dev/rccd0c: can't rewrite disk label



I believe that there is a problem in/near ufs/ufs/ufs_disksubr.c where it
says that it requires an existing disklabel before it writes a new one.
If I change the "#if 1" to an "#if 0" in it, then I don't get this failure.




Here's my test script:

#!/bin/sh
#
# ccdtest.sh
#
# Build a 100 MByte linear ccd from a vnode and newfs it.
#


set -v
set -e

ccdconfig -u ccd0 2> /dev/null || true
vnconfig -u /dev/vn0 2> /dev/null || true

(cd /dev && ./MAKEDEV ccd0 vn0)

if [ ! -f /var/tmp/vn0 ]; then
  dd if=/dev/zero of=/var/tmp/vn0 bs=1024 count=102400
fi

vnconfig -e -s labels /dev/vn0 /var/tmp/vn0

disklabel -w -r vn0 auto
echo "Make 'c' a 4.2BSD type filesystem.  [press Enter now]"
read dummy
disklabel -e vn0

ccdconfig -c ccd0 0 0 /dev/vn0c

newfs /dev/rccd0c

ccdconfig -u ccd0 || true
vnconfig -u /dev/vn0 || true







-Mark Taylor
NetMAX Developer
[EMAIL PROTECTED]
http://www.netmax.com/



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: newfs of a ccd failing?

[Dmitrij Tejblum]

> 
> I've had this problem since at least FreeBSD 3.1-RELEASE (it works in
> 2.2.7/2.2.8).  Same problem in 3.2-RELEASE and -current (as of last night).
> 
> Can someone reproduce this error?  I can't believe that you can't newfs
> a ccd...  did I miss something?

I always see the error message last months, but it is harmless in 
practice - the filesystem is OK, the ccd is ready to use.

> newfs: ioctl (WDINFO): No such process
> newfs: /dev/rccd0c: can't rewrite disk label

Dima




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: newfs of a ccd failing?

[Matthew Dillon]

:I've had this problem since at least FreeBSD 3.1-RELEASE (it works in
:2.2.7/2.2.8).  Same problem in 3.2-RELEASE and -current (as of last night).
:
:Can someone reproduce this error?  I can't believe that you can't newfs
:a ccd...  did I miss something?


:[snip]
:newfs /dev/rccd0c
:Warning: 16 sector(s) in last cylinder unallocated
:/dev/rccd0c:204784 sectors in 50 cylinders of 1 tracks, 4096 sectors
:100.0MB in 4 cyl groups (16 c/g, 32.00MB/g, 6272 i/g)
:super-block backups (for fsck -b #) at:
: 32, 65568, 131104, 196640
:newfs: ioctl (WDINFO): No such process
:newfs: /dev/rccd0c: can't rewrite disk label

You have two problems.

First, you are using a VN device for which you have enabled 
labels.  The label is stored in the first few sectors of the
VN's device.

You have then created a CCD on top of the VN device and
tried to create a label in it as well, using 'c' which
starts at offset 0.

The two label areas overlap.  Creating a real label under
the ccd device will destroy the VN device's label.


Problem #2:  the ccd device creates a 'garbage' label.  It
does not create a real label.

newfs tries to rewrite the real label, but since no label
exists it gets an error.

You can create a real label like this:

disklabel ccd0 > /tmp/ccd0.label
disklabel -R -r ccd0 /tmp/ccd0.label

And then your newfs will not generate any errors.

BUT, you've just destroyed the VN label by doing this.

Ok, so how to fix?

* Create a 'd' partition in the VN device which is offset
  by 16 sectors.  'disklabel -e vn0'

8 partitions:
#size   offsetfstype   [fsize bsize bps/cpg]
  c:   2048000unused0 0 # (Cyl.0 - 99)
  d:   204784   164.2BSD0 0 0   # (Cyl.0*- 99*)

* Configure the ccd on top of the vn device's 'd' partition.
* Create a real label for the ccd
* newfs your filesystem.

:
:I believe that there is a problem in/near ufs/ufs/ufs_disksubr.c where it
:says that it requires an existing disklabel before it writes a new one.
:If I change the "#if 1" to an "#if 0" in it, then I don't get this failure.

It's probably safer for the system to generate an error if no
preexisting label exists.  It is fairly easy to create a label.

The CCD device is rather archaic and needs to be babied a bit when
you use it on top of artificially constructed devices.  The real
problem is that the CCD device requires a block device with an
fstype of '4.2BSD'.  If we got rid of that requirement then you
could run it on top of a 'raw' VN device (without -s labels).  If
the ccd device didn't try to fake up its label then newfs would
not attempt to rewrite it and thus would not complain.

-Matt
Matthew Dillon 
<[EMAIL PROTECTED]>


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: newfs of a ccd failing?

[Bruce Evans]

>> I've had this problem since at least FreeBSD 3.1-RELEASE (it works in
>> 2.2.7/2.2.8).  Same problem in 3.2-RELEASE and -current (as of last night).

This is because writing of the newfs parameters to the label is broken
(not done) for all disk devices in 2.2.x.  Now it is only broken for
devices that don't support labels properly.

>I always see the error message last months, but it is harmless in 
>practice - the filesystem is OK, the ccd is ready to use.
>
>> newfs: ioctl (WDINFO): No such process

I don't know why the errno is ESRCH.

>> newfs: /dev/rccd0c: can't rewrite disk label

Its harm is limited to fsck no being able to find backup superblocks
automatically if the primary superblock is damaged, and newfs not being
able to find some previous fsize and bsize paramters if it is rerun.

Bruce


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Softupdates reliability?

[Wilko Bulte]

As Rodney W. Grimes wrote ...
> > As Rodney W. Grimes wrote ...
> > > > On Tue, 24 Aug 1999, Richard Tobin wrote:
> > > > 
> > > > > > >   Origin = "AuthenticAMD"  Id = 0x580  Stepping=0
> > 
> > > The original K6-2's off the line where all 100MHz parts, it was later when
> > > AMD found that some people where sticking these in 66MHz boards and trying
> > > to run them with a 66MHz FSB and having troubles that AMD started to test
> > > the parts for 66MHz operation, they had to make some changes in the I/O
> > > buffers and then qualify a new part number and those are the ones stamped 66.
> > >  Aka AMD 6K86-2-P300/66 vs AMD 6K86-2-P300/100 for those who know what a
> > > real AMD part number is.
> > 
> > Rod, 
> > 
> > Do I understand you correctly that I should get a 66Mc variant for my Asus
> > T2P4 because a 100Mc is unlikely to work? Or are the newer 100Mc chips also
> > coping OK with 66Mc FSB? 
> 
> Yes, you stand a far better chance of making this hack work with a 66MHz
> part.No the newer std parts are not designed to run with a 66MHz FSB,
> you should always order them as /66.  Note that AMD has stopped making
> these chips due to low demand for them (with 100MHz boards <$80 USA the
> price/performance is usually worth it for most folks.)

The USA... your prices tend to be a lot better than ours. I could can the
T2P4 but that would also mean I had to can the SIMMs (everything is DIMMs
now), get an AGP videocard and can the perfectly fine Millenium II (I need
the extra PCI slot quite badly) and buy a new CPU. Oh, and buy an ATX case.
In the end that is quite a bit more than $80. Unfortunately.

> > (I'm aware of the slight hardware hack required to make a T2P4 accept a K6-2.
> > What would be the fastest K6-2 running ok with a 66 FSB? And is this
> > potential upgrade worthwhile, with K6-2 going here for around 80-90$ or so?)
> 
> I've got about 8 of the T2P4's here and I'm not going to bother with it,

I must say I still like the T2P4 a alot. Works just fine for me.

> they are all getting replaced with 100MHz boards...  and 450MHz chips
> that have now fallen to <$82 US.  And I pick up 1MB L2 cache while I'm
> at it :-)

Yep, there are more goodies included ;)

-- 
|   / o / /  _   Arnhem, The Netherlands- Powered by FreeBSD -
|/|/ / / /( (_) BulteWWW  : http://www.tcja.nl  http://www.freebsd.org


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Docs blows up make release

[Nik Clayton]

[ I've added Satoshi Asami to the cc: list -- I figure he's almost certainly
  on -current, but I wanted to make sure he sees this and can add his input
  as necessary.

  I've also added -doc, for information. ]

On Sun, Aug 22, 1999 at 02:25:52PM -0700, Jordan K. Hubbard wrote:
> Nik Clayton wrote:
> > For the immediate future, it looks like it will -- it seems as though
> > we don't have the man power to make the necessary changes to sysinstall
> > to support "installing the docs as packages", so I'm going to fix up 
> > src/release/Makefile as necessary to cope with the new directory structure.

Just an update on that.  I've been working on this with Jack O'Neill, and
if the reports are favourable I'll have one small patch to 
src/release/Makefile and one small patch to doc/*/Makefile to go in some
time in the next 48 hours or so which should get release builds working.

Note that this won't include any fixes to teach sysinstall about the new
paths under /usr/share/doc/, although you should have seen a patch I sent
you about that by now.

> I also should note that there's nothing to preclude supplying the docs
> as packages *also*, assuming that they appear in the INDEX and get
> built as part of Satoshi's ports build.  

This assumes that the documentation is also listed in the ports tree.

I don't think this is a great idea -- more specifically, I don't think
this is a great idea as the primary mechanism for making packages of
the documentation.  I've got no problems with it being another way to 
make doc packages.

As the comment for ports/japanese/handbook says, "this is pretty useless
as a port, but is here so I can build a package -- Satoshi".

This makes the ports tree have a dependency on the doc tree.  I don't think
this dependency should be there.  It's bad enough that the src/ tree
depends on doc/ (and the reason I want the documentation available as
packages is to remove this dependency), having ports depend on the doc tree
as well just means that when things go out of sync in doc for a while I get
both you and Satoshi complaining at me, instead of just you :-)

Putting the package building rules in the doc/ Makefiles also (and this
is just my personal opinion) makes it easier for people to see how the
documentation packages are built.  The ports Makefile structure is a 
marvel, but it contains a lot of code that's not necessary for building
documentation packages (the "automagically add man pages to the PLIST 
i" code, for example) that makes it more difficult for the interested
learner to browse and understand what's going on.

I've attached the patch to docproj.docbook.mk that tells it how to build
packages to this message.  To use it.

  1.  Checkout a recent copy of the doc/ repository.

  2.  Patch doc/share/mk/docproj.docbook.mk with the attached patch.

  3.  Pick a directory, such as the English FAQ

  # cd doc/en_US.ISO_8859-1/books/faq

  4.  Make sure that a COMMENT and DESCR file exist.  I haven't committed
  any of these yet, so the simplest thing to do is

  # touch COMMENT DESCR

  5.  Run "make package", ensuring that the FORMATS variable is set to the
  formats you want to build.

  # make "FORMATS=html html-split ps pdf rtf" package

  6.  Sit back and relax, it takes a while.  When it's finished, look at
  the .tgz files that have been created.  Note that package building
  *will* update the installed documentation under /usr/share/doc/.
  If there's a way to work around this (so that you can build the 
  package containing files in one directory, but so that when you run
  pkg_add(1) the files are installed in a different directory) I'd like
  to know about it.

This is still proof of concept.  For example, when it's finished, it would
be nice if the DESCR could be automatically generated by pulling out the
... that might be in the source, and the name of the
generated package should probably be something like

...tgz

so

faq.en_US.ISO_8859-1.pdf.tgz

But I think it currently fits the 80/20 rule reasonably well.

If you put COMMENT and DESCR files in all the appropriate directories you
should certainly be able to do something like

# cd /usr/doc
# make "FORMATS=html html-split ps pdf rtf" package
# find . -name \*.tgz -exec scp {} wcarchive:/archive/pub/FreeBSD/doc \;

which is how I intend to automate building these things and ensuring that
wcarchive is kept up to date.

Does that all make sense?  I don't think there's anything there that's
egregiously stupid, but it's been known to happen before :-)

N
-- 
 [intentional self-reference] can be easily accommodated using a blessed,
 non-self-referential dummy head-node whose own object destructor severs
 the links.
-- Tom Christiansen in <[EMAIL PROTECTED]>


Index: docproj.docbook.mk
===
RCS file: /home/ncvs/doc/share/mk/docproj.docbook.mk,v
retrieving revision 1.9
diff -u -r1

Libraries broken in -CURRENT

[Udo Schweigert]

Hello all,


I just cvsuped -CURRENT and got the following error (only the first of many):

--
>>> Rebuilding bootstrap libraries
--
cd /work/src/HEAD; BISON_SIMPLE=/usr/obj/work/src/HEAD/tmp/usr/share/misc/bison.simple 
 
COMPILER_PATH=/usr/obj/work/src/HEAD/tmp/usr/libexec:/usr/obj/work/src/HEAD/tmp/usr/bin
  
GCC_EXEC_PREFIX=/usr/obj/work/src/HEAD/tmp/usr/lib:/usr/obj/work/src/HEAD/tmp/usr/lib/ 
 LD_LIBRARY_PATH=/usr/obj/work/src/HEAD/tmp/usr/lib  
LIBRARY_PATH=/usr/obj/work/src/HEAD/tmp/usr/lib:/usr/obj/work/src/HEAD/tmp/usr/lib 
NOEXTRADEPEND=t 
PATH=/usr/obj/work/src/HEAD/tmp/sbin:/usr/obj/work/src/HEAD/tmp/usr/sbin:/usr/obj/work/src/HEAD/tmp/bin:/usr/obj/work/src/HEAD/tmp/usr/bin:/sbin:/usr/sbin:/usr/X11R6/bin:.:/usr/local/bin:/usr/local/pilot/bin:/home/ust/bin/file:/home/ust/bin/sys:/home/ust/bin/misc:/home/ust/bin/dev:/sbin:/usr/sbin:/usr/X11R6/bin:.:/usr/local/bin:/usr/local/pilot/bin:/home/ust/bin/file:/home/ust/bin/sys:/home/ust/bin/misc:/home/ust/bin/dev:/home/ust/bin:/bin:/usr/bin:/usr/local/bin:/usr/X11R6/bin
  OBJFORMAT_PATH=/usr/obj/work/src/HEAD/tmp/usr/libexec:/usr/libexec 
/usr/obj/work/src/HEAD!
 /t!
!
mp/usr/bin/make DESTDIR=/usr/obj/work/src/HEAD/tmp -f Makefile.inc1 bootstrap-libraries
cd /work/src/HEAD/lib/csu/i386-elf;  /usr/obj/work/src/HEAD/tmp/usr/bin/make -DWORLD 
-DNOINFO -DNOMAN -DNOPIC -DNOPROFILE -DNOSHARED cleandepend;  
/usr/obj/work/src/HEAD/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN -DNOPIC -DNOPROFILE 
-DNOSHARED all;  /usr/obj/work/src/HEAD/tmp/usr/bin/make -DWORLD -DNOINFO -DNOMAN 
-DNOPIC -DNOPROFILE -DNOSHARED -B install cleandir obj
rm -f .depend /usr/obj/work/src/HEAD/lib/csu/i386-elf/GPATH 
/usr/obj/work/src/HEAD/lib/csu/i386-elf/GRTAGS  
/usr/obj/work/src/HEAD/lib/csu/i386-elf/GSYMS 
/usr/obj/work/src/HEAD/lib/csu/i386-elf/GTAGS
cc -O -pipe -elf -Wall -fkeep-inline-functions 
-I/usr/obj/work/src/HEAD/tmp/usr/include -c /work/src/HEAD/lib/csu/i386-elf/crt1.c -o 
crt1.o
cc -O -pipe -elf -Wall -fkeep-inline-functions 
-I/usr/obj/work/src/HEAD/tmp/usr/include -c /work/src/HEAD/lib/csu/i386-elf/crtbegin.c 
-o crtbegin.o
/work/src/HEAD/lib/csu/i386-elf/crtbegin.c:32: section attributes are not supported 
for this target
/work/src/HEAD/lib/csu/i386-elf/crtbegin.c:33: section attributes are not supported 
for this target
*** Error code 1 (continuing)
cc -O -pipe -elf -Wall -fkeep-inline-functions 
-I/usr/obj/work/src/HEAD/tmp/usr/include -c /work/src/HEAD/lib/csu/i386-elf/crtend.c 
-o crtend.o
/work/src/HEAD/lib/csu/i386-elf/crtend.c:32: section attributes are not supported for 
this target
/work/src/HEAD/lib/csu/i386-elf/crtend.c:33: section attributes are not supported for 
this target
*** Error code 1 (continuing)

Best regards
---
Udo Schweigert  || Voice  : +49 89 636 42170
Siemens AG, Siemens CERT|| Fax: +49 89 636 48000
ZT IK 3 || email  : [EMAIL PROTECTED]
D-81730 Muenchen / Germany  ||: [EMAIL PROTECTED]
PGP fingerprint || 2A 53 F6 A6 30 59 64 02  6B C4 E0 73 B2 C9 6C E7
---


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: Docs blows up make release

[Jordan K. Hubbard]

> Just an update on that.  I've been working on this with Jack O'Neill, and
> if the reports are favourable I'll have one small patch to 
> src/release/Makefile and one small patch to doc/*/Makefile to go in some
> time in the next 48 hours or so which should get release builds working.

Great, sounds good.

> Note that this won't include any fixes to teach sysinstall about the new
> paths under /usr/share/doc/, although you should have seen a patch I sent
> you about that by now.

Hmm, I still have 3000 mails I'm going through here...  sysinstall
required changes?  I thought everything was still under
/usr/share/doc, or are the subdirs different now?

> This assumes that the documentation is also listed in the ports tree.
> 
> I don't think this is a great idea -- more specifically, I don't think
> this is a great idea as the primary mechanism for making packages of
> the documentation.  I've got no problems with it being another way to 
> make doc packages.

Hmmm.  How else were you thinking of making "doc packages" then -
wasn't that the whole project you were working on?

> This makes the ports tree have a dependency on the doc tree.  I don't think
> this dependency should be there.  It's bad enough that the src/ tree
> depends on doc/ (and the reason I want the documentation available as
> packages is to remove this dependency), having ports depend on the doc tree
> as well just means that when things go out of sync in doc for a while I get
> both you and Satoshi complaining at me, instead of just you :-)

Erm, I think the ports tree is pretty darn loose about "dependencies"
since they're easily updated.  Consider, for example, the fact that
some ports are dependent on the organization of binary tarballs over
at Netscape, or depend on WordPerfect's linux distribution RPM.  Those
are some pretty heavy deps, and depending on something in our own doc
tree is certainly no worse. :)

> Putting the package building rules in the doc/ Makefiles also (and this
> is just my personal opinion) makes it easier for people to see how the
> documentation packages are built.  The ports Makefile structure is a 
> marvel, but it contains a lot of code that's not necessary for building
> documentation packages (the "automagically add man pages to the PLIST 
> i" code, for example) that makes it more difficult for the interested
> learner to browse and understand what's going on.

Now this is a point which is more germin.  So, you figure on making a
similar sort of "package" target under doc?  I guess it really doesn't
matter where these things live, as long as it's still automated..

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "The Matrix" screensaver, v.0.2

[Jordan K. Hubbard]

> The issue with boggle and tetris wasn't the name, it was "look and feel".

No, it was the name.  Believe me, I read the letters we got from their
lawyers. :)

Unless we produce a movie with the name "Matrix" somewhere in it, I
doubt we're going to be in the same boat.  Hasbro objected to our
having a game in /usr/games called boggle and the Tetris folks
objected to the use of the name.  Other folks chose to rename their
tetris clones to "tertis" and made the Tetris folks perfectly happy
in so doing, even though the look-and-feel of the game remained
completely unchanged.

You are trying to apply rules of logic to this.  This is a legal
issue. :)

- Jordan


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: NFSv3 on freebsd<-->solaris

[Dmitrij Tejblum]

Doug Rabson wrote:
> 
> This is probably because our server detects that the directory has been
> modified and rejects the solaris client's directory cookies.

I think we should not ever reject a client's cookie. Consider a local 
program that scan the directoty with the getdirentries() syscall. The 
offset in the directory is essentially the cookie that would be sent to
an NFS client. But we never "reject" the offset, and everyone is happy.
(Not to mention NFSv2, where we never reject a client's cookie too). 
So, what we are trying to achieve by rejecting a NFSv3 client's cookie?

> Instead of
> recovering, the solaris client barfs. Its a solaris bug really

IMHO, it is very arguable. Why the client should "recover" after "stale 
cookie" error, but should not recover after "stale filehandle" error? 
How should it perform the recovery: If a reliable recovery is possible, 
why it is not done on the server? 

(After all, Sun know how NFSv3 should work, since they wrote the spec, 
right? :-|)

Dima


Dima




To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

3C597 fast ethernet support

[Bret Ford]

I've got a 100Mbit 3COM EISA ethernet interface.  Here are the particulars:

vx0: <3Com 3C597-TX Network Adapter> at 0x5000-0x501f, 0x5c80-0x5c89
vx0: irq 12 (edge) on eisa0 slot 5

I've been running it for a while now at 10Mbit.  From what I can gather, the
vx driver doesn't support fast ethernet.  I'd be happy to lend the card to
anyone interested
in working on it.  The reward would be my gratitude and money for your
favorite pizza and beverages!  :-) Any interest?

Thanks,

Bret Ford



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: 3C597 fast ethernet support

[Matthew N. Dodd]

On Wed, 25 Aug 1999, Bret Ford wrote:
> I've got a 100Mbit 3COM EISA ethernet interface.  Here are the particulars:
> 
> vx0: <3Com 3C597-TX Network Adapter> at 0x5000-0x501f, 0x5c80-0x5c89
> vx0: irq 12 (edge) on eisa0 slot 5
> 
> I've been running it for a while now at 10Mbit.  From what I can
> gather, the vx driver doesn't support fast ethernet.  I'd be happy to
> lend the card to anyone interested in working on it.  The reward would
> be my gratitude and money for your favorite pizza and beverages!  :-)
> Any interest?

I've actually been keeping an eye open for one of those but haven't
managed to grab one yet.  I've intended on getting one and fiddling with
it but currently have no time.  If you find one for $10 or less grab it
and I'll pay cost plus shipping.  If its on my shelf I'll likely look at
it at some point.

I've got code for the Compaq NetFlex 3/E that gloms on to Bill's
Thunderland driver that I've not managed to get working correctly yet.
This card also supports 100 meg mode.  (Damn Compaq for not having doc
available.)

-- 
| Matthew N. Dodd  | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD  |
| [EMAIL PROTECTED] |   2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | This Space For Rent  | ISO8802.5 4ever |



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: "The Matrix" screensaver, v.0.2

[Jordan K. Hubbard]

I'm sorry you got so beaten up over this one.  All due respect to the
contributors aside, I think we have too many old women around here,
all shrieking and holding up their skirts at the rumor of a mouse
somewhere in the building. :)

- Jordan

> On Mon, 23 Aug 1999, Mike Smith wrote:
> 
> > Just make it a port, for crap's sake, and distribute it from Poland.  
> > By the time WB's American lawyers work out where you are on the map, 
> > the statute of limitations will have expired and you'll be fine.
> > 
> > But it's not going into the tree, no.  I think Kevin's point and the 
> > experiences we had with Hasbro should already have convinced people of 
> > that much.
> 
> I'm tired of this. It has priority number -infinity on my list. Do with it
> what you want - the code is there. I won"t put it in the tree.
> 
> Andrzej Bialecki
> 
> //  <[EMAIL PROTECTED]> WebGiro AB, Sweden (http://www.webgiro.com)
> // ---
> // -- FreeBSD: The Power to Serve. http://www.freebsd.org 
> // --- Small & Embedded FreeBSD: http://www.freebsd.org/~picobsd/ 
> 
> 
> 
> 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: Softupdates reliability?

[Alex Zepeda]

On Wed, 25 Aug 1999, Wilko Bulte wrote:

> The USA... your prices tend to be a lot better than ours. I could can the
> T2P4 but that would also mean I had to can the SIMMs (everything is DIMMs
> now), get an AGP videocard and can the perfectly fine Millenium II (I need
> the extra PCI slot quite badly) and buy a new CPU. Oh, and buy an ATX case.
> In the end that is quite a bit more than $80. Unfortunately.

Doesn't Asus make an AT formfactor Super 7 motherboard w/ a 100mhz bus?

I'm pretty sure it has DIMM and SIMM slots on it too (well I think their
ATX board does too); obviously using both at the same time won't work
well..

- alex



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

make world failure (signal 11 in cpp)

[John W. DeBoskey]

Hi,

   I'm having problems making world... before I dig into this, does
anyone already know what's going on? My source is current as of
11:30pm EST.

thanks,
John

===> cpp
cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc 
-I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE 
-DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" 
-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" 
-I/usr/obj/usr/src/gnu/usr.bin/cc/cpp/../cc_tools 
-I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -DPREFIX=\"/usr\"   
-I/usr/obj/usr/src/tmp/usr/include -c 
/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c
yacc  -o cexp.c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cexp.y
*** Signal 11

Stop in /usr/src/gnu/usr.bin/cc/cpp.
*** Error code 1

Stop in /usr/src/gnu/usr.bin/cc.
*** Error code 1



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make world failure (signal 11 in cpp)

[Greg Lehey]

On Wednesday, 25 August 1999 at 23:39:56 -0400, John W. DeBoskey wrote:
> Hi,
>
>I'm having problems making world... before I dig into this, does
> anyone already know what's going on? My source is current as of
> 11:30pm EST.
>
> thanks,
> John
>
> ===> cpp
> cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc 
>-I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE 
>-DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" 
>-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" 
>-I/usr/obj/usr/src/gnu/usr.bin/cc/cpp/../cc_tools 
>-I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -DPREFIX=\"/usr\"   
>-I/usr/obj/usr/src/tmp/usr/include -c 
>/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c
> yacc  -o cexp.c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cexp.y
> *** Signal 11

The canonical explanation for this sort of thing is processor or
memory problems.  Would that fit?

Greg
--
See complete headers for address, home page and phone numbers
finger [EMAIL PROTECTED] for PGP public key


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make world failure (signal 11 in cpp)

[John W. DeBoskey]

> On Wednesday, 25 August 1999 at 23:39:56 -0400, John W. DeBoskey wrote:
> > Hi,
> >
> >I'm having problems making world... before I dig into this, does
> > anyone already know what's going on? My source is current as of
> > 11:30pm EST.
> >
> > thanks,
> > John
> >
> > ===> cpp
> > cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc 
>-I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE 
>-DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" 
>-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" 
>-I/usr/obj/usr/src/gnu/usr.bin/cc/cpp/../cc_tools 
>-I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -DPREFIX=\"/usr\"   
>-I/usr/obj/usr/src/tmp/usr/include -c 
>/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c
> > yacc  -o cexp.c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cexp.y
> > *** Signal 11
> 
> The canonical explanation for this sort of thing is processor or
> memory problems.  Would that fit?
> 
> Greg
> --
> See complete headers for address, home page and phone numbers
> finger [EMAIL PROTECTED] for PGP public key


   I really doubt it, though I can replace the memory and swap
machines tomorrow if I need to. It is a stock machine from Dell
with no mods.

   This machine has been dedicated to building -current SNAP's
for more than 8 months. When this machine has problems, the typical
problem is bad code getting into the system, or a corrupted
filesystem (I nolonger run any of my filesystems async for this
reason).

   fyi, this problem does replicate at the exact same location. It
appears to actually be yacc...

/usr/obj/usr/src/gnu/usr.bin/cc/cpp %ls -al
drwxr-xr-x   2 root  wheel 512 Aug 25 23:53 .
drwxr-xr-x  16 root  wheel 512 Aug 25 23:47 ..
-rw-r--r--   1 root  wheel   92936 Aug 25 23:53 cccp.o
-rw---   1 root  wheel  147456 Aug 25 23:53 yacc.core
/usr/obj/usr/src/gnu/usr.bin/cc/cpp %file yacc.core
yacc.core: ELF 32-bit LSB core file, Intel 80386, version 1 (FreeBSD), from 'yacc'

gdb says the following:

(no debugging symbols found)...
Core was generated by `yacc'.
Program terminated with signal 11, Segmentation fault.
#0  0x8051bec in free ()

   I guess I'll try to build a debug version next...

Thanks,
John



To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Re: make world failure (signal 11 in cpp)

[Jeroen Ruigrok/Asmodai]

* Greg Lehey ([EMAIL PROTECTED]) [990826 06:19]:
>On Wednesday, 25 August 1999 at 23:39:56 -0400, John W. DeBoskey wrote:

>> ===> cpp
>> cc -O -pipe -I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc 
>-I/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/config -DFREEBSD_NATIVE 
>-DHAVE_CONFIG_H -DDEFAULT_TARGET_VERSION=\"egcs-2.91.66\" 
>-DDEFAULT_TARGET_MACHINE=\"i386-unknown-freebsd\" 
>-I/usr/obj/usr/src/gnu/usr.bin/cc/cpp/../cc_tools 
>-I/usr/src/gnu/usr.bin/cc/cpp/../cc_tools -DPREFIX=\"/usr\"   
>-I/usr/obj/usr/src/tmp/usr/include -c 
>/usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cccp.c
>> yacc  -o cexp.c /usr/src/gnu/usr.bin/cc/cpp/../../../../contrib/egcs/gcc/cexp.y
>> *** Signal 11
>
>The canonical explanation for this sort of thing is processor or
>memory problems.  Would that fit?

Could I think, but...

Last time I had that when making a week/two week old CURRENT to the
current CURRENT I got sig 11's on all my compiles.

I had to install a snapshot cc in order to rebuilt libc and cc and
then make world again. Everything compiled core dumped with the first
compiler. After reinstalling cc, no more problems.

So compliers and Sig 11's are harder to troubleshoot, at least IMHO.

HTH,

-- 
Jeroen Ruigrok van der Werven  asmodai(at)wxs.nl
The BSD Programmer's Documentation Project 
Network/Security SpecialistBSD: Technical excellence at its best
Man shall not live by bread alone.


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message