* pci 0000:01:04.0: BAR 0: no parent found for of device
@ 2009-11-03 21:00 Helge Deller
[not found] ` <20091106062234.GC4574@lackof.org>
2009-11-10 16:56 ` Domenico Andreoli
0 siblings, 2 replies; 4+ messages in thread
From: Helge Deller @ 2009-11-03 21:00 UTC (permalink / raw)
To: linux-parisc; +Cc: Matthew Wilcox, John David Anglin
Hi all,
Something broke the stifb graphics driver in 2.6.32-rc5 (Linus' current head).
Somehow it seems, that the PCI subsystem does not activate this PCI slot:
Linux version 2.6.32-rc5-32bit (deller@p100) (gcc version 4.4.1 (GCC) ) #157 Tue Nov 3 21:49:24 CET 2009
...
Searching for devices...
Found devices:
1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b }
2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a }
3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a }
4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a }
5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a }
6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 }
7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 }
CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz
Setting cache flush threshold to 780 (1 CPUs online)
SBA found Astro 2.1 at 0xfed00000
Elroy version TR4.0 (0x5) found at 0xfed30000
PCI: Enabled native mode for NS87415 (pif=0x8f)
Elroy version TR4.0 (0x5) found at 0xfed32000
pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff]
^^^ HERE
...
STI GSC/PCI core graphics driver Version 0.9a
sti 0000:01:04.0: device not available because of BAR 0 [0xfa000000-0xfbffffff] collisions
sti 0000:01:04.0: Cannot enable PCI device
^^^ HERE
sti: probe of 0000:01:04.0 failed with error -22
STI PCI graphic ROM found at f3800000 (2048 kB), fb at f6000000 (32 MB)
id 35acda30-9a02587, conforms to spec rev. 8.0d
graphics card name: A1262A
sticon: Initializing STI text console.
Console: switching to colour STI console 128x48
stifb: 'A1262A' (id: 0x35acda30) not supported.
Linux agpgart interface v0.103
....
Hopefully someone of you has an idea what caused this change?
lspci reports:
01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03)
Flags: 66MHz, medium devsel
Memory at fa000000 (32-bit, non-prefetchable) [size=32M]
Expansion ROM at f2400000 [disabled] [size=64K]
Helge
^ permalink raw reply [flat|nested] 4+ messages in thread[parent not found: <20091106062234.GC4574@lackof.org>]
[parent not found: <4AF4890B.4050700@gmx.de>]
[parent not found: <20091106235405.GC5262@lackof.org>]
* Re: pci 0000:01:04.0: BAR 0: no parent found for of device [not found] ` <20091106235405.GC5262@lackof.org> @ 2009-11-06 23:55 ` Grant Grundler 2009-11-10 21:55 ` Helge Deller 0 siblings, 1 reply; 4+ messages in thread From: Grant Grundler @ 2009-11-06 23:55 UTC (permalink / raw) To: linux-parisc; +Cc: Helge Deller [ sorry - didn't realize I hit "reply" instead of "reply-all" ] On Fri, Nov 06, 2009 at 04:54:05PM -0700, Grant Grundler wrote: > On Fri, Nov 06, 2009 at 09:37:31PM +0100, Helge Deller wrote: > > Hi Grant, > > > > Thanks for your answers!!! > ... > >> IIRC, the graphics frame buffers are routed by every Elroy ELMMIO register > >> on all 4 Elroys. If you can get the machine to NOT HPMC, > >> ELMMIO resources should be listed in /proc/iomem for workstations. > > > > Ok, the good thing is, that it doesn't HPMCs. > > But sadly I have no clue about what you write above :-( > > Heh...Here is a short and probably inadequate explanation. > > Elroy has 3 MMIO range registers that determine which physical > addresses will get routed down to the PCI bus: > LMMIO 32-bit MMIO address range > ELMMIO "Extra" 32-bit MMIO address range > GMMIO 64-bit MMIO address range > > The Astro that is upstream (via ropes) is also programmed to route > specific addresses to specific Elroy devices. Including the ELMMIO > and GMMIO ranges. > > The upstream routing is essentially the negative decoding of the > downstream routing. So if f9000000-f9ffffff is routed down to > elroy with PCI01, then any addresses generated by the PCI devices > OUTSIDE of that range will get routed upstream since Elroy > is designed to believe there is no device on that bus that will > respond to addresses outside that range. > > It might be easiest to think of each MMIO transaction (read or write) > as a network packet traversing a fabric and the MMIO address is > the equivalent to an IP address. Each component in the path has > a "routing table" (one or more MMIO range registers) to decide > what to do with the packet. > > > > > Syslog says: > > SBA found Astro 2.1 at 0xfed00000 > > Elroy version TR4.0 (0x5) found at 0xfed30000 > > PCI: Enabled native mode for NS87415 (pif=0x8f) > > Elroy version TR4.0 (0x5) found at 0xfed32000 > > pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff] > > iosapic: hpa not registered for 0000:01:04.0 > > iosapic: hpa not registered for 0000:01:05.0 > > Elroy version TR4.0 (0x5) found at 0xfed38000 > > Elroy version TR4.0 (0x5) found at 0xfed3c000 > > iosapic: hpa not registered for 0000:03:02.0 > > powersw: Soft power switch at 0xf0400804 enabled. > > > > > > Maybe it's important, that 2 Elroys are detected before the BAR0 message and 2 afterwards? > > Yes, I think it is. There are two ELMMIO ranges being routed to PCI01 and > PCI03. Need to determine if those are the right PCI busses (ergo Elroy) > for those devices and that the same resources are available in the kernel > that is failing to boot. Just hack lba_pci.c to dump more info about > the address routing while it's booting. > > > > > > and here is /proc/iomem: > > root@c3000:~# cat /proc/iomem > > 00000000-7fffffff : System RAM > > 00000000-000009ff : PDC data (Page Zero) > > 00100000-00602fff : Kernel code > > 00603000-0073bfff : Kernel data > > f05d0000-f05d0000 : lcd_data > > f05d0008-f05d0008 : lcd_cmd > > f2000000-f23fffff : PCI00 LMMIO > > f2000000-f2001fff : 0000:00:0f.1 > > f2000000-f2001fff : sym53c8xx > > f2002000-f2003fff : 0000:00:0f.0 > > f2002000-f2003fff : sym53c8xx > > f2004000-f20043ff : 0000:00:0f.1 > > f2004000-f20043ff : sym53c8xx > > f2005000-f20053ff : 0000:00:0f.0 > > f2005000-f20053ff : sym53c8xx > > f2006000-f2006fff : 0000:00:0e.2 > > f2007000-f2007fff : 0000:00:0e.2 > > f2007000-f2007fff : ohci_hcd > > f2008000-f20083ff : 0000:00:0c.0 > > f2008000-f20083ff : tulip > > f2009000-f200900f : 0000:00:0d.0 > > f200a000-f200a00f : 0000:00:0d.0 > > f200b000-f200b00f : 0000:00:0d.0 > > f200c000-f200c1ff : 0000:00:0d.0 > > f2040000-f207ffff : 0000:00:0c.0 > > f2400000-f27fffff : PCI01 LMMIO > > f2400000-f240ffff : 0000:01:04.0 > > f3000000-f33fffff : PCI02 LMMIO > > f3000000-f3003fff : 0000:02:01.0 > > f3004000-f300407f : 0000:02:03.0 > > f3004000-f300407f : tulip > > f3040000-f307ffff : 0000:02:03.0 > > f3800000-f3bfffff : PCI03 LMMIO > > f3800000-f39fffff : 0000:03:02.0 > > f6000000-f7ffffff : PCI03 ELMMIO > > f6000000-f7ffffff : 0000:03:02.0 > > f9000000-f9ffffff : PCI01 ELMMIO > > f9000000-f9ffffff : 0000:01:05.0 > > I suspect how these are parented has changed. > IIRC, Astro already "owns" this resource - but they aren't PCI devices. > I don't recall offhand how the resource is (if at all) advertised and > which Elroy's can even claim specific MMIO ranges. > > If the "fb at f6000000 (32 MB)" is coming from the PCI03 Elroy, then > you can be sure the MMIO resource is not being advertised correctly. > But the output below suggests its from PCI bus 1 (== PCI01 ? need to check). > > hth, > grant > > > fed00000-fed00fff : 10 > > fed30000-fed30fff : 10:0 > > fed32000-fed32fff : 10:1 > > fed38000-fed38fff : 10:4 > > fed3c000-fed3cfff : 10:6 > > fef00000-feffffff : Astro Intr Ack > > fff80000-fffaffff : Central Bus > > fffa0000-fffa0fff : 32 > > fffb0000-fffdffff : Local Broadcast > > fffe0000-ffffffff : Global Broadcast > > > > > > > >>> ... > >>> STI GSC/PCI core graphics driver Version 0.9a > >>> sti 0000:01:04.0: device not available because of BAR 0 [0xfa000000-0xfbffffff] collisions > >>> sti 0000:01:04.0: Cannot enable PCI device > >>> ^^^ HERE > >>> sti: probe of 0000:01:04.0 failed with error -22 > >>> STI PCI graphic ROM found at f3800000 (2048 kB), fb at f6000000 (32 MB) > >>> id 35acda30-9a02587, conforms to spec rev. 8.0d > >>> graphics card name: A1262A > >>> sticon: Initializing STI text console. > >>> Console: switching to colour STI console 128x48 > >>> stifb: 'A1262A' (id: 0x35acda30) not supported. > >>> Linux agpgart interface v0.103 > >>> .... > >>> > >>> Hopefully someone of you has an idea what caused this change? > >> > >> The automatic resource parenting code has changed a few times back > >> and forth over the last 2-3 major releases. I've lost track > >> but suspect it's probably easier to just look at what the > >> LBA range registers say (set up by PDC) and then get the PCI subsystem > >> to advertise those resources in a reasonable way. > > > > How can I see/check the LBA range registers? > > Where is the advertising done? > > Sorry, but I have no clue about PCI/LBA/Elroy/... ? > > > >> TBH, I'd rather spent a few hours this weekend debugging the PCI-PCI bridge > >> support on PAT machines. > > > > Understood. > > Any hints or untested patches would be great though... > > > >> hth, > >> grant > > > > Thanks, > > Helge > > > > > >> > >>> > >>> lspci reports: > >>> 01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) > >>> Flags: 66MHz, medium devsel > >>> Memory at fa000000 (32-bit, non-prefetchable) [size=32M] > >>> Expansion ROM at f2400000 [disabled] [size=64K] ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pci 0000:01:04.0: BAR 0: no parent found for of device 2009-11-06 23:55 ` Grant Grundler @ 2009-11-10 21:55 ` Helge Deller 0 siblings, 0 replies; 4+ messages in thread From: Helge Deller @ 2009-11-10 21:55 UTC (permalink / raw) To: Grant Grundler; +Cc: linux-parisc On 11/07/2009 12:55 AM, Grant Grundler wrote: > On Fri, Nov 06, 2009 at 04:54:05PM -0700, Grant Grundler wrote: >> On Fri, Nov 06, 2009 at 09:37:31PM +0100, Helge Deller wrote: >>>> IIRC, the graphics frame buffers are routed by every Elroy ELMMIO register >>>> on all 4 Elroys. If you can get the machine to NOT HPMC, >>>> ELMMIO resources should be listed in /proc/iomem for workstations. >>> >>> Ok, the good thing is, that it doesn't HPMCs. >>> But sadly I have no clue about what you write above :-( >> >> Heh...Here is a short and probably inadequate explanation. >> >> Elroy has 3 MMIO range registers that determine which physical >> addresses will get routed down to the PCI bus: >> LMMIO 32-bit MMIO address range >> ELMMIO "Extra" 32-bit MMIO address range >> GMMIO 64-bit MMIO address range >> >> The Astro that is upstream (via ropes) is also programmed to route >> specific addresses to specific Elroy devices. Including the ELMMIO >> and GMMIO ranges. >> >> The upstream routing is essentially the negative decoding of the >> downstream routing. So if f9000000-f9ffffff is routed down to >> elroy with PCI01, then any addresses generated by the PCI devices >> OUTSIDE of that range will get routed upstream since Elroy >> is designed to believe there is no device on that bus that will >> respond to addresses outside that range. >> >> It might be easiest to think of each MMIO transaction (read or write) >> as a network packet traversing a fabric and the MMIO address is >> the equivalent to an IP address. Each component in the path has >> a "routing table" (one or more MMIO range registers) to decide >> what to do with the packet. >> >>> >>> Syslog says: >>> SBA found Astro 2.1 at 0xfed00000 >>> Elroy version TR4.0 (0x5) found at 0xfed30000 >>> PCI: Enabled native mode for NS87415 (pif=0x8f) >>> Elroy version TR4.0 (0x5) found at 0xfed32000 >>> pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff] >>> iosapic: hpa not registered for 0000:01:04.0 >>> iosapic: hpa not registered for 0000:01:05.0 >>> Elroy version TR4.0 (0x5) found at 0xfed38000 >>> Elroy version TR4.0 (0x5) found at 0xfed3c000 >>> iosapic: hpa not registered for 0000:03:02.0 >>> powersw: Soft power switch at 0xf0400804 enabled. >>> >>> >>> Maybe it's important, that 2 Elroys are detected before the BAR0 message and 2 afterwards? >> >> Yes, I think it is. There are two ELMMIO ranges being routed to PCI01 and >> PCI03. Need to determine if those are the right PCI busses (ergo Elroy) >> for those devices and that the same resources are available in the kernel >> that is failing to boot. Just hack lba_pci.c to dump more info about >> the address routing while it's booting. I added the patch from Matthew from http://lkml.org/lkml/2009/8/2/106. Here is the log. Does this helps? Elroy version TR4.0 (0x5) found at 0xfed30000 PCI: Enabled native mode for NS87415 (pif=0x8f) Inserting resource 0000:00:0c.0 [0x1000-0x107f] (BAR 0) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0c.0 [0xf2008000-0xf20083ff] (BAR 1) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0c.0 [0xf2040000-0xf207ffff] (BAR 6) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0d.0 [0xf200c000-0xf200c1ff] (BAR 0) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0d.0 [0xf200b000-0xf200b00f] (BAR 1) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0d.0 [0xf200a000-0xf200a00f] (BAR 2) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0d.0 [0xf2009000-0xf200900f] (BAR 3) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0e.0 [0xf00-0xf07] (BAR 0) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0e.0 [0xe00-0xe03] (BAR 1) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0e.0 [0xd00-0xd07] (BAR 2) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0e.0 [0xb00-0xb03] (BAR 3) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0e.0 [0xa00-0xa0f] (BAR 4) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0e.2 [0xf2007000-0xf2007fff] (BAR 0) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0e.2 [0xf2006000-0xf2006fff] (BAR 1) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0f.0 [0x900-0x9ff] (BAR 0) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0f.0 [0xf2005000-0xf20053ff] (BAR 1) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0f.0 [0xf2002000-0xf2003fff] (BAR 3) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0f.1 [0x800-0x8ff] (BAR 0) inside resource PCI00 Ports [0x00-0x1fff] Inserting resource 0000:00:0f.1 [0xf2004000-0xf20043ff] (BAR 1) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Inserting resource 0000:00:0f.1 [0xf2000000-0xf2001fff] (BAR 3) inside resource PCI00 LMMIO [0xf2000000-0xf23fffff] Elroy version TR4.0 (0x5) found at 0xfed32000 No parent found for resource 0000:01:04.0 [0xfa000000-0xfbffffff] pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff] Inserting resource 0000:01:04.0 [0xf2400000-0xf240ffff] (BAR 6) inside resource PCI01 LMMIO [0xf2400000-0xf27fffff] iosapic: hpa not registered for 0000:01:04.0 Inserting resource 0000:01:05.0 [0xf9000000-0xf9ffffff] (BAR 0) inside resource PCI01 ELMMIO [0xf9000000-0xf9ffffff] iosapic: hpa not registered for 0000:01:05.0 Elroy version TR4.0 (0x5) found at 0xfed38000 Inserting resource 0000:02:01.0 [0xf3000000-0xf3003fff] (BAR 0) inside resource PCI02 LMMIO [0xf3000000-0xf33fffff] Inserting resource 0000:02:03.0 [0x28000-0x2807f] (BAR 0) inside resource PCI02 Ports [0x28000-0x29fff] Inserting resource 0000:02:03.0 [0xf3004000-0xf300407f] (BAR 1) inside resource PCI02 LMMIO [0xf3000000-0xf33fffff] Inserting resource 0000:02:03.0 [0xf3040000-0xf307ffff] (BAR 6) inside resource PCI02 LMMIO [0xf3000000-0xf33fffff] Elroy version TR4.0 (0x5) found at 0xfed3c000 Inserting resource 0000:03:02.0 [0xf6000000-0xf7ffffff] (BAR 0) inside resource PCI03 ELMMIO [0xf6000000-0xf7ffffff] Inserting resource 0000:03:02.0 [0xf3800000-0xf39fffff] (BAR 6) inside resource PCI03 LMMIO [0xf3800000-0xf3bfffff] iosapic: hpa not registered for 0000:03:02.0 >>> and here is /proc/iomem: >>> root@c3000:~# cat /proc/iomem >>> 00000000-7fffffff : System RAM >>> 00000000-000009ff : PDC data (Page Zero) >>> 00100000-00602fff : Kernel code >>> 00603000-0073bfff : Kernel data >>> f05d0000-f05d0000 : lcd_data >>> f05d0008-f05d0008 : lcd_cmd >>> f2000000-f23fffff : PCI00 LMMIO >>> f2000000-f2001fff : 0000:00:0f.1 >>> f2000000-f2001fff : sym53c8xx >>> f2002000-f2003fff : 0000:00:0f.0 >>> f2002000-f2003fff : sym53c8xx >>> f2004000-f20043ff : 0000:00:0f.1 >>> f2004000-f20043ff : sym53c8xx >>> f2005000-f20053ff : 0000:00:0f.0 >>> f2005000-f20053ff : sym53c8xx >>> f2006000-f2006fff : 0000:00:0e.2 >>> f2007000-f2007fff : 0000:00:0e.2 >>> f2007000-f2007fff : ohci_hcd >>> f2008000-f20083ff : 0000:00:0c.0 >>> f2008000-f20083ff : tulip >>> f2009000-f200900f : 0000:00:0d.0 >>> f200a000-f200a00f : 0000:00:0d.0 >>> f200b000-f200b00f : 0000:00:0d.0 >>> f200c000-f200c1ff : 0000:00:0d.0 >>> f2040000-f207ffff : 0000:00:0c.0 >>> f2400000-f27fffff : PCI01 LMMIO >>> f2400000-f240ffff : 0000:01:04.0 >>> f3000000-f33fffff : PCI02 LMMIO >>> f3000000-f3003fff : 0000:02:01.0 >>> f3004000-f300407f : 0000:02:03.0 >>> f3004000-f300407f : tulip >>> f3040000-f307ffff : 0000:02:03.0 >>> f3800000-f3bfffff : PCI03 LMMIO >>> f3800000-f39fffff : 0000:03:02.0 >>> f6000000-f7ffffff : PCI03 ELMMIO >>> f6000000-f7ffffff : 0000:03:02.0 >>> f9000000-f9ffffff : PCI01 ELMMIO >>> f9000000-f9ffffff : 0000:01:05.0 >> >> I suspect how these are parented has changed. >> IIRC, Astro already "owns" this resource - but they aren't PCI devices. >> I don't recall offhand how the resource is (if at all) advertised and >> which Elroy's can even claim specific MMIO ranges. >> >> If the "fb at f6000000 (32 MB)" is coming from the PCI03 Elroy, then >> you can be sure the MMIO resource is not being advertised correctly. >> But the output below suggests its from PCI bus 1 (== PCI01 ? need to check). >> >> hth, >> grant >> >>> fed00000-fed00fff : 10 >>> fed30000-fed30fff : 10:0 >>> fed32000-fed32fff : 10:1 >>> fed38000-fed38fff : 10:4 >>> fed3c000-fed3cfff : 10:6 >>> fef00000-feffffff : Astro Intr Ack >>> fff80000-fffaffff : Central Bus >>> fffa0000-fffa0fff : 32 >>> fffb0000-fffdffff : Local Broadcast >>> fffe0000-ffffffff : Global Broadcast >>> >>> >>> >>>>> ... >>>>> STI GSC/PCI core graphics driver Version 0.9a >>>>> sti 0000:01:04.0: device not available because of BAR 0 [0xfa000000-0xfbffffff] collisions >>>>> sti 0000:01:04.0: Cannot enable PCI device >>>>> ^^^ HERE >>>>> sti: probe of 0000:01:04.0 failed with error -22 >>>>> STI PCI graphic ROM found at f3800000 (2048 kB), fb at f6000000 (32 MB) >>>>> id 35acda30-9a02587, conforms to spec rev. 8.0d >>>>> graphics card name: A1262A >>>>> sticon: Initializing STI text console. >>>>> Console: switching to colour STI console 128x48 >>>>> stifb: 'A1262A' (id: 0x35acda30) not supported. >>>>> Linux agpgart interface v0.103 >>>>> .... >>>>> >>>>> Hopefully someone of you has an idea what caused this change? >>>> >>>> The automatic resource parenting code has changed a few times back >>>> and forth over the last 2-3 major releases. I've lost track >>>> but suspect it's probably easier to just look at what the >>>> LBA range registers say (set up by PDC) and then get the PCI subsystem >>>> to advertise those resources in a reasonable way. >>> >>> How can I see/check the LBA range registers? >>> Where is the advertising done? >>> Sorry, but I have no clue about PCI/LBA/Elroy/... ? >>> >>>> TBH, I'd rather spent a few hours this weekend debugging the PCI-PCI bridge >>>> support on PAT machines. >>> >>> Understood. >>> Any hints or untested patches would be great though... >>> >>>> hth, >>>> grant >>> >>> Thanks, >>> Helge >>> >>> >>>> >>>>> >>>>> lspci reports: >>>>> 01:04.0 Display controller: Hewlett-Packard Company A4977A Visualize EG (rev 03) >>>>> Flags: 66MHz, medium devsel >>>>> Memory at fa000000 (32-bit, non-prefetchable) [size=32M] >>>>> Expansion ROM at f2400000 [disabled] [size=64K] > ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: pci 0000:01:04.0: BAR 0: no parent found for of device 2009-11-03 21:00 pci 0000:01:04.0: BAR 0: no parent found for of device Helge Deller [not found] ` <20091106062234.GC4574@lackof.org> @ 2009-11-10 16:56 ` Domenico Andreoli 1 sibling, 0 replies; 4+ messages in thread From: Domenico Andreoli @ 2009-11-10 16:56 UTC (permalink / raw) To: Helge Deller; +Cc: linux-parisc, Matthew Wilcox, John David Anglin On Tue, Nov 03, 2009 at 10:00:39PM +0100, Helge Deller wrote: > Hi all, hi, > Something broke the stifb graphics driver in 2.6.32-rc5 (Linus' current head). mine was a PCI controller for additional USB ports or maybe the MGA graphic controller, i don't rememer. i will check ;) > Somehow it seems, that the PCI subsystem does not activate this PCI slot: > > Linux version 2.6.32-rc5-32bit (deller@p100) (gcc version 4.4.1 (GCC) ) #157 Tue Nov 3 21:49:24 CET 2009 > ... > Searching for devices... > Found devices: > 1. Astro BC Runway Port at 0xfed00000 [10] { 12, 0x0, 0x582, 0x0000b } > 2. Elroy PCI Bridge at 0xfed30000 [10/0] { 13, 0x0, 0x782, 0x0000a } > 3. Elroy PCI Bridge at 0xfed32000 [10/1] { 13, 0x0, 0x782, 0x0000a } > 4. Elroy PCI Bridge at 0xfed38000 [10/4] { 13, 0x0, 0x782, 0x0000a } > 5. Elroy PCI Bridge at 0xfed3c000 [10/6] { 13, 0x0, 0x782, 0x0000a } > 6. Allegro W2 at 0xfffa0000 [32] { 0, 0x0, 0x5dc, 0x00004 } > 7. Memory at 0xfed10200 [49] { 1, 0x0, 0x09c, 0x00009 } > CPU(s): 1 x PA8700 (PCX-W2) at 750.000000 MHz > Setting cache flush threshold to 780 (1 CPUs online) > SBA found Astro 2.1 at 0xfed00000 > Elroy version TR4.0 (0x5) found at 0xfed30000 > PCI: Enabled native mode for NS87415 (pif=0x8f) > Elroy version TR4.0 (0x5) found at 0xfed32000 > pci 0000:01:04.0: BAR 0: no parent found for of device [0xfa000000-0xfbffffff] > ^^^ HERE i had a couple of these messages and also a couple of BAR collisions on my J5600, recently booted with 2.6.32-rc6. these threads seem related: http://lkml.org/lkml/2009/8/2/82 http://lkml.org/lkml/2009/11/9/356 i will try to learn something new later, when I turn on my hppa box later. cheers, Domenic -----[ Domenico Andreoli, aka cavok --[ http://www.dandreoli.com/gpgkey.asc ---[ 3A0F 2F80 F79C 678A 8936 4FEE 0677 9033 A20E BC50 ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2009-11-10 21:55 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-11-03 21:00 pci 0000:01:04.0: BAR 0: no parent found for of device Helge Deller
[not found] ` <20091106062234.GC4574@lackof.org>
[not found] ` <4AF4890B.4050700@gmx.de>
[not found] ` <20091106235405.GC5262@lackof.org>
2009-11-06 23:55 ` Grant Grundler
2009-11-10 21:55 ` Helge Deller
2009-11-10 16:56 ` Domenico Andreoli
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).