Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 24 Oct 2000, Eric W. Biederman wrote: > "David S. Miller" <[EMAIL PROTECTED]> writes: > > > > I bet PCI allows no such thing, thus to be totally safe I would > > conditionalize this feature on the specific bridge. Ie. only allow > > it for this bridge type, because I bet it is just some bug in the > > the address comparators which makes the bridge interpret zero ranges > > as "forward and respond to everything". > > I'm not certain of the details but I do know that it is legal. > To date I've only heard of it on ISA bridges, in particular the PIIXE. All ISA bridges use subtractive decode (== listen to whether somebody else claims it, and if not, take it yourself), and that's part of the spec. However, there can obviously be only one subtractive decoder on a bus: otherwise they'd end up fighting over the requests that don't have anybody on the primary bus. HOWEVER, you could potentially have multiple subtractive decoders if you have multiple buses, and that's actually kind of what my pseudo-patch tries to allow for. I'd like to see what the lspci outout is, but it is possible that the docking bridge is behind another PCI bridge, which would make subtractive decoding legal. The other alternative is that the docking bridge also is the ISA bridge, and knows where the ISA space is (not that hard - ISA IO space is 0x100-0x3ff, and ISA memory space is basically limited to 0xA-1M now that there are no machines with less than 16MB of RAM any more), and then acts as _one_ subtractive bridge, but forwards it to two different buses depending on what the range was. So there does seem to be "legal" ways of doing what the bridge may be doing. I'd still like to see what the PCI details on that system are, and if possible get some documentation on that particular bridge to see what that says.. 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 24 Oct 2000, Eric W. Biederman wrote: "David S. Miller" [EMAIL PROTECTED] writes: I bet PCI allows no such thing, thus to be totally safe I would conditionalize this feature on the specific bridge. Ie. only allow it for this bridge type, because I bet it is just some bug in the the address comparators which makes the bridge interpret zero ranges as "forward and respond to everything". I'm not certain of the details but I do know that it is legal. To date I've only heard of it on ISA bridges, in particular the PIIXE. All ISA bridges use subtractive decode (== listen to whether somebody else claims it, and if not, take it yourself), and that's part of the spec. However, there can obviously be only one subtractive decoder on a bus: otherwise they'd end up fighting over the requests that don't have anybody on the primary bus. HOWEVER, you could potentially have multiple subtractive decoders if you have multiple buses, and that's actually kind of what my pseudo-patch tries to allow for. I'd like to see what the lspci outout is, but it is possible that the docking bridge is behind another PCI bridge, which would make subtractive decoding legal. The other alternative is that the docking bridge also is the ISA bridge, and knows where the ISA space is (not that hard - ISA IO space is 0x100-0x3ff, and ISA memory space is basically limited to 0xA-1M now that there are no machines with less than 16MB of RAM any more), and then acts as _one_ subtractive bridge, but forwards it to two different buses depending on what the range was. So there does seem to be "legal" ways of doing what the bridge may be doing. I'd still like to see what the PCI details on that system are, and if possible get some documentation on that particular bridge to see what that says.. 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 24 Oct 2000, jamal wrote:
>
> (Now that i see Martin alive).
> Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
and it appears that the reason 2.2.x works is simply that 2.2.x doesn't
care because it doesn't keep track of resources at all - it just takes
what the devices say their resources are. And the bridge obviously
_works_, it just doesn't tell which area it bridges.
Can you do a "lspci -vvxxx" on a 2.2.x setup, so that I can take a look at
what the bridge claims it is doing.
I quite frankly have no idea what to do otherwise. We could special-case a
bridge resource that is all zeroes, and say that it's a "transparent"
bridge and just say that the resource is the same as the parent resource.
That might get you going. It's probably not the right thing to do, but you
_can_ try something like this in pci_read_bridge_bases(), where it does
if (base && base <= limit) {
res->flags |= ...
..
- }
+ } else {
+ /* Transparent bridge */
+ child->resource[0] = child->bus->resource[0];
+ }
..
(and do same thing for resource[1] and resource[2]..)
Does the above make it work for you? I don't know if PCI even has the
notion of transparent bridging, and quite frankly I doubt it does. The
above would be nothing but a hack that basically says "I don't understand
the resources of this bridge, so I'll just say it bridges everything".
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Linus, Martin (Now that i see Martin alive). Could we pursue this further? cheers, jamal -- Forwarded message -- Date: Sun, 15 Oct 2000 19:58:24 -0400 (EDT) From: jamal <[EMAIL PROTECTED]> To: Linus Torvalds <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED], Martin Mares <[EMAIL PROTECTED]> Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: > And I don't find any code that would ever have done this, either. It must > be somewhere, if 2.2 works for you. > I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest > Ehh. How about yet another debugging patch, to see what the bridge bases > are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Linus, Martin (Now that i see Martin alive). Could we pursue this further? cheers, jamal -- Forwarded message -- Date: Sun, 15 Oct 2000 19:58:24 -0400 (EDT) From: jamal [EMAIL PROTECTED] To: Linus Torvalds [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], Martin Mares [EMAIL PROTECTED] Subject: Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resource collisions (fwd) Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: And I don't find any code that would ever have done this, either. It must be somewhere, if 2.2 works for you. I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest Ehh. How about yet another debugging patch, to see what the bridge bases are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 24 Oct 2000, jamal wrote:
(Now that i see Martin alive).
Could we pursue this further?
The trouble definitely seems to be the fact that your PCI-PCI bridge does
not seem to have been set up for bridging:
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
and it appears that the reason 2.2.x works is simply that 2.2.x doesn't
care because it doesn't keep track of resources at all - it just takes
what the devices say their resources are. And the bridge obviously
_works_, it just doesn't tell which area it bridges.
Can you do a "lspci -vvxxx" on a 2.2.x setup, so that I can take a look at
what the bridge claims it is doing.
I quite frankly have no idea what to do otherwise. We could special-case a
bridge resource that is all zeroes, and say that it's a "transparent"
bridge and just say that the resource is the same as the parent resource.
That might get you going. It's probably not the right thing to do, but you
_can_ try something like this in pci_read_bridge_bases(), where it does
if (base base = limit) {
res-flags |= ...
..
- }
+ } else {
+ /* Transparent bridge */
+ child-resource[0] = child-bus-resource[0];
+ }
..
(and do same thing for resource[1] and resource[2]..)
Does the above make it work for you? I don't know if PCI even has the
notion of transparent bridging, and quite frankly I doubt it does. The
above would be nothing but a hack that basically says "I don't understand
the resources of this bridge, so I'll just say it bridges everything".
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Sorry for the delay, the docking station in question is a few kilometers away. On Fri, 13 Oct 2000, Linus Torvalds wrote: > And I don't find any code that would ever have done this, either. It must > be somewhere, if 2.2 works for you. > I can put up the 2.2 bootup with DEBUG in pci.c if this is of interest > Ehh. How about yet another debugging patch, to see what the bridge bases > are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the attached. cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #7 Sat Oct 14 12:18:35 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.472 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 IO base: 00c0 limit: 00c0 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning bus 02 Found 02:08 [102b/051b] 000300 00 Found 02:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 02:05.0 Found 02:38 [9004/6078] 000100 00 Found 02:40 [10b7/9050] 000200 00 Fixups for bus 02 PCI: Scanning for ghost devices on bus 2 IO base: limit: Bus scan for 02 returning with max=02 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 02:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 02:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 02:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device 02:05.0 PCI: Resource fcd8-fcdb (f=109, d=0,
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote: > > This is in addition to the debug statements from the previous email > Weirder results (like bus 0x0a) Ok, thanks - this part didn't get anything new, the bus numbers are just different due to the re-allocation, the actual bus windows are the same broken ones. I wonder why they are so broken. And why did 2.2 work? 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote:
>
> On Fri, 13 Oct 2000, Linus Torvalds wrote:>
> > Can you add the same extra debug code that I asked Dag Bakke to add for
> > his problem:
>
> Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking bridge) has not been set up correctly, and
has a serious lack of bridging windows, which causes the inability for
Linux to map any of the devices behind that bus. So you get printouts like
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
device Matrox Graphics, Inc. MGA 2164W [Millennium II] resource 1 size 4000
PCI: Failed to allocate resource 1 for Matrox Graphics, Inc. MGA 2164W
[Millennium II]
The above means that of the three bus windows set up for the PCI-PCI
bridge for the docking, two are disabled, and the last one is a
prefetchable memory window which is unacceptable to most devices (the
Matrox want a non-prefetchable window for its command area).
The other cases all show the same.
Martin, what's up? It looks like PCI-PCI bridge windows are not enabled
and set up at all. At least on this particular machine.
And I don't find any code that would ever have done this, either. It must
be somewhere, if 2.2 works for you.
Ehh. How about yet another debugging patch, to see what the bridge bases
are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the
place where it reads the PCI_IO_BASE/LIMIT and the UPPER bits, and add
printk("IO base: %04x%04x limit: %04x%04x\n",
io_base_hi, io_base_lo,
io_limit_hi, io_limit_lo);
to before the sanity test for the resource[0] case (ie before the stuff
that says "if (base && base <= limit) {" etc).
And do the same for the mem_base stuff for the resource[1] and resource[2]
cases.
Martin, any ideas on why only the prefetchable memory case would show up?
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > Oh, also, can you try to see what happens if you change the define for > > #define pcibios_assign_all_busses() 0 > > to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure > all buses, regardless of whether they have been set up some way by the > BIOS. Which might make a difference. > > But please do this separately from the extra debug code - I'd like to see > what the debug code says regardless of this change.. This is in addition to the debug statements from the previous email Weirder results (like bus 0x0a) cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Fri Oct 13 18:06:10 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.478 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Scanning bus 0a Found 0a:08 [102b/051b] 000300 00 Found 0a:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 0a:05.0 Found 0a:38 [9004/6078] 000100 00 Found 0a:40 [10b7/9050] 000200 00 Fixups for bus 0a PCI: Scanning for ghost devices on bus 10 Bus scan for 0a returning with max=0a Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 0a:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote:
> Can you add the same extra debug code that I asked Dag Bakke to add for
> his problem:
>
> -- snip from another email, because I'm lazy ---
>
> Please add a debug printk() to drivers/pci/setup-res.c to the very end of
> pci_assign_bus_resource(), just before the "return -EBUSY", something like
>
> printk("device %s resource %d size %08lx\n", dev->name, resno, size);
>
> just to see what it wants and why it fails..
>
> Also, it's probably worth printing out what the actual bus resources are,
> to possibly explain the failure. So add another line that says
>
> printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start,
> r->end);
>
Attached.
cheers,
jamal
Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux
(egcs-1.1.2 release)) #5 Fri Oct 13 18:02:43 EDT 2000
BIOS-provided physical RAM map:
BIOS-e820: 0009fc00 @ (usable)
BIOS-e820: 0400 @ 0009fc00 (reserved)
BIOS-e820: c000 @ 000c (reserved)
BIOS-e820: 0fef @ 0010 (usable)
BIOS-e820: 0001 @ 0fff (ACPI data)
BIOS-e820: 0006 @ 100a (reserved)
BIOS-e820: 0020 @ ffe0 (reserved)
On node 0 totalpages: 65520
zone(0): 4096 pages.
zone(1): 61424 pages.
zone(2): 0 pages.
Kernel command line:
Initializing CPU#0
Detected 498.471 MHz processor.
Console: colour VGA+ 80x25
Calibrating delay loop... 992.87 BogoMIPS
Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k
init, 0k highmem)
Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes)
Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes)
Page-cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 16384 (order: 5, 131072 bytes)
CPU: Intel Pentium III (Coppermine) stepping 03
Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED])
PCI: BIOS32 Service Directory structure at 0xc00ffe80
PCI: BIOS32 Service Directory entry at 0xffe90
PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02
PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2
PCI: Using configuration type 1
PCI: Probing PCI hardware
Scanning bus 00
Found 00:00 [8086/7190] 000600 00
Found 00:08 [8086/7191] 000604 01
Found 00:18 [104c/ac1c] 000607 02
Found 00:19 [104c/ac1c] 000607 02
Found 00:38 [8086/7110] 000680 00
Found 00:39 [8086/7111] 000101 00
PCI: IDE base address fixup for 00:07.1
Found 00:3a [8086/7112] 000c03 00
Found 00:3b [8086/7113] 000680 00
Found 00:88 [8086/124b] 000604 01
Fixups for bus 00
PCI: Scanning for ghost devices on bus 0
Scanning behind PCI bridge 00:01.0, config 010100, pass 0
Scanning bus 01
Found 01:00 [10c8/0006] 000300 00
Found 01:01 [10c8/8006] 000401 00
Fixups for bus 01
PCI: Scanning for ghost devices on bus 1
Bus scan for 01 returning with max=01
Scanning behind PCI bridge 00:03.0, config 00, pass 0
Scanning behind PCI bridge 00:03.1, config 00, pass 0
Scanning behind PCI bridge 00:11.0, config 020200, pass 0
Scanning bus 02
Found 02:08 [102b/051b] 000300 00
Found 02:28 [1095/0646] 000101 00
PCI: IDE base address fixup for 02:05.0
Found 02:38 [9004/6078] 000100 00
Found 02:40 [10b7/9050] 000200 00
Fixups for bus 02
PCI: Scanning for ghost devices on bus 2
Bus scan for 02 returning with max=02
Scanning behind PCI bridge 00:01.0, config 010100, pass 1
Scanning behind PCI bridge 00:03.0, config 00, pass 1
Scanning behind PCI bridge 00:03.1, config 00, pass 1
Scanning behind PCI bridge 00:11.0, config 020200, pass 1
Bus scan for 00 returning with max=0a
PCI: IRQ init
PCI: Interrupt Routing Table found at 0xc00fbd80
00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8
01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/
00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/
00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/
00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8
PCI: Bus 01 already known
PCI: Using IRQ router default [8086/1234] at 00:07.0
PCI: IRQ fixup
PCI: Allocating resources
PCI: Resource e000-e3ff (f=1208, d=0, p=0)
PCI: Resource 0860-086f (f=101, d=0, p=0)
PCI: Resource ece0-ecff (f=101, d=0, p=0)
PCI: Resource e780-e7ff (f=1208, d=0, p=0)
PCI: Resource fda0-fdaf (f=200, d=0, p=0)
PCI: Resource e500-e5ff (f=1208, d=0, p=0)
PCI: Resource fbffc000-fbff (f=200, d=0, p=0)
PCI: Cannot allocate resource region 1 of device 02:01.0
PCI: Resource fb00-fb7f (f=200, d=0, p=0)
PCI: Cannot allocate resource region 2 of device 02:01.0
PCI: Resource fcf8-fcff (f=109, d=0, p=0)
PCI: Cannot allocate resource region 0 of device 02:05.0
PCI: Resource fcf0-fcf3 (f=101, d=0, p=0)
PCI: Cannot allocate resource
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: > > Can you add the same extra debug code that I asked Dag Bakke to add for > his problem: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Thu, 12 Oct 2000, jamal wrote:
>
> I am attaching the debug output on bootup after defining DEBUG in pci.c
> and the i386 pci header file with test10-pre2
> Note: this is a Dell Lattitude docking station. The devices which are
> having resource problems are on the docking station. Works fine with 2.2
> kernels.
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
-- snip from another email, because I'm lazy ---
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev->name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r->flags, r->start,
r->end);
just after the line that says
if (!r)
continue;
in the same function.
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Thu, 12 Oct 2000, jamal wrote:
I am attaching the debug output on bootup after defining DEBUG in pci.c
and the i386 pci header file with test10-pre2
Note: this is a Dell Lattitude docking station. The devices which are
having resource problems are on the docking station. Works fine with 2.2
kernels.
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
-- snip from another email, because I'm lazy ---
Please add a debug printk() to drivers/pci/setup-res.c to the very end of
pci_assign_bus_resource(), just before the "return -EBUSY", something like
printk("device %s resource %d size %08lx\n", dev-name, resno, size);
just to see what it wants and why it fails..
Also, it's probably worth printing out what the actual bus resources are,
to possibly explain the failure. So add another line that says
printk("bus res %d %x %08lx-%08lx\n", i, r-flags, r-start,
r-end);
just after the line that says
if (!r)
continue;
in the same function.
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: Can you add the same extra debug code that I asked Dag Bakke to add for his problem: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, Linus Torvalds wrote: Oh, also, can you try to see what happens if you change the define for #define pcibios_assign_all_busses() 0 to a 1 in include/asm-i386/pci.h? That should force Linux to re-configure all buses, regardless of whether they have been set up some way by the BIOS. Which might make a difference. But please do this separately from the extra debug code - I'd like to see what the debug code says regardless of this change.. This is in addition to the debug statements from the previous email Weirder results (like bus 0x0a) cheers, jamal Linux version 2.4.0-test10 (root@PCARD38C) (gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)) #6 Fri Oct 13 18:06:10 EDT 2000 BIOS-provided physical RAM map: BIOS-e820: 0009fc00 @ (usable) BIOS-e820: 0400 @ 0009fc00 (reserved) BIOS-e820: c000 @ 000c (reserved) BIOS-e820: 0fef @ 0010 (usable) BIOS-e820: 0001 @ 0fff (ACPI data) BIOS-e820: 0006 @ 100a (reserved) BIOS-e820: 0020 @ ffe0 (reserved) On node 0 totalpages: 65520 zone(0): 4096 pages. zone(1): 61424 pages. zone(2): 0 pages. Kernel command line: Initializing CPU#0 Detected 498.478 MHz processor. Console: colour VGA+ 80x25 Calibrating delay loop... 992.87 BogoMIPS Memory: 255768k/262080k available (1095k kernel code, 5924k reserved, 70k data, 188k init, 0k highmem) Dentry-cache hash table entries: 32768 (order: 6, 262144 bytes) Buffer-cache hash table entries: 16384 (order: 4, 65536 bytes) Page-cache hash table entries: 65536 (order: 6, 262144 bytes) Inode-cache hash table entries: 16384 (order: 5, 131072 bytes) CPU: Intel Pentium III (Coppermine) stepping 03 Checking 'hlt' instruction... OK. POSIX conformance testing by UNIFIX mtrr: v1.36 (2221) Richard Gooch ([EMAIL PROTECTED]) PCI: BIOS32 Service Directory structure at 0xc00ffe80 PCI: BIOS32 Service Directory entry at 0xffe90 PCI: BIOS probe returned s=00 hw=01 ver=02.10 l=02 PCI: PCI BIOS revision 2.10 entry at 0xfc0ce, last bus=2 PCI: Using configuration type 1 PCI: Probing PCI hardware Scanning bus 00 Found 00:00 [8086/7190] 000600 00 Found 00:08 [8086/7191] 000604 01 Found 00:18 [104c/ac1c] 000607 02 Found 00:19 [104c/ac1c] 000607 02 Found 00:38 [8086/7110] 000680 00 Found 00:39 [8086/7111] 000101 00 PCI: IDE base address fixup for 00:07.1 Found 00:3a [8086/7112] 000c03 00 Found 00:3b [8086/7113] 000680 00 Found 00:88 [8086/124b] 000604 01 Fixups for bus 00 PCI: Scanning for ghost devices on bus 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 0 Scanning behind PCI bridge 00:03.0, config 00, pass 0 Scanning behind PCI bridge 00:03.1, config 00, pass 0 Scanning behind PCI bridge 00:11.0, config 020200, pass 0 Scanning behind PCI bridge 00:01.0, config 010100, pass 1 Scanning bus 01 Found 01:00 [10c8/0006] 000300 00 Found 01:01 [10c8/8006] 000401 00 Fixups for bus 01 PCI: Scanning for ghost devices on bus 1 Bus scan for 01 returning with max=01 Scanning behind PCI bridge 00:03.0, config 00, pass 1 Scanning behind PCI bridge 00:03.1, config 00, pass 1 Scanning behind PCI bridge 00:11.0, config 020200, pass 1 Scanning bus 0a Found 0a:08 [102b/051b] 000300 00 Found 0a:28 [1095/0646] 000101 00 PCI: IDE base address fixup for 0a:05.0 Found 0a:38 [9004/6078] 000100 00 Found 0a:40 [10b7/9050] 000200 00 Fixups for bus 0a PCI: Scanning for ghost devices on bus 10 Bus scan for 0a returning with max=0a Bus scan for 00 returning with max=0a PCI: IRQ init PCI: Interrupt Routing Table found at 0xc00fbd80 00:07 slot=00 0:00/ 1:00/ 2:00/ 3:63/def8 01:00 slot=00 0:60/def8 1:61/def8 2:00/ 3:00/ 00:03 slot=00 0:63/def8 1:63/def8 2:00/ 3:00/ 00:0d slot=00 0:62/def8 1:00/ 2:00/ 3:00/ 00:11 slot=00 0:62/def8 1:62/def8 2:62/def8 3:62/def8 PCI: Bus 01 already known PCI: Using IRQ router default [8086/1234] at 00:07.0 PCI: IRQ fixup PCI: Allocating resources PCI: Resource e000-e3ff (f=1208, d=0, p=0) PCI: Resource 0860-086f (f=101, d=0, p=0) PCI: Resource ece0-ecff (f=101, d=0, p=0) PCI: Resource e780-e7ff (f=1208, d=0, p=0) PCI: Resource fda0-fdaf (f=200, d=0, p=0) PCI: Resource e500-e5ff (f=1208, d=0, p=0) PCI: Resource fbffc000-fbff (f=200, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:01.0 PCI: Resource fb00-fb7f (f=200, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:01.0 PCI: Resource fcf8-fcff (f=109, d=0, p=0) PCI: Cannot allocate resource region 0 of device 0a:05.0 PCI: Resource fcf0-fcf3 (f=101, d=0, p=0) PCI: Cannot allocate resource region 1 of device 0a:05.0 PCI: Resource fce0-fce7 (f=101, d=0, p=0) PCI: Cannot allocate resource region 2 of device 0a:05.0
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Fri, 13 Oct 2000, jamal wrote:
On Fri, 13 Oct 2000, Linus Torvalds wrote:
Can you add the same extra debug code that I asked Dag Bakke to add for
his problem:
Attached.
Thanks.
It looks like the bridge that your docking devices are behind (I assume
that's just a regular docking bridge) has not been set up correctly, and
has a serious lack of bridging windows, which causes the inability for
Linux to map any of the devices behind that bus. So you get printouts like
bus res 0 0 -
bus res 1 0 -
bus res 2 1200 e400-e5ff
device Matrox Graphics, Inc. MGA 2164W [Millennium II] resource 1 size 4000
PCI: Failed to allocate resource 1 for Matrox Graphics, Inc. MGA 2164W
[Millennium II]
The above means that of the three bus windows set up for the PCI-PCI
bridge for the docking, two are disabled, and the last one is a
prefetchable memory window which is unacceptable to most devices (the
Matrox want a non-prefetchable window for its command area).
The other cases all show the same.
Martin, what's up? It looks like PCI-PCI bridge windows are not enabled
and set up at all. At least on this particular machine.
And I don't find any code that would ever have done this, either. It must
be somewhere, if 2.2 works for you.
Ehh. How about yet another debugging patch, to see what the bridge bases
are? In drivers/pci/pci.c, function pci_read_bridge_bases(), find the
place where it reads the PCI_IO_BASE/LIMIT and the UPPER bits, and add
printk("IO base: %04x%04x limit: %04x%04x\n",
io_base_hi, io_base_lo,
io_limit_hi, io_limit_lo);
to before the sanity test for the resource[0] case (ie before the stuff
that says "if (base base = limit) {" etc).
And do the same for the mem_base stuff for the resource[1] and resource[2]
cases.
Martin, any ideas on why only the prefetchable memory case would show up?
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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
[EMAIL PROTECTED] said: > The genuine Linux kernel distribution contains its own documentation > on how to build and configure it. Indeed it does. Documentation/Changes says: GCC --- You will need at least gcc 2.7.2 to compile the kernel. You currently have several options for gcc-derived compilers: gcc 2.7.2.3, various versions of egcs, the new gcc 2.95 and upcoming gcc 3.0, and experimental compilers like pgcc. For absolute stability, it is still recommended that gcc 2.7.2.3 be used to compile your kernel. egcs 1.1.2 should also work. gcc 2.95 is known to have problems, and using pgcc for your kernel is just asking for trouble. > The kgcc story looks to me like a lie from RedHat. In my opinion, they > just don't want to recognize that they have been loose. $ kgcc -v Reading specs from /usr/lib/gcc-lib/i386-glibc21-linux/egcs-2.91.66/specs gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release) Looks true to me. -- dwmw2 - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 09:56:46 -0400, Horst von Brand blurted forth: > - RH 7 ships a gcc patched from CVS sources in order to take advantage of >better (on ix86 mainly) optimizations on userland > - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to >be broken and not compilable with new gcc's > - No, the kernel won't be fixed. The work is huge, and the risk is much too >high > - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and >probably won't be, at least for some time) a supported configuration ah, thank you for setting the record straight. :) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 07:32:30 -0400, Jakub Jelinek blurted forth: > The fact that we recommend using kgcc (especially for 2.2 kernels) does not > mean that the default gcc is broken, but simply that using it for kernels > has not been tested yet too much and there can be e.g. bugs in the way > kernel uses inline assembly and the likes. Again, you miss the entire point, which you brush upon here: Redhat 7.0 is supposed to be a 'stable' release, suddenly thousands of people have been snagging the iso's for it, then there will be people who have problems compiling new kernels for it and they'll have problems for it once in awhile (i've seen quite a few cases reported on irc.. of course, i refer them to this list). Now, while this problem is being worked on and will eventually be solved, it just doesn't seem like a logical thing to me to call a buggy release 'stable'. But then, it's not my decision so I guess I'll just stop right there before someone else decides to flame me. ;) > See above, it does not sum up anything. The only thing is that if somebody > is reporting a bug on lkml, he'd just better first made sure it is > reproduceable with kgcc as well (bug reports for kernels compiled with > gcc 2.95 have been handled this way for a long time on lkml). Considering he's already stated that he's reproduced this on a few machines, I'd say that says it all right there. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000, Mike A. Harris wrote: > On 10 Oct 2000, Gnea wrote: > > >> Please add this to your list. Linux is unusable in these machines. > >> I have cc'ed Martin and Linus because they play in that PCI area. > > > >erm, looking at your list it says that you're using Redhat 7.0, which > >is known to ship with a buggy gcc, which is KNOWN to do nasty things > >with kernels. > > > >Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc > >version 2.96 2 > >731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > > > >yeah, that pretty much sums it up right there.. you may want to try > >something else. > > Once again misinformation and FUD. > > On Red Hat 7.0, use "kgcc" for kernel compilation. This is > really an FAQ... Instead of changing distributions, try reading > manuals. What manuals ? The genuine Linux kernel distribution contains its own documentation on how to build and configure it. The kgcc story looks to me like a lie from RedHat. In my opinion, they just don't want to recognize that they have been loose. Gérard. - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
> - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to > be broken and not compilable with new gcc's > - No, the kernel won't be fixed. The work is huge, and the risk is much too > high Actually I take the same attitude I took with 2.95. If you submit patches which fix cases where stuff got overoptimised or has wrong constraints I'll apply them but I still wont recommend using that gcc to build it Alan - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Gnea <[EMAIL PROTECTED]> said: > On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: [...] > erm, looking at your list it says that you're using Redhat 7.0, which > is known to ship with a buggy gcc, which is KNOWN to do nasty things > with kernels. OK, let's set a few things straight: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote: > > On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: > > > > > Ted, > > > > Please add this to your list. Linux is unusable in these machines. > > I have cc'ed Martin and Linus because they play in that PCI area. > > erm, looking at your list it says that you're using Redhat 7.0, which > is known to ship with a buggy gcc, which is KNOWN to do nasty things > with kernels. Can you tell me (when it is KNOWN) what nasty things does that gcc do to kernels? The thing that it does not compile vanilla 2.2.x kernels is not its fault, and if you choose to either use K preprocessing in assembly (but then no GNU extensions) or ANSI preprocessing plus you export memset/memcpy, it will actually build and work, see H.J.'s patchlets: http://www.lucon.org/linux/linux-2.2.14-gcc.patch http://www.lucon.org/linux/linux-2.2.17-library.patch The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. > > Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc > version 2.96 2 > 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > > yeah, that pretty much sums it up right there.. you may want to try > something else. See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Jakub - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, Oct 10, 2000 at 11:32:43PM -0500, Gnea wrote: On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Can you tell me (when it is KNOWN) what nasty things does that gcc do to kernels? The thing that it does not compile vanilla 2.2.x kernels is not its fault, and if you choose to either use KR preprocessing in assembly (but then no GNU extensions) or ANSI preprocessing plus you export memset/memcpy, it will actually build and work, see H.J.'s patchlets: http://www.lucon.org/linux/linux-2.2.14-gcc.patch http://www.lucon.org/linux/linux-2.2.17-library.patch The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Jakub - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
Gnea [EMAIL PROTECTED] said: On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: [...] erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. OK, let's set a few things straight: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration -- Dr. Horst H. von Brand mailto:[EMAIL PROTECTED] Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, ChileFax: +56 32 797513 - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
- RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high Actually I take the same attitude I took with 2.95. If you submit patches which fix cases where stuff got overoptimised or has wrong constraints I'll apply them but I still wont recommend using that gcc to build it Alan - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000, Mike A. Harris wrote: On 10 Oct 2000, Gnea wrote: Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. What manuals ? The genuine Linux kernel distribution contains its own documentation on how to build and configure it. The kgcc story looks to me like a lie from RedHat. In my opinion, they just don't want to recognize that they have been loose. Gérard. - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 07:32:30 -0400, Jakub Jelinek blurted forth: The fact that we recommend using kgcc (especially for 2.2 kernels) does not mean that the default gcc is broken, but simply that using it for kernels has not been tested yet too much and there can be e.g. bugs in the way kernel uses inline assembly and the likes. Again, you miss the entire point, which you brush upon here: Redhat 7.0 is supposed to be a 'stable' release, suddenly thousands of people have been snagging the iso's for it, then there will be people who have problems compiling new kernels for it and they'll have problems for it once in awhile (i've seen quite a few cases reported on irc.. of course, i refer them to this list). Now, while this problem is being worked on and will eventually be solved, it just doesn't seem like a logical thing to me to call a buggy release 'stable'. But then, it's not my decision so I guess I'll just stop right there before someone else decides to flame me. ;) See above, it does not sum up anything. The only thing is that if somebody is reporting a bug on lkml, he'd just better first made sure it is reproduceable with kgcc as well (bug reports for kernels compiled with gcc 2.95 have been handled this way for a long time on lkml). Considering he's already stated that he's reproduced this on a few machines, I'd say that says it all right there. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Wed, 11 Oct 2000 09:56:46 -0400, Horst von Brand blurted forth: - RH 7 ships a gcc patched from CVS sources in order to take advantage of better (on ix86 mainly) optimizations on userland - RH 7 ships kgcc for compiling the kernel, as the 2.2 kernels are known to be broken and not compilable with new gcc's - No, the kernel won't be fixed. The work is huge, and the risk is much too high - Yes, 2.4 should compile with new gcc's. But then again, it isn't (and probably won't be, at least for some time) a supported configuration ah, thank you for setting the record straight. :) -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 10 Oct 2000, Gnea wrote: >> Please add this to your list. Linux is unusable in these machines. >> I have cc'ed Martin and Linus because they play in that PCI area. > >erm, looking at your list it says that you're using Redhat 7.0, which >is known to ship with a buggy gcc, which is KNOWN to do nasty things >with kernels. > >Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc >version 2.96 2 >731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 > >yeah, that pretty much sums it up right there.. you may want to try >something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Microsoft Windows(tm). A thirty-two bit extension and graphical shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor which was written by a two-bit company that can't stand one bit of competition. - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: > > Ted, > > Please add this to your list. Linux is unusable in these machines. > I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On Tue, 10 Oct 2000 19:56:46 -0400 (EDT), jamal blurted forth: Ted, Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. -- .oO gnea at rochester dot rr dot com Oo. .oO url: http://garson.org/~gnea Oo. "You can tune a filesystem, but you can't tuna fish" -unknown - 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/
Re: Updated 2.4 TODO List -- new addition WAS(test9 PCI resourcecollisions (fwd)
On 10 Oct 2000, Gnea wrote: Please add this to your list. Linux is unusable in these machines. I have cc'ed Martin and Linus because they play in that PCI area. erm, looking at your list it says that you're using Redhat 7.0, which is known to ship with a buggy gcc, which is KNOWN to do nasty things with kernels. Linux version 2.4.0-test9-JHS1 ([EMAIL PROTECTED]) (gcc version 2.96 2 731 (Red Hat Linux 7.0)) #2 Thu Oct 5 11:59:31 EDT 2000 yeah, that pretty much sums it up right there.. you may want to try something else. Once again misinformation and FUD. On Red Hat 7.0, use "kgcc" for kernel compilation. This is really an FAQ... Instead of changing distributions, try reading manuals. -- Mike A. Harris - Linux advocate - Open source advocate Computer Consultant - Capslock Consulting Copyright 2000 all rights reserved -- Microsoft Windows(tm). A thirty-two bit extension and graphical shell to a sixteen bit patch to an eight bit operating system originally coded for a four bit microprocessor which was written by a two-bit company that can't stand one bit of competition. - 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/
