Messages in this thread |  | | Date | Tue, 19 Sep 2000 23:07:49 +0200 | From | Dag B <> |
| |
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/
|  |