In article <[EMAIL PROTECTED]>, Dag Bakke  <[EMAIL PROTECTED]> 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 [EMAIL PROTECTED]
Please read the FAQ at http://www.tux.org/lkml/

Reply via email to