From: Linus Torvalds on
On Wed, Jun 30, 2010 at 2:15 PM, Ram Pai <linuxram(a)us.ibm.com> wrote:
> � � � PCI: skip release and reallocation of io port resources

Gaah. This still looks like just total ad-hoc hackery. The logic for
it all seems very fragile, just a random case made up from the one
failing issue. There's no underlying logic or design to it.

I still think that we should just make people explicitly ask for a
blank slate if the bios allocations don't work out. Rather than trying
to fix it up automatically, which has been a total rats nest of random
crud.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on
On Tue, Jul 6, 2010 at 4:13 PM, Yinghai Lu <yinghai(a)kernel.org> wrote:
>
> So you want to use pci=override_bios to reallocate all bios assigned resource include
> peer root buses resources and pci bridge resource and pci devices BAR?

In a perfect world, we'd never need this at all, but sicne that's not
an option, the second-best alternative might be something like the
following:

pci=override=off # default
pci=override=conflict # override only on conflicts
pci=override=<device> # clear BIOS allocations for <device> (and any
children, if it's a bus)

and possibly

pci=override=always # ignore BIOS allocations entirely

although I suspect that last one isn't really usable, since at a
minimum you'd have to honor things that ACPI ends up depending on.
Which is pretty much always going to happen for _some_ device.

What I _don't_ think is a good idea is to call it "try=1" and "try=2"
which is entirely uncomprehensible. Also, I do think we have to
default to "override=off", since even the "only for conflicts"
obviously triggers problems.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Yinghai Lu on
On 07/06/2010 04:58 PM, Linus Torvalds wrote:
> On Tue, Jul 6, 2010 at 4:13 PM, Yinghai Lu <yinghai(a)kernel.org> wrote:
>>
>> So you want to use pci=override_bios to reallocate all bios assigned resource include
>> peer root buses resources and pci bridge resource and pci devices BAR?
>
> In a perfect world, we'd never need this at all, but sicne that's not
> an option, the second-best alternative might be something like the
> following:
>
> pci=override=off # default
> pci=override=conflict # override only on conflicts
> pci=override=<device> # clear BIOS allocations for <device> (and any
> children, if it's a bus)

current:
if there is conflict, like pci bridge resources or pci devices resources is not in the scope of peer root bus resource range.
or pci devices is not in pci bridge resources range.
kernel would reject the resource and try to get new range in parent resource for the children.

so current default is overriding the conflicts already.

Maybe your conflicts have other meaning? like pci bridge resource size is not big enough?

or we can have use

pci=override=small_bridge

or

pci=override=bridges

instead?

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Andrew Hendry on
Is this the same or related issue?

http://lkml.org/lkml/2010/7/6/108
New messages since -rc4, X and graphics really slow after.

[ 1.387013] swapper:1 freeing invalid memtype bf788000-bf789000
[ 1.387409] swapper:1 freeing invalid memtype bf789000-bf78a000
[ 5.999675] modprobe:548 freeing invalid memtype d0000000-d0040000
[ 6.068347] modprobe:548 freeing invalid memtype d0140000-d0150000
[ 6.068647] modprobe:548 freeing invalid memtype d0150000-d0160000
[ 6.069661] modprobe:548 freeing invalid memtype d0170000-d01f0000
[ 6.085969] modprobe:548 freeing invalid memtype d01f0000-d0200000
[ 6.087673] modprobe:548 freeing invalid memtype d0210000-d0220000
[ 6.087900] modprobe:548 freeing invalid memtype d0220000-d0230000
[ 6.088092] modprobe:548 freeing invalid memtype d0230000-d0240000
[ 6.088317] modprobe:548 freeing invalid memtype d0240000-d0250000


On Wed, Jul 7, 2010 at 10:49 AM, Yinghai Lu <yinghai(a)kernel.org> wrote:
> On 07/06/2010 04:58 PM, Linus Torvalds wrote:
>> On Tue, Jul 6, 2010 at 4:13 PM, Yinghai Lu <yinghai(a)kernel.org> wrote:
>>>
>>> So you want to use pci=override_bios to reallocate all bios assigned resource include
>>> peer root buses resources and pci bridge resource and pci devices BAR?
>>
>> In a perfect world, we'd never need this at all, but sicne that's not
>> an option, the second-best alternative might be something like the
>> following:
>>
>> � pci=override=off # default
>> � pci=override=conflict # override only on conflicts
>> � pci=override=<device> # clear BIOS allocations for <device> (and any
>> children, if it's a bus)
>
> current:
> if there is conflict, like pci bridge resources or pci devices resources is not in the scope of peer root bus resource range.
> or pci devices is not in pci bridge resources range.
> kernel would reject the resource and try to get new range in parent resource for the children.
>
> so current default is overriding the conflicts already.
>
> Maybe your conflicts have other meaning? like pci bridge resource size is not big enough?
>
> or we can have use
>
> pci=override=small_bridge
>
> or
>
> pci=override=bridges
>
> instead?
>
> Thanks
>
> Yinghai
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo(a)vger.kernel.org
> More majordomo info at �http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at �http://www.tux.org/lkml/
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/