Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have
On Thu, Jun 23, 2011 at 10:42:29PM +0200, Rafael J. Wysocki wrote: > On Thursday, June 23, 2011, Jesse Barnes wrote: > > On Tue, 21 Jun 2011 17:48:16 -0700 > > Ram Pai wrote: > > > I assume majority of the platforms will have enough resources to satisfy > > > all > > > the resource requests, and their BIOS would have done a decent job. > > > > > > Even if the BIOS has not done a decent job, and there are enough resources > > > available we should not see a regression. > > > > > > The only platforms that would expose a regression is when resources are > > > under > > > contention and the BIOS has assigned enough resource to the cardbus > > > bridge but > > > not to some other device. It will be hard to find such a platform, but I > > > am > > > sure there is one out somewhere there. > > > > > > I am sure we will see; some day, reports of regression because that > > > platform > > > would have the exact right characteristics to expose the issue. But then > > > that > > > platform is a highly constrained platform in the first place. Its > > > debatable if > > > that should be characterised as a regression, or a platform that was > > > riding on > > > good luck till now. > > > > > > Even Oliver's platform is a highly constrained platform, and we probably > > > can > > > treat his platform as 'riding on good luck till now'. > > > > > > We won't be able to satisfy all the platforms with resource constraints. > > > I > > > think our probable choice is to select a solution that breaks least > > > number of > > > platforms and special case those broken platforms through kernel command > > > line > > > parameters. > > > > Another option is to hide the new allocation behavior behind a kernel > > parameter. I know Bjorn has opposed this in the past because really > > this sort of thing should "just work". But so far it hasn't, and we've > > had to revert both Bjorn's resource tracking changes as well as the > > re-allocation code. > > > > Hiding it behind a boot option would at least let us improve things > > over time and potentially switch over to new resource code in the > > future... > > > > Thoughts? > > Do I understand correctly that at the moment we have two set of systems, > one of which works with the new code and doesn't work with the old code > and the other one conversely? Here is the current state: (a) As of 2.6.39, for platforms whose BIOS have not allocated enough resources to its devices, those devices will **continue to not work**. An example of such a platform is the one whose BIOS has not allocated enough resources to SRIOV BARs. (b) With Yinghai's patch the commit "PCI: update bridge resources to get more big ranges when allocating space (again)" http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da7822e5ad71ec9b745b412639f1e5e0ba795a20 Most of the platforms that were not working in (a) will start working, but will break a few platforms, that have resource constraints and whose BIOS has not allocated enough resources to some of its devices. Oliver's and Ben Hutching's platform are two of the known platforms; as of now. (c) with my patch all the above platforms will start working. But the 4th patch in the series raises a genuine concern that it might break resource-constrained platforms with cardbus bridges. The question is which one of these is a lesser-evil :) Personally I think we should merge all the patches except the 4th patch, and support Oliver's platform through kernel command line parameter. And I think we should revert Yinghai's patch for now and merge it with all other patches in the 3.0.1 timeframe after thorough testing. RP -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have
On Wed, Jun 22, 2011 at 12:13:01AM +0200, Dominik Brodowski wrote: > Hey, > > On Tue, Jun 21, 2011 at 02:36:22PM -0700, Jesse Barnes wrote: > > On Tue, 21 Jun 2011 09:23:21 -0700 > > Ram Pai wrote: > > > > > On Tue, Jun 21, 2011 at 09:57:00AM +0200, Dominik Brodowski wrote: > > > > On Mon, Jun 20, 2011 at 03:47:17PM -0700, Ram Pai wrote: > > > > > Allocate resources to cardbus bridge only after all other genuine > > > > > resources requests are satisfied. Dont retry if resource allocation > > > > > for cardbus-bridge fails. > > > > > > > > Well, for those who use cardbus cards, cardbus resources aren't "nice to > > > > have", they are absolutely required. Of course, not all cardbus cards > > > > need > > > > as many resources as are currently assigned, so I wouldn't oppose a > > > > patch > > > > which marks _some_ of the currently assigned resources as "nice to > > > > have". > > > > But this approach -- 0 required, all "nice to have" -- seems wrong to > > > > me. > > > > > > Do you know how much minimal resource is good enough? The value, before > > > this patch, was 256 for IO ports and 64M for memory. > > > > > > BTW: If the BIOS has already assigned enough resources for all the > > > devices on > > > the system, no devices will be starved including the cardbus. The OS > > > intervenes > > > and is forced to make this hard choice only when it sees unassigned > > > resources to > > > some devices along with resource contention. > > > > Dominik, presumably you have a few good cardbus test machines; can you > > give Ram's patches a try? If we know they break existing > > configurations, I'm afraid we'll just have to revert the whole > > re-allocation patch yet again. If your stuff survives, I'll ping Linus > > to see what he thinks, though he'll probably want to revert in any > > case... > > Actually, I only have one cardbus-capable test machine, which does work in > very most cases, and also I do care much more about the PCMCIA side of > things than the PCI/CardBus side... Therefore, all I could do is some more > or less informed guessing about how much minimal resource we should try to > allocate... I assume majority of the platforms will have enough resources to satisfy all the resource requests, and their BIOS would have done a decent job. Even if the BIOS has not done a decent job, and there are enough resources available we should not see a regression. The only platforms that would expose a regression is when resources are under contention and the BIOS has assigned enough resource to the cardbus bridge but not to some other device. It will be hard to find such a platform, but I am sure there is one out somewhere there. I am sure we will see; some day, reports of regression because that platform would have the exact right characteristics to expose the issue. But then that platform is a highly constrained platform in the first place. Its debatable if that should be characterised as a regression, or a platform that was riding on good luck till now. Even Oliver's platform is a highly constrained platform, and we probably can treat his platform as 'riding on good luck till now'. We won't be able to satisfy all the platforms with resource constraints. I think our probable choice is to select a solution that breaks least number of platforms and special case those broken platforms through kernel command line parameters. RP -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have
On Tue, Jun 21, 2011 at 09:57:00AM +0200, Dominik Brodowski wrote: > On Mon, Jun 20, 2011 at 03:47:17PM -0700, Ram Pai wrote: > > Allocate resources to cardbus bridge only after all other genuine > > resources requests are satisfied. Dont retry if resource allocation > > for cardbus-bridge fails. > > Well, for those who use cardbus cards, cardbus resources aren't "nice to > have", they are absolutely required. Of course, not all cardbus cards need > as many resources as are currently assigned, so I wouldn't oppose a patch > which marks _some_ of the currently assigned resources as "nice to have". > But this approach -- 0 required, all "nice to have" -- seems wrong to me. Do you know how much minimal resource is good enough? The value, before this patch, was 256 for IO ports and 64M for memory. BTW: If the BIOS has already assigned enough resources for all the devices on the system, no devices will be starved including the cardbus. The OS intervenes and is forced to make this hard choice only when it sees unassigned resources to some devices along with resource contention. RP -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 4/4] PCI: make cardbus-bridge resources nice-to-have
Allocate resources to cardbus bridge only after all other genuine
resources requests are satisfied. Dont retry if resource allocation
for cardbus-bridge fails.
Tested-by: Oliver Hartkopp
Signed-off-by: Ram Pai
---
drivers/pci/setup-bus.c | 20 +---
1 files changed, 13 insertions(+), 7 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 4f8873e..023fc9c 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -742,7 +742,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
return 1;
}
-static void pci_bus_size_cardbus(struct pci_bus *bus)
+static void pci_bus_size_cardbus(struct pci_bus *bus,
+ struct resource_list_x *add_head)
{
struct pci_dev *bridge = bus->self;
struct resource *b_res = &bridge->resource[PCI_BRIDGE_RESOURCES];
@@ -753,12 +754,14 @@ static void pci_bus_size_cardbus(struct pci_bus *bus)
* a fixed amount of bus space for CardBus bridges.
*/
b_res[0].start = 0;
- b_res[0].end = pci_cardbus_io_size - 1;
+ b_res[0].end = 0;
b_res[0].flags |= IORESOURCE_IO | IORESOURCE_SIZEALIGN;
+ add_to_list(add_head, bridge, b_res, pci_cardbus_io_size - 1, 1);
b_res[1].start = 0;
- b_res[1].end = pci_cardbus_io_size - 1;
+ b_res[1].end = 0;
b_res[1].flags |= IORESOURCE_IO | IORESOURCE_SIZEALIGN;
+ add_to_list(add_head, bridge, b_res+1, pci_cardbus_io_size - 1, 1);
/*
* Check whether prefetchable memory is supported
@@ -778,16 +781,19 @@ static void pci_bus_size_cardbus(struct pci_bus *bus)
*/
if (ctrl & PCI_CB_BRIDGE_CTL_PREFETCH_MEM0) {
b_res[2].start = 0;
- b_res[2].end = pci_cardbus_mem_size - 1;
+ b_res[2].end = 0;
b_res[2].flags |= IORESOURCE_MEM | IORESOURCE_PREFETCH |
IORESOURCE_SIZEALIGN;
+ add_to_list(add_head, bridge, b_res+2, pci_cardbus_mem_size -
1, 1);
b_res[3].start = 0;
- b_res[3].end = pci_cardbus_mem_size - 1;
+ b_res[3].end = 0;
b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_SIZEALIGN;
+ add_to_list(add_head, bridge, b_res+3, pci_cardbus_mem_size -
1, 1);
} else {
b_res[3].start = 0;
- b_res[3].end = pci_cardbus_mem_size * 2 - 1;
+ b_res[3].end = 0;
b_res[3].flags |= IORESOURCE_MEM | IORESOURCE_SIZEALIGN;
+ add_to_list(add_head, bridge, b_res+3, pci_cardbus_mem_size * 2
- 1, 1);
}
}
@@ -805,7 +811,7 @@ void __ref __pci_bus_size_bridges(struct pci_bus *bus,
switch (dev->class >> 8) {
case PCI_CLASS_BRIDGE_CARDBUS:
- pci_bus_size_cardbus(b);
+ pci_bus_size_cardbus(b, add_head);
break;
case PCI_CLASS_BRIDGE_PCI:
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 3/4] PCI: make SRIOV resources nice-to-have
From: Yinghai Lu
Allocate resources to SRIOV BARs only after all other genuine resources
requests are satisfied. Dont retry if resource allocation for SRIOV BARs fail.
Signed-off-by: Ram Pai
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index c282c48..4f8873e 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -672,6 +672,16 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned
long mask,
if (r->parent || (r->flags & mask) != type)
continue;
r_size = resource_size(r);
+#ifdef CONFIG_PCI_IOV
+ /* add SRIOV BARs to nice-to-have list */
+ if (add_head && i >= PCI_IOV_RESOURCES &&
+ i <= PCI_IOV_RESOURCE_END) {
+ r->end = r->start - 1;
+ add_to_list(add_head, dev, r, r_size, 1);
+ children_add_size += r_size;
+ continue;
+ }
+#endif
/* For bridges size != alignment */
align = pci_resource_alignment(dev, r);
order = __ffs(align) - 20;
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 2/4] PCI : ability to resize assigned pci-resource
Currently pci-bridges are allocated enough resources to satisfy their immediate
requirements. Any additional resource-requests fail if additional free space,
contiguous to the one already allocated, is not available. This behavior is not
satisfying when sufficient contiguous resources, that can satisfy the request,
is available in a different location.
This patch provides the ability to expand a allocated resource. This behavior
is particularly useful to satisfy larger size nice-to-have resource requests,
like SRIOV BARs or cardbus bridges.
Signed-off-by: Ram Pai
---
drivers/pci/setup-bus.c | 30 ++---
drivers/pci/setup-res.c | 152 +--
include/linux/pci.h |1 +
kernel/resource.c | 98 ---
4 files changed, 206 insertions(+), 75 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index e42b89a..c282c48 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -34,6 +34,7 @@ struct resource_list_x {
resource_size_t start;
resource_size_t end;
resource_size_t add_size;
+ resource_size_t min_align;
unsigned long flags;
};
@@ -58,7 +59,7 @@ struct resource_list_x {
*/
static void add_to_list(struct resource_list_x *head,
struct pci_dev *dev, struct resource *res,
-resource_size_t add_size)
+resource_size_t add_size, resource_size_t min_align)
{
struct resource_list_x *list = head;
struct resource_list_x *ln = list->next;
@@ -77,13 +78,16 @@ static void add_to_list(struct resource_list_x *head,
tmp->end = res->end;
tmp->flags = res->flags;
tmp->add_size = add_size;
+ tmp->min_align = min_align;
list->next = tmp;
}
static void add_to_failed_list(struct resource_list_x *head,
struct pci_dev *dev, struct resource *res)
{
- add_to_list(head, dev, res, 0);
+ add_to_list(head, dev, res,
+ 0 /* dont care */,
+ 0 /* dont care */);
}
static void __dev_sort_resources(struct pci_dev *dev,
@@ -152,13 +156,19 @@ static void adjust_resources_sorted(struct
resource_list_x *add_head,
idx = res - &list->dev->resource[0];
add_size=list->add_size;
- if (!resource_size(res) && add_size) {
-res->end = res->start + add_size - 1;
-if(pci_assign_resource(list->dev, idx))
+ if (!resource_size(res)) {
+ res->end = res->start + add_size - 1;
+ if(pci_assign_resource(list->dev, idx))
reset_resource(res);
- } else if (add_size) {
- adjust_resource(res, res->start,
- resource_size(res) + add_size);
+ } else {
+ resource_size_t align = list->min_align;
+ res->flags |= list->flags &
+ (IORESOURCE_STARTALIGN|IORESOURCE_SIZEALIGN);
+ if (pci_reassign_resource(list->dev, idx, add_size,
+ align))
+ dev_printk(KERN_DEBUG, &list->dev->dev,
+ "failed to add optional resources res=%pR\n",
+ res);
}
out:
tmp = list;
@@ -615,7 +625,7 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
b_res->end = b_res->start + size0 - 1;
b_res->flags |= IORESOURCE_STARTALIGN;
if (size1 > size0 && add_head)
- add_to_list(add_head, bus->self, b_res, size1-size0);
+ add_to_list(add_head, bus->self, b_res, size1-size0, 4096);
}
/**
@@ -718,7 +728,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
b_res->end = size0 + min_align - 1;
b_res->flags |= IORESOURCE_STARTALIGN | mem64_mask;
if (size1 > size0 && add_head)
- add_to_list(add_head, bus->self, b_res, size1-size0);
+ add_to_list(add_head, bus->self, b_res, size1-size0, min_align);
return 1;
}
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
index bc0e6ee..e8a94d5 100644
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -129,16 +129,16 @@ void pci_disable_bridge_window(struct pci_dev *dev)
}
#endif /* CONFIG_PCI_QUIRKS */
+
+
static int __pci_assign_resource(struct pci_bus *bus, struct pci_dev *dev,
-int resno)
+ int resno, resource_size_t size, resource_size_t align)
{
struct resource *res = dev->resource + resno;
- reso
[PATCH 1/4] PCI: honor child buses add_size in hot plug configuration
From: Yinghai Lu
Recent pci_bus_size change will use add_size for minimum resource size for pcie
hotplug bridge. But it does not pass children back to parent bridge.
that will have problem on some setup like:
hot add one chassis with more hot plug slots.
for example: if the chassis have 8 slots, we should allocate 8x2M instead
of one 1x2M for parent bus.
So try to get child add_size and compare the sum with parent bus bridge...
Signed-off-by: Yinghai Lu
Reviewed-by: Ram Pai
---
drivers/pci/setup-bus.c | 26 ++
1 files changed, 26 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index 1e9e5a5..e42b89a 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -536,6 +536,20 @@ static resource_size_t calculate_memsize(resource_size_t
size,
return size;
}
+static resource_size_t get_res_add_size(struct resource_list_x *add_head,
+ struct resource *res)
+{
+ struct resource_list_x *list;
+
+ /* check if it is in add_head list */
+ for (list = add_head->next; list && list->res != res;
+ list = list->next);
+ if (list)
+ return list->add_size;
+
+ return 0;
+}
+
/**
* pbus_size_io() - size the io window of a given bus
*
@@ -555,6 +569,7 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
struct pci_dev *dev;
struct resource *b_res = find_free_bus_resource(bus, IORESOURCE_IO);
unsigned long size = 0, size0 = 0, size1 = 0;
+ resource_size_t children_add_size = 0;
if (!b_res)
return;
@@ -575,10 +590,15 @@ static void pbus_size_io(struct pci_bus *bus,
resource_size_t min_size,
size += r_size;
else
size1 += r_size;
+
+ if (add_head)
+ children_add_size += get_res_add_size(add_head,
r);
}
}
size0 = calculate_iosize(size, min_size, size1,
resource_size(b_res), 4096);
+ if (children_add_size > add_size)
+ add_size = children_add_size;
size1 = (!add_head || (add_head && !add_size)) ? size0 :
calculate_iosize(size, min_size+add_size, size1,
resource_size(b_res), 4096);
@@ -620,6 +640,7 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
int order, max_order;
struct resource *b_res = find_free_bus_resource(bus, type);
unsigned int mem64_mask = 0;
+ resource_size_t children_add_size = 0;
if (!b_res)
return 0;
@@ -661,6 +682,9 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
if (order > max_order)
max_order = order;
mem64_mask &= r->flags & IORESOURCE_MEM_64;
+
+ if (add_head)
+ children_add_size += get_res_add_size(add_head,
r);
}
}
align = 0;
@@ -677,6 +701,8 @@ static int pbus_size_mem(struct pci_bus *bus, unsigned long
mask,
align += aligns[order];
}
size0 = calculate_memsize(size, min_size, 0, resource_size(b_res),
min_align);
+ if (children_add_size > add_size)
+ add_size = children_add_size;
size1 = (!add_head || (add_head && !add_size)) ? size0 :
calculate_memsize(size, min_size+add_size, 0,
resource_size(b_res), min_align);
--
1.7.0.4
--
To unsubscribe from this list: send the line "unsubscribe linux-mmc" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 0/4] PCI: fix cardbus and sriov regressions
The following patch-set fixes regressions caused by: the commit "PCI: update bridge resources to get more big ranges when allocating space (again)" http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da7822e5ad71ec9b745b412639f1e5e0ba795a20 patch 1/4: correctly calculates the additional resource size for hotplug bridges. patch 2/4: ability to resize assigned pci-resource. patch 3/4: makes SRIOV BARs a nice-to-have resource, which means resources will be attempted to assign, but not gauranteed to succeed. patch 4/4: makes cardbus bridge resources nice-to-have resource. The regression was caused because on some platforms with limited i/o and mem resources, the nice-to-have resources were allocated ahead of absolutely-required resources, thus starving the latter. The patchset will ensure that all the mandatory resource requirements are satisfied before any nice-to-have resource requirements are satisfied. -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: sdhci-pci fails on 3.0.0-rc1 on Dell E6510
On Wed, Jun 08, 2011 at 08:26:14AM +0200, Oliver Hartkopp wrote: > On 08.06.2011 00:18, Yinghai Lu wrote: > > thanks. > > > > second report. > > > > can you send out whole boot log. > > See attached dmesg output. The 'dirty' is due to the revert test of the sd/mmc > stuff (see below) - the rest is plain 3.0.0-rc2. > > Good luck :-) Looks like the kernel; by default, tries to allocate mem resource of size 0x400 each to the BARs of the cardbus bridge. This cannot be satisfied meeting all the constraints. The BIOS had not allocated the resource to begin with. Anyone knows if the default value can be reduced to something smaller? Or Should the resource requirements of cardbus bridge be made nice-to-have? > > Oliver > > > > > On 06/07/2011 01:06 PM, Oliver Hartkopp wrote: > >> On 07.06.2011 20:36, Oliver Hartkopp wrote: > >> Hi all, > >> > >> the commit "PCI: update bridge resources to get more big ranges when > >> allocating space (again)" > >> > >> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=da7822e5ad71ec9b745b412639f1e5e0ba795a20 > >> > >> kills my SD-Card and the PCMCIA slot on a Dell E6510 with the latest > >> 3.0.0-rc2 ... > >> RP > >> When i revert the commit both the MMC/SD stuff and the PCMCIA re-appears. > >> > >> Any idea? > >> > >> See my attached boot.diff / kernel config > >> > >> Regards, > >> Oliver > >> > >> > >> > >> > >>> On 06.06.2011 21:56, Chris Ball wrote: > Hi Oliver, > > On Mon, Jun 06 2011, Oliver Hartkopp wrote: > >>> dmesg is a bit more detailed: > >>> [6.242510] sdhci-pci :03:00.1: SDHCI controller found > >>> [1180:e822] (rev 3) > >>> [6.244168] sdhci-pci :03:00.1: PCI INT B -> GSI 19 (level, > >>> low) -> IRQ 19 > >>> [6.245788] sdhci-pci :03:00.1: BAR 0 is not iomem. Aborting. > >>> [6.247609] sdhci-pci :03:00.1: PCI INT B disabled > > If you get a chance to do some bisecting, that would be extremely > helpful -- even just building 3.0 from *before* the MMC tree was > merged would help a lot, since if the problem still happens before > the MMC merge we might be looking at some kind of generic PCI bug. > > >>> > >>> > >>> Hi Chris, > >>> > >>> i just reverted this pull of your merge window patches in my 3.0.0-rc2 > >>> tree: > >>> > >>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=8c1c77ff9be27137fa7cbbf51efedef1a2ae915b;hp=f3ae1c75203535f65448517e46c8dd70a56b6c71 > >>> > >>> And you were right: The problem still exists. So it might be from the PCI > >>> subsystem :-( > >>> > >>> [6.167106] sdhci: Secure Digital Host Controller Interface driver > >>> [6.167108] sdhci: Copyright(c) Pierre Ossman > >>> [6.194731] ehci_hcd :00:1a.0: cache line size of 64 is not > >>> supported > >>> [6.195140] ehci_hcd :00:1a.0: irq 16, io mem 0xf697 > >>> [6.196423] sdhci-pci :03:00.1: SDHCI controller found [1180:e822] > >>> (rev 3) > >>> [6.196429] sdhci-pci :03:00.1: found 1 slot(s) > >>> [6.196447] sdhci-pci :03:00.1: PCI INT B -> GSI 19 (level, low) > >>> -> IRQ 19 > >>> [6.196451] sdhci-pci :03:00.1: BAR 0 is not iomem. Aborting. > >>> [6.196459] sdhci-pci :03:00.1: PCI INT B disabled > >>> > >>> Well then, i'll reset my tree and look for differences in the PCI boot > >>> messages. > >>> > >>> Thanks, > >>> Oliver > >> > > > ...snip... RP -- To unsubscribe from this list: send the line "unsubscribe linux-mmc" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
