Re: 2.6.34-rc3-git6: Reported regressions from 2.6.33
On Wed, Apr 07, 2010 at 11:08:30PM +0200, Rafael J. Wysocki wrote: Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=15551 Subject : WARNING: at net/mac80211/work.c:811 ieee80211_work_work+0x7f/0xde8 [mac80211]() Submitter : Alex Zhavnerchik alex.vi...@gmail.com Date : 2010-03-16 22:03 (23 days old) I sent a pull request with the patch for this to Dave M. today. :-) John -- John W. LinvilleSomeday the world will need a hero, and you linvi...@tuxdriver.com might be all we have. Be ready. -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Mesa3d-dev] DRI SDK and modularized drivers.
Pulling drm back out of the kernel tree seems like a hard sell, but the ddx/mesa hw driver/libdrm set seemed like it might be a good candidate for grouping. I guess the core question is whether we expect the X-to-ddx and mesa-to-hw-driver interfaces to be more or less volatile than the ddx-to-libdrm and mesa-hw-driver-to-libdrm interfaces over the next couple of years. On the core-to-driver interface side we have the Gallium3D and GL 3/4 work, and on the libdrm interface side we have ongoing improvements in memory management and command submission. Tough call. I guess another option would be a pseudo-modular approach where the code stays in the current trees but we adopt versioning and build/test procedures which treat ddx/mesahw/libdrm as a single code base even if the code is still living in multiple projects. That might be an easy first step, but repartitioning the code does seem like a better long-term approach. If the drm code were omitted from the proposal and we focused only on ddx/libdrm/mesahw would that help ? -Original Message- From: xorg-boun...@lists.freedesktop.org [mailto:xorg-boun...@lists.freedesktop.org] On Behalf Of Nicolai Haehnle Sent: Friday, March 19, 2010 1:26 PM To: Luc Verhaegen Cc: dri-devel@lists.sourceforge.net; mesa3d-...@lists.sourceforge.net; x...@lists.freedesktop.org Subject: Re: [Mesa3d-dev] DRI SDK and modularized drivers. On Thu, Mar 18, 2010 at 5:38 PM, Luc Verhaegen l...@skynet.be wrote: So, identify the volatile interfaces, and the more stable interfaces, and then isolate the volatile ones, and then you come to only one conclusion. Except that the Mesa core - classic driver interface also wants to change from time to time in non-trivial ways, and trying to force a separation there on people who don't want an additional set of compatibility issues to deal with is not exactly a friendly move. It may seem e.g. like the DRM interface is the worst because of rather large threads caused by certain kernel developer's problems, but that doesn't mean problems wouldn't be created by splitting other areas. In particular, the Mesa core - classic driver split only makes sense if there are enough people who are actually working on those drivers who would support the split. Otherwise, this is bound to lead straight into hell. In a way, the kernel people got it right: put all the drivers in one repository, and make building the whole package and having parallel installations trivial. The (only?) issues with that in X.org are that: 1) there is a cultural aversion due to the bad experience with the horrible pre-modularization setup, and 2) it wouldn't actually solve the DRM problems, because we want to have the DRM in our codebase, and the kernel people want to have it in theirs. cu, Nicolai ___ x...@lists.freedesktop.org: X.Org support Archives: http://lists.freedesktop.org/archives/xorg Info: http://lists.freedesktop.org/mailman/listinfo/xorg -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon KMS regression still present in 2.6.33-rc6
On Sat, Jan 30, 2010 at 8:54 PM, Linus Torvalds torva...@linux-foundation.org wrote: On Sat, 30 Jan 2010, Johannes Hirte wrote: This is caused by commit 42590a75019a50012f25a962246498dead42843 Fix is already posted: http://marc.info/?l=linux-kernelm=126428141429200w=2 Goodie. Kevin, can you test the patch from FUJITA Tomonori in that thread (http://marc.info/?l=linux-kernelm=126439631307219w=2; to be exact). The little hunk of code that Kevin posted is also the source of a new warning in -rc6, which is easily fixed. (following up with a patch) Assuming the patch in that link fixes the problem, the order of the check of the aper_size in radeon_agp_init appears incorrect to me. Also following up with a patch. John Kacur -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] radeon_agp: Fix warning, format ‘%d’ expects type ‘int’, but argument 4 has type ‘size_t’
On Sun, 31 Jan 2010, Dan Nicholson wrote:
On Sat, Jan 30, 2010 at 12:51 PM, John Kacur jka...@redhat.com wrote:
Fix warning by using %zu instead of %d for size_t
Signed-off-by: John Kacur jka...@redhat.com
---
drivers/gpu/drm/radeon/radeon_agp.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index c9ad7f5..1c4e523 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -134,7 +134,7 @@ int radeon_agp_init(struct radeon_device *rdev)
int ret;
if (rdev-ddev-agp-agp_info.aper_size 32) {
- dev_warn(rdev-dev, AGP aperture to small (%dM)
+ dev_warn(rdev-dev, AGP aperture to small (%zuM)
As long as you're fixing this line, you might want to correct the
grammar s/to/too/.
Thanks, I saw that too, after I sent. Unfortunately, I have to respin both
patches, because there is a merge conflict after fixing the
grammar/spelling mistake.
Both patches coming up, in a separate mail.
John--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 1/2] =?utf-8?q?radeon=5Fagp:=20Fix=20warning, =20format=20=E2=80=98%d=E2=80=99=20expects=20type=20=E2=80=98int=E2=80=99, =20but=20argument=204=20has=20type=20=E2=80=98size=5Ft=E2=80=99?=
- Fix warning by using %zu instead of %d for size_t
- Fix spelling mistake, to should be too.
Signed-off-by: John Kacur jka...@redhat.com
---
drivers/gpu/drm/radeon/radeon_agp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index c9ad7f5..f58c5f4 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -134,7 +134,7 @@ int radeon_agp_init(struct radeon_device *rdev)
int ret;
if (rdev-ddev-agp-agp_info.aper_size 32) {
- dev_warn(rdev-dev, AGP aperture to small (%dM)
+ dev_warn(rdev-dev, AGP aperture too small (%zuM)
need at least 32M, disabling AGP\n,
rdev-ddev-agp-agp_info.aper_size);
return -EINVAL;
--
1.6.0.6
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 0/2] radeon_agp_init fixes
radeon_agp_init fixes: John Kacur (2): radeon_agp: Fix warning, format â%dâ expects type âintâ, but argument 4 has type âsize_tâ. Also fix grammar/spelling error, change to to too radeon_agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info drivers/gpu/drm/radeon/radeon_agp.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH 2/2] radeon_agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info
First call drm_agp_acquire to check if agp has been acquired.
Second call drm_agp_info to fill in the info data struct, including aper_size.
Finally do the check to see if the aper_size makes sense.
Signed-off-by: John Kacur jka...@redhat.com
---
drivers/gpu/drm/radeon/radeon_agp.c | 15 ---
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index f58c5f4..b634d98 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -133,13 +133,6 @@ int radeon_agp_init(struct radeon_device *rdev)
bool is_v3;
int ret;
- if (rdev-ddev-agp-agp_info.aper_size 32) {
- dev_warn(rdev-dev, AGP aperture too small (%zuM)
- need at least 32M, disabling AGP\n,
- rdev-ddev-agp-agp_info.aper_size);
- return -EINVAL;
- }
-
/* Acquire AGP. */
if (!rdev-ddev-agp-acquired) {
ret = drm_agp_acquire(rdev-ddev);
@@ -154,6 +147,14 @@ int radeon_agp_init(struct radeon_device *rdev)
DRM_ERROR(Unable to get AGP info: %d\n, ret);
return ret;
}
+
+ if (rdev-ddev-agp-agp_info.aper_size 32) {
+ dev_warn(rdev-dev, AGP aperture too small (%zuM)
+ need at least 32M, disabling AGP\n,
+ rdev-ddev-agp-agp_info.aper_size);
+ return -EINVAL;
+ }
+
mode.mode = info.mode;
agp_status = (RREG32(RADEON_AGP_STATUS) | RADEON_AGPv3_MODE)
mode.mode;
is_v3 = !!(agp_status RADEON_AGPv3_MODE);
--
1.6.0.6
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] =?utf-8?q?radeon=5Fagp:=20Fix=20warning, =20format=20=E2=80=98%d=E2=80=99=20expects=20type=20=E2=80=98int=E2=80=99, =20but=20argument=204=20has=20type=20=E2=80=98size=5Ft=E2=80=99?=
Fix warning by using %zu instead of %d for size_t
Signed-off-by: John Kacur jka...@redhat.com
---
drivers/gpu/drm/radeon/radeon_agp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/radeon/radeon_agp.c
b/drivers/gpu/drm/radeon/radeon_agp.c
index c9ad7f5..1c4e523 100644
--- a/drivers/gpu/drm/radeon/radeon_agp.c
+++ b/drivers/gpu/drm/radeon/radeon_agp.c
@@ -134,7 +134,7 @@ int radeon_agp_init(struct radeon_device *rdev)
int ret;
if (rdev-ddev-agp-agp_info.aper_size 32) {
- dev_warn(rdev-dev, AGP aperture to small (%dM)
+ dev_warn(rdev-dev, AGP aperture to small (%zuM)
need at least 32M, disabling AGP\n,
rdev-ddev-agp-agp_info.aper_size);
return -EINVAL;
--
1.6.0.6
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] radeon_agp_init fixes
radeon_agp_init fixes John Kacur (2): radeon_agp: Fix warning, format â%dâ expects type âintâ, but argument 4 has type âsize_tâ radeon_agp: Move the check of the aper_size after drm_acp_acquire and drm_agp_info drivers/gpu/drm/radeon/radeon_agp.c | 15 --- 1 files changed, 8 insertions(+), 7 deletions(-) -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com-- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [OOPS] radeon kms
On Fri, 15 Jan 2010, Jerome Glisse wrote: On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote: On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] RSP 8801a1a8fb68 CR2: 0048 ---[ end trace 604e2e318733e108 ]--- udevd-work[166]: '/sbin/modprobe -b pci:v1002d9498sv1043sd0300bc 03sc00i00' unexpected exit with status 0x0009 I forgot to mention that this is kernel version 2.6.33-rc4. Thanks. Yes, we didn't paid enough attention to failure path :( Sorry for that Fix should be in next rc, patch
Re: [OOPS] radeon kms
On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 9:10 AM, John Kacur jka...@redhat.com wrote: On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 8:21 AM, John Kacur jka...@redhat.com wrote: On Fri, 15 Jan 2010, Jerome Glisse wrote: On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote: On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] RSP 8801a1a8fb68 CR2: 0048 ---[ end trace 604e2e318733e108 ]--- udevd-work[166]: '/sbin/modprobe
Re: [OOPS] radeon kms
On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 8:21 AM, John Kacur jka...@redhat.com wrote: On Fri, 15 Jan 2010, Jerome Glisse wrote: On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote: On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] RSP 8801a1a8fb68 CR2: 0048 ---[ end trace 604e2e318733e108 ]--- udevd-work[166]: '/sbin/modprobe -b pci:v1002d9498sv1043sd0300bc 03sc00i00' unexpected exit with status 0x0009 I forgot to mention that this is kernel
Re: [OOPS] radeon kms
On Tue, 26 Jan 2010, Gene Heskett wrote: On Tuesday 26 January 2010, John Kacur wrote: On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 9:10 AM, John Kacur jka...@redhat.com wrote: On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 8:21 AM, John Kacur jka...@redhat.com wrote: On Fri, 15 Jan 2010, Jerome Glisse wrote: On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote: On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034
Re: [OOPS] radeon kms
On Tue, Jan 26, 2010 at 9:20 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 9:35 AM, John Kacur jka...@redhat.com wrote: On Tue, Jan 26, 2010 at 3:19 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 9:10 AM, John Kacur jka...@redhat.com wrote: On Tue, Jan 26, 2010 at 2:59 PM, Alex Deucher alexdeuc...@gmail.com wrote: On Tue, Jan 26, 2010 at 8:21 AM, John Kacur jka...@redhat.com wrote: On Fri, 15 Jan 2010, Jerome Glisse wrote: On Fri, Jan 15, 2010 at 03:47:19PM +0100, John Kacur wrote: On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034
[OOPS] radeon kms
The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] RSP 8801a1a8fb68 CR2: 0048 ---[ end trace 604e2e318733e108 ]--- udevd-work[166]: '/sbin/modprobe -b pci:v1002d9498sv1043sd0300bc 03sc00i00' unexpected exit with status 0x0009 -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [OOPS] radeon kms
On Fri, 15 Jan 2010, John Kacur wrote: The oops is triggered because I am missing the firmware for radeon/R700_rlc.bin and radeon/R600_rlc.bin However, I think it should be able to deal with this more gracefully. ATOM BIOS: 9498.11.22.6.0.AS03 [drm] Clocks initialized ! [drm] Detected VRAM RAM=256M, BAR=256M [drm] RAM width 128bits DDR [TTM] Zone kernel: Available graphics memory: 3050912 kiB. [TTM] Zone dma32: Available graphics memory: 2097152 kiB. [drm] radeon: 256M of VRAM memory ready [drm] radeon: 512M of GTT memory ready. alloc irq_desc for 33 on node -1 alloc kstat_irqs on node -1 radeon :02:00.0: irq 33 for MSI/MSI-X [drm] radeon: using MSI. [drm] radeon: irq initialized. [drm] GART: num cpu pages 131072, num gpu pages 131072 [drm] Loading RV730 Microcode platform radeon_cp.0: firmware: requesting radeon/RV730_pfp.bin platform radeon_cp.0: firmware: requesting radeon/RV730_me.bin platform radeon_cp.0: firmware: requesting radeon/R700_rlc.bin r600_cp: Failed to load firmware radeon/R700_rlc.bin [drm:rv770_startup] *ERROR* Failed to load firmware! radeon :02:00.0: 8801a20b5400 unpin not necessary BUG: unable to handle kernel NULL pointer dereference at 0048 IP: [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] PGD 1a1a74067 PUD 1a19b8067 PMD 0 Oops: [#1] SMP last sysfs file: /sys/devices/platform/radeon_cp.0/firmware/radeon_cp.0/loading CPU 4 Pid: 168, comm: modprobe Not tainted 2.6.33-rc4 #3 EX58-UD3R/EX58-UD3R RIP: 0010:[a0061034] [a0061034] ttm_bo_reserve+0x16/0xf8 [t tm] RSP: 0018:8801a1a8fb68 EFLAGS: 00010292 RAX: 8801 RBX: RCX: RDX: RSI: 0001 RDI: 0048 RBP: 8801a1a8fba8 R08: R09: R10: R11: R12: R13: 8801a8838000 R14: 0024 R15: 2000 FS: 7f0f9c6dc700() GS:88002e40() knlGS: CS: 0010 DS: ES: CR0: 8005003b CR2: 0048 CR3: 0001a195d000 CR4: 06e0 DR0: DR1: DR2: DR3: DR6: 0ff0 DR7: 0400 Process modprobe (pid: 168, threadinfo 8801a1a8e000, task 8801a22c) Stack: 8801 8801a27e2900 8801a1a8fb88 0 8801a8838000 0024 2000 0 8801a1a8fbd8 a00ba05b 8801a1a8fbd8 8801a27f4000 Call Trace: [a00ba05b] radeon_bo_reserve.clone.0+0x2a/0x6d [radeon] [a00bb441] rv770_suspend+0x43/0x69 [radeon] [a00bb6cf] rv770_init+0x1a4/0x22d [radeon] [a0089593] radeon_device_init+0x27f/0x300 [radeon] [a008a0fb] radeon_driver_load_kms+0xff/0x184 [radeon] [a001e1a6] drm_get_dev+0x3c4/0x4c5 [drm] [8122ea73] ? pci_match_device+0x22/0xd0 [a00c3bb8] radeon_pci_probe+0x15/0x268 [radeon] [8122e941] local_pci_probe+0x17/0x1b [8122f721] pci_device_probe+0xcd/0xfd [812ce793] ? driver_sysfs_add+0x4c/0x71 [812ce95c] driver_probe_device+0xde/0x1fe [812cead9] __driver_attach+0x5d/0x81 [812cea7c] ? __driver_attach+0x0/0x81 [812cdded] bus_for_each_dev+0x59/0x8e [812ce6f2] driver_attach+0x1e/0x20 [812ce330] bus_add_driver+0xd8/0x240 [812cedcb] driver_register+0x9d/0x10e [8122f969] __pci_register_driver+0x68/0xd8 [81439aa2] ? printk+0x41/0x47 [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a0018eb3] drm_init+0x75/0xdb [drm] [a00f7000] ? radeon_init+0x0/0xc1 [radeon] [a00f70bf] radeon_init+0xbf/0xc1 [radeon] [81002069] do_one_initcall+0x5e/0x15e [81087788] sys_init_module+0xd8/0x23a [81009bf2] system_call_fastpath+0x16/0x1b Code: 01 00 00 00 31 c0 48 83 c4 38 5b 41 5c 41 5d 41 5e 41 5f c9 c3 55 48 89 e5 41 57 41 56 41 55 41 54 53 48 83 ec 18 0f 1f 44 00 00 4c 8b 27 48 89 fb 41 88 f5 41 88 d6 41 88 cf 44 89 45 c8 49 81 RIP [a0061034] ttm_bo_reserve+0x16/0xf8 [ttm] RSP 8801a1a8fb68 CR2: 0048 ---[ end trace 604e2e318733e108 ]--- udevd-work[166]: '/sbin/modprobe -b pci:v1002d9498sv1043sd0300bc 03sc00i00' unexpected exit with status 0x0009 I forgot to mention that this is kernel version 2.6.33-rc4. Thanks. -- Throughout its 18-year history, RSA Conference consistently attracts the world's best and brightest in the field, creating opportunities for Conference attendees to learn about information security's most important issues through interactions with peers, luminaries and emerging and established companies. http://p.sf.net/sfu/rsaconf-dev2dev
Re: [PATCH v2] drm: Keep disabled outputs disabled after suspend / resume
On 12/31/2009 12:00 PM, David John wrote: With the current DRM code, an output that has been powered off from userspace will automatically power back on when resuming from suspend. This patch fixes this behaviour. Tested only with the Intel i915 driver on an Intel GM45 Express chipset. Signed-off-by: David John david...@xenontk.org Ping. Any update on this? Correct? Incorrect? Utter rubbish that I should be ashamed of myself? Regards, David. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [PATCH] drm/kms: fix fbdev blanking regression
On 01/07/2010 12:42 AM, Johan Hovold wrote: Yeap. The fix uncovered a bug in your driver. I haven't heard of problems with the other drm drivers. The backlight is handled via the DRI driver I assume. At least i9xx_crtc_dpms is called on powerdown. Can you post your dmesg and kernel config. [snip] Adding the Intel DRM people in CC as well. I have the same issue with my GM45. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream
Would something like mesa/r600_demo be appropriate ? -Original Message- From: Keith Whitwell [mailto:kei...@vmware.com] Sent: Friday, July 17, 2009 9:24 AM To: Harald Welte Cc: dri-devel@lists.sourceforge.net; richard...@via.com.tw; gre...@suse.de; brucech...@via.com.tw; josephc...@via.com.tw; benjamin...@viatech.com Subject: Re: [Patch 0/3] Resubmit VIA Chrome9 DRM via_chrome9 for upstream On Fri, 2009-07-17 at 04:37 -0700, Harald Welte wrote: On Fri, Jul 17, 2009 at 07:09:06PM +1000, Dave Airlie wrote: On Fri, Jul 17, 2009 at 4:36 PM, brucech...@via.com.tw wrote: To whom it may ceoncern: The following 3 patches are the DRM kernel module that support VIA Chorme9 GFX chipset. They are based on 2.6.31-rc3. Please kindly help to integrate into kernel. Is there a userspace, or available documentation to write a userspace to use this code. Dear David, the situation is still like it was some time ago: 1) VIA's 3D Xorg driver cannot be released as FOSS since it cotains 3rd party licensed code 2) VIA is very supportive of anybody in the community who will work on a FOSS 3D driver for Chrome9. However, we are not aware of any such project :( 3) VIA has released all the programming documentation that it has for this specific chipset, it is available from http://www.x.org/docs/via/ What is still missing is the pixel shader documentation, which will join those public documents soon. 4) VIA does not have the resources to write an entirely new 3D driver for Chrome9, especially since future products contain a different, incompatible GPU. I think it's much more useful to focus the resources at getting things right for those future products. So, as you can see, the situation is far from being perfect. However, it could also be much worse. I would be the first person to argue in favour of having some FOSS userspace code against this DRM kernel driver - but I can also understand the practical constraints. Given that the technical issues (32bit ioctl compat, ...) can be adressed, I would hope the driver can get merged. So far I was not aware that there is an absolute precondition of existing 3D FOSS userspace code to get a DRM driver merged. Yes, we all want it. But is it a strong requirement? Maybe VIA can provide some userspace code without putting together an entire driver. A handful of standalone programs that exercise the interface would help evaluate the interfaces and might be sufficient to serve as guide to someone wanting to use this module. A handful would include: -- draw a triangle -- draw a textured triangle -- draw a triangle using indexed vertices -- some sort of occlusion query At least then there would be some concrete examples of this in use so that an interested party wouldn't later have to work from scratch. Keith -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: 2.6.31-rc2: Reported regressions from 2.6.30
On Tue, 2009-07-07 at 03:25 +0200, Andres Freund wrote: There is also http://lkml.org/lkml/2009/6/30/398 : Soft-Lockup/Race in networking in 2.6.31-rc1+195 (possibly caused by netem) There is some similarity between this soft lockup and the one reported in http://www.spinics.net/lists/netdev/msg100957.html. In both, the process is doing both sends and receives on raw sockets. -- John -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Need sample program or tutorial
Couldn't DRI also be used by a non-GL direct-rendering driver, eg. for something like video acceleration ? -Original Message- From: Jerome Glisse [mailto:gli...@freedesktop.org] Sent: Wednesday, May 13, 2009 4:53 AM To: Enno Fennema Cc: dri-devel@lists.sourceforge.net Subject: Re: Need sample program or tutorial On Wed, 2009-05-13 at 10:00 +0200, Enno Fennema wrote: In the absence of much activity on the user list I come for assistance here, I fail miserably in my first attempt to write a direct rendering client. I think DRI is properly installed on my system, at least glxinfo confirms Direct rendering: Yes. As a first step I just want to draw a trangle in a window. My program initializes all kind of things but when it comes to make something current I get probably confused between all contexts and windows/drawables or missed some vital step. Is there anywhere a tutorial that tells me how to write a DRI client program (not how to compile and install DRI) or a very simple program that I could have a look at. Appreciate any pointers. Enno Fennema DRI is a protocol which is here to allow X GL client to directly talk with GL driver and GL driver to talk with X to know where to render. It's not intended to be used by anyone else beyond GL driver or X server. What you want is simply a GL application and there is tons of example out there on how to do one, you could also find examples in mesa/progs/* mese/progs/trivial/tri-* for instance show how to render a simple triangle. So GL app will talk to GL driver which will use DRI on your computer if it's enabled. Cheers, Jerome Glisse -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
RE: Need sample program or tutorial
My understanding was that XF86DRIQueryDirectRenderingCapable just asked the X server if *it* was able to support direct rendering on a particular screen, didn't tell you anything about whether the right 3D driver existed or was installed correctly. I think the convention is to ask for direct when creating a context unless you have a good reason for needing indirect (eg some compositing managers need to use indirect), then if you care you can use glXIsDirect to see if you got it. The DRI API is for inter-driver communication only AFAIK, not for application use. Not sure what hardware documentation has to do with this; pretty much everything in the original R200 documentation (I'm guessing that's what you're referring to, since there is a lot of publicly available documentation for newer chips) has been transcribed into the open source drivers already. In terms of the relationship, I thought it was basically : - app calls GL lib - GL lib uses DRI to see if server supports direct rendering for that screen - if yes, GL lib makes other calls to set up shared areas and find name of 3d driver - if all that succeeds, GL lib passes drawing calls directly to the 3d driver AIGLX is more complicated but not a lot more so. Anyways, bottom line is that if you are writing another direct rendering driver you probably should be using DRI calls and if you are not writing a driver then you probably should just be using GLX calls... or something like that ;) -Original Message- From: Enno Fennema [mailto:e.fenn...@tiscali.nl] Sent: Wednesday, May 13, 2009 3:57 PM To: Jerome Glisse; Bridgman, John Cc: dri-devel@lists.sourceforge.net Subject: Re: Need sample program or tutorial Jerome Glisse wrote: ... Why do you want to use XF86DRIQueryDirectRenderingCapable ? I only called XF86...Capable to confirm that the software recognized my video card as *capable* of direct rendering. glXIsDirect tells you what you want to know ie if it's direct or not. Correct, glXDirect tells me the context is or is not *using* direct rendering. I don't understand what you are trying to do here, you shouldn't care to know if direct rendering is enabled or not, applications shouldn't behave differently if DRI is enabled or not. I thought direct rendering is faster than indirect as it avoids the translation from OpenGL to the X protocol and then back again. The difference in application behaviour is then only speed but it my case the difference is 'crash' or 'works ok'. Another question is why should I specify direct/indirect in glXCreateContext if there is no reason to care. My longer term aim is to understand what my Radeon SE9200 can and cannot do. Mesa is so clever that it hides by software when hardware is deficient. I think that only by getting access to the the drm kernel driver can I start exploring the hardware. As John Bridgman wrote DRI might be useful too for non-GL applications, which do want contact with the X server not to clobber other windows but otherwise would like to access non-GL capabilities of the hardware or GL capabilities in a differnt way. Radeon documentation is possibly available but under non disclosure conditions which I do not want to accept. At least I found very little publicly available. In the short run I try to understand a bit better how DRI manages the relation ships between X windows, those that GLXWindows and, maybe an impossible animal, a DRM Window, which shows consideration for other X windows. Regards, Enno -- The NEW KODAK i700 Series Scanners deliver under ANY circumstances! Your production scanning environment may not be a perfect world - but thanks to Kodak, there's a perfect scanner to get the job done! With the NEW KODAK i700 Series Scanner you'll get full speed at 300 dpi even with all image processing features enabled. http://p.sf.net/sfu/kodak-com -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[pgarr...@optusnet.com.au: Re: [RFC] page flipping/buffer swap for DRI2]
- Forwarded message from Peter John Garrone pgarr...@optusnet.com.au - From: Peter John Garrone pgarr...@optusnet.com.au To: Jesse Barnes jbar...@virtuousgeek.org Subject: Re: [RFC] page flipping/buffer swap for DRI2 On Fri, Feb 13, 2009 at 04:44:08PM -0800, Jesse Barnes wrote: On Friday, February 13, 2009 4:18 pm Peter John Garrone wrote: In reply to Jesse Barnes post. I'm not on top of the finer details, being a consumer rather than a developer. I have the following queries: 1) Is the buffer flip to be synchronous in the hardware, or to be implemented as a software interrupt? I'm not sure what you mean... The flip is queued in the hardware ring, and delayed by hardware until the vertical blank interval starts. So in that sense the hardware takes care of it for us (we don't rely on an interrupt to get the bits on the screen). We do require an interrupt, however, to know when the flip has occurred. This lets us know that it's ok to start drawing on the new back buffer, since it's no longer being displayed to the user. I incorrectly wrote software interrupt when I meant hardware interrupt, which is confusing, sorry. I would rephrase my own particular requirement as Is the buffer flip to be implemented in the hardware, or implemented in software triggered by hardware interrupt? The intel hardware has the ability to do a buffer swap in the hardware. However I believe that the current dri infrustructure works (see mesa/src/mesa/drivers/dri/intel/intel_swapbuffers.c:intelSwapBuffers) by flushing pending rendering commands, waiting for the appropriate vertical blank interrupt, then copying the opengl back buffer to the front buffer. This is a problem when the interrupt response is slow, or when the hardware graphics queue is not empty because other opengl applications are currently rendering, so the buffer swap is delayed, creating a tear generally near the top of the screen. I don't think this quite agrees with your outline, unless your patch set addresses this problem, which would be wonderful. I currently cope with this by poking the hardware to cause the two screens to interrupt at a particular phase, and synchronizing the two rendering threads to wait until both have accomplished their screen swaps. At high loads, however, the synchronization breaks down and tearing results, and it is never possible to completly eliminate tearing. 2) By fullscreen, do you mean covering one or all screens in a multi-headed display? It's hard coded to deal with one screen in this patchset, but potentially needs to flip both heads in a shared (cloned or extended desktop) configuration. That's fine. I would hope that in a dual-headed setup, each screen (or plane) can be individually full-screen. Sometimes fullscreen is interpreted as a single window covering both screens, which is not good for me. 3) If fullscreen means covering an individual screen in a multi-headed display, will it be possible to have multiple simultaneous fullscreen tear-free applications? Yes, it should be possible. 4) Will non-fullscreen applications be tear-free? Maybe. If you're running a compositing manager that always swaps the whole screen (like the hacked version of compiz I've been using for testing does), then any non-DRI apps running under it will be tear-free. DRI apps will need special treatment, which I haven't implemented yet. To be honest, the speed of the window manager is not a big issue for me. Tearing is. In production mode, efficient fullscreen output mode is desirable. In development mode, having the output into manageable re-sizeable windows is nicer. The only way I can see non-tearing non-fullscreen applications working is with triple-buffer. i.e. a kernel screen flyback interrupt copies a screen-full from the multi-headed working buffer to a plane buffer, schedules that plane buffer to be swapped upon the next flyback, and triggers approptiate returns from the application swap-buffer function calls. I assume this is triple-buffer because there is the large possibly virtual working buffer and also two plane buffers for each screen. That would be one way of handling non-fullscreen apps. Another way would be to queue front buffer blits from such apps to occur during the vertical blank period. That's not as reliable (nor easy to implement) as full page flipping though, but has the advantage of just blitting over a small area of the screen, which will preserve most of the compressed framebuffer (if present), saving power. This appears to me to be what the code in intel_swapbuffers.c currently achieves. I'm grateful if you are creating an alternative for fullscreen applications, anyway. However a fullscreen application should be able to override this on an individual screen basis, rendering directly into the non-output display plane, and scheduling it to be swapped upon the N'th flyback. Right, that's
Re: [RFC] page flipping/buffer swap for DRI2
In reply to Jesse Barnes post. I'm not on top of the finer details, being a consumer rather than a developer. I have the following queries: 1) Is the buffer flip to be synchronous in the hardware, or to be implemented as a software interrupt? 2) By fullscreen, do you mean covering one or all screens in a multi-headed display? 3) If fullscreen means covering an individual screen in a multi-headed display, will it be possible to have multiple simultaneous fullscreen tear-free applications? 4) Will non-fullscreen applications be tear-free? To be honest, the speed of the window manager is not a big issue for me. Tearing is. In production mode, efficient fullscreen output mode is desirable. In development mode, having the output into manageable re-sizeable windows is nicer. The only way I can see non-tearing non-fullscreen applications working is with triple-buffer. i.e. a kernel screen flyback interrupt copies a screen-full from the multi-headed working buffer to a plane buffer, schedules that plane buffer to be swapped upon the next flyback, and triggers approptiate returns from the application swap-buffer function calls. I assume this is triple-buffer because there is the large possibly virtual working buffer and also two plane buffers for each screen. However a fullscreen application should be able to override this on an individual screen basis, rendering directly into the non-output display plane, and scheduling it to be swapped upon the N'th flyback. Apologies for sounding preachy, I simply outline my own analysis and am wondering how it is possible for a window manager, which must output to a larger virtual space, could be regarded as a good candidate for double-buffering as you suggest. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: radeon r6xx DRM...
Brian Paul wrote : If the new driver won't be an incremental change to the existing radeon drivers, I'd recommend basing it on Gallium. The driver will be an incremental change. The 6xx family is conceptually different inside and there is a learning curve, but the basic programming model is largely unchanged from previous generations. There are just a lot more changes in things like memory controller setup, and some of the VAP functionality moves into vertex shaders. We definitely plan to do any further work on Gallium; we just want to get a 6xx 3D driver in users hands quickly on a code base that everyone knows already. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
PBO and TNPOT for Intel hardware
Hey, I'm not sure if this is the correct mailing list for this question, but I think it may be. If I'm wrong don't hesitate to point me in the right direction. Anyways, I am wondering if pixel buffer objects and textures whose dimensions are not powers of two will be supported by Intel hardware (read: not texture rectangle). These are both officially OpenGL 2.1 features, but they have been present as extensions for a while. So, I have three questions, 1) Is it possible to implement these features on Intel chips (and which ones?) 2) Is it just a lack of developer time or are these features blocking on the new memory manager? 3) Assuming that the answer to 1) is Yes, any chance of getting an ETA of when this might be implemented? -- John McCutchan [EMAIL PROTECTED] - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
What can the FSF do to help?
The Free Software Foundation had listed http://r300.sf.net/ as a High Priority Project. We recognize that the lack of 3D video drivers for their specific hardware is one of the primary obstacles preventing people from running entirely free systems. The development status and location of that project has changed, and we would like to update our recommendation. We are interested in ideas for how we can help contribute to the project's development (and to the overall goals of performing 3D video drivers for free software operating systems). I'd like to hear any suggestions or feedback that the developers on the list have for what could be done. (I'll stay subscribed to the list -- or please point me in a different direction if there is a more appropriate list for this.) Thanks, -- John Sullivan Program Administrator| Phone: (617)542-5942 x23 51 Franklin Street, 5th Fl. | Fax: (617)542-2652 Boston, MA 02110-1301 USA| GPG: AE8600B6 - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
driver level sub-pixel rendering?
Do these drivers do anything to support subpixel rendering of the text or screen images? Is any of that built in to the hardware acceleration, or is that done only at the operating system level?I think on the Windows side, some of the Nvidia drivers do subpixel work on the driver level.
Re: driver level sub-pixel rendering?
Sorry Brian, I should have been more specific. I mean more as a final output onto a screen. Using an LCD/CRT's individual RGB subpixels to antialiasing (or some form of screen output enhancement). It seems a lot of the 3D stuff in the GPU is already employing sub-pixel coordinates, so it would be nice if the actual output to the screen would take advantage of that. On 3/30/06, Brian Paul [EMAIL PROTECTED] wrote: John Kheit wrote: Do these drivers do anything to support subpixel rendering of the text or screen images? Is any of that built in to the hardware acceleration, or is that done only at the operating system level? I think on the Windows side, some of the Nvidia drivers do subpixel work on the driver level.Can you be more specific?If you're asking about line/triangle rasterization, I believe vertex coordinates are snapped/truncated to some sub-pixel fraction (ratherthan whole pixel coords) in all hardware.For text, are you asking about some form of antialiasing?Or, do you have multisampling in mind? -Brian
Re: [Dri-users] How to build the new cvs
On Mon, 2006-02-27 at 16:42 -0500, Felix Kühling wrote: What do you mean with unmerge? I think he is referring to un-intalling, the Gentoo way :) --- This SF.Net email is sponsored by xPML, a groundbreaking scripting language that extends applications into web and mobile media. Attend the live webcast and join the prime developer group breaking into this new coding territory! http://sel.as-us.falkag.net/sel?cmd=lnkkid=110944bid=241720dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Radeon X1600?
On Tue, 7 Feb 2006, Roland Scheidegger wrote: Both xpress 200m and x700 should at least work for 2d, and the x700 hopefully for 3d too (some people still don't have luck with them it seems). There is not much hope of getting the X1xxx chips to work anytime soon, even for 2d, as they are believed to be much different (especially as far as modesetting/2d is concerned, radeon 7200 to radeon x850 are nearly identical there). You can always use vesa driver, which of course totally sucks, and there's a high probability you couldn't even use the display's native resolution with that. Fglrx should support it at some point, but an ATI employee stated it will take a couple of driver revisions, which I interpret as something up to half a year. Roland Thanks (everyone) for the info. It's unfortunate, but it's what I honestly expected. Looks like I'll either have to go suck it up and buy an x700 notebook before they disappear, or gamble with a 200m and hope we can figure out the memory controller (and memory management that goes with it). john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Radeon X1600?
There was a post on this list at the end of december(?) indicating that ATI was not interested in helping open source with 3D specs anymore.. I'm guessing they didn't do much with the r300 line either.. but does anyone know anything or have any official word on whether the r500 series of radeon cards will ever be supported by anything other than fglrx for 3D? Any official word from ATI? Is anything known about these cards? I ask because my ibook g3 is getting a bit long in the tooth, and since my non-x86 options for laptops are fast approaching 0, I'm looking for a turion notebook with a supported chipset. I'm debating about going cheaper with a radeon 200M (which i think has an undocumented memory controller and thus doesn't work even though it's an r300 core?), or the MSI-1029 with an X700 (which is supported by r300, right?). But, the 1029 is about to be replaced with the 1039 which comes with the new X1600, so I'd like to know if I have to move before the 1029 disappears, or if i can wait a little while. john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-users] Glxinfo seg fault with Thinkpad T20 Savage IX
Thanks, now for a dumb question... how far back do I need to go to get mesa without those changes, and where? Thanks again for the help. I have a Thinkpad T20 with a Savage IX, that is running Gentoo Linux with 2.6.14-rc2-mm1 kernel. In order to get direct rendering working, I have followed the build from cvs instructions on the dri wiki. Now everything seems to work, dmesg shows no errors, and the xorg log tells me direct rendering is enabled, and I can run glxgears with fps from 150 up to 300. However, glxinfo bombs with a seg fault message, and tuxracer locks up the computer before actually getting to the play screen. I've compiled with the latest xorg cvs, dri cvs, mesa cvs, etc. Any ideas? I think Brian's renderbuffer changes may be the cause. If you go to a version of mesa cvs prior to the changes it should work. I've lots of other reports of this problem on savage; cc'ing dri-devel. --- This SF.Net email is sponsored by: Power Architecture Resource Center: Free content, downloads, discussions, and more. http://solutions.newsforge.com/ibmarch.tmpl -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
r300 + agpfastwrite
hello! I'm using the r300 driver from mesa+drm cvs and would like to know if there is any way of using agpfastwrite? thanx jon --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: r300_dri compiling
WOW! worked like a charm! thanks! On Sunday 21 August 2005 16:01, Vladimir Dergachev wrote: On Sun, 21 Aug 2005, john wrote: hi! i'm not too experienced in programming, but here it goes: but i've been able to check out the Mesa cvs and the r300 cvs. i've been trying for quite a long time, to compile r300 Mesa drivers. the drm works fine from r300 cvs, but i cant get mesa to compile. if i try to compile the r300 code from Mesa cvs the compile finishes cleanly, but I get no direct 3D acceleration. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No Take a look in /var/log/Xorg.0.log - I bet it says direct rendering disabled. You need to use DRM from DRI CVS - it has proper version number that Xorg Xserver recognizes. The reason for the check is that previous DRM versions provided 2d acceleration only and using Mesa driver with them will not work. if I lndir the r300 code from r300 cvs, the build doesn't finish: output in attached file. No, it is not supposed to - there had been significant changes in Mesa. best Vladimir Dergachev i think it's just me, but i would like to be shure i can't help you guys! THANX for the hard work (i got it to compile about one month ago, once, but am still using that driver!) --- SF.Net email is Sponsored by the Better Software Conference EXPO September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices Agile Plan-Driven Development * Managing Projects Teams * Testing QA Security * Process Improvement Measurement * http://www.sqe.com/bsce5sf -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel pgp1IjcMc5qw5.pgp Description: PGP signature
r300_dri compiling
hi! i'm not too experienced in programming, but here it goes: but i've been able to check out the Mesa cvs and the r300 cvs. i've been trying for quite a long time, to compile r300 Mesa drivers. the drm works fine from r300 cvs, but i cant get mesa to compile. if i try to compile the r300 code from Mesa cvs the compile finishes cleanly, but I get no direct 3D acceleration. libGL warning: 3D driver returned no fbconfigs. libGL error: InitDriver failed libGL error: reverting to (slow) indirect rendering display: :0 screen: 0 direct rendering: No if I lndir the r300 code from r300 cvs, the build doesn't finish: output in attached file. i think it's just me, but i would like to be shure i can't help you guys! THANX for the hard work (i got it to compile about one month ago, once, but am still using that driver!) In file included from r200_context.h:51, from radeon_screen.c:48: radeon_context.h:199: error: syntax error before âPFNGLXGETUSTPROCâ radeon_context.h:199: warning: no semicolon at end of struct or union radeon_context.h:207: error: syntax error before â}â token In file included from radeon_screen.c:48: r200_context.h:759: error: field âradeonâ has incomplete type In file included from radeon_screen.c:49: r300_context.h:813: error: field âradeonâ has incomplete type radeon_screen.c: In function âradeonCreateScreenâ: radeon_screen.c:502: warning: pointer targets in assignment differ in signedness radeon_screen.c:586: warning: implicit declaration of function âglXGetProcAddressâ radeon_screen.c: In function âradeonCreateContextâ: radeon_screen.c:765: warning: control reaches end of non-void function radeon_screen.c: In function âradeonDestroyContextâ: radeon_screen.c:774: error: dereferencing pointer to incomplete type radeon_screen.c: At top level: radeon_screen.c:809: error: syntax error before â*â token radeon_screen.c: In function â__driCreateScreenâ: radeon_screen.c:814: warning: implicit declaration of function â__driUtilCreateScreenâ radeon_screen.c:814: error: âdpyâ undeclared (first use in this function) radeon_screen.c:814: error: (Each undeclared identifier is reported only once radeon_screen.c:814: error: for each function it appears in.) radeon_screen.c:814: error: âscrnâ undeclared (first use in this function) radeon_screen.c:814: error: âpscâ undeclared (first use in this function) radeon_screen.c:814: error: ânumConfigsâ undeclared (first use in this function) radeon_screen.c:814: error: âconfigâ undeclared (first use in this function) radeon_screen.c:814: warning: assignment makes pointer from integer without a cast radeon_screen.c: In function âgetSwapInfoâ: radeon_screen.c:890: error: dereferencing pointer to incomplete type radeon_screen.c:891: error: dereferencing pointer to incomplete type radeon_screen.c:892: error: dereferencing pointer to incomplete type radeon_screen.c:895: error: dereferencing pointer to incomplete type make[6]: *** [radeon_screen.o] Error 1 make[6]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa/src/mesa/drivers/dri/r300' make[5]: *** [subdirs] Error 1 make[5]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa/src/mesa/drivers/dri' make[4]: *** [drivers-dri] Error 2 make[4]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa/src/mesa' make[3]: *** [default] Error 2 make[3]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa/src/mesa' make[2]: *** [subdirs] Error 1 make[2]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa/src' make[1]: *** [default] Error 1 make[1]: Leaving directory `/home/jano/DRIcvs/Xorg/Mesa' make: *** [linux-dri-x86] Error 2 pgpXQBv1D2G1m.pgp Description: PGP signature
radeon 9600se?
I have xorg.conf set up to use radeon driver with big desktop mode and xinerama. It works fine, but I want acceleration. So am I correct in saying all I need to do is # Load dri Load glx uncomment the dri load, and make install your modules? __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com --- This SF.Net email is sponsored by Yahoo. Introducing Yahoo! Search Developer Network - Create apps using Yahoo! Search APIs Find out how you can build Yahoo! directly into your own Applications - visit http://developer.yahoo.net/?fr=offad-ysdn-ostg-q22005 -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [r300] Radeon 9600se mostly working..
Hi Vladimir, On Mon, 21 Feb 2005, John Clemens wrote: give it a go on my fanless 9600se (RV350 AP). How much memory do you have ? What kind of CPU and motherboard ? Duron 1.8G, 256MB ddr, old(ish) via km266 motherboard in a shuttle sk41g. Gentoo. The card has 128Mb ram. - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. should I be concerned that these fps are too low? others seem to be reporting around 1000.. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit ... The swap buffer blit is just a copy - for example a copy from back buffer to front buffer. Since the engine timed out before swap buffer blit it means that the commands before it were at fault. Which is puzzling as you point out that everything works in 640x480. Just to elaborate: 640x480 runs fine. at 800x600 windowed, it plays fine, but if a scene gets more complicated i see some jerkyness.. i.e., the scene freezes for a second or two and then jumps ahead, and i get a few messages in the log. At 1280x1024, this happens all the time, so it appears the game is locked, and I get a stream of those messages in the log file. alt-F switching to the console works, and switching back i get about 2 seconds more of movement, and then soft-lock again (persumably because the card re-inits on VC switch). I can switch to the VC and kill it and all's fine. Judging from what you're saying, the card isn't locked, it just isn't able to draw a full scene before it times out. Who is responsible for drawing to this buffer? r300, mesa or x? I just grabbed the CVS trees and did a make, I think mesa by default might be compiled with -O -g, would it be better to recomile it with just -O2? I wonder whether the lockup detection logic is at fault - we simply wait a fixed amount of time for the engine to become idle. Perhaps it would be better to actually monitor the CP engine progress, for example by looking for changes in current ring pointer (i.e. wait and check whether the value changed). If the ring pointer does not change declare a lockup. What does everyone think ? Seems reasonable. What's the downside if you if you swap a half-draw buffer to the fore and then start drawing a new one? tearing? john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[r300] Radeon 9600se mostly working..
So I've been lurking for a while following the r300 work and decided to give it a go on my fanless 9600se (RV350 AP). - glxinfo states r300 DRI is enabled. (AGP4x, NO-TCL) - glxgears gives me about 250fps with drm debug=1, ~625fps without debug on. - tuxracer runs ok at 640x480 fullscreen - ice textures look psychadelicly blue - at 1280x1024, (and somewhat at 800x600 windowed), i get these errors: [drm:radeon_cp_dispatch_swap] *ERROR* Engine timed out before swap buffer blit Any pointers on what causes that? This is with Xorg cvs, Mesa cvs, r300 cvs, as of 4 hours ago. I'm guessing the X server or mesa isn't filling the buffer up fast enough at higher resolutions...but I'm new to devlopment so i don't know which buffer that would be.. thanks, john.c -- John Clemens http://www.deater.net/john john at deater.net I Hate Quotes -- Samuel L. Clemens --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
New Debian packages built from Xorg
I was feeling a bit frisky yesterday and built new DRI packages for Debian Unstable using the Xorg xc tree. Any feedback would be greatly appreciated. http://www.nixnuts.net/files/experimental/ I'm still wondering where /usr/X11R6/lib/modules/codeconv/ went though. Is there a define to build these libraries that isn't in the sample host.def for Xorg? Are they necessary for languages other than English? John signature.asc Description: This is a digitally signed message part
Re: dri_util.c:157: warning: pointer targets differ in signedness.
First let me say that if anyone would like to take over updating the dri-trunk-sid packages on a semi-regular basis, I'd really appreciate it. I don't track the Debian X or DRI mailing lists closely enough to keep up with changes. On Tue, 2004-12-28 at 15:00 -0800, Mike Mestnik wrote: The source I'm using contains the old DRI xc. I can see where the old xc source is needed to build the OLD Xserver and Mesa is needed there to build it's dri, glx, and opengl Xdrivers. How ever I can't see why this old xc code has not been diffed in to debian's Xfree86? Would submitting a patch to TDBTS help? I'm not a member of the Debian X team so I don't speak for them, but I wouldn't expect that a patch of DRI's changes to XFree86 will be accepted. The reason I started updating Michel Daenzer's packages was that I needed MergedFB support and wanted some of the fixes that were being incorporated into DRI. Requests for MergedFB in Debian's X packages date back to June 2003. I wouldn't imagine there will be any major changes to Debian's X until Sarge releases. At this time Xorg is used for most of the DRI development. It also seams that the dri, glx, and opengl Xdrivers can be built in the Mesa tree with libGL and the dri_ Xdrivers. Since Mesa is now able to build against Xfree86 and Xorg this would seam to fix most of the problems. This is news to me. I thought the current recommended way of doing things was to build an Xorg xserver, glx, and libgl, then build the 3D drivers in Mesa. http://dri.sourceforge.net/cgi-bin/moin.cgi/Building Rather than updating the dri-trunk-sid packages to build Xorg it might be easier to direct users to the experimental Xorg packages at http://debian.linux-systeme.com/ With a new libGL in place, installing Mesa and drm CVS by hand isn't that difficult and doesn't have to overwrite the packaged X server. It would be nice if driconf had a way of overriding LIBGL_DRIVERS_PATH on a per-user or global basis though. I got this after cvs updating the tar.gz of the unofficial debian source... This source is at least missing the DRI_NEW_INTERFACE_ONLY define dri_util.c:1073, cause it uses the xc Makefiles to build Mesa. dri_util.c: In function `glx_find_dri_screen': dri_util.c:157: warning: pointer targets in passing arg 1 of `glXGetProcAddress' differ in signedness I ran into the same problem, but this message convinced me there was little point in trying to fix it. http://www.mail-archive.com/dri-devel@lists.sourceforge.net/msg20719.html John signature.asc Description: This is a digitally signed message part
Re: Segfault on RTCW with Savage
On Wednesday 06 October 2004 06:54, Felix Kühling wrote:
On Mon, 04 Oct 2004 12:09:09 +0100
Keith Whitwell [EMAIL PROTECTED] wrote:
John,
I'd say the problem is with these lines in savagetris.c:
if (index (_TNL_BIT_COLOR1|_TNL_BIT_FOG)) {
EMIT_ATTR( _TNL_ATTRIB_COLOR1, EMIT_3UB_3F_BGR, SAVAGE_HW_NO_CS );
EMIT_ATTR( _TNL_ATTRIB_FOG, EMIT_1UB_1F, SAVAGE_HW_NO_CS );
}
This is a cut and paste of old code from another driver. Have a look at
how other drivers handle this now to avoid trying to emit FOG when only
COLOR1 is enabled, and vice versa.
Is there a simpler test case than RTCW? I can't reproduce a segfault
with a simple program that draws triangles with diffuse lighting and
Fog. John, can you try if the attached patch fixes it?
Your patch does fix the problem. The checkpoint demo loads and runs without
problems now.
John
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Segfault on RTCW with Savage
On Friday 01 October 2004 04:03, Keith Whitwell wrote:
John Lightsey wrote:
A while back I mentioned on dri-devel that Savage cards will segfault
RTCW while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple
fix which eliminates the problem.
Does anyone see this in other hardware? If it's only the savage driver
causing this, I would say there's probably a bug in the driver somewhere.
What are the values of j, count and a[j] at the time of the crash?
I didn't see the problem with any other hardware, but RTCW refused to run with
r128 and sis 305, the last time I tried.
GDB's output seems a bit confused. After the segfault j=3
VB-AttribPtr[a[j].attrib] is a valid pointer, but vptr is null. It looks
like j is being incremented after the segfault since
VB-AttribPtr[a[2].attrib] is the same bad pointer as vptr.
...snip...
LOADING... graphics
LOADING... maps/mp_destruction.bsp
stitched 0 LoD cracks
...loaded 15194 faces, 48 meshes, 275 trisurfs, 31 flares
Program received signal SIGSEGV, Segmentation fault.
do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
916 t_vertex.c: No such file or directory.
in t_vertex.c
(gdb) print j
$1 = 3
(gdb) print a[j]
$2 = {attrib = 5, format = 8, vertoffset = 23, vertattrsize = 1, inputptr =
0x0,
inputstride = 0, insert = 0x4653ce48, emit = 0, extract = 0x464dfa70
extract_1ub_1f,
vp = 0xa4f9ef8}
(gdb) print a[j].attrib
$3 = 5
(gdb) print VB-AttribPtr[a[j].attrib]
$4 = (GLvector4f *) 0xb2d3718
(gdb) print a[2]
$5 = {attrib = 4, format = 10, vertoffset = 20, vertattrsize = 3, inputptr =
0x87bfb00 ,
inputstride = 8, insert = 0x4653ce80, emit = 0x464deb20 insert_2f_2,
extract = 0x464dfa30 extract_3ub_3f_bgr, vp = 0xa4f9ef8}
(gdb) print a[2].attrib
$6 = 4
(gdb) print VB-AttribPtr[a[2].attrib]
$7 = (GLvector4f *) 0x0
(gdb) print vptr
$8 = (GLvector4f *) 0x0
(gdb) print vptr-stride
Cannot access memory at address 0xc
(gdb) bt
#0 do_emit (ctx=0xa4fa078, start=0, end=4, dest=0x4) at t_vertex.c:916
#1 0x464d8fb6 in run_render (ctx=0xa4fa078, stage=0x4) at t_vb_render.c:296
#2 0x464c6575 in _tnl_run_pipeline (ctx=0xa4fa078) at t_pipeline.c:159
#3 0x464c4d40 in _tnl_draw_range_elements (ctx=0xa4fa078, mode=1,
max_index=4,
index_count=4, indices=0x4) at t_array_api.c:108
#4 0x464c53be in _tnl_DrawElements (mode=4, count=6, type=5125, indices=0x4)
at t_array_api.c:383
#5 0x080746e0 in ?? ()
(gdb)
Hope that helps.
John
---
This SF.net email is sponsored by: IT Product Guide on ITManagersJournal
Use IT products in your business? Tell us what you think of them. Give us
Your Opinions, Get Free ThinkGeek Gift Certificates! Click to find out more
http://productguide.itmanagersjournal.com/guidepromo.tmpl
--
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
Segfault on RTCW with Savage
A while back I mentioned on dri-devel that Savage cards will segfault RTCW
while loading the Checkpoint demo.
( http://www.nixnuts.net/benchmarks/current/ ) The problem is in
Mesa/src/mesa/tnl/t_tertex.c around lines 741 and 913.
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
a[j].inputstride = vptr-stride;
...
}
vptr is null in the middle of the for loop ( j=2 is null j=0, 1, and 3 is
valid.) I have no idea why this is the case, but I've attached a simple fix
which eliminates the problem.
John Lightsey
--- xc/../Mesa/src/mesa/tnl/t_vertex.c.orig 2004-09-30 16:59:08.0 -0500
+++ xc/../Mesa/src/mesa/tnl/t_vertex.c 2004-09-30 16:59:58.0 -0500
@@ -741,9 +741,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
end -= start;
@@ -913,9 +915,11 @@
for (j = 0; j count; j++) {
GLvector4f *vptr = VB-AttribPtr[a[j].attrib];
- a[j].inputstride = vptr-stride;
- a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
- a[j].emit = a[j].insert[vptr-size - 1];
+ if (vptr) {
+ a[j].inputstride = vptr-stride;
+ a[j].inputptr = ((GLubyte *)vptr-data) + start * vptr-stride;
+ a[j].emit = a[j].insert[vptr-size - 1];
+ }
}
vtx-emit = 0;
Re: First DRI uber-benchmark
On Monday 23 August 2004 12:36, Ian Romanick wrote: John Lightsey wrote: Once I have all the benchmarks together I'll make some pretty little graphs. Soany suggestions, comments, feedback? First off, great work! Hopefully you'll be willing to re-run those tests to look for regressions in future releases. ;) I have only two criticisms. First, demo4 is a crummy Quake3 benchmark, and demo1 is a crummy Quake2 benchmark. I've got a couple Quake3 demos that I recorded for DRI testing that I can post in the next day or so. Something like massive1 or crusher would be a much better Quake2 benchmark (that really turns back the way-back clock for me!). I'll look into those Quake2 demos for the next try. Benchmarking Quake2 and Quake3 is very fast, so including another demo or two shouldn't be a problem. My other critical comment is that you only have texture intensive benchmarks. It would be nice to add a couple purely polygon intensive benchmarks. I know that viewperf is a pain to run, but it does it's job well. Do any of the open-source modeling packages (i.e., Blender) have a benchmark mode? I think that might be intersting to a lot of Linux people. I'd be interested in average FPS for things like blender, chromium, bzflag, etc... Perhaps they'll take patches to add it in if the code isn't there already. I gave up on specviewperf after waiting over half an hour for the Voodoo 5 to run it. It's just too time consuming. Are there one or two tests that stand out in particular? The HTML version with lots of pretty pictures and graphs is online here: http://www.nixnuts.net/benchmarks/040815/ Thanks to everyone that has given feedback. I'll run another round of benchmarks in a month or two and try to submit bug reports on everything that doesn't work in the mean time. DRI is an amazing piece of software Many thanks to everyone for the great work. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
First DRI uber-benchmark
pretty little graphs. Soany suggestions, comments, feedback? John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 04:57, Simon 'corecode' Schubert wrote: On 22.08.2004, at 08:16, John Lightsey wrote: glxgears - let it run for 1 minute then marked down the highest score how reproducable and meaningful is a highest score? I don't know, but I got a feeling that using a mean or a median might be of better reproducability and also might better reflect common 3d response feeling (in case you want to make a real-world benchmark, not a synthetic one). The high score ends up being a fraction of a frame higher than the mode score. The difference doesn't seem significant on any of the cards. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 04:59, Felix Kühling wrote: On Sun, 22 Aug 2004 01:16:18 -0500 John Lightsey [EMAIL PROTECTED] wrote: Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. There are rumors about some Savage4's that lock up when reading the status register. :-/ A workaround would be to use shadow status (the card writes status to system/AGP memory and the driver picks it up from there). This is high on my todo list, but it'll require some fundamental work on the DRM driver first. In the mean time, maybe trying different AGP speeds would help. Or is this a PCI card? They're all AGP cards. I'll try setting the a90 to AGP1x to see if that helps. The crash with the IBM SR9 happens while the checkpoint demo is loading. Some kind of texture loading problem perhaps? John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
First DRI uber-benchmark
A while back it was suggested that benchmarking all of the various DRI-compatible video cards might provide some interesting information. I just finished my first attempt at performing a slew of benchmarks with this goal, and the results haven't been great. It's certainly possible that (a) some of the video cards might be bad since they were purchased on ebay, (b) I didn't configure some of them properly, or (c) the CVS checkout I used had problems. At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Setup: I used an old ECS k7s5a pro motherboard with an Athlon 2400XP. 512 MB of PC2100 Ram, onboard sound, IBM G74 monitor, and Maxtor ATA100 drive. The OS was Debian Unstable, with the sources.list set to snapshot.debian.net with a date of 15 Aug 2004. The DRI packages I used are the same ones on my server (CVS checkout from 15 Aug 04 with S3TC and Radeon DynamicPM.) I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Method: All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. glxgears - let it run for 1 minute then marked down the highest score quake2 - s_initsound 0, snd_restart, timedemo 1, map demo1.dm2. Run each resolution 2x and select the highest score. Used glx OpenGL driver. quake3 - s_initsound 0, snd_restart, timedemo 1, demo four. Run each resolution 2x and select the highest score. RTCW - launched with wolfmp +set sv_cheats 1, s_initsound 0, snd_restart, timedemo 1, demo checkpoint. Run each resolution 2x and select the highest score. Unreal Tournament - launch game, bring up console, timedemo 1, wait for second flyby to complete then mark down second score. X and the games were all configured for 16 bit color. r_ext_compressed_textures was set to 0. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. Shuttle Spacewalker 16MB (sis 305) Lots of crashing. Problems with vesafb? glxgears gave this 337.8 fps. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. Cards that worked (more or less): Voodoo 5-5500 64MB (tdfx) glxgears - 1425.6 q2 640x480 - 56.4 q2 800x600 - 51.2 q2 1024x768 - 42.9 q3 640x480 - 95 q3 800x600 - 68 q3 1024x768 - 46.1 rtcw 640x480 - 57.6 rtcw 800x600 - 44.6 rtcw 1024x768 - 32.3 ut 640x480 - 80.79 ut 800x600 - 76.6 ut 1024x768 - 58.11 Notes: Seemed very reliable. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Radeon DDR 32MB (r100) glxgears - 1123 q2 640x480 - 87.8 q2 800x600 - 74.2 q2 1024x768 - 58.1 q3 640x480 - 114.9 q3 800x600 - 80.9 q3 1024x768 - 53.5 rtcw 640x480 - 85.5 rtcw 800x600 - 63.9 rtcw 1024x768 - 43.7 ut 640x480 - 82.97 ut 800x600 - 76.34 ut 1024x768 - 56.4 Notes: RTCW was substantially slower on the first run. Screen became corrupted once and was only fixed be a reboot. Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 Notes: Reliable, looks great. UT suffered from lots of software fallback. Radeon 8500 AIW 128MB (r200) glxgears - 2583.4 q2 640x480 - 115 q2 800x600 - 105.4 q2 1024x768 - 88.2 q3 640x480 - 165.3 q3 800x600 - 131.5 q3 1024x768 - 90.6 rtcw 640x480 - 98.4 rtcw 800x600 - 92.2 rtcw 1024x768 - 68 ut 640x480 - 73.74 ut 800x600 - 73.4 ut 1024x768 - 67.14 Notes: Roland's observations about massive slowdown at the end of the UT flyby are still accurate. Although not tested, the 8500 locks up playing ut2003 and ut2004. I have a few more cards to benchmark for comparison. Nvidia - TNT2 and FX5200 FGLRX - Radeon 8500 AIW and Radeon 9600se I also have a Radeon 9200 that I was unable to get working with this machine. Once I have all the benchmarks together I'll make some pretty little graphs. Soany suggestions, comments, feedback? John
Re: First DRI uber-benchmark
On Sunday 22 August 2004 01:52, Adam Jackson wrote: On Sunday 22 August 2004 02:16, John Lightsey wrote: At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Awesome stuff. I'd ask that you open bugs for the crashes you get, preferably with testcases that aren't closed-source games if possible. Once I'm certain that the problems are not caused by bad hardware or a bad configuration on my part I'll try to debug and report the lockups and crashes. All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. There are several programs under mesa/progs/* that include synthetic benchmarks, which might show interesting variations compared with glxgears (the other canonical synthetic benchmark). Maybe. Also several of the xscreensaver GL demos have benchmarks; glblur, blocktube, flurry, and lavalite are particularly punishing, and menger and sierpinski3d are great for generating absurd numbers of polygons. I looked around for some free software programs that would calculate an average framerate rather than simply showing a FPS counter, but I didn't find any. Something based on crystal-space would be particularly nice. I also looked at specviewperf, but it takes far too long to run. Are there any in mesa/progs that stand out? Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. This is disturbing, I used to play ut on a mach64 all the time. Perhaps the DMA path is still busted? It crashes without locking the display or even changing the resolution. This one looks easier to debug than the others. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
First DRI uber-benchmark
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I sent this message earlier, but it doesn't seem to have made it through. Subject: First DRI uber-benchmark Date: Saturday 21 August 2004 13:17 From: John Lightsey [EMAIL PROTECTED] To: [EMAIL PROTECTED] A while back it was suggested that benchmarking all of the various DRI-compatible video cards might provide some interesting information. I just finished my first attempt at performing a slew of benchmarks with this goal, and the results haven't been great. It's certainly possible that (a) some of the video cards might be bad since they were purchased on ebay, (b) I didn't configure some of them properly, or (c) the CVS checkout I used had problems. At any rate, here are the results of the first run. If anyone has suggestions for fixing any of the cards which failed in one way or another, I would really appreciate the feedback. Setup: I used an old ECS k7s5a pro motherboard with an Athlon 2400XP. 512 MB of PC2100 Ram, onboard sound, IBM G74 monitor, and Maxtor ATA100 drive. The OS was Debian Unstable, with the sources.list set to snapshot.debian.net with a date of 15 Aug 2004. The DRI packages I used are the same ones on my server (CVS checkout from 15 Aug 04 with S3TC and Radeon DynamicPM.) I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Method: All of the benchmarks were started with X already running. I logged into a user account, started X with xinit /usr/X11R6/bin/xterm -- :0 then ran the benchmarks one after the other. glxgears - let it run for 1 minute then marked down the highest score quake2 - s_initsound 0, snd_restart, timedemo 1, map demo1.dm2. Run each resolution 2x and select the highest score. Used glx OpenGL driver. quake3 - s_initsound 0, snd_restart, timedemo 1, demo four. Run each resolution 2x and select the highest score. RTCW - launched with wolfmp +set sv_cheats 1, s_initsound 0, snd_restart, timedemo 1, demo checkpoint. Run each resolution 2x and select the highest score. Unreal Tournament - launch game, bring up console, timedemo 1, wait for second flyby to complete then mark down second score. X and the games were all configured for 16 bit color. r_ext_compressed_textures was set to 0. Cards that didn't work: Oxygen GMX 2000 96MB (gamma). I tried various BusID values. X would start, but direct rendering was always disabled. Diamond Speedstar a90 16MB (savage 4 pro+) Lots of lockups. glxgears gave this a disappointing 229 fps. Shuttle Spacewalker 16MB (sis 305) Lots of crashing. Problems with vesafb? glxgears gave this 337.8 fps. Rage Pro Turbo (mach64) glxgears works with 181.6 fps, but every other OpenGL program would crash. Rage 128 Pro (r128) At 640x480 this one seemed semi-reliable. At 1024x768 it usually froze. glxgears gave this one 518.6 fps. Cards that worked (more or less): Voodoo 5-5500 64MB (tdfx) glxgears - 1425.6 q2 640x480 - 56.4 q2 800x600 - 51.2 q2 1024x768 - 42.9 q3 640x480 - 95 q3 800x600 - 68 q3 1024x768 - 46.1 rtcw 640x480 - 57.6 rtcw 800x600 - 44.6 rtcw 1024x768 - 32.3 ut 640x480 - 80.79 ut 800x600 - 76.6 ut 1024x768 - 58.11 Notes: Seemed very reliable. IBM SR9 16MB Savage 4 eXtreme (savage) glxgears - 569.2 q2 640x480 - 49.4 q2 800x600 - 38.8 q2 1024x768 - 27.1 q3 640x480 - 45.1 q3 800x600 - 34.4 q3 1024x768 - 23.3 rtcw 640x480 - segfault rtcw 800x600 - segfault rtcw 1024x768 - segfault ut 640x480 - 36.8 ut 800x600 - 28.78 ut 1024x768 - 20.6 Notes: The segfault in RTCW seemed to be related to the checkpoint demo. wolfsp seemed to run fine. Radeon DDR 32MB (r100) glxgears - 1123 q2 640x480 - 87.8 q2 800x600 - 74.2 q2 1024x768 - 58.1 q3 640x480 - 114.9 q3 800x600 - 80.9 q3 1024x768 - 53.5 rtcw 640x480 - 85.5 rtcw 800x600 - 63.9 rtcw 1024x768 - 43.7 ut 640x480 - 82.97 ut 800x600 - 76.34 ut 1024x768 - 56.4 Notes: RTCW was substantially slower on the first run. Screen became corrupted once and was only fixed by a reboot. Matrox G400 32MB (mga) glxgears - 1000.2 q2 640x480 - 62.9 q2 800x600 - 52.3 q2 1024x768 - 40.2 q3 640x480 - 65.9 q3 800x600 - 51.4 q3 1024x768 - 36.4 rtcw 640x480 - 42.3 rtcw 800x600 - 33.5 rtcw 1024x768 - 24.7 ut 640x480 - 35.32 ut 800x600 - 30.98 ut 1024x768 - 26.7 Notes: Reliable, looks great. UT suffered from lots of software fallback. Radeon 8500 AIW 128MB (r200) glxgears - 2583.4 q2 640x480 - 115 q2 800x600 - 105.4 q2 1024x768 - 88.2 q3 640x480 - 165.3 q3 800x600 - 131.5 q3 1024x768 - 90.6 rtcw 640x480 - 98.4 rtcw 800x600 - 92.2 rtcw 1024x768 - 68 ut 640x480 - 73.74 ut 800x600 - 73.4 ut 1024x768 - 67.14 Notes: Roland's observations about massive slowdown at the end of the UT flyby are still accurate. Although not tested, the 8500 locks up playing ut2003 and ut2004. I have a few more cards to benchmark for comparison. Nvidia - TNT2 and FX5200 FGLRX - Radeon 8500 AIW and Radeon 9600se I also have a Radeon 9200
Re: First DRI uber-benchmark
On Sunday 22 August 2004 05:39, Alan Cox wrote: On Sul, 2004-08-22 at 07:16, John Lightsey wrote: I shut off most of the services on the machine. rcconf shows klogd, makedev, and sysklogd as the only services active at boot. The kernel used was 2.6.7-1-k7 from Debian. Which DRI kernel modules - the CVS tree provided ones or the 2.6.7 kernel ones ? The kernel modules were from CVS. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
Here are the FGLRX and Nvidia scores for comparison... The Nvidia drivers were built from the packages in Debian non-free (1.0.6111) and the FGLRX drivers were built from Flavio Stanchina's packages (3.11.1). BFG FX5200 Ultra 128MB glxgears - 3934.8 q2 640x480 - 337.1 q2 800x600 - 312.3 q2 1024x768 - 268.5 q3 640x480 - 219.2 q3 800x600 - 217.6 q3 1024x768 - 203.6 rtcw 640x480 - 108.9 rtcw 800x600 - 108.7 rtcw 1024x768 - 107.7 ut 640x480 - 98.12 ut 800x600 - 98.28 ut 1024x768 - 95.71 Notes: TNT2 32MB glxgears - 491.6 q2 640x480 - 83.7 q2 800x600 - 55 q2 1024x768 - 38.9 q3 640x480 - 54.2 q3 800x600 - 34.6 q3 1024x768 - 22.4 rtcw 640x480 - 41.8 rtcw 800x600 - 27.2 rtcw 1024x768 - 17.4 ut 640x480 - 60.14 ut 800x600 - 41.59 ut 1024x768 - 26.31 Notes: Locked up with agpgart. Minor display corruption when switching resolutions in UT which was cleared up by restarting X. Radeon 8500 AIW 128MB w/FGLRX Contant lockups... Totally unusable. Radeon 9600LE 128MB glxgears - 753.4 q2 640x480 - 146.2 q2 800x600 - 97.8 q2 1024x768 - 56 q3 640x480 - 133.6 q3 800x600 - 82.8 q3 1024x768 - 45.3 rtcw 640x480 - 95.1 rtcw 800x600 - 67.4 rtcw 1024x768 - 37.7 ut 640x480 - 93.08 ut 800x600 - 72.98 ut 1024x768 - 41.65 Notes: These numbers all represent X running at 32 bit color depth. FGLRX does not support 16 bit. So... A Radeon DDR 32MB running DRI seems to be faster than a TNT2 32MB. Matrox G400 seems to be faster on everything other than Unreal Tournament. I'll send a link to the graphs on Monday. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: First DRI uber-benchmark
On Sunday 22 August 2004 18:37, Ville Syrjälä wrote: On Sun, Aug 22, 2004 at 01:16:18AM -0500, John Lightsey wrote: Matrox G400 32MB (mga) ... I'm aware of two perfomance bottlenecks in the driver. Number one is that it always uses synchronous DMA. I have asynchronous DMA working just fine under DirectFB but it should probably be tested more with XFree86 before going to cvs. Number two is the TC2_MAGIC bit. It really hurts the single texturing case and even dual texturing gains ~1 fps (in q3) with that bit turned off. Even with those two changes the Windows drivers are still quite a bit faster :( Notes: Reliable, looks great. UT suffered from lots of software fallback. Any idea what fallbacks? ut2k4 demo was actually playable on my G400 if I disabled the texenv extensions. We probably need a config option for that. ut2k3 demo always used projective multi texturing despite what settings I tweaked so I couldn't get decent performance out of it. I'm not at all sure... It slows down to a crawl in a few different places. 1) The section of tunnel with textures on the ground that look like paper trash. This lasts until you pass the grate with steam coming out of it. 2) As the billboards are approached it slows down. (This happens twice.) 3) Heading towards the fire escape it slows down. 4) Right before it enters the tunnel on the building it slows down very briefly. ut2004 is almost playable with the g400 with the lowest settings. The Nvidia logo looks wrong and it's very slow. There are also some points on different maps where the framerate drops through the floor (on DM-Asbestos for instance, when you look at the sunken area where the rocket launcher appears, the framerate drops to single digits. The sunken area is supposed to be filled with water, but there is no water visible with the g400.) I didn't include ut2003/2004 in the list of benchmarks because I didn't figure any of the cards would handle it. I'll try including on of them next time. John --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No DRM kernel support for i830 ?
On Wednesday 11 August 2004 04:01 pm, Charles Sprickman wrote: On Wed, 11 Aug 2004, John Baldwin wrote: The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head because of a security problem with the code. Just out of curiousity, does this support the original i810 chipset? ie: agp0: Intel 82810E (i810E GMCH) SVGA controller mem 0xff00-0xff07,0xf400-0xf7ff irq 9 at device 1.0 on pci0 Not sure. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: No DRM kernel support for i830 ?
On Wednesday 11 August 2004 07:07 am, Alexey Dokuchaev wrote: Hi there, Judging from /sys/dev/drm/ contents, and listed kernel options in NOTES, there's currently evidence of support for i810/830 chips in FreeBSD, which (I suspect) is the probable reason why DRI is not enabled on my box (FreeBSD 5.2-CURRENT from yesterday, latest X.Org). I also found traces of i810/830 support in FDo CVS (http://freedesktop.org/cgi-bin/viewcvs.cgi/dri/drm/bsd/i830/), getting me to the fact that i8x0 files were removed from the BSD side, since they were not actually ported. (Unfinished? broken? unstable?) The i830 DRM stuff is ported in a branch of DRI, but it's not in DRI head because of a security problem with the code. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ --- SF.Net email is sponsored by Shop4tech.com-Lowest price on Blank Media 100pk Sonic DVD-R 4x for only $29 -100pk Sonic DVD+R for only $33 Save 50% off Retail on Ink Toner - Free Shipping and Free Gift. http://www.shop4tech.com/z/Inkjet_Cartridges/9_108_r285 -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: Debian packages of DRI drivers
On Thursday 22 July 2004 17:23, Philipp Klaus Krause wrote: Since the packages from Micahel Dänzer are outdated and don't contain the S3TC patch we now have the strange situation that the lates non-free ATI drivers are easier to use on Debian GNU/Linux than the lates DRI drivers. Would it be possible to cretae a system for unsing the DRI drivers similar to the one used for the ATI drivers. For the ATI drivers there exists an easy way to cretae Debian packages form them. I think it would be useful if there were a script that downloads the drivers, applies the S3TC patch if the user cooses to and creates Debian packages optimized for the user's processor. I have updated versions of Danzer's packages online here: http://www.nixnuts.net/files/ The last set of DRI packages I made are from July 7th. Since then I've been adding the S3TC patch and haven't put them online. If someone outside the US is willing to host them, I'll gladly share the newer versions with S3TC compiled in. John --- This SF.Net email is sponsored by BEA Weblogic Workshop FREE Java Enterprise J2EE developer tools! Get your free copy of BEA WebLogic Workshop 8.1 today. http://ads.osdn.com/?ad_idG21alloc_id040op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Volunteer for GATOS/DRI/Kernel 2.6 Merge
Hello everyone, I am offically throwing in my hat to volunteer for testing and code merging for the gatos/dri/linux kernel 2.6 effort that I have seen as I lurk through the DRI and GATOS mailing lists. My current config: Debian Testing (sarge) Xfree 4.3.0 configuration Using: Kernel 2.6.5 at the moment with 2.4.25 as an option to boot Hardware: Dual Athlon 2400+ CPU's on a Tyan S2466-4M board with ATI Radeon All in Wonder card. This is the 7200 series AGP R100 theatre chipset. I have been successfully using the 2.4.25 with drm 1.100. Now that I have upgraded to 2.6.5, obviously, the DRI portion doesn't work. I have patched the gatos CVS version with debian updates and am running with KM without the DRM support. I have seen multiple emails from Hod McWuff stating he's working on a merge and I would like to help and test. Please email me directly at: [EMAIL PROTECTED] (Take out the _NOSPAM_) __ Do you Yahoo!? Yahoo! Tax Center - File online by April 15th http://taxes.yahoo.com/filing.html --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] bug - execute permissions on data areas
Hmm... I can't seem to find a working bugzilla for DRI, instead things seem to be directed here. I just opened the following bug for xorg, it fixes various pieces of code that need to set execute permission on data memory. Some of these are in DRI and Mesa, it would be great if could get these fixes upstream. Full explanation in the bugzilla referenced. http://pdx.freedesktop.org/cgi-bin/bugzilla/show_bug.cgi?id=399 -- John Dennis [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] [Dri-users] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
export RADEON_GARTTEXTURING_FORCE_DISABLE=1 i have this in /etc/profile, the machine has been rebooted since then, and rainbow problem still exists. --- On Fri 03/12, John H. [EMAIL PROTECTED] wrote: From: John H. [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Fri, 12 Mar 2004 19:40:34 -0500 (EST) Subject: [Dri-users] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems) brsorry, I'm still waiting for someone to tell me exactly how I do what is described here, to stop getting the rainbow stuff.brbrbrbrDo i disable this in XF86Config or something?brbrbrbrbrbrbrbrbrbr --- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] wrote:brbrFrom: Michel =?ISO-8859-1?Q?D=E4nzer?= [mailto: [EMAIL PROTECTED]brbrTo: [EMAIL PROTECTED]brbr Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]brbrDate: Wed, 10 Mar 2004 13:18:20 +0100brbrSubject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)brbrbrbrOn Wed, 2004-03-10 at 12:24, Felix Kühling wrote:br On Mon, 8 Mar 2004 15:19:32 -0500 (EST)br John H. [EMAIL PROTECTED] wrote:br br well, your suggestion at least makes the speed ok with 800x600(which isn't that great)br br however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that?br br I just remembered that I saw a similar problem on my Radeon 7500 thatbr seemed to be related to AGP texturing. With a normal radeon thebr workaround is to disable AGP textures using an environment variable.brbrNamely RADEON_GARTTEXTURING_FORCE_DISABLE.brbr However, with an IGP chip you don't have that choice.brbrYes, you do. Framebuffer and GART are still separate, even if both liebrin system RAM.brbrbr-- brEarthling Michel Dänzer | Debian (powerpc), X and DRI developerbrLibre software enthusiast | http://svcs.affero.net/rm.php?r=daenzerbrbrbrbr___brNo banners. No pop-ups. No kidding.brIntroducing My Way - http://www.myway.combrbrbr---brThis SF.Net email is sponsored by: IBM Linux TutorialsbrFree Linux tutorial presented by Daniel Robbins, President and CEO ofbrGenToo technologies. Learn everything from fundamentals to systembradministration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=clickbr--br___brDri-users mailing listbr[EMAIL PROTECTED]brhttps://lists.sourceforge.net/lists/listinfo/dri-usersbr ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
sorry, I'm still waiting for someone to tell me exactly how I do what is described here, to stop getting the rainbow stuff. Do i disable this in XF86Config or something? --- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 10 Mar 2004 13:18:20 +0100 Subject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems) On Wed, 2004-03-10 at 12:24, Felix Kühling wrote:br On Mon, 8 Mar 2004 15:19:32 -0500 (EST)br John H. [EMAIL PROTECTED] wrote:br br well, your suggestion at least makes the speed ok with 800x600(which isn't that great)br br however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that?br br I just remembered that I saw a similar problem on my Radeon 7500 thatbr seemed to be related to AGP texturing. With a normal radeon thebr workaround is to disable AGP textures using an environment variable.brbrNamely RADEON_GARTTEXTURING_FORCE_DISABLE.brbr However, with an IGP chip you don't have that choice.brbrYes, you do. Framebuffer and GART are still separate, even if both liebrin system RAM.brbrbr-- brEarthling Michel Dänzer | Debian (powerpc), X and DRI developerbrLibre software enthusiast| http://svcs.affero.net/rm.php?r=daenzerbrbr ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems)
so what do i do? --- On Wed 03/10, Michel =?ISO-8859-1?Q?D=E4nzer?= [EMAIL PROTECTED] wrote: From: Michel =?ISO-8859-1?Q?D=E4nzer?= [mailto: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Wed, 10 Mar 2004 13:18:20 +0100 Subject: Re: Rainbow colors and AGP texturing (was radeon 320m and 3d problems) On Wed, 2004-03-10 at 12:24, Felix Kühling wrote:br On Mon, 8 Mar 2004 15:19:32 -0500 (EST)br John H. [EMAIL PROTECTED] wrote:br br well, your suggestion at least makes the speed ok with 800x600(which isn't that great)br br however, the rainbow color thing is making it unplayable(I can't distinguish between players). is there any way around that?br br I just remembered that I saw a similar problem on my Radeon 7500 thatbr seemed to be related to AGP texturing. With a normal radeon thebr workaround is to disable AGP textures using an environment variable.brbrNamely RADEON_GARTTEXTURING_FORCE_DISABLE.brbr However, with an IGP chip you don't have that choice.brbrYes, you do. Framebuffer and GART are still separate, even if both liebrin system RAM.brbrbr-- brEarthling Michel Dänzer | Debian (powerpc), X and DRI developerbrLibre software enthusiast| http://svcs.affero.net/rm.php?r=daenzerbrbr ___ No banners. No pop-ups. No kidding. Introducing My Way - http://www.myway.com --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click -- ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] DRI proprietary modules
For DRI to work correctly there are several independent pieces that all have to be in sync. * XFree86 server which loads drm modules (via xfree86 driver module) * The drm kernel module * The agpgart kernel module Does anybody know for the proprietary drivers (supplied by ATI and Nvidia) which pieces they replace and which pieces they expect to be there? The reason I'm asking is to understand the consequences of changing an API. I'm curious to the answer in general, but in this specific instance the api I'm worried about is between the agpgart kernel module and drm kernel module. If the agpgart kernel module modifies it's API will that break things for someone who installs a proprietary 3D driver? Do the proprietary drivers limit themselves to mesa driver and retain the existing kernel services assuming the IOCTL's are the same? Or do they replace the kernel drm drivers as well? If so do they manage AGP themselves, or do they use the systems agpgart driver? Do they replace the systems agpgart driver? -- John Dennis [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. SourceForge.net hosts over 70,000 Open Source Projects. See the people who have HELPED US provide better services: Click here: http://sourceforge.net/supporters.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Deadlock with radeon DRI
The locking problem is solved, my original analysis was incorrect. The
problem was that DRM_CAS was not correctly implemented on IA64. Thus
this was an IA64 issue only, this is consistent with others who showed
up in a google search describing the problem, all were on IA64.
I have filed an XFree86 bug report on this. I could not find a DRI
specific bug reporting mechanism other than the dri-devel list.
The IA64 implementation of CAS was this:
#define DRM_CAS(lock,old,new,__ret) \
do { \
unsigned int __result, __old = (old); \
__asm__ __volatile__( \
mf\n\
mov ar.ccv=%2\n \
;;\n\
cmpxchg4.acq %0=%1,%3,ar.ccv\
: =r (__result), =m (__drm_dummy_lock(lock)) \
: r (__old), r (new) \
: memory); \
__ret = (__result) != (__old);\
} while (0)
The problem was with the data types given to the cmpxchg4
instruction. All of the lock types in DRM are int's and on IA64 thats
4 bytes wide. The digit suffix cmpxchg4 signifies this instruction
operates on a 4 byte quantity. One might expect then since this
instruction operates on 4 byte values and in DRM the locks are 4 bytes
everything is fine, but it isn't.
The cmpxchg4 instruction operates this way:
cmpxchg4 r1=[r3],r2,ar.ccv
4 bytes are read at the address pointed to by r3, that 32 bit value is
then zero extended to 64 bits. The 64 bit value is then compared to
the 64 bit value stored in appliation register CCV. If the two 64 bit
values are equal then the least significant 4 bytes in r2 are written
back to the address pointed to by r3. The original value pointed to by
r3 is stored in r1. The entire operation is atomic.
The mistake in the DRM_CAS implemenation is that the comparison is 64
bits wide, thus the value stored in ar.ccv (%2 in the asm) must be 64
bits wide and for us that means zero extending the 32 bit old
parameter to 64 bits.
Because of the way GCC asm blocks work to tie C variables and data
types to asm values the promotion of old from unsigned int to
unsigned long was not happening. Thus when old was stored into
ar.ccv its most significant 32 bits contained garbage. (Actually
because of the way GCC generates constants it turns out the upper 32
bits was 0x, this was from the OR of DRM_LOCK_HELD which is
defined as 0x8000, but the compiler generates a 64 bit OR
operation using the immediate value 0x8000, which is legal
because the upper 32 bits are undefined on int (32 bit) operations).
The bottom line is that the test would fail when it shouldn't because
the high 32 bits in ar.ccv were not zero.
One might think that because old was assigned to __old in a local
block which was unsigned int the compiler would know enough when using
this value in the asm to have zero extended it. But that's not true,
in asm blocks its critical to define the asm value correctly so the
compiler can translate between the C code variable and what the asm
code is referring to.
The line:
: r (__old), r (new)
says %2 is mapped by r (__old), in other words put __old in a
general 64 bit register. We've told the compiler to put 64 bits of
__old into a register, but __old is a 32 bit value with its high
order 32 bits undefined. We need to tell the compiler to widen the
type when assigning it to a general register, thus the asm template
type definition needs to be modified with a cast to unsigned long.
: r ((unsigned long)__old), r (new)
Only with this will the compiler know to widen the 32 bit __old value
to 64 bits inside the asm code.
Thanks to Jakub Jelinek who helped me understand the nuances of GCC
asm templates and type conversions.
As a minor side note, definitions of bit flags should be tagged as
unsigned. Thus things like:
#define DRM_LOCK_HELD 0x8000
#define DRM_LOCK_CONT 0x4000
should really be:
#define DRM_LOCK_HELD 0x8000U
#define DRM_LOCK_CONT 0x4000U
John
---
This SF.net email is sponsored by: SF.net Giveback Program.
SourceForge.net hosts over 70,000 Open Source Projects.
See the people who have HELPED US provide better services:
Click here: http://sourceforge.net/supporters.php
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] bug in light locks?
I've been trying to track down a DRI client and server deadlock problem. I think I now know the problem, I'd appreciate it if others could confirm this is a bug or if I have a misunderstanding. This is the scenario: 1) Client takes heavyweight lock via ioctl, lock now has DRM_LOCK_HELD bit or'ed in, high nibble is now 0x8. 2) Server requests heavyweight lock on a different context via ioctl, lock is held by client, server is suspened pending release of lock by client. The DRM_LOCK_CONT flag is or'ed in, high nibble is now 0xC. 3) Client wants to take lightweight lock, client currently holds lock. A CAS test is performed between the lock and (DRM_LOCK_HELD | context). The CAS test fails because even though the context is the same the high nibble now has both the DRM_LOCK_HELD and the DRM_LOCK_CONT flags or'ed into it. The test would have succeeded if the DRM_LOCK_CONT flags was not set. Because the test fails the client does not believe it owns the lock (but it does!) and then issues heavyweight ioctl lock on the very context it already owns the lock on. 4) In the kernel driver DRM(take_lock) discovers the lock is already held on that context by that process. It issues an ERROR message, and returns 0. A zero return value indicates the lock cannot be taken, it then suspends the client waiting for the lock to be released, but it is this client that holds the lock, both the client and server are now suspended both waiting for a lock release that will never occur, a classic deadlock. Assuming my analysis is correct I see the following possible solutions: 1) Invoke CAS twice, once with (DRM_LOCK_HELD | context) and if it fails try once again with (DRM_LOCK_HELD | DRM_LOCK_CONT | context) 2) remove the DRM_LOCK_CONT from the lock and put the flag elsewhere. 3) Have CAS (or better a macro that wraps it) mask out bits not belonging to the test (at the moment thats just DRM_LOCK_CONT). 4) Have DRM(take_lock) return TRUE if the lock is already held. I think this is a bad choice because it violates the locking semantics of no nested heavyweight locks in the driver. The client would continue to be confused over when to lock and unlock, thus no matter what the client needs to be fixed. Questions: 1) Does the analysis sound correct? 2) If so, which approach is preferred? I need to make a patch to fix this, might as well do in a manner that keeps the upstream developers happy. My personal preference is solution #3. John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Deadlock with radeon DRI
[Note: this is cross posted between dri-devel and [EMAIL PROTECTED] ] I'm trying to debug a hung X server problem with DRI using the radeon driver. Sources are XFree86 4.3.0. This happens to be on ia64, but at the moment I don't see anything architecture specific about the problem. The symptom of the problem is the following message from the drm radeon kernel driver: [drm:radeon_lock_take] *ERROR* x holds heavyweight lock where x is a context id. I've tracked the sequence of events down to the following: DRIFinishScreenInit is called during the radeon driver initialization, inside DRIFinishScreenInit is the following code snippet: /* Now that we have created the X server's context, we can grab the * hardware lock for the X server. */ DRILock(pScreen, 0); pDRIPriv-grabbedDRILock = TRUE; Slightly later on RADEONAdjustFrame is called and it does the following: #ifdef XF86DRI if (info-CPStarted) DRILock(pScrn-pScreen, 0); #endif Its this DRILock which is causing the *ERROR* x holds heavyweight lock message. The reason is both DRIFinishScreenInit and RADEONAdjustFrame are executing in the server and using the servers DRI lock. DRIFinishScreenInit never unlocks, it sets the grabbedDRILock flag, big deal, no one ever references this flag. When RADEONAdjustFrame calls DRILock its already locked because DRIFinishScreenInit locked and never unlocked. The dri kernel driver on the second lock call then suspends the X server process (DRM(lock_take) returns zero to DRM(lock) because the context holding the lock and context requesting the lock are the same, this then causes DRM(lock) to put the X server on the lock wait queue). Putting the X server on the wait queue waiting for the lock to be released then deadlocks the X server because its the process holding the lock on its context. Questions: The whole crux of the problem seems to me the taking and holding of the lock in DRIFinishScreenInit. Why is this being done? I can't see a reason for it. Why does it set a flag indicating its holding the lock if nobody examines that flag? Is suspending a process that already holds a lock during a lock request really the right behavior? Granted, a process thats trying to lock twice without an intervening unlock is broken, but do we really want to deadlock that process? Any other insights to this issue? FWIW, I googled for this error and came up with several folks who starting around last spring started seeing the same problem, but none of the mail threads had a follow up solution. Thanks, John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] drm vs. drm-4.0
In the linux 2.4 kernel tree under drivers/char there is both a drm subdirectory and a drm-4.0 subdirectory. I've looked high and low for an explanation of drm vs. drm-4.0, I assume its a version difference, but I've come up dry. Can someone either explain to me what drm-4.0 is or send me a pointer to something that documents it. I'd like to know why one implementation is picked over the other, are there version dependencies, why it exists as parallel to drm and what its trying to fix. Thanks, John -- John Dennis [EMAIL PROTECTED] --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T)
After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modulesmake[1]: Entering directory `/home/john/dripkg/drm'make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modulesmake[2]: Entering directory `/usr/src/linux-2.4.20-8'make -r -f tmp_include_depends allmake[3]: Entering directory `/usr/src/linux-2.4.20-8'touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h': No such file or directorymake[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h] Error 1make[3]: Leaving directory `/usr/src/linux-2.4.20-8'make[2]: *** [tmp_include_depends] Error 2make[2]: Leaving directory `/usr/src/linux-2.4.20-8'make[1]: *** [modules] Error 2make[1]: Leaving directory `/home/john/dripkg/drm'make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. --John
Re: [Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T)
Please explain this a little more. You say you have the kernel source installed, but that's not enough. It must be configured exactly as your target kernel and the dependencies must have been made, i.e., 'make dep' on the kernel source dir. I did this, it gave me the same errors. Also try just doing: make -f Makefile.linux radeon.o on /home/john/dripkg/drm and see if it helps. - Original Message - From: José Fonseca [EMAIL PROTECTED] To: John R. Tomawski [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 02, 2003 10:05 AM Subject: Re: [Dri-devel] ERROR COMPILING - DRI Driver Installation (R E P O S T) John, On Wed, Jul 02, 2003 at 09:15:42AM -0400, John R. Tomawski wrote: After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modules make[1]: Entering directory `/home/john/dripkg/drm' make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modules make[2]: Entering directory `/usr/src/linux-2.4.20-8' ^^ You say you have the kernel source installed, but that's not enough. It must be configured exactly as your target kernel and the dependencies must have been made, i.e., 'make dep' on the kernel source dir. Also try just doing: make -f Makefile.linux radeon.o on /home/john/dripkg/drm and see if it helps. make -r -f tmp_include_depends all make[3]: Entering directory `/usr/src/linux-2.4.20-8' touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug. h': No such file or directory make[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug. h] Error 1 make[3]: Leaving directory `/usr/src/linux-2.4.20-8' make[2]: *** [tmp_include_depends] Error 2 make[2]: Leaving directory `/usr/src/linux-2.4.20-8' make[1]: *** [modules] Error 2 make[1]: Leaving directory `/home/john/dripkg/drm' make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. José Fonseca --- This SF.Net email sponsored by: Free pre-built ASP.NET sites including Data Reports, E-commerce, Portals, and Forums are available now. Download today and enter to win an XBOX or Visual Studio .NET. http://aspnet.click-url.com/go/psa0016ave/direct;at.asp_061203_01/01 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Error compiling - DRI Driver Installation
After I see this: Compiling... ERROR: Kernel modules did not compile I get the following in dri.log, when I try sh install.sh make -f Makefile.linux DRM_MODULES=radeon.o modulesmake[1]: Entering directory `/home/john/dripkg/drm'make -C /lib/modules/2.4.20-8/build SUBDIRS=`pwd` DRMSRCDIR=`pwd` modulesmake[2]: Entering directory `/usr/src/linux-2.4.20-8'make -r -f tmp_include_depends allmake[3]: Entering directory `/usr/src/linux-2.4.20-8'touch: creating `/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h': No such file or directorymake[3]: *** [/usr/src/build/231485-i386/install/usr/src/linux-2.4.20-8/fs/jfs/jfs_debug.h] Error 1make[3]: Leaving directory `/usr/src/linux-2.4.20-8'make[2]: *** [tmp_include_depends] Error 2make[2]: Leaving directory `/usr/src/linux-2.4.20-8'make[1]: *** [modules] Error 2make[1]: Leaving directory `/home/john/dripkg/drm'make: *** [radeon.o] Error 2 I have RedHat 9 and an ATI Radeon 64MB DDR VIVO. Yes, I do have the kernel source installed. --John
[Dri-devel] DRM errors on an i830
I just tried to fire up Quake III on a laptop with an Intel 830 chipset and the i830 DRI snapshot from a couple of days ago. The game started, but only displayed one frame (I think). I switched consoles, killed Q3, and then got this message on the console: [drm:i830_wait_ring] *ERROR* space: 131048 wanted 131064 [drm:i830_wait_ring] *ERROR* lockup I've seen similar errors before, but I don't know if they were exactly the same. I can get NWN to play on here at about 13 fps with those drivers, but there are some other problems there. (It has stuttering audio, at roughly the frequency corresponding to the games frame rate. It also crashes eventually. I was trying out Q3 for the first time on this laptop to see if it experiences the same problems. I haven't been able to see if the same error appears on the console in NWN, though.) Glxgears runs fine on here, with 148 fps. (Slow, but is this normal for this chipset?) Glxinfo reports that direct rendering _is_ working. The X server, by the way, is the XFree86 4.3.0 shipped w/ Red Hat 9, and the kernel is the Red Hat 9 kernel w/ the Dec. 12 ACPI patches applied. As far as I can tell, the kernel drm module and server module for the Intel 830 driver I downloaded are installed correctly. I was getting DRM errors with Red Hat 8.0, too, but I don't know whether they were the same ones or not. They occured using Galeon, rather than a 3D client. I didn't write down the errors there, because I thought that upgrading to Red Hat 9 and the latest drivers would probably make them go away. But, they sure looked similar to what I'm seeing now. Does anyone have an idea of where the problem might be? (I've done a little bit of work on the R100 driver myself, and wanted to look through the i830 source myself, but the anonymous CVS servers have been a wreck for the last few days.) Thanks for the help! John --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Rage 128 texmem problems
I think it's a been a decent interval to resend The problem was with a PCI Rage128 card (16 MB video RAM) which seemed to have problems with memory allocation (i.e. 0 kb texture memory allocated at 1280 * 1024, only 4MB at 1024768). Since the box claims 3D performance at 1280 in Windows, I was wondering if this was just a driver issue. On Friday 06 June 2003 08:56 am, Ian Romanick wrote: Hmmm...that is odd. The resolution should only require 7.5MB for the front, back, and depth-buffers. That should leave about 8MB for textures, not 800KB. Are you sure it's at 16-bpp? ~800KB left is about rigth if you were running at 24-bpp. I'm sure (or my system is sure) it's 16 bpp. Switching to 1024 * 768 @ 16, I see only 4MB. Would this figure be on-card or system memory? More stuff from the XFree logs: Found a line: (--) Depth 24 pixmap format is 32 bpp After XAA is loaded. Then we have the perhaps useful lines here: (II) R128(0): [drm] loaded kernel module for r128 driver (II) R128(0): [drm] created r128 driver at busid PCI:1:14:0 (II) R128(0): [drm] added 8192 byte SAREA at 0xd2a22000 (II) R128(0): [drm] mapped SAREA 0xd2a22000 to 0x40018000 (II) R128(0): [drm] framebuffer handle = 0xf800 (II) R128(0): [drm] added 1 reserved context for kernel (II) R128(0): [pci] 8192 kB allocated with handle 0xd3b17000 (II) R128(0): [pci] ring handle = 0xd3b17000 (II) R128(0): [pci] Ring mapped at 0x411b2000 (II) R128(0): [pci] Ring contents 0x (II) R128(0): [pci] ring read ptr handle = 0xd3c18000 (II) R128(0): [pci] Ring read ptr mapped at 0x4001a000 (II) R128(0): [pci] Ring read ptr contents 0x (II) R128(0): [pci] vertex/indirect buffers handle = 0xd3c19000 (II) R128(0): [pci] Vertex/indirect buffers mapped at 0x412b3000 (II) R128(0): [pci] Vertex/indirect buffers contents 0x (II) R128(0): [drm] register handle = 0xf0104000 (II) R128(0): [dri] Visual configs initialized (II) R128(0): CCE in BM mode (II) R128(0): Using 8 MB AGP aperture (II) R128(0): Using 1 MB for the ring buffer (II) R128(0): Using 2 MB for vertex/indirect buffers (II) R128(0): Using 1 MB for AGP textures (II) R128(0): Memory manager initialized to (0,0) (1024,3072) (II) R128(0): Reserved area from (0,768) to (1024,770) (II) R128(0): Largest offscreen area available: 1024 x 2302 (II) R128(0): Reserved back buffer from (0,770) to (1024,1538) (II) R128(0): Reserved depth buffer from (0,1538) to (1024,2307) (II) R128(0): Reserved depth span from (0,2306) offset 0x902000 (II) R128(0): Reserved 4096 kb for textures at offset 0xc0 (II) R128(0): Using XFree86 Acceleration Architecture (XAA) Maybe that will help. (this is at 1024 x 768 @ 16 bpp) --- --- This SF.Net email is sponsored by: INetU Attention Web Developers Consultants: Become An INetU Hosting Partner. Refer Dedicated Servers. We Manage Them. You Get 10% Monthly Commission! INetU Dedicated Managed Hosting http://www.inetu.net/partner/index.php ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
On Thursday 05 June 2003 11:45 am, Leif Delgass wrote: I'm pretty sure I ran into this problem on r128 before when I tried running at 24-bit depth with a high enough resolution. If this is the problem, I think you'd see a message like: Reserved 0 kb for textures at offset 0x0 in the X log. Right, that appears in the logs. So what to do? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Test
Just a testI think my e-mail might not be getting through --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
On Thursday 05 June 2003 11:45 am, Leif Delgass wrote: I'm pretty sure I ran into this problem on r128 before when I tried running at 24-bit depth with a high enough resolution. If this is the problem, I think you'd see a message like: Reserved 0 kb for textures at offset 0x0 in the X log. Right, that appears in the logs. So what to do? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems
On Friday 06 June 2003 08:56 am, Ian Romanick wrote: Hmmm...that is odd. The resolution should only require 7.5MB for the front, back, and depth-buffers. That should leave about 8MB for textures, not 800KB. Are you sure it's at 16-bpp? ~800KB left is about rigth if you were running at 24-bpp. I'm sure (or my system is sure) it's 16 bpp. Switching to 1024 * 768 @ 16, I see only 4MB. Would this figure be on-card or system memory? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems
On Friday 06 June 2003 10:39 am, you wrote: On Friday 06 June 2003 08:56 am, Ian Romanick wrote: Hmmm...that is odd. The resolution should only require 7.5MB for the front, back, and depth-buffers. That should leave about 8MB for textures, not 800KB. Are you sure it's at 16-bpp? ~800KB left is about rigth if you were running at 24-bpp. I'm sure (or my system is sure) it's 16 bpp. Switching to 1024 * 768 @ 16, I see only 4MB. Would this figure be on-card or system memory? More stuff from the XFree logs: Found a line: (--) Depth 24 pixmap format is 32 bpp After XAA is loaded. Then we have the perhaps useful lines here: (II) R128(0): [drm] loaded kernel module for r128 driver (II) R128(0): [drm] created r128 driver at busid PCI:1:14:0 (II) R128(0): [drm] added 8192 byte SAREA at 0xd2a22000 (II) R128(0): [drm] mapped SAREA 0xd2a22000 to 0x40018000 (II) R128(0): [drm] framebuffer handle = 0xf800 (II) R128(0): [drm] added 1 reserved context for kernel (II) R128(0): [pci] 8192 kB allocated with handle 0xd3b17000 (II) R128(0): [pci] ring handle = 0xd3b17000 (II) R128(0): [pci] Ring mapped at 0x411b2000 (II) R128(0): [pci] Ring contents 0x (II) R128(0): [pci] ring read ptr handle = 0xd3c18000 (II) R128(0): [pci] Ring read ptr mapped at 0x4001a000 (II) R128(0): [pci] Ring read ptr contents 0x (II) R128(0): [pci] vertex/indirect buffers handle = 0xd3c19000 (II) R128(0): [pci] Vertex/indirect buffers mapped at 0x412b3000 (II) R128(0): [pci] Vertex/indirect buffers contents 0x (II) R128(0): [drm] register handle = 0xf0104000 (II) R128(0): [dri] Visual configs initialized (II) R128(0): CCE in BM mode (II) R128(0): Using 8 MB AGP aperture (II) R128(0): Using 1 MB for the ring buffer (II) R128(0): Using 2 MB for vertex/indirect buffers (II) R128(0): Using 1 MB for AGP textures (II) R128(0): Memory manager initialized to (0,0) (1024,3072) (II) R128(0): Reserved area from (0,768) to (1024,770) (II) R128(0): Largest offscreen area available: 1024 x 2302 (II) R128(0): Reserved back buffer from (0,770) to (1024,1538) (II) R128(0): Reserved depth buffer from (0,1538) to (1024,2307) (II) R128(0): Reserved depth span from (0,2306) offset 0x902000 (II) R128(0): Reserved 4096 kb for textures at offset 0xc0 (II) R128(0): Using XFree86 Acceleration Architecture (XAA) Maybe that will help. (this is at 1024 x 768 @ 16 bpp) --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Rage 128 texmem problems (was Re: Snapshots missing libGL.so?)
On Thursday 05 June 2003 07:08 pm, Leif Delgass wrote: Try a lower resolution and/or color depth. We can fix the segfault, but that won't change the fact that there isn't enough on-card memory to use 3D at the configured resolution/depth (at least with the current static shared back buffer allocation scheme). Right then, it works. But being the person I am, I just can't leave well enough alone The box on my card (XPert 128 [r128 chip, 16 MB RAM] ) claims 1280 * 1024 @ 16 bbp. Is that then OS- or driver-specific? I would think the card has at least those capabilities. Currently in Linux I'm at 1152 * 864 @ 16 bbp (1280 * 1024 segfaults) and the logs claim: (II) R128(0): Reserved 832 kb for textures at offset 0xf3 Seems awful low to me. (Of course, I wouldn't have the background to know better). So is this a DRI driver issue? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Managed to get my r128 working by lowering res/bpp (duh moment) One more thing I noticed: in my wide journeys in getting my DRI to work one of the things I did was to replace my distro-supplied (Mandrake 9.1) libGL.so with the one off the DRI download site. Now that I have working 3D accel, I find that I hit a segfault if I try to go back to the Mandrake libGL.so . Try replacing the Mandrake-supplied one, maybe it will work (and make sure the symbolic links get sorted out). Good luck --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Output of gdb on glxinfo: Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2145)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2145)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
Some relevant background: About a month ago, I clean-installed Mandrake 9.1 on the system. XFree + DRI works great, except for the fact that the r128 driver was an old system and evidently had problems with my PCI Rage128 card. So I downloaded the binary driver packages and installed, with the result of a segfault with anything hardware-accelerated (glxinfo, glxgears, tuxracer, etc.) So I tried compiling from scratch, etc, then doing the driver packages again. No luck as usual. Along the way I noticed that with the (Mandrake packaged) system came libGL.so.1.4.500 but with the self-compiled comes libGL.so.1.2 . Perhaps this could be a problem? --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] Snapshots missing libGL.so?
On Wednesday 04 June 2003 03:56 am, José Fonseca wrote: Please do: # gdb glxgears run ... bt And send the resulting backtrace to pinpoint the problem. Didn't notice you wanted the backtrace. Here it is (whole) [start] Starting program: /usr/X11R6/bin/glxinfo (no debugging symbols found)...[New Thread 16384 (LWP 2817)] name of display: :0.0 Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 16384 (LWP 2817)] 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 584 texmem.c: No such file or directory. in texmem.c (gdb) (gdb) (gdb) (gdb) bt #0 0x4046dee5 in driSetTextureSwapCounterLocation (heap=0x0, counter=0x8051c18) at texmem.c:584 #1 0x4046e8a9 in r128CreateContext (glVisual=0xb410, driContextPriv=0x804d698, sharedContextPrivate=0x1) at r128_context.c:151 #2 0x4037329b in driCreateContext (dpy=0x804c618, vis=0x8051870, sharedPrivate=0x0, pctx=0x8054814, fbconfig=0x0) at dri_util.c:1007 #3 0x4008c756 in CreateContext (dpy=0x804c618, vis=0x8051870, shareList=0x0, allowDirect=1, contextID=0) at glxcmds.c:220 #4 0x4008c8ad in glXCreateContext (dpy=0x804c618, vis=0x8051870, shareList=0x0, allowDirect=1) at glxcmds.c:264 #5 0x08048fd0 in strcpy () #6 0x0804a1aa in strcpy () #7 0x402347f7 in __libc_start_main () from /lib/i686/libc.so.6 [end] --- This SF.net email is sponsored by: Etnus, makers of TotalView, The best thread debugger on the planet. Designed with thread debugging features you've never dreamed of, try TotalView 6 free at www.etnus.com. ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Bin. driver packages
Two questions... 1. Are the wrapped binary driver packages ever coming back? 2. It seems with an old one I got (binary driver packages) it was missing the libGL's so that once installed, (for example) glxinfo segfaults as it tries to load old libGL's. An oversight or purposeful omission? Thanks John --- This SF.net email is sponsored by: eBay Get office equipment for less on eBay! http://adfarm.mediaplex.com/ad/ck/711-11697-6916-5 ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Lose $ on Markets?
Title: Free Please Read: Very Important Information for You Your Future. Investment Bankers and Analysts Provide You With Information Only They Want to Hear...Their Buy Recommendations Always Seem Wrong...They Lose You Money...And All of That is While They Collect Big Fees Now You're In Charge with our FREE Letter! You can now have the same information used by professional Swiss Investors to make money in the market by trading long, short, and even using options. See for yourself. Don't miss this one-time opportunity. Subscribe for a Free Trial of our Investment Research Letter based in Basel, Switzerland Just Fill Out Our Simple Form and Receive Your One Month Free Trial Subscription Under No Obligation. Let Us Prove We Are Right Show you how to make Money! Click Here Now - don't miss out Opt-Out Instructions: We are strongly against sending unsolicited emails to those who do not wish to receive our special mailings. We have attained the services of an independent 3rd party to overlook list management and removal services. If you do not wish to receive further mailings, please visit the link below be removed from the list. Please accept our apologies if you have been sent this email in error. We honour all removes requests: Click Here --- This SF.net email is sponsored by: SlickEdit Inc. Develop an edge. The most comprehensive and flexible code editor you can use. Code faster. C/C++, C#, Java, HTML, XML, many more. FREE 30-Day Trial. www.slickedit.com/sourceforge ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [XFree86] Re: Security in new drivers
On Fri, Feb 14, 2003 at 10:14:21PM +0100, Michel D?nzer wrote: Also keep in mind that access to the DRI can be controlled via ownership and permissions of the /dev/dri/cardX devices. On a private machine this is method is effective. On a public machine, such as a University lab, where all users must be considered hostile this is less effective. Thanks for the infomation. John Bartoszewski Email: [EMAIL PROTECTED] Senior Systems/Security Administrator .--. Instructional Laboratories: If you are not terrified : Department of Computing Science : you are just repeating yourself. : University of Alberta, Canada `._- Gilbert and George _.' --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problem with DRM/Radeon 7000
On Tue, Feb 11, 2003 at 03:07:57PM +0100, Michel Dänzer mentioned: The point is that this is either the wrong (too old) radeon module, or the radeon DRM is already built into the kernel (in which case you can load another one as a module unfortunately, but clients see the one built into the kernel). Ah. I should have thought of that! OK, I've a rebuild kernel. radeon.o and agpgart.o are modprobed. However, I get the same error. Is there a method I can use strings or some such to verify that all the required libraries are matching versions ? (Problem being I'm no longer sure what libraries are supposed to be used). glxinfo -v does output; OpenGL renderer string: Mesa DRI Radeon 20021125 AGP 1x x86/MMX/SSE NO-TCL OpenGL version string: 1.2 Mesa 5.0 Is this good ? John --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problem with DRM/Radeon 7000
On Wed, Feb 12, 2003 at 04:33:03PM +0100, Michel Dänzer mentioned: OK, I've a rebuild kernel. radeon.o and agpgart.o are modprobed. However, I get the same error. What does dmesg | grep '\[drm\]' say? ratbert[11]:~% dmesg | grep '\[drm\]' [drm] AGP 0.99 on Intel i845 @ 0xf800 64MB [drm] Initialized radeon 1.7.0 20020828 on minor 0 glxinfo -v does output; OpenGL renderer string: Mesa DRI Radeon 20021125 AGP 1x x86/MMX/SSE NO-TCL OpenGL version string: 1.2 Mesa 5.0 Is this good ? Yes, it means the DRI should work once the DRM is new enough. Hmm. OK, so I've to match the DRM date and the renderer date. And it looks like the DRM is really old. OK, I'll try update that...properly. John --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problem with DRM/Radeon 7000
On Tue, Feb 11, 2003 at 12:36:54AM +0100, Michel Dänzer mentioned: On Mon, 2003-02-10 at 19:31, John P. Looney wrote: Hi, I was using the old Radeon drivers that shipped with a dist-upgraded Woody, though they were mostly fine in Quake3, in Wolfenstien, there were severe problems with corrupted textures. After noting a few people were recommended to upgrade to get rid of these problems, I did. To upgrade, I used drm-trunk-module-2.4.18 from debian woody. Huh? Where exactly did you get that from? Get which - the code or the recommendation ? The recommendation was from this list, some months ago, and the code was from the URL below... The code seems to be dated Jan 18 2003. I got the .debs via apt from http://people.debian.org/~daenzer/dri-trunk/ Received signal 8, exiting... This bug should be fixed in the packages for sid at deb http://people.debian.org/~daenzer/dri-trunk-sid/./ I'll hopefully get around to updating the packages for woody/sarge soon (once those for sid have settled a bit), in the meantime I think setting MESA_NO_SSE=1 should serve as a workaround. I tried that, and got: wolf.x86: radeon_ioctl.h:165: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Received signal 6, exiting... As soon as I get some broadband, I'll upgrade to sid. I'm still on ISDN here, so I didn't think upgrading to sid would be a good idea. Can the source packages for sid be compiled on woody, without much effort ? I'll give that a go, if it's possible. John --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problem with DRM/Radeon 7000
On Mon, Feb 10, 2003 at 11:24:58PM +0100, Jacek Pop³awski mentioned: On Mon, Feb 10, 2003 at 06:31:37PM +, John P. Looney wrote: Hi, I was using the old Radeon drivers that shipped with a dist-upgraded Woody, though they were mostly fine in Quake3, in Wolfenstien, there were severe problems with corrupted textures. Could you try driver 20021022 (from dri.sf.net downloads)? As I wrote in other post - flickering textures are only visible in latest version of driver. I can't see any mention of older drivers, just a link to: http://www.xfree86.org/~alanh/ Is there an archive ? If the problems are known, and fixable, I don't mind waiting a while for new drivers to be released. John --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] problem with DRM/Radeon 7000
On Tue, Feb 11, 2003 at 02:28:58PM +0100, Michel Dänzer mentioned: Well, that's the source of my confusion - I don't provide a drm-trunk-module-2.4.18 package, and neither does Debian woody. I'll just assume you built it yourself from drm-trunk-module-src. Ah yes, I did build it from your drm-trunk-module-src package. wolf.x86: radeon_ioctl.h:165: radeonAllocCmdBuf: Assertion `rmesa-dri.drmMinor = 3' failed. Received signal 6, exiting... Now you need to make sure the new DRM is actually used. The easiest way to achieve that is probably to disable the DRM in the kernel. I don't understand...I've got these loaded at the moment: ratbert:/var/www# lsmod Module Size Used byNot tainted i810 64472 0 (unused) radeon107896 0 (unused) radeonfb 17888 0 (unused) fbcon-cfb24 4320 0 [radeonfb] fbcon-cfb8 3392 0 [radeonfb] fbcon-cfb32 3744 0 [radeonfb] fbcon-cfb16 4032 0 [radeonfb] Should the radeon.o not be loaded ? What would then provide the DRM functionality ? John --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] problem with DRM/Radeon 7000
Hi, I was using the old Radeon drivers that shipped with a dist-upgraded
Woody, though they were mostly fine in Quake3, in Wolfenstien, there were
severe problems with corrupted textures.
After noting a few people were recommended to upgrade to get rid of these
problems, I did. To upgrade, I used drm-trunk-module-2.4.18 from debian
woody. The code seems to be dated Jan 18 2003. I got the .debs via apt
from http://people.debian.org/~daenzer/dri-trunk/
When I try Wolfenstien now, it doesn't even start:
Started tty console (use +set ttycon 0 to disable)
^5PunkBuster Client: PunkBuster Client (v1.017 | A0) Enabled
^3PunkBuster Server: PunkBuster Server (v0.993 | A0 C0.0) **DISABLED**
Resolving wolfmotd.idsoftware.com
wolfmotd.idsoftware.com resolved to 192.246.40.65:27951
Received signal 8, exiting...
Shutdown tty console
strace reports:
6882 write(2, Using 4/4/4 Color bits, 24 depth..., 53) = 53
6882 write(33, \221\24 \0\1\0\0\0\2\0\0\0m\0\0\0GL_ARB_multitext..., 376) = 376
6882 write(33, +\24\1\0, 4) = 4
6882 read(33, \23\0\'\0\2\0`\0\2\0`\0\1\0\0\0\22\0\0\0\1\0\0\0\254\315..., 32) = 32
6882 read(33, \17\367\'\0\2\0`\0\0E\253\10\230\367\340\1\200\2\200\2..., 32) = 32
6882 read(33, \1\2)\0\0\0\0\0Y\0\200\0\0\0\0\0\1\0\0\0\0\0\0\0\0\0\0..., 32) = 32
6882 old_mmap(NULL, 266240, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) =
0x48ca1000
6882 write(33, \200\5\4\0\0\0\0\0\'\0\0\0\3\0`\0, 16) = 16
6882 read(33, \1\236*\0\0\0\0\0\7\0\0\0\0\0\0\0\214\370\377\277\1\0\0..., 32) = 32
6882 write(33, \200\5\4\0\0\0\0\0\'\0\0\0\4\0`\0, 16) = 16
6882 read(33, \1\236+\0\0\0\0\0\10\0\0\0\0\0\0\0\214\370\377\277\1\0..., 32) = 32
6882 brk(0xa514000)= 0xa514000
6882 rt_sigaction(SIGILL, NULL, {0x80d5014, [ILL], SA_RESTART|0x400}, 8) = 0
6882 rt_sigaction(SIGFPE, NULL, {0x80d5014, [FPE], SA_RESTART|0x400}, 8) = 0
6882 rt_sigaction(SIGILL, {0x464d26b4, [ILL], SA_RESTART|0x400}, {0x80d5014,
[ILL], SA_RESTART|0x400}, 8) = 0
6882 rt_sigaction(SIGFPE, {0x464d26d4, [FPE], SA_RESTART|0x400}, {0x80d5014,
[FPE], SA_RESTART|0x400}, 8) = 0
6882 --- SIGFPE (Floating point exception) ---
Could this be a problem with the DRM upgrade ? I'd upgraded all the
packages in that apt repository mentionedcould their be more i'm
missing ?
John
---
This SF.NET email is sponsored by:
SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
http://www.vasoftware.com
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Confusing..?
I just last night downloaded the newest CVS from dri.sourceforge.net.. and tried compiling it.. it went smoothly.. no errors.. *BUT*.. none of the kernel modules were created.. for *any* of the video drivers listed in the host.def file.. Any ideas? -- John S. Chalice
[Dri-devel] Which card?
I posted this on the XFree86 list, but was refered here instead. I'm getting ready to rebuild my system from scratch and am pondering which card to put into it. 1) a 3DLabs GVX1 AGP card. This works fine in 2D but the 3D support is still pending. I would prefer to work with this card as I'm very interested in 3D stuff and plan to get 3D glasses (one day ;-) 2) an ATI Rage128 card. I understand that this does have 3D support, but would it warrant getting rid of hte GVX card? I think there should be much better capabilities in the GVX1 card. Plus, the ATI card does not work with 3D glasses. Unfortunately, I've only one box with AGP, my regular desktop, though I also have a PCI version of the GVX card. That is in my daughters PC. I'm not much of a programmer, yet, but I am working on it. See homepage.eircom.net/johngay/frames.html for an example of the limits of my C knowledge. I was hoping that getting inside the gamma and pm3 code could be enlightening, eventually. Cheers, John Gay --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] Bug in compilation?
John S. Chalice wrote: I am attempting to recompile DRI on my newly configured Mandrake 9.0 system.. but it cuts out with an error on line 14282 or so of my log file.. with an error in a gcc line.. it's the only place it tries to use the Xpm library "-lXpm" and for some reason, it says it can't find it. Any ideas? Could you send the specific compiler output? You don't have to send the whole output from make, just the part that shows the error.- rm -f xf86cfggcc -m32 -o xf86cfg -march=i686 -O3 -pipe -ansi -Wno-return-type -w -pipe -g -L../../../../../exports/lib -L/usr/X11R6/lib accessx.ocards.oconfig.ocard-cfg.oexpert.ohelp.ointerface.okeyboard-cfg.olibc_wrapper.o loader.o loadmod.o monitor-cfg.omouse-cfg.ooptions.oscreen-cfg.oscreen.ostartx.ostubs.otext-mode.ovidmode.oxf86config.o -lxkbui -lxkbfile -lxf86config -lXxf86misc -lXxf86vm -lXaw -lXmu -lXt -lSM -lICE -lXext -lX11 -lXt -lSM -lICE -lXpm -L../loader -lxloader -L../dummylib -ldummy -rdynamic -ldl -lXext -lX11 -lncurses -lm -Wl,-rpath-link,../../../../../exports/lib/usr/bin/ld: cannot find -lXpmcollect2: ld returned 1 exit statusmake[6]: *** [xf86cfg] Error 1make[6]: Target `all' not remade because of errors. --- There 'tis :) Thanks for any help. :) -- John S. Chalice
[Dri-devel] Bug in compilation?
I am attempting to recompile DRI on my newly configured Mandrake 9.0 system.. but it cuts out with an error on line 14282 or so of my log file.. with an error in a gcc line.. it's the only place it tries to use the Xpm library "-lXpm" and for some reason, it says it can't find it. Any ideas? Thanks.. -- John S. Chalice a.k.a. crysaliq
[Dri-devel] Do Matrox/ATI help DRI devs?
I asked about this on dri-users but I think it may be better placed here. I was just browsing around the developer relations areas of the ATI and Matrox sites, and I'm getting the impression that they don't really care about having open source DRI drivers available for their products. Are these companies friendly towards XFree86/DRI devs? That is to say, do they provide timely, accurate, and complete docs? Are they helpful? I'm interested in supporting the most DRI-friendly manufacturers by buying their products, but I also think this information would be interesting to developers considering working on the DRI. Thank you. ---John --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] Re: [Dri-users] problems with radeon-20021001,2 and 4 and RadeonMobility M6
0xd000 - 0xd3ff (0x400) MX[B] [11] -1 0xe000 - 0xefff (0x1000) MX[B] [12] -1 0xd010 - 0xd010 (0x1) MX[B](B) [13] -1 0xd800 - 0xdfff (0x800) MX[B](B) [14] 0 0x000a - 0x000a (0x1) MS[B] [15] 0 0x000b - 0x000b7fff (0x8000) MS[B] [16] 0 0x000b8000 - 0x000b (0x8000) MS[B] [17] 0 0x3000 - 0x30ff (0x100) IX[B] [18] -1 0x - 0x (0x1) IX[B] [19] -1 0x - 0x00ff (0x100) IX[B] [20] -1 0x4000 - 0x403f (0x40) IX[B] [21] -1 0x2000 - 0x207f (0x80) IX[B] [22] -1 0x2400 - 0x24ff (0x100) IX[B] [23] -1 0x18c0 - 0x18ff (0x40) IX[B] [24] -1 0x1c00 - 0x1cff (0x100) IX[B] [25] -1 0x1880 - 0x189f (0x20) IX[B] [26] -1 0x1860 - 0x186f (0x10) IX[B] [27] -1 0x0374 - 0x0374 (0x1) IX[B] [28] -1 0x0170 - 0x0177 (0x8) IX[B] [29] -1 0x03f4 - 0x03f4 (0x1) IX[B] [30] -1 0x01f0 - 0x01f7 (0x8) IX[B] [31] -1 0x1840 - 0x185f (0x20) IX[B] [32] -1 0x1820 - 0x183f (0x20) IX[B] [33] -1 0x1800 - 0x181f (0x20) IX[B] [34] -1 0x3000 - 0x30ff (0x100) IX[B](B) [35] 0 0x03b0 - 0x03bb (0xc) IS[B] [36] 0 0x03c0 - 0x03df (0x20) IS[B] (==) RADEON(0): Write-combining range (0xd800,0x100) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmOpenDevice: minor is 0 drmOpenDevice: node name is /dev/dri/card0 drmOpenDevice: open result is 6, (OK) drmGetBusid returned '' (II) RADEON(0): [drm] created radeon driver at busid PCI:1:0:0 (II) RADEON(0): [drm] added 8192 byte SAREA at 0xe09ab000 (II) RADEON(0): [drm] mapped SAREA 0xe09ab000 to 0x40018000 (II) RADEON(0): [drm] framebuffer handle = 0xd800 (II) RADEON(0): [drm] added 1 reserved context for kernel (II) RADEON(0): [agp] Mode 0x1f000201 [AGP 0x8086/0x3575; Card 0x1002/0x4c59] (II) RADEON(0): [agp] 8192 kB allocated with handle 0xe09ae000 (II) RADEON(0): [agp] ring handle = 0xe000 (II) RADEON(0): [agp] Ring mapped at 0x4125f000 (II) RADEON(0): [agp] ring read ptr handle = 0xe0101000 (II) RADEON(0): [agp] Ring read ptr mapped at 0x4001a000 (II) RADEON(0): [agp] vertex/indirect buffers handle = 0xe0102000 (II) RADEON(0): [agp] Vertex/indirect buffers mapped at 0x4136 (II) RADEON(0): [agp] AGP texture map handle = 0xe0302000 (II) RADEON(0): [agp] AGP Texture map mapped at 0x4156 (II) RADEON(0): [drm] register handle = 0xd010 (II) RADEON(0): [dri] Visual configs initialized (II) RADEON(0): CP in BM mode (II) RADEON(0): Using 8 MB AGP aperture (II) RADEON(0): Using 1 MB for the ring buffer (II) RADEON(0): Using 2 MB for vertex/indirect buffers (II) RADEON(0): Using 5 MB for AGP textures (II) RADEON(0): Memory manager initialized to (0,0) (1408,5957) (II) RADEON(0): Largest offscreen area available: 1408 x 4907 (II) RADEON(0): Will use back buffer at offset 0x5bc000 (II) RADEON(0): Will use depth buffer at offset 0x88e000 (II) RADEON(0): Will use 4736 kb for textures at offset 0xb6 (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled Fatal server error: Caught signal 11. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] Jose Fonseca On Fri, Oct 04, 2002 at 04:08:47PM -0400, John Jasen wrote: On Fri, 4 Oct 2002, José Fonseca wrote: Was any error message in /var/log/XFree86.0.log or in /var/log/message, or `dmesg`? /var/log/XFree86.0.log (==) RADEON(0): Backing store disabled (==) RADEON(0): Silken mouse enabled Fatal server error: Caught signal 11. Server aborting When reporting a problem related to a server crash, please send the full server output, not just the last messages. This can be found in the log file /var/log/XFree86.0.log. Please report problems to [EMAIL PROTECTED] ... very strange. dmesg: Linux agpgart interface v0.99 (c) Jeff Hartmann agpgart: Maximum main memory to use for agp memory: 439M agpgart: Detected Intel i830M chipset agpgart: AGP aperture is 256M @ 0xe000 [drm] AGP 0.99 on Unknown @ 0xe000 256MB [drm] Initialized radeon 1.6.0 20020828 on minor 0 -- -- John E. Jasen ([EMAIL PROTECTED]) -- User Error #2361: Please insert coffee and try again. -- -- John E. Jasen ([EMAIL PROTECTED]) -- User Error #2361: Please insert coffee and try again. --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf
[Dri-devel] Re: S3 VIRGE DRI in CVS now
On Tue, 2002-06-25 at 09:34, [EMAIL PROTECTED] wrote: Message: 11 From: max [EMAIL PROTECTED] To: Keith Whitwell [EMAIL PROTECTED] Date: Tue, 25 Jun 2002 12:22:01 +0200 Cc: [EMAIL PROTECTED] Subject: [Dri-devel] S3 VIRGE DRI in CVS now On Thursday 20 June 2002 13:11, you wrote: I think you should upload it... Other people may be able to help finish it or track down bugs... Ok. Just uploaded the latest and greatest version of my driver in CVS. The branch is named: s3virge-0-0-1-branch 1) Could someone have a try and let me know if everything compile just fine? 2) Could the web page mantainer add virge to supported chipsets (so that interested people will know about it)? Good luck, vale, -max lingua Is the Virge MX+ supported? This is the one that was commonly found in notebooks, as that is what I will be testing it out on. -- John Tobin [EMAIL PROTECTED]; AOL IM: ogre7929 http://ogre.rocky-road.net http://ogre.rocky-road.net/cdr.shtml --- Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: [Dri-devel] tuxkart, and bug reports..
There aren't a great number of dri_users questions anyway and a good=20 percentage of them probably should be on dri_devel as it stands now (they= 're=20 proper bugs, or whatever). So, I guess I still think the second list: - doesn't serve it's intended audience well - doesn't save us any time (except by making it easier to ignore users). But, I don't feel anywhere near as strongly about this as about the=20 sourceforge bug tracker. I can live with either outcome. One thing that you might want to explore is closing off dri-devel from the average user and trying to shift a majority of the traffic to dri-users and keep dri-devel strictly on the development side of dri instead of having it double as a help mailing list. Just my $.02. -- John Tobin [EMAIL PROTECTED]; AOL IM: ogre7929 http://ogre.rocky-road.net http://ogre.rocky-road.net/cdr.shtml ___ Sponsored by: ThinkGeek at http://www.ThinkGeek.com/ ___ Dri-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/dri-devel
[Dri-devel] i think i have a functioning FreeBSD SiS 630e/300 agp device. howdo i test it?
hi;
i have reason to suspect that i have successfully hooked up agp in my
FreeBSD kernel.
Why? because agp0 is now attached to a pci id that matches the one that
http://www.yourvote.com/pci/vendors.txt asserts is the agp port on the
SiS630
agp0@pci1:0:0: class=0x03 card=0x80351043 chip=0x63001039 rev=0x21
hdr=0x00
('chip' is the way the pci id called out in FreeBSD land)
this was not the case when i started out on this adventure, so i've hit my
first incremental milestone
ok dri guys, what's the most trivial piece of code that will tell me if
this is actually functional and acting agp-ish?
note that the answer to this question is an important bit of
fundamental dri-porting wisdom!
tnx!
johnu
--
John L. Utz III
[EMAIL PROTECTED]
Idiocy is the Impulse Function in the Convolution of Life
___
Dri-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/dri-devel
