Re: [RFC v2 PATCH 1/1] PCI: override BIOS/firmware resource allocation

From: Bjorn Helgaas
Date: Fri Oct 22 2010 - 17:50:50 EST


On Friday, October 22, 2010 12:59:37 pm Ram Pai wrote:
> On Fri, Oct 22, 2010 at 11:55:18AM -0600, Bjorn Helgaas wrote:
> > If we assign resources to bridges with no devices behind them while
> > starving bridges that DO have devices behind them, I think that's a bug.
> > It'd be great if you could isolate and fix that before we complicate
> > things by throwing Yinghai's patch into the mix.
>
> Yes. I sent out a patch an hour back with a fix for that.

Yeah, I saw that right after I hit "send" :-)

> > I think it'd interesting to have a debug parameter like "pci=assign-all"
> > that meant "ignore all BIOS PCI config and start from scratch." I'm
> > sure we'd trip over lots of issues and it would be easier to resolve them
> > before trying to make things fancier.
>
> The patch that I had sent 3-weeks back had that feature. It can be triggered
> by pci=override=always.
>
> However, your arguement earlier was that it would make no difference because
> no one will enable that parameter by default. This means hardly anyone will
> report any bugs.

I just meant as a development tool, maybe not even upstream, as a way
to exercise the Linux allocation code. I don't have much confidence
in it yet. We certainly don't want Linux to ignore the BIOS config in
general; we should just use it unless we can tell it's broken.

> Gating "Yinghai's patch or any other approach" on fixing all the bugs in the
> pci subsystem, implicitly means 'go away' ;). I hope you dont mean that.

Oh, no.

> I propose to bring Yinghai's patch, for that will enable us to expose bugs and
> at the same time it will enable SRIOV on *all* the platforms that don't have it.

Yes, we should consider Yinghai's patch again after all the known issues
with it are fixed. I just don't know whether we're there yet.

Bjorn
--
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/