lkml.org 
[lkml]   [2000]   [Sep]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
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/

\
 
 \ /
  Last update: 2005-03-22 12:38    [W:0.039 / U:0.872 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site