Mark Santcroos wrote:
> On Thu, Aug 22, 2002 at 02:33:57AM -0700, Terry Lambert wrote:
> > options DISABLE_PSE
> > options DISABLE_PG_G
> Coming up next in this theater :-)
> btw, how does the report that using the other compiler fixed everything
> for KT fit in?
Coincidentally. It's hard to trigger the bug, so it's easy to
work around it accidently.
Most people who run into these type of bugs only really care about
getting things working, so if they accidently work around the thing,
they stop there, without digging down to discover the root cause.
It's much better to find out the root cause than to submerge the bug
again; making it "go away" for unknown reasons means it will probably
"come back" for unknown reasons at a later point, and bite you on the
No one in their right mind could believe that recompining a user
space application to avoid kernel-based faults actually fixes the
underlying problem. If I had to voice a theory, I would say that
the change in memory access patterns resulted in the problem being
submerged again. Most likely, a different set of system load
characteristics could cause it to resurface, everything else being
the same (in fact, that's what I would say is happening with the
original compiler; workarounds are commutative).
It's not really predictable at what future point that could/would
happen, so you basically you end up being left with a live landmine
somewhere in your back yard, and you think it's safe because poodles
no longer explode 15 minutes after they are tied to the apple tree.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message