Re: regression fixed by using pci=rom

[Gary Hade]

On Fri, May 09, 2008 at 08:44:03AM +0200, Ingo Molnar wrote:
> 
> * Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> wrote:
> 
> > On Thu, 8 May 2008, Jesse Barnes wrote:
> > > 
> > > Hm, yeah in many cases we definitely *do* want to try to get the 
> > > expansion ROM space allocated.  But maybe it should be a lower 
> > > priority than other BARs...  Gary?
> > 
> > The thing is, a lot of these things have been done this way because 
> > not doing them that way breaks.
> > 
> > We want to allocate expansion ROM space - even if we don't enable it - 
> > because not doing so will screw up bus sizing etc, and can make it 
> > impossible to allocate later.
> > 
> > In general, changing PCI allocation strategy is really _really_ 
> > dangerous, even when it is "right", because it tends to expose a lot 
> > of issues where something worked just because it was perhaps 
> > indirectly causing a layout that worked.
> 
> i tend to believe that the best strategy would be to generally do what 
> other OSs do for PCI BAR sizing and PCI resource setup [on desktop 
> systems that would be Windows in particular] - and i believe there are 
> still a number of gratuitous-looking differences in our code that seem 
> unnecessary. Especially on the myriads of desktop systems Windows is 
> what gets tested primarily, and by deviating from that legacy layout we 
> just set up ourselves for unnecessary failures.

Ingo, Would you (or others listening to this discussion) know
exactly what Windows does with respect to BIOS unassigned
expansion ROMs?  Does Windows attempt to obtain space for the
expansion ROMs at boot-time or does it perhaps have some sort
of strategy where space is allocated on an "as needed" basis
at run-time?

Gary

-- 
Gary Hade
System x Enablement
IBM Linux Technology Center
503-578-4503  IBM T/L: 775-4503
garyhade@xxxxxxxxxx
http://www.ibm.com/linux/ltc
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/