search

DragonFlyBSD / DPorts

The dedicated application build system for DragonFly BSD
Other
89 stars 45 forks source link

Xorg for Radeon 4xxx not loading kernel radeon modules #89

Closed davshao closed 9 years ago

davshao commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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

davshao commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

yeah, hal patches need to be fixed.

jrmarino commented 10 years ago

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

davshao commented 10 years ago

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 commented 10 years ago

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 commented 10 years ago

okay, these patches are surely invalid but at least hal builds with the last master: https://github.com/DragonFlyBSD/DPorts/commit/935e67689d993ba5d294f1d901c2d831d9a57dc7

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 commented 10 years ago

For current dports master through

commit 84cdd885b21a83fd3df22604fdca0fd77303bff9 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=<optimized out>) 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=<optimized out>, 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 commented 10 years ago

ftigeot, what is the status with this one?

ftigeot commented 10 years ago

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 commented 10 years ago

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

-.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 commented 10 years ago

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

ftigeot commented 10 years ago

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

jrmarino commented 9 years ago

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

ftigeot commented 9 years ago

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