Re: Makeworld is dying...

2000-09-19 Thread James Housley

Steve Roome wrote:
> 
> On Mon, Sep 18, 2000 at 06:16:59PM +0100, Mark Ovens wrote:
> > On Mon, Sep 18, 2000 at 10:45:26AM -0400, James Housley wrote:
> > > Steve Roome wrote:
> > > >
> > > >
> > > > So could we change the text (something like, but better worded than
> > > > the following) in the FAQ, e.g. :
> > > >
> >
> > You should submit it as a PR. Ideally we'd like the SGML diffs, but
> > the plain text will do if you can't provide SGML.
> 
> I can supply diffs to the HTML (v3.2 it seems) versions that I have
> locally, better yet against the ones on the website. But how does one
> go about getting hold of the SGML versions, or did you mean HTML ?
> 
> Ta,
> 
> Steve
The simplest place is
http://www.FreeBSD.org/cgi/cvsweb.cgi/doc/en_US.ISO_8859-1/books/faq/book.sgml
.  It is also in the CVS repository if you have a copy locally.

Jim
-- 
Hi! I'm a .signature virus! Copy me in your ~/.signature
to help me spread! <- Save this lifeform ;-)
 S/MIME Cryptographic Signature


Re: Makeworld is dying...

2000-09-18 Thread James Housley

Steve Roome wrote:
> 
> 
> So could we change the text (something like, but better worded than
> the following) in the FAQ, e.g. :
> 
> Q: My programs occasionally die with Signal 11 ( or 10 ).
> 
> A: Signal 11 errors are caused when your process has attempted to
>access memory which the operating system has not granted it access
>to.
> 
>This could be caused by a number of different circumstances :
> 
> a) Most likely, if you're developing it yourself it's buggy
> code. (We've all been there!)
> 
> b) If it's a problem with part of the base FreeBSD system,
> it might be buggy code, but more often than not these problems
> are found long before us general FAQ readers get to use these
> bits of code.
> 
> If these problems are only affecting you, it's probably bad
> hardware.
> 
> In the case of a) you can use a debugger and find the point
> in the program which is attempting to access a bogus address
> and then fix it. [ you probably already know this if you're
> a programmer! ]
> 
> In the case of b) You need to verify the settings on your
> motherboard. Checking for hardware you might be running slightly
> out of spec, too fast, or mismatched hardware. Often setting
> memory wait states too short will trigger random signal 11's.
> An overclocked CPU will possibly also exhibit strange or similar
> symptoms.
> 
> Try running some memory testing programs, or do a make buildworld
> if you have the full source available for FreeBSD (after a few
> successful buildworlds it's probably safe to say the hardware
> is okay.).
> 
> See the SIG11 FAQ (LINK) for more information.
> 
> That's my idea for a rough draft anyway. I'm clearly illiterate
> though, please don't flame me for that!
> 
I like it because it also give some simple, usefully ways to verify the
problem.

Jim
-- 
microsoft: "where do you want to go today?"
linux: "where do you want to go tomorrow?"
BSD:   "are you guys coming, or what?"
 S/MIME Cryptographic Signature


Re: Makeworld is dying...

2000-09-18 Thread Steve Roome

On Sun, Sep 17, 2000 at 04:00:06PM +0930, Greg Lehey wrote:
> What you *should* do before sending out a reply like this is to check
> whether it's really in the FAQ or not.  It is
> (http://www.freebsd.org/FAQ/troubleshoot.html#AEN1570):

There's a lot of people who are quick to step up to the podium and
proclaim that all these signal elevens are caused by bad RAM, or bad
RAM settings. It *could* be a pointer arithmetic problem.

The FAQ ought to comment on this, and from recent personal experience,
the number of people who respond to these just quoting the FAQ gets
more annoying each time, mainly because it's something that doesn't
need to be said on the mailing lists... again.

In this case, it is possibly bad hardware, so maybes it's a fair call,
then again it can be caused by, e.g. freaky optimizations in gcc...

So could we change the text (something like, but better worded than
the following) in the FAQ, e.g. :

Q: My programs occasionally die with Signal 11 ( or 10 ).

A: Signal 11 errors are caused when your process has attempted to
   access memory which the operating system has not granted it access
   to.

   This could be caused by a number of different circumstances :

a) Most likely, if you're developing it yourself it's buggy
code. (We've all been there!)

b) If it's a problem with part of the base FreeBSD system,
it might be buggy code, but more often than not these problems
are found long before us general FAQ readers get to use these
bits of code.

If these problems are only affecting you, it's probably bad
hardware.

In the case of a) you can use a debugger and find the point
in the program which is attempting to access a bogus address
and then fix it. [ you probably already know this if you're
a programmer! ]

In the case of b) You need to verify the settings on your
motherboard. Checking for hardware you might be running slightly
out of spec, too fast, or mismatched hardware. Often setting
memory wait states too short will trigger random signal 11's.
An overclocked CPU will possibly also exhibit strange or similar
symptoms.

Try running some memory testing programs, or do a make buildworld
if you have the full source available for FreeBSD (after a few
successful buildworlds it's probably safe to say the hardware
is okay.). 

See the SIG11 FAQ (LINK) for more information.


That's my idea for a rough draft anyway. I'm clearly illiterate
though, please don't flame me for that!

Steve,



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



Re: Makeworld is dying...

2000-09-16 Thread Greg Lehey

On Sunday, 17 September 2000 at  9:24:47 +0300, Roman Shterenzon wrote:
> On Sat, 16 Sep 2000, Kent Stewart wrote:
>> "Paul A. Howes" wrote:
>>>
>>> All-
>>>
>>> When I attempt a buildworld on a brand new FreeBSD system (IBM/Cyrix-166+,
>>> 64MB memory, 20GB Maxtor drive), it dies while building the ncurses library.
>>> This happen whether it's the version of the source code on the 4.1 CD-Rom
>>> disc, or the latest and greatest 4-STABLE code from a cvsup.  Any help would
>>> be appreciated.  The tail of the trace log is included below.
>>
>> Signal 11's during a buildworld are usually caused by memory and a few
>> things such as cpu cooling. I finished a buildworld at 1:30 PDT (about
>> 2 hours before your message arrived) and I didn't have any problems.
>> Do you have another 64MB of memory that you could switch as a test of
>> your memory.
>
> Perhaps we should add an entry to a FAQ (if it's not already there),
> describing the problem, and, a good indication of a bad ram or undercooled
> cpu would be trying buildworld couple of times (without -DNOCLEAN) and
> watch where it fails.
> If it fails in different places - then it's almost sure hardware problem,
> if it fails in the same place, it's still can be a hardware problem, for
> example some c++ file which demands more memory then others to compile.
> Can someone add it to FAQ, or shall I fill a PR? :)

No.

What you *should* do before sending out a reply like this is to check
whether it's really in the FAQ or not.  It is
(http://www.freebsd.org/FAQ/troubleshoot.html#AEN1570):

Q: My programs occasionally die with Signal 11 errors.

A: This can be caused by bad hardware (memory, motherboard, etc.). Try
   running a memory-testing program on your PC. Note that, even though
   every memory testing program you try will report your memory as
   being fine, it's possible for slightly marginal memory to pass all
   memory tests, yet fail under operating conditions (such as during
   bus mastering DMA from a SCSI controller like the Adaptec 1542,
   when you're beating on memory by compiling a kernel, or just when
   the system's running particularly hot).

   The SIG11 FAQ (listed below) points up slow memory as being the
   most common problem. Increase the number of wait states in your
   BIOS setup, or get faster memory.

   For me the guilty party has been bad cache RAM or a bad on-board
   cache controller. Try disabling the on-board (secondary) cache in
   the BIOS setup and see if that solves the problem.

   There's an extensive FAQ on this at the (link) SIG11 problem FAQ

Now you *could* consider better wording of the text.  This entry
belies its age by the hardware it refers to.

Greg
--
Finger [EMAIL PROTECTED] for PGP public key
See complete headers for address and phone numbers


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



Re: Makeworld is dying...

2000-09-16 Thread Roman Shterenzon


Perhaps we should add an entry to a FAQ (if it's not already there),
describing the problem, and, a good indication of a bad ram or undercooled
cpu would be trying buildworld couple of times (without -DNOCLEAN) and
watch where it fails.
If it fails in different places - then it's almost sure hardware problem,
if it fails in the same place, it's still can be a hardware problem, for
example some c++ file which demands more memory then others to compile.
Can someone add it to FAQ, or shall I fill a PR? :)

On Sat, 16 Sep 2000, Kent Stewart wrote:

> 
> 
> "Paul A. Howes" wrote:
> > 
> > All-
> > 
> > When I attempt a buildworld on a brand new FreeBSD system (IBM/Cyrix-166+,
> > 64MB memory, 20GB Maxtor drive), it dies while building the ncurses library.
> > This happen whether it's the version of the source code on the 4.1 CD-Rom
> > disc, or the latest and greatest 4-STABLE code from a cvsup.  Any help would
> > be appreciated.  The tail of the trace log is included below.
> 
> Signal 11's during a buildworld are usually caused by memory and a few
> things such as cpu cooling. I finished a buildworld at 1:30 PDT (about
> 2 hours before your message arrived) and I didn't have any problems.
> Do you have another 64MB of memory that you could switch as a test of
> your memory.
> 
> Kent
> 
> > 
> > Thanks!
> > 
> > --
> > Paul A. Howes
> > [EMAIL PROTECTED]
> > 
> > cc -fpic -DPIC -O -pipe -I. -I/usr/src/lib/libncurses -
> > /usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncur
> > ses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CON
> > FIG_H -DTERMIOS -I/usr/obj/usr/src/i386/usr/include -c
> > /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/alloc_entry.c -o
> > alloc_entry.So
> > 
> > cc: Internal compiler error: program cc1 got fatal signal 11
> > *** Error code 1
> > 
> > Stop in /usr/src/lib/libncurses.
> > *** Error code 1
> > 
> > Stop in /usr/src.
> > *** Error code 1
> > 
> > Stop in /usr/src.
> > *** Error code 1
> > 
> > Stop in /usr/src.
> > 
> > To Unsubscribe: send mail to [EMAIL PROTECTED]
> > with "unsubscribe freebsd-stable" in the body of the message
> 
> -- 
> Kent Stewart
> Richland, WA
> 
> mailto:[EMAIL PROTECTED]
> http://kstewart.urx.com/kstewart/index.html
> FreeBSD News http://daily.daemonnews.org/
> 
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message
> 



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



Re: Makeworld is dying...

2000-09-16 Thread Kent Stewart



"Paul A. Howes" wrote:
> 
> All-
> 
> When I attempt a buildworld on a brand new FreeBSD system (IBM/Cyrix-166+,
> 64MB memory, 20GB Maxtor drive), it dies while building the ncurses library.
> This happen whether it's the version of the source code on the 4.1 CD-Rom
> disc, or the latest and greatest 4-STABLE code from a cvsup.  Any help would
> be appreciated.  The tail of the trace log is included below.

Signal 11's during a buildworld are usually caused by memory and a few
things such as cpu cooling. I finished a buildworld at 1:30 PDT (about
2 hours before your message arrived) and I didn't have any problems.
Do you have another 64MB of memory that you could switch as a test of
your memory.

Kent

> 
> Thanks!
> 
> --
> Paul A. Howes
> [EMAIL PROTECTED]
> 
> cc -fpic -DPIC -O -pipe -I. -I/usr/src/lib/libncurses -
> /usr/src/lib/libncurses/../../contrib/ncurses/ncurses -I/usr/src/lib/libncur
> ses/../../contrib/ncurses/include -Wall -DFREEBSD_NATIVE -DNDEBUG -DHAVE_CON
> FIG_H -DTERMIOS -I/usr/obj/usr/src/i386/usr/include -c
> /usr/src/lib/libncurses/../../contrib/ncurses/ncurses/tinfo/alloc_entry.c -o
> alloc_entry.So
> 
> cc: Internal compiler error: program cc1 got fatal signal 11
> *** Error code 1
> 
> Stop in /usr/src/lib/libncurses.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> *** Error code 1
> 
> Stop in /usr/src.
> 
> To Unsubscribe: send mail to [EMAIL PROTECTED]
> with "unsubscribe freebsd-stable" in the body of the message

-- 
Kent Stewart
Richland, WA

mailto:[EMAIL PROTECTED]
http://kstewart.urx.com/kstewart/index.html
FreeBSD News http://daily.daemonnews.org/


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