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 butt. 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. 8-) 8-). -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
