linux-3.2.2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

linux-3.2.2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

unable to have a working radeon kms framebuffer with linux-3.2.2 on ppc
video card: Radeon X1650PRO PCIE

here the boot log:



U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)

CPU:   AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
       No Security/Kasumi support
       Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Sam460ex, PCIe 4x + SATA-2
I2C:   ready
DRAM:  2 GiB (ECC not enabled, 466 MHz, CL4)
PCI:   Bus Dev VenId DevId Class Int
        00  06  126f  0501  0380  00
PCIE1: successfully set as root-complex
        02  00  1002  71c1  0300  ff
Net:   ppc_4xx_eth0
FPGA:  Revision 03 (2010-10-07)
SM502: found
VGA:   1
VESA:  OK
Using Canyonlands machine description
Cannot reserve gpages without hugetlb enabled
Initializing cgroup subsys cpu
Linux version 3.2.2 (root@sam460) (gcc version 4.5.3 (CRUX PPC) ) #3 Fri Feb 3 0
2:20:16 CET 2012
Zone PFN ranges:
  DMA      0x00000000 -> 0x00030000
  Normal   empty
  HighMem  0x00030000 -> 0x00080000
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
    0: 0x00000000 -> 0x00080000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
Kernel command line: root=/dev/sda3 ro video=800x600 console=tty0 console=ttyS0,
115200 udbg-immortal
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2072768k/2097152k available (6732k kernel code, 24384k reserved, 196k da
ta, 141k bss, 200k init)
Kernel virtual memory layout:
  * 0xfffcf000..0xfffff000  : fixmap
  * 0xffc00000..0xffe00000  : highmem PTEs
  * 0xffa00000..0xffc00000  : consistent mem
  * 0xffa00000..0xffa00000  : early ioremap
  * 0xf1000000..0xffa00000  : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:512 nr_irqs:512 16
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
UIC3 (32 IRQ sources) at DCR 0xf0
clocksource: timebase mult[36db6e] shift[22] registered
Console: colour dummy device 80x25
console [tty0] enabled
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
devtmpfs: initialized
NET: Registered protocol family 16
256k L2-cache enabled
PCIE0: Port disabled via device-tree
PCIE1: Checking link...
PCIE1: Device detected, waiting for link...
PCIE1: link is up !
PCI host bridge /plb/pciex@d20000000 (primary) ranges:
 MEM 0x0000000e80000000..0x0000000effffffff -> 0x0000000080000000
 MEM 0x0000000f00100000..0x0000000f001fffff -> 0x0000000000000000
  IO 0x0000000f80010000..0x0000000f8001ffff -> 0x0000000000000000
 Removing ISA hole at 0x0000000f00100000
4xx PCI DMA offset set to 0x00000000
/plb/pciex@d20000000: Legacy ISA memory support enabled
PCIE1: successfully set as root-complex
PCI host bridge /plb/pci@c0ec00000 (primary) ranges:
 MEM 0x0000000d80000000..0x0000000dffffffff -> 0x0000000080000000
 MEM 0x0000000c0ee00000..0x0000000c0eefffff -> 0x0000000000000000
  IO 0x0000000c08000000..0x0000000c0800ffff -> 0x0000000000000000
 Removing ISA hole at 0x0000000c0ee00000
4xx PCI DMA offset set to 0x00000000
/plb/pci@c0ec00000: Legacy ISA memory support enabled
PCI: Probing PCI hardware
PCI: Hiding 4xx host bridge resources 0000:80:00.0
pci 0000:81:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with
 'pcie_aspm=force'
pci 0000:80:00.0: PCI bridge to [bus 81-bf]
pci 0000:80:00.0: BAR 15: assigned [mem 0xe80000000-0xe97ffffff pref]
pci 0000:80:00.0: BAR 14: assigned [mem 0xe98000000-0xe980fffff]
pci 0000:80:00.0: BAR 13: assigned [io  0xfffe1000-0xfffe1fff]
pci 0000:81:00.0: BAR 0: assigned [mem 0xe80000000-0xe8fffffff 64bit pref]
pci 0000:81:00.0: BAR 0: set to [mem 0xe80000000-0xe8fffffff 64bit pref] (PCI ad
dress [0x80000000-0x8fffffff])
pci 0000:81:00.0: BAR 6: assigned [mem 0xe90000000-0xe9001ffff pref]
pci 0000:81:00.0: BAR 2: assigned [mem 0xe98000000-0xe9800ffff 64bit]
pci 0000:81:00.0: BAR 2: set to [mem 0xe98000000-0xe9800ffff 64bit] (PCI address
 [0x98000000-0x9800ffff])
pci 0000:81:00.1: BAR 0: assigned [mem 0xe98010000-0xe9801ffff 64bit]
pci 0000:81:00.1: BAR 0: set to [mem 0xe98010000-0xe9801ffff 64bit] (PCI address
 [0x98010000-0x9801ffff])
pci 0000:81:00.0: BAR 4: assigned [io  0xfffe1000-0xfffe10ff]
pci 0000:81:00.0: BAR 4: set to [io  0xfffe1000-0xfffe10ff] (PCI address [0x1000
-0x10ff])
pci 0000:80:00.0: PCI bridge to [bus 81-bf]
pci 0000:80:00.0:   bridge window [io  0xfffe1000-0xfffe1fff]
pci 0000:80:00.0:   bridge window [mem 0xe98000000-0xe980fffff]
pci 0000:80:00.0:   bridge window [mem 0xe80000000-0xe97ffffff pref]
pci 0001:00:06.0: BAR 0: assigned [mem 0xd80000000-0xd83ffffff]
pci 0001:00:06.0: BAR 0: set to [mem 0xd80000000-0xd83ffffff] (PCI address [0x80
000000-0x83ffffff])
pci 0001:00:06.0: BAR 1: assigned [mem 0xd84000000-0xd841fffff]
pci 0001:00:06.0: BAR 1: set to [mem 0xd84000000-0xd841fffff] (PCI address [0x84
000000-0x841fffff])
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:81:00.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:81:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Could not remap bcsr
setting trigger mode 3 for irq 44 failed (uic_set_irq_type+0x0/0x164)
setting trigger mode 3 for irq 44 failed (uic_set_irq_type+0x0/0x164)
highmem bounce pool size: 64 pages
JFS: nTxBlock = 8192, nTxLock = 65536
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enab
led
Btrfs loaded
msgmni has been set to 1488
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4ef600300 (irq = 21) is a U6_16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0x4ef600400 (irq = 22) is a U6_16550A
4ef600300.serial: ttyS0 at MMIO 0x4ef600300 (irq = 21) is a 16550
4ef600400.serial: ttyS1 at MMIO 0x4ef600400 (irq = 22) is a 16550
Generic non-volatile memory driver v1.1
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV530 0x1002:0x71C1 0x174B:0x0840).
[drm] register mmio base: 0x98000000
[drm] register mmio size: 65536
radeon 0000:81:00.0: Invalid ROM contents
ATOM BIOS: X1650PRO
[drm] Generation 2 PCI interface, using max accessible memory
radeon 0000:81:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M us
ed)
radeon 0000:81:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 381024 kiB.
[TTM] Zone highmem: Available graphics memory: 1036384 kiB.
[TTM] Initializing pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: 1 quad pipes, 2 z pipes initialized.
Machine check in kernel mode.
Data Write PLB Error
Oops: Machine check, sig: 7 [#1]
Canyonlands
Modules linked in:
NIP: c0399564 LR: c03825e0 CTR: c039952c
REGS: efff7f10 TRAP: 0214   Not tainted  (3.2.2)
MSR: 00029000 <EE,ME,CE>  CR: 447f4228  XER: 00000000
TASK = ef830000[1] 'swapper' THREAD: ef834000
GPR00: f5580000 ef835d80 ef830000 ffffffea f5580004 002f018c 002f018c 00000000
GPR08: 800bf41b 00020000 00040000 c06ac844 447f4228 0400682e 0fff9038 00000000
GPR16: 0ffc2388 0ffc2368 0ffc2388 0ffc2368 0fff9038 00000001 c0000010 0000000f
GPR24: 00000000 00000000 ef8f89f8 ef8f8800 00400017 fffffff4 00000002 ef80d000
NIP [c0399564] rv370_pcie_gart_set_page+0x38/0x48
LR [c03825e0] radeon_gart_restore+0x58/0x84
Call Trace:
[ef835d90] [c039a4e0] rv370_pcie_gart_enable+0x4c/0x230
[ef835db0] [c03a3818] r520_startup+0xc0/0x144
[ef835dc0] [c03a3af8] r520_init+0x1ac/0x204
[ef835de0] [c036f020] radeon_device_init+0x3c0/0x470
[ef835df0] [c0370618] radeon_driver_load_kms+0xb0/0x104
[ef835e10] [c0343778] drm_get_pci_dev+0x148/0x218
[ef835e30] [c0541904] radeon_pci_probe+0xd4/0xdc
[ef835e50] [c02f32c4] local_pci_probe+0x5c/0xac
[ef835e70] [c02f387c] pci_device_probe+0x68/0x94
[ef835ea0] [c03cc330] driver_probe_device+0xe4/0x198
[ef835ec0] [c03cc454] __driver_attach+0x70/0x98
[ef835ee0] [c03cb3cc] bus_for_each_dev+0x60/0x90
[ef835f10] [c03cbf88] driver_attach+0x24/0x34
[ef835f20] [c03cbb54] bus_add_driver+0xbc/0x23c
[ef835f40] [c03cca6c] driver_register+0xb8/0x144
[ef835f60] [c02f3ab4] __pci_register_driver+0x4c/0xc8
[ef835f80] [c03438c4] drm_pci_init+0x7c/0xf8
[ef835fa0] [c067aa88] radeon_init+0xc8/0xd0
[ef835fb0] [c0001608] do_one_initcall+0xe0/0x1b8
[ef835fe0] [c0661798] kernel_init+0x88/0x120
[ef835ff0] [c000b140] kernel_thread+0x4c/0x68
Instruction dump:
80030324 3860ffea 4da00020 81290328 7f844840 4d9d0020 54c6c23e 54a5c00e
60c6000c 5484103a 7cc52b78 7c802214 <7c0004ac> 7ca0252c 38600000 4e800020
---[ end trace 9e9e815408964066 ]---
Kernel panic - not syncing: Attempted to kill init!
Call Trace:
Rebooting in 180 seconds..

-- 
acrux <acrux@cruxppc.org>

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

On Fri, 3 Feb 2012 02:56:18 +0100
acrux <acrux_it@libero.it> wrote:

unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
video card: Radeon X1650PRO PCIE

here the boot log:

U-Boot 2010.06.05 (Jul 05 2011 - 17:53:34)

CPU:   AMCC PowerPC 460EX Rev. B at 1166.667 MHz (PLB=233 OPB=116 EBC=116)
       No Security/Kasumi support
       Bootstrap Option H - Boot ROM Location I2C (Addr 0x52)
       Internal PCI arbiter enabled
       32 kB I-Cache 32 kB D-Cache
Board: Sam460ex, PCIe 4x + SATA-2
I2C:   ready
DRAM:  2 GiB (ECC not enabled, 466 MHz, CL4)
PCI:   Bus Dev VenId DevId Class Int
        00  06  126f  0501  0380  00
PCIE1: successfully set as root-complex
        02  00  1002  71c1  0300  ff
Net:   ppc_4xx_eth0
FPGA:  Revision 03 (2010-10-07)
SM502: found
VGA:   1
VESA:  OK
Using Canyonlands machine description
Initializing cgroup subsys cpu
Linux version 3.3.0-rc2 (root@sam460) (gcc version 4.5.3 (CRUX PPC) ) #2 Sat Feb 4 20:34:21 CET 2012
Zone PFN ranges:
  DMA      0x00000000 -> 0x00030000
  Normal   empty
  HighMem  0x00030000 -> 0x00080000
Movable zone start PFN for each node
Early memory PFN ranges
    0: 0x00000000 -> 0x00080000
MMU: Allocated 1088 bytes of context maps for 255 contexts
Built 1 zonelists in Zone order, mobility grouping on.  Total pages: 520192
Kernel command line: root=/dev/sda3 ro video=800x600 console=tty0 console=ttyS0,115200 udbg-immortal
PID hash table entries: 4096 (order: 2, 16384 bytes)
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes)
Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
Memory: 2072736k/2097152k available (6772k kernel code, 24416k reserved, 188k data, 143k bss, 196k init)
Kernel virtual memory layout:
  * 0xfffcf000..0xfffff000  : fixmap
  * 0xffc00000..0xffe00000  : highmem PTEs
  * 0xffa00000..0xffc00000  : consistent mem
  * 0xffa00000..0xffa00000  : early ioremap
  * 0xf1000000..0xffa00000  : vmalloc & ioremap
SLUB: Genslabs=13, HWalign=32, Order=0-3, MinObjects=0, CPUs=1, Nodes=1
NR_IRQS:512 nr_irqs:512 16
UIC0 (32 IRQ sources) at DCR 0xc0
UIC1 (32 IRQ sources) at DCR 0xd0
UIC2 (32 IRQ sources) at DCR 0xe0
UIC3 (32 IRQ sources) at DCR 0xf0
clocksource: timebase mult[db6db7] shift[24] registered
Console: colour dummy device 80x25
console [tty0] enabled
pid_max: default: 32768 minimum: 301
Mount-cache hash table entries: 512
devtmpfs: initialized
NET: Registered protocol family 16
256k L2-cache enabled
PCIE0: Port disabled via device-tree
PCIE1: Checking link...
PCIE1: Device detected, waiting for link...
PCIE1: link is up !
PCI host bridge /plb/pciex@d20000000 (primary) ranges:
 MEM 0x0000000e80000000..0x0000000effffffff -> 0x0000000080000000
 MEM 0x0000000f00100000..0x0000000f001fffff -> 0x0000000000000000
  IO 0x0000000f80010000..0x0000000f8001ffff -> 0x0000000000000000
 Removing ISA hole at 0x0000000f00100000
4xx PCI DMA offset set to 0x00000000
4xx PCI DMA window base to 0x0000000000000000
DMA window size 0x0000000080000000
/plb/pciex@d20000000: Legacy ISA memory support enabled
PCIE1: successfully set as root-complex
PCI host bridge /plb/pci@c0ec00000 (primary) ranges:
 MEM 0x0000000d80000000..0x0000000dffffffff -> 0x0000000080000000
 MEM 0x0000000c0ee00000..0x0000000c0eefffff -> 0x0000000000000000
  IO 0x0000000c08000000..0x0000000c0800ffff -> 0x0000000000000000
 Removing ISA hole at 0x0000000c0ee00000
4xx PCI DMA offset set to 0x00000000
4xx PCI DMA window base to 0x0000000000000000
DMA window size 0x0000000080000000
/plb/pci@c0ec00000: Legacy ISA memory support enabled
gpiochip_add: registered GPIOs 224 to 255 on device: /plb/opb/gpio@ef600b00
PCI: Probing PCI hardware
PCI host bridge to bus 0000:80
pci_bus 0000:80: root bus resource [io  0xfffe0000-0xfffeffff]
pci_bus 0000:80: root bus resource [mem 0xe80000000-0xeffffffff]
PCI: Hiding 4xx host bridge resources 0000:80:00.0
pci 0000:81:00.0: disabling ASPM on pre-1.1 PCIe device.  You can enable it with 'pcie_aspm=force'
pci 0000:80:00.0: PCI bridge to [bus 81-bf]
PCI host bridge to bus 0001:00
pci_bus 0001:00: root bus resource [io  0x0000-0xffff]
pci_bus 0001:00: root bus resource [mem 0xd80000000-0xdffffffff]
pci 0000:80:00.0: BAR 15: assigned [mem 0xe80000000-0xe97ffffff pref]
pci 0000:80:00.0: BAR 14: assigned [mem 0xe98000000-0xe980fffff]
pci 0000:80:00.0: BAR 13: assigned [io  0xfffe1000-0xfffe1fff]
pci 0000:81:00.0: BAR 0: assigned [mem 0xe80000000-0xe8fffffff 64bit pref]
pci 0000:81:00.0: BAR 6: assigned [mem 0xe90000000-0xe9001ffff pref]
pci 0000:81:00.0: BAR 2: assigned [mem 0xe98000000-0xe9800ffff 64bit]
pci 0000:81:00.1: BAR 0: assigned [mem 0xe98010000-0xe9801ffff 64bit]
pci 0000:81:00.0: BAR 4: assigned [io  0xfffe1000-0xfffe10ff]
pci 0000:80:00.0: PCI bridge to [bus 81-bf]
pci 0000:80:00.0:   bridge window [io  0xfffe1000-0xfffe1fff]
pci 0000:80:00.0:   bridge window [mem 0xe98000000-0xe980fffff]
pci 0000:80:00.0:   bridge window [mem 0xe80000000-0xe97ffffff pref]
pci 0001:00:06.0: BAR 0: assigned [mem 0xd80000000-0xd83ffffff]
pci 0001:00:06.0: BAR 1: assigned [mem 0xd84000000-0xd841fffff]
bio: create slab <bio-0> at 0
vgaarb: device added: PCI:0000:81:00.0,decodes=io+mem,owns=none,locks=none
vgaarb: loaded
vgaarb: bridge control possible 0000:81:00.0
SCSI subsystem initialized
usbcore: registered new interface driver usbfs
usbcore: registered new interface driver hub
usbcore: registered new device driver usb
Switching to clocksource timebase
NET: Registered protocol family 2
IP route cache hash table entries: 32768 (order: 5, 131072 bytes)
TCP established hash table entries: 131072 (order: 8, 1048576 bytes)
TCP bind hash table entries: 65536 (order: 6, 262144 bytes)
TCP: Hash tables configured (established 131072 bind 65536)
TCP reno registered
UDP hash table entries: 512 (order: 1, 8192 bytes)
UDP-Lite hash table entries: 512 (order: 1, 8192 bytes)
NET: Registered protocol family 1
RPC: Registered named UNIX socket transport module.
RPC: Registered udp transport module.
RPC: Registered tcp transport module.
RPC: Registered tcp NFSv4.1 backchannel transport module.
Could not remap bcsr
setting trigger mode 3 for irq 44 failed (uic_set_irq_type+0x0/0x164)
setting trigger mode 3 for irq 44 failed (uic_set_irq_type+0x0/0x164)
highmem bounce pool size: 64 pages
JFS: nTxBlock = 8192, nTxLock = 65536
SGI XFS with ACLs, security attributes, large block/inode numbers, no debug enabled
Btrfs loaded
msgmni has been set to 1488
Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253)
io scheduler noop registered
io scheduler cfq registered (default)
Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled
serial8250.0: ttyS0 at MMIO 0x4ef600300 (irq = 21) is a U6_16550A
console [ttyS0] enabled
serial8250.0: ttyS1 at MMIO 0x4ef600400 (irq = 22) is a U6_16550A
4ef600300.serial: ttyS0 at MMIO 0x4ef600300 (irq = 21) is a 16550
4ef600400.serial: ttyS1 at MMIO 0x4ef600400 (irq = 22) is a 16550
Generic non-volatile memory driver v1.1
[drm] Initialized drm 1.1.0 20060810
[drm] radeon defaulting to kernel modesetting.
[drm] radeon kernel modesetting enabled.
[drm] initializing kernel modesetting (RV530 0x1002:0x71C1 0x174B:0x0840).
[drm] register mmio base: 0x98000000
[drm] register mmio size: 65536
radeon 0000:81:00.0: Invalid ROM contents
ATOM BIOS: X1650PRO
[drm] Generation 2 PCI interface, using max accessible memory
radeon 0000:81:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
radeon 0000:81:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
[drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
[drm] Driver supports precise vblank timestamp query.
[drm] radeon: irq initialized.
[drm] Detected VRAM RAM=512M, BAR=256M
[drm] RAM width 128bits DDR
[TTM] Zone  kernel: Available graphics memory: 381008 kiB.
[TTM] Zone highmem: Available graphics memory: 1036368 kiB.
[TTM] Initializing pool allocator.
[TTM] Initializing DMA pool allocator.
[drm] radeon: 512M of VRAM memory ready
[drm] radeon: 512M of GTT memory ready.
[drm] GART: num cpu pages 131072, num gpu pages 131072
[drm] radeon: ib pool ready.
[drm] radeon: 1 quad pipes, 2 z pipes initialized.
Machine check in kernel mode.
Data Write PLB Error
Oops: Machine check, sig: 7 [#1]
Canyonlands
Modules linked in:
NIP: c03a3cd8 LR: c038b380 CTR: c03a3ca0
REGS: efff7f10 TRAP: 0214   Not tainted  (3.3.0-rc2)
MSR: 00029000 <CE,EE,ME>  CR: 447b4628  XER: 00000000
TASK = ef830000[1] 'swapper' THREAD: ef834000
GPR00: f5580000 ef835d60 ef830000 ffffffea f5580004 002fb02c 002fb02c 00000000
GPR08: 800bf41b 00020000 00040000 c06b6cd4 447b4628 8500686f 0fff9038 00000000
GPR16: 0ffc2388 0ffc2368 0ffc2388 0ffc2368 0fff9038 00000001 c0000010 0000000f
GPR24: 00000000 ef849060 c06a14c0 000000ff ffffffff ef849000 00000002 ef8ea000
NIP [c03a3cd8] rv370_pcie_gart_set_page+0x38/0x48
LR [c038b380] radeon_gart_restore+0x58/0x84
Call Trace:
[ef835d60] [ffffffff] 0xffffffff (unreliable)
[ef835d70] [c03a4c54] rv370_pcie_gart_enable+0x4c/0x230
[ef835d90] [c03ae288] r520_startup+0xc0/0x188
[ef835da0] [c03ae5d8] r520_init+0x1d0/0x234
[ef835dc0] [c0377558] radeon_device_init+0x4dc/0x5a4
[ef835df0] [c0378bc0] radeon_driver_load_kms+0xb0/0x104
[ef835e10] [c034a18c] drm_get_pci_dev+0x148/0x218
[ef835e30] [c054911c] radeon_pci_probe+0xd4/0xdc
[ef835e50] [c02fb63c] local_pci_probe+0x5c/0xac
[ef835e70] [c02fc1e4] pci_device_probe+0x68/0x94
[ef835ea0] [c03d91f0] driver_probe_device+0xe4/0x198
[ef835ec0] [c03d9314] __driver_attach+0x70/0x98
[ef835ee0] [c03d7b50] bus_for_each_dev+0x60/0x90
[ef835f10] [c03d8e48] driver_attach+0x24/0x34
[ef835f20] [c03d8a14] bus_add_driver+0xbc/0x23c
[ef835f40] [c03d992c] driver_register+0xb8/0x144
[ef835f60] [c02fc41c] __pci_register_driver+0x4c/0xc8
[ef835f80] [c034a2d8] drm_pci_init+0x7c/0xf8
[ef835fa0] [c0685030] radeon_init+0xc8/0xd0
[ef835fb0] [c0001608] do_one_initcall+0xe0/0x1b8
[ef835fe0] [c066c798] kernel_init+0x88/0x120
[ef835ff0] [c000b0f0] kernel_thread+0x4c/0x68
Instruction dump:
80030324 3860ffea 4da00020 81290328 7f844840 4d9d0020 54c6c23e 54a5c00e
60c6000c 5484103a 7cc52b78 7c802214 <7c0004ac> 7ca0252c 38600000 4e800020
---[ end trace 1871530e46d86950 ]---

Kernel panic - not syncing: Attempted to kill init!
Rebooting in 180 seconds..

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Son, 2012-02-05 at 00:38 +0100, acrux wrote:
> 
> unable to have a working radeon kms framebuffer with linux-3.3-rc2 on ppc
> video card: Radeon X1650PRO PCIE

Is this a regression? If yes, can you bisect?


> [drm] GART: num cpu pages 131072, num gpu pages 131072

The driver detects the CPU page size as 4K, is that correct?


> [drm] radeon: ib pool ready.
> [drm] radeon: 1 quad pipes, 2 z pipes initialized.
> Machine check in kernel mode.
> Data Write PLB Error
> Oops: Machine check, sig: 7 [#1]
> Canyonlands
> Modules linked in:
> NIP: c03a3cd8 LR: c038b380 CTR: c03a3ca0
> REGS: efff7f10 TRAP: 0214   Not tainted  (3.3.0-rc2)
> MSR: 00029000 <CE,EE,ME>  CR: 447b4628  XER: 00000000
> TASK = ef830000[1] 'swapper' THREAD: ef834000
> GPR00: f5580000 ef835d60 ef830000 ffffffea f5580004 002fb02c 002fb02c 00000000
> GPR08: 800bf41b 00020000 00040000 c06b6cd4 447b4628 8500686f 0fff9038 00000000
> GPR16: 0ffc2388 0ffc2368 0ffc2388 0ffc2368 0fff9038 00000001 c0000010 0000000f
> GPR24: 00000000 ef849060 c06a14c0 000000ff ffffffff ef849000 00000002 ef8ea000
> NIP [c03a3cd8] rv370_pcie_gart_set_page+0x38/0x48
> LR [c038b380] radeon_gart_restore+0x58/0x84
> Call Trace:
> [ef835d60] [ffffffff] 0xffffffff (unreliable)
> [ef835d70] [c03a4c54] rv370_pcie_gart_enable+0x4c/0x230
> [ef835d90] [c03ae288] r520_startup+0xc0/0x188
> [ef835da0] [c03ae5d8] r520_init+0x1d0/0x234

Not sure what exactly 'Data Write PLB Error' means, but it looks like
the problem occurs when the card's VRAM is first accessed for setting a
GART page table entry. 


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

On Tue, 07 Feb 2012 18:32:44 +0100
Michel Dänzer <michel@daenzer.net> wrote:

> On Son, 2012-02-05 at 00:38 +0100, acrux wrote:
> > 
> > unable to have a working radeon kms framebuffer with linux-3.3-rc2
> > on ppc video card: Radeon X1650PRO PCIE
> 
> Is this a regression? If yes, can you bisect?
> 

not a regression, i didn't find a working kernel release

> 
> > [drm] GART: num cpu pages 131072, num gpu pages 131072
> 
> The driver detects the CPU page size as 4K, is that correct?
> 
> 

it's right, 4k page size

Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
videocards and both them are not able to boot with radeonkms.
Modern PCI-E videocards are not recognized by the old linux framebuffer
subsystem and they solely can be managed by the new KMS frame buffer
that doesn't work properly on Power Architecture. Anyway, YDL
Powerstation can fallback to use the old OpenFirmware
frame buffer.
KMS porting to Power Architecture machines with PCIE is it only an
exercise or someone is also able to test them?
Because i can understand that the userbase is non-existent and the
dri-developers don't have these "rare" machines.



[1] YDL Powerstation, Acube Sam460ex


cheers,
--nico
-- 
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: 
> 
> Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> videocards and both them are not able to boot with radeonkms.
> Modern PCI-E videocards are not recognized by the old linux framebuffer
> subsystem and they solely can be managed by the new KMS frame buffer
> that doesn't work properly on Power Architecture.

That's too broad a statement, it works fine on other PowerPC machines
(PowerMacs, some embedded boards).

It looks like there's a problem with accessing the PCIe device memory,
and at this point it's not even 100% clear that this is due to a problem
in the driver, as opposed to e.g. in the platform code.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Son, 2012-02-12 at 11:00 +0100, Michel Dänzer wrote: 
> On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: 
> > 
> > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > videocards and both them are not able to boot with radeonkms.
> > Modern PCI-E videocards are not recognized by the old linux framebuffer
> > subsystem and they solely can be managed by the new KMS frame buffer
> > that doesn't work properly on Power Architecture.
> 
> That's too broad a statement, it works fine on other PowerPC machines
> (PowerMacs, some embedded boards).
> 
> It looks like there's a problem with accessing the PCIe device memory,
> and at this point it's not even 100% clear that this is due to a problem
> in the driver, as opposed to e.g. in the platform code.

So, maybe you should bring this up on the linuxppc-dev list at
lists.ozlabs.org . The folks there might be able to help narrow down the
problem.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

On Sun, 12 Feb 2012 11:00:43 +0100
Michel Dänzer <michel@daenzer.net> wrote:

> On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: 
> > 
> > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > videocards and both them are not able to boot with radeonkms.
> > Modern PCI-E videocards are not recognized by the old linux framebuffer
> > subsystem and they solely can be managed by the new KMS frame buffer
> > that doesn't work properly on Power Architecture.
> 
> That's too broad a statement, it works fine on other PowerPC machines
> (PowerMacs, some embedded boards).
> 

hi Michel,
thanks a lot for your help, i really appreciate it.

If you say they were tested on real Power Architecture boards with PCIE
videocards thus it is reassuring... and i'm happy that you understand
my previus assertion wasn't affected by malevolence or sarcasm. Indeed
i'm also a bit troubled 'n frustrated thinking that next release of
mesa 'll do extend use of llvm (that doesn't work properly on linuxppc
and totally untested on linuxppc64)

Btw, to sum up the list of Power Architecture machines with PCIE  that
aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac
Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last
two, on present evidence (my attempts), aren't able to boot up if
bootkernel has kms enabled. Furthermore the first tree ones can
fallback to the legacy OpenFirmware framebuffer and safely get a
console.

> It looks like there's a problem with accessing the PCIe device memory,
> and at this point it's not even 100% clear that this is due to a problem
> in the driver, as opposed to e.g. in the platform code.
> 

it could be the right problem and i've CC BenH that has a better global
perspective.

all the best,
--nico
-- 
acrux <acrux@cruxppc.org>

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Benjamin Herrenschmidt]

On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> On Sun, 12 Feb 2012 11:00:43 +0100
> Michel Dänzer <michel@daenzer.net> wrote:
> 
> > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: 
> > > 
> > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > > videocards and both them are not able to boot with radeonkms.
> > > Modern PCI-E videocards are not recognized by the old linux framebuffer
> > > subsystem and they solely can be managed by the new KMS frame buffer
> > > that doesn't work properly on Power Architecture.
> > 
> > That's too broad a statement, it works fine on other PowerPC machines
> > (PowerMacs, some embedded boards).
> > 
> 
> hi Michel,
> thanks a lot for your help, i really appreciate it.
> 
> If you say they were tested on real Power Architecture boards with PCIE
> videocards thus it is reassuring... and i'm happy that you understand
> my previus assertion wasn't affected by malevolence or sarcasm. Indeed
> i'm also a bit troubled 'n frustrated thinking that next release of
> mesa 'll do extend use of llvm (that doesn't work properly on linuxppc
> and totally untested on linuxppc64)
> 
> Btw, to sum up the list of Power Architecture machines with PCIE  that
> aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac
> Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last
> two, on present evidence (my attempts), aren't able to boot up if
> bootkernel has kms enabled.

Which radeon card, kernel log please ? I've successfully booted various
reasonably modern radeons on these. I've also used gnome3 with GL
acceleration etc... on some of these. Granted that was a few month ago
so it's possible that something regressed.

>  Furthermore the first tree ones can
> fallback to the legacy OpenFirmware framebuffer and safely get a
> console.
> 
> > It looks like there's a problem with accessing the PCIe device memory,
> > and at this point it's not even 100% clear that this is due to a problem
> > in the driver, as opposed to e.g. in the platform code.
> > 
> 
> it could be the right problem and i've CC BenH that has a better global
> perspective.

Can you give me more data about the problem please ? It could be a
recent regression or some setup problem.

Also I've noticed on the PowerStation some issues where heavy DMA use by
a video card will eventually lock up the system. From what I can tell
this is an issue with the northbridge, though a Quad G5 with the same
bridge (tho not quite the same revision) doesn't show the problem. Could
be a configuration issue.

Cheers,
Ben.



_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Mit, 2012-02-15 at 13:50 +1100, Benjamin Herrenschmidt wrote: 
> On Wed, 2012-02-15 at 03:23 +0100, acrux wrote:
> > On Sun, 12 Feb 2012 11:00:43 +0100
> > Michel Dänzer <michel@daenzer.net> wrote:
> > 
> > > On Sam, 2012-02-11 at 21:00 +0100, acrux wrote: 
> > > > 
> > > > Just a curiosity, i've only two powerpc machines[1] equipped with PCIE
> > > > videocards and both them are not able to boot with radeonkms.
> > > > Modern PCI-E videocards are not recognized by the old linux framebuffer
> > > > subsystem and they solely can be managed by the new KMS frame buffer
> > > > that doesn't work properly on Power Architecture.
> > > 
> > > That's too broad a statement, it works fine on other PowerPC machines
> > > (PowerMacs, some embedded boards).
> > > 
> > 
> > hi Michel,
> > thanks a lot for your help, i really appreciate it.
> > 
> > If you say they were tested on real Power Architecture boards with PCIE
> > videocards thus it is reassuring... and i'm happy that you understand
> > my previus assertion wasn't affected by malevolence or sarcasm. Indeed
> > i'm also a bit troubled 'n frustrated thinking that next release of
> > mesa 'll do extend use of llvm (that doesn't work properly on linuxppc
> > and totally untested on linuxppc64)

I don't see any reason to worry yet. LLVM is still completely optional
in Mesa 8.0, and if you're worrying about the upcoming use of LLVM in
the drivers for newer Radeons, I don't think the current problems in the
LLVM usage of llvmpipe/draw on PPC will necessarily translate to that,
as I suspect at least some of the issues are specific to the LLVM PPC
backend, which won't be used in that case.


> > Btw, to sum up the list of Power Architecture machines with PCIE  that
> > aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac
> > Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last
> > two, on present evidence (my attempts), aren't able to boot up if
> > bootkernel has kms enabled.
> 
> Which radeon card, kernel log please ?

See
http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html (start of this thread) and http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html .


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Benjamin Herrenschmidt]

On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote:

> > > Btw, to sum up the list of Power Architecture machines with PCIE  that
> > > aim to be a desktop/workstation: Apple iMac G5 (iSight), Apple PowerMac
> > > Quad G5, YDL Powerstation 2x970MP and Acube Sam460ex . And the last
> > > two, on present evidence (my attempts), aren't able to boot up if
> > > bootkernel has kms enabled.
> > 
> > Which radeon card, kernel log please ?
> 
> See
> http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html (start of this thread) and http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html .

Ok, so for the 460EX, I am not surprised things aren't working with KMS
& DRI2... the 460 is not cache coherent, and this is not handled by TTM
as far as I can tell.

The second case with no firmware is a bit more surprising, looks like
something bad happened on the PCI express bus or the kernel tried to
access something that the card rejected (target abort or PCIe equivalent
most likely), thus triggering a PLB error . That could be investigated a
bit more.

Note that you say this is smoe kind of "SAM460EX" card... but it claims
to be a Canyonlands in the device-tree... is that expected or do we have
yet another case of a vendor claiming to be the eval board they based
their design upon and generally screwing up in a major way ? IE. does it
indeed work with an -identical- device-tree to a canyonland and no
patches added to the machine support at all ?

Cheers,
Ben.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[acrux]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Thu, 16 Feb 2012 07:28:10 +1100
Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:

> On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote:
> 
> > > > Btw, to sum up the list of Power Architecture machines with
> > > > PCIE  that aim to be a desktop/workstation: Apple iMac G5
> > > > (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and
> > > > Acube Sam460ex . And the last two, on present evidence (my
> > > > attempts), aren't able to boot up if bootkernel has kms enabled.
> > > 
> > > Which radeon card, kernel log please ?
> > 
> > See
> > http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html
> > (start of this thread) and
> > http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html .
> 
> Ok, so for the 460EX, I am not surprised things aren't working with
> KMS & DRI2... the 460 is not cache coherent, and this is not handled
> by TTM as far as I can tell.
> 
> The second case with no firmware is a bit more surprising, looks like
> something bad happened on the PCI express bus or the kernel tried to
> access something that the card rejected (target abort or PCIe
> equivalent most likely), thus triggering a PLB error . That could be
> investigated a bit more.
> 
> Note that you say this is smoe kind of "SAM460EX" card... but it
> claims to be a Canyonlands in the device-tree... is that expected or
> do we have yet another case of a vendor claiming to be the eval board
> they based their design upon and generally screwing up in a major
> way ? IE. does it indeed work with an -identical- device-tree to a
> canyonland and no patches added to the machine support at all ?
> 

Guys, thank you very much for your replies,

i know it's a very common (bad) scenario, thanks for your opinion i
already informed the vendor to suggest a _real_ linux kernel
porting and i'll do it again.

Anyway after nearly ten years, due a lack in resources, i'm sadly going
to suspend the CRUX PPC project and my activism pro free
software thus i'm unable to follow these debug. I'll hold on to me
the only YDL Powerstation then from the next weeks i'll can only follow
trying to help in debug [1] on this specific machine.  

[1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html


all the best and again THANKS for all your work,
- --nico
- -- 
GNU/Linux on Power Architecture
CRUX PPC - http://cruxppc.org/

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.18 (GNU/Linux)

iEYEARECAAYFAk88VnEACgkQxq34tDeO7Lg1NQCgkcHSqVxtJ2pfw2x+fyyuTLpx
llMAn1h0szhNtxusxjCsBzjj5LQ/v6VZ
=Uszy
-----END PGP SIGNATURE-----

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Don, 2012-02-16 at 01:05 +0000, acrux wrote: 
> On Thu, 16 Feb 2012 07:28:10 +1100
> Benjamin Herrenschmidt <benh@kernel.crashing.org> wrote:
> 
> > On Wed, 2012-02-15 at 08:39 +0100, Michel Dänzer wrote:
> > 
> > > > > Btw, to sum up the list of Power Architecture machines with
> > > > > PCIE  that aim to be a desktop/workstation: Apple iMac G5
> > > > > (iSight), Apple PowerMac Quad G5, YDL Powerstation 2x970MP and
> > > > > Acube Sam460ex . And the last two, on present evidence (my
> > > > > attempts), aren't able to boot up if bootkernel has kms enabled.
> > > > 
> > > > Which radeon card, kernel log please ?
> > > 
> > > See
> > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018792.html
> > > (start of this thread) and
> > > http://lists.freedesktop.org/archives/dri-devel/2012-February/018791.html .
> > 
> > Ok, so for the 460EX, I am not surprised things aren't working with
> > KMS & DRI2... the 460 is not cache coherent, and this is not handled
> > by TTM as far as I can tell.
> > 
> > The second case with no firmware is a bit more surprising, looks like
> > something bad happened on the PCI express bus or the kernel tried to
> > access something that the card rejected (target abort or PCIe
> > equivalent most likely), thus triggering a PLB error . That could be
> > investigated a bit more.

AFAICT in both cases the immediate problem is the PLB error on first
access to VRAM, indicating some kind of problem with ioremap_wc() or
generally PCIe device memory access.


> Anyway after nearly ten years, due a lack in resources, i'm sadly going
> to suspend the CRUX PPC project and my activism pro free
> software thus i'm unable to follow these debug. I'll hold on to me
> the only YDL Powerstation then from the next weeks i'll can only follow
> trying to help in debug [1] on this specific machine.  
> 
> [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html

For that one, I'd try adding some more debugging output to
radeon_get_bios() to find out which method it ends up using to retrieve
the ROM contents, and why it doesn't look like it's an ATOM BIOS.

Does the same card work in an x86 machine?


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Benjamin Herrenschmidt]

On Thu, 2012-02-16 at 08:50 +0100, Michel Dänzer wrote:
> > > The second case with no firmware is a bit more surprising, looks like
> > > something bad happened on the PCI express bus or the kernel tried to
> > > access something that the card rejected (target abort or PCIe
> > > equivalent most likely), thus triggering a PLB error . That could be
> > > investigated a bit more.
> 
> AFAICT in both cases the immediate problem is the PLB error on first
> access to VRAM, indicating some kind of problem with ioremap_wc() or
> generally PCIe device memory access.

I think the problem here is more along the lines of >32-bit physical
memory and ttm screwing up the physical addresses before mapping the
vram object.

Tony (CC) has some patches to address that part (for use with a 476
which is cache coherent, we got evergreen working on that).

I think he hasn't yet "polished" the patches enough (ie fixed all the
drivers for the change in types) but basically, quite a few places in
there need to store physical addresses in resource_size_t instead of
long's.

> > Anyway after nearly ten years, due a lack in resources, i'm sadly going
> > to suspend the CRUX PPC project and my activism pro free
> > software thus i'm unable to follow these debug. I'll hold on to me
> > the only YDL Powerstation then from the next weeks i'll can only follow
> > trying to help in debug [1] on this specific machine.  
> > 
> > [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html
> 
> For that one, I'd try adding some more debugging output to
> radeon_get_bios() to find out which method it ends up using to retrieve
> the ROM contents, and why it doesn't look like it's an ATOM BIOS.

Is it an Apple card or an x86 card ? Apple cards don't have the BIOS in
the right place unfortunately.

Cheers,
Ben.

> Does the same card work in an x86 machine?
> 
> 
> -- 
> Earthling Michel Dänzer           |                   http://www.amd.com
> Libre software enthusiast         |          Debian, X and DRI developer
> 
> 

_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Michel Dänzer]

On Don, 2012-02-16 at 19:02 +1100, Benjamin Herrenschmidt wrote: 
> On Thu, 2012-02-16 at 08:50 +0100, Michel Dänzer wrote:
> > > > The second case with no firmware is a bit more surprising, looks like
> > > > something bad happened on the PCI express bus or the kernel tried to
> > > > access something that the card rejected (target abort or PCIe
> > > > equivalent most likely), thus triggering a PLB error . That could be
> > > > investigated a bit more.
> > 
> > AFAICT in both cases the immediate problem is the PLB error on first
> > access to VRAM, indicating some kind of problem with ioremap_wc() or
> > generally PCIe device memory access.
> 
> I think the problem here is more along the lines of >32-bit physical
> memory and ttm screwing up the physical addresses before mapping the
> vram object.
> 
> Tony (CC) has some patches to address that part (for use with a 476
> which is cache coherent, we got evergreen working on that).
> 
> I think he hasn't yet "polished" the patches enough (ie fixed all the
> drivers for the change in types) but basically, quite a few places in
> there need to store physical addresses in resource_size_t instead of
> long's.

I see, thanks.


> > > Anyway after nearly ten years, due a lack in resources, i'm sadly going
> > > to suspend the CRUX PPC project and my activism pro free
> > > software thus i'm unable to follow these debug. I'll hold on to me
> > > the only YDL Powerstation then from the next weeks i'll can only follow
> > > trying to help in debug [1] on this specific machine.  
> > > 
> > > [1]http://lists.freedesktop.org/archives/dri-devel/2012-January/018575.html
> > 
> > For that one, I'd try adding some more debugging output to
> > radeon_get_bios() to find out which method it ends up using to retrieve
> > the ROM contents, and why it doesn't look like it's an ATOM BIOS.
> 
> Is it an Apple card or an x86 card ? Apple cards don't have the BIOS in
> the right place unfortunately.

I don't think there ever were any Mac Editions of FireGL cards, and if
it wasn't an x86 card, I'd expect different error messages.


-- 
Earthling Michel Dänzer           |                   http://www.amd.com
Libre software enthusiast         |          Debian, X and DRI developer
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

Re: linux-3.3-rc2 and radeon kms failure on ppc32 with Radeon X1650PRO pcie

[Benjamin Herrenschmidt]

On Thu, 2012-02-16 at 09:26 +0100, Michel Dänzer wrote:
> > > For that one, I'd try adding some more debugging output to
> > > radeon_get_bios() to find out which method it ends up using to
> retrieve
> > > the ROM contents, and why it doesn't look like it's an ATOM BIOS.
> > 
> > Is it an Apple card or an x86 card ? Apple cards don't have the BIOS
> in
> > the right place unfortunately.
> 
> I don't think there ever were any Mac Editions of FireGL cards, and if
> it wasn't an x86 card, I'd expect different error messages. 

There is -one- Mac edition of r5xx actually :-) I have one of them...
It's PCIe and came as an option for the PCIe latest generation G5s. At
some point Alex gave me a BIOS ROM file that we could use to get the
ATOM stuff from, but we never quite sorted out distribution and so never
added mechanisms to use it from the driver.

Cheers,
Ben.


_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel