pci issue - wrong detection of pci ressources

pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

Hi,
I tried to use a radeon r200 based graphic card on a sequoia ppc (440epx) board. I wondered about the initialization of radeonfb that failed with
	__ioremap(): phys addr 0x0 is RAM lr c029cf80
	radeonfb (0000:00:0a.0): cannot map MMIO
	radeonfb: probe of 0000:00:0a.0 failed with error -5

I trigger a check in ioremap, because the address it wants to remap is 0x0 which can never work. The reason of that is that the pci ressource of that graphic card is not properly detected.

With some help I found two kernels - one that work and one that has this issue.
Unfortunately they are very different:
   good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
   bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build for arch=powerpc
I tried building the 2.6.25-rc9 with arch=ppc, but that one does not boot so far. Because of that I can't surely tell you if it is only that difference that breaks the pci detection.
We need arch=powerpc for our kvm code anyway, so I hope there is another solution than to switch to arch=ppc ;-)

I just started to debug into that, but I wanted to ask here if there might be some known issues causing that and/or to get some hints where to look at.

The issue is much better visible when I boot with these two kernels and use "lspci -vvv"

Good kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
        Subsystem: PC Partner Limited Unknown device 0250
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (2000ns min)
        Interrupt: pin A routed to IRQ 67
        Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at ff00 [size=256]
        Region 2: Memory at 87ff0000 (32-bit, non-prefetchable) [size=64K]
        Expansion ROM at 80020000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

Bad kernel:
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
        Subsystem: PC Partner Limited Unknown device 0250
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (2000ns min)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at 1000 [size=256]
        Region 2: Memory at <ignored> (32-bit, non-prefetchable)
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-


=> Region 2 is not detected with our kernel, this later break things like radeonfb initialization.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

P.S. I tested both pci slots of my board and both behave the same

Re: pci issue - wrong detection of pci ressources

[Johan Borkhuis]

Hello Christian,

Christian Ehrhardt wrote:
> Hi,
> I tried to use a radeon r200 based graphic card on a sequoia ppc 
> (440epx) board. I wondered about the initialization of radeonfb that 
> failed with
>     __ioremap(): phys addr 0x0 is RAM lr c029cf80
>     radeonfb (0000:00:0a.0): cannot map MMIO
>     radeonfb: probe of 0000:00:0a.0 failed with error -5
>
> I trigger a check in ioremap, because the address it wants to remap is 
> 0x0 which can never work. The reason of that is that the pci ressource 
> of that graphic card is not properly detected.
>
> With some help I found two kernels - one that work and one that has 
> this issue.
> Unfortunately they are very different:
>   good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
>   bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build 
> for arch=powerpc
> I tried building the 2.6.25-rc9 with arch=ppc, but that one does not 
> boot so far. Because of that I can't surely tell you if it is only 
> that difference that breaks the pci detection.
> We need arch=powerpc for our kvm code anyway, so I hope there is 
> another solution than to switch to arch=ppc ;-)

I came across a similar problem, which (ultimately) was caused by a lack 
of memory reserved for PCI. I moved from 2.6.14(ppc) to 2.6.20(powerpc), 
and suddenly some cards stopped working: the BAR registers were not 
initialized, so it was not possible to access the cards.
Have a look at the boot-time messages, especially the early messages, as 
the PCI subsystem is started very early in the boot process. You could 
also try switching on PCI-debugging, and have a look at the debug 
messages, or add some extra debugging info to the pci-initialization code.

Kind regards,
    Johan

Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov]

Christian Ehrhardt wrote:

> I tried to use a radeon r200 based graphic card on a sequoia ppc 
> (440epx) board. I wondered about the initialization of radeonfb that 
> failed with
>     __ioremap(): phys addr 0x0 is RAM lr c029cf80
>     radeonfb (0000:00:0a.0): cannot map MMIO
>     radeonfb: probe of 0000:00:0a.0 failed with error -5

> I trigger a check in ioremap, because the address it wants to remap is 
> 0x0 which can never work. The reason of that is that the pci ressource 
> of that graphic card is not properly detected.

    There might be another reason.  This driver seems to be another subject to 
the 440-specific PCI memory space issue beacuse it uses 'unsigned long' to 
store the PCI memory physical addresses and those are 64-bit in the 440 
arch/powerpc/ kernels.

> With some help I found two kernels - one that work and one that has this 
> issue.
> Unfortunately they are very different:
>   good => 2.6.24.2 from the linux-2.6-denx - built for arch=ppc
>   bad => we have 2.6.25-rc9 (used in our kvm ppc project atm) - build 
> for arch=powerpc
> I tried building the 2.6.25-rc9 with arch=ppc, but that one does not 
> boot so far. Because of that I can't surely tell you if it is only that 
> difference that breaks the pci detection.
> We need arch=powerpc for our kvm code anyway, so I hope there is another 
> solution than to switch to arch=ppc ;-)

    Yes, the driver needs fixing -- at least that.

> I just started to debug into that, but I wanted to ask here if there 
> might be some known issues causing that and/or to get some hints where 
> to look at.

    Now you know of at least one.

> The issue is much better visible when I boot with these two kernels and 
> use "lspci -vvv"

> Good kernel:
> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
> 9200 PRO] (rev 01) (prog-if 00 [VGA])
>        Subsystem: PC Partner Limited Unknown device 0250
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 128 (2000ns min)
>        Interrupt: pin A routed to IRQ 67
>        Region 0: Memory at 88000000 (32-bit, prefetchable) [size=128M]
>        Region 1: I/O ports at ff00 [size=256]
>        Region 2: Memory at 87ff0000 (32-bit, non-prefetchable) [size=64K]
>        Expansion ROM at 80020000 [disabled] [size=128K]

    Here, the PCI resources have been re-assigned by arch/ppc/ kernel, and are 
confined to 4 GB due to fixup_bigphys_addr() trick used for 440...

>        Capabilities: [50] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

> Bad kernel:
> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
> 9200 PRO] (rev 01) (prog-if 00 [VGA])
>        Subsystem: PC Partner Limited Unknown device 0250
>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
> ParErr- Stepping- SERR- FastB2B-
>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
> <TAbort- <MAbort- >SERR- <PERR-
>        Latency: 128 (2000ns min)
>        Interrupt: pin A routed to IRQ 16
>        Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]

    That's beyond 4 GB, seems correct. That should be the address assigned by 
bootloader? BTW, what's your bootloader, U-Boot?

>        Region 1: I/O ports at 1000 [size=256]
>        Region 2: Memory at <ignored> (32-bit, non-prefetchable)

    Hm... what could this mean? Could you post the result of 'lspci -x'?

>        Capabilities: [50] Power Management version 2
>                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

> => Region 2 is not detected with our kernel, this later break things 
> like radeonfb initialization.

    Well, not only this...

WBR, Sergei

Re: pci issue - wrong detection of pci ressources

[Benjamin Herrenschmidt]

On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote:
> => Region 2 is not detected with our kernel, this later break things
> like radeonfb initialization.

I'll need some information here:

- Your device-tree (is that the base sequoia one ?)
- Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c
- Send me the resulting dmesg log
- Also include the output of /proc/iomem

Thanks !

Cheers,
Ben.

Re: pci issue - wrong detection of pci ressources

[Benjamin Herrenschmidt]

On Sat, 2008-04-19 at 10:48 +1000, Benjamin Herrenschmidt wrote:
> On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote:
> > => Region 2 is not detected with our kernel, this later break things
> > like radeonfb initialization.
> 
> I'll need some information here:
> 
> - Your device-tree (is that the base sequoia one ?)
> - Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c
> - Send me the resulting dmesg log
> - Also include the output of /proc/iomem

Actually, there's a bug in radeonfb:

In radeonfb.h, try changing

	unsigned long		mmio_base_phys;
	unsigned long		fb_base_phys;

To

	resource_size_t		mmio_base_phys;
	resource_size_t		fb_base_phys;

And tell us if it makes a difference too.

Cheers,
Ben.

Re: pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 6882 bytes --]

Johan Borkhuis wrote:
> Hello Christian,
> 
> Christian Ehrhardt wrote:
>> Hi,
>> I tried to use a radeon r200 based graphic card on a sequoia ppc 
>> (440epx) board. I wondered about the initialization of radeonfb that 
>> failed with
>>     __ioremap(): phys addr 0x0 is RAM lr c029cf80
>>     radeonfb (0000:00:0a.0): cannot map MMIO
>>     radeonfb: probe of 0000:00:0a.0 failed with error -5
>>
[...]
> 
> I came across a similar problem, which (ultimately) was caused by a lack 
> of memory reserved for PCI. I moved from 2.6.14(ppc) to 2.6.20(powerpc), 
> and suddenly some cards stopped working: the BAR registers were not 
> initialized, so it was not possible to access the cards.
> Have a look at the boot-time messages, especially the early messages, as 
> the PCI subsystem is started very early in the boot process. You could 
> also try switching on PCI-debugging, and have a look at the debug 
> messages, or add some extra debugging info to the pci-initialization code.

Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?

With DEBUG in pci-common.c enabled (bad kernel) and a extension showing which functions alloc fails (put a %s for __func__):
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization


########


To be complete for the case we might need it I answer all the other questions:

Benjamin Herrenschmidt wrote:
> On Fri, 2008-04-18 at 14:07 +0200, Christian Ehrhardt wrote:
>> => Region 2 is not detected with our kernel, this later break things
>> like radeonfb initialization.
> 
> I'll need some information here:
> 
> - Your device-tree (is that the base sequoia one ?)

DTS File is the normal sequoia.dts file in arch/powerpc/boot/dts with the latest change being:
user:        Stefan Roese <sr@denx.de>
date:        Fri Feb 15 21:35:30 2008 -0600
summary:     [POWERPC] 4xx: Remove "i2c" and "xxmii-interface" device_types from dts

> - Enable DEBUG in arch/powerpc/kernel/pci-common.c and pci_32.c
> - Send me the resulting dmesg log

done - full dmesg attached

> - Also include the output of /proc/iomem

/proc/iomem - bad kernel
root@sequoia:~# cat /proc/iomem
e0000300-e000038f : ehci_hcd
180000000-18fffffff : /plb/pci@1ec000000
  180000000-187ffffff : 0000:00:0a.0
  188000000-18fffffff : 0000:00:0a.1
1ef600300-1ef600307 : serial
1ef600400-1ef600407 : serial
1ef600500-1ef600507 : serial
1ef600600-1ef600607 : serial
1fc000000-1ffffffff : 1fc000000.nor_flash

/proc/iomem - good kernel
root@sequoia:~# cat /proc/iomem
80000000-8fffffff : PCI host bridge
  80000000-8000ffff : 0000:00:0a.1
  80020000-8003ffff : 0000:00:0a.0
  87ff0000-87ffffff : 0000:00:0a.0
    87ff0000-87ffffff : radeonfb mmio
  88000000-8fffffff : 0000:00:0a.0
    88000000-8fffffff : radeonfb framebuffer
d0000000-d0001fff : ndfc-nand.0
e0000100-e000017f : musbhsfc_udc.0
  e0000100-e000017f : musbhsfc_udc
e0000300-e00003ff : ppc-soc-ehci.0
e0000400-e00004ff : ppc-soc-ohci.0
fc000000-ffffffff : physmap-flash.0
  fc000000-ffffffff : physmap-flash.0
 

> Actually, there's a bug in radeonfb:
> 
> In radeonfb.h, try changing
> 
> 	unsigned long		mmio_base_phys;
> 	unsigned long		fb_base_phys;
> 
> To
> 
> 	resource_size_t		mmio_base_phys;
> 	resource_size_t		fb_base_phys;

This did not fix the issue, as we have seen that it is caused earlier in pci initialization.
But that fix corrects the code if it is useful in my case or not ;-)

########

Sergei Shtylyov wrote:
> Christian Ehrhardt wrote:
> 
[...]
>> Bad kernel:
>> 00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 
>> 9200 PRO] (rev 01) (prog-if 00 [VGA])
>>        Subsystem: PC Partner Limited Unknown device 0250
>>        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- 
>> ParErr- Stepping- SERR- FastB2B-
>>        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium 
>> >TAbort- <TAbort- <MAbort- >SERR- <PERR-
>>        Latency: 128 (2000ns min)
>>        Interrupt: pin A routed to IRQ 16
>>        Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
> 
>    That's beyond 4 GB, seems correct. That should be the address 
> assigned by bootloader? BTW, what's your bootloader, U-Boot?

Yes a modified u-boot

> 
>>        Region 1: I/O ports at 1000 [size=256]
>>        Region 2: Memory at <ignored> (32-bit, non-prefetchable)
> 
>    Hm... what could this mean? Could you post the result of 'lspci -x'?

lspci -xvvv (bad kernel)
00:0a.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 PRO] (rev 01) (prog-if 00 [VGA])
        Subsystem: PC Partner Limited Unknown device 0250
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 128 (2000ns min)
        Interrupt: pin A routed to IRQ 16
        Region 0: Memory at 180000000 (32-bit, prefetchable) [size=128M]
        Region 1: I/O ports at 1000 [size=256]
        Region 2: Memory at <ignored> (32-bit, non-prefetchable)
        Capabilities: [50] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-
00: 02 10 60 59 07 00 90 02 01 00 00 03 00 80 80 00
10: 08 00 00 80 01 10 00 00 00 00 00 88 00 00 00 00
20: 00 00 00 00 00 00 00 00 00 00 00 00 4b 17 50 02
30: 00 00 00 00 50 00 00 00 00 00 00 00 43 01 08 00


[-- Attachment #2: pci_resource_alocation_fails.dmesg.txt --]
[-- Type: text/plain, Size: 10968 bytes --]

Using Sequoia machine description
Linux version 2.6.25-rc9-dirty (paelzer@HeliosPrime.boeblingen.de.ibm.com) (gcc version 4.0.0 (DENX ELDK 4.1 4.0.0)) #7 Sun Apr 20 21:14:50 CEST 2008
Found legacy serial port 0 for /plb/opb/serial@ef600300
  mem=1ef600300, taddr=1ef600300, irq=0, clk=11059200, speed=115200
Found legacy serial port 1 for /plb/opb/serial@ef600400
  mem=1ef600400, taddr=1ef600400, irq=0, clk=11059200, speed=0
Found legacy serial port 2 for /plb/opb/serial@ef600500
  mem=1ef600500, taddr=1ef600500, irq=0, clk=4385964, speed=0
Found legacy serial port 3 for /plb/opb/serial@ef600600
  mem=1ef600600, taddr=1ef600600, irq=0, clk=4385964, speed=0
console [udbg0] enabled
Entering add_active_range(0, 0, 65536) 0 entries of 256 used
Top of RAM: 0x10000000, Total RAM: 0x10000000
Memory hole size: 0MB
Zone PFN ranges:
  DMA             0 ->    65536
  Normal      65536 ->    65536
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0:        0 ->    65536
On node 0 totalpages: 65536
  DMA zone: 512 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 65024 pages, LIFO batch:15
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 65024
Kernel command line: console=ttyS0,115200 ip=dhcp nfsroot=192.168.1.2:/home/paelzer/ubuntu_ppc root=/dev/nfs rw
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
PID hash table entries: 1024 (order: 10, 4096 bytes)
time_init: decrementer frequency = 666.666660 MHz
time_init: processor frequency   = 666.666660 MHz
clocksource: timebase mult[600000] shift[22] registered
clockevent: decrementer mult[aaaa] shift[16] cpu[0]
Console: colour dummy device 80x25
Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
Memory: 255744k/262144k available (3448k kernel code, 6052k reserved, 152k data, 153k bss, 156k init)
Calibrating delay loop... 1331.20 BogoMIPS (lpj=2662400)
Mount-cache hash table entries: 512
net_namespace: 440 bytes
NET: Registered protocol family 16
PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000 
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0363060 (PCI IO)
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0363038 (PCI mem)
PCI: Assigning unassigned resouces...
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
NET: Registered protocol family 2
Switched to high resolution mode on CPU 0
IP route cache hash table entries: 2048 (order: 1, 8192 bytes)
TCP established hash table entries: 8192 (order: 4, 65536 bytes)
TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
TCP: Hash tables configured (established 8192 bind 8192)
TCP reno registered
JFFS2 version 2.2. (NAND) © 2001-2006 Red Hat, Inc.
io scheduler noop registered
io scheduler anticipatory registered (default)
io scheduler deadline registered
io scheduler cfq registered
radeonfb_pci_register BEGIN
radeonfb_pci_register - resource0 0x1 - 0x80000000
radeonfb_pci_register - resource1 0x0 - 0x1000
radeonfb_pci_register - resource2 0x0 - 0x0
radeonfb_pci_register - got pci ressources fb_base_phys 0x1 mmio_base_phys 0x80000000
radeonfb_pci_register - call ioremap for base 0 and size 0
__ioremap(): phys addr 0x0 is RAM lr c029cf88 - mem_init_done 1 highmem@10000000
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5
Linux agpgart interface v0.103
[drm] Initialized drm 1.1.0 20060810
[drm] Initialized radeon 1.28.0 20060524 on minor 0
Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
console handover: boot [udbg0] -> real [ttyS0]
serial8250.0: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
serial8250.0: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
serial8250.0: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
1ef600300.serial: ttyS0 at MMIO 0x1ef600300 (irq = 17) is a 16550A
1ef600400.serial: ttyS1 at MMIO 0x1ef600400 (irq = 18) is a 16550A
1ef600500.serial: ttyS2 at MMIO 0x1ef600500 (irq = 19) is a 16550A
1ef600600.serial: ttyS3 at MMIO 0x1ef600600 (irq = 20) is a 16550A
brd: module loaded
PPC 4xx OCP EMAC driver, version 3.54
MAL v2 /plb/mcmal, 2 TX channels, 2 RX channels
ZMII /plb/opb/emac-zmii@ef600d00 initialized
RGMII /plb/opb/emac-rgmii@ef601000 initialized with MDIO support
/plb/opb/emac-rgmii@ef601000: input 0 in RGMII mode
eth0: EMAC-0 /plb/opb/ethernet@ef600e00, MAC 00:10:ec:00:e2:3e
eth0: found Marvell 88E1111 Ethernet PHY (0x00)
/plb/opb/emac-rgmii@ef601000: input 1 in RGMII mode
eth1: EMAC-1 /plb/opb/ethernet@ef600f00, MAC 00:10:ec:80:e2:3e
eth1: found Marvell 88E1111 Ethernet PHY (0x01)
tun: Universal TUN/TAP device driver, 1.6
tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
Driver 'sd' needs updating - please use bus_type methods
1fc000000.nor_flash: Found 1 x16 devices at 0x0 in 16-bit bank
 Amd/Fujitsu Extended Query Table at 0x0040
1fc000000.nor_flash: CFI does not contain boot bank location. Assuming top.
number of CFI chips: 1
cfi_cmdset_0002: Disabling erase-suspend-program due to code brokenness.
RedBoot partition parsing not available
of-flash: probe of 1fc000000.nor_flash failed with error -22
ppc-of-ehci e0000300.ehci: OF EHCI
ppc-of-ehci e0000300.ehci: new USB bus registered, assigned bus number 1
ppc-of-ehci e0000300.ehci: irq 32, io mem 0xe0000300
ppc-of-ehci e0000300.ehci: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 1 port detected
usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OF EHCI
usb usb1: Manufacturer: Linux 2.6.25-rc9-dirty ehci_hcd
usb usb1: SerialNumber: PPC-OF USB
USB Universal Host Controller Interface driver v3.0
Initializing USB Mass Storage driver...
usb 1-1: new high speed USB device using ppc-of-ehci and address 2
usb 1-1: configuration #1 chosen from 1 choice
hub 1-1:1.0: USB hub found
hub 1-1:1.0: 4 ports detected
usb 1-1: New USB device found, idVendor=05e3, idProduct=0608
usb 1-1: New USB device strings: Mfr=0, Product=1, SerialNumber=0
usb 1-1: Product: USB2.0 Hub
usb 1-1.1: new low speed USB device using ppc-of-ehci and address 3
usb 1-1.1: configuration #1 chosen from 1 choice
usb 1-1.1: New USB device found, idVendor=04b3, idProduct=310c
usb 1-1.1: New USB device strings: Mfr=0, Product=2, SerialNumber=0
usb 1-1.1: Product: USB Optical Mouse
usb 1-1.2: new full speed USB device using ppc-of-ehci and address 4
usb 1-1.2: configuration #1 chosen from 1 choice
hub 1-1.2:1.0: USB hub found
hub 1-1.2:1.0: 2 ports detected
usb 1-1.2: New USB device found, idVendor=04b3, idProduct=3022
usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2: Manufacturer: Chicony
usb 1-1.2.1: new full speed USB device using ppc-of-ehci and address 5
usb 1-1.2.1: configuration #1 chosen from 1 choice
usb 1-1.2.1: New USB device found, idVendor=04b3, idProduct=3021
usb 1-1.2.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.1: Product: IBM Preferred Pro USB Fingerprint Keyboard
usb 1-1.2.1: Manufacturer: Chicony
usb 1-1.2.2: new full speed USB device using ppc-of-ehci and address 6
usb 1-1.2.2: configuration #1 chosen from 1 choice
usb 1-1.2.2: New USB device found, idVendor=0483, idProduct=2016
usb 1-1.2.2: New USB device strings: Mfr=1, Product=2, SerialNumber=0
usb 1-1.2.2: Product: Biometric Coprocessor
usb 1-1.2.2: Manufacturer: STMicroelectronics
usbcore: registered new interface driver usb-storage
USB Mass Storage support registered.
usbcore: registered new interface driver libusual
mice: PS/2 mouse device common for all mice
input: USB Optical Mouse as /class/input/input0
input: USB HID v1.11 Mouse [USB Optical Mouse] on usb-PPC-OF USB-1.1
input: Chicony IBM Preferred Pro USB Fingerprint Keyboard as /class/input/input1
input: USB HID v1.10 Keyboard [Chicony IBM Preferred Pro USB Fingerprint Keyboard] on usb-PPC-OF USB-1.2.1
HID device claimed by neither input, hiddev nor hidraw
usbcore: registered new interface driver usbhid
drivers/hid/usbhid/hid-core.c: v2.6:USB HID core driver
oprofile: using timer interrupt.
Netfilter messages via NETLINK v0.30.
ip_tables: (C) 2000-2006 Netfilter Core Team
TCP cubic registered
NET: Registered protocol family 1
NET: Registered protocol family 17
Bridge firewalling registered
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
drivers/rtc/hctosys.c: unable to open rtc device (rtc0)
eth0: link is up, 100 FDX, pause enabled
eth1: link is up, 100 FDX, pause enabled
Sending DHCP requests ., OK
IP-Config: Got DHCP answer from 192.168.1.2, my address is 192.168.1.3
IP-Config: Complete:
     device=eth0, addr=192.168.1.3, mask=255.255.255.0, gw=192.168.1.2,
     host=192.168.1.3, domain=local-devnet, nis-domain=(none),
     bootserver=192.168.1.2, rootserver=192.168.1.2, rootpath=
Looking up port of RPC 100003/2 on 192.168.1.2
Looking up port of RPC 100005/1 on 192.168.1.2
VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 156k init
eth1: link is up, 100 FDX, pause enabled
swapon: swapfile has holes
warning: `avahi-daemon' uses 32-bit capabilities (legacy support in use)
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
Machine check in kernel mode.
Data Read PLB Error
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).
lockd_up: makesock failed, error=-5
rpcbind: server localhost not responding, timed out
RPC: failed to contact local rpcbind server (errno 5).

Re: pci issue - wrong detection of pci ressources

[Benjamin Herrenschmidt]

> Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
> And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
> Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?

Hrm... I was expecting to see a lot more output here, make sure you have
"debug" on your command line (or enable early debug output, same
effect).

Cheers,
Ben.

Re: pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

Benjamin Herrenschmidt wrote:
>> Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
>> And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
>> Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
> 
> Hrm... I was expecting to see a lot more output here, make sure you have
> "debug" on your command line (or enable early debug output, same
> effect).

There is nothing more even with debug in kernel command line.
But I added some printk's around the resource handling to get a better feeling what's happening.
I attached the new extended bootlog and the patch with the printk's for a better understanding where which message is printed.

I tried to understand how I might e.g. increase the number of available resources or their size, but unfortunately that is not the simplest code when working with it the first time ;-)

> Cheers,
> Ben.
> 
> 

For comparison I defined DEBUG in the good kernel (arch=ppc) and that is what the initialization prints (pci ...:0a:1 is the secondary head of the same graphic card an it's not an issue if thats not allocated):
good case:
PCI: Probing PCI hardware
PCI: bridge rsrc 0..ffff (100), parent c0354624
PCI: bridge rsrc 80000000..8fffffff (200), parent c0354608
PCI:0000:00:0a.0: Resource 0: 0000000088000000-000000008fffffff (f=1208)
PCI:0000:00:0a.0: Resource 1: 000000000000ff00-000000000000ffff (f=101)
PCI:0000:00:0a.0: Resource 2: 0000000087ff0000-0000000087ffffff (f=200)
PCI:0000:00:0a.1: Resource 0: 0000000078000000-000000007fffffff (f=1208)
PCI: Cannot allocate resource region 0 of device 0000:00:0a.1
PCI:0000:00:0a.1: Resource 1: 0000000077ff0000-0000000077ffffff (f=200)
PCI: Cannot allocate resource region 1 of device 0000:00:0a.1
PCI: Failed to allocate mem resource #0:8000000@90000000 for 0000:00:0a.1

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

[-- Attachment #2: pci_resource_issue_bootmsg_badkernel.txt --]
[-- Type: text/plain, Size: 4899 bytes --]

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0365060 (PCI IO)
__request_resource - request cf8045b0 name '/plb/pci@1ec000000' start 0x0 end 0x0
__request_resource - no conflict parent c0365060 sibling 00000000
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0365038 (PCI mem)
__request_resource - request cf8045d8 name '/plb/pci@1ec000000' start 0x1 end 0x80000000
__request_resource - no conflict parent c0365038 sibling 00000000
PCI: Assigning unassigned resouces...
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1
find_resource - size 0, min 0x8000000, max 0x1
find_resource - found start 0x1 end 0x80000000
__request_resource - request cf810578 name '0000:00:0a.0' start 0x1 end 0x80000000
__request_resource - no conflict parent cf8045d8 sibling 00000000
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1
find_resource - size 0, min 0x8000000, max 0x1
find_resource - continue with start 0x1 on 88000000
find_resource - found start 0x1 end 0x88000000
__request_resource - request cf810178 name '0000:00:0a.1' start 0x1 end 0x88000000
__request_resource - no conflict parent cf8045d8 sibling 00000000
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 131072, align -1
find_resource - size 0, min 0x20000, max 0x1
find_resource - continue with start 0x1 on 88000000
find_resource - continue with start 0x1 on 90000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1
find_resource - size 0, min 0x10000, max 0x1
find_resource - continue with start 0x1 on 88000000
find_resource - continue with start 0x1 on 90000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1
find_resource - size 0, min 0x10000, max 0x1
find_resource - continue with start 0x1 on 88000000
find_resource - continue with start 0x1 on 90000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0 startcalc 256, align -1
find_resource - size 0, min 0x100, max 0x0
find_resource - found start 0x0 end 0x1000
__request_resource - request cf8105a0 name '0000:00:0a.0' start 0x0 end 0x1000
__request_resource - no conflict parent cf8045b0 sibling 00000000
SCSI subsystem initialized
[...]
radeonfb_pci_register BEGIN
radeonfb_pci_register - resource0 0x1 - 0x80000000
radeonfb_pci_register - resource1 0x0 - 0x1000
radeonfb_pci_register - resource2 0x0 - 0x0
radeonfb_pci_register - got pci ressources fb_base_phys 0x1 mmio_base_phys 0x80000000
__request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
__request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
__request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
__request_resource - no conflict parent cf810578 sibling 00000000
radeonfb_pci_register - call ioremap for base 0 and size 0
__ioremap(): phys addr 0x0 is RAM lr c029df88 - mem_init_done 1 highmem@10000000
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5

[-- Attachment #3: debug_pci_radeonfb.diff --]
[-- Type: text/x-patch, Size: 7931 bytes --]

Subject: [PATCH] : ! debug only ! - printk's in pci ressource handling

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This defines debug for pci and put's some printk's to keep track of the pci
ressource handling. This patch is just for reference to understand the
resulting boot message log.
The patch is ugly - but for debugging only ;-)

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kernel/pci-common.c |    2 ++
 arch/powerpc/mm/pgtable_32.c     |    4 ++--
 drivers/pci/bus.c                |    3 +++
 drivers/pci/setup-res.c          |   12 ++++++++----
 drivers/video/aty/radeon_base.c  |    7 +++++++
 drivers/video/aty/radeonfb.h     |    4 ++--
 kernel/resource.c                |   17 ++++++++++++++++-
 7 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -37,6 +37,8 @@
 #include <asm/machdep.h>
 #include <asm/ppc-pci.h>
 #include <asm/firmware.h>
+
+#define DEBUG
 
 #ifdef DEBUG
 #include <asm/udbg.h>
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -183,8 +183,8 @@ __ioremap(phys_addr_t addr, unsigned lon
 	 * mem_init() sets high_memory so only do the check after that.
 	 */
 	if (mem_init_done && (p < virt_to_phys(high_memory))) {
-		printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
-		       (unsigned long long)p, __builtin_return_address(0));
+		printk("__ioremap(): phys addr 0x%llx is RAM lr %p - mem_init_done %d highmem@%p\n",
+		       (unsigned long long)p, __builtin_return_address(0), mem_init_done, virt_to_phys(high_memory));
 		return NULL;
 	}
 
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -42,6 +42,8 @@ pci_bus_alloc_resource(struct pci_bus *b
 {
 	int i, ret = -ENOMEM;
 
+printk(KERN_ERR"%s - enter\n", __func__);
+
 	type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
 
 	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
@@ -59,6 +61,7 @@ pci_bus_alloc_resource(struct pci_bus *b
 		    !(res->flags & IORESOURCE_PREFETCH))
 			continue;
 
+printk(KERN_ERR"%s - call allocate ressource size %d startcalc %d, align %d\n", __func__, size, (r->start ? : min,-1), align);
 		/* Ok, try it out.. */
 		ret = allocate_resource(r, res, size,
 					r->start ? : min,
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -142,10 +142,13 @@ int pci_assign_resource(struct pci_dev *
 	   required alignment in the "start" field. */
 	align = (resno < PCI_BRIDGE_RESOURCES) ? size : res->start;
 
+printk(KERN_ERR"%s - allocate with IORESOURCE_PREFETCH\n", __func__);
+
 	/* First, try exact prefetching match.. */
 	ret = pci_bus_alloc_resource(bus, res, size, align, min,
 				     IORESOURCE_PREFETCH,
 				     pcibios_align_resource, dev);
+
 
 	if (ret < 0 && (res->flags & IORESOURCE_PREFETCH)) {
 		/*
@@ -154,13 +157,14 @@ int pci_assign_resource(struct pci_dev *
 		 * But a prefetching area can handle a non-prefetching
 		 * window (it will just not perform as well).
 		 */
+printk(KERN_ERR"%s - second pci_bus_alloc_resource call\n", __func__);
 		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
 					     pcibios_align_resource, dev);
 	}
 
 	if (ret) {
-		printk(KERN_ERR "PCI: Failed to allocate %s resource "
-			"#%d:%llx@%llx for %s\n",
+		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
+			"#%d:%llx@%llx for %s\n", __func__,
 			res->flags & IORESOURCE_IO ? "I/O" : "mem",
 			resno, (unsigned long long)size,
 			(unsigned long long)res->start, pci_name(dev));
@@ -197,8 +201,8 @@ int pci_assign_resource_fixed(struct pci
 	}
 
 	if (ret) {
-		printk(KERN_ERR "PCI: Failed to allocate %s resource "
-				"#%d:%llx@%llx for %s\n",
+		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
+				"#%d:%llx@%llx for %s\n", __func__,
 			res->flags & IORESOURCE_IO ? "I/O" : "mem",
 			resno, (unsigned long long)(res->end - res->start + 1),
 			(unsigned long long)res->start, pci_name(dev));
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -2160,6 +2160,10 @@ static int __devinit radeonfb_pci_regist
 	int ret;
 
 	RTRACE("radeonfb_pci_register BEGIN\n");
+
+printk(KERN_ERR"%s - resource0 0x%0lx - 0x%0lx\n", __func__, pdev->resource[0].start, pdev->resource[0].end);
+printk(KERN_ERR"%s - resource1 0x%0lx - 0x%0lx\n", __func__, pdev->resource[1].start, pdev->resource[1].end);
+printk(KERN_ERR"%s - resource2 0x%0lx - 0x%0lx\n", __func__, pdev->resource[2].start, pdev->resource[2].end);
 	
 	/* Enable device in PCI config */
 	ret = pci_enable_device(pdev);
@@ -2198,6 +2202,8 @@ static int __devinit radeonfb_pci_regist
 	rinfo->fb_base_phys = pci_resource_start (pdev, 0);
 	rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+printk(KERN_ERR"%s - got pci ressources fb_base_phys 0x%0lx mmio_base_phys 0x%0lx\n", __func__,rinfo->fb_base_phys,rinfo->mmio_base_phys);
+
 	/* request the mem regions */
 	ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
 	if (ret < 0) {
@@ -2214,6 +2220,7 @@ static int __devinit radeonfb_pci_regist
 	}
 
 	/* map the regions */
+printk(KERN_ERR "%s - call ioremap for base %ld and size %d\n",__func__, rinfo->mmio_base_phys, RADEON_REGSIZE);
 	rinfo->mmio_base = ioremap(rinfo->mmio_base_phys, RADEON_REGSIZE);
 	if (!rinfo->mmio_base) {
 		printk(KERN_ERR "radeonfb (%s): cannot map MMIO\n",
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -287,8 +287,8 @@ struct radeonfb_info {
 
 	char			name[DEVICE_NAME_SIZE];
 
-	unsigned long		mmio_base_phys;
-	unsigned long		fb_base_phys;
+	resource_size_t		mmio_base_phys;
+	resource_size_t		fb_base_phys;
 
 	void __iomem		*mmio_base;
 	void __iomem		*fb_base;
diff --git a/kernel/resource.c b/kernel/resource.c
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -152,6 +152,9 @@ static struct resource * __request_resou
 	resource_size_t end = new->end;
 	struct resource *tmp, **p;
 
+printk(KERN_ERR"%s - request %p name '%s' start 0x%0lx end 0x%0lx\n",
+			__func__, new, new->name, start, end);
+
 	if (end < start)
 		return root;
 	if (start < root->start)
@@ -165,6 +168,7 @@ static struct resource * __request_resou
 			new->sibling = tmp;
 			*p = new;
 			new->parent = root;
+printk(KERN_ERR"%s - no conflict parent %p sibling %p\n",__func__, new->parent, new->sibling);
 			return NULL;
 		}
 		p = &tmp->sibling;
@@ -305,6 +309,8 @@ static int find_resource(struct resource
 {
 	struct resource *this = root->child;
 
+printk(KERN_ERR"%s - size %lx, min 0x%0lx, max 0x%0lx\n", __func__, size, min, max);
+
 	new->start = root->start;
 	/*
 	 * Skip past an allocated resource that starts at 0, since the assignment
@@ -328,10 +334,16 @@ static int find_resource(struct resource
 			alignf(alignf_data, new, size, align);
 		if (new->start < new->end && new->end - new->start >= size - 1) {
 			new->end = new->start + size - 1;
+printk(KERN_ERR"%s - found start 0x%0lx end 0x%0lx\n", __func__, new->start, new->end);
 			return 0;
 		}
-		if (!this)
+		if (!this) {
+printk(KERN_ERR"%s - no this - exit\n", __func__);
 			break;
+}
+else {
+printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__, (this->end + 1), this->sibling);
+}
 		new->start = this->end + 1;
 		this = this->sibling;
 	}
@@ -385,6 +397,9 @@ int insert_resource(struct resource *par
 {
 	int result;
 	struct resource *first, *next;
+
+printk(KERN_ERR"%s - insert %p (start 0x%0lx end 0x%0lx) under parent %p\n",
+			__func__, new, new->start, new->end, parent);
 
 	write_lock(&resource_lock);
 

Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov]

Hello.

Christian Ehrhardt wrote:

>> Cheers,
>> Ben.

> For comparison I defined DEBUG in the good kernel (arch=ppc) and that is 
> what the initialization prints (pci ...:0a:1 is the secondary head of 
> the same graphic card an it's not an issue if thats not allocated):
> good case:
> PCI: Probing PCI hardware
> PCI: bridge rsrc 0..ffff (100), parent c0354624
> PCI: bridge rsrc 80000000..8fffffff (200), parent c0354608
> PCI:0000:00:0a.0: Resource 0: 0000000088000000-000000008fffffff (f=1208)
> PCI:0000:00:0a.0: Resource 1: 000000000000ff00-000000000000ffff (f=101)
> PCI:0000:00:0a.0: Resource 2: 0000000087ff0000-0000000087ffffff (f=200)
> PCI:0000:00:0a.1: Resource 0: 0000000078000000-000000007fffffff (f=1208)
> PCI: Cannot allocate resource region 0 of device 0000:00:0a.1
> PCI:0000:00:0a.1: Resource 1: 0000000077ff0000-0000000077ffffff (f=200)
> PCI: Cannot allocate resource region 1 of device 0000:00:0a.1
> PCI: Failed to allocate mem resource #0:8000000@90000000 for 0000:00:0a.1

> ------------------------------------------------------------------------

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
>  MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
>   IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
> 4xx PCI DMA offset set to 0x00000000
> PCI: Probing PCI hardware
> PCI: Hiding 4xx host bridge resources 0000:00:00.0
> Try to map irq for 0000:00:00.0...
>  -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
>  -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.0...
>  -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
>  -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.1...
> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0365060 (PCI IO)
> __request_resource - request cf8045b0 name '/plb/pci@1ec000000' start 0x0 end 0x0
> __request_resource - no conflict parent c0365060 sibling 00000000
> PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0365038 (PCI mem)
> __request_resource - request cf8045d8 name '/plb/pci@1ec000000' start 0x1 end 0x80000000

    Bogus start/end value because you're not printing them right...

> __request_resource - no conflict parent c0365038 sibling 00000000
> PCI: Assigning unassigned resouces...
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1
> find_resource - size 0, min 0x8000000, max 0x1
> find_resource - found start 0x1 end 0x80000000
> __request_resource - request cf810578 name '0000:00:0a.0' start 0x1 end 0x80000000

    The start/end values are bogus -- not printed right.

> __request_resource - no conflict parent cf8045d8 sibling 00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 134217728, align -1
> find_resource - size 0, min 0x8000000, max 0x1
> find_resource - continue with start 0x1 on 88000000
> find_resource - found start 0x1 end 0x88000000
> __request_resource - request cf810178 name '0000:00:0a.1' start 0x1 end 0x88000000

    Same here.

> __request_resource - no conflict parent cf8045d8 sibling 00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH

    It's not clear why the register space is prefetchable.

> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 131072, align -1
> find_resource - size 0, min 0x20000, max 0x1
> find_resource - continue with start 0x1 on 88000000
> find_resource - continue with start 0x1 on 90000000
> find_resource - no this - exit

    ... and here. It's not clear why it failed with 188000000... maybe we ran 
out of prefetchable space?

> PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1
> find_resource - size 0, min 0x10000, max 0x1
> find_resource - continue with start 0x1 on 88000000
> find_resource - continue with start 0x1 on 90000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 65536, align -1
> find_resource - size 0, min 0x10000, max 0x1
> find_resource - continue with start 0x1 on 88000000
> find_resource - continue with start 0x1 on 90000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0 startcalc 256, align -1
> find_resource - size 0, min 0x100, max 0x0
> find_resource - found start 0x0 end 0x1000
> __request_resource - request cf8105a0 name '0000:00:0a.0' start 0x0 end 0x1000
> __request_resource - no conflict parent cf8045b0 sibling 00000000
> SCSI subsystem initialized
> [...]
> radeonfb_pci_register BEGIN
> radeonfb_pci_register - resource0 0x1 - 0x80000000
> radeonfb_pci_register - resource1 0x0 - 0x1000
> radeonfb_pci_register - resource2 0x0 - 0x0

    The value here are bugus because you're not printing them right.

> radeonfb_pci_register - got pci ressources fb_base_phys 0x1 mmio_base_phys 0x80000000
> __request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
> __request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
> __request_resource - request cf8bfd20 name 'radeonfb framebuffer' start 0x1 end 0x80000000
> __request_resource - no conflict parent cf810578 sibling 00000000
> radeonfb_pci_register - call ioremap for base 0 and size 0
> __ioremap(): phys addr 0x0 is RAM lr c029df88 - mem_init_done 1 highmem@10000000
> radeonfb (0000:00:0a.0): cannot map MMIO
> radeonfb: probe of 0000:00:0a.0 failed with error -5


> ------------------------------------------------------------------------

> Subject: [PATCH] : ! debug only ! - printk's in pci ressource handling

> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

> This defines debug for pci and put's some printk's to keep track of the pci
> ressource handling. This patch is just for reference to understand the
> resulting boot message log.
> The patch is ugly - but for debugging only ;-)

    Moreover, it's inconsistent because you're not using the right format for 
printing throughout it...

> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
[...]
> diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
> --- a/arch/powerpc/kernel/pci-common.c
> +++ b/arch/powerpc/kernel/pci-common.c
> @@ -37,6 +37,8 @@
>  #include <asm/machdep.h>
>  #include <asm/ppc-pci.h>
>  #include <asm/firmware.h>
> +
> +#define DEBUG
>  
>  #ifdef DEBUG
>  #include <asm/udbg.h>
> diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
> --- a/arch/powerpc/mm/pgtable_32.c
> +++ b/arch/powerpc/mm/pgtable_32.c
> @@ -183,8 +183,8 @@ __ioremap(phys_addr_t addr, unsigned lon
>  	 * mem_init() sets high_memory so only do the check after that.
>  	 */
>  	if (mem_init_done && (p < virt_to_phys(high_memory))) {
> -		printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
> -		       (unsigned long long)p, __builtin_return_address(0));
> +		printk("__ioremap(): phys addr 0x%llx is RAM lr %p - mem_init_done %d highmem@%p\n",
> +		       (unsigned long long)p, __builtin_return_address(0), mem_init_done, virt_to_phys(high_memory));
>  		return NULL;
>  	}
>  
> diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
> --- a/drivers/pci/bus.c
> +++ b/drivers/pci/bus.c
> @@ -42,6 +42,8 @@ pci_bus_alloc_resource(struct pci_bus *b
>  {
>  	int i, ret = -ENOMEM;
>  
> +printk(KERN_ERR"%s - enter\n", __func__);
> +
>  	type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
>  
>  	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
> @@ -59,6 +61,7 @@ pci_bus_alloc_resource(struct pci_bus *b
>  		    !(res->flags & IORESOURCE_PREFETCH))
>  			continue;
>  
> +printk(KERN_ERR"%s - call allocate ressource size %d startcalc %d, align %d\n", __func__, size, (r->start ? : min,-1), align);
>  		/* Ok, try it out.. */
>  		ret = allocate_resource(r, res, size,
>  					r->start ? : min,
> diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
> --- a/drivers/pci/setup-res.c
> +++ b/drivers/pci/setup-res.c
> @@ -142,10 +142,13 @@ int pci_assign_resource(struct pci_dev *
>  	   required alignment in the "start" field. */
>  	align = (resno < PCI_BRIDGE_RESOURCES) ? size : res->start;
>  
> +printk(KERN_ERR"%s - allocate with IORESOURCE_PREFETCH\n", __func__);
> +
>  	/* First, try exact prefetching match.. */
>  	ret = pci_bus_alloc_resource(bus, res, size, align, min,
>  				     IORESOURCE_PREFETCH,
>  				     pcibios_align_resource, dev);
> +
>  
>  	if (ret < 0 && (res->flags & IORESOURCE_PREFETCH)) {
>  		/*
> @@ -154,13 +157,14 @@ int pci_assign_resource(struct pci_dev *
>  		 * But a prefetching area can handle a non-prefetching
>  		 * window (it will just not perform as well).
>  		 */
> +printk(KERN_ERR"%s - second pci_bus_alloc_resource call\n", __func__);
>  		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
>  					     pcibios_align_resource, dev);
>  	}
>  
>  	if (ret) {
> -		printk(KERN_ERR "PCI: Failed to allocate %s resource "
> -			"#%d:%llx@%llx for %s\n",
> +		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
> +			"#%d:%llx@%llx for %s\n", __func__,
>  			res->flags & IORESOURCE_IO ? "I/O" : "mem",
>  			resno, (unsigned long long)size,
>  			(unsigned long long)res->start, pci_name(dev));
> @@ -197,8 +201,8 @@ int pci_assign_resource_fixed(struct pci
>  	}
>  
>  	if (ret) {
> -		printk(KERN_ERR "PCI: Failed to allocate %s resource "
> -				"#%d:%llx@%llx for %s\n",
> +		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
> +				"#%d:%llx@%llx for %s\n", __func__,
>  			res->flags & IORESOURCE_IO ? "I/O" : "mem",
>  			resno, (unsigned long long)(res->end - res->start + 1),
>  			(unsigned long long)res->start, pci_name(dev));
> diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
> --- a/drivers/video/aty/radeon_base.c
> +++ b/drivers/video/aty/radeon_base.c
> @@ -2160,6 +2160,10 @@ static int __devinit radeonfb_pci_regist
>  	int ret;
>  
>  	RTRACE("radeonfb_pci_register BEGIN\n");
> +
> +printk(KERN_ERR"%s - resource0 0x%0lx - 0x%0lx\n", __func__, pdev->resource[0].start, pdev->resource[0].end);
> +printk(KERN_ERR"%s - resource1 0x%0lx - 0x%0lx\n", __func__, pdev->resource[1].start, pdev->resource[1].end);
> +printk(KERN_ERR"%s - resource2 0x%0lx - 0x%0lx\n", __func__, pdev->resource[2].start, pdev->resource[2].end);

    You should have used %llx here -- the resources are 64-bit on 44x.

>  	/* Enable device in PCI config */
>  	ret = pci_enable_device(pdev);
> @@ -2198,6 +2202,8 @@ static int __devinit radeonfb_pci_regist
>  	rinfo->fb_base_phys = pci_resource_start (pdev, 0);
>  	rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
>  
> +printk(KERN_ERR"%s - got pci ressources fb_base_phys 0x%0lx mmio_base_phys 0x%0lx\n", __func__,rinfo->fb_base_phys,rinfo->mmio_base_phys);
> +

    You've changed fb_base_phys and mmio_base_phys to resource_size_t which is 
64-bit, so use %llx to print them.

>  	/* request the mem regions */
>  	ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
>  	if (ret < 0) {
> @@ -2214,6 +2220,7 @@ static int __devinit radeonfb_pci_regist
>  	}
>  
>  	/* map the regions */
> +printk(KERN_ERR "%s - call ioremap for base %ld and size %d\n",__func__, rinfo->mmio_base_phys, RADEON_REGSIZE);

    You've changed mmio_base_phys to resource_size_t which is 64-bit, so use 
%llx to print it.

>  	rinfo->mmio_base = ioremap(rinfo->mmio_base_phys, RADEON_REGSIZE);
>  	if (!rinfo->mmio_base) {
>  		printk(KERN_ERR "radeonfb (%s): cannot map MMIO\n",
> diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
> --- a/drivers/video/aty/radeonfb.h
> +++ b/drivers/video/aty/radeonfb.h
> @@ -287,8 +287,8 @@ struct radeonfb_info {
>  
>  	char			name[DEVICE_NAME_SIZE];
>  
> -	unsigned long		mmio_base_phys;
> -	unsigned long		fb_base_phys;
> +	resource_size_t		mmio_base_phys;
> +	resource_size_t		fb_base_phys;
>  
>  	void __iomem		*mmio_base;
>  	void __iomem		*fb_base;
> diff --git a/kernel/resource.c b/kernel/resource.c
> --- a/kernel/resource.c
> +++ b/kernel/resource.c
> @@ -152,6 +152,9 @@ static struct resource * __request_resou
>  	resource_size_t end = new->end;
>  	struct resource *tmp, **p;
>  
> +printk(KERN_ERR"%s - request %p name '%s' start 0x%0lx end 0x%0lx\n",
> +			__func__, new, new->name, start, end);
> +

    You should have used %llx here too...

>  	if (end < start)
>  		return root;
>  	if (start < root->start)
> @@ -165,6 +168,7 @@ static struct resource * __request_resou
>  			new->sibling = tmp;
>  			*p = new;
>  			new->parent = root;
> +printk(KERN_ERR"%s - no conflict parent %p sibling %p\n",__func__, new->parent, new->sibling);
>  			return NULL;
>  		}
>  		p = &tmp->sibling;
> @@ -305,6 +309,8 @@ static int find_resource(struct resource
>  {
>  	struct resource *this = root->child;
>  
> +printk(KERN_ERR"%s - size %lx, min 0x%0lx, max 0x%0lx\n", __func__, size, min, max);
> +

    Should have used %0llx here as well...

>  	new->start = root->start;
>  	/*
>  	 * Skip past an allocated resource that starts at 0, since the assignment
> @@ -328,10 +334,16 @@ static int find_resource(struct resource
>  			alignf(alignf_data, new, size, align);
>  		if (new->start < new->end && new->end - new->start >= size - 1) {
>  			new->end = new->start + size - 1;
> +printk(KERN_ERR"%s - found start 0x%0lx end 0x%0lx\n", __func__, new->start, new->end);

    And here too...

>  			return 0;
>  		}
> -		if (!this)
> +		if (!this) {
> +printk(KERN_ERR"%s - no this - exit\n", __func__);
>  			break;
> +}
> +else {
> +printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__, (this->end + 1), this->sibling);

    And here. Yet it's not clear why you call resource's 'end' 'start'...

> +}
>  		new->start = this->end + 1;
>  		this = this->sibling;
>  	}
> @@ -385,6 +397,9 @@ int insert_resource(struct resource *par
>  {
>  	int result;
>  	struct resource *first, *next;
> +
> +printk(KERN_ERR"%s - insert %p (start 0x%0lx end 0x%0lx) under parent %p\n",
> +			__func__, new, new->start, new->end, parent);

    Use %llx hereas well...

>  
>  	write_lock(&resource_lock);
>  

WBR, Sergei

Re: pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 1198 bytes --]

Sergei Shtylyov wrote:
> Hello.
> 
> Christian Ehrhardt wrote:
> 
>>> Cheers,
>>> Ben.
> 
>> For comparison I defined DEBUG in the good kernel (arch=ppc) and that 
>> is what the initialization prints (pci ...:0a:1 is the secondary head 
>> of the same graphic card an it's not an issue if thats not allocated):
[...]
>    You've changed fb_base_phys and mmio_base_phys to resource_size_t 
> which is 64-bit, so use %llx to print them.
> 
Thanks your absolutely right, I sometimes forget that I need long long for 64bit on 32bit archs (and ignored the warnings :-( ).
I corrected the printk format strings and attached the new logs.

[...]
>> +else {
>> +printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__, (this->end + 1), this->sibling);
>> +}
>>                 new->start = this->end + 1;
>>                 this = this->sibling;
> 
>    And here. Yet it's not clear why you call resource's 'end' 'start'...

It's the new->start that get's calculated one line after that new else part.
I printed that one to to see a bit how the loop iterates the resource elements.

> 
> WBR, Sergei


-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

[-- Attachment #2: pci_resource_issue_bootmsg_badkernel.txt --]
[-- Type: text/plain, Size: 5748 bytes --]

With DEBUG in arch/powerpc/kernel/pci-common.c, debug in commandline and a patch with some printk's (I attached the patch because it is the usual "put printk's everywhere" so the diff helps to understand where the prints come from). Corrected prinf format specifiers according to the comments from Sergei Shtylyov.

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
4xx PCI DMA offset set to 0x00000000
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:00:00.0
Try to map irq for 0000:00:00.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.0...
 -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
 -> mapped to linux irq 16
Try to map irq for 0000:00:0a.1...
PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0365060 (PCI IO)
__request_resource - request 0xcf8045b0 name '/plb/pci@1ec000000' start 0x0 end 0xfffff
__request_resource - no conflict parent 0xc0365060 sibling 0x00000000
PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0365038 (PCI mem)
__request_resource - request 0xcf8045d8 name '/plb/pci@1ec000000' start 0x180000000 end 0x18fffffff
__request_resource - no conflict parent 0xc0365038 sibling 0x00000000
PCI: Assigning unassigned resouces...
pci_assign_unassigned_resources -#1- bus 0xcf82d400
pci_assign_unassigned_resources -#2- bus 0xcf82d400
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
find_resource - found start 0x180000000 end 0x187ffffff
__request_resource - request 0xcf810578 name '0000:00:0a.0' start 0x180000000 end 0x187ffffff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
find_resource - continue with start 0x188000000 on 0x00000000
find_resource - found start 0x188000000 end 0x18fffffff
__request_resource - request 0xcf810178 name '0000:00:0a.1' start 0x188000000 end 0x18fffffff
__request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_assign_resource - second pci_bus_alloc_resource call
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x20000 startcalc 0xffffffff, align 0x20000
find_resource - size 0x20000, min 0x180000000, max 0xffffffffffffffff
find_resource - continue with start 0x188000000 on 0xcf810178
find_resource - continue with start 0x190000000 on 0x00000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x10000 startcalc 0xffffffff, align 0x10000
find_resource - size 0x10000, min 0x180000000, max 0xffffffffffffffff
find_resource - continue with start 0x188000000 on 0xcf810178
find_resource - continue with start 0x190000000 on 0x00000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x10000 startcalc 0xffffffff, align 0x10000
find_resource - size 0x10000, min 0x180000000, max 0xffffffffffffffff
find_resource - continue with start 0x188000000 on 0xcf810178
find_resource - continue with start 0x190000000 on 0x00000000
find_resource - no this - exit
PCI: pci_assign_resource - Failed to allocate mem resource #1:10000@190000000 for 0000:00:0a.1
pci_assign_resource - allocate with IORESOURCE_PREFETCH
pci_bus_alloc_resource - enter
pci_bus_alloc_resource - call allocate ressource size 0x100 startcalc 0xffffffff, align 0x100
find_resource - size 0x100, min 0x1000, max 0xffffffffffffffff
find_resource - found start 0x1000 end 0x10ff
__request_resource - request 0xcf8105a0 name '0000:00:0a.0' start 0x1000 end 0x10ff
__request_resource - no conflict parent 0xcf8045b0 sibling 0x00000000

[...]

radeonfb_pci_register BEGIN
radeonfb_pci_register - resource0 0x180000000 - 0x187ffffff
radeonfb_pci_register - resource1 0x1000 - 0x10ff
radeonfb_pci_register - resource2 0x0 - 0x0
radeonfb_pci_register - got pci ressources fb_base_phys 0x180000000 mmio_base_phys 0x0
__request_resource - request 0xcf8bfd20 name 'radeonfb framebuffer' start 0x180000000 end 0x187ffffff
__request_resource - request 0xcf8bfd20 name 'radeonfb framebuffer' start 0x180000000 end 0x187ffffff
__request_resource - request 0xcf8bfd20 name 'radeonfb framebuffer' start 0x180000000 end 0x187ffffff
__request_resource - no conflict parent 0xcf810578 sibling 0x00000000
radeonfb_pci_register - call ioremap for base 0x0 and size 16384
__ioremap(): phys addr 0x0 is RAM lr 0xc029df88 - mem_init_done 1 highmem@0x10000000
radeonfb (0000:00:0a.0): cannot map MMIO
radeonfb: probe of 0000:00:0a.0 failed with error -5


[-- Attachment #3: debug_pci_radeonfb.diff --]
[-- Type: text/x-patch, Size: 8625 bytes --]

Subject: [PATCH] : ! debug only ! - printk's in pci ressource handling

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This defines debug for pci and put's some printk's to keep track of the pci
ressource handling. This patch is just for reference to understand the
resulting boot message log.
The patch is ugly - but for debugging only ;-)

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/kernel/pci-common.c |    2 ++
 arch/powerpc/mm/pgtable_32.c     |    4 ++--
 drivers/pci/bus.c                |    3 +++
 drivers/pci/setup-res.c          |   12 ++++++++----
 drivers/video/aty/radeon_base.c  |    7 +++++++
 drivers/video/aty/radeonfb.h     |    4 ++--
 kernel/resource.c                |   17 ++++++++++++++++-
 7 files changed, 40 insertions(+), 9 deletions(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -37,6 +37,8 @@
 #include <asm/machdep.h>
 #include <asm/ppc-pci.h>
 #include <asm/firmware.h>
+
+#define DEBUG
 
 #ifdef DEBUG
 #include <asm/udbg.h>
diff --git a/arch/powerpc/mm/pgtable_32.c b/arch/powerpc/mm/pgtable_32.c
--- a/arch/powerpc/mm/pgtable_32.c
+++ b/arch/powerpc/mm/pgtable_32.c
@@ -183,8 +183,8 @@ __ioremap(phys_addr_t addr, unsigned lon
 	 * mem_init() sets high_memory so only do the check after that.
 	 */
 	if (mem_init_done && (p < virt_to_phys(high_memory))) {
-		printk("__ioremap(): phys addr 0x%llx is RAM lr %p\n",
-		       (unsigned long long)p, __builtin_return_address(0));
+		printk("__ioremap(): phys addr 0x%llx is RAM lr 0x%p - mem_init_done %d highmem@0x%p\n",
+		       (unsigned long long)p, __builtin_return_address(0), mem_init_done, virt_to_phys(high_memory));
 		return NULL;
 	}
 
diff --git a/drivers/pci/bus.c b/drivers/pci/bus.c
--- a/drivers/pci/bus.c
+++ b/drivers/pci/bus.c
@@ -42,6 +42,8 @@ pci_bus_alloc_resource(struct pci_bus *b
 {
 	int i, ret = -ENOMEM;
 
+printk(KERN_ERR"%s - enter\n", __func__);
+
 	type_mask |= IORESOURCE_IO | IORESOURCE_MEM;
 
 	for (i = 0; i < PCI_BUS_NUM_RESOURCES; i++) {
@@ -59,6 +61,7 @@ pci_bus_alloc_resource(struct pci_bus *b
 		    !(res->flags & IORESOURCE_PREFETCH))
 			continue;
 
+printk(KERN_ERR"%s - call allocate ressource size 0x%0llx startcalc 0x%0x, align 0x%0llx\n", __func__, size, (r->start ? : min,-1), align);
 		/* Ok, try it out.. */
 		ret = allocate_resource(r, res, size,
 					r->start ? : min,
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -544,10 +544,12 @@ pci_assign_unassigned_resources(void)
 	/* Depth first, calculate sizes and alignments of all
 	   subordinate buses. */
 	list_for_each_entry(bus, &pci_root_buses, node) {
+printk(KERN_ERR"%s -#1- bus 0x%p\n",__func__, bus);
 		pci_bus_size_bridges(bus);
 	}
 	/* Depth last, allocate resources and update the hardware. */
 	list_for_each_entry(bus, &pci_root_buses, node) {
+printk(KERN_ERR"%s -#2- bus 0x%p\n",__func__, bus);
 		pci_bus_assign_resources(bus);
 		pci_enable_bridges(bus);
 	}
diff --git a/drivers/pci/setup-res.c b/drivers/pci/setup-res.c
--- a/drivers/pci/setup-res.c
+++ b/drivers/pci/setup-res.c
@@ -142,10 +142,13 @@ int pci_assign_resource(struct pci_dev *
 	   required alignment in the "start" field. */
 	align = (resno < PCI_BRIDGE_RESOURCES) ? size : res->start;
 
+printk(KERN_ERR"%s - allocate with IORESOURCE_PREFETCH\n", __func__);
+
 	/* First, try exact prefetching match.. */
 	ret = pci_bus_alloc_resource(bus, res, size, align, min,
 				     IORESOURCE_PREFETCH,
 				     pcibios_align_resource, dev);
+
 
 	if (ret < 0 && (res->flags & IORESOURCE_PREFETCH)) {
 		/*
@@ -154,13 +157,14 @@ int pci_assign_resource(struct pci_dev *
 		 * But a prefetching area can handle a non-prefetching
 		 * window (it will just not perform as well).
 		 */
+printk(KERN_ERR"%s - second pci_bus_alloc_resource call\n", __func__);
 		ret = pci_bus_alloc_resource(bus, res, size, align, min, 0,
 					     pcibios_align_resource, dev);
 	}
 
 	if (ret) {
-		printk(KERN_ERR "PCI: Failed to allocate %s resource "
-			"#%d:%llx@%llx for %s\n",
+		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
+			"#%d:%llx@%llx for %s\n", __func__,
 			res->flags & IORESOURCE_IO ? "I/O" : "mem",
 			resno, (unsigned long long)size,
 			(unsigned long long)res->start, pci_name(dev));
@@ -197,8 +201,8 @@ int pci_assign_resource_fixed(struct pci
 	}
 
 	if (ret) {
-		printk(KERN_ERR "PCI: Failed to allocate %s resource "
-				"#%d:%llx@%llx for %s\n",
+		printk(KERN_ERR "PCI: %s - Failed to allocate %s resource "
+				"#%d:%llx@%llx for %s\n", __func__,
 			res->flags & IORESOURCE_IO ? "I/O" : "mem",
 			resno, (unsigned long long)(res->end - res->start + 1),
 			(unsigned long long)res->start, pci_name(dev));
diff --git a/drivers/video/aty/radeon_base.c b/drivers/video/aty/radeon_base.c
--- a/drivers/video/aty/radeon_base.c
+++ b/drivers/video/aty/radeon_base.c
@@ -2160,6 +2160,10 @@ static int __devinit radeonfb_pci_regist
 	int ret;
 
 	RTRACE("radeonfb_pci_register BEGIN\n");
+
+printk(KERN_ERR"%s - resource0 0x%0llx - 0x%0llx\n", __func__, pdev->resource[0].start, pdev->resource[0].end);
+printk(KERN_ERR"%s - resource1 0x%0llx - 0x%0llx\n", __func__, pdev->resource[1].start, pdev->resource[1].end);
+printk(KERN_ERR"%s - resource2 0x%0llx - 0x%0llx\n", __func__, pdev->resource[2].start, pdev->resource[2].end);
 	
 	/* Enable device in PCI config */
 	ret = pci_enable_device(pdev);
@@ -2198,6 +2202,8 @@ static int __devinit radeonfb_pci_regist
 	rinfo->fb_base_phys = pci_resource_start (pdev, 0);
 	rinfo->mmio_base_phys = pci_resource_start (pdev, 2);
 
+printk(KERN_ERR"%s - got pci ressources fb_base_phys 0x%0llx mmio_base_phys 0x%0llx\n", __func__,rinfo->fb_base_phys,rinfo->mmio_base_phys);
+
 	/* request the mem regions */
 	ret = pci_request_region(pdev, 0, "radeonfb framebuffer");
 	if (ret < 0) {
@@ -2214,6 +2220,7 @@ static int __devinit radeonfb_pci_regist
 	}
 
 	/* map the regions */
+printk(KERN_ERR "%s - call ioremap for base 0x%0llx and size %d\n",__func__, rinfo->mmio_base_phys, RADEON_REGSIZE);
 	rinfo->mmio_base = ioremap(rinfo->mmio_base_phys, RADEON_REGSIZE);
 	if (!rinfo->mmio_base) {
 		printk(KERN_ERR "radeonfb (%s): cannot map MMIO\n",
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -287,8 +287,8 @@ struct radeonfb_info {
 
 	char			name[DEVICE_NAME_SIZE];
 
-	unsigned long		mmio_base_phys;
-	unsigned long		fb_base_phys;
+	resource_size_t		mmio_base_phys;
+	resource_size_t		fb_base_phys;
 
 	void __iomem		*mmio_base;
 	void __iomem		*fb_base;
diff --git a/kernel/resource.c b/kernel/resource.c
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -152,6 +152,9 @@ static struct resource * __request_resou
 	resource_size_t end = new->end;
 	struct resource *tmp, **p;
 
+printk(KERN_ERR"%s - request 0x%p name '%s' start 0x%0llx end 0x%0llx\n",
+			__func__, new, new->name, start, end);
+
 	if (end < start)
 		return root;
 	if (start < root->start)
@@ -165,6 +168,7 @@ static struct resource * __request_resou
 			new->sibling = tmp;
 			*p = new;
 			new->parent = root;
+printk(KERN_ERR"%s - no conflict parent 0x%p sibling 0x%p\n",__func__, new->parent, new->sibling);
 			return NULL;
 		}
 		p = &tmp->sibling;
@@ -305,6 +309,8 @@ static int find_resource(struct resource
 {
 	struct resource *this = root->child;
 
+printk(KERN_ERR"%s - size 0x%0llx, min 0x%0llx, max 0x%0llx\n", __func__, size, min, max);
+
 	new->start = root->start;
 	/*
 	 * Skip past an allocated resource that starts at 0, since the assignment
@@ -328,10 +334,16 @@ static int find_resource(struct resource
 			alignf(alignf_data, new, size, align);
 		if (new->start < new->end && new->end - new->start >= size - 1) {
 			new->end = new->start + size - 1;
+printk(KERN_ERR"%s - found start 0x%0llx end 0x%0llx\n", __func__, new->start, new->end);
 			return 0;
 		}
-		if (!this)
+		if (!this) {
+printk(KERN_ERR"%s - no this - exit\n", __func__);
 			break;
+}
+else {
+printk(KERN_ERR"%s - continue with start 0x%0llx on 0x%p\n", __func__, (this->end + 1), this->sibling);
+}
 		new->start = this->end + 1;
 		this = this->sibling;
 	}
@@ -385,6 +397,9 @@ int insert_resource(struct resource *par
 {
 	int result;
 	struct resource *first, *next;
+
+printk(KERN_ERR"%s - insert 0x%p (start 0x%0llx end 0x%0llx) under parent 0x%p\n",
+			__func__, new, new->start, new->end, parent);
 
 	write_lock(&resource_lock);
 

Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov]

Christian Ehrhardt wrote:

>>> +else {
>>> +printk(KERN_ERR"%s - continue with start 0x%0lx on %p\n", __func__, 
>>> (this->end + 1), this->sibling);
>>> +}
>>>                 new->start = this->end + 1;
>>>                 this = this->sibling;
>>
>>
>>    And here. Yet it's not clear why you call resource's 'end' 'start'...

> It's the new->start that get's calculated one line after that new else 
> part.
> I printed that one to to see a bit how the loop iterates the resource 
> elements.

    Yeah, I figured that out right after sending mail. :-)

> ------------------------------------------------------------------------

> With DEBUG in arch/powerpc/kernel/pci-common.c, debug in commandline and a patch with some printk's (I attached the patch because it is the usual "put printk's everywhere" so the diff helps to understand where the prints come from). Corrected prinf format specifiers according to the comments from Sergei Shtylyov.

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
>  MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000
>   IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000
> 4xx PCI DMA offset set to 0x00000000
> PCI: Probing PCI hardware
> PCI: Hiding 4xx host bridge resources 0000:00:00.0
> Try to map irq for 0000:00:00.0...
>  -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
>  -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.0...
>  -> got one, spec 2 cells (0x00000003 0x00000008...) on /interrupt-controller2
>  -> mapped to linux irq 16
> Try to map irq for 0000:00:0a.1...
> PCI: PHB (bus 0) bridge rsrc 0: 0000000000000000-00000000000fffff [0x100], parent c0365060 (PCI IO)
> __request_resource - request 0xcf8045b0 name '/plb/pci@1ec000000' start 0x0 end 0xfffff
> __request_resource - no conflict parent 0xc0365060 sibling 0x00000000
> PCI: PHB (bus 0) bridge rsrc 1: 0000000180000000-000000018fffffff [0x200], parent c0365038 (PCI mem)
> __request_resource - request 0xcf8045d8 name '/plb/pci@1ec000000' start 0x180000000 end 0x18fffffff
> __request_resource - no conflict parent 0xc0365038 sibling 0x00000000
> PCI: Assigning unassigned resouces...
> pci_assign_unassigned_resources -#1- bus 0xcf82d400
> pci_assign_unassigned_resources -#2- bus 0xcf82d400
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
> find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
> find_resource - found start 0x180000000 end 0x187ffffff
> __request_resource - request 0xcf810578 name '0000:00:0a.0' start 0x180000000 end 0x187ffffff
> __request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x8000000 startcalc 0xffffffff, align 0x8000000
> find_resource - size 0x8000000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0x00000000
> find_resource - found start 0x188000000 end 0x18fffffff
> __request_resource - request 0xcf810178 name '0000:00:0a.1' start 0x188000000 end 0x18fffffff
> __request_resource - no conflict parent 0xcf8045d8 sibling 0x00000000
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_assign_resource - second pci_bus_alloc_resource call
> pci_bus_alloc_resource - enter

    Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 265 
MiB of the PCI memory space (128+128), so no place is left for other memory BARs.

> pci_bus_alloc_resource - call allocate ressource size 0x20000 startcalc 0xffffffff, align 0x20000
> find_resource - size 0x20000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0xcf810178
> find_resource - continue with start 0x190000000 on 0x00000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #6:20000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH
> pci_bus_alloc_resource - enter
> pci_bus_alloc_resource - call allocate ressource size 0x10000 startcalc 0xffffffff, align 0x10000
> find_resource - size 0x10000, min 0x180000000, max 0xffffffffffffffff
> find_resource - continue with start 0x188000000 on 0xcf810178
> find_resource - continue with start 0x190000000 on 0x00000000
> find_resource - no this - exit
> PCI: pci_assign_resource - Failed to allocate mem resource #2:10000@190000000 for 0000:00:0a.0
> pci_assign_resource - allocate with IORESOURCE_PREFETCH

    Hm, BAR2 shouldn't be allocated in theprefetchable space -- it corresponds 
to non-prefetchable (from lspci's output) MMIO register region...

WBR, Sergei

Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov]

Hello, I wrote:

>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 
> 265 MiB of the PCI memory space (128+128), so no place is left for other 
> memory BARs.

    What's interesting, the Sequoia/Rainier board user manual says that PCI 
memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux code seem 
to always have assumed only 0x[1]800000000 thru 0x[1]8fffffff...

WBR, Sergei

Re: pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 5100 bytes --]

Sergei Shtylyov wrote:
> Hello, I wrote:
> 
>>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the whole 
>> 265 MiB of the PCI memory space (128+128), so no place is left for 
>> other memory BARs.
> 
>    What's interesting, the Sequoia/Rainier board user manual says that 
> PCI memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux 
> code seem to always have assumed only 0x[1]800000000 thru 0x[1]8fffffff...
> 
> WBR, Sergei

Thanks to all your help I saw that the detected spaces on boot are wrong because of the dts file.

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000    => 256M
  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000    => 1M

The Documentation of the 440EPx core lists these spaces:
PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
I/O              1 E800 0000     1 E800 FFFF     64KB
I/O              1 E880 0000     1 EBFF FFFF     56MB

I modified the dts file and now it shows this on boot which is what the user manual lists as mem/io space:

PCI host bridge /plb/pci@1ec000000 (primary) ranges:
 MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000
  IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000
  IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000
 \--> Skipped (too many) !
4xx PCI DMA offset set to 0x00000000

The detected sizes look good compared to the processor documentation.
But I never modified a dts file before and I only found a ranges documentation speaking of three elemnts in the ranges element.
So feel free to correct the dts if I wrote something bad without knowing it (e.g. that skipped message).

The issue that let me start debugging this was the initialization of the radeonfb driver and with that patch it works:
radeonfb_pci_register BEGIN
radeonfb (0000:00:0a.0): Cannot match card to OF node !
aper_base: 80000000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: ffff9000
radeonfb (0000:00:0a.0): Found 131072k of DDR 64 bits wide videoram
radeonfb (0000:00:0a.0): mapped 16384k videoram
radeonfb: Found Intel x86 BIOS ROM Image
radeonfb: Retrieved PLL infos from BIOS
radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, System=200.00 MHz
radeonfb: PLL min 20000 max 40000
1 chips in connector info
 - chip 1 has 2 connectors
  * connector 0 of type 2 (CRT) : 2300
  * connector 1 of type 3 (DVI-I) : 3201
Starting monitor auto detection...
radeonfb: I2C (port 1) ... not found
radeonfb: I2C (port 2) ... found TMDS panel
radeonfb: I2C (port 3) ... found CRT display
i2c-adapter i2c-3: unable to read EDID block.
i2c-adapter i2c-3: unable to read EDID block.
i2c-adapter i2c-3: unable to read EDID block.
radeonfb: I2C (port 4) ... not found
radeon_probe_OF_head
radeonfb: I2C (port 2) ... found TMDS panel
radeon_probe_OF_head
radeonfb: I2C (port 3) ... found CRT display
radeonfb: Monitor 1 type DFP found
radeonfb: EDID probed
radeonfb: Monitor 2 type CRT found
radeonfb: EDID probed
Parsing EDID data for panel info
Setting up default mode based on panel info
radeonfb (0000:00:0a.0): ATI Radeon Y`
radeonfb_pci_register END

And btw. now we really need the change of the radeonfb.h to use the correct resource_size_t type, otherwise it fails with:

radeonfb_pci_register BEGIN
Machine check in kernel mode.
Data Read PLB Error
Oops: Machine check, sig: 7 [#1]
Sequoia
Modules linked in:
NIP: c029cf00 LR: c029cee8 CTR: 00000000
REGS: c038bf50 TRAP: 0214   Not tainted  (2.6.25-rc9)
MSR: 00029000 <EE,ME>  CR: 84000028  XER: 0000005f
TASK = cf81ec00[1] 'swapper' THREAD: cf82e000
GPR00: 01000000 cf82fe00 cf81ec00 d1018000 d101b000 00000000 90023000 0000071b
GPR08: 00000000 00000000 9002371b 00000000 9002ffff 00000000 0ffa6800 0ffbf000
GPR16: 100c0000 00000000 100c0000 c02e0000 cf810458 cf8a0608 cf8a0000 00000001
GPR24: c0350000 cf810400 c037102c cf813de0 c03713f4 c0371800 00000000 cf8a02ec
NIP [c029cf00] 0xc029cf00
LR [c029cee8] 0xc029cee8
Call Trace:
[cf82fe00] [c029cee8] 0xc029cee8 (unreliable)
[cf82fe40] [c012f554] pci_device_probe+0x80/0xa0
[cf82fe60] [c019014c] driver_probe_device+0xb8/0x1cc
[cf82fe80] [c0190438] __driver_attach+0xcc/0xf8
[cf82fea0] [c018ecd4] bus_for_each_dev+0x58/0x94
[cf82fed0] [c018fe7c] driver_attach+0x24/0x34
[cf82fee0] [c018fc6c] bus_add_driver+0xb0/0x248
[cf82ff00] [c0190920] driver_register+0x48/0x130
[cf82ff20] [c012f158] __pci_register_driver+0x48/0x94
[cf82ff40] [c034bca4] radeonfb_init+0xc4/0x21c
[cf82ff70] [c0337840] kernel_init+0x98/0x284
[cf82fff0] [c000cc4c] kernel_thread+0x44/0x60
Instruction dump:
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX
XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX XXXXXXXX

I attached the patch I used to get it working now for further discussion e.g. because I don't really know dts syntax ;-)
I hope both changes find their way into the kernel once you are all agreeing with the new dts content.

I still have issues with my X11, but thats another story.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

[-- Attachment #2: fix-sequoia-pci-memory-dts --]
[-- Type: text/plain, Size: 2281 bytes --]

Subject: [PATCH][dts][radeonfb]: fix pci mem in dts and radeonfb resource variables

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch is fixing the sequoia.dts device tree file to the values defined
in the 440Epx data sheet from amcc.
That fixes an issue where my graphic card could not initialize because the pci
resource space was not big enough.
The related mail thread about the backgrounds of this has the subject "pci
issue - wrong detection of pci ressources"
After these values were fixed another modification that came up in the mail
thread was needed to prevent an error. This change fixes the type of the
resource vaiables in the radeon frame buffer driver (We might want to split
that into two patches).

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 arch/powerpc/boot/dts/sequoia.dts |    9 +++++++--
 drivers/video/aty/radeonfb.h      |    4 ++--
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -344,9 +344,14 @@
 			/* Outbound ranges, one memory and one IO,
 			 * later cannot be changed. Chip supports a second
 			 * IO range but we don't use it for now
+			 * From the 440EPx user manual:
+			 * PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
+			 * I/O              1 E800 0000     1 E800 FFFF     64KB
+			 * I/O              1 E880 0000     1 EBFF FFFF     56MB
 			 */
-			ranges = <02000000 0 80000000 1 80000000 0 10000000
-				01000000 0 00000000 1 e8000000 0 00100000>;
+			ranges = <02000000 0 80000000 1 80000000 0 40000000
+				01000000 0 00000000 1 e8000000 0 00010000
+				01000000 0 00000000 1 e8800000 0 03800000>;
 
 			/* Inbound 2GB range starting at 0 */
 			dma-ranges = <42000000 0 0 0 0 0 80000000>;
diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
--- a/drivers/video/aty/radeonfb.h
+++ b/drivers/video/aty/radeonfb.h
@@ -287,8 +287,8 @@ struct radeonfb_info {
 
 	char			name[DEVICE_NAME_SIZE];
 
-	unsigned long		mmio_base_phys;
-	unsigned long		fb_base_phys;
+	resource_size_t		mmio_base_phys;
+	resource_size_t		fb_base_phys;
 
 	void __iomem		*mmio_base;
 	void __iomem		*fb_base;

Re: pci issue - wrong detection of pci ressources

[Sergei Shtylyov]

Hello.

Christian Ehrhardt wrote:

>>>    Ah, that's what happens -- BAR0 in functions 0/1 takes up the 
>>> whole 265 MiB of the PCI memory space (128+128), so no place is left 
>>> for other memory BARs.

>>    What's interesting, the Sequoia/Rainier board user manual says that 
>> PCI memory is 0x80000000 thru 0xbfffffff (i.e. 1 GiB), while the Linux 
>> code seem to always have assumed only 0x[1]800000000 thru 
>> 0x[1]8fffffff...

> Thanks to all your help I saw that the detected spaces on boot are wrong 
> because of the dts file.

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> MEM 0x0000000180000000..0x000000018fffffff -> 0x0000000080000000    => 256M
>  IO 0x00000001e8000000..0x00000001e80fffff -> 0x0000000000000000    => 1M

    Yeah, I/O space should be 64K according to what arch/ppc/ had (well, I'm 
looking at the out-of-tree source code :-).

> The Documentation of the 440EPx core lists these spaces:
> PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
> I/O              1 E800 0000     1 E800 FFFF     64KB
> I/O              1 E880 0000     1 EBFF FFFF     56MB

    Having 2 I/O spaces looks just wrong. Actually, PCs do well with only 64K 
of I/O space.

> I modified the dts file and now it shows this on boot which is what the 
> user manual lists as mem/io space:

> PCI host bridge /plb/pci@1ec000000 (primary) ranges:
> MEM 0x0000000180000000..0x00000001bfffffff -> 0x0000000080000000
>  IO 0x00000001e8000000..0x00000001e800ffff -> 0x0000000000000000
>  IO 0x00000001e8800000..0x00000001ebffffff -> 0x0000000000000000
> \--> Skipped (too many) !
> 4xx PCI DMA offset set to 0x00000000

> The detected sizes look good compared to the processor documentation.
> But I never modified a dts file before and I only found a ranges 
> documentation speaking of three elemnts in the ranges element.
> So feel free to correct the dts if I wrote something bad without knowing 
> it (e.g. that skipped message).

> The issue that let me start debugging this was the initialization of the 
> radeonfb driver and with that patch it works:
> radeonfb_pci_register BEGIN
> radeonfb (0000:00:0a.0): Cannot match card to OF node !
> aper_base: 80000000 MC_FB_LOC to: 87ff8000, MC_AGP_LOC to: ffff9000
> radeonfb (0000:00:0a.0): Found 131072k of DDR 64 bits wide videoram
> radeonfb (0000:00:0a.0): mapped 16384k videoram
> radeonfb: Found Intel x86 BIOS ROM Image
> radeonfb: Retrieved PLL infos from BIOS
> radeonfb: Reference=27.00 MHz (RefDiv=12) Memory=240.00 Mhz, 
> System=200.00 MHz
> radeonfb: PLL min 20000 max 40000
> 1 chips in connector info
> - chip 1 has 2 connectors
>  * connector 0 of type 2 (CRT) : 2300
>  * connector 1 of type 3 (DVI-I) : 3201
> Starting monitor auto detection...
> radeonfb: I2C (port 1) ... not found
> radeonfb: I2C (port 2) ... found TMDS panel
> radeonfb: I2C (port 3) ... found CRT display
> i2c-adapter i2c-3: unable to read EDID block.
> i2c-adapter i2c-3: unable to read EDID block.
> i2c-adapter i2c-3: unable to read EDID block.
> radeonfb: I2C (port 4) ... not found
> radeon_probe_OF_head
> radeonfb: I2C (port 2) ... found TMDS panel
> radeon_probe_OF_head
> radeonfb: I2C (port 3) ... found CRT display
> radeonfb: Monitor 1 type DFP found
> radeonfb: EDID probed
> radeonfb: Monitor 2 type CRT found
> radeonfb: EDID probed
> Parsing EDID data for panel info
> Setting up default mode based on panel info
> radeonfb (0000:00:0a.0): ATI Radeon Y`

    Hm, what's that Y`?

> radeonfb_pci_register END

> And btw. now we really need the change of the radeonfb.h to use the 
> correct resource_size_t type, otherwise it fails with:

    Of course.


> I attached the patch I used to get it working now for further discussion 
> e.g. because I don't really know dts syntax ;-)
> I hope both changes find their way into the kernel once you are all 
> agreeing with the new dts content.

> I still have issues with my X11, but thats another story.


> ------------------------------------------------------------------------
> 
> Subject: [PATCH][dts][radeonfb]: fix pci mem in dts and radeonfb resource variables

> From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

> This patch is fixing the sequoia.dts device tree file to the values defined
> in the 440Epx data sheet from amcc.
> That fixes an issue where my graphic card could not initialize because the pci
> resource space was not big enough.
> The related mail thread about the backgrounds of this has the subject "pci
> issue - wrong detection of pci ressources"
> After these values were fixed another modification that came up in the mail
> thread was needed to prevent an error. This change fixes the type of the
> resource vaiables in the radeon frame buffer driver (We might want to split
> that into two patches).

> Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

> diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
> --- a/arch/powerpc/boot/dts/sequoia.dts
> +++ b/arch/powerpc/boot/dts/sequoia.dts
> @@ -344,9 +344,14 @@
>  			/* Outbound ranges, one memory and one IO,
>  			 * later cannot be changed. Chip supports a second
>  			 * IO range but we don't use it for now
> +			 * From the 440EPx user manual:
> +			 * PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
> +			 * I/O              1 E800 0000     1 E800 FFFF     64KB
> +			 * I/O              1 E880 0000     1 EBFF FFFF     56MB
>  			 */
> -			ranges = <02000000 0 80000000 1 80000000 0 10000000
> -				01000000 0 00000000 1 e8000000 0 00100000>;
> +			ranges = <02000000 0 80000000 1 80000000 0 40000000
> +				01000000 0 00000000 1 e8000000 0 00010000
> +				01000000 0 00000000 1 e8800000 0 03800000>;

   I don't think 56 MiB of I/O space make sense, so might as well skip the 3rg 
range...

>  
>  			/* Inbound 2GB range starting at 0 */
>  			dma-ranges = <42000000 0 0 0 0 0 80000000>;
> diff --git a/drivers/video/aty/radeonfb.h b/drivers/video/aty/radeonfb.h
> --- a/drivers/video/aty/radeonfb.h
> +++ b/drivers/video/aty/radeonfb.h
> @@ -287,8 +287,8 @@ struct radeonfb_info {
>  
>  	char			name[DEVICE_NAME_SIZE];
>  
> -	unsigned long		mmio_base_phys;
> -	unsigned long		fb_base_phys;
> +	resource_size_t		mmio_base_phys;
> +	resource_size_t		fb_base_phys;
>  
>  	void __iomem		*mmio_base;
>  	void __iomem		*fb_base;

    I think you'd better use Ben's patch that he's just posted:

http://patchwork.ozlabs.org/linuxppc/patch?id=18034

WBR, Sergei

Re: pci issue - wrong detection of pci ressources

[Christian Ehrhardt]

[-- Attachment #1: Type: text/plain, Size: 1266 bytes --]

Sergei Shtylyov wrote:
> Hello.
> 
> Christian Ehrhardt wrote:
> 
[...]
> 
>> The Documentation of the 440EPx core lists these spaces:
>> PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
>> I/O              1 E800 0000     1 E800 FFFF     64KB
>> I/O              1 E880 0000     1 EBFF FFFF     56MB
> 
> Having 2 I/O spaces looks just wrong. Actually, PCs do well with only 
> 64K of I/O space.
> 

ok - I just wanted to be complete.
I removed the 56M section from the new dts file patch.

[...]

>> radeonfb: EDID probed
>> Parsing EDID data for panel info
>> Setting up default mode based on panel info
>> radeonfb (0000:00:0a.0): ATI Radeon Y`
> 
>    Hm, what's that Y`?

Thats the final message in the radeonfb driver ater initializing everything.
   printk ("radeonfb (%s): %s\n", pci_name(rinfo->pdev), rinfo->name);
I wonder why that rinfo->name is clobbered - maybe another issue, I have to keep that in mind.

[...]
> 
>    I think you'd better use Ben's patch that he's just posted:
> 
> http://patchwork.ozlabs.org/linuxppc/patch?id=18034
> 
> WBR, Sergei

yep - I use Ben's patch now which reduces my patch to the actual dts fix.
Updated patch attached.

-- 

Grüsse / regards, 
Christian Ehrhardt
IBM Linux Technology Center, Open Virtualization

[-- Attachment #2: fix-sequoia-pci-memory-dts --]
[-- Type: text/plain, Size: 1470 bytes --]

Subject: [PATCH][dts]: fix pci mem in sequoia dts

From: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>

This patch is fixing the sequoia.dts device tree file to the values defined
in the 440Epx data sheet from amcc.
That fixes an issue where my graphic card could not initialize because the pci
resource space was not big enough.
The related mail thread about the backgrounds of this has the subject "pci
issue - wrong detection of pci ressources"

Signed-off-by: Christian Ehrhardt <ehrhardt@linux.vnet.ibm.com>
---

[diffstat]
 sequoia.dts |    8 ++++++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/boot/dts/sequoia.dts b/arch/powerpc/boot/dts/sequoia.dts
--- a/arch/powerpc/boot/dts/sequoia.dts
+++ b/arch/powerpc/boot/dts/sequoia.dts
@@ -344,9 +344,13 @@
 			/* Outbound ranges, one memory and one IO,
 			 * later cannot be changed. Chip supports a second
 			 * IO range but we don't use it for now
+			 * From the 440EPx user manual:
+			 * PCI 1 Memory     1 8000 0000     1 BFFF FFFF     1GB
+			 * I/O              1 E800 0000     1 E800 FFFF     64KB
+			 * I/O              1 E880 0000     1 EBFF FFFF     56MB
 			 */
-			ranges = <02000000 0 80000000 1 80000000 0 10000000
-				01000000 0 00000000 1 e8000000 0 00100000>;
+			ranges = <02000000 0 80000000 1 80000000 0 40000000
+				01000000 0 00000000 1 e8000000 0 00010000>;
 
 			/* Inbound 2GB range starting at 0 */
 			dma-ranges = <42000000 0 0 0 0 0 80000000>;

Re: pci issue - wrong detection of pci ressources

[Michel Dänzer]

On Tue, 2008-04-22 at 16:21 +0200, Christian Ehrhardt wrote:
> 
> >> radeonfb: EDID probed
> >> Parsing EDID data for panel info
> >> Setting up default mode based on panel info
> >> radeonfb (0000:00:0a.0): ATI Radeon Y`
> > 
> >    Hm, what's that Y`?
> 
> Thats the final message in the radeonfb driver ater initializing everything.
>    printk ("radeonfb (%s): %s\n", pci_name(rinfo->pdev), rinfo->name);
> I wonder why that rinfo->name is clobbered - maybe another issue, I
> have to keep that in mind.

It isn't clobbered, it's just the PCI device ID printed as characters.
That was a human readable string with early Radeons and thus convenient
for identifying them between humans, but that's no longer the case with
newer ones.


-- 
Earthling Michel Dänzer           |          http://tungstengraphics.com
Libre software enthusiast         |          Debian, X and DRI developer

Re: pci issue - wrong detection of pci ressources

[Benjamin Herrenschmidt]

> >> radeonfb: EDID probed
> >> Parsing EDID data for panel info
> >> Setting up default mode based on panel info
> >> radeonfb (0000:00:0a.0): ATI Radeon Y`
> > 
> >    Hm, what's that Y`?
> 
> Thats the final message in the radeonfb driver ater initializing everything.
>    printk ("radeonfb (%s): %s\n", pci_name(rinfo->pdev), rinfo->name);
> I wonder why that rinfo->name is clobbered - maybe another issue, I have to keep that in mind.

Nah, that's normal. ATI used to use nice letters for their PCI ID, and
we used to print that as that's also what they used in some docs etc...
but a few years ago, they started using other characters (running out of
letters). I think there's a patch floating around to print it in hex
instead.

Cheers,
Ben.

Re: pci issue - wrong detection of pci ressources

[Benjamin Herrenschmidt]

On Mon, 2008-04-21 at 13:55 +0200, Christian Ehrhardt wrote:
> Benjamin Herrenschmidt wrote:
> >> Yes you're right. Early at the pci initialization are errors of the allocation for pi ressources.
> >> And that are exactly the ressources failing later, so that pci initialization seem to be the reason for my problem.
> >> Was there any simple solution (e.g. just somehow increase memory reserved for pci) when you came across that issue Johan ?
> > 
> > Hrm... I was expecting to see a lot more output here, make sure you have
> > "debug" on your command line (or enable early debug output, same
> > effect).
> 
> There is nothing more even with debug in kernel command line.

Weird. pcibios_fixup_resources() should have printed things that I
didn't see in your log, which is why I asked...

I -think- your card is just asking too much, more than what we know how
to assign, but that doesn't explain why it used to work. I'll have to
dig a bit more.

You can assign more by changing the "ranges" property in the .dts, I
would expect the 44x PCI code I wrote to automatically adjust.

Cheers,
Ben.