[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

(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


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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Jerome Glisse]

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-writeback-early-v3.patch

If not please open bug on bugs.freedesktop.org against radeon driver.

Cheers,
Jerome

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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-writeback-early-v3.patch
> If not please open bug on bugs.freedesktop.org against radeon driver.

ok

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Jerome Glisse]

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-writeback-early-v3.patch
>> 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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Jerome Glisse]

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-writeback-early-v3.patch
>>> 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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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-writeback-early-v3.patch
>>>> 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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Alex Deucher]

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-writeback-early-v3.patch
>>>>> 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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Alex Deucher]

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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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)?

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Alex Deucher]

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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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?)

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Alex Deucher]

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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[batouzo]

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?

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Alex Deucher]

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

Re: [drm] [radeon] [3.1.4] slub memory corruption in drm_vblank_cleanup

[Jerome Glisse]

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-writeback-early-v3.patch
> >>>> 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