[new port] graphics/linux-dri74

Tijl Coosemans tijl at ulyssis.org
Tue May 19 18:12:10 UTC 2009


On Tuesday 19 May 2009 18:50:39 Yamagi Burmeister wrote:
> Okay, I investigated further. First I tried a FreeBSD/i386 version of
> ioQuake3 on a FreeBSD/amd64 host. After some minor and unrelated
> problems it worked.
> 
> After that I tried to debug the linux-dri74. Reading the source and
> doing a lot test runs I realized, that there are in fact two
> problems. Every ten starts or so the userland side of drm crashes:
> 
>   yamagi at saya:ttyp3 ~: /usr/compat/linux/usr/bin/glxinfo
>   name of display: :0.0
>   libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
>   libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
>   libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
>   drmOpenDevice: node name is /dev/dri/card0
>   drmOpenDevice: open result is 4, (OK)
>   DRM_IOCTL_VERSION: Bad address
>   Segmentation fault (core dumped)
> 
> The other times the userland side of drm is able to open the
> drm-device bit is unable to initalize it. The error message is
> somewhat missleading:
> 
>   yamagi at saya:ttyp3 ~: /usr/compat/linux/usr/bin/glxinfo
>   name of display: :0.0
>   libGL: XF86DRIGetClientDriverName: 5.3.0 r300 (screen 0)
>   libGL: OpenDriver: trying /usr/lib/dri/tls/r300_dri.so
>   libGL: OpenDriver: trying /usr/lib/dri/r300_dri.so
>   drmOpenDevice: node name is /dev/dri/card0
>   drmOpenDevice: open result is 4, (OK)
>   drmOpenByBusid: Searching for BusID pci:0000:01:00.0
>   drmOpenDevice: node name is /dev/dri/card0
>   drmOpenDevice: open result is 4, (OK)
>   drmOpenByBusid: drmOpenMinor returns 4
>   drmOpenByBusid: drmGetBusid reports (null)
>   drmOpenDevice: node name is /dev/dri/card1
>   drmOpenByBusid: drmOpenMinor returns -1
>   drmOpenDevice: node name is /dev/dri/card2
>   drmOpenByBusid: drmOpenMinor returns -1
>   drmOpenDevice: node name is /dev/dri/card3
>   drmOpenByBusid: drmOpenMinor returns -1
>   drmOpenDevice: node name is /dev/dri/card4
>   drmOpenByBusid: drmOpenMinor returns -1
>    [..]
>   drmOpenDevice: node name is /dev/dri/card14
>   drmOpenByBusid: drmOpenMinor returns -1
>   libGL error: drmOpenOnce failed (Operation not permitted)
>   libGL error: reverting to software direct rendering
>   libGL: OpenDriver: trying /usr/lib/dri/tls/swrast_dri.so
>   libGL: OpenDriver: trying /usr/lib/dri/swrast_dri.so
>   display: :0  screen: 0
>   direct rendering: Yes
> 
> So I added debug printf() into the code. I stepped through it. After
> some hours of intesive debugging im 99% sure, that both of the above
> failures of linux-drm74 are originating at the kernel side. It's most
> likely NOT a problem of the userland side and therefor not a problem
> of the port.
> 
> I'll investigate further at the kernel side, but that'll need some
> time. So, while it's the fault linux-drm74, what about a little
> warning message in the install message of the port? Just to be sure,
> that other users experiencing the same problem know, that it is not a
> bug of linux-dr74.

I noticed you use the r300 driver so maybe this patch helps:
http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch

Robert Noland (CCed) probably knows more about this though.
http://lists.freebsd.org/pipermail/freebsd-emulation/2009-May/005995.html


More information about the freebsd-emulation mailing list