From: ebiederm@xmission.com (Eric W. Biederman)
To: Alan Cox <alan@lxorguk.ukuu.org.uk>
Cc: torvalds@transmeta.com (Linus Torvalds),
beamz_owl@yahoo.com (Edward Spidre),
linux-kernel@vger.kernel.org (Kernel Mailing List)
Subject: Re: Possible PCI subsystem bug in 2.4
Date: 04 May 2001 10:13:56 -0600 [thread overview]
Message-ID: <m17kzxnlbv.fsf@frodo.biederman.org> (raw)
In-Reply-To: <E14vhsG-0007Xe-00@the-village.bc.nu>
In-Reply-To: Alan Cox's message of "Fri, 4 May 2001 16:52:07 +0100 (BST)"
Alan Cox <alan@lxorguk.ukuu.org.uk> writes:
> > There are a couple of options here.
> > 1) read the MTRRs unless the BIOS is braindead it will set up that area as
> > write-back. At any rate we shouldn't ever try to allocate a pci region
> > that is write-back cached.
>
> 'unless the BIOS is braindead'. Right. We only got into this problem because
> the BIOS _was_ braindead.
Well I did provide a suggestion so you don't have to second guess...
Usually it's actually easier to read the memory size from the northbridge
than to parse the E820 map.
However since it is different kinds of braindamage to mess up the MTRRs,
and the E820 memory map, it is worth a shot. Personally I think MTRRs
are much easier to get right, because you don't need to take into
account what the BIOS is going to do just where your ram is.
As for braindead BIOS's in general any comments on totally nuking
them?
Seriously. With the general attitude of distrusting BIOS's I have
been amazed at the number of things linux expects the BIOS to get
right. In practice windows seem to trust the BIOS much less than
linux does.
Eric
next prev parent reply other threads:[~2001-05-04 16:16 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20010503140318.7583.qmail@web10704.mail.yahoo.com>
2001-05-03 17:08 ` Possible PCI subsystem bug in 2.4 Linus Torvalds
2001-05-03 17:51 ` Alan Cox
2001-05-03 18:12 ` Linus Torvalds
2001-05-03 18:22 ` Jeff Garzik
2001-05-03 18:31 ` Alan Cox
2001-05-04 15:41 ` Eric W. Biederman
2001-05-04 15:52 ` Alan Cox
2001-05-04 16:13 ` Eric W. Biederman [this message]
2001-05-04 17:04 ` Alan Cox
2001-05-05 5:41 ` Eric W. Biederman
2001-05-08 16:01 ` Maciej W. Rozycki
2001-05-09 15:45 ` Eric W. Biederman
2001-05-04 17:44 ` Linus Torvalds
2001-05-05 5:30 ` Eric W. Biederman
2001-05-05 7:17 ` Alan Cox
2001-05-04 11:34 ` Rogier Wolff
[not found] <20010503191655.67673.qmail@web10701.mail.yahoo.com>
2001-05-03 19:28 ` Linus Torvalds
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=m17kzxnlbv.fsf@frodo.biederman.org \
--to=ebiederm@xmission.com \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=beamz_owl@yahoo.com \
--cc=linux-kernel@vger.kernel.org \
--cc=torvalds@transmeta.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox