From: Gary Hade <garyhade@us.ibm.com>
To: Ingo Molnar <mingo@elte.hu>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
Jesse Barnes <jbarnes@virtuousgeek.org>,
Dave Airlie <airlied@gmail.com>,
kernel list <linux-kernel@vger.kernel.org>,
Gary Hade <garyhade@us.ibm.com>,
Thomas Gleixner <tglx@linutronix.de>
Subject: Re: regression fixed by using pci=rom
Date: Fri, 9 May 2008 09:45:51 -0700 [thread overview]
Message-ID: <20080509164551.GB6255@us.ibm.com> (raw)
In-Reply-To: <20080509064402.GA15754@elte.hu>
On Fri, May 09, 2008 at 08:44:03AM +0200, Ingo Molnar wrote:
>
> * Linus Torvalds <torvalds@linux-foundation.org> 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@us.ibm.com
http://www.ibm.com/linux/ltc
next prev parent reply other threads:[~2008-05-09 16:46 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-05-08 23:54 regression fixed by using pci=rom Dave Airlie
2008-05-09 0:17 ` Jesse Barnes
2008-05-09 1:46 ` Linus Torvalds
2008-05-09 6:29 ` Jesse Barnes
2008-05-09 16:05 ` Gary Hade
2008-05-09 6:44 ` Ingo Molnar
2008-05-09 16:45 ` Gary Hade [this message]
2008-05-09 17:26 ` Linus Torvalds
2008-05-09 18:54 ` Gary Hade
2008-05-09 1:36 ` 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=20080509164551.GB6255@us.ibm.com \
--to=garyhade@us.ibm.com \
--cc=airlied@gmail.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
/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