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..
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..
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.
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
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.
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.
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
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.
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 .
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.
-----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/
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?
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
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.
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@lists.freedesktop.org
-
acrux -
Benjamin Herrenschmidt -
Michel Dänzer