Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 19 May 2009 20:12:05 +0200
From:      Tijl Coosemans <tijl@ulyssis.org>
To:        freebsd-emulation@freebsd.org, Yamagi Burmeister <lists@yamagi.org>
Cc:        Robert Noland <rnoland@freebsd.org>
Subject:   Re: [new port] graphics/linux-dri74
Message-ID:  <200905192012.06401.tijl@ulyssis.org>
In-Reply-To: <20090519165039.GA12505@yamagi.org>
References:  <92596693@bb.ipt.ru> <20090515145252.GA69488@yamagi.org> <20090519165039.GA12505@yamagi.org>

next in thread | previous in thread | raw e-mail | index | archive | help
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@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@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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200905192012.06401.tijl>