[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #18 from Christophe Saout 2011-03-29 08:26:51 PDT --- Oh, well, that patch only concerns rs600, right? So no point in that... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #19 from Alex Deucher 2011-03-29 08:30:16 PDT --- (In reply to comment #18) > Oh, well, that patch only concerns rs600, right? So no point in that... That rs600 code is shared by r5xx-r7xx (same regs on all asics in that range), so it applies to your card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 15112] Radeon KMS on RV250 gets wrong refresh rate.
https://bugzilla.kernel.org/show_bug.cgi?id=15112 Joe Kowalski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE --- Comment #13 from Joe Kowalski 2011-03-29 16:00:40 --- Finally got around to upgrading that machine to 2.6.38, and KMS now sets a proper mode. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[RFC] drm platform multi-device support
From: Rob Clark
Include the minor device id in the bus-id to give userspace a way to open
the correct "cardN" when there are multiple device instances.
---
It may seem a bit strange to have multiple platform device instances, but
we have a use-case for this. And this relatively simple patch does the
trick.
drivers/gpu/drm/drm_ioctl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 47db4df..075024b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -165,14 +165,15 @@ static int drm_set_busid(struct drm_device *dev, struct
drm_file *file_priv)
drm_unset_busid(dev, master);
if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
- master->unique_len = 10 + strlen(dev->platformdev->name);
+ master->unique_len = 13 + strlen(dev->platformdev->name);
+ master->unique_size = master->unique_len;
master->unique = kmalloc(master->unique_len + 1, GFP_KERNEL);
if (master->unique == NULL)
return -ENOMEM;
len = snprintf(master->unique, master->unique_len,
- "platform:%s", dev->platformdev->name);
+ "platform:%s:%02d", dev->platformdev->name,
dev->primary->index);
if (len > master->unique_len) {
DRM_ERROR("Unique buffer overflowed\n");
--
1.7.1
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
gallium softpipe driver build instructions.
Hi All, Am using Mesa 7.8.2. Can anyone please send out the instructions to building a gallium based softpipe driver? thanks K ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse: > 2011/3/29 r6144 : > > 在 2011-03-29二的 10:22 -0400，Jerome Glisse写道： > > > >> Killer solution would be to have no mapping and a decent > >> upload/download ioctl that can take userpage. > > > > Doesn't this sound like GEM's read/write interface implemented by e.g. > > the i915 driver? But if I understand correctly, a mmap-like interface > > should still be necessary if we want to implement e.g. glMapBuffer() > > without extra copying. > > > > r6144 > > > > > glMapBuffer should not be use, it's really not a good way to do stuff. > Anyway the extra copy might be unavoidable given that sometime the > front/back might either be in unmappable vram or either have memory > layout that is not the one specify at buffer creation (this is very > common when using tiling for instance). So even considering MapBuffer > or a like function i believe it's a lot better to not allow buffer > mapping in userspace but provide upload/download hooks that can use > userpage to avoid as much as possible extra copy. > > Cheers, > Jerome > Wouldn't this give us a performance penalty for short lived resources like vbo's which are located in GART memory? Mmap allows us to write directly to this drm controlled portion of sysram. With a copy based implementation we would have to allocate the buffer in sysram just to copy it over to another portion of sysram which seems a little insane to me, but I'm not an expert here. -- Lucas ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 2:01 PM, Lucas Stach wrote: > Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse: >> 2011/3/29 r6144 : >> > 在 2011-03-29二的 10:22 -0400，Jerome Glisse写道： >> > >> >> Killer solution would be to have no mapping and a decent >> >> upload/download ioctl that can take userpage. >> > >> > Doesn't this sound like GEM's read/write interface implemented by e.g. >> > the i915 driver? But if I understand correctly, a mmap-like interface >> > should still be necessary if we want to implement e.g. glMapBuffer() >> > without extra copying. >> > >> > r6144 >> > >> > >> glMapBuffer should not be use, it's really not a good way to do stuff. >> Anyway the extra copy might be unavoidable given that sometime the >> front/back might either be in unmappable vram or either have memory >> layout that is not the one specify at buffer creation (this is very >> common when using tiling for instance). So even considering MapBuffer >> or a like function i believe it's a lot better to not allow buffer >> mapping in userspace but provide upload/download hooks that can use >> userpage to avoid as much as possible extra copy. >> >> Cheers, >> Jerome >> > > Wouldn't this give us a performance penalty for short lived resources > like vbo's which are located in GART memory? Mmap allows us to write > directly to this drm controlled portion of sysram. With a copy based > implementation we would have to allocate the buffer in sysram just to > copy it over to another portion of sysram which seems a little insane to > me, but I'm not an expert here. > > -- Lucas Short lived & small bo would definitly doesn't work well for this kind of API, it would all be a function of the ioctl cost. But i am not sure the drawback would be that big, intel tested with pread/pwrite and gived up don't remember why. For the vbo case you describe the scheme i was thinking would be : allocate bo and on buffer data call upload to the allocated bo using the bind user page feature that would mean zero extra copy operation. For the fire forget case of vbo, likely somekind of transient buffer would be more appropriate. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: > Short lived & small bo would definitly doesn't work well for this kind > of API, it would all be a function of the ioctl cost. But i am not > sure the drawback would be that big, intel tested with pread/pwrite > and gived up don't remember why. For the vbo case you describe the > scheme i was thinking would be : allocate bo and on buffer data call > upload to the allocated bo using the bind user page feature that would > mean zero extra copy operation. For the fire forget case of vbo, > likely somekind of transient buffer would be more appropriate. Just to clarify: Uploads to linear buffers are all done with pwrite (due to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how much faster that is: Switching vbo's from mmpa to pwrite has given a few percent more fps in openarena in i915g! As long as the chunk you're gonna write fits into L1 cache, it's probably a net win. -Daniel -- Daniel Vetter Mail: dan...@ffwll.ch Mobile: +41 (0)79 365 57 48 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter wrote: > On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: >> Short lived & small bo would definitly doesn't work well for this kind >> of API, it would all be a function of the ioctl cost. But i am not >> sure the drawback would be that big, intel tested with pread/pwrite >> and gived up don't remember why. For the vbo case you describe the >> scheme i was thinking would be : allocate bo and on buffer data call >> upload to the allocated bo using the bind user page feature that would >> mean zero extra copy operation. For the fire forget case of vbo, >> likely somekind of transient buffer would be more appropriate. > > Just to clarify: Uploads to linear buffers are all done with pwrite (due > to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how > much faster that is: Switching vbo's from mmpa to pwrite has given a few > percent more fps in openarena in i915g! As long as the chunk you're gonna > write fits into L1 cache, it's probably a net win. > -Daniel What i had in mind was something little bit more advance that pwrite, somethings that would take width,height,pitch of userpage and would be able to perform proper blit. But yes pwrite in intel is kind of limited. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 28622] radeon video lockup
https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #8 from Florian Mickler 2011-03-29 21:13:02 --- Is this still a problem on 2.6.38.y / 2.6.39-rc* ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar -- ___ Dri-devel mailing list dri-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Wed, Mar 30, 2011 at 7:04 AM, Jerome Glisse wrote: > On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter wrote: >> On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: >>> Short lived & small bo would definitly doesn't work well for this kind >>> of API, it would all be a function of the ioctl cost. But i am not >>> sure the drawback would be that big, intel tested with pread/pwrite >>> and gived up don't remember why. For the vbo case you describe the >>> scheme i was thinking would be : allocate bo and on buffer data call >>> upload to the allocated bo using the bind user page feature that would >>> mean zero extra copy operation. For the fire forget case of vbo, >>> likely somekind of transient buffer would be more appropriate. >> >> Just to clarify: Uploads to linear buffers are all done with pwrite (due >> to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how >> much faster that is: Switching vbo's from mmpa to pwrite has given a few >> percent more fps in openarena in i915g! As long as the chunk you're gonna >> write fits into L1 cache, it's probably a net win. >> -Daniel > > What i had in mind was something little bit more advance that pwrite, > somethings that would take width,height,pitch of userpage and would be > able to perform proper blit. But yes pwrite in intel is kind of > limited. TTM has support for userpage binding we just don't use it. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c
https://bugs.freedesktop.org/show_bug.cgi?id=35483 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marek Olšák 2011-03-29 15:53:57 PDT --- Fixed by Henri's commit 5d7c27f5ec2f30c264dc2d53c4980970b3a13ee5. I am cherry-picking it to the 7.9 and 7.10 branches. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34217] [r300g] Unigine Sanctuary: no fog visible
https://bugs.freedesktop.org/show_bug.cgi?id=34217 Marek Olšák changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #1 from Marek Olšák 2011-03-29 16:52:51 PDT --- The fog is rendered correctly with the floating2 branch, and Unigine Sanctuary does use floating-point textures. This is what is printed during loading: Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_RGBA16F) The game is clearly using float textures and doesn't check for the extension. Closing as NOT-OUR-BUG. Thanks for the info anyway. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 34206] [r300g] Unigine Sanctuary: glow around fires is distorted and displaced
https://bugs.freedesktop.org/show_bug.cgi?id=34206 --- Comment #7 from Marek Olšák 2011-03-29 16:59:52 PDT --- I think the glow is broken because the WPOS input is unassigned. Glow is a screen-space effect and as such must either use (or emulate) gl_FragCoord. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)
https://bugs.freedesktop.org/show_bug.cgi?id=33790 --- Comment #2 from Marek Olšák 2011-03-29 17:04:28 PDT --- Can you set this environment variable: RADEON_THREAD=0 and try again? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)
https://bugs.freedesktop.org/show_bug.cgi?id=33790 --- Comment #3 from Marek Olšák 2011-03-29 17:08:49 PDT --- (In reply to comment #2) > Can you set this environment variable: > > RADEON_THREAD=0 > > and try again? Please, ignore this. I forgot there is no thread offloading in 7.10. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[PATCH] drm: export drm_find_cea_extension to drivers
From: Ben Skeggs
Nouveau needs access to this structure to build an ELD block for use
by the HDA audio codec.
Signed-off-by: Ben Skeggs
---
drivers/gpu/drm/drm_edid.c |3 ++-
include/drm/drm_crtc.h |1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/drivers/gpu/drm/drm_edid.c b/drivers/gpu/drm/drm_edid.c
index a245d17..0c39b09 100644
--- a/drivers/gpu/drm/drm_edid.c
+++ b/drivers/gpu/drm/drm_edid.c
@@ -1288,7 +1288,7 @@ add_detailed_modes(struct drm_connector *connector,
struct edid *edid,
/**
* Search EDID for CEA extension block.
*/
-static u8 *drm_find_cea_extension(struct edid *edid)
+u8 *drm_find_cea_extension(struct edid *edid)
{
u8 *edid_ext = NULL;
int i;
@@ -1309,6 +1309,7 @@ static u8 *drm_find_cea_extension(struct edid *edid)
return edid_ext;
}
+EXPORT_SYMBOL(drm_find_cea_extension);
/**
* drm_detect_hdmi_monitor - detect whether monitor is hdmi.
diff --git a/include/drm/drm_crtc.h b/include/drm/drm_crtc.h
index 801be59..5422004 100644
--- a/include/drm/drm_crtc.h
+++ b/include/drm/drm_crtc.h
@@ -778,6 +778,7 @@ extern int drm_mode_gamma_get_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
extern int drm_mode_gamma_set_ioctl(struct drm_device *dev,
void *data, struct drm_file *file_priv);
+extern u8 *drm_find_cea_extension(struct edid *edid);
extern bool drm_detect_hdmi_monitor(struct edid *edid);
extern bool drm_detect_monitor_audio(struct edid *edid);
extern int drm_mode_page_flip_ioctl(struct drm_device *dev,
--
1.7.4.2
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: gallium softpipe driver build instructions.
Can someone please help out with the instructions. thx K On Tue, 2011-03-29 at 10:34 -0700, kumar vemuri wrote: > Hi All, > > Am using Mesa 7.8.2. Can anyone please send out the instructions > to building a gallium based softpipe driver? > > thanks > K > > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #20 from Christophe Saout 2011-03-29 23:43:09 PDT --- Applied that patch to my kernel yesterday and just experienced the issue again. Killed compiz, X went on, but GL is unusable. If I run e.g. glxgears, the application doesn't draw anything, but is still running and seems to be waiting for something from the X server. Closing the window results in some error "34" IIRC (I can write down the exact error next time if it helps). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for -rc1
On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson wrote: > On Mon, 28 Mar 2011 21:53:32 +0300, Pekka Enberg wrote: >> On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg wrote: >> > On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie wrote: >> >> It should have the fix for your i915 in the intel patches, along with >> >> a couple of radeon fixes, and the vblank change + fix. >> > >> > I'm seeing some laptop screen flicker during boot and a while after I >> > log in (it then seems to go away). It's my trusty old Macbook with >> > i915 and Ubuntu 10.04. I see this in dmesg: >> > >> > [ 1.782046] [drm] initialized overlay support >> > [ 1.782075] [drm] capturing error event; look for more information >> > in /debug/dri/0/i915_error_state >> > [ 1.782889] render error detected, EIR: 0x0010 >> > [ 1.782933] page table error >> > [ 1.782970] PGTBL_ER: 0x0102 >> > [ 1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: >> > 0x0010, masking >> > [ 1.783063] render error detected, EIR: 0x0010 >> > [ 1.783106] page table error >> > [ 1.783143] PGTBL_ER: 0x0102 >> > >> > I'm attaching the full dmesg, i915_error_state, and .config. > > Right, looks like we have an issue with setting up the hardware for > KMS/GEM whilst it is still active. As we disable the outputs anyway for > the KMS takeover, we can arrange to do so first and so prevent this bug. > The side-effect will be that initial screen blanking will last a little > bit longer. Let me know if there's a patch/git tree to test. The flicker is extremely annoying and I boot the machine often because it's my main kernel development laptop. >> I'm also seeing these errors now which seem to be new from 2.6.38-final: >> >> [ 437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ 437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ 437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ 437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ 437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer > > That's an old userspace bug, which so far no one has been able to > reproduce on the upstream ddx. Is it harmless? Why is the kernel complaining about it? ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury wrote: > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) system > with HDMI port connected through an LVDS converter. The "panel timings" are > the HDMI output mode, and it gets set through a BIOS option making it > impossible to use the native resolution on the HDTV display. Can you please attach the EDID for the connection and let's see if there is any tell-tale? -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson wrote: > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > wrote: >> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) >> system with HDMI port connected through an LVDS converter. The "panel >> timings" are the HDMI output mode, and it gets set through a BIOS option >> making it impossible to use the native resolution on the HDTV display. > > Can you please attach the EDID for the connection and let's see if there > is any tell-tale? can you guys ask someone internally about it also, there is a driver somewhere in Google also for driving the LVDS->HDMI adapter but I'm not sure what i2c bus its hanging off. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm fixes for -rc1
On Tue, 29 Mar 2011 10:11:21 +0300, Pekka Enberg wrote: > On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson > wrote: > Let me know if there's a patch/git tree to test. The flicker is > extremely annoying and I boot the machine often because it's my main > kernel development laptop. I will let you know as soon as I have something ready for testing. > > That's an old userspace bug, which so far no one has been able to > > reproduce on the upstream ddx. > > Is it harmless? Why is the kernel complaining about it? Being pragmatic, so that I can tell one EINVAL apart from another. And it's only mostly harmless. Userspace is attempting to write to/read from a buffer it has marked as being no longer required, so some rendering is going amiss. And it does not rule out the possibility that at some point it will catch the error later and result in a SIGBUS being sent to the application (probably X). However since it is not a kernel error nor is it fatal, that and a lot of similar messages can be demoted to debug. -Chris -- Chris Wilson, Intel Open Source Technology Centre ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > wrote: >> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury >> wrote: >>> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) >>> system with HDMI port connected through an LVDS converter. The "panel >>> timings" are the HDMI output mode, and it gets set through a BIOS option >>> making it impossible to use the native resolution on the HDTV display. >> >> Can you please attach the EDID for the connection and let's see if there >> is any tell-tale? > > can you guys ask someone internally about it also, there is a driver > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > not sure what i2c bus its hanging off. > > Dave. http://git.chromium.org/gitweb/?p=chrontel.git;a=tree may or may not be the thing. Dave. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 21682] White screen with compiz/AIGLX on X.org server 1.5.2 when running on 16bpp (intel 945GM)
https://bugs.freedesktop.org/show_bug.cgi?id=21682 --- Comment #18 from Stefan Dirsch 2011-03-29 03:48:23 PDT --- Tamas, any news on that one? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > wrote: > > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) > > system with HDMI port connected through an LVDS converter. The "panel > > timings" are the HDMI output mode, and it gets set through a BIOS > > option making it impossible to use the native resolution on the HDTV > > display. > > Can you please attach the EDID for the connection and let's see if there > is any tell-tale? Unfortunately EDID doesn't seem to be making it through. /sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/edid is empty so I tried read-edid, but it reported "Monitor and video card combination does not support DDC1/2 transfers". EDID was present using VGA-DVI so the TV does support EDID. (Although it didn't actually support the modes it claimed to when it determined it was connected to a PC!) I've attached dmidecode output in case it helps.# dmidecode 2.11 SMBIOS 2.6 present. 22 structures occupying 1254 bytes. Table at 0x000FB9F0. Handle 0x, DMI type 0, 24 bytes BIOS Information Vendor: American Megatrends Inc. Version: 080016 Release Date: 12/01/2010 Address: 0xF Runtime Size: 64 kB ROM Size: 1024 kB Characteristics: ISA is supported PCI is supported PNP is supported BIOS is upgradeable BIOS shadowing is allowed ESCD support is available Boot from CD is supported Selectable boot is supported BIOS ROM is socketed EDD is supported 5.25"/1.2 MB floppy services are supported (int 13h) 3.5"/720 kB floppy services are supported (int 13h) 3.5"/2.88 MB floppy services are supported (int 13h) Print screen service is supported (int 5h) 8042 keyboard services are supported (int 9h) Serial services are supported (int 14h) Printer services are supported (int 17h) CGA/mono video services are supported (int 10h) ACPI is supported USB legacy is supported LS-120 boot is supported ATAPI Zip drive boot is supported BIOS boot specification is supported Targeted content distribution is supported BIOS Revision: 8.16 Handle 0x0001, DMI type 1, 27 bytes System Information Manufacturer: To Be Filled By O.E.M. Product Name: To Be Filled By O.E.M. Version: To Be Filled By O.E.M. Serial Number: To Be Filled By O.E.M. UUID: 03000200-0400-0500-0006-000700080009 Wake-up Type: Power Switch SKU Number: To Be Filled By O.E.M. Family: To Be Filled By O.E.M. Handle 0x0002, DMI type 2, 15 bytes Base Board Information Manufacturer: To be filled by O.E.M. Product Name: To be filled by O.E.M. Version: To be filled by O.E.M. Serial Number: To be filled by O.E.M. Asset Tag: To Be Filled By O.E.M. Features: Board is a hosting board Board is replaceable Location In Chassis: To Be Filled By O.E.M. Chassis Handle: 0x0003 Type: Motherboard Contained Object Handles: 0 Handle 0x0003, DMI type 3, 21 bytes Chassis Information Manufacturer: To Be Filled By O.E.M. Type: Desktop Lock: Not Present Version: To Be Filled By O.E.M. Serial Number: To Be Filled By O.E.M. Asset Tag: To Be Filled By O.E.M. Boot-up State: Safe Power Supply State: Safe Thermal State: Safe Security Status: None OEM Information: 0x Height: Unspecified Number Of Power Cords: 1 Contained Elements: 0 Handle 0x0004, DMI type 4, 42 bytes Processor Information Socket Designation: CPU 1 Type: Central Processor Family: Atom Manufacturer: Intel ID: CA 06 01 00 FF FB EB BF Signature: Type 0, Family 6, Model 28, Stepping 10 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table)
Re: [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > wrote: > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > wrote: > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > (Pineview) system with HDMI port connected through an LVDS > > > > converter. The "panel timings" are the HDMI output mode, and it > > > > gets set through a BIOS option making it impossible to use the > > > > native resolution on the HDTV display. > > > > > > Can you please attach the EDID for the connection and let's see if > > > there is any tell-tale? > > > > can you guys ask someone internally about it also, there is a driver > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > not sure what i2c bus its hanging off. > > > > Dave. > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > may or may not be the thing. > > Dave. I'll see if it works... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > wrote: > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > wrote: > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > converter. The "panel timings" are the HDMI output mode, and it > > > > > gets set through a BIOS option making it impossible to use the > > > > > native resolution on the HDTV display. > > > > > > > > Can you please attach the EDID for the connection and let's see if > > > > there is any tell-tale? > > > > > > can you guys ask someone internally about it also, there is a driver > > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > > not sure what i2c bus its hanging off. > > > > > > Dave. > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > may or may not be the thing. > > > > Dave. > I'll see if it works... Is there a public clone URI for that repo? I dont want to have to download the full ChromiumOS... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > - Original message - > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > wrote: > > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > > wrote: > > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > > wrote: > > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > > converter. The "panel timings" are the HDMI output mode, and > > > > > > it gets set through a BIOS option making it impossible to use > > > > > > the native resolution on the HDTV display. > > > > > > > > > > Can you please attach the EDID for the connection and let's see > > > > > if there is any tell-tale? > > > > > > > > can you guys ask someone internally about it also, there is a > > > > driver somewhere in Google also for driving the LVDS->HDMI adapter > > > > but I'm not sure what i2c bus its hanging off. > > > > > > > > Dave. > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > may or may not be the thing. > > > > > > Dave. > > I'll see if it works... > Is there a public clone URI for that repo? I dont want to have to > download the full ChromiumOS... Okay, I guessed it right: http://git.chromium.org/git/chrontel.git ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > > - Original message - > > - Original message - > > > - Original message - > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > wrote: > > > > > can you guys ask someone internally about it also, there is a > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > Dave. > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > may or may not be the thing. > > > > > > > > Dave. > > > I'll see if it works... > > Is there a public clone URI for that repo? I dont want to have to > > download the full ChromiumOS... > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git Simply running the resulting executables didn't work, it fails to detect the chip, the code also references accesses through GPIO and seems it wants an nm10_gpio driver which isn't in my kernel tree. My board is an NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could well be the same hardware. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #15 from Christophe Saout 2011-03-29 07:19:04 PDT --- Hmm, I wouldn't have made the connection with "graphical glitches" and also I'm not disabling redirection in fullscreen mode, but I'm still trying the attached patch. I applied it yesterday evening and X has been running ever since. If it stays that for the next few days I will call you my personal hero. ;) I'll come back otherwise. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Mon, Mar 28, 2011 at 2:13 PM, Lucas Stach wrote: > Hi, > > I have seen this too in some traces I have done with nouveau nvfx some > time ago. (The report in kernel bugzilla is a outcome of this.) I'm > strongly in favour of fixing the kernel side, as I think doing a > workaround in userspace is a bad hack. In fact doing so is on my long > "list of things to fix when I ever get a 48h day". > > One thing that pulled me away from this is, that doing something new in > mmap is a bit regression-prone. If we miss some corner case it is very > easy to break someone's application. > > --Lucas > > Am Montag, den 28.03.2011, 19:16 +0800 schrieb r6144: >> Hello, >> >> I am reporting a problem of significant desktop sluggishness caused by >> mmap-related kernel algorithms. In particular, after a few days of use, >> I encounter multiple-second delays switching between a workspace >> containing Evolution and another containing e.g. firefox, which is very >> annoying since I switch workspaces very frequently. Oprofile indicates >> that, during workspace switching, over 30% of CPU time is spent in >> find_vma(), likely called from arch_get_unmapped_area_topdown(). >> >> This is essentially a repost of https://lkml.org/lkml/2010/11/14/236 , >> with a bit more investigation and workarounds. The same issue has also >> been reported in https://bugzilla.kernel.org/show_bug.cgi?id=17531 , but >> that bug report has not received any attention either. >> >> My kernel is Fedora 14's kernel-2.6.35.11-83.fc14.x86_64, and the open >> source radeon (r600) driver is used. >> >> Basically, the GEM/TTM-based r600 driver (and presumably many other >> drivers as well) seems to allocate a buffer object for each XRender >> picture or glyph, and most such objects are mapped into the X server's >> address space with libdrm. After the system runs for a few days, the >> number of mappings according to "wc -l /proc/$(pgrep Xorg)/maps" can >> reach 5k-10k, with the vast majority being 4kB-sized mappings >> to /dev/dri/card0 almost contiguously laid out in the address space. >> Such a large number of mappings should be expected, given the numerous >> distinct glyphs arising from different CJK characters, fonts, and sizes. >> Note that libdrm_radeon's bo_unmap() keeps a buffer object mapped even >> if it is no longer accessed by the CPU (and only calls munmap() when the >> object is destroyed), which has certainly inflated the mapping count >> significantly, but otherwise the mmap() overhead would be prohibitive. >> >> Currently the kernel's arch_get_unmapped_area_topdown() is linear-time, >> so further mmap() calls becomes very slow with so many mappings existing >> in the X server's address space. Since redrawing a window usually >> involves the creation of a significant number of temporary pixmaps or >> XRender pictures, often requiring mapping by the X server, it is thus >> slowed down greatly. Although arch_get_unmapped_area_topdown() attempts >> to use mm->free_area_cache to speed up the search, the cache is usually >> invalidated due to the mm->cached_hole_size test whenever the block size >> being searched for is smaller than that in the last time; this ensures >> that the function always finds the earliest unmapped area in search >> order that is sufficiently large, thus reducing address space >> fragmentation (commit 1363c3cd). Consequently, if different mapping >> sizes are used in successive mmap() calls, as is often the case when >> dealing with pixmaps larger than a page in size, the cache would be >> invalidated almost half of the time, and the amortized cost of each >> mmap() remains linear. >> >> A quantitative measurement is made with the attached pbobench.cpp, >> compiled with Makefile.pbobench. This program uses OpenGL pixel-buffer >> objects (which corresponds one-to-one to GEM buffer objects on my >> system) to simulate the effect of having a large number of GEM-related >> mappings in the X server. It first creates and maps N page-sized PBOs >> to mimic the large number of XRender glyphs, then measures the time >> needed to create/map/unmap/destroy more PBOs with size varying between >> 1-16384 bytes. The time spent per iteration (which does either a >> create/map or an unmap/destroy) is clearly O(N): >> >> N=100: 17.3us >> N=1000: 19.9us >> N=1: 88.5us >> N=2: 205us >> N=4: 406us >> >> and in oprofile results, the amount of CPU time spent in find_vma() can >> reach 60-70%, while no other single function takes more than 3%. >> >> I think this problem is not difficult to solve. While it isn't obvious >> to me how to find the earliest sufficiently-large unmapped area quickly, >> IMHO it is just as good, fragmentation-wise, if we simply allocate from >> the smallest sufficiently-large unmapped area regardless of its address; >> for this purpose, the final "open-ended" unmapped area in the original >> search order (i.e. the one with the lowest address in >> arch_get_unmapped_area_topdown()) can be regarde
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #16 from Alex Deucher 2011-03-29 07:27:42 PDT --- (In reply to comment #15) > Hmm, I wouldn't have made the connection with "graphical glitches" and also > I'm > not disabling redirection in fullscreen mode, but I'm still trying the > attached > patch. I applied it yesterday evening and X has been running ever since. If it > stays that for the next few days I will call you my personal hero. ;) I'll > come > back otherwise. Just to be clear, which patch are you referring to? The one from bug 35452 or the one from comment 6 of this bug? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: drm/radeon: using libdrm_radeon for a new display server
On Tue, Mar 29, 2011 at 12:59 AM, Marek Olšák wrote: > On Mon, Mar 28, 2011 at 9:35 AM, Chia-I Wu wrote: >> >> Hi list, >> >> I have a simple scenario that there are clients rendering to buffer >> objects using the CPU, and the display server compositing the buffers >> using OpenGL and doing page flips to present the final contents. It >> is like doing the following steps repeatedly >> >> 1) process A (the server) allocates a bo >> >> bo = radeon_bo_open(info->bufmgr, 0, size, align, RADEON_GEM_DOMAIN_GTT, >> 0); >> >> 2) process B (the client) maps the bo for CPU rendering and unmaps >> >> radeon_bo_map(bo, 1); >> /* ...render with CPU... */ >> radeon_bo_unmap(bo); >> >> 3) process A renders to the back buffer using the bo as the texture >> >> /* renders with OpenGL followed by a glFinish() */ >> >> 4) process A flips its front and back buffers >> >> drmModePageFlip(fd, crtc_id, fb_id_of_the_bo, 0x0, NULL); >> drmWaitVBlank(fd, &vbl); /* HACK! wait until the next vblank */ >> >> With this setup, I am seeing glitches frequently. My hardware is a >> CEDAR. The kernel is 2.6.38-rc7 and both mesa and drm are from >> master. I originally ran them on a i965-based machine using >> libdrm_i915, and it is fine there. >> >> I think there are sync issues in how I use libdrm_radeon, but I could >> not identify them. Here are my findings/questions >> >> In 1), The bo is initially in the GTT domain because CPU rendering is >> expected. Using VRAM domain reduces the glitches greatly, but there >> are still glitches and the framerate is much lower. >> >> In 3), glFinish() is called after rendering to make sure the frame is >> complete before page flipping. Does glFlush() suffice here? I think >> that would require page flipping to be pipelined, but I am not sure if >> that is the case with radeon. > > glFinish uses fences, which are not implemented in r600g (and there is no > wait-for-a-fence ioctl), so glFinish=glFlush. Could that be the cause of > your problems? The other radeon drivers use bo_wait for glFinish (including > r300g). It turned out to be 4) that causes the glitches. It is resolved by using DRM_MODE_PAGE_FLIP_EVENT as mentioned in the last mail. But drmModePageFlip still needs to be fixed to block rendering to the previous scanout buffer until the flip takes place. > Marek > ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
> > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > > wrote: > > > > > > can you guys ask someone internally about it also, there is a > > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > > > Dave. > > > > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > > > may or may not be the thing. > > > > > > > > > > Dave. > > > > I'll see if it works... > > > Is there a public clone URI for that repo? I dont want to have to > > > download the full ChromiumOS... > > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git > Simply running the resulting executables didn't work, it fails to detect > the chip, the code also references accesses through GPIO and seems it > wants an nm10_gpio driver which isn't in my kernel tree. My board is an > NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could > well be the same hardware. I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while it worked fine the chrontel driver still couldn't detect the chip: XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p ./ch7036_monitor: starts Found device ID 0xff ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 So either it isn't a ch7036 or I'm still not doing everything necessary to expose it. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
WARNING: at drivers/gpu/drm/ttm/ttm_page_alloc.c:758
Just came across this WARNING (running latest git kernel): Mar 29 09:14:39 gentoo kernel: udev[888]: starting version 164 Mar 29 15:45:45 gentoo kernel: [ cut here ] Mar 29 15:45:45 gentoo kernel: WARNING: at drivers/gpu/drm/ttm/ttm_page_alloc.c:758 ttm_put_pages+0x1c6/0x2b0() Mar 29 15:45:45 gentoo kernel: Hardware name: System Product Name Mar 29 15:45:45 gentoo kernel: Pid: 688, comm: kworker/u:6 Not tainted 2.6.38-09065-g89078d5 #23 Mar 29 15:45:45 gentoo kernel: Call Trace: Mar 29 15:45:45 gentoo kernel: [] warn_slowpath_common+0x7a/0xb0 Mar 29 15:45:45 gentoo kernel: [] warn_slowpath_null+0x1a/0x20 Mar 29 15:45:45 gentoo kernel: [] ttm_put_pages+0x1c6/0x2b0 Mar 29 15:45:45 gentoo kernel: [] ttm_tt_free_alloced_pages+0xbd/0x100 Mar 29 15:45:45 gentoo kernel: [] ttm_tt_swapout+0x1ac/0x2a0 Mar 29 15:45:45 gentoo kernel: [] ttm_bo_swapout+0x1a5/0x230 Mar 29 15:45:45 gentoo kernel: [] ? drm_mm_kmalloc+0x3c/0xd0 Mar 29 15:45:45 gentoo kernel: [] ttm_shrink+0xd8/0x120 Mar 29 15:45:45 gentoo kernel: [] ? queue_delayed_work_on+0x91/0x100 Mar 29 15:45:45 gentoo kernel: [] ? ttm_shrink+0x120/0x120 Mar 29 15:45:45 gentoo kernel: [] ttm_shrink_work+0x19/0x20 Mar 29 15:45:45 gentoo kernel: [] process_one_work+0x11e/0x4c0 Mar 29 15:45:45 gentoo kernel: [] worker_thread+0x15e/0x340 Mar 29 15:45:45 gentoo kernel: [] ? manage_workers.isra.28+0x220/0x220 Mar 29 15:45:45 gentoo kernel: [] kthread+0x8c/0xa0 Mar 29 15:45:45 gentoo kernel: [] kernel_thread_helper+0x4/0x10 Mar 29 15:45:45 gentoo kernel: [] ? kthread_flush_work_fn+0x20/0x20 Mar 29 15:45:45 gentoo kernel: [] ? gs_change+0xb/0xb Mar 29 15:45:45 gentoo kernel: ---[ end trace d5b07e4231e70291 ]--- Mar 29 15:45:45 gentoo kernel: [ cut here ] ... It's repeated ad nauseam from there on. (/var/log/kern.log is now over 85MB in size) -- Markus ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #17 from Christophe Saout 2011-03-29 08:07:17 PDT --- I was referring to Bug 35452. But bad news: That fix didn't make a difference, I just experienced the same GL lockup again. Just for completeness I'll also apply the patch from comment 6 ind addition to see if that makes any difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
2011/3/29 r6144 : > 在 2011-03-29二的 10:22 -0400，Jerome Glisse写道： > >> Killer solution would be to have no mapping and a decent >> upload/download ioctl that can take userpage. > > Doesn't this sound like GEM's read/write interface implemented by e.g. > the i915 driver? But if I understand correctly, a mmap-like interface > should still be necessary if we want to implement e.g. glMapBuffer() > without extra copying. > > r6144 > > glMapBuffer should not be use, it's really not a good way to do stuff. Anyway the extra copy might be unavoidable given that sometime the front/back might either be in unmappable vram or either have memory layout that is not the one specify at buffer creation (this is very common when using tiling for instance). So even considering MapBuffer or a like function i believe it's a lot better to not allow buffer mapping in userspace but provide upload/download hooks that can use userpage to avoid as much as possible extra copy. Cheers, Jerome ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
在 2011-03-29二的 10:22 -0400，Jerome Glisse写道： > Killer solution would be to have no mapping and a decent > upload/download ioctl that can take userpage. Doesn't this sound like GEM's read/write interface implemented by e.g. the i915 driver? But if I understand correctly, a mmap-like interface should still be necessary if we want to implement e.g. glMapBuffer() without extra copying. r6144 ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[git pull] drm fixes for -rc1
On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson wrote: > On Mon, 28 Mar 2011 21:53:32 +0300, Pekka Enberg > wrote: >> On Mon, Mar 28, 2011 at 9:43 PM, Pekka Enberg wrote: >> > On Thu, Mar 24, 2011 at 1:34 PM, Dave Airlie wrote: >> >> It should have the fix for your i915 in the intel patches, along with >> >> a couple of radeon fixes, and the vblank change + fix. >> > >> > I'm seeing some laptop screen flicker during boot and a while after I >> > log in (it then seems to go away). It's my trusty old Macbook with >> > i915 and Ubuntu 10.04. I see this in dmesg: >> > >> > [ ? ?1.782046] [drm] initialized overlay support >> > [ ? ?1.782075] [drm] capturing error event; look for more information >> > in /debug/dri/0/i915_error_state >> > [ ? ?1.782889] render error detected, EIR: 0x0010 >> > [ ? ?1.782933] page table error >> > [ ? ?1.782970] ? PGTBL_ER: 0x0102 >> > [ ? ?1.783009] [drm:i915_report_and_clear_eir] *ERROR* EIR stuck: >> > 0x0010, masking >> > [ ? ?1.783063] render error detected, EIR: 0x0010 >> > [ ? ?1.783106] page table error >> > [ ? ?1.783143] ? PGTBL_ER: 0x0102 >> > >> > I'm attaching the full dmesg, i915_error_state, and .config. > > Right, looks like we have an issue with setting up the hardware for > KMS/GEM whilst it is still active. As we disable the outputs anyway for > the KMS takeover, we can arrange to do so first and so prevent this bug. > The side-effect will be that initial screen blanking will last a little > bit longer. Let me know if there's a patch/git tree to test. The flicker is extremely annoying and I boot the machine often because it's my main kernel development laptop. >> I'm also seeing these errors now which seem to be new from 2.6.38-final: >> >> [ ?437.566022] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ ?437.566187] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ ?437.566232] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ ?437.566275] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer >> [ ?437.566318] [drm:i915_gem_mmap_gtt] *ERROR* Attempting to mmap a >> purgeable buffer > > That's an old userspace bug, which so far no one has been able to > reproduce on the upstream ddx. Is it harmless? Why is the kernel complaining about it?
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury wrote: > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) system > with HDMI port connected through an LVDS converter. The "panel timings" are > the HDMI output mode, and it gets set through a BIOS option making it > impossible to use the native resolution on the HDTV display. Can you please attach the EDID for the connection and let's see if there is any tell-tale? -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson wrote: > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > wrote: >> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) >> system with HDMI port connected through an LVDS converter. ?The "panel >> timings" are the HDMI output mode, and it gets set through a BIOS option >> making it impossible to use the native resolution on the HDTV display. > > Can you please attach the EDID for the connection and let's see if there > is any tell-tale? can you guys ask someone internally about it also, there is a driver somewhere in Google also for driving the LVDS->HDMI adapter but I'm not sure what i2c bus its hanging off. Dave.
[git pull] drm fixes for -rc1
On Tue, 29 Mar 2011 10:11:21 +0300, Pekka Enberg wrote: > On Mon, Mar 28, 2011 at 10:09 PM, Chris Wilson > wrote: > Let me know if there's a patch/git tree to test. The flicker is > extremely annoying and I boot the machine often because it's my main > kernel development laptop. I will let you know as soon as I have something ready for testing. > > That's an old userspace bug, which so far no one has been able to > > reproduce on the upstream ddx. > > Is it harmless? Why is the kernel complaining about it? Being pragmatic, so that I can tell one EINVAL apart from another. And it's only mostly harmless. Userspace is attempting to write to/read from a buffer it has marked as being no longer required, so some rendering is going amiss. And it does not rule out the possibility that at some point it will catch the error later and result in a SIGBUS being sent to the application (probably X). However since it is not a kernel error nor is it fatal, that and a lot of similar messages can be demoted to debug. -Chris -- Chris Wilson, Intel Open Source Technology Centre
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > wrote: >> On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > snewbury.org.uk> wrote: >>> Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) >>> system with HDMI port connected through an LVDS converter. ?The "panel >>> timings" are the HDMI output mode, and it gets set through a BIOS option >>> making it impossible to use the native resolution on the HDTV display. >> >> Can you please attach the EDID for the connection and let's see if there >> is any tell-tale? > > can you guys ask someone internally about it also, there is a driver > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > not sure what i2c bus its hanging off. > > Dave. http://git.chromium.org/gitweb/?p=chrontel.git;a=tree may or may not be the thing. Dave.
[Bug 21682] White screen with compiz/AIGLX on X.org server 1.5.2 when running on 16bpp (intel 945GM)
https://bugs.freedesktop.org/show_bug.cgi?id=21682 --- Comment #18 from Stefan Dirsch 2011-03-29 03:48:23 PDT --- Tamas, any news on that one? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > wrote: > > Hi Chris, have you updated this patch? I have an Intel D525 (Pineview) > > system with HDMI port connected through an LVDS converter.? The "panel > > timings" are the HDMI output mode, and it gets set through a BIOS > > option making it impossible to use the native resolution on the HDTV > > display. > > Can you please attach the EDID for the connection and let's see if there > is any tell-tale? Unfortunately EDID doesn't seem to be making it through. /sys/devices/pci:00/:00:02.0/drm/card0/card0-LVDS-1/edid is empty so I tried read-edid, but it reported "Monitor and video card combination does not support DDC1/2 transfers". EDID was present using VGA-DVI so the TV does support EDID. (Although it didn't actually support the modes it claimed to when it determined it was connected to a PC!) I've attached dmidecode output in case it helps. -- next part -- An embedded and charset-unspecified text was scrubbed... Name: dmi-decoded URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20110329/1e814552/attachment.asc>
[PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > wrote: > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > wrote: > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > (Pineview) system with HDMI port connected through an LVDS > > > > converter. ?The "panel timings" are the HDMI output mode, and it > > > > gets set through a BIOS option making it impossible to use the > > > > native resolution on the HDTV display. > > > > > > Can you please attach the EDID for the connection and let's see if > > > there is any tell-tale? > > > > can you guys ask someone internally about it also, there is a driver > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > not sure what i2c bus its hanging off. > > > > Dave. > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > may or may not be the thing. > > Dave. I'll see if it works...
[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie wrote: > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > wrote: > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > wrote: > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > converter. ?The "panel timings" are the HDMI output mode, and it > > > > > gets set through a BIOS option making it impossible to use the > > > > > native resolution on the HDTV display. > > > > > > > > Can you please attach the EDID for the connection and let's see if > > > > there is any tell-tale? > > > > > > can you guys ask someone internally about it also, there is a driver > > > somewhere in Google also for driving the LVDS->HDMI adapter but I'm > > > not sure what i2c bus its hanging off. > > > > > > Dave. > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > may or may not be the thing. > > > > Dave. > I'll see if it works... Is there a public clone URI for that repo? I dont want to have to download the full ChromiumOS...
[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > - Original message - > > - Original message - > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > wrote: > > > > On Tue, Mar 29, 2011 at 5:29 PM, Chris Wilson > > > > wrote: > > > > > On Mon, 28 Mar 2011 22:46:55 +0100, Steven Newbury > > > > > wrote: > > > > > > Hi Chris, have you updated this patch? I have an Intel D525 > > > > > > (Pineview) system with HDMI port connected through an LVDS > > > > > > converter. ?The "panel timings" are the HDMI output mode, and > > > > > > it gets set through a BIOS option making it impossible to use > > > > > > the native resolution on the HDTV display. > > > > > > > > > > Can you please attach the EDID for the connection and let's see > > > > > if there is any tell-tale? > > > > > > > > can you guys ask someone internally about it also, there is a > > > > driver somewhere in Google also for driving the LVDS->HDMI adapter > > > > but I'm not sure what i2c bus its hanging off. > > > > > > > > Dave. > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > may or may not be the thing. > > > > > > Dave. > > I'll see if it works... > Is there a public clone URI for that repo? I dont want to have to > download the full ChromiumOS... Okay, I guessed it right: http://git.chromium.org/git/chrontel.git
[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
- Original message - > > - Original message - > > - Original message - > > > - Original message - > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > wrote: > > > > > can you guys ask someone internally about it also, there is a > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > Dave. > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > may or may not be the thing. > > > > > > > > Dave. > > > I'll see if it works... > > Is there a public clone URI for that repo? I dont want to have to > > download the full ChromiumOS... > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git Simply running the resulting executables didn't work, it fails to detect the chip, the code also references accesses through GPIO and seems it wants an nm10_gpio driver which isn't in my kernel tree. My board is an NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could well be the same hardware.
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #15 from Christophe Saout 2011-03-29 07:19:04 PDT --- Hmm, I wouldn't have made the connection with "graphical glitches" and also I'm not disabling redirection in fullscreen mode, but I'm still trying the attached patch. I applied it yesterday evening and X has been running ever since. If it stays that for the next few days I will call you my personal hero. ;) I'll come back otherwise. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Mon, Mar 28, 2011 at 2:13 PM, Lucas Stach wrote: > Hi, > > I have seen this too in some traces I have done with nouveau nvfx some > time ago. (The report in kernel bugzilla is a outcome of this.) I'm > strongly in favour of fixing the kernel side, as I think doing a > workaround in userspace is a bad hack. In fact doing so is on my long > "list of things to fix when I ever get a 48h day". > > One thing that pulled me away from this is, that doing something new in > mmap is a bit regression-prone. If we miss some corner case it is very > easy to break someone's application. > > --Lucas > > Am Montag, den 28.03.2011, 19:16 +0800 schrieb r6144: >> Hello, >> >> I am reporting a problem of significant desktop sluggishness caused by >> mmap-related kernel algorithms. ?In particular, after a few days of use, >> I encounter multiple-second delays switching between a workspace >> containing Evolution and another containing e.g. firefox, which is very >> annoying since I switch workspaces very frequently. ?Oprofile indicates >> that, during workspace switching, over 30% of CPU time is spent in >> find_vma(), likely called from arch_get_unmapped_area_topdown(). >> >> This is essentially a repost of https://lkml.org/lkml/2010/11/14/236 , >> with a bit more investigation and workarounds. ?The same issue has also >> been reported in https://bugzilla.kernel.org/show_bug.cgi?id=17531 , but >> that bug report has not received any attention either. >> >> My kernel is Fedora 14's kernel-2.6.35.11-83.fc14.x86_64, and the open >> source radeon (r600) driver is used. >> >> Basically, the GEM/TTM-based r600 driver (and presumably many other >> drivers as well) seems to allocate a buffer object for each XRender >> picture or glyph, and most such objects are mapped into the X server's >> address space with libdrm. ?After the system runs for a few days, the >> number of mappings according to "wc -l /proc/$(pgrep Xorg)/maps" can >> reach 5k-10k, with the vast majority being 4kB-sized mappings >> to /dev/dri/card0 almost contiguously laid out in the address space. >> Such a large number of mappings should be expected, given the numerous >> distinct glyphs arising from different CJK characters, fonts, and sizes. >> Note that libdrm_radeon's bo_unmap() keeps a buffer object mapped even >> if it is no longer accessed by the CPU (and only calls munmap() when the >> object is destroyed), which has certainly inflated the mapping count >> significantly, but otherwise the mmap() overhead would be prohibitive. >> >> Currently the kernel's arch_get_unmapped_area_topdown() is linear-time, >> so further mmap() calls becomes very slow with so many mappings existing >> in the X server's address space. ?Since redrawing a window usually >> involves the creation of a significant number of temporary pixmaps or >> XRender pictures, often requiring mapping by the X server, it is thus >> slowed down greatly. ?Although arch_get_unmapped_area_topdown() attempts >> to use mm->free_area_cache to speed up the search, the cache is usually >> invalidated due to the mm->cached_hole_size test whenever the block size >> being searched for is smaller than that in the last time; this ensures >> that the function always finds the earliest unmapped area in search >> order that is sufficiently large, thus reducing address space >> fragmentation (commit 1363c3cd). ?Consequently, if different mapping >> sizes are used in successive mmap() calls, as is often the case when >> dealing with pixmaps larger than a page in size, the cache would be >> invalidated almost half of the time, and the amortized cost of each >> mmap() remains linear. >> >> A quantitative measurement is made with the attached pbobench.cpp, >> compiled with Makefile.pbobench. ?This program uses OpenGL pixel-buffer >> objects (which corresponds one-to-one to GEM buffer objects on my >> system) to simulate the effect of having a large number of GEM-related >> mappings in the X server. ?It first creates and maps N page-sized PBOs >> to mimic the large number of XRender glyphs, then measures the time >> needed to create/map/unmap/destroy more PBOs with size varying between >> 1-16384 bytes. ?The time spent per iteration (which does either a >> create/map or an unmap/destroy) is clearly O(N): >> >> N=100: 17.3us >> N=1000: 19.9us >> N=1: 88.5us >> N=2: 205us >> N=4: 406us >> >> and in oprofile results, the amount of CPU time spent in find_vma() can >> reach 60-70%, while no other single function takes more than 3%. >> >> I think this problem is not difficult to solve. ?While it isn't obvious >> to me how to find the earliest sufficiently-large unmapped area quickly, >> IMHO it is just as good, fragmentation-wise, if we simply allocate from >> the smallest sufficiently-large unmapped area regardless of its address; >> for this purpose, the final "open-ended" unmapped area in the original >> search order (i.e. the one with the lowest address in >> arch_get_unmapped_area_topdown()) can be regarde
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #16 from Alex Deucher 2011-03-29 07:27:42 PDT --- (In reply to comment #15) > Hmm, I wouldn't have made the connection with "graphical glitches" and also > I'm > not disabling redirection in fullscreen mode, but I'm still trying the > attached > patch. I applied it yesterday evening and X has been running ever since. If it > stays that for the next few days I will call you my personal hero. ;) I'll > come > back otherwise. Just to be clear, which patch are you referring to? The one from bug 35452 or the one from comment 6 of this bug? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
drm/radeon: using libdrm_radeon for a new display server
On Tue, Mar 29, 2011 at 12:59 AM, Marek Ol??k wrote: > On Mon, Mar 28, 2011 at 9:35 AM, Chia-I Wu wrote: >> >> Hi list, >> >> I have a simple scenario that there are clients rendering to buffer >> objects using the CPU, and the display server compositing the buffers >> using OpenGL and doing page flips to present the final contents. ?It >> is like doing the following steps repeatedly >> >> 1) process A (the server) allocates a bo >> >> ? bo = radeon_bo_open(info->bufmgr, 0, size, align, RADEON_GEM_DOMAIN_GTT, >> 0); >> >> 2) process B (the client) maps the bo for CPU rendering and unmaps >> >> ? radeon_bo_map(bo, 1); >> ? /* ...render with CPU... */ >> ? radeon_bo_unmap(bo); >> >> 3) process A renders to the back buffer using the bo as the texture >> >> ? /* renders with OpenGL followed by a glFinish() */ >> >> 4) process A flips its front and back buffers >> >> ? drmModePageFlip(fd, crtc_id, fb_id_of_the_bo, 0x0, NULL); >> ? drmWaitVBlank(fd, &vbl); /* HACK! wait until the next vblank */ >> >> With this setup, I am seeing glitches frequently. ?My hardware is a >> CEDAR. ?The kernel is 2.6.38-rc7 and both mesa and drm are from >> master. ?I originally ran them on a i965-based machine using >> libdrm_i915, and it is fine there. >> >> I think there are sync issues in how I use libdrm_radeon, but I could >> not identify them. ?Here are my findings/questions >> >> In 1), The bo is initially in the GTT domain because CPU rendering is >> expected. ?Using VRAM domain reduces the glitches greatly, but there >> are still glitches and the framerate is much lower. >> >> In 3), glFinish() is called after rendering to make sure the frame is >> complete before page flipping. ?Does glFlush() suffice here? ?I think >> that would require page flipping to be pipelined, but I am not sure if >> that is the case with radeon. > > glFinish uses fences, which are not implemented in r600g (and there is no > wait-for-a-fence ioctl), so glFinish=glFlush. Could that be the cause of > your problems? The other radeon drivers use bo_wait for glFinish (including > r300g). It turned out to be 4) that causes the glitches. It is resolved by using DRM_MODE_PAGE_FLIP_EVENT as mentioned in the last mail. But drmModePageFlip still needs to be fixed to block rendering to the previous scanout buffer until the flip takes place. > Marek >
[Intel-gfx] [PATCH] drm, drm/i915/lvds: Honour video= parameter to override LVDS fixed mode
> > > > > On Tue, Mar 29, 2011 at 5:49 PM, Dave Airlie > > > > > wrote: > > > > > > can you guys ask someone internally about it also, there is a > > > > > > driver somewhere in Google also for driving the LVDS->HDMI > > > > > > adapter but I'm not sure what i2c bus its hanging off. > > > > > > > > > > > > Dave. > > > > > > > > > > > > > > > http://git.chromium.org/gitweb/?p=chrontel.git;a=tree > > > > > > > > > > may or may not be the thing. > > > > > > > > > > Dave. > > > > I'll see if it works... > > > Is there a public clone URI for that repo? I dont want to have to > > > download the full ChromiumOS... > > Okay, I guessed it right: http://git.chromium.org/git/chrontel.git > Simply running the resulting executables didn't work, it fails to detect > the chip, the code also references accesses through GPIO and seems it > wants an nm10_gpio driver which isn't in my kernel tree. My board is an > NM10 chipset system, as is the target "Cr48 Chrome Notebook" so it could > well be the same hardware. I cherry-picked the nm10_gpio driver from the ChromeOS kernel, but while it worked fine the chrontel driver still couldn't detect the chip: XAUTHORITY=//home/mythtv/.Xauthority ./ch7036_monitor -v -p ./ch7036_monitor: starts Found device ID 0xff ./ch7036_monitor: Fatal: Device ID 0xff not the expected 0x56 So either it isn't a ch7036 or I'm still not doing everything necessary to expose it.
WARNING: at drivers/gpu/drm/ttm/ttm_page_alloc.c:758
Just came across this WARNING (running latest git kernel): Mar 29 09:14:39 gentoo kernel: udev[888]: starting version 164 Mar 29 15:45:45 gentoo kernel: [ cut here ] Mar 29 15:45:45 gentoo kernel: WARNING: at drivers/gpu/drm/ttm/ttm_page_alloc.c:758 ttm_put_pages+0x1c6/0x2b0() Mar 29 15:45:45 gentoo kernel: Hardware name: System Product Name Mar 29 15:45:45 gentoo kernel: Pid: 688, comm: kworker/u:6 Not tainted 2.6.38-09065-g89078d5 #23 Mar 29 15:45:45 gentoo kernel: Call Trace: Mar 29 15:45:45 gentoo kernel: [] warn_slowpath_common+0x7a/0xb0 Mar 29 15:45:45 gentoo kernel: [] warn_slowpath_null+0x1a/0x20 Mar 29 15:45:45 gentoo kernel: [] ttm_put_pages+0x1c6/0x2b0 Mar 29 15:45:45 gentoo kernel: [] ttm_tt_free_alloced_pages+0xbd/0x100 Mar 29 15:45:45 gentoo kernel: [] ttm_tt_swapout+0x1ac/0x2a0 Mar 29 15:45:45 gentoo kernel: [] ttm_bo_swapout+0x1a5/0x230 Mar 29 15:45:45 gentoo kernel: [] ? drm_mm_kmalloc+0x3c/0xd0 Mar 29 15:45:45 gentoo kernel: [] ttm_shrink+0xd8/0x120 Mar 29 15:45:45 gentoo kernel: [] ? queue_delayed_work_on+0x91/0x100 Mar 29 15:45:45 gentoo kernel: [] ? ttm_shrink+0x120/0x120 Mar 29 15:45:45 gentoo kernel: [] ttm_shrink_work+0x19/0x20 Mar 29 15:45:45 gentoo kernel: [] process_one_work+0x11e/0x4c0 Mar 29 15:45:45 gentoo kernel: [] worker_thread+0x15e/0x340 Mar 29 15:45:45 gentoo kernel: [] ? manage_workers.isra.28+0x220/0x220 Mar 29 15:45:45 gentoo kernel: [] kthread+0x8c/0xa0 Mar 29 15:45:45 gentoo kernel: [] kernel_thread_helper+0x4/0x10 Mar 29 15:45:45 gentoo kernel: [] ? kthread_flush_work_fn+0x20/0x20 Mar 29 15:45:45 gentoo kernel: [] ? gs_change+0xb/0xb Mar 29 15:45:45 gentoo kernel: ---[ end trace d5b07e4231e70291 ]--- Mar 29 15:45:45 gentoo kernel: [ cut here ] ... It's repeated ad nauseam from there on. (/var/log/kern.log is now over 85MB in size) -- Markus
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #17 from Christophe Saout 2011-03-29 08:07:17 PDT --- I was referring to Bug 35452. But bad news: That fix didn't make a difference, I just experienced the same GL lockup again. Just for completeness I'll also apply the patch from comment 6 ind addition to see if that makes any difference. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
2011/3/29 r6144 : > ? 2011-03-29?? 10:22 -0400?Jerome Glisse??? > >> Killer solution would be to have no mapping and a decent >> upload/download ioctl that can take userpage. > > Doesn't this sound like GEM's read/write interface implemented by e.g. > the i915 driver? But if I understand correctly, a mmap-like interface > should still be necessary if we want to implement e.g. glMapBuffer() > without extra copying. > > r6144 > > glMapBuffer should not be use, it's really not a good way to do stuff. Anyway the extra copy might be unavoidable given that sometime the front/back might either be in unmappable vram or either have memory layout that is not the one specify at buffer creation (this is very common when using tiling for instance). So even considering MapBuffer or a like function i believe it's a lot better to not allow buffer mapping in userspace but provide upload/download hooks that can use userpage to avoid as much as possible extra copy. Cheers, Jerome
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
? 2011-03-29?? 10:22 -0400?Jerome Glisse??? > Killer solution would be to have no mapping and a decent > upload/download ioctl that can take userpage. Doesn't this sound like GEM's read/write interface implemented by e.g. the i915 driver? But if I understand correctly, a mmap-like interface should still be necessary if we want to implement e.g. glMapBuffer() without extra copying. r6144
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #18 from Christophe Saout 2011-03-29 08:26:51 PDT --- Oh, well, that patch only concerns rs600, right? So no point in that... -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #19 from Alex Deucher 2011-03-29 08:30:16 PDT --- (In reply to comment #18) > Oh, well, that patch only concerns rs600, right? So no point in that... That rs600 code is shared by r5xx-r7xx (same regs on all asics in that range), so it applies to your card. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 15112] Radeon KMS on RV250 gets wrong refresh rate.
https://bugzilla.kernel.org/show_bug.cgi?id=15112 Joe Kowalski changed: What|Removed |Added Status|NEW |RESOLVED Resolution||OBSOLETE --- Comment #13 from Joe Kowalski 2011-03-29 16:00:40 --- Finally got around to upgrading that machine to 2.6.38, and KMS now sets a proper mode. -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[RFC] drm platform multi-device support
From: Rob Clark
Include the minor device id in the bus-id to give userspace a way to open
the correct "cardN" when there are multiple device instances.
---
It may seem a bit strange to have multiple platform device instances, but
we have a use-case for this. And this relatively simple patch does the
trick.
drivers/gpu/drm/drm_ioctl.c |5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/drivers/gpu/drm/drm_ioctl.c b/drivers/gpu/drm/drm_ioctl.c
index 47db4df..075024b 100644
--- a/drivers/gpu/drm/drm_ioctl.c
+++ b/drivers/gpu/drm/drm_ioctl.c
@@ -165,14 +165,15 @@ static int drm_set_busid(struct drm_device *dev, struct
drm_file *file_priv)
drm_unset_busid(dev, master);
if (drm_core_check_feature(dev, DRIVER_USE_PLATFORM_DEVICE)) {
- master->unique_len = 10 + strlen(dev->platformdev->name);
+ master->unique_len = 13 + strlen(dev->platformdev->name);
+ master->unique_size = master->unique_len;
master->unique = kmalloc(master->unique_len + 1, GFP_KERNEL);
if (master->unique == NULL)
return -ENOMEM;
len = snprintf(master->unique, master->unique_len,
- "platform:%s", dev->platformdev->name);
+ "platform:%s:%02d", dev->platformdev->name,
dev->primary->index);
if (len > master->unique_len) {
DRM_ERROR("Unique buffer overflowed\n");
--
1.7.1
gallium softpipe driver build instructions.
Hi All, Am using Mesa 7.8.2. Can anyone please send out the instructions to building a gallium based softpipe driver? thanks K
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse: > 2011/3/29 r6144 : > > ? 2011-03-29?? 10:22 -0400?Jerome Glisse??? > > > >> Killer solution would be to have no mapping and a decent > >> upload/download ioctl that can take userpage. > > > > Doesn't this sound like GEM's read/write interface implemented by e.g. > > the i915 driver? But if I understand correctly, a mmap-like interface > > should still be necessary if we want to implement e.g. glMapBuffer() > > without extra copying. > > > > r6144 > > > > > glMapBuffer should not be use, it's really not a good way to do stuff. > Anyway the extra copy might be unavoidable given that sometime the > front/back might either be in unmappable vram or either have memory > layout that is not the one specify at buffer creation (this is very > common when using tiling for instance). So even considering MapBuffer > or a like function i believe it's a lot better to not allow buffer > mapping in userspace but provide upload/download hooks that can use > userpage to avoid as much as possible extra copy. > > Cheers, > Jerome > Wouldn't this give us a performance penalty for short lived resources like vbo's which are located in GART memory? Mmap allows us to write directly to this drm controlled portion of sysram. With a copy based implementation we would have to allocate the buffer in sysram just to copy it over to another portion of sysram which seems a little insane to me, but I'm not an expert here. -- Lucas
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 2:01 PM, Lucas Stach wrote: > Am Dienstag, den 29.03.2011, 11:23 -0400 schrieb Jerome Glisse: >> 2011/3/29 r6144 : >> > ? 2011-03-29?? 10:22 -0400?Jerome Glisse??? >> > >> >> Killer solution would be to have no mapping and a decent >> >> upload/download ioctl that can take userpage. >> > >> > Doesn't this sound like GEM's read/write interface implemented by e.g. >> > the i915 driver? ?But if I understand correctly, a mmap-like interface >> > should still be necessary if we want to implement e.g. glMapBuffer() >> > without extra copying. >> > >> > r6144 >> > >> > >> glMapBuffer should not be use, it's really not a good way to do stuff. >> Anyway the extra copy might be unavoidable given that sometime the >> front/back might either be in unmappable vram or either have memory >> layout that is not the one specify at buffer creation (this is very >> common when using tiling for instance). So even considering MapBuffer >> or a like function i believe it's a lot better to not allow buffer >> mapping in userspace but provide upload/download hooks that can use >> userpage to avoid as much as possible extra copy. >> >> Cheers, >> Jerome >> > > Wouldn't this give us a performance penalty for short lived resources > like vbo's which are located in GART memory? Mmap allows us to write > directly to this drm controlled portion of sysram. With a copy based > implementation we would have to allocate the buffer in sysram just to > copy it over to another portion of sysram which seems a little insane to > me, but I'm not an expert here. > > -- Lucas Short lived & small bo would definitly doesn't work well for this kind of API, it would all be a function of the ioctl cost. But i am not sure the drawback would be that big, intel tested with pread/pwrite and gived up don't remember why. For the vbo case you describe the scheme i was thinking would be : allocate bo and on buffer data call upload to the allocated bo using the bind user page feature that would mean zero extra copy operation. For the fire forget case of vbo, likely somekind of transient buffer would be more appropriate. Cheers, Jerome
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: > Short lived & small bo would definitly doesn't work well for this kind > of API, it would all be a function of the ioctl cost. But i am not > sure the drawback would be that big, intel tested with pread/pwrite > and gived up don't remember why. For the vbo case you describe the > scheme i was thinking would be : allocate bo and on buffer data call > upload to the allocated bo using the bind user page feature that would > mean zero extra copy operation. For the fire forget case of vbo, > likely somekind of transient buffer would be more appropriate. Just to clarify: Uploads to linear buffers are all done with pwrite (due to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how much faster that is: Switching vbo's from mmpa to pwrite has given a few percent more fps in openarena in i915g! As long as the chunk you're gonna write fits into L1 cache, it's probably a net win. -Daniel -- Daniel Vetter Mail: daniel at ffwll.ch Mobile: +41 (0)79 365 57 48
GEM-related desktop sluggishness due to linear-time arch_get_unmapped_area_topdown()
On Tue, Mar 29, 2011 at 4:26 PM, Daniel Vetter wrote: > On Tue, Mar 29, 2011 at 03:45:34PM -0400, Jerome Glisse wrote: >> Short lived & small bo would definitly doesn't work well for this kind >> of API, it would all be a function of the ioctl cost. But i am not >> sure the drawback would be that big, intel tested with pread/pwrite >> and gived up don't remember why. For the vbo case you describe the >> scheme i was thinking would be : allocate bo and on buffer data call >> upload to the allocated bo using the bind user page feature that would >> mean zero extra copy operation. For the fire forget case of vbo, >> likely somekind of transient buffer would be more appropriate. > > Just to clarify: Uploads to linear buffers are all done with pwrite (due > to an api foobar, it's not so great for 2d/tiled stuff). It's amazing how > much faster that is: Switching vbo's from mmpa to pwrite has given a few > percent more fps in openarena in i915g! As long as the chunk you're gonna > write fits into L1 cache, it's probably a net win. > -Daniel What i had in mind was something little bit more advance that pwrite, somethings that would take width,height,pitch of userpage and would be able to perform proper blit. But yes pwrite in intel is kind of limited. Cheers, Jerome
[Bug 28622] radeon video lockup
https://bugzilla.kernel.org/show_bug.cgi?id=28622 --- Comment #8 from Florian Mickler 2011-03-29 21:13:02 --- Is this still a problem on 2.6.38.y / 2.6.39-rc* ? -- Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar -- ___ Dri-devel mailing list Dri-devel at lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 35483] util_blit_pixels_writemask: crash in line 322 of src/gallium/auxiliary/util/u_blit.c
https://bugs.freedesktop.org/show_bug.cgi?id=35483 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #3 from Marek Ol??k 2011-03-29 15:53:57 PDT --- Fixed by Henri's commit 5d7c27f5ec2f30c264dc2d53c4980970b3a13ee5. I am cherry-picking it to the 7.9 and 7.10 branches. Closing. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34217] [r300g] Unigine Sanctuary: no fog visible
https://bugs.freedesktop.org/show_bug.cgi?id=34217 Marek Ol??k changed: What|Removed |Added Status|NEW |RESOLVED Resolution||NOTOURBUG --- Comment #1 from Marek Ol??k 2011-03-29 16:52:51 PDT --- The fog is rendered correctly with the floating2 branch, and Unigine Sanctuary does use floating-point textures. This is what is printed during loading: Mesa: User error: GL_INVALID_VALUE in glTexImage2D(internalFormat=GL_RGBA16F) The game is clearly using float textures and doesn't check for the extension. Closing as NOT-OUR-BUG. Thanks for the info anyway. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 34206] [r300g] Unigine Sanctuary: glow around fires is distorted and displaced
https://bugs.freedesktop.org/show_bug.cgi?id=34206 --- Comment #7 from Marek Ol??k 2011-03-29 16:59:52 PDT --- I think the glow is broken because the WPOS input is unassigned. Glow is a screen-space effect and as such must either use (or emulate) gl_FragCoord. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)
https://bugs.freedesktop.org/show_bug.cgi?id=33790 --- Comment #2 from Marek Ol??k 2011-03-29 17:04:28 PDT --- Can you set this environment variable: RADEON_THREAD=0 and try again? -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
[Bug 33790] [r300g] Black windows with opengl apps (ex. glxgears)
https://bugs.freedesktop.org/show_bug.cgi?id=33790 --- Comment #3 from Marek Ol??k 2011-03-29 17:08:49 PDT --- (In reply to comment #2) > Can you set this environment variable: > > RADEON_THREAD=0 > > and try again? Please, ignore this. I forgot there is no thread offloading in 7.10. -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
gallium softpipe driver build instructions.
Can someone please help out with the instructions. thx K On Tue, 2011-03-29 at 10:34 -0700, kumar vemuri wrote: > Hi All, > > Am using Mesa 7.8.2. Can anyone please send out the instructions > to building a gallium based softpipe driver? > > thanks > K > >
[Bug 35697] System locks up when watching fullscreen flash video
https://bugs.freedesktop.org/show_bug.cgi?id=35697 --- Comment #20 from Christophe Saout 2011-03-29 23:43:09 PDT --- Applied that patch to my kernel yesterday and just experienced the issue again. Killed compiz, X went on, but GL is unusable. If I run e.g. glxgears, the application doesn't draw anything, but is still running and seems to be waiting for something from the X server. Closing the window results in some error "34" IIRC (I can write down the exact error next time if it helps). -- Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug.
