So the bootloader is just as likely to step on things... what happens when/if it does? Ingo Molnar <mingo@xxxxxxxxxx> wrote: > >* Jesse Barnes <jbarnes@xxxxxxxxxxxxxxxx> 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 hidden memory, which can cause >> problems. I'm not sure if there are similar problems for >> other hunks of the address space; if so it's possible >> this could be made more general (though the bits for >> looking up the address of this region are definitely >> Intel graphics specific). > >It looks pretty hardware specific. Discovering it the hard >way and marking it e820 reserved in an early quirk is what >the firmware should have done to begin with - and I doubt >the kernel could do anything significantly cleaner. > >How does Windows manage to not crash? By luckily never >allocating PCI resources on top of the RAM? Or does it have >a quirk? > >> 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. >> >> Any comments? I assume no one likes this, but maybe it's >> just another early quirk we'll have to live with... > >No strong feelings against it - my only suggestion would be >to make this more visible - right now it's added as e820 >reserved which hides amongst other areas already marked >reserved - would a low-key printk() of the range added make >it more apparent that a kernel quirk activated here? > >Just so that people know that it came from the kernel, not >the firmware. > >But in any case: > >Acked-by: Ingo Molnar <mingo@xxxxxxxxxx> > >Thanks, > > Ingo -- Sent from my mobile phone. Please excuse brevity and lack of formatting. _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
