(Send similar post to LKML / linux.kernel but no responses there yet)
Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
Debian stable. Builded with make-kpkg using gcc 4.4.5
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
With radeon + kms the bug happens around 1 in 3 boot ups, right after the radeon is enabled (with slub debugging) or later with no debug (few seconds later or on shutdown esp. in rmmod).
When disabling radeon and KMS the bug was not seen;
Please fix this bug :) What to test to help fixing it?
Interesting part of the messages linked above is:
[ 94.401991] fb0: radeondrmfb frame buffer device [ 94.401992] drm: registered panic notifier [ 94.402033] [drm] Initialized radeon 2.11.0 20080528 for 0000:01:00.0 on minor 0 [ 94.402921] ============================================================================= [ 94.402961] BUG kmalloc-16: Poison overwritten [ 94.402982] ----------------------------------------------------------------------------- [ 94.402983] [ 94.403025] INFO: 0xffff880137dbbc38-0xffff880137dbbc3b. First byte 0x0 instead of 0x6b [ 94.403066] INFO: Allocated in drm_vblank_init+0x139/0x260 [drm] age=253 cpu=3 pid=535 [ 94.403103] set_track+0x58/0x100 [ 94.403119] alloc_debug_processing+0x160/0x170 [ 94.403140] __slab_alloc+0x26d/0x440 [ 94.403160] drm_vblank_init+0x139/0x260 [drm] [ 94.403182] drm_debugfs_create_files+0xcb/0x1a0 [drm] [ 94.403208] drm_vblank_init+0x139/0x260 [drm] [ 94.403228] __kmalloc+0x100/0x180 [ 94.403247] drm_vblank_init+0x139/0x260 [drm] [ 94.403276] radeon_irq_kms_init+0x6d/0x160 [radeon] [ 94.403303] evergreen_init+0x11c/0x2a0 [radeon] [ 94.403337] radeon_device_init+0x3c9/0x470 [radeon] [ 94.403367] radeon_driver_load_kms+0xad/0x160 [radeon] [ 94.403394] drm_get_pci_dev+0x198/0x2c0 [drm] [ 94.403416] local_pci_probe+0x55/0xd0 [ 94.403433] pci_device_probe+0x10a/0x130 [ 94.403453] driver_sysfs_add+0x72/0xa0 [ 94.403474] INFO: Freed in drm_vblank_cleanup+0x78/0x90 [drm] age=235 cpu=0 pid=535 [ 94.403508] set_track+0x58/0x100 [ 94.403524] free_debug_processing+0x1f3/0x240 [ 94.403545] __slab_free+0x1a6/0x2b0 [ 94.403562] native_read_tsc+0x2/0x20 [ 94.403580] delay_tsc+0x42/0x80 [ 94.403598] drm_vblank_cleanup+0x78/0x90 [drm] [ 94.403625] radeon_irq_kms_fini+0xd/0x60 [radeon] [ 94.403651] evergreen_init+0x289/0x2a0 [radeon] [ 94.403677] radeon_device_init+0x3c9/0x470 [radeon] [ 94.403704] radeon_driver_load_kms+0xad/0x160 [radeon] [ 94.403731] drm_get_pci_dev+0x198/0x2c0 [drm] [ 94.403751] local_pci_probe+0x55/0xd0 [ 94.403772] pci_device_probe+0x10a/0x130 [ 94.403791] driver_sysfs_add+0x72/0xa0 [ 94.404806] driver_probe_device+0x8e/0x1b0 [ 94.405782] __driver_attach+0x93/0xa0 [ 94.406031] INFO: Slab 0xffffea0004df6e80 objects=23 used=23 fp=0x (null) flags=0x200000000004080 [ 94.406031] INFO: Object 0xffff880137dbbc38 @offset=7224 fp=0xffff880137dbb830 [ 94.406031] [ 94.406031] Bytes b4 0xffff880137dbbc28: 06 0e ff ff 00 00 00 00 5a 5a 5a 5a 5a 5a 5a 5a ..��....ZZZZZZZZ [ 94.406031] Object 0xffff880137dbbc38: 00 00 00 00 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b 6b a5 ....kkkkkkkkkkk� [ 94.406031] Redzone 0xffff880137dbbc48: bb bb bb bb bb bb bb bb �������� [ 94.406031] Padding 0xffff880137dbbd88: 5a 5a 5a 5a 5a 5a 5a 5a ZZZZZZZZ [ 94.406031] Pid: 466, comm: udevd Not tainted 3.1.4-norm007+dbg #1 [ 94.406031] Call Trace: [ 94.406031] [] ? check_bytes_and_report+0x110/0x150 [ 94.406031] [] ? check_object+0x1fe/0x250 [ 94.406031] [] ? shmem_symlink+0xd4/0x220 [ 94.406031] [] ? shmem_symlink+0xd4/0x220 [ 94.406031] [] ? alloc_debug_processing+0xee/0x170 [ 94.406031] [] ? __slab_alloc+0x26d/0x440 [ 94.406031] [] ? shmem_symlink+0xd4/0x220 [ 94.406031] [] ? inode_init_always+0xfc/0x1b0 [ 94.406031] [] ? alloc_inode+0x32/0x90 [ 94.406031] [] ? shmem_symlink+0xd4/0x220 [ 94.406031] [] ? __kmalloc_track_caller+0xf8/0x180 [ 94.406031] [] ? kmemdup+0x27/0x60 [ 94.406031] [] ? shmem_symlink+0xd4/0x220 [ 94.406031] [] ? vfs_symlink+0x87/0xa0 [ 94.406031] [] ? sys_symlinkat+0xdc/0xf0 [ 94.406031] [] ? system_call_fastpath+0x16/0x1b [ 94.406031] FIX kmalloc-16: Restoring 0xffff880137dbbc38-0xffff880137dbbc3b=0x6b
On Tue, Dec 13, 2011 at 10:26:15PM +0100, batouzo wrote:
(Send similar post to LKML / linux.kernel but no responses there yet)
Hello, we where building 3.1.4 kernel when we noticed BUG()s on bootup.
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
Debian stable. Builded with make-kpkg using gcc 4.4.5
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
With radeon + kms the bug happens around 1 in 3 boot ups, right after the radeon is enabled (with slub debugging) or later with no debug (few seconds later or on shutdown esp. in rmmod).
When disabling radeon and KMS the bug was not seen;
Please fix this bug :) What to test to help fixing it?
Interesting part of the messages linked above is:
Do you boot your kernel with kexec ? Does the patch help :
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w...
If not please open bug on bugs.freedesktop.org against radeon driver.
Cheers, Jerome
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
On Tue, Dec 13, 2011 at 6:33 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
Note that this patch might also help non kexec case.
Cheers, Jerome
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Tue, Dec 13, 2011 at 6:33 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
Note that this patch might also help non kexec case.
Cheers, Jerome
Oh and try booting with radeon.no_wb=1
Cheers, Jerome
On 12/14/2011 12:47 AM, Jerome Glisse wrote:
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Tue, Dec 13, 2011 at 6:33 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
Note that this patch might also help non kexec case.
Cheers, Jerome
Oh and try booting with radeon.no_wb=1
Cheers, Jerome
Using that patch on 3.1.4 results in locking for 60 seconds on startup, since it is now looking for firmware.
This wait was not present without that patch.
This looks familiar, like the 60 second wait when using netconsole caused by netconsole attempt to look for NIC card firmware too early (when / is not really mounted, just initramfs).
I will report soon does it fix the crash;
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
[ 1.386916] pci 0000:03:06.0: calling quirk_usb_early_handoff+0x0/0x575 [ 1.386918] pci 0000:03:06.0: calling pci_fixup_video+0x0/0xa6 [ 1.386925] PCI: CLS 64 bytes, default 64 [ 1.387113] Unpacking initramfs... [ 1.569824] Freeing initrd memory: 9080k freed [ 1.572659] pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55 [ 1.572906] pci 0000:00:00.2: irq 72 for MSI/MSI-X [ 1.573088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 [ 1.634353] AMD-Vi: Lazy IO/TLB flushing enabled [ 1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 1.634421] Placing 64MB software IO TLB between ffff8800b9a5e000 - ffff8800bda5e000 [ 1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000 [ 1.639283] audit: initializing netlink socket (disabled) [ 1.639353] type=2000 audit(1323849178.636:1): initialized [ 1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.663115] VFS: Disk quotas dquot_6.5.2 [ 1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.663769] msgmni has been set to 7808 [ 1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.664353] io scheduler noop registered [ 1.664385] io scheduler deadline registered [ 1.664684] io scheduler cfq registered (default) [ 1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.667276] [drm] Initialized drm 1.1.0 20060810 [ 1.667404] [drm] radeon defaulting to kernel modesetting. [ 1.667436] [drm] radeon kernel modesetting enabled. [ 1.667559] radeon 0000:01:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 [ 1.667594] radeon 0000:01:00.0: setting latency timer to 64 [ 1.668367] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1458:0x21F1). [ 1.668455] [drm] register mmio base: 0xFEA20000 [ 1.668487] [drm] register mmio size: 131072 [ 1.668685] ATOM BIOS: GV [ 1.668806] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) [ 1.668842] radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF [ 1.676059] [drm] Detected VRAM RAM=512M, BAR=256M [ 1.676094] [drm] RAM width 64bits DDR [ 1.676270] [TTM] Zone kernel: Available graphics memory: 1998922 kiB. [ 1.676303] [TTM] Initializing pool allocator. [ 1.676440] [drm] radeon: 512M of VRAM memory ready [ 1.676476] [drm] radeon: 512M of GTT memory ready. [ 1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.676655] [drm] Driver supports precise vblank timestamp query. [ 1.676759] radeon 0000:01:00.0: irq 73 for MSI/MSI-X [ 1.676763] radeon 0000:01:00.0: radeon: using MSI. [ 1.676903] [drm] radeon: irq initialized. [ 1.676941] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 1.677602] [drm] Loading CEDAR Microcode [ 2.636773] Refined TSC clocksource calibration: 3110.391 MHz. [ 2.636809] Switching to clocksource tsc [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 62.347222] radeon 0000:01:00.0: disabling GPU acceleration [ 62.348334] radeon 0000:01:00.0: ffff8801364be9a0 unpin not necessary [ 62.348367] radeon 0000:01:00.0: ffff8801364be9a0 unpin not necessary [ 62.348452] failed to evaluate ATIF got AE_BAD_PARAMETER [ 62.351087] [drm] Radeon Display Connectors [ 62.351120] [drm] Connector 0: [ 62.351151] [drm] DisplayPort [ 62.351182] [drm] HPD4 [ 62.351214] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 62.351249] [drm] Encoders: [ 62.351280] [drm] DFP1: INTERNAL_UNIPHY1 [ 62.351311] [drm] Connector 1: [ 62.351343] [drm] HDMI-A [ 62.351374] [drm] HPD2 [ 62.351405] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 62.351440] [drm] Encoders: [ 62.351471] [drm] DFP2: INTERNAL_UNIPHY1 [ 62.351502] [drm] Connector 2: [ 62.351533] [drm] HDMI-A [ 62.351564] [drm] HPD1 [ 62.351596] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 62.351630] [drm] Encoders: [ 62.351661] [drm] DFP3: INTERNAL_UNIPHY [ 62.351693] [drm] Connector 3: [ 62.351724] [drm] VGA [ 62.351756] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
On Wed, Dec 14, 2011 at 2:00 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:47 AM, Jerome Glisse wrote:
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Tue, Dec 13, 2011 at 6:33 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
Note that this patch might also help non kexec case.
Cheers, Jerome
Oh and try booting with radeon.no_wb=1
Cheers, Jerome
Using that patch on 3.1.4 results in locking for 60 seconds on startup, since it is now looking for firmware.
This wait was not present without that patch.
This looks familiar, like the 60 second wait when using netconsole caused by netconsole attempt to look for NIC card firmware too early (when / is not really mounted, just initramfs).
I will report soon does it fix the crash;
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Alex
[ 1.386916] pci 0000:03:06.0: calling quirk_usb_early_handoff+0x0/0x575 [ 1.386918] pci 0000:03:06.0: calling pci_fixup_video+0x0/0xa6 [ 1.386925] PCI: CLS 64 bytes, default 64 [ 1.387113] Unpacking initramfs... [ 1.569824] Freeing initrd memory: 9080k freed [ 1.572659] pci 0000:00:00.2: PCI INT A -> GSI 55 (level, low) -> IRQ 55 [ 1.572906] pci 0000:00:00.2: irq 72 for MSI/MSI-X [ 1.573088] AMD-Vi: Enabling IOMMU at 0000:00:00.2 cap 0x40 [ 1.634353] AMD-Vi: Lazy IO/TLB flushing enabled [ 1.634387] PCI-DMA: Using software bounce buffering for IO (SWIOTLB) [ 1.634421] Placing 64MB software IO TLB between ffff8800b9a5e000 - ffff8800bda5e000 [ 1.634456] software IO TLB at phys 0xb9a5e000 - 0xbda5e000 [ 1.639283] audit: initializing netlink socket (disabled) [ 1.639353] type=2000 audit(1323849178.636:1): initialized [ 1.648286] HugeTLB registered 2 MB page size, pre-allocated 0 pages [ 1.663115] VFS: Disk quotas dquot_6.5.2 [ 1.663309] Dquot-cache hash table entries: 512 (order 0, 4096 bytes) [ 1.663769] msgmni has been set to 7808 [ 1.664318] Block layer SCSI generic (bsg) driver version 0.4 loaded (major 253) [ 1.664353] io scheduler noop registered [ 1.664385] io scheduler deadline registered [ 1.664684] io scheduler cfq registered (default) [ 1.665691] Serial: 8250/16550 driver, 4 ports, IRQ sharing enabled [ 1.667276] [drm] Initialized drm 1.1.0 20060810 [ 1.667404] [drm] radeon defaulting to kernel modesetting. [ 1.667436] [drm] radeon kernel modesetting enabled. [ 1.667559] radeon 0000:01:00.0: PCI INT A -> GSI 24 (level, low) -> IRQ 24 [ 1.667594] radeon 0000:01:00.0: setting latency timer to 64 [ 1.668367] [drm] initializing kernel modesetting (CEDAR 0x1002:0x68F9 0x1458:0x21F1). [ 1.668455] [drm] register mmio base: 0xFEA20000 [ 1.668487] [drm] register mmio size: 131072 [ 1.668685] ATOM BIOS: GV [ 1.668806] radeon 0000:01:00.0: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used) [ 1.668842] radeon 0000:01:00.0: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF [ 1.676059] [drm] Detected VRAM RAM=512M, BAR=256M [ 1.676094] [drm] RAM width 64bits DDR [ 1.676270] [TTM] Zone kernel: Available graphics memory: 1998922 kiB. [ 1.676303] [TTM] Initializing pool allocator. [ 1.676440] [drm] radeon: 512M of VRAM memory ready [ 1.676476] [drm] radeon: 512M of GTT memory ready. [ 1.676621] [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). [ 1.676655] [drm] Driver supports precise vblank timestamp query. [ 1.676759] radeon 0000:01:00.0: irq 73 for MSI/MSI-X [ 1.676763] radeon 0000:01:00.0: radeon: using MSI. [ 1.676903] [drm] radeon: irq initialized. [ 1.676941] [drm] GART: num cpu pages 131072, num gpu pages 131072 [ 1.677602] [drm] Loading CEDAR Microcode [ 2.636773] Refined TSC clocksource calibration: 3110.391 MHz. [ 2.636809] Switching to clocksource tsc [ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 62.347222] radeon 0000:01:00.0: disabling GPU acceleration [ 62.348334] radeon 0000:01:00.0: ffff8801364be9a0 unpin not necessary [ 62.348367] radeon 0000:01:00.0: ffff8801364be9a0 unpin not necessary [ 62.348452] failed to evaluate ATIF got AE_BAD_PARAMETER [ 62.351087] [drm] Radeon Display Connectors [ 62.351120] [drm] Connector 0: [ 62.351151] [drm] DisplayPort [ 62.351182] [drm] HPD4 [ 62.351214] [drm] DDC: 0x6440 0x6440 0x6444 0x6444 0x6448 0x6448 0x644c 0x644c [ 62.351249] [drm] Encoders: [ 62.351280] [drm] DFP1: INTERNAL_UNIPHY1 [ 62.351311] [drm] Connector 1: [ 62.351343] [drm] HDMI-A [ 62.351374] [drm] HPD2 [ 62.351405] [drm] DDC: 0x6460 0x6460 0x6464 0x6464 0x6468 0x6468 0x646c 0x646c [ 62.351440] [drm] Encoders: [ 62.351471] [drm] DFP2: INTERNAL_UNIPHY1 [ 62.351502] [drm] Connector 2: [ 62.351533] [drm] HDMI-A [ 62.351564] [drm] HPD1 [ 62.351596] [drm] DDC: 0x6450 0x6450 0x6454 0x6454 0x6458 0x6458 0x645c 0x645c [ 62.351630] [drm] Encoders: [ 62.351661] [drm] DFP3: INTERNAL_UNIPHY [ 62.351693] [drm] Connector 3: [ 62.351724] [drm] VGA [ 62.351756] [drm] DDC: 0x6430 0x6430 0x6434 0x6434 0x6438 0x6438 0x643c 0x643c
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 12/14/2011 03:10 PM, Alex Deucher wrote:
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
[ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 62.347222] radeon 0000:01:00.0: disabling GPU acceleration
On Wed, Dec 14, 2011 at 11:32 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
Alex
[ 62.347154] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 62.347189] [drm:evergreen_startup] *ERROR* Failed to load firmware! [ 62.347222] radeon 0000:01:00.0: disabling GPU acceleration
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
Ok I see.
Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)?
On Wed, Dec 14, 2011 at 12:12 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
Ok I see.
Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)?
You can download/compare with my tree: http://people.freedesktop.org/~agd5f/radeon_ucode/
Alex
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 12/14/2011 06:21 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 12:12 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
Ok I see.
Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)?
You can download/compare with my tree: http://people.freedesktop.org/~agd5f/radeon_ucode/
Alex
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Thanks.
Is this firmware a closed source binary blob? Or open source, only uploaded to the card on init?
Who develops it / where to get the source code, and how to build that file from sources?
This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?)
On Wed, Dec 14, 2011 at 12:27 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 06:21 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 12:12 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 05:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 11:32 AM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 03:10 PM, Alex Deucher wrote:
> Though, the 60 second delay may influence the rarity of hitting BUG (it > was the case with netconsole's 60sec wait). > Should I just remove loading of this firmware? > Make sure the ucode is available in your initrd or kernel image or filesystem depending on how you are loading the driver. The driver has much more limited functionality without the ucode (no acceleration support, no interrupt support). You may not hit the bug at all due to the reduced functionality.
Actually, where is that file? Can't find CEDAR_pfp.bin or even any "*CEDAR*" in entire filesystem where I build the kernel.
Also I tried CONFIG_FIRMWARE_IN_KERNEL=y but it didn't helped, hm.
You need to grab them from here: http://git.kernel.org/?p=linux/kernel/git/dwmw2/linux-firmware.git
Ok I see.
Is there a pubkey signed version of that available, or what is the safe-download procedure (as with kernl.org .tar's + .sign for kernels)?
You can download/compare with my tree: http://people.freedesktop.org/~agd5f/radeon_ucode/
Alex
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Thanks.
Is this firmware a closed source binary blob? Or open source, only uploaded to the card on init?
It's closed source and only uploaded to the card on init.
Who develops it / where to get the source code, and how to build that file from sources?
AMD develops and releases the ucode images. No source is available.
This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?)
The ucode is volatile and is lost on reboot. The different ucode images are used for different things. The PFP and ME ucode images provide the acceleration API and the RLC ucode is required to make the interrupt controller work. On newer asics, the MC ucode is used for the gddr5 controller on the chip and is required to link train the memory so it will run at full speed.
Alex
dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
On 12/14/2011 06:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 12:27 PM, batouzo batouzo@gmx.com wrote:
AMD develops and releases the ucode images. No source is available.
This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?)
The ucode is volatile and is lost on reboot. The different ucode images are used for different things. The PFP and ME ucode images provide the acceleration API and the RLC ucode is required to make the interrupt controller work. On newer asics, the MC ucode is used for the gddr5 controller on the chip and is required to link train the memory so it will run at full speed.
Thanks for explanation.
I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS philosophy etc) solution, but it seems to not be the case then.
What should one do to have 100% opensource, maximally secure X on radeon cards? Maybe I should disable firmware to achieve this goal at cost of performance - or may disabling firmware actually introduce any security/stability problems?
Would Intel build-in card be better for this use? Any particular family?
On Wed, Dec 14, 2011 at 12:49 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 06:40 PM, Alex Deucher wrote:
On Wed, Dec 14, 2011 at 12:27 PM, batouzo batouzo@gmx.com wrote:
AMD develops and releases the ucode images. No source is available.
This means that entire firmeware of GFX card is flashed on bootup? Btw this is a form of virus protection you could say (or anyway such firmware is volatile and lost on reboot?)
The ucode is volatile and is lost on reboot. The different ucode images are used for different things. The PFP and ME ucode images provide the acceleration API and the RLC ucode is required to make the interrupt controller work. On newer asics, the MC ucode is used for the gddr5 controller on the chip and is required to link train the memory so it will run at full speed.
Thanks for explanation.
I hoped using radeon and KMS I'm choosing the "good" (secure / FOSS philosophy etc) solution, but it seems to not be the case then.
What should one do to have 100% opensource, maximally secure X on radeon cards? Maybe I should disable firmware to achieve this goal at cost of performance - or may disabling firmware actually introduce any security/stability problems?
I don't want to get into a philosophical discussion about firmware. It's required for proper operation on radeon cards. Not using it will disable acceleration and interrupts and is overall not well tested/supported. On newer asics that require the MC ucode, the MC ucode is required to use the card at all as the boot up state is only enough to light up the screen.
Alex
On Wed, Dec 14, 2011 at 08:00:04AM +0100, batouzo wrote:
On 12/14/2011 12:47 AM, Jerome Glisse wrote:
On Tue, Dec 13, 2011 at 6:46 PM, Jerome Glisse j.glisse@gmail.com wrote:
On Tue, Dec 13, 2011 at 6:33 PM, batouzo batouzo@gmx.com wrote:
On 12/14/2011 12:31 AM, Jerome Glisse wrote:
Allocated in drm_vblank_init+0x139/0x260 [drm] + Freed in drm_vblank_cleanup+0x78/0x90 [drm] Allocated in drm_vblank_init+0xbe/0x260 [drm] + Freed in drm_vblank_cleanup+0x48/0x90 [drm]
It is Amd Bulldozer computer, with Radeon card: 01:00.0 VGA compatible controller: ATI Technologies Inc Cedar PRO [Radeon HD 5450]
messages: http://pastebin.com/NXN5EPtG config used: http://pastebin.com/AeVxEX7c
Do you boot your kernel with kexec ? Does the patch help :
Nope. Already seen that kexec bugfix on LKML but I start system normally not with kexec.
http://people.freedesktop.org/~glisse/0001-drm-radeon-disable-possible-GPU-w... If not please open bug on bugs.freedesktop.org against radeon driver.
ok
Note that this patch might also help non kexec case.
Cheers, Jerome
Oh and try booting with radeon.no_wb=1
Cheers, Jerome
Using that patch on 3.1.4 results in locking for 60 seconds on startup, since it is now looking for firmware.
This wait was not present without that patch.
This looks familiar, like the 60 second wait when using netconsole caused by netconsole attempt to look for NIC card firmware too early (when / is not really mounted, just initramfs).
I will report soon does it fix the crash;
Though, the 60 second delay may influence the rarity of hitting BUG (it was the case with netconsole's 60sec wait). Should I just remove loading of this firmware?
That patch doesn't change anything in regard of firmware. You need firmware for GPU to be use otherwise kms is just a fancy framebuffer driver.
Cheers, Jerome
dri-devel@lists.freedesktop.org
-
Alex Deucher -
batouzo -
Jerome Glisse