[Bug 14575] using a hdmi connector frame buffer resolution maxes out at 1920x1200
http://bugzilla.kernel.org/show_bug.cgi?id=14575 --- Comment #1 from Wil Reichert 2009-11-10 05:55:14 --- Created an attachment (id=23721) --> (http://bugzilla.kernel.org/attachment.cgi?id=23721) dmesg with dvi connector attached -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14575] New: using a hdmi connector frame buffer resolution maxes out at 1920x1200
http://bugzilla.kernel.org/show_bug.cgi?id=14575 Summary: using a hdmi connector frame buffer resolution maxes out at 1920x1200 Product: Drivers Version: 2.5 Kernel Version: 2.6.32-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: wil.reich...@gmail.com Regression: No Created an attachment (id=23720) --> (http://bugzilla.kernel.org/attachment.cgi?id=23720) dmesg with hdmi connected Using a Radeon 4890 / Dell 3008WFP, a day or 2 old git kernel & kms built into the kernel. Using a DVI connector the kernel boots into the native panel resolution of 2560x1600, when using the hdmi connection it defaults to 1920x1200. Even after booting into X I was unable to set the native resolution. dmesg attached. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14574] New: using a displayport connector results in stack in dmesg and blank screen
http://bugzilla.kernel.org/show_bug.cgi?id=14574 Summary: using a displayport connector results in stack in dmesg and blank screen Product: Drivers Version: 2.5 Kernel Version: 2.6.32-rc6 Platform: All OS/Version: Linux Tree: Mainline Status: NEW Severity: normal Priority: P1 Component: Video(DRI - non Intel) AssignedTo: drivers_video-...@kernel-bugs.osdl.org ReportedBy: wil.reich...@gmail.com Regression: No Created an attachment (id=23719) --> (http://bugzilla.kernel.org/attachment.cgi?id=23719) dmesg output Using a Radeon 4890 / Dell 3008WFP, a day or 2 old git kernel & kms built into the kernel. Works fine with DVI. stack trace: [0.577043] WARNING: at drivers/gpu/drm/drm_crtc_helper.c:1031 drm_helper_initial_config+0x41/0x5c() [0.577048] Hardware name: OEM [0.577050] No connectors reported connected with modes [0.577053] Modules linked in: [0.577057] Pid: 1, comm: swapper Not tainted 2.6.32-rc6-linus #6 [0.577060] Call Trace: [0.577066] [] warn_slowpath_common+0x77/0x8f [0.577070] [] warn_slowpath_fmt+0x3c/0x3e [0.577074] [] drm_helper_initial_config+0x41/0x5c [0.577080] [] radeon_modeset_init+0x521/0x532 [0.577085] [] radeon_driver_load_kms+0xd9/0xe9 [0.577089] [] drm_get_dev+0x356/0x462 [0.577094] [] radeon_pci_probe+0x10/0x12 [0.577099] [] local_pci_probe+0x12/0x16 [0.577103] [] pci_device_probe+0x60/0x8f [0.577107] [] ? driver_sysfs_add+0x47/0x6c [0.577112] [] driver_probe_device+0xa6/0x137 [0.577116] [] __driver_attach+0x58/0x7c [0.577120] [] ? __driver_attach+0x0/0x7c [0.577124] [] bus_for_each_dev+0x4e/0x83 [0.577128] [] driver_attach+0x19/0x1b [0.577133] [] bus_add_driver+0xb8/0x204 [0.577137] [] driver_register+0x98/0x109 [0.577141] [] __pci_register_driver+0x53/0xc3 [0.577146] [] ? printk+0x3c/0x44 [0.577151] [] ? radeon_init+0x0/0xc1 [0.577155] [] drm_init+0x6b/0xd1 [0.577159] [] ? radeon_init+0x0/0xc1 [0.577163] [] radeon_init+0xbf/0xc1 [0.577168] [] do_one_initcall+0x59/0x149 [0.577172] [] kernel_init+0x14b/0x1a1 [0.577177] [] child_rip+0xa/0x20 [0.577181] [] ? kernel_init+0x0/0x1a1 [0.577185] [] ? child_rip+0x0/0x20 [0.577191] ---[ end trace 182f58d67963377a ]--- full dmesg attached -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24124] Massive flickering with KMS enabled at 1600x1...@85 and 1280x1...@85
http://bugs.freedesktop.org/show_bug.cgi?id=24124 --- Comment #5 from Adam K Kirchhoff 2009-11-09 17:03:44 PST --- FYI, this is still an issue as of 2.6.31.5, and also happens with an x850. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 23901] radeon KMS sends no input signal to LCD (regression in 2.6.31)
http://bugs.freedesktop.org/show_bug.cgi?id=23901 Adam K Kirchhoff changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #16 from Adam K Kirchhoff 2009-11-09 17:01:03 PST --- Updated to 2.6.31.5 today and it works great again. Thanks all. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[PATCH] drm/radeon/r600: CS parser updates
>From 33043f0c15730f1bda1abd18179ebbfb603c0105 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 9 Nov 2009 16:41:21 -0500
Subject: [PATCH] drm/radeon/r600: CS parser updates
Add some additional regs that require relocs.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cs.c | 18 ++
drivers/gpu/drm/radeon/r600d.h | 10 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 17e4219..0d82076 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -466,6 +466,23 @@ static int r600_packet3_check(struct radeon_cs_parser *p,
for (i = 0; i < pkt->count; i++) {
reg = start_reg + (4 * i);
switch (reg) {
+ case SQ_ESGS_RING_BASE:
+ case SQ_GSVS_RING_BASE:
+ case SQ_ESTMP_RING_BASE:
+ case SQ_GSTMP_RING_BASE:
+ case SQ_VSTMP_RING_BASE:
+ case SQ_PSTMP_RING_BASE:
+ case SQ_FBUF_RING_BASE:
+ case SQ_REDUC_RING_BASE:
+ case SX_MEMORY_EXPORT_BASE:
+ r = r600_cs_packet_next_reloc(p, &reloc);
+ if (r) {
+ DRM_ERROR("bad SET_CONFIG_REG "
+ "0x%04X\n", reg);
+ return -EINVAL;
+ }
+ ib[idx+1+i] += (u32)((reloc->lobj.gpu_offset >>
8) & 0x);
+ break;
case CP_COHER_BASE:
/* use PACKET3_SURFACE_SYNC */
return -EINVAL;
@@ -487,6 +504,7 @@ static int r600_packet3_check(struct radeon_cs_parser *p,
reg = start_reg + (4 * i);
switch (reg) {
case DB_DEPTH_BASE:
+ case DB_HTILE_DATA_BASE:
case CB_COLOR0_BASE:
case CB_COLOR1_BASE:
case CB_COLOR2_BASE:
diff --git a/drivers/gpu/drm/radeon/r600d.h b/drivers/gpu/drm/radeon/r600d.h
index cf238bf..b99f45d 100644
--- a/drivers/gpu/drm/radeon/r600d.h
+++ b/drivers/gpu/drm/radeon/r600d.h
@@ -118,6 +118,7 @@
#defineDB_DEBUG0x9830
#definePREZ_MUST_WAIT_FOR_POSTZ_DONE (1 <<
31)
#defineDB_DEPTH_BASE 0x2800C
+#defineDB_HTILE_DATA_BASE 0x28014
#defineDB_WATERMARKS 0x9838
#defineDEPTH_FREE(x) ((x) <<
0)
#defineDEPTH_FLUSH(x) ((x) <<
5)
@@ -170,6 +171,14 @@
#define SQ_STACK_RESOURCE_MGMT_2 0x8c14
# define NUM_GS_STACK_ENTRIES(x)((x) << 0)
# define NUM_ES_STACK_ENTRIES(x)((x) << 16)
+#define SQ_ESGS_RING_BASE 0x8c40
+#define SQ_GSVS_RING_BASE 0x8c48
+#define SQ_ESTMP_RING_BASE 0x8c50
+#define SQ_GSTMP_RING_BASE 0x8c58
+#define SQ_VSTMP_RING_BASE 0x8c60
+#define SQ_PSTMP_RING_BASE 0x8c68
+#define SQ_FBUF_RING_BASE 0x8c70
+#define SQ_REDUC_RING_BASE 0x8c78
#define GRBM_CNTL 0x8000
# define GRBM_READ_TIMEOUT(x) ((x) << 0)
@@ -355,6 +364,7 @@
#defineSX_MISC 0x28350
+#defineSX_MEMORY_EXPORT_BASE 0x9010
#defineSX_DEBUG_1 0x9054
#defineSMX_EVENT_RELEASE (1 << 0)
#defineENABLE_NEW_SMX_ADDRESS (1 <<
16)
--
1.5.6.3
From 33043f0c15730f1bda1abd18179ebbfb603c0105 Mon Sep 17 00:00:00 2001
From: Alex Deucher
Date: Mon, 9 Nov 2009 16:41:21 -0500
Subject: [PATCH] drm/radeon/r600: CS parser updates
Add some additional regs that require relocs.
Signed-off-by: Alex Deucher
---
drivers/gpu/drm/radeon/r600_cs.c | 18 ++
drivers/gpu/drm/radeon/r600d.h | 10 ++
2 files changed, 28 insertions(+), 0 deletions(-)
diff --git a/drivers/gpu/drm/radeon/r600_cs.c b/drivers/gpu/drm/radeon/r600_cs.c
index 17e4219..0d82076 100644
--- a/drivers/gpu/drm/radeon/r600_cs.c
+++ b/drivers/gpu/drm/radeon/r600_cs.c
@@ -466,6 +466,23 @@ static int r600_packet3_c
Re: RFC: libdrm repo
On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: > On Sun, Nov 8, 2009 at 23:33, Eric Anholt wrote: > > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: > >> On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote: > >> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: > >> >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote: > >> >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: > >> >> >> 2009/11/6 Kristian Høgsberg : > >> >> >> > Hi, > >> >> >> > > >> >> >> > This has come up a few time and it's something I think makes a lot > >> >> >> > of > >> >> >> > sense. Since all driver development (afaik) now happens in linux > >> >> >> > kernel tree, it makes sense to drop the driver bits from the > >> >> >> > drm.git > >> >> >> > repo. I've put up a repo under > >> >> >> > >> >> >> Actually, I don't think a separate libdrm makes much sense. We don't > >> >> >> want to add yet another outside component and ask ourselves questions > >> >> >> like "how do I maintain compatibility" (which, incidentally, have > >> >> >> already been raised). > >> >> >> > >> >> >> Given this, IMO libdrm live somewhere alongside the kernel. > >> >> >> Furthermore when pulling outside stuff we driver devs can do a > >> >> >> kernel+DRM+libdrm pull at the same time which is a win. > >> >> >> > >> >> >> And also users don't have to wonder where/how to pick the right > >> >> >> libdrm. You get the right one with your kernel. > >> >> > > >> >> > This is a bad idea. libdrm with the kernel means that users and > >> >> > distributions can't trivially update libdrm. So all of the users of > >> >> > libdrm end up being an ifdeffed nightmare of both compile-time and > >> >> > runtime detection. > >> >> > >> >> Why do you need to update libdrm separately from the kernel? Is there > >> >> so much that's in libdrm that does not also require a new drm? Newer > >> >> libdrm functionality usually also requires a new drm... > >> >> > >> >> > Our code used to be that way before we fixed libdrm > >> >> > to be "only use kernel code that's going upstream, and never regress > >> >> > it". Things have improved in the last few years for upstream drivers, > >> >> > and I don't want to regress them with moving libdrm to the kernel. > >> >> > >> >> Again I don't see what kind of changes you have in mind. You just say > >> >> "regress". > >> > > >> > I need to enable a new feature in the driver by relying on a new kernel > >> > interface. This happens at least once per kernel version (every ~3 > >> > months), and we're currently retaining backwards compatibility to > >> > kernels a year old. > >> > > >> > Today, this ends up easy. In my driver components (Mesa and > >> > xf86-video-intel) I pkg-config version assert on on the new version of > >> > libdrm with the new headers. I do a runtime detection of the new > >> > feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl > >> > interface as appropriate. An example of this would be > >> > kernel_exec_fencing in 2.6.29, which impacts many files in the driver. > >> > > >> > If userland doesn't get to assert new libdrm/interface header presence, > >> > then in addition to the runtime detection, I have to ifdef all use of > >> > the new interfaces. Now, if we screw up the ifdefs (which used to > >> > happen regularly), people's builds don't work because they have old > >> > kernels. > >> > > >> > People obviously thought that situation sucked in the past, as we saw in > >> > both the intel and radeon drivers where pieces of the drm headers were > >> > just spammed right into the files using them, under ifdefs. This did > >> > result in actual divergence from the kernel definitions and real bugs, > >> > unlike today's situation where diff can confirm for me that we're using > >> > exactly the same interfaces between userland and kernel. > >> > > >> > >> Okay, well in any case nothing in what you mentioned prevents the > >> libdrm from living with the kernel. We could keep the compat stuff > >> here, and we still have the advantages I mentioned. > >> > >> So is there any other reason for not putting it with the kernel? > > > > So you're saying that people building their distribution on 2.6.29 would > > have to pull down linux-2.6 from master to build and install libdrm? > > > > People with old kernels can pick an old libdrm from some place else in > the meantime.People with 2.6.32 don't have to grab anything more as > libdrm came with their kernel already. I don't care about the transition. I care about the long term. Replace 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user get his libdrm at that time? And how do I get releases of libdrm out outside of kernel releases? We're doing libdrms at least twice a kernel cycle, because we've got stable fixes to push out/new interfaces to start relying on faster than every 3 months. This is all seeming like a huge pain to avoid cp. -- Eric Anholt e...@anholt.net
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 17:42, Eric Anholt wrote: > On Sun, 2009-11-08 at 23:40 +0100, Stephane Marchesin wrote: >> On Sun, Nov 8, 2009 at 23:33, Eric Anholt wrote: >> > On Sun, 2009-11-08 at 21:19 +0100, Stephane Marchesin wrote: >> >> On Sun, Nov 8, 2009 at 20:02, Eric Anholt wrote: >> >> > On Sun, 2009-11-08 at 19:47 +0100, Stephane Marchesin wrote: >> >> >> On Sun, Nov 8, 2009 at 19:18, Eric Anholt wrote: >> >> >> > On Sun, 2009-11-08 at 13:20 +0100, Stephane Marchesin wrote: >> >> >> >> 2009/11/6 Kristian Høgsberg : >> >> >> >> > Hi, >> >> >> >> > >> >> >> >> > This has come up a few time and it's something I think makes a >> >> >> >> > lot of >> >> >> >> > sense. Since all driver development (afaik) now happens in linux >> >> >> >> > kernel tree, it makes sense to drop the driver bits from the >> >> >> >> > drm.git >> >> >> >> > repo. I've put up a repo under >> >> >> >> >> >> >> >> Actually, I don't think a separate libdrm makes much sense. We don't >> >> >> >> want to add yet another outside component and ask ourselves >> >> >> >> questions >> >> >> >> like "how do I maintain compatibility" (which, incidentally, have >> >> >> >> already been raised). >> >> >> >> >> >> >> >> Given this, IMO libdrm live somewhere alongside the kernel. >> >> >> >> Furthermore when pulling outside stuff we driver devs can do a >> >> >> >> kernel+DRM+libdrm pull at the same time which is a win. >> >> >> >> >> >> >> >> And also users don't have to wonder where/how to pick the right >> >> >> >> libdrm. You get the right one with your kernel. >> >> >> > >> >> >> > This is a bad idea. libdrm with the kernel means that users and >> >> >> > distributions can't trivially update libdrm. So all of the users of >> >> >> > libdrm end up being an ifdeffed nightmare of both compile-time and >> >> >> > runtime detection. >> >> >> >> >> >> Why do you need to update libdrm separately from the kernel? Is there >> >> >> so much that's in libdrm that does not also require a new drm? Newer >> >> >> libdrm functionality usually also requires a new drm... >> >> >> >> >> >> > Our code used to be that way before we fixed libdrm >> >> >> > to be "only use kernel code that's going upstream, and never regress >> >> >> > it". Things have improved in the last few years for upstream >> >> >> > drivers, >> >> >> > and I don't want to regress them with moving libdrm to the kernel. >> >> >> >> >> >> Again I don't see what kind of changes you have in mind. You just say >> >> >> "regress". >> >> > >> >> > I need to enable a new feature in the driver by relying on a new kernel >> >> > interface. This happens at least once per kernel version (every ~3 >> >> > months), and we're currently retaining backwards compatibility to >> >> > kernels a year old. >> >> > >> >> > Today, this ends up easy. In my driver components (Mesa and >> >> > xf86-video-intel) I pkg-config version assert on on the new version of >> >> > libdrm with the new headers. I do a runtime detection of the new >> >> > feature with a GET_PARAM ioctl. Then I use the new libdrm or ioctl >> >> > interface as appropriate. An example of this would be >> >> > kernel_exec_fencing in 2.6.29, which impacts many files in the driver. >> >> > >> >> > If userland doesn't get to assert new libdrm/interface header presence, >> >> > then in addition to the runtime detection, I have to ifdef all use of >> >> > the new interfaces. Now, if we screw up the ifdefs (which used to >> >> > happen regularly), people's builds don't work because they have old >> >> > kernels. >> >> > >> >> > People obviously thought that situation sucked in the past, as we saw in >> >> > both the intel and radeon drivers where pieces of the drm headers were >> >> > just spammed right into the files using them, under ifdefs. This did >> >> > result in actual divergence from the kernel definitions and real bugs, >> >> > unlike today's situation where diff can confirm for me that we're using >> >> > exactly the same interfaces between userland and kernel. >> >> > >> >> >> >> Okay, well in any case nothing in what you mentioned prevents the >> >> libdrm from living with the kernel. We could keep the compat stuff >> >> here, and we still have the advantages I mentioned. >> >> >> >> So is there any other reason for not putting it with the kernel? >> > >> > So you're saying that people building their distribution on 2.6.29 would >> > have to pull down linux-2.6 from master to build and install libdrm? >> > >> >> People with old kernels can pick an old libdrm from some place else in >> the meantime.People with 2.6.32 don't have to grab anything more as >> libdrm came with their kernel already. > > I don't care about the transition. I care about the long term. Replace > 2.6.32 and 2.6.29 with 2.6.43 and 2.6.40. Where does the 2.6.40 user > get his libdrm at that time? Well, once libdrm is with the kernel, you get libdrm ... with the kernel. What's unclear in what I explained? > > And how do I get releases of libdrm out o
Re: RFC: libdrm repo
Stephane Marchesin wrote: > Okay, well in any case nothing in what you mentioned prevents the > libdrm from living with the kernel. We could keep the compat stuff > here, and we still have the advantages I mentioned. > > So is there any other reason for not putting it with the kernel? I know BSD & OpenSolaris really don't matter much, but there are still some of us using libdrm on kernels other than Linux. -- -Alan Coopersmith- alan.coopersm...@sun.com Sun Microsystems, Inc. - X Window System Engineering -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 --- Comment #8 from Konstantin 2009-11-09 08:24:30 PST --- (In reply to comment #7) > Created an attachment (id=31066) --> (http://bugs.freedesktop.org/attachment.cgi?id=31066) [details] > Really serialize the linking after the subdirs > > Sorry, I can't reproduce this, so it's hard to know if the fix is right. Can > you try this patch? It should definitely synchronize things. > This patch seems to have helped, thanks a lot :) I recompiled at least 7 times and never ran into the problem again, so I'm quite certain (it failed >50% before). (I left this as NEW to wait for inclusion in master). -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 24950] Build of mesa-git fails sometimes (no rule to make target compiler/libr300compiler.a)
http://bugs.freedesktop.org/show_bug.cgi?id=24950 Dan Nicholson changed: What|Removed |Added Attachment #31050|0 |1 is obsolete|| --- Comment #7 from Dan Nicholson 2009-11-09 05:58:21 PST --- Created an attachment (id=31066) --> (http://bugs.freedesktop.org/attachment.cgi?id=31066) Really serialize the linking after the subdirs Sorry, I can't reproduce this, so it's hard to know if the fix is right. Can you try this patch? It should definitely synchronize things. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
On Mon, Nov 9, 2009 at 11:51, Rémi Cardona wrote: > Le 09/11/2009 00:14, Robert Noland a écrit : >> There are any number of changes that may occur in libdrm that do not >> impact the KBI and users should be able to get those features/bug fixes >> without needing a new kernel. > > Absolutely. In fact, one of the biggest Intel performance wins lately > was in a libdrm change [1] that had absolutely nothing to do with the > kernel per se. Not having to force a new kernel down our users throat > was very welcome. > But then it sees little testing. If you ship together with the kernel, you get the rc test phases and all... Stephane -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: RFC: libdrm repo
Le 09/11/2009 00:14, Robert Noland a écrit : > There are any number of changes that may occur in libdrm that do not > impact the KBI and users should be able to get those features/bug fixes > without needing a new kernel. Absolutely. In fact, one of the biggest Intel performance wins lately was in a libdrm change [1] that had absolutely nothing to do with the kernel per se. Not having to force a new kernel down our users throat was very welcome. Cheers, Rémi [1] http://cgit.freedesktop.org/mesa/drm/commit/?id=3f3c5be6f908272199ccf53f108b1124bfe0a00e -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
