Re: New MTRR fix for 2.1.120-pre3
Richard Gooch (rgooch@atnf.csiro.au)
Fri, 4 Sep 1998 11:34:58 +1000
Andy Higgins writes:
>
>
> On Fri, 4 Sep 1998, Richard Gooch wrote:
>
> > > >
> > Erm, 2.1.120-pre3 already had MTRR support. Did you get lockups when
> > enabling CONFIG_MTRR?
> > The patch I posted a few days ago shouldn't have any effect after
> > bootup. Are you sure you needed to apply it to fix post-boot lockups?
> >
> Lockups both with CONFIG_MTRR and w/out on 2.1.120-pre3(minus Patch) (post
> boot)..
>
> To make sure I wasn't dreaming I pulled the patch put a fresh 2.1.120-pre3
> without MTRR patch and without CONFIG_MTRR and reproduced the lockup
> under the following conditions (but unable to cause lockup with
> patch re-applied)
>
> heavily loaded apache_1.3.0 (frontpage extentions..hit heavy)
> heavily loaded squid_1.2 beta24 (caches spanning 2 24gb ultra's)
> find / -name 'blahblah'
>
> system:
> Adaptec onboard AIC-7880 Ultra SCSI host adapter (stock 2.1.120-pre3
> driver)
> smp enabled.
> max file descriptors upped from 256->1024
> Network card: tulip.c:v0.89H 5/23/98 becker@cesdis.gsfc.nasa.gov
> Lite-On 82c168 PNIC (not stock driver..needed PNIC)
> Video: Diamond Stealth PCI 4mb
>
> thing is from what I know about mtrr (which can fit in this dot ->.
> it 'should' be irrelevent whether enabled or not ..since
> its just a server..never run X-apps..no high video..etc..just
> disk and memory thrashing..
No, it's not quite this simple. Some BIOSes don't set the MTRRs the
same for all CPUs, so the existing MTRR support fixes this during the
bootup sequence. Having different MTRRs can cause problems later.
So the safe option for SMP machines is to enable CONFIG_MTRR.
My recent patch should only affect the bootup code, preventing general
MTRR manipulation before the system is ready. I don't know how it
could fix things post-boot.
Let me just clarify what I mean by "post-boot": I mean after you see
the "Freeing unused kernel memory: #k freed" message.
Regards,
Richard....
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/faq.html