I've built the ports with the following lines in my /etc/make.conf:
WITH_NEW_XORG=1
WITH_KMS=1
WITH_GALLIUM=1
And I've attempted to run ``startx''.
The compiler was a very recent version of Clang.
When building the kernel (not the ports):
== /etc/make.conf snippet begins ==
On Sun, 10 Nov 2013, d...@gmx.com wrote:
I've built the ports with the following lines in my /etc/make.conf:
WITH_NEW_XORG=1
WITH_KMS=1
WITH_GALLIUM=1
And I've attempted to run ``startx''.
My -current is still from ~July 3, and I also got panics
when trying new Xorg. Take the drm devices o
Daniel Eischen wrote, On 11/10/2013 17:40:
My -current is still from ~July 3, and I also got panics
when trying new Xorg. Take the drm devices out of your
kernel configuration and let X load the necessary drm2
devices when it starts. This allowed it to work for me.
Hmm, works for me to avoid
On Nov 10, 2013, at 12:20 PM, d...@gmx.com wrote:
>
> Daniel Eischen wrote, On 11/10/2013 17:40:
>> My -current is still from ~July 3, and I also got panics
>> when trying new Xorg. Take the drm devices out of your
>> kernel configuration and let X load the necessary drm2
>> devices when it star
On Sun, Nov 10, 2013 at 9:34 AM, Daniel Eischen wrote:
>
> On Nov 10, 2013, at 12:20 PM, d...@gmx.com wrote:
> >
> > Daniel Eischen wrote, On 11/10/2013 17:40:
> >> My -current is still from ~July 3, and I also got panics
> >> when trying new Xorg. Take the drm devices out of your
> >> kernel con
On Sun, 10 Nov 2013 18:20:29 +0100 d...@gmx.com wrote:
> info: [drm] Loading R300 Microcode
> radeonkmsfw_R300_cp: could not load firmware image, error 2
> error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load
> firmware "radeonkmsfw_R300_cp"
> error: [drm:pid667:r100_cp_ini
Tijl Coosemans wrote, On 11/11/2013 10:07:
On Sun, 10 Nov 2013 18:20:29 +0100 d...@gmx.com wrote:
error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to load firmware
"radeonkmsfw_R300_cp"
Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko.
Oops, my bad. I had WITHOUT_S
On Tue, 12 Nov 2013 00:34:24 +0100 d...@gmx.com wrote:
> Tijl Coosemans wrote, On 11/11/2013 10:07:
>> On Sun, 10 Nov 2013 18:20:29 +0100 d...@gmx.com wrote:
>>> error: [drm:pid667:r100_cp_init_microcode] *ERROR* radeon_cp: Failed to
>>> load firmware "radeonkmsfw_R300_cp"
>>
>> Make sure you have
Le 10/11/2013 18:20, d...@gmx.com a écrit :
drmn0: info: GTT: 0M 0xF000 - 0xEFFF
Tijl Coosemans is right, the problem is this line.
As I don't really now how AGP works and have no AGP hardware to
reproduce the problem, can you post the output of the following commands
as a start?
On Wed, 13 Nov 2013 21:29:23 +0100 Jean-Sébastien Pédron wrote:
> Le 10/11/2013 18:20, d...@gmx.com a écrit :
>> drmn0: info: GTT: 0M 0xF000 - 0xEFFF
>
> Tijl Coosemans is right, the problem is this line.
>
> As I don't really now how AGP works and have no AGP hardware to
> reproduce the
On Thu, 14 Nov 2013 11:38:46 +0100 Tijl Coosemans wrote:
> On Wed, 13 Nov 2013 21:29:23 +0100 Jean-Sébastien Pédron wrote:
>> Le 10/11/2013 18:20, d...@gmx.com a écrit :
>>> drmn0: info: GTT: 0M 0xF000 - 0xEFFF
>>
>> Tijl Coosemans is right, the problem is this line.
>>
>> As I don't real
Jean-Sébastien Pédron wrote, On 11/13/2013 21:29:
As I don't really now how AGP works and have no AGP hardware to reproduce the
problem, can you post the output of the following commands as a start?
pciconf -lvbce
hostb0@pci0:0:0:0: class=0x06 card=0x25701849 chip=0x25708086 rev=
Tijl Coosemans wrote, On 11/14/2013 11:38:
On Wed, 13 Nov 2013 21:29:23 +0100 Jean-Sébastien Pédron wrote:
Le 10/11/2013 18:20, d...@gmx.com a écrit :
drmn0: info: GTT: 0M 0xF000 - 0xEFFF
Tijl Coosemans is right, the problem is this line.
The attached patch should fix it, but I have
Le 14/11/2013 22:35, Tijl Coosemans a écrit :
The attached patch should fix it, but I haven't been able to test it
yet. The ai_aperture_size field is in bytes.
So it doesn't work, but it gets a bit further:
Thank Tijl, I committed your patch today.
It looks like some support for AGP is mis
Still nobody wants to apply Robert Noland's DRM patch?
Index: sys/dev/drm/r300_cmdbuf.c
===
--- sys/dev/drm/r300_cmdbuf.c (revision 259413)
+++ sys/dev/drm/r300_cmdbuf.c (working copy)
@@ -1043,6 +1043,8 @@
int emit_dispatch_age = 0
On 16.12.2013 08:36, d...@gmx.com wrote:
> Still nobody wants to apply Robert Noland's DRM patch?
What problem(s) does this patch fix?
--
Jean-Sébastien Pédron
signature.asc
Description: OpenPGP digital signature
Jean-Sébastien Pédron wrote, On 12/17/2013 22:20:
On 16.12.2013 08:36, d...@gmx.com wrote:
Still nobody wants to apply Robert Noland's DRM patch?
What problem(s) does this patch fix?
It fixes non-deterministic lockups when the (old, drm1) r300 drivers are used.
According to John Baldwin [1]
On 18.12.2013 07:41, d...@gmx.com wrote:
> Jean-Sébastien Pédron wrote, On 12/17/2013 22:20:
>> On 16.12.2013 08:36, d...@gmx.com wrote:
>>> Still nobody wants to apply Robert Noland's DRM patch?
>>
>> What problem(s) does this patch fix?
>
> It fixes non-deterministic lockups when the (old, drm1)
[snip]
So the standard trop of UNLOCK/WORK/RELOCK is pretty dangerous.
There's no state re-validation going on when you re-acquire that lock.
So, although it meets the lock requirements, it may not be 'correct'.
It's scattered throughout the code base (wifi drivers aren't an
exception here either
On Wednesday, December 18, 2013 2:43:28 pm Adrian Chadd wrote:
> [snip]
>
> So the standard trop of UNLOCK/WORK/RELOCK is pretty dangerous.
> There's no state re-validation going on when you re-acquire that lock.
> So, although it meets the lock requirements, it may not be 'correct'.
>
> It's sca
John Baldwin wrote, On 12/23/2013 17:50:
It needs fixing, but the fix needs to be correct.
Though a fix should not be delayed by decades...
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsub
On 24 December 2013 12:41, wrote:
> John Baldwin wrote, On 12/23/2013 17:50:
>
>> It needs fixing, but the fix needs to be correct.
>
>
> Though a fix should not be delayed by decades...
THe problem here is that a lot of people (and no offence to the patch
author or other developers!) just go "U
On 17 December 2013 22:41, wrote:
> Jean-Sébastien Pédron wrote, On 12/17/2013 22:20:
>
>> On 16.12.2013 08:36, d...@gmx.com wrote:
>>>
>>> Still nobody wants to apply Robert Noland's DRM patch?
>>
>>
>> What problem(s) does this patch fix?
>
>
> It fixes non-deterministic lockups when the (old,
Adrian Chadd wrote, On 12/30/2013 22:17:
On 17 December 2013 22:41, wrote:
It fixes non-deterministic lockups when the (old, drm1) r300 drivers are
used.
According to John Baldwin [1]: "The drm code is doing a copyin() while
holding a mutex (which is not allowed)." The latest version of the p
On 30 December 2013 16:32, wrote:
>
>
> Oops, I meant panics, not lockups. The kernel panics exactly because -- as I
> gather -- the assertions are already there.
>
> There are lockup issues even with the patch applied (for the most part, only
> when using, in Xorg.conf: Option "AccelMethod" "EXA
25 matches
Mail list logo
