[Bug 22372] radeon_mipmap_tree.c:114: compute_tex_image_offset: Assertion `lvl-size 0' failed.
http://bugs.freedesktop.org/show_bug.cgi?id=22372 --- Comment #12 from Andrew Belitsky belitsk...@gmail.com 2009-12-30 00:21:19 PST --- There is no error anymore with mesa 7.7. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25346] kwin extraneous transparent boxes
http://bugs.freedesktop.org/show_bug.cgi?id=25346 Alex Deucher ag...@yahoo.com changed: What|Removed |Added CC||hansmbak...@gmail.com --- Comment #3 from Alex Deucher ag...@yahoo.com 2009-12-30 01:21:00 PST --- *** Bug 25825 has been marked as a duplicate of this bug. *** -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote: On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote: Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto: 2009/12/28 Luca Tettamanti kronos...@gmail.com: On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote: 2009/12/28 Luca Tettamanti kronos...@gmail.com: 2009/12/28 Alex Deucher alexdeuc...@gmail.com: On Mon, Dec 28, 2009 at 5:53 AM, Luca Tettamanti kronos...@gmail.com wrote: On Sun, Dec 27, 2009 at 1:55 AM, Rafał Miłecki zaj...@gmail.com wrote: W dniu 26 grudnia 2009 20:08 użytkownik Alex Deucher alexdeuc...@gmail.com napisał: It may be that the engine doesn't like to be reclocked while it's running. Perhaps we should use the GUI idle interrupt rather than vblanks to reclock the engine. Could you say something more about GUI idle interrupt, please? It's mentioned in the documentation of the IH (see r600.c); I guess it's enabled by GUI_IDLE_INT_ENABLE. What is this, do we already have code for that? Unless there are more subtleties all is needed it to enabled the interrupt and catch it in r600_irq_process. That's pretty much it. Pre-r6xx asics have a GUI interrupt as well. I can look up the details for that if they are not already documented. I can't find a way to ack the interrupt; I see RADEON_GUI_IDLE_INT_TEST_ACK but I think it's for pre-r6xx cards, right? You don't have to ACK it as the CP generates the interrupt in software; similar to the sw interrupts used for fences. Ok, good: I've got the stub running on my M76. r100 and rs600 parts are untested. Comments? Looks pretty good. I've included the proper defines from the register database below and you'll need to ack the gui idle interrupts on pre-r600 chips. Now you just have to do something when you get the idle interrupt. I've adapted Rafał's patch to do the reclock when the idle interrupt is fired (which btw should take care of the special case for nr CRTCs 1). Unfortunately I still see the black frame when reclocking is performed. So I tried recloking directly from the IH (yeah, I'm ashamed of myself...); this got rid of the black frame, but causes corruption of a horizontal block of the screen (during the reclock, before and after the screen looks fine). If you mean the interrupt handler for the idle interrupt, Yes. have you tried doing it in the interrupt handler for the vblank interrupt instead? Not yet; I've tried a solution similar to what Xavier suggested: lock the ring, wait for idle, reclock (outside the IH), unlock and it still causes corruption (but not the black frame). The next iteration would be: lock cp wait for idle enable vblank wait for vlbank relock unlock cp With reclock that might be moved to the vblank interrupt if it still causes problems. Sounds sensible? This approach however reintroduces the issue with multiple active crtcs... Luca -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14963] New: no connectors detected when KMS is enabled on r100
http://bugzilla.kernel.org/show_bug.cgi?id=14963 Summary: no connectors detected when KMS is enabled on r100 Product: Drivers Version: 2.5 Kernel Version: 2.6.33-rc2 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: farb...@web.de Regression: No Created an attachment (id=24378) -- (http://bugzilla.kernel.org/attachment.cgi?id=24378) dmesg with KMS enabled Booting with KMS enabled results in the VGA connector not being detected. It works fine if I disable KMS or use radeonfb: [0.336653] radeonfb: Found Intel x86 BIOS ROM Image [0.336697] radeonfb: Retrieved PLL infos from BIOS [0.336740] radeonfb: Reference=27.00 MHz (RefDiv=60) Memory=183.00 Mhz, System=183.00 MHz [0.336792] radeonfb: PLL min 12000 max 35000 [0.337063] radeonfb: No connector info table detected [0.469522] i2c i2c-1: unable to read EDID block. [0.689500] i2c i2c-1: unable to read EDID block. [0.909486] i2c i2c-1: unable to read EDID block. [1.230009] radeonfb: Monitor 1 type CRT found [1.230051] radeonfb: EDID probed [1.269614] Console: switching to colour frame buffer device 128x48 [1.278977] radeonfb (:02:00.0): ATI Radeon 5144 QD X.Org detects the card as: (--) PCI:*(0:2:0:0) 1002:5144:1002:001a ATI Technologies Inc Radeon R100 QD [Radeon 7200] rev 0, Mem @ 0xd000/134217728, 0xdd00/524288, I/O @ 0xc000/256, BIOS @ 0x/131072 -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25833] New: Rendering stops, maybe clipping problem.
http://bugs.freedesktop.org/show_bug.cgi?id=25833 Summary: Rendering stops, maybe clipping problem. Product: DRI Version: DRI CVS Platform: Other OS/Version: All Status: NEW Severity: normal Priority: medium Component: DRM/Radeon AssignedTo: dri-devel@lists.sourceforge.net ReportedBy: kmakaro...@gmail.com Created an attachment (id=32377) -- (http://bugs.freedesktop.org/attachment.cgi?id=32377) Origin outside visibile area from the top. Linux 2.6.32 libgl 7.7 xf86-video-ati 6.12.4 libdrm 2.4.17 Using glxgears as benchmark..yes I know it is not really. In non compositing environment, when glxgears window origin is moved out of current desktop(left and up coordinates), rendering stops (shows last rendered frame, clipped with the window border of-course) frames go high ~4500 as of my hardware RS780(full window visible ~ 1900FPS). On the other hand, when the glxgears window is under other window, entirely, frames drop down to ~100. When simultaneously origin outside desktop and covered by window entirely FPS are ~100 too. In compositing environment, when moving window with GL context, window moves (content black), but GL rendering context stays(and continue to render) on the old place, above any windows. When I finish the move, then it moves in to GL window as usual. When the window origin is moved beyond desktop dimensions, window content stays black. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 25833] Rendering stops, maybe clipping problem.
http://bugs.freedesktop.org/show_bug.cgi?id=25833 --- Comment #1 from Drago kmakaro...@gmail.com 2009-12-30 07:56:55 PST --- Now I saw, that on the attachment besides glxgears, on unrefreshed area there is a screen from game Nexuiz, I tested 2 hours ago. Maybe this can help too. -- Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are the assignee for the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
[Bug 14910] Stable version 2.6.32.2 broke my KMS Radeon setup
http://bugzilla.kernel.org/show_bug.cgi?id=14910 --- Comment #3 from Rafael J. Wysocki r...@sisk.pl 2009-12-30 21:44:40 --- On Wednesday 30 December 2009, Ruud Linders wrote: On 12/29/2009 04:09 PM, Rafael J. Wysocki wrote: This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.32. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=14910 Subject : Stable version 2.6.32.2 broke my KMS Radeon setup Submitter : Ruud Linders kerne...@xs4all.nl Date: 2009-12-20 12:02 (10 days old) References : http://marc.info/?l=linux-kernelm=126131105608871w=4 ... This one can be closed as it's not an 2.6.33 issue (I'm running 2.6.33-rc1 with KMS just fine) See also http://patchwork.kernel.org/patch/69076/ for stable patch to fix it in 2.6.32.3. -- Configure bugmail: http://bugzilla.kernel.org/userprefs.cgi?tab=email --- You are receiving this mail because: --- You are watching the assignee of the bug. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm: gem_object_free without struct_mutex
[CC to Jesse.] On Wednesday 30 December 2009, Hugh Dickins wrote: I've changed BUG_ON to WARN_ON in drm_gem.c (patch at bottom) to get this dmesg when I resume after suspend, instead of crashing. Perhaps it's a patch that should go in, perhaps not, but obviously the real problem lies elsewhere. Happens with 2.6.33-rc1 and -rc2. No surprise if I'm stupidly misconfigured to get the pin power context error in the first place (.config on demand), but I don't deserve to BUG! Hugh [drm:intel_init_clock_gating] *ERROR* failed to pin power context: -16 [ cut here ] WARNING: at drivers/gpu/drm/drm_gem.c:438 drm_gem_object_free+0x20/0x5e() Hardware name: ESPRIMO Mobile V5505 Modules linked in: snd_pcm_oss snd_mixer_oss snd_seq snd_seq_device Pid: 3793, comm: s2ram Not tainted 2.6.33-rc2 #4 Call Trace: [7815298e] warn_slowpath_common+0x59/0x6b [781529b3] warn_slowpath_null+0x13/0x18 [78317c1a] ? drm_gem_object_free+0x20/0x5e [78317c1a] drm_gem_object_free+0x20/0x5e [78317bfa] ? drm_gem_object_free+0x0/0x5e [7829df11] kref_put+0x38/0x45 [7833a5f0] intel_init_clock_gating+0x232/0x271 [78317bfa] ? drm_gem_object_free+0x0/0x5e [7832c307] i915_restore_state+0x21a/0x2b3 [7832379d] i915_resume+0x3c/0xbb [78174fe5] ? trace_hardirqs_on_caller+0xfc/0x123 [7831c756] ? drm_class_resume+0x0/0x3e [7831c78d] drm_class_resume+0x37/0x3e [78351e0a] legacy_resume+0x1e/0x51 [78351ece] device_resume+0x91/0xab [7831c756] ? drm_class_resume+0x0/0x3e [78352226] dpm_resume+0x58/0x10f [783522fb] dpm_resume_end+0x1e/0x2c [78180f80] suspend_devices_and_enter+0x61/0x84 [78180ff8] enter_state+0x55/0x83 [7818091c] state_store+0x94/0xaa [7829d09e] kobj_attr_store+0x1e/0x23 [782098e0] sysfs_write_file+0x66/0x99 [781cd2f0] vfs_write+0x8a/0x108 [781cd408] sys_write+0x3c/0x63 [78125c10] sysenter_do_call+0x12/0x36 ---[ end trace a343537f29950fda ]--- [PATCH] gem: free just WARN_ON(!mutex_is_locked) drm_gem_object_free() WARN_ON(!mutex_is_locked) instead of BUG_ON: i915_resume()-i915_restore_state()-intel_init_clock_gating() is currently causing it to trigger with my config. Signed-off-by: Hugh Dickins hugh.dick...@tiscali.co.uk --- drivers/gpu/drm/drm_gem.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 2.6.33-rc2/drivers/gpu/drm/drm_gem.c 2009-12-03 03:51:21.0 + +++ linux/drivers/gpu/drm/drm_gem.c 2009-12-26 18:29:57.0 + @@ -435,7 +435,7 @@ drm_gem_object_free(struct kref *kref) struct drm_gem_object *obj = (struct drm_gem_object *) kref; struct drm_device *dev = obj-dev; - BUG_ON(!mutex_is_locked(dev-struct_mutex)); + WARN_ON(!mutex_is_locked(dev-struct_mutex)); if (dev-driver-gem_free_object != NULL) dev-driver-gem_free_object(obj); -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev -- ___ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
Re: drm/radeon/kms: pm: single frame corruptions on reclocking
On Wed, Dec 30, 2009 at 10:56 AM, Luca Tettamanti kronos...@gmail.com wrote:
On Wed, Dec 30, 2009 at 08:03:53AM +0100, Michel Dänzer wrote:
On Tue, 2009-12-29 at 19:35 +0100, Luca Tettamanti wrote:
Il Mon, Dec 28, 2009 at 05:27:13PM -0500, Alex Deucher ha scritto:
2009/12/28 Luca Tettamanti kronos...@gmail.com:
On Mon, Dec 28, 2009 at 01:32:24PM -0500, Alex Deucher wrote:
Looks pretty good. I've included the proper defines from the register
database below and you'll need to ack the gui idle interrupts on
pre-r600 chips. Now you just have to do something when you get the
idle interrupt.
I've adapted Rafał's patch to do the reclock when the idle interrupt is
fired (which btw should take care of the special case for nr CRTCs 1).
Unfortunately I still see the black frame when reclocking is performed.
So I tried recloking directly from the IH (yeah, I'm ashamed of
myself...); this got rid of the black frame, but causes corruption of a
horizontal block of the screen (during the reclock, before and after the
screen looks fine).
If you mean the interrupt handler for the idle interrupt,
Yes.
have you tried
doing it in the interrupt handler for the vblank interrupt instead?
Not yet; I've tried a solution similar to what Xavier suggested: lock the
ring,
wait for idle, reclock (outside the IH), unlock and it still causes corruption
(but not the black frame).
The next iteration would be:
lock cp
wait for idle
enable vblank
wait for vlbank
relock
unlock cp
With reclock that might be moved to the vblank interrupt if it still causes
problems. Sounds sensible?
I still see corruption... this is what I'm doing:
driver decides to reclock
take cp.mutex
wait_event(gui_idle)
idle interrupt {
set idle flag
wake_up()
}
drm_vblank_get
vblank interrupt {
reclock()
}
drm_vblank_put
release cp.mutex
-ENOIDEA
Luca
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
--
___
Dri-devel mailing list
Dri-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dri-devel
