On Fri, Jul 26, 2013 at 10:28 PM, H. Peter Anvin wrote:
> On 07/26/2013 01:24 PM, Ingo Molnar wrote:
>>
>> Am I being too pedantic in expecting that we still mark it
>> e820-reserved?
>>
>> This area really isnt an ordinary PCI resource such as a
>> BAR or an MMIO region. It's truly system RAM (wh
On 07/26/2013 01:24 PM, Ingo Molnar wrote:
>
> Am I being too pedantic in expecting that we still mark it
> e820-reserved?
>
> This area really isnt an ordinary PCI resource such as a
> BAR or an MMIO region. It's truly system RAM (which cannot
> be moved/reallocated), used by graphics hardwar
On Thu, Jul 25, 2013 at 05:48:42PM -0700, H. Peter Anvin wrote:
> On 07/25/2013 05:31 PM, Linus Torvalds wrote:
> > On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> >> So the bootloader is just as likely to step on things... what happens
> >> when/if it does?
> >
> > This isn't a new pro
On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> To clarify: it'll either be marked reserved or not listed at all in e820,
> which is why I did this early, before any other e820 stuff like the "RAM
> buffer" are allocated, and before we could use the iomem resource (or maybe
> we could even early p
On 07/25/2013 04:17 PM, Jesse Barnes wrote:
> Well, it's ok if the boot loader writes to this memory, the worst
> that'll happen is you'll see garbage on the screen. If the boot loader
> tries to do MMIO mapping on top it'll get into trouble... but why would
> it do that?
>
> Jesse
Much worse: i
On 07/25/2013 05:31 PM, Linus Torvalds wrote:
> On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
>> So the bootloader is just as likely to step on things... what happens
>> when/if it does?
>
> This isn't a new problem. We've had this "firmware tables don't show
> all devices" issue before
So the bootloader is just as likely to step on things... what happens when/if
it does?
Ingo Molnar wrote:
>
>* Jesse Barnes wrote:
>
>> Patch 2/2 has the description, but suffice it to say I'm
>> not really pleased with this, though it does solve a
>> problem we have. On some machines, we ge
On Thu, 25 Jul 2013 17:31:29 -0700
Linus Torvalds wrote:
> On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> > So the bootloader is just as likely to step on things... what happens
> > when/if it does?
>
> This isn't a new problem. We've had this "firmware tables don't show
> all device
On Thu, 25 Jul 2013 20:31:27 -0700
"H. Peter Anvin" wrote:
> On 07/25/2013 07:14 PM, Jesse Barnes wrote:
> > To clarify: it'll either be marked reserved or not listed at all in e820,
> > which is why I did this early, before any other e820 stuff like the "RAM
> > buffer" are allocated, and befo
To clarify: it'll either be marked reserved or not listed at all in e820, which
is why I did this early, before any other e820 stuff like the "RAM buffer" are
allocated, and before we could use the iomem resource (or maybe we could even
early per Linus? I'll check).
Jesse
--
Jesse Barnes, In
On Thu, Jul 25, 2013 at 3:42 PM, H. Peter Anvin wrote:
> So the bootloader is just as likely to step on things... what happens when/if
> it does?
This isn't a new problem. We've had this "firmware tables don't show
all devices" issue before.
The only odd thing about this one is how the quirk in
Well, it's ok if the boot loader writes to this memory, the worst
that'll happen is you'll see garbage on the screen. If the boot loader
tries to do MMIO mapping on top it'll get into trouble... but why would
it do that?
Jesse
On Thu, 25 Jul 2013 15:42:25 -0700
"H. Peter Anvin" wrote:
> So the
On Thu, Jul 25, 2013 at 01:16:48PM -0700, Jesse Barnes wrote:
> On Thu, 25 Jul 2013 22:05:51 +0200
> Ingo Molnar wrote:
> > > Chris has some patches on top to add a new E820 type so
> > > we can look up the region later, which removes some
> > > redundant code in the i915 driver at least.
> > >
On Thu, 25 Jul 2013 22:05:51 +0200
Ingo Molnar wrote:
>
> * Jesse Barnes wrote:
>
> > Patch 2/2 has the description, but suffice it to say I'm
> > not really pleased with this, though it does solve a
> > problem we have. On some machines, we get MMIO space
> > allocated on top of this hidd
Patch 2/2 has the description, but suffice it to say I'm not really
pleased with this, though it does solve a problem we have. On some
machines, we get MMIO space allocated on top of this hidden memory,
which can cause problems. I'm not sure if there are similar problems
for other hunks of the ad
15 matches
Mail list logo
