Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 17 Jul 2002 11:35:35 -0700
From:      Terry Lambert <tlambert2@mindspring.com>
To:        Szilveszter Adam <sziszi@bsd.hu>
Cc:        freebsd-current@FreeBSD.ORG
Subject:   Re: Interesting panic very early in the boot
Message-ID:  <3D35B8F7.9915A14D@mindspring.com>
References:  <3D3508A0.B7D12818@mindspring.com> <200207171657.MAA28965@glatton.cnchost.com> <20020717173822.GB1068@fonix.adamsfamily.xx>

next in thread | previous in thread | raw e-mail | index | archive | help
Szilveszter Adam wrote:
> Ok, so it's time to speculate a bit more about this.
> 
> Although I have been seeing this panic since Sunday, only one other
> person has reported it so far. Although it may be that this is due to
> the fact that developers do not run up-to-date -CURRENT and hence do not
> see problems that are this "new" (and I bet that the tinderbox only
> tests building, but does not try to actually run the stuff), perhaps
> there is a different explanation.
> 
> Bakul mentioned that the panic happens on a PPro. For me, it's a PII. I
> am using a CPUTYPE setting of "p2" in /etc/make.conf. This gets
> converted to a "-march=pentiumpro" on the actual compile line. This may
> be the same for the PPro. This suggests a remote possibility that there
> might be a problem with this option, so this is the next thing that I am
> going to test.
> 
> We'll see...

My bet on the root cause, if I am correct, means that if you change
the amount of physical RAM installed in the machine, the problem will
go away, and that the problem is probably rare because it depends on
certain things that are more complicated, after Matt's changes after
my complaints about machdep.c reservations on large memory machines,
as the amount of physical RAM approaches the size of the address
space.

My suggestion for DISABLE_PSE was intended to mask the problem,
not fix it, because the root problem I was thinking of isn't
really related to that.

That change masking the problem would have been information.

The change *not* masking the problem is *not* information; i.e.
the masking as a side effect would have been prrof of the theory,
but lack of masking doesn't disprove the theory.

Finding a gremlin body squished in the gears is proof of gremlins,
but not finding one doesn't prove the non-existance of gremlins...
;^).

-- Terry

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3D35B8F7.9915A14D>