Messages in this thread |  | | From | (Linus Torvalds) | Date | 19 Sep 2000 11:46:10 -0700 |
| |
In article <39C70CB0.AEB0DF8E@sgi.com>, Dag Bakke <dagb@sgi.com> wrote: >Tigran Aivazian wrote: >> >> On Mon, 18 Sep 2000, Derek Wildstar wrote: >> >> > On 18 Sep 2000, Alex Romosan wrote: >> > >> > I get the same thing with a Xircon realport 10/100/modem card. Works >> > great in test9-pre1 and test8. >> > >> > -dwild >> > >> >> did you try this patch? >> >> --- linux/drivers/pci/pci.c Mon Sep 18 12:35:11 2000 >> +++ work/drivers/pci/pci.c Mon Sep 18 13:12:20 2000 >> @@ -714,7 +714,7 @@ >> * We need to blast all three values with a single write. >> */ >> pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses); >> - if (!is_cardbus) { >> + if (is_cardbus) { >> /* Now we can scan all subordinate buses... */ >> max = pci_do_scan_bus(child); >> } else { >> > > >I did. >Didn't work for me. >My Xircom is still being detected. But PCI resource allocation still fails. >I'll be happy to set up a remote debug session for anyone interested...
There seem to be two potential problems with the new code. How about this instead:
First off, it's doing the subordinate bus write with a byte write, which is, as far as I can tell, not legal. When you update the bus information, you have to update it all at the same time.
Does it help if you change drivers/pci/pci.c pci_scan_bridge(), the line that says
pci_write_config_byte(dev, PCI_SUBORDINATE_BUS, max);
and you replace that with
buses = (buses & 0xff00ffff) | ((unsigned int)(child->subordinate) << 16); pci_write_config_dword(dev, PCI_PRIMARY_BUS, buses);
instead.
Second, if the cardbus bridge is already allocated by the BIOS, the "max bus" logic looks bogus. It looks like
if (!is_cardbus) { unsigned int cmax = pci_do_scan_bus(child); if (cmax > max) max = cmax; }
and it _should_ probably have something like
if (!is_cardbus) { .. same logic .. } else { unsigned int cmax = child->subordinate + 3; if (cmax > max) max = cmax; }
because otherwise we'd completely ignore the cardbus "max" values as far as I can tell, and if the machine has another bus it might be given the same bus value as the already-configured cardbus bridge.
Do the above two fixes help? If not, I suspect that we're better off just reverting the new PCI bus allocation until it's fixed.
Linus - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
|  |