Xorg for Radeon 4xxx not loading kernel radeon modules

[davshao]

There was a brief moment after the porting of the kernel radeon drivers where the kernel modules were loaded for Radeon 4xxx cards such as Radeon 4550 and 4350, but that was months ago. Since the new FreeBSD ports framework using WITH_NEW_XORG and WITH_GALLIUM was imported, even though these are not used in DragonFly Dports, the kernel modules are not being loaded.

$ kldstat

Id Refs Address Size Name
1 5 0xffffffff80200000 1545e30 kernel
2 1 0xffffffff81746000 816fd0 acpi.ko
3 1 0xffffffff81f5d000 56e58 ehci.ko

A sample from Xorg.0.log reads:

220.839 Falling back to old probe method for vesa
220.839 VGA arbiter: cannot open kernel arbiter, no multi-card support
220.839 RADEON(0): TOTO SAYS 00000000feaf0000
220.839 RADEON(0): MMIO registers at 0x00000000feaf0000: size 64KB
220.839 RADEON(0): PCI bus 1 card 0 func 0
220.839 RADEON(0): Creating default Display subsection in Screen section
"Builtin Default ati Screen 0" for depth/fbbpp 24/32
220.839 RADEON(0): Depth 24, (--) framebuffer bpp 32
220.839 RADEON(0): Pixel depth = 24 bits stored in 4 bytes (32 bpp pixmaps)
220.839 RADEON(0): Default visual is TrueColor
220.839 Loading sub module "vgahw"
220.839 LoadModule: "vgahw"
220.839 Loading /usr/local/lib/xorg/modules/libvgahw.so
220.840 Module vgahw: vendor="X.Org Foundation"
[ 220.840] compiled for 1.12.4, module version = 0.1.0
[ 220.840] ABI class: X.Org Video Driver, version 12.1
220.840 RADEON(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0
220.840 RADEON(0): RGB weight 888
220.840 RADEON(0): Using 8 bits per RGB (8 bit DAC)
220.840 RADEON(0): Chipset: "ATI Radeon HD 4350" (ChipID = 0x954f)
220.840 RADEON(0): Linear framebuffer at 0x00000000d0000000
220.840 RADEON(0): PCIE card detected
220.840 Loading sub module "int10"
220.840 LoadModule: "int10"
220.840 Loading /usr/local/lib/xorg/modules/libint10.so
220.842 Module int10: vendor="X.Org Foundation"
[ 220.842] compiled for 1.12.4, module version = 1.0.0
[ 220.842] ABI class: X.Org Video Driver, version 12.1
220.842 RADEON(0): initializing int10
220.846 RADEON(0): Primary V_BIOS segment is: 0xc000
220.847 RADEON(0): ATOM BIOS detected
220.847 RADEON(0): ATOM BIOS Rom:
[ 220.847] SubsystemVendorID: 0x1458 SubsystemID: 0x21ac
[ 220.847] IOBaseAddress: 0xd000
[ 220.847] Filename: R435OC9I.F3
[ 220.847] BIOS Bootup Message: GV-R435OC-512I/F3

220.847 RADEON(0): Framebuffer space used by Firmware (kb): 20
220.847 RADEON(0): Start of VRAM area used by Firmware: 0x7ffec
220.847 RADEON(0): AtomBIOS requests 20kB of VRAM scratch space
220.847 RADEON(0): AtomBIOS VRAM scratch base: 0x7ffec
220.847 RADEON(0): Cannot get VRAM scratch space. Allocating in main memory instead
220.847 RADEON(0): Default Engine Clock: 650000
220.847 RADEON(0): Default Memory Clock: 400000
220.847 RADEON(0): Maximum Pixel ClockPLL Frequency Output: 1200000
220.847 RADEON(0): Minimum Pixel ClockPLL Frequency Output: 0
220.847 RADEON(0): Maximum Pixel ClockPLL Frequency Input: 16000
220.847 RADEON(0): Minimum Pixel ClockPLL Frequency Input: 6000
220.847 RADEON(0): Maximum Pixel Clock: 400000
220.847 RADEON(0): Reference Clock: 27000
[ 220.847] drmOpenDevice: node name is /dev/dri/card0
[ 220.847] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory
[ 220.848] drmOpenDevice: open result is -1, (No such file or directory)
[ 220.848] Failed to change owner or group for file /dev/dri/card0! 2: No such file or directory
[ 220.848] drmOpenDevice: open result is -1, (No such file or directory)
[ 220.848] drmOpenDevice: Open failed
[ 220.848] [drm] failed to load kernel module "radeon"
220.848 RADEON(0): [dri] RADEONDRIGetVersion failed to open the DRM
[dri] Disabling DRI.

[davshao]

Does the switch to usb4bsd as the default usb stack mean that dports version of hal can assume working libusb, at least for 3.7+? In turn does that mean xorg-server can use hal as a default option? I am curious whether with these changes using hal more extensively and with fixing the broken WITH_GALLIUM version of dri / libGL (at least last time I tried it), whether Radeon 4xxx would start using the kernel drm modules again.

Also there is a mechanism for detecting OS version numbers in FreeBSD ports, but is there something similar for DragonFly OS version numbers in dports? What about specifying specific architectures such as i386 or x86_64?

[jrmarino]

It will take some time to switch all the ports, but yes, 3.7+ ports will be the same as freebsd which is to say they'll use U4b.

FreeBSD uses ${OSVERSION} which is set to 9999999 for use.
If we need the OS version, we can use ${DFLYVERSION}. That intel driver uses this to select version numbers.

[davshao]

Do the latest patches to sysutils/hal still permit building dports from source for versions of DragonFly earlier than latest 3.7-DEVELOPMENT, which do not have usb4bsd as the default?

The patches also work for cvs pkgsrc on DragonFly 3.7-DEVELOPMENT i386 and x86_64.

[jrmarino]

I believe sysutils/hal builds equally well on 3.4, 3.6, and the 3.7 development branch.
I've build packages on all 3 platforms and hal built on all three.

[davshao]

Actually looking at the patch patch-hald_freebsd_probing_probe-hiddev.c I wonder what are the right include lines for usb4bsd versus the old usb.

Is the user expected to have a nonempty /usr/include/bus/usb directory if the user is using usb4bsd as the default in 3.7-DEVELOPMENT? Every now and then I experiment by moving aside /usr/include during a make installworld, so when I do this with current 3.7-DEVELOPMENT the new /usr/include/bus/usb directory is empty.

For systems using usb4bsd should the includes possibly be:
dev/u4b/usb.h
dev/u4b/usbhid.h

and not the current

bus/usb/usb.h
bus/usb/usbhid.h

[jrmarino]

I just double checked my Release36 jail and my bleeding edge jail. Both have /usr/include/bus/usb directories with lots of headers. I believe the same locations are used for U4B as before.

Unless my eyes are playing tricks with me, the second block of pseudo-code is identical to the first one, so I don't know what to do with that. In any case, like I said, systems/hal is building on all 3 supported branches right now.

[davshao]

Yes, a system that was working prior to the change to U4B will have the old /usr/include/bus/usb headers. The question is what happens when some lunatic like me installs /usr/include from scratch by moving the old /usr/include and doing

make installworld && make installkernel

and getting a brand new /usr/include. For that case the /usr/include/bus/usb will be empty.

Note that patch-hald_freebsd_probing_probe-usb2-device.c uses u4b not usb.

I guess my concern is that /usr/include/bus/u4b reflects "the truth" while /usr/include/bus/usb is the old headers that may or may not be accurate as to what is now actually installed on a U4B system.

[jrmarino]

the usb2 file (patch-hald_freebsd_probing_probe-usb2-device.c) is only compiled for the U4B scenario, so we don't need to think about the old usb support.

I'm trying to get some confirmation on why you aren't seeing bus/usb headers get installed. If they are truly for the original usb then they should be removed with "make upgrade" but that is clearly not happening.

[jrmarino]

okay, from initial discussions it seems you caught a problem. standby...

[davshao]

Just check the modification times in /usr/include/bus/usb. They are probably months old files. Whereas the files in /usr/include/bus/u4b will be newer.

My experiment is something like

cd /usr
mv include include.old
cd /usr/src
make installkernel && make installworld && make upgrade

Now one has a brand new /usr/include with empty /usr/include/bus/usb.

Here's another way to look at what I am questioning. Is /usr/include/usb/usb.h guaranteed to always be the same as /usr/include/u4b/usb.h, and the same for usbhid.h? I believe the u4b directory is the truth and usb is the older possibly non-truth.

[jrmarino]

From what I'm hearing:

1. Yes, it should be bus/u4b
2. make upgrade will be updated to remove the bus/usb files when u4b is selected. The directory itself may stay, but it will be empty

That should remove the ambiguity (swildner didn't think it was necessary but I convinced him to do that)

[davshao]

Does that mean the sysutil/hal patches should be changed to use

bus/u4b/usb.h
bus/u4b/usbhid.h

It seems to me that it would be possibly to clean out /usr/include/bus/usb and then install the u4b headers also into /usr/include/bus/usb? Should userland even need to know there is a separate u4b directory in /usr/include/bus?

It's too bad that the backwards compatibility problems are probably too great to synch DragonFly with every other BSD I know of and simply use /usr/include/dev/usb for the headers ...

[jrmarino]

yeah, hal patches need to be fixed.

[jrmarino]

Dillon doesn't want dev to be used, he thinks that is a mistake, so it's different by design.

[davshao]

I am very concerned about how to compile hald/freebsd/hf-usb.c under U4B. There are many constants in the old usb/usb.h that do not seem to have an analogous definition anywhere in U4B such as USB_MAX_DEVNAMES. struct usb_device_info is actually declared in u4b/usb_ioctl.h instead of formerly usb/usb.h. Furthermore the old struct usb_device_info has fields that have no analog in U4B such as udi_devnames.

[jrmarino]

While I haven't tried to update hal myself, I trust that this may be a major challenge. As far as dports is concerned, there will be a push to remove hal from all the dports as has already been done for xorg. That doesn't address pkgsrc though.

I am not sure of the best approach yet. Is it worth disabling USB functionality on hal on U4B systems? Likely that would not be a good solution as mice and keyboards not working would be noticed. Ideally hal would be removed from option lists for dragonfly on pkgsrc as well. It would be nice to know which major packages would need modication (e.g. KDE4, XFCE4, Xorg)

[jrmarino]

okay, these patches are surely invalid but at least hal builds with the last master:
935e676

I'm going to send profmakx the link so he can at least restore the ports[i] functionality which must be in there somewhere.

[davshao]

For current dports master through

commit 84cdd88
Author: DPorts Builder nobody@home.ok
Date: Thu Jun 5 11:06:18 2014 -0700

Import devel/gnatcoll version 2014_3

and a bit earlier, building x11/xorg and x11-wm/xfce4 from source with current master DragonFly 3.9-DEVELOPMENT on both an Intel i3 and AMD machine with Radeon 4550 or Radeon 4350 graphics cards results in locked machines with eventual panic. Restoring to dports from around April 24, 2014, resulted in a system that could at least use Xorg with the vesa driver.

From tailing /var/log/messages:

Jun 5 15:37:40 kernel: info: [drm] Initialized drm 1.1.0 20060810
Jun 5 15:37:40 kernel: drm0: <ATI Radeon HD 4550> on vgapci0
Jun 5 15:37:40 kernel: info: [drm] RADEON_IS_PCIE
Jun 5 15:37:40 kernel: info: [drm] initializing kernel modesetting (RV710 0x1002:0x9540 0x174B:0xE970).
Jun 5 15:37:40 kernel: info: [drm] register mmio base: 0xF7E20000
Jun 5 15:37:40 kernel: info: [drm] register mmio size: 65536
Jun 5 15:37:40 kernel: info: [drm] radeon_atrm_get_bios: ===> Try ATRM...
Jun 5 15:37:40 kernel: info: [drm] radeon_atrm_get_bios: pci_find_class() found: 0:4:0:0, vendor=1002, device=9540
Jun 5 15:37:40 kernel: info: [drm] radeon_atrm_get_bios: Get ACPI device handle
Jun 5 15:37:40 kernel: info: [drm] radeon_acpi_vfct_bios: ===> Try VFCT...
Jun 5 15:37:40 kernel: info: [drm] radeon_acpi_vfct_bios: Get "VFCT" ACPI table
Jun 5 15:37:40 kernel: info: [drm] radeon_acpi_vfct_bios: Failed to get "VFCT" table: AE_NOT_FOUND
Jun 5 15:37:40 kernel: info: [drm] igp_read_bios_from_vram: ===> Try IGP's VRAM...
Jun 5 15:37:40 kernel: info: [drm] igp_read_bios_from_vram: VRAM base address: 0xe0000000
Jun 5 15:37:40 kernel: info: [drm] igp_read_bios_from_vram: Map address: 0xffffffe20c410000 (262144 bytes)
Jun 5 15:37:40 kernel: info: [drm] igp_read_bios_from_vram: Incorrect BIOS signature: 0x7807
Jun 5 15:37:40 kernel: info: [drm] radeon_read_bios: ===> Try PCI Expansion ROM...
Jun 5 15:37:40 kernel: info: [drm] radeon_read_bios: Map address: 0xffffffe20c410000 (131072 bytes)
Jun 5 15:37:40 kernel: info: [drm] ATOM BIOS: 11X
Jun 5 15:37:40 kernel: drm0: info: VRAM: 512M 0x0000000000000000 - 0x000000001FFFFFFF (512M used)
Jun 5 15:37:40 kernel: drm0: info: GTT: 512M 0x0000000020000000 - 0x000000003FFFFFFF
Jun 5 15:37:40 kernel: info: [drm] Detected VRAM RAM=512M, BAR=256M
Jun 5 15:37:40 kernel: info: [drm] RAM width 64bits DDR
Jun 5 15:37:40 kernel: [TTM] Zone kernel: Available graphics memory: 8345920 kiB
Jun 5 15:37:40 kernel: [TTM] Zone dma32: Available graphics memory: 2097152 kiB
Jun 5 15:37:40 kernel: [TTM] Initializing pool allocator
Jun 5 15:37:40 kernel: info: [drm] radeon: 512M of VRAM memory ready
Jun 5 15:37:40 kernel: info: [drm] radeon: 512M of GTT memory ready.
Jun 5 15:37:40 kernel: info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010).
Jun 5 15:37:40 kernel: info: [drm] Driver supports precise vblank timestamp query.
Jun 5 15:37:40 kernel: info: [drm] radeon: irq initialized.
Jun 5 15:37:40 kernel: info: [drm] GART: num cpu pages 131072, num gpu pages 131072
Jun 5 15:37:40 kernel: info: [drm] probing gen 2 caps for device 1002:9540 = 1/0
Jun 5 15:37:40 kernel: info: [drm] Loading RV710 Microcode
Jun 5 15:37:40 kernel: info: [drm] PCIE GART of 512M enabled (table at 0x0000000000040000).
Jun 5 15:37:40 kernel: drm0: info: WB enabled
Jun 5 15:37:40 kernel: drm0: info: fence driver on ring 0 use gpu addr 0x0000000020000c00 and cpu addr 0x0xffffdf80033cdc00
Jun 5 15:37:40 kernel: drm0: info: fence driver on ring 3 use gpu addr 0x0000000020000c0c and cpu addr 0x0xffffdf80033cdc0c
Jun 5 15:37:40 kernel: info: [drm] ring test on 0 succeeded in 1 usecs
Jun 5 15:37:40 kernel: info: [drm] ring test on 3 succeeded in 0 usecs
Jun 5 15:37:40 kernel: info: [drm] ib test on ring 0 succeeded in 0 usecs
Jun 5 15:37:40 kernel: info: [drm] ib test on ring 3 succeeded in 0 usecs
Jun 5 15:37:40 kernel: info: [drm] radeon_device_init: Taking over the fictitious range 0xe0000000-0xf0000000
Jun 5 15:37:40 kernel: iicbus0: on iicbb0 addr 0xff
Jun 5 15:37:40 kernel: iicbus1: on iicbb1 addr 0xff
Jun 5 15:37:40 kernel: iicbus2: on iicbb2 addr 0xff
Jun 5 15:37:40 kernel: iicbus3: on iicbb3 addr 0xff
Jun 5 15:37:40 kernel: iicbus4: on iicbb4 addr 0xff
Jun 5 15:37:40 kernel: iicbus5: on iicbb5 addr 0xff
Jun 5 15:37:40 kernel: iicbus6: on iicbb6 addr 0xff
Jun 5 15:37:40 kernel: info: [drm] Radeon Display Connectors
Jun 5 15:37:40 kernel: info: [drm] Connector 0:
Jun 5 15:37:40 kernel: info: [drm] VGA-1
Jun 5 15:37:40 kernel: info: [drm] DDC: 0x7e40 0x7e40 0x7e44 0x7e44 0x7e48 0x7e48 0x7e4c 0x7e4c
Jun 5 15:37:40 kernel: info: [drm] Encoders:
Jun 5 15:37:40 kernel: info: [drm] CRT2: INTERNAL_KLDSCP_DAC2
Jun 5 15:37:40 kernel: info: [drm] Connector 1:
Jun 5 15:37:40 kernel: info: [drm] HDMI-A-1
Jun 5 15:37:40 kernel: info: [drm] HPD1
Jun 5 15:37:40 kernel: info: [drm] DDC: 0x7e50 0x7e50 0x7e54 0x7e54 0x7e58 0x7e58 0x7e5c 0x7e5c
Jun 5 15:37:40 kernel: info: [drm] Encoders:
Jun 5 15:37:40 kernel: info: [drm] DFP1: INTERNAL_UNIPHY
Jun 5 15:37:40 kernel: info: [drm] Connector 2:
Jun 5 15:37:40 kernel: info: [drm] DVI-I-1
Jun 5 15:37:40 kernel: info: [drm] HPD4
Jun 5 15:37:40 kernel: info: [drm] DDC: 0x7f10 0x7f10 0x7f14 0x7f14 0x7f18 0x7f18 0x7f1c 0x7f1c
Jun 5 15:37:40 kernel: info: [drm] Encoders:
Jun 5 15:37:40 kernel: info: [drm] CRT1: INTERNAL_KLDSCP_DAC1
Jun 5 15:37:40 kernel: info: [drm] DFP2: INTERNAL_UNIPHY2
Jun 5 15:37:40 kernel: info: [drm] Internal thermal controller with fan control
Jun 5 15:37:40 kernel: info: [drm] radeon: power management initialized
Jun 5 15:37:40 kernel: info: [drm] Initialized radeon 2.29.0 20080528
Jun 5 15:37:40 kernel:
Jun 5 15:37:40 kernel:

From the summary of the panic:

Version String: DragonFly v3.9.0.44.g1b3d9-DEVELOPMENT #1: Thu Jun 5 08:46:47 PDT 2014 xxxxx@:/usr/obj/usr/src/sys/X86_64_GENERIC

panic: page fault
...
Reading symbols from /boot/kernel/acpi.ko...done.
Loaded symbols for /boot/kernel/acpi.ko
Reading symbols from /boot/kernel/ehci.ko...done.
Loaded symbols for /boot/kernel/ehci.ko
Reading symbols from /boot/kernel/radeonkms.ko...done.
Loaded symbols for /boot/kernel/radeonkms.ko
Reading symbols from /boot/kernel/iicbb.ko...done.
Loaded symbols for /boot/kernel/iicbb.ko
Reading symbols from /boot/kernel/iicbus.ko...done.
Loaded symbols for /boot/kernel/iicbus.ko
Reading symbols from /boot/kernel/iic.ko...done.
Loaded symbols for /boot/kernel/iic.ko
Reading symbols from /boot/kernel/drm.ko...done.
Loaded symbols for /boot/kernel/drm.ko
Reading symbols from /boot/kernel/radeonkmsfw_RV710_pfp.ko...done.
Loaded symbols for /boot/kernel/radeonkmsfw_RV710_pfp.ko
Reading symbols from /boot/kernel/radeonkmsfw_RV710_me.ko...done.
Loaded symbols for /boot/kernel/radeonkmsfw_RV710_me.ko
Reading symbols from /boot/kernel/radeonkmsfw_R700_rlc.ko...done.
Loaded symbols for /boot/kernel/radeonkmsfw_R700_rlc.ko
_get_mycpu () at ./machine/thread.h:69
69 __asm ("movq %%gs:globaldata,%0" : "=r" (gd) : "m"(__mycpu__dummy));
(kgdb) #0 _get_mycpu () at ./machine/thread.h:69
#1 md_dumpsys (di=di@entry=0xffffffff8100e0a0 )
at /usr/src/sys/platform/pc64/x86_64/dump_machdep.c:265
#2 0xffffffff805e046c in dumpsys () at /usr/src/sys/kern/kern_shutdown.c:912
#3 0xffffffff805e0939 in boot (howto=howto@entry=260)
at /usr/src/sys/kern/kern_shutdown.c:369
#4 0xffffffff805e0c31 in panic (fmt=fmt@entry=0xffffffff80a0fcab "%s")
at /usr/src/sys/kern/kern_shutdown.c:818
#5 0xffffffff809b981a in trap_fatal (frame=frame@entry=0xffffffe20b415408,
eva=) at /usr/src/sys/platform/pc64/x86_64/trap.c:1034
#6 0xffffffff809b9a19 in trap_pfault (frame=frame@entry=0xffffffe20b415408,
usermode=usermode@entry=0) at /usr/src/sys/platform/pc64/x86_64/trap.c:934
#7 0xffffffff809b9f65 in trap (frame=0xffffffe20b415408)
at /usr/src/sys/platform/pc64/x86_64/trap.c:610
#8 0xffffffff809a35bf in calltrap ()
at /usr/src/sys/platform/pc64/x86_64/exception.S:188
#9 0xffffffff8343425b in ttm_bo_vm_insert_rb (bo=0xffffffe20a565608)
at /usr/src/sys/dev/drm/drm/../ttm/ttm_bo.c:1691
#10 ttm_bo_setup_vm (bo=0xffffffe20a565608)
at /usr/src/sys/dev/drm/drm/../ttm/ttm_bo.c:1742
#11 ttm_bo_init (bdev=bdev@entry=0xffffffe20c3e21a8,
bo=bo@entry=0xffffffe20a565608, size=size@entry=16384,
type=type@entry=ttm_bo_type_device,
placement=placement@entry=0xffffffe20a5655e0,
page_alignment=page_alignment@entry=1,
interruptible=interruptible@entry=true,
persistent_swap_storage=persistent_swap_storage@entry=0x0,
acc_size=acc_size@entry=9344, sg=sg@entry=0x0,
destroy=destroy@entry=0xffffffff828741da <radeon_ttm_bo_destroy>)
at /usr/src/sys/dev/drm/drm/../ttm/ttm_bo.c:1298
#12 0xffffffff8287453d in radeon_bo_create (
rdev=rdev@entry=0xffffffe20c3e1c00, size=size@entry=16384,
byte_align=byte_align@entry=4096, kernel=kernel@entry=false,
domain=domain@entry=4, sg=sg@entry=0x0,
bo_ptr=bo_ptr@entry=0xffffffe20b4155f0)
at /usr/src/sys/dev/drm/radeon/radeon_object.c:153
#13 0xffffffff828672ec in radeon_gem_object_create (
rdev=rdev@entry=0xffffffe20c3e1c00, size=16384, alignment=4096,
initial_domain=4, discardable=discardable@entry=false,
kernel=kernel@entry=false, obj=obj@entry=0xffffffe20b415660)
at /usr/src/sys/dev/drm/radeon/radeon_gem.c:80
#14 0xffffffff82867749 in radeon_gem_create_ioctl (
dev=dev@entry=0xffffffe20bf83700, data=data@entry=0xffffffe20b415840,
filp=0xffffffe209cad850) at /usr/src/sys/dev/drm/radeon/radeon_gem.c:266
#15 0xffffffff8341f452 in drm_ioctl (ap=)
at /usr/src/sys/dev/drm/drm/../drm_drv.c:831
#16 0xffffffff805be914 in dev_dioctl (dev=dev@entry=0xffffffe1e687d580,
cmd=cmd@entry=3223348317, data=data@entry=0xffffffe20b415840 "",
fflag=, cred=cred@entry=0xffffffe033a4ee98,
msg=msg@entry=0xffffffe20b415950, fp=fp@entry=0xffffffe209cd6d28)
at /usr/src/sys/kern/kern_device.c:250
#17 0xffffffff807cecfa in devfs_fo_ioctl (fp=0xffffffe209cd6d28,
com=3223348317, data=0xffffffe20b415840 "", ucred=0xffffffe033a4ee98,
msg=0xffffffe20b415950) at /usr/src/sys/vfs/devfs/devfs_vnops.c:1492
#18 0xffffffff806190f8 in fo_ioctl (msg=0xffffffe20b415950,
cred=0xffffffe033a4ee98, data=0xffffffe20b415840 "", com=3223348317,
fp=0xffffffe209cd6d28) at /usr/src/sys/sys/file2.h:88
#19 mapped_ioctl (fd=32, com=3223348317,
uspc_data=0x7fffffffe7e0 <Address 0x7fffffffe7e0 out of bounds>,
map=map@entry=0x0, msg=0xffffffe20b415950)
at /usr/src/sys/kern/sys_generic.c:727
#20 0xffffffff806191ce in sys_ioctl (uap=)
at /usr/src/sys/kern/sys_generic.c:548
#21 0xffffffff809ba8d8 in syscall2 (frame=0xffffffe20b4159f8)
at /usr/src/sys/platform/pc64/x86_64/trap.c:1243
#22 0xffffffff809a380b in Xfast_syscall ()
at /usr/src/sys/platform/pc64/x86_64/exception.S:323
#23 0x000000000000002b in ?? ()
Backtrace stopped: previous frame inner to this frame (corrupt stack?)
(kgdb) (kgdb)
Token collisions owner
pmap_token 0 not held
dev_token 0 not held
vm_token 0 not held
vmspace_token 0 not held
kvm_token 0 not held
tty_token 6676477 not held
vnode_token 0 not held

[jrmarino]

ftigeot, what is the status with this one?

[ftigeot]

I have been focusing on drm/i915 lately and haven't touched drm/radeon in a while.
The memory corruption issues in drm/ttm are still present; some bugs have been fixed but it was not enough.
If I get enough free time this summer I plan to continue synchronizing our drm/ttm code with the Linux 3.9 implementation.

[davshao]

As of current master through:

commit dacf70b99fb315685679e484687c2f3c94e8ab49
Date: Thu Jul 3 20:32:47 2014 +0200

<sys/sysctl.h>: Put the access argument in parentheses.

which is after a series of changes improving drm/ttm, on both DragonFly 3.9-DEVELOPMENT x86_64 and i386, Radeon 4xxxx graphics cards now are able to match say FreeBSD 10-releng in loading kernel radeon modules.

For i386, I changed /etc/make.conf to have the lines:

WITH_NEW_XORG="YES"
WITH_GALLIUM="YES"
WITH_KMS=true

and then

pkg delete -R libGL dri
cd /usr/dports/x11/xorg
rehash && make clean && make NO_DIALOG=yes install clean

With x86_64 all I had to do was

portmaster -d x11-drivers/xf86-video-ati

Here's the very brief patch just reversing a previous patch:

diff --git a/x11-drivers/xf86-video-ati/Makefile b/x11-drivers/xf86-video-ati/Makefile
index 14cff59..52f997a 100644
--- a/x11-drivers/xf86-video-ati/Makefile
+++ b/x11-drivers/xf86-video-ati/Makefile
@@ -14,7 +14,7 @@ USE_XORG= xf86driproto xineramaproto xf86miscproto glproto

.include <bsd.port.options.mk>

-.if ${DFLYVERSION} < 300951 || !defined(WITH_NEW_XORG)
+.if ${DFLYVERSION} < 300751 || !defined(WITH_NEW_XORG)
ATI_VERSION= 6.14.6
ATI_REVISION= 3
CONFIGURE_ARGS+=--disable-kms

[jrmarino]

okay, ftigeot didn't object so I'll change this in DeltaPorts and then regenerate it in DPorts

[ftigeot]

The previous commit incorrectly enabled xf86-video-ati 7.2 on DragonFly 3.8.
I have pushed a fix to DeltaPorts.

[jrmarino]

do we need to keep this issue open? Does the problem still exist currently?

[ftigeot]

xf86-video-ati appears to function as expected on both dragonfly 3.8.x and 3.9.x.