"Maciej W. Rozycki" <[EMAIL PROTECTED]> writes:
> On 4 May 2001, Eric W. Biederman wrote:
>
> > The example that sticks out in my head is we rely on the MP table to
> > tell us if the local apic is in pic_mode or in virtual wire mode.
> > When all we really have to do is ask it.
>
> You can't.
On 4 May 2001, Eric W. Biederman wrote:
> The example that sticks out in my head is we rely on the MP table to
> tell us if the local apic is in pic_mode or in virtual wire mode.
> When all we really have to do is ask it.
You can't. IMCR is write-only and may involve chipset-specific
side-effe
> O.k. I was simply thinking that if we weren't reprogramming the mtrrs, it
> would be a good idea to make certain we didn't map any PCI drivers
> into a write back area.
What if the BIOS set up an mtrr for a device ?
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Alan Cox <[EMAIL PROTECTED]> writes:
> > 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.
>
> It becomes more and more obv
Linus Torvalds <[EMAIL PROTECTED]> writes:
> On 4 May 2001, Eric W. Biederman wrote:
> >
> > 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
> >th
On 4 May 2001, Eric W. Biederman wrote:
>
> 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.
This one I'd really hesitate
> 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.
It becomes more and more obvious over time exactly why. One problem however
is
Alan Cox <[EMAIL PROTECTED]> 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 bra
> 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 beca
Alan Cox <[EMAIL PROTECTED]> writes:
> > I suspect it would be safe to round up to the next megabyte, possibly up
> > to 64MB or so. But much more would make me nervous.
> > Any suggestions?
>
> I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large
> stuck at the top of R
Linus Torvalds wrote:
>
> On Thu, 3 May 2001, Alan Cox wrote:
> >
> > Obvious one is to go to the next power of two clear.
>
> The question is mainly _which_ power of two.
>
> I don't think we can round up infinitely, as that might just end up
> causing us to not have any PCI space at all. O
On Thu, 3 May 2001, Edward Spidre wrote:
>
> Sure, I'm more than willing to test out patches. Just
> let me know which version of source to apply it
> against.
Ok, this is not a patch per se, just a description of what I think should
work..
In include/asm-i386/pci.h, change the line
#d
> I suspect it would be safe to round up to the next megabyte, possibly up
> to 64MB or so. But much more would make me nervous.
> Any suggestions?
I'd go for 1MByte simply because I've not seen an EBDA/NVRAM area that large
stuck at the top of RAM. 1Mb would fix the Dell. (It was only when I sa
Linus Torvalds wrote:
> The question is mainly _which_ power of two.
>
> I don't think we can round up infinitely, as that might just end up
> causing us to not have any PCI space at all. Or we could end up deciding
> that real PCI space is memory, and then getting a clash when a real device
> tr
On Thu, 3 May 2001, Alan Cox wrote:
>
> Obvious one is to go to the next power of two clear.
The question is mainly _which_ power of two.
I don't think we can round up infinitely, as that might just end up
causing us to not have any PCI space at all. Or we could end up deciding
that real PCI
> at ALL. Which means that Linux thinks that it is free... And Linux will
> place PCI devices there. Even though there certainly is memory there.
Ahah.. that explains the Dell inspiron 8000 cardbus + 256Mb bug as well.
> I'll have to work around the BIOS bug some way. Will you be willing to
> tr
On Thu, 3 May 2001, Edward Spidre wrote:
>
> Note: a diff between booting with mem and without it
> yield the same results (the user-defined phys ram map
> is identical to the bios provided one)
Interesting. Your BIOS-provided memory map is buggy:
> BIOS-provided physical RAM map:
> BIOS-e820
17 matches
Mail list logo
