From: Linus Torvalds on 30 Jun 2010 19:20 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 6 Jul 2010 20:00 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 6 Jul 2010 21:00 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 7 Jul 2010 00:30 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/
|
Pages: 1 Prev: Removing dead SHARPSL_LOCOMO Next: financial advancement |