Re: 2.4.0-test9-pre2: pcmcia 3c59x doesn't work

From: Dag B (dagb@os.telia.no)
Date: Tue Sep 19 2000 - 17:07:49 EDT

  • Next message: Andrea Arcangeli: "Re: (reiserfs) Re: An elevator algorithm (patch)"

    Linus Torvalds wrote:

    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.

    [note: neither of these kernels worked for me]

    >> >
    >> > -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

    [snip]

    > >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

    Nah. Didn't help:

    Yenta IRQ list 0698, PCI irq11
    Socket status: 30000006
    Yenta IRQ list 0698, PCI irq11
    Socket status: 30000020
    cs: cb_alloc(bus 6): vendor 0x115d, device 0x0003
    PCI: Failed to allocate resource 0 for PCI device 115d:0003
    PCI: Failed to allocate resource 1 for PCI device 115d:0003
    PCI: Failed to allocate resource 2 for PCI device 115d:0003
    PCI: Failed to allocate resource 6 for PCI device 115d:0003
    PCI: Device 06:00.0 not available because of resource collisions
    PCI: Failed to allocate resource 0 for PCI device 115d:0103
    PCI: Failed to allocate resource 1 for PCI device 115d:0103
    PCI: Failed to allocate resource 2 for PCI device 115d:0103
    PCI: Failed to allocate resource 6 for PCI device 115d:0103
    PCI: Device 06:00.1 not available because of resource collisions

    With Tigran's fix, resource 0 is successfully allocated, and the message
    is approximately:
    Found 04:00 [115d/0003] 000200 00
    PCI: Failed to allocate resource 1 for PCI device 115d:0003
    PCI: Failed to allocate resource 2 for PCI device 115d:0003
    PCI: Failed to allocate resource 6 for PCI device 115d:0003
    PCI: Enabling device 04:00.0 (0000 -> 0003)
    Found 04:01 [115d/0103] 000300 00
    PCI: Failed to allocate resource 1 for PCI device 115d:0103
    PCI: Failed to allocate resource 2 for PCI device 115d:0103
    PCI: Failed to allocate resource 6 for PCI device 115d:0103
    PCI: Enabling device 04:00.1 (0000 -> 0003)

    But loading the driver reveals hw-addr == 0:0:0:0:0:0, and ifconfig'ing
    the interface causes a hang.

    If I parse the message from Martin Mares
    (http://www.cs.helsinki.fi/linux/linux-kernel/2000-38/0532.html)

    correctly, a fix is possibly needed in
    ./drivers/pcmcia/yenta.c , and not in ./drivers/pci/pci.c ?

    I tried to grok it, but I never got very much beyond 'Hello World\n'....
    I notice that most devices in this laptop get IRQ 11. Is this an
    indication of anything?

    dagblap:~# lspci -v | grep -i irq
            Flags: bus master, medium devsel, latency 168, IRQ 11
            Flags: bus master, medium devsel, latency 168, IRQ 11
            Flags: bus master, medium devsel, latency 32, IRQ 11
            Flags: bus master, medium devsel, latency 32, IRQ 11
            Flags: bus master, medium devsel, latency 32, IRQ 11
            Flags: medium devsel, IRQ 5
            Flags: medium devsel, IRQ 11
            Flags: medium devsel, IRQ 11

    dagblap:~# cat /proc/interrupts
               CPU0
      0: 92925 XT-PIC timer
      1: 3 XT-PIC keyboard
      2: 0 XT-PIC cascade
     11: 431 XT-PIC Texas Instruments PCI1225, Texas
    Instruments PCI1225 (#2), eth0
     12: 0 XT-PIC PS/2 Mouse
     13: 0 XT-PIC fpu
     14: 874 XT-PIC ide0
     15: 3 XT-PIC ide1
    NMI: 0
    ERR: 0

    Dag B
    -
    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/



    This archive was generated by hypermail 2b29 : Tue Sep 19 2000 - 17:10:49 EDT