Bug #2635

Stablize drm/radeon KMS drivers for new xorg

Added by tuxillo 2 months ago. Updated about 1 month ago.

Status:NewStart date:02/13/2014
Priority:NormalDue date:
Assignee:jorisgio% Done:

20%

Category:Driver
Target version:3.8.0

Description

Stablize drm/radeon KMS drivers for new xorg

patch-ttm_bo.c Magnifier (422 Bytes) vadaszi, 02/21/2014 03:59 PM

core.txt.8 (34.4 KB) jorisgio, 02/24/2014 09:57 AM

dmesg (5.19 KB) jorisgio, 02/24/2014 10:00 AM

History

#1 Updated by vadaszi about 1 month ago

This patch fixes the assertion failing during "kldload radeonkms" in sys/dev/drm/ttm/ttm_bo.c line 1169.

#2 Updated by jorisgio about 1 month ago

Thanks. I believed this had already been fixed. I commited your patch ea6f52c4fb2da1957cbee60ff4daf8be83de1f8e.

I remember there where one or two of those. I think fixed have been commited, but i'm not sure anymore now. But after that, the major issue with ttm is an issue with the RB_TREE of buffers object. I get a panic where some of the elements in the tree have a null refcount and invalid data in them.

I'll upload core as soon as i can access the machine.

#3 Updated by jorisgio about 1 month ago

Hi,

With kernel v3.7.1.747.g4fd11-DEVELOPMENT, I have a new panic. See core files :

http://leaf.dragonflybsd.org/~joris/vmcore.ttm
http://leaf.dragonflybsd.org/~joris/kern.ttm

The radeonkms module loads and initialize.

Laters xorg calls mmap to get a shared mapping of the card0 device.

* vm_mmap in vm/vm_mmap.c is called to obtain a shared mapping. This is a device mapping, type is VCHR

* enters dev_dmmap_single -> drm_mmap_single -> ttm_bo_mmap_single

* ttm_bo_mmap_single looks up the pair (offset/size) in the buffer object red/black tree. bdev address in the core is 0xffffffe0e89f73a8

* offset is 4299227136>>12, and size is 8192>>12

* The lookup fails. Here are some informations from the core. There are only two elements in the tree, the second being the right child of the first. First element is at address 0xffffffe0e64b85a0 and second element is at address 0xffffffe0e64b81c8.

* at the end of the while loop, the condition (best_bo->vm_node->start + best_bo->num_pages) < (page_start + num_pages) is false

* ttm_bo_mmap_single returns EINVAL

* vm_mmap only check error code against ENODEV. object is unitiliazed, and hence the panic.

Now the real question is "why does the lookup fail ?" That, i don't know.

#4 Updated by jorisgio about 1 month ago

  • Assignee set to jorisgio

Also available in: Atom PDF