Re: new Xorg (KMS, etc.) for Radeon 9600
On 17 December 2013 22: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) 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 patch (also the one I used for years) is at [2], linked from [3]. Hm. Well, can we add some lock assertions to the dri code to panic whenever this is done? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
Adrian Chadd wrote, On 12/30/2013 22:17: On 17 December 2013 22:41, d...@gmx.com 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 patch (also the one I used for years) is at [2], linked from [3]. Hm. Well, can we add some lock assertions to the dri code to panic whenever this is done? 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). ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On 30 December 2013 16:32, d...@gmx.com 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). Ok. i have hangs with i915 on -HEAD where the mouse pointer works fine, but the gui and console just locks up. It happens when I start playing video. It's very random - just random enough for me to grr :) -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On 24 December 2013 12:41, d...@gmx.com 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 UNLOCK; FOO; LOCK WORKS FOR ME and moves on. 99% of the time it's working by magic, rather than working by intention. The trouble is that it's working, so there's no reason to invest the real time in fixing the poor locking in the first place. :) -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 scattered throughout the code base (wifi drivers aren't an exception here either, sigh.) Just something to keep in mind when you validate the 'correctness' of this kind of lock hack. Agreed. It needs fixing, but the fix needs to be correct. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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) 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 patch (also the one I used for years) is at [2], linked from [3]. [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch [3] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html Oh, I didn't notice that the patch targets the old driver, not the new KMS one. I must admit this part isn't my priority and I'm already busy with the new driver. Robert, you worked on this patch a few years ago. Could you please look at it again and maybe commit? -- Jean-Sébastien Pédron signature.asc Description: OpenPGP digital signature
Re: new Xorg (KMS, etc.) for Radeon 9600
[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, sigh.) Just something to keep in mind when you validate the 'correctness' of this kind of lock hack. -adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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
Re: new Xorg (KMS, etc.) for Radeon 9600
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]: The drm code is doing a copyin() while holding a mutex (which is not allowed). The latest version of the patch (also the one I used for years) is at [2], linked from [3]. [1] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/005988.html [2] http://people.freebsd.org/~rnoland/drm_radeon-copyin-fix-try2.patch [3] http://lists.freebsd.org/pipermail/freebsd-current/2009-April/006080.html ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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;
int ret = 0;
+ DRM_UNLOCK();
+
DRM_DEBUG(\n);
/* pacify */
@@ -1205,5 +1207,7 @@
COMMIT_RING();
+ DRM_LOCK();
+
return ret;
}
Index: sys/dev/drm/radeon_irq.c
===
--- sys/dev/drm/radeon_irq.c (revision 259413)
+++ sys/dev/drm/radeon_irq.c (working copy)
@@ -338,10 +338,13 @@
result = radeon_emit_irq(dev);
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(emit-irq_seq, result, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_mem.c
===
--- sys/dev/drm/radeon_mem.c (revision 259413)
+++ sys/dev/drm/radeon_mem.c (working copy)
@@ -246,11 +246,14 @@
if (!block)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(alloc-region_offset, block-start,
sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Index: sys/dev/drm/radeon_state.c
===
--- sys/dev/drm/radeon_state.c (revision 259413)
+++ sys/dev/drm/radeon_state.c (working copy)
@@ -1773,8 +1773,13 @@
}
if (!buf) {
DRM_DEBUG(EAGAIN\n);
- if (DRM_COPY_TO_USER(tex-image, image, sizeof(*image)))
+ DRM_UNLOCK();
+ if (DRM_COPY_TO_USER(tex-image, image,
+ sizeof(*image))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
return -EAGAIN;
}
@@ -1786,10 +1791,13 @@
#define RADEON_COPY_MT(_buf, _data, _width) \
do { \
- if (DRM_COPY_FROM_USER(_buf, _data, (_width))) {\
+ DRM_UNLOCK(); \
+ if (DRM_COPY_FROM_USER(_buf, _data, (_width))) { \
DRM_ERROR(EFAULT on pad, %d bytes\n, (_width)); \
+ DRM_LOCK(); \
return -EFAULT; \
} \
+ DRM_LOCK(); \
} while(0)
if (microtile) {
@@ -2130,9 +2138,13 @@
if (sarea_priv-nbox RADEON_NR_SAREA_CLIPRECTS)
sarea_priv-nbox = RADEON_NR_SAREA_CLIPRECTS;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(depth_boxes, clear-depth_boxes,
- sarea_priv-nbox * sizeof(depth_boxes[0])))
+ sarea_priv-nbox * sizeof(depth_boxes[0]))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
radeon_cp_dispatch_clear(dev, clear, depth_boxes);
@@ -2394,10 +2406,13 @@
return -EINVAL;
}
- if (DRM_COPY_FROM_USER(image,
- (drm_radeon_tex_image_t __user *) tex-image,
- sizeof(image)))
- return -EFAULT;
+ DRM_UNLOCK();
+ ret = -DRM_COPY_FROM_USER(image,
+ (drm_radeon_tex_image_t __user *) tex-image,
+ sizeof(image));
+ DRM_LOCK();
+ if (ret)
+ return ret;
RING_SPACE_TEST_WITH_RETURN(dev_priv);
VB_AGE_TEST_WITH_RETURN(dev_priv);
@@ -2418,8 +2433,12 @@
LOCK_TEST_WITH_RETURN(dev, file_priv);
- if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(mask, stipple-mask, 32 * sizeof(u32))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
RING_SPACE_TEST_WITH_RETURN(dev_priv);
@@ -2546,16 +2565,24 @@
drm_radeon_prim_t prim;
drm_radeon_tcl_prim_t tclprim;
- if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(prim, vertex-prim[i], sizeof(prim))) {
+ DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (prim.stateidx != laststate) {
drm_radeon_state_t state;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(state,
vertex-state[prim.stateidx],
- sizeof(state)))
+ sizeof(state))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
if (radeon_emit_state2(dev_priv, file_priv, state)) {
DRM_ERROR(radeon_emit_state2 failed\n);
@@ -2772,8 +2799,12 @@
do {
if (i cmdbuf-nbox) {
- if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box)))
+ DRM_UNLOCK();
+ if (DRM_COPY_FROM_USER(box, boxes[i], sizeof(box))) {
+DRM_LOCK();
return -EFAULT;
+ }
+ DRM_LOCK();
/* FIXME The second and subsequent times round
* this loop, send a WAIT_UNTIL_3D_IDLE before
* calling emit_clip_rect(). This fixes a
@@ -2866,11 +2897,14 @@
kbuf = drm_alloc(cmdbuf-bufsz, DRM_MEM_DRIVER);
if (kbuf == NULL)
return -ENOMEM;
+ DRM_UNLOCK();
if (DRM_COPY_FROM_USER(kbuf, (void __user *)cmdbuf-buf,
cmdbuf-bufsz)) {
+ DRM_LOCK();
drm_free(kbuf, orig_bufsz, DRM_MEM_DRIVER);
return -EFAULT;
}
+ DRM_LOCK();
cmdbuf-buf = kbuf;
}
@@ -3089,10 +3123,13 @@
return -EINVAL;
}
+ DRM_UNLOCK();
if (DRM_COPY_TO_USER(param-value, value, sizeof(int))) {
DRM_ERROR(copy_to_user\n);
+ DRM_LOCK();
return -EFAULT;
}
+ DRM_LOCK();
return 0;
}
Re: new Xorg (KMS, etc.) for Radeon 9600
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 missing in radeon_ttm.c. It's hidden behind #ifdef DUMBBELL_WIP. Yes. I looked at it today: the work is non-trivial and I don't have the required knowledge to do it alone. I'll talk about it to Konstantin Belousov as the time permits. -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 problem, can you post the output of the following commands
as a start?
pciconf -lvbce
devinfo -vr
The attached patch should fix it, but I haven't been able to test it
yet. The ai_aperture_size field is in bytes.
Index: sys/dev/drm2/radeon/radeon_agp.c
===
--- sys/dev/drm2/radeon/radeon_agp.c (revision 258128)
+++ sys/dev/drm2/radeon/radeon_agp.c (working copy)
@@ -153,11 +153,11 @@ int radeon_agp_init(struct radeon_device
return ret;
}
- if (rdev-ddev-agp-info.ai_aperture_size 32) {
+ if (rdev-ddev-agp-info.ai_aperture_size (32 20)) {
drm_agp_release(rdev-ddev);
dev_warn(rdev-dev, AGP aperture too small (%zuM)
need at least 32M, disabling AGP\n,
- rdev-ddev-agp-info.ai_aperture_size);
+ rdev-ddev-agp-info.ai_aperture_size 20);
return -EINVAL;
}
@@ -246,7 +246,7 @@ int radeon_agp_init(struct radeon_device
}
rdev-mc.agp_base = rdev-ddev-agp-info.ai_aperture_base;
- rdev-mc.gtt_size = rdev-ddev-agp-info.ai_aperture_size 20;
+ rdev-mc.gtt_size = rdev-ddev-agp-info.ai_aperture_size;
rdev-mc.gtt_start = rdev-mc.agp_base;
rdev-mc.gtt_end = rdev-mc.gtt_start + rdev-mc.gtt_size - 1;
dev_info(rdev-dev, GTT: %juM 0x%08jX - 0x%08jX\n,
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 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 devinfo -vr 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: drmn0: info: GTT: 256M 0xE000 - 0xEFFF info: [drm] Generation 2 PCI interface, using max accessible memory drmn0: info: VRAM: 128M 0xD000 - 0xD7FF (64M used) info: [drm] Supports vblank timestamp caching Rev 1 (10.10.2010). info: [drm] Driver supports precise vblank timestamp query. info: [drm] radeon: irq initialized. info: [drm] Detected VRAM RAM=128M, BAR=128M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 519536 kiB [TTM] Initializing pool allocator info: [drm] radeon: 64M of VRAM memory ready info: [drm] radeon: 256M of GTT memory ready. info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. error: [drm:pid54242:radeon_gart_bind] *ERROR* trying to bind memory to uninitialized GART ! error: [drm:pid54242:radeon_ttm_backend_bind] *ERROR* failed to bind 1 pages at 0x drmn0: warning: (-22) create WB bo failed drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon: cp finalized [TTM] Finalizing pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB info: [drm] radeon: ttm finalized info: [drm] Forcing AGP to PCI mode It looks like some support for AGP is missing in radeon_ttm.c. It's hidden behind #ifdef DUMBBELL_WIP. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82865G/PE/P DRAM Controller/Host-Hub Interface' class = bridge subclass = HOST-PCI bar [10] = type Prefetchable Memory, range 32, base 0xf000, size 134217728, enabled cap 09[e4] = vendor (length 6) Intel cap 0 version 1 cap 02[a0] = AGP v3 8x 4x SBA disabled PCI errors = Received Master-Abort pcib1@pci0:0:1:0: class=0x060400 card=0x chip=0x25718086 rev=0x02 hdr=0x01 vendor = 'Intel Corporation' device = '82865G/PE/P AGP Bridge' class = bridge subclass = PCI-PCI uhci0@pci0:0:29:0: class=0x0c0300 card=0x24d01849 chip=0x24d28086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe000, size 32, enabled uhci1@pci0:0:29:1: class=0x0c0300 card=0x24d01849 chip=0x24d48086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe400, size 32, enabled uhci2@pci0:0:29:2: class=0x0c0300 card=0x24d01849 chip=0x24d78086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xe800, size 32, enabled uhci3@pci0:0:29:3: class=0x0c0300 card=0x24d01849 chip=0x24de8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB UHCI Controller' class = serial bus subclass = USB bar [20] = type I/O Port, range 32, base 0xec00, size 32, enabled ehci0@pci0:0:29:7: class=0x0c0320 card=0x24d01849 chip=0x24dd8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) USB2 EHCI Controller' class = serial bus subclass = USB bar [10] = type Memory, range 32, base 0xff2ffc00, size 1024, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 cap 0a[58] = EHCI Debug Port at offset 0xa0 in map 0x14 pcib2@pci0:0:30:0: class=0x060400 card=0x chip=0x244e8086 rev=0xc2 hdr=0x01 vendor = 'Intel Corporation' device = '82801 PCI Bridge' class = bridge subclass = PCI-PCI isab0@pci0:0:31:0: class=0x060100 card=0x chip=0x24d08086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) LPC Interface Bridge' class = bridge subclass = PCI-ISA atapci0@pci0:0:31:1:class=0x01018a card=0x24d01849 chip=0x24db8086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) IDE Controller' class = mass storage subclass = ATA bar [20] = type I/O Port, range 32, base 0xfc00, size 16, enabled bar [24] = type Memory, range 32, base 0, size 1024, enabled none0@pci0:0:31:3: class=0x0c0500 card=0x24d01849 chip=0x24d38086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) SMBus Controller' class = serial bus subclass = SMBus bar [20] = type I/O Port, range 32, base 0x400, size 32, enabled pcm0@pci0:0:31:5: class=0x040100 card=0x97611849 chip=0x24d58086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = '82801EB/ER (ICH5/ICH5R) AC'97 Audio Controller' class = multimedia subclass = audio bar [10] = type I/O Port, range 32, base 0xd800, size 256, enabled bar [14] = type I/O Port, range 32, base 0xdc00, size 64, enabled bar [18] = type Memory, range 32, base 0xff2ff800, size 512, enabled bar [1c] = type Memory, range 32, base 0xff2ff400, size 256, enabled cap 01[50] = powerspec 2 supports D0 D3 current D0 vgapci0@pci0:1:0:0: class=0x03 card=0x200217ee chip=0x41501002 rev=0x00 hdr=0x00 vendor = 'Advanced Micro Devices [AMD] nee ATI' device = 'RV350 AP [Radeon 9600]' class = display subclass = VGA bar [10] = type Prefetchable Memory, range 32, base 0xd000, size 268435456, enabled bar [14] = type I/O Port, range 32, base 0xa800, size 256, enabled bar [18] = type Memory, range 32, base 0xff0f, size 65536, enabled cap 02[58] = AGP v3 8x 4x SBA disabled cap 01[50] = powerspec 2 supports D0 D1 D2 D3 current D0 vgapci1@pci0:1:0:1: class=0x038000 card=0x200317ee chip=0x41701002 rev=0x00
Re: new Xorg (KMS, etc.) for Radeon 9600
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 haven't been able to test it yet. The ai_aperture_size field is in bytes. Doesn't help in practice (the program still should run faster), although now I get: drmn0: info: GTT: 128M 0xF000 - 0xF7FF ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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? pciconf -lvbce devinfo -vr Thanks! -- Jean-Sébastien Pédron ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 /boot/kernel/radeonkmsfw_R300_cp.ko. Oops, my bad. I had WITHOUT_SOURCELESS=1 in /etc/src.conf. Now the said 3D application works, though the performance is crappier than with the old Xorg... That could be because of this: info: [drm] Detected VRAM RAM=256M, BAR=256M info: [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 257392 kiB [TTM] Initializing pool allocator info: [drm] radeon: 128M of VRAM memory ready info: [drm] radeon: 0M of GTT memory ready. info: [drm] radeon: 1 quad pipes, 1 Z pipes initialized. drmn0: warning: (-12) create WB bo failed drmn0: error: Disabling GPU acceleration info: [drm] radeon: cp finalized info: [drm] radeon: cp finalized [TTM] Finalizing pool allocator [TTM] Zone kernel: Used memory at exit: 0 kiB info: [drm] radeon: ttm finalized info: [drm] Forcing AGP to PCI mode It fails to use AGP. I have the same problem. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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_init] *ERROR* Failed to load firmware! drmn0: error: failed initializing CP (-2). drmn0: error: Disabling GPU acceleration Make sure you have /boot/kernel/radeonkmsfw_R300_cp.ko. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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_SOURCELESS=1 in /etc/src.conf. Now the said 3D application works, though the performance is crappier than with the old Xorg... ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
new Xorg (KMS, etc.) for Radeon 9600
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 == CPUTYPE?=native CXXFLAGS+= -stdlib=libc++ KERNCONF=MYKERNCONF MODULES_OVERRIDE=drm2 == /etc/make.conf snippet ends == == /sys/i386/conf/MYKERNCONF begins == cpu I686_CPU ident MYKERNCONF options SCHED_ULE # ULE scheduler options PREEMPTION # Enable kernel thread preemption options INET# InterNETworking options FFS # Berkeley Fast Filesystem options SOFTUPDATES # Enable FFS soft updates support options UFS_DIRHASH # Improve performance on big directories options MD_ROOT # MD is a potential root device options MSDOSFS # MSDOS Filesystem options GEOM_PART_GPT # GUID Partition Tables. options GEOM_LABEL # Provides labelization options COMPAT_FREEBSD4 # Compatible with FreeBSD4 options COMPAT_FREEBSD5 # Compatible with FreeBSD5 options COMPAT_FREEBSD6 # Compatible with FreeBSD6 options COMPAT_FREEBSD7 # Compatible with FreeBSD7 options SCSI_DELAY=1000 # Delay (in ms) before probing SCSI options SYSVSHM # SYSV-style shared memory options SYSVMSG # SYSV-style message queues options SYSVSEM # SYSV-style semaphores options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time extensions options PRINTF_BUFR_SIZE=128# Prevent printf output being interspersed. # To make an SMP kernel, the next two lines are needed options SMP # Symmetric MultiProcessor Kernel device apic# I/O APIC # Bus support. device acpi device pci # ATA controllers device ata # Legacy ATA/SATA controllers # ATA/SCSI peripherals device scbus # SCSI bus (required for ATA/SCSI) device da # Direct Access (disks) # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbdc # AT keyboard controller device atkbd # AT keyboard device vga # VGA video card driver # syscons is the default console driver, resembling an SCO console device sc device agp # support several AGP chipsets # PCI Ethernet NICs that use the common MII bus controller code. # NOTE: Be sure to keep the 'device miibus' line in order to use these NICs! device miibus # MII bus support device rl # RealTek 8129/8139 # Pseudo devices. device loop# Network loopback device random # Entropy device device ether # Ethernet support device md # Memory disks device firmware# firmware assist module # USB support device uhci# UHCI PCI-USB interface device ohci# OHCI PCI-USB interface device ehci# EHCI PCI-USB interface (USB 2.0) device usb # USB Bus (required) device umass # Disks/Mass storage - Requires scbus and da device ums # Mouse # Sound support device sound # Generic sound driver (required) device snd_ich # Intel, NVidia and other ICH AC'97 Audio device drm device radeondrm device iicbus device iic device iicbb == /sys/i386/conf/MYKERNCONF ends == == /etc/X11/xorg.conf begins == Section ServerFlags Option DontZoom on Option VTSysReq on # #Option BlankTime 1 # #Option StandbyTime 2 # #Option SuspendTime 3 # #Option OffTime 4 # Option HandleSpecialKeys Always Option AIGLX off Option GlxVisuals minimal Option AllowEmptyInput off Option AutoAddDevices off Option AutoEnableDevices off EndSection Section InputDevice Identifier mouse1 Driver mouse Option Device /dev/ums0 EndSection Section InputDevice Identifier keyboard1 Driver kbd Option XkbLayout us,hu Option AutoRepeat 320 29 EndSection Section Device Identifier card1 Driver radeon VideoRam 131072 #Option ScalerWidth 1920 Option AGPMode 8 #Option AGPFastWrite on # sux Option BusType AGP Option DisplayPriority HIGH Option
Re: new Xorg (KMS, etc.) for Radeon 9600
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 out of your kernel configuration and let X load the necessary drm2 devices when it starts. This allowed it to work for me. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
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 panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. == dmesg begins == Copyright (c) 1992-2013 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 11.0-CURRENT #6 r257831M: Sun Nov 10 17:55:45 CET 2013 root@:/usr/obj/usr/src/sys/CUSTOM i386 clang version 3.4 (trunk 194164) CPU: Intel(R) Pentium(R) 4 CPU 3.00GHz (2999.72-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf41 Family = 0xf Model = 0x4 Stepping = 1 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x441dSSE3,DTES64,MON,DS_CPL,CNXT-ID,xTPR TSC: P-state invariant real memory = 536870912 (512 MB) avail memory = 515149824 (491 MB) Event timer LAPIC quality 400 ACPI APIC Table: A M I OEMAPIC FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 1 core(s) x 2 HTT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP/HT): APIC ID: 1 ioapic0: Changing APIC ID to 2 ioapic0 Version 2.0 irqs 0-23 on motherboard random: Software, Yarrow initialized acpi0: A M I OEMRSDT on motherboard acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1ff0 (3) failed cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 attimer0: AT timer port 0x40-0x43 irq 0 on acpi0 Timecounter i8254 frequency 1193182 Hz quality 0 Event timer i8254 frequency 1193182 Hz quality 100 atrtc0: AT realtime clock port 0x70-0x71 irq 8 on acpi0 Event timer RTC frequency 32768 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 900 acpi_timer0: 24-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: Intel 82865 host to AGP bridge on hostb0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0: VGA-compatible display port 0xa800-0xa8ff mem 0xd000-0xdfff,0xff0f-0xff0f irq 16 at device 0.0 on pci1 vgapci1: VGA-compatible display mem 0xc000-0xcfff,0xff0e-0xff0e at device 0.1 on pci1 uhci0: Intel 82801EB (ICH5) USB controller USB-A port 0xe000-0xe01f irq 16 at device 29.0 on pci0 usbus0 on uhci0 uhci1: Intel 82801EB (ICH5) USB controller USB-B port 0xe400-0xe41f irq 19 at device 29.1 on pci0 usbus1 on uhci1 uhci2: Intel 82801EB (ICH5) USB controller USB-C port 0xe800-0xe81f irq 18 at device 29.2 on pci0 usbus2 on uhci2 uhci3: Intel 82801EB (ICH5) USB controller USB-D port 0xec00-0xec1f irq 16 at device 29.3 on pci0 usbus3 on uhci3 ehci0: Intel 82801EB/R (ICH5) USB 2.0 controller mem 0xff2ffc00-0xff2f irq 23 at device 29.7 on pci0 usbus4: EHCI version 1.0 usbus4 on ehci0 pcib2: ACPI PCI-PCI bridge at device 30.0 on pci0 pci2: ACPI PCI bus on pcib2 rl0: RealTek 8139 10/100BaseTX port 0xb800-0xb8ff mem 0xff1ffc00-0xff1ffcff irq 22 at device 5.0 on pci2 miibus0: MII bus on rl0 rlphy0: RealTek internal media interface PHY 0 on miibus0 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: Ethernet address: 00:25:22:10:7c:de isab0: PCI-ISA bridge at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH5 UDMA100 controller port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xfc00-0xfc0f at device 31.1 on pci0 ata0: ATA channel at channel 0 on atapci0 ata1: ATA channel at channel 1 on atapci0 pci0: serial bus, SMBus at device 31.3 (no driver attached) pcm0: Intel ICH5 (82801EB) port 0xd800-0xd8ff,0xdc00-0xdc3f mem 0xff2ff800-0xff2ff9ff,0xff2ff400-0xff2ff4ff irq 17 at device 31.5 on pci0 pcm0: C-Media Electronics CMI9761 AC97 Codec acpi_button0: Power Button on acpi0 atkbdc0: Keyboard controller (i8042) port 0x60,0x64 irq 1 on acpi0 atkbd0: AT Keyboard irq 1 on atkbdc0 atkbd0: [GIANT-LOCKED] orm0: ISA Option ROM at iomem 0xc-0xccfff pnpid ORM on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 acpi_throttle0: ACPI CPU Throttling on cpu0 Timecounters tick every 1.000 msec random: unblocking device. usbus0: 12Mbps Full Speed USB v1.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 12Mbps Full Speed USB v1.0 usbus3: 12Mbps Full Speed USB v1.0 usbus4: 480Mbps High Speed USB v2.0 ugen1.1: Intel at usbus1 uhub0: Intel UHCI root HUB, class 9/0, rev 1.00/1.00,
Re: new Xorg (KMS, etc.) for Radeon 9600
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 starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. Yes, I can get it to crash also when using a Java-based GUI, but it works for all the basic X apps that I need. I also have the virtual terminal switching problem also, but I think that is being addressed with newsyscons. It really does suck not having a functional X. -- DE ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: new Xorg (KMS, etc.) for Radeon 9600
On Sun, Nov 10, 2013 at 9:34 AM, Daniel Eischen deisc...@freebsd.orgwrote: 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 starts. This allowed it to work for me. Hmm, works for me to avoid panics and hard reboots. Problems: 1. Switching to the virtual terminals or shutting down X causes the display to go black and unrevivable -- a (soft) reboot is necessary. 2. A 3D application crashes with SIGBUS, and the stack gets toasted. Yes, I can get it to crash also when using a Java-based GUI, but it works for all the basic X apps that I need. I also have the virtual terminal switching problem also, but I think that is being addressed with newsyscons. It really does suck not having a functional X. For the record, newcons (not newsyscons) is available for testing. I'll admit that I have not tried it, but there have been quite a few positive reports on it. https://wiki.freebsd.org/Newcons. -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.com ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
