[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #6 from Eugene Shalygin --- The same crash happens time to time when maximizing application windows -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/860eb4d6/attachment.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with HD6450 and 3.8.1 kernel
https://bugs.freedesktop.org/show_bug.cgi?id=61747 Chris Rankin changed: What|Removed |Added Summary|[r600g] GPU lockup when |[r600g] GPU lockup when |playing WoW with 3.8.1 |playing WoW with HD6450 and |kernel. |3.8.1 kernel -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/f85e82fe/attachment.html>
[RFC][PATCH 00/30] staging: Android sync driver
On Fri, Mar 1, 2013 at 1:42 AM, John Stultz wrote: > As proposed yesterday, here's the Android sync driver patches for > staging. > > I've preserved the commit history, but moved all the changes over > to be against the staging directory (instead of drivers/base). > > > The goal of submitting this driver to staging is to try to get > more collaberation, as there are some similar efforts going on > in the community with dmabuf-fences. My email from yesterday with > more details for how I hope this goes is here: > http://comments.gmane.org/gmane.linux.kernel/1448420 I've been offline in a week of snowboarding, but I'll throw my late Ack - I've discussed this a bit with John offline and I agree with his general plan for integrating android sync points into mainline. > Erik also provided a nice background on the patch set in his > reply yesterday, which I'll quote here: > > "In Honeycomb where we introduced the Hardware Composer HAL. This is a > userspace layer that allows composition acceleration on a per platform > basis. Different SoC vendors have implemented this using overlays, 2d > blitters, a combinations of both, or other clever/disgusting means. > Along with the HWC we consolidated a lot of our camera and media > pipeline to allow their input to be fed into the GPU or > display(overlay.) In order to exploit parallelism the the graphics > pipeline, this introduced lots of implicit synchronization > dependancies. After a couple years of working with many different SoC > vendors, we found that it was really difficult to communicate our > system's expectations of the implicit contract and it was difficult > for the SoC vendors to properly implement the implicit contract in > each of their IP blocks (display, gpu, camera, video codecs). It was > also incredibly difficult to debug when problems/deadlocks arose. dma_buf fences should be tons easier to debug thanks to integration with lockdep. Also their design fundamentally excludes deadlock-loops in the fences themselves. And I also think that we should be able to hide the complexity from most drivers in e.g. drm/ttm or the v2l core. So I'm still bullish on implicit fencing (and will keep on pushing that for all things intel). But I guess the simpler programming model afforded by that for userspace isn't of much use for the google guys now that they've pushed the effort to convert SurfaceFlinger to explicit fence handling ... Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 5:39 AM, Linus Torvalds
wrote:
> On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie wrote:
>>
>> Highlights:
>>
>> i915: all over the map, haswell power well enhancements, valleyview macro
>> horrors cleaned up, killing lots of legacy GTT
>> code,
>
> Lowlight:
>
> There's something wrong with i915 DP detection or whatever. I get
> stuff like this:
>
> [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not
> signal timeout (has irq: 1)!
> [5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
> .
> [8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status
> 0xa145003f
I have the same messages after upgrading up to
b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50
But in my case when I reboot computer the second monitor, that plugged
via HDMI, didn't works, end when I run `xrandr`, I have next messages
in kern.log
Mar 3 18:09:15 home-spb kernel: [12321.758273] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
Mar 3 18:09:15 home-spb kernel: [12321.771715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.782712]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.793715]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.804719]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.815725]
[drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout
(has irq: 1)!
Mar 3 18:09:15 home-spb kernel: [12321.817293] [drm:intel_dp_aux_ch]
*ERROR* dp_aux_ch not done status 0xa143003f
# lspci | fgrep -i graph
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation
Core Processor Family Integrated Graphics Controller (rev 09)
I tested some commits, and here the results:
- Breaked at v3.8-10206-gb0af9cd
- Works normal v3.8-rc3-139-g34f2be4
- Works normal v3.8-rc3-188-g10aa17c
- Works normal 6dc1c49
I've tested 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch and it
works for me.
Thank, Dave.
>
> and after that the screen ends up black.
>
> It's happened twice now, but is not 100% repeatable. It looks like the
> message itself is new, but the black screen is also new and does seem
> to happen when I get the message, so...
>
> The second time I touched the power button, and the machine came back.
> Apparently the suspend/resume cycle made it all magically work: the
> suspend caused the same errors, but then the resume made it all good
> again.
>
> Some kind of missed initialization at bootup? It's not reliable enough
> to bisect, but I obviously suspect commit 9ee32fea5fe8 ("drm/i915:
> irq-drive the dp aux communication") since that is where the message
> was added..
>
> Btw, looking at that commit, what do you think the semantics of the
> timeout in something like
>
> done = wait_event_timeout(dev_priv->gmbus_wait_queue, C, 10);
>
> would be? What's that magic "10"? It's some totally random number.
>
> Guys, it should be something meaningful. If you meant a tenth of a
> second, use HZ/10 or something. Because just the plain "10" is crazy.
> I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a
> hundreth of a second. Was that what you intended? Because if it was,
> it is still crap, since CONFIG_HZ might be 100, and then you're
> waiting for ten times longer.
>
> IOW, passing in a random number like that is crazy. It cannot possibly
> be right.
>
> I have no idea whether the timeout has anything to do with anything,
> but it reinforces my suspicion that there is something wrong with that
> commit.
>
>Linus
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo at vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Respectfully
Azat Khuzhin
Primary email a3at.mail at gmail.com
[Intel-gfx] [PATCH 3/8] drm/i915: Added SDP and VSC structures for handling PSR for eDP
On Mon, Feb 25, 2013 at 07:55:17PM -0300, Rodrigo Vivi wrote:
> From: Shobhit Kumar
>
> Signed-off-by: Sateesh Kavuri
>
> v2: Modified and corrected the structures to be more in line for
> kernel coding guidelines and rebased the code on Paulo's DP patchset
>
> Signed-off-by: Shobhit Kumar
>
> v3: removing unecessary identation at DP_RECEIVER_CAP_SIZE
> v4: moving them to include/drm/drm_dp_helper.h and also already
> icluding EDP_PSR_RECEIVER_CAP_SIZE to add everything needed
> for PSR at once at drm_dp_helper.h
>
> Signed-off-by: Rodrigo Vivi
Bikeshed for your patch headlines: You still have drm/i915 there, despite
that the #defines and structures are now moved to the drm core dp helpers.
Non-Intel people might simply ignore the patches in that case.
-Daniel
> ---
> include/drm/drm_dp_helper.h | 22 ++
> 1 file changed, 22 insertions(+)
>
> diff --git a/include/drm/drm_dp_helper.h b/include/drm/drm_dp_helper.h
> index e8e1417..06c5060 100644
> --- a/include/drm/drm_dp_helper.h
> +++ b/include/drm/drm_dp_helper.h
> @@ -343,12 +343,34 @@ u8 drm_dp_get_adjust_request_pre_emphasis(u8
> link_status[DP_LINK_STATUS_SIZE],
> int lane);
>
> #define DP_RECEIVER_CAP_SIZE 0xf
> +#define EDP_PSR_RECEIVER_CAP_SIZE 2
> +
> void drm_dp_link_train_clock_recovery_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
> void drm_dp_link_train_channel_eq_delay(u8 dpcd[DP_RECEIVER_CAP_SIZE]);
>
> u8 drm_dp_link_rate_to_bw_code(int link_rate);
> int drm_dp_bw_code_to_link_rate(u8 link_bw);
>
> +/* SDP header as per eDP 1.3 spec, section 3.6 */
> +struct edp_sdp_header {
> + u8 id;
> + u8 type;
> + u8 revision;
> + u8 valid_payload_bytes;
> +} __attribute__((packed));
> +
> +/* SDP VSC header as per eDP 1.3 spec, section 3.6 */
> +struct edp_vsc_psr {
> + struct edp_sdp_header sdp_header;
> + u8 DB1; /* 0 - PSR State; 1 - Update RFB; 2 - CRC Valid*/
> + u8 DB2; /* CRC value bits 7:0 of the R or Cr component */
> + u8 DB3; /* CRC value bits 15:8 of the R or Cr component */
> + u8 DB4; /* CRC value bits 7:0 of the G or Y component */
> + u8 DB5; /* CRC value bits 15:8 of the G or Y component */
> + u8 DB6; /* CRC value bits 7:0 of the B or Cb component */
> + u8 DB7; /* CRC value bits 15:8 of the B or Cb component */
> +} __attribute__((packed));
> +
> static inline int
> drm_dp_max_link_rate(u8 dpcd[DP_RECEIVER_CAP_SIZE])
> {
> --
> 1.8.1.2
>
> ___
> Intel-gfx mailing list
> Intel-gfx at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/intel-gfx
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Intel-gfx] [PATCH 2/8] drm/i915: Use cpu_transcoder for HSW_TVIDEO_DIP_* instead of pipe
On Wed, Feb 27, 2013 at 04:44:59PM -0300, Paulo Zanoni wrote: > Hi > > 2013/2/25 Rodrigo Vivi : > > While old platforms had 3 transcoders and 3 pipes (1:1), HSW has > > 4 transcoders and 3 pipes. > > These regs were being used only by HDMI code where pipe is always the same > > thing as cpu_transcoder. > > This patch allow us to use them for DP, specially for TRANSCODER_EDP. > > > > v2: Adding HSW_TVIDEO_DIP_VSC_DATA to transmit vsc to eDP. > > > > Signed-off-by: Rodrigo Vivi > > Reviewed-by: Paulo Zanoni Queued for -next, thanks for the patch. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[PATCH] drm/i915: Fix missing variable initilization
On Mon, Feb 25, 2013 at 04:05:38AM +0530, Syam Sidhardhan wrote:
> Need to initialize the variable wait to false.
>
> Signed-off-by: Syam Sidhardhan
Looks sane, thanks for the patch. Cc'ing Paulo in case I've missed
something.
-Daniel
> ---
> drivers/gpu/drm/i915/intel_ddi.c |2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/gpu/drm/i915/intel_ddi.c
> b/drivers/gpu/drm/i915/intel_ddi.c
> index fc95ef0..5d0a687 100644
> --- a/drivers/gpu/drm/i915/intel_ddi.c
> +++ b/drivers/gpu/drm/i915/intel_ddi.c
> @@ -1391,8 +1391,8 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
> *encoder)
> struct intel_dp *intel_dp = _dig_port->dp;
> struct drm_i915_private *dev_priv = encoder->dev->dev_private;
> enum port port = intel_dig_port->port;
> - bool wait;
> uint32_t val;
> + bool wait = false;
>
> if (I915_READ(DP_TP_CTL(port)) & DP_TP_CTL_ENABLE) {
> val = I915_READ(DDI_BUF_CTL(port));
> --
> 1.7.9.5
>
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
A patch referencing this bug report has been merged...
On Sat, Mar 02, 2013 at 07:35:45PM +0100, Florian Mickler wrote: > On Wed, 30 Jan 2013 11:14:01 +0200 > Jani Nikula wrote: > > > > > Hi Florian, all - > > > > First, thanks for your work on adding the bugzilla comments when patches > > referencing bugs get merged. I find it useful. > > > > Recently however there was a comment about a commit referencing a commit > > referencing the bug report. Turns out the comment was missing one level > > of indirection, it was really about a commit referencing a commit > > referencing a commit referencing the bug [1]. > > > > Do we really need go that far, or is that a bug in your scripts? I think > > three levels of indirection is more noise than signal; two might be > > still be okay. What do others think? > > > > BR, > > Jani. > > > > > > [1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56 > > Is it really a problem? I can change it of course, but I doubt it is > worth the hassle. At the moment I just record sha1 -> bug associations > and if in a commit message, the mentioned (full!) sha1 is associated to > a bug, I associate that commit with that bug. > > If someone goes to the trouble to actually mention the sha1 in a > commit message, that probably means it really is an important > connection. > And if that commit is associated with a bug, then that should mean > something too. > > Think about multiple attempts to fix a bug which get always reverted > because the hardware is really acting up in different ways with every > attempt... > > As it is, I don't think it is worth the trouble. If you feel strongly > about the message, I can reword it to be somewhat unspecific about the > level of indirection... what do you think? I think the multiple-indirection bug entries are ok, and could indeed be useful to stitch together the story of a bug (or help us remember to reopen a bug if we need to revert a patch). I guess drm/i915 hit a few more of those than other people since we're always citing commits in full (we paste --pretty=short into commit messages). And we also tend to cite a lot of commits, sometimes mentioning all relevant changes to the code in the past few years ;-) Together with our tendecy to track all bug reports in bugzilla that leads to the oddball useless commit entry in a bug. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch
[Bug 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #4 from Chris Rankin --- After a reboot, the new glxinfo reports: OpenGL vendor string: X.Org OpenGL renderer string: Gallium 0.4 on AMD CAICOS OpenGL version string: 3.0 Mesa 9.2-devel (git-0b6e72f) OpenGL shading language version string: 1.30 I am guessing that it switched to swrast_dri after it failed to recover from the GPU lockup correctly. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/55b86848/attachment-0001.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #3 from Chris Rankin --- WTF? According to glxinfo, it's not using r600g at all...?!?! $ LIBGL_DEBUG=verbose LD_LIBRARY_PATH=/usr/local/lib64 glxinfo name of display: :1 libGL: screen 0 does not appear to be DRI2 capable libGL: OpenDriver: trying /usr/local/lib64/dri/swrast_dri.so libGL error: dlopen /usr/local/lib64/dri/swrast_dri.so failed (/usr/local/lib64/dri/swrast_dri.so: cannot open shared object file: No such file or directory) libGL error: unable to load driver: swrast_dri.so libGL error: failed to load driver: swrast display: :1 screen: 0 direct rendering: No (If you want to find out why, try setting LIBGL_DEBUG=verbose) OpenGL vendor string: VMware, Inc. OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301) OpenGL version string: 1.4 (2.1 Mesa 9.0.1) It can't find swrast_dri.so because I didn't compile it, but r600g_dri.so is definitely there! Fedora's gnome-shell process has suspiciously switched to swrast_dri.so too. I have no idea what has just happened. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/a366c5fe/attachment.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #2 from Chris Rankin --- I have successfully played WoW using this exact same version of Mesa and a stock x86_64 3.8.1 kernel with my RV790. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/a6d42135/attachment.html>
[Bug 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #1 from Chris Rankin --- Created attachment 75853 --> https://bugs.freedesktop.org/attachment.cgi?id=75853=edit Xorg.0.log file from the failed session. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/04875189/attachment.html>
[Bug 61747] New: [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 Priority: medium Bug ID: 61747 Assignee: dri-devel at lists.freedesktop.org Summary: [r600g] GPU lockup when playing WoW with 3.8.1 kernel. Severity: major Classification: Unclassified OS: Linux (All) Reporter: rankincj at googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 75852 --> https://bugs.freedesktop.org/attachment.cgi?id=75852=edit dmesg output, showing lockup and failed reset. Playing WoW on Fedora's kernel-3.8.1-201.fc18.x86_64, and the GPU locked up moments later. A GPU reset did not succeed in restoring anything, and I was forced to "kill -HUP" the Xorg process from a virtual console. Mesa's git HEAD is: commit 0b6e72f8d75a31ef233ad5be0c9f59497880657f Author: Brian Paul Date: Fri Mar 1 17:36:34 2013 -0700 st/mesa: add switch case for ir_txf_ms to silence warning -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/0fa8c2c9/attachment-0001.html>
[Bug 61470] Driver does not turn on LCD backlight on resume
https://bugs.freedesktop.org/show_bug.cgi?id=61470 --- Comment #3 from webmaster at jamescobban.net --- Created attachment 75847 --> https://bugs.freedesktop.org/attachment.cgi?id=75847=edit Xorg log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/06b1ed42/attachment.html>
[Bug 61470] Driver does not turn on LCD backlight on resume
https://bugs.freedesktop.org/show_bug.cgi?id=61470 --- Comment #2 from webmaster at jamescobban.net --- Created attachment 75846 --> https://bugs.freedesktop.org/attachment.cgi?id=75846=edit DMESG log -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/1a5fe263/attachment.html>
[Bug 52549] libdrm 2.4.37 compilation fails if ETIME not defined
https://bugs.freedesktop.org/show_bug.cgi?id=52549 Francois Tigeot changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois Tigeot --- Resolved by commit 7d42b49c0cf19dbb4531cd84efae51f95db2eea1, present in libdrm-2.4.41. -- You are receiving this mail because: You are the assignee for the bug. -- next part -- An HTML attachment was scrubbed... URL: <http://lists.freedesktop.org/archives/dri-devel/attachments/20130303/418d3070/attachment.html>
[Bug 52549] libdrm 2.4.37 compilation fails if ETIME not defined
https://bugs.freedesktop.org/show_bug.cgi?id=52549 Francois Tigeot ftig...@wolfpond.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #3 from Francois Tigeot ftig...@wolfpond.org --- Resolved by commit 7d42b49c0cf19dbb4531cd84efae51f95db2eea1, present in libdrm-2.4.41. -- 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 61470] Driver does not turn on LCD backlight on resume
https://bugs.freedesktop.org/show_bug.cgi?id=61470 --- Comment #2 from webmas...@jamescobban.net --- Created attachment 75846 -- https://bugs.freedesktop.org/attachment.cgi?id=75846action=edit DMESG log -- 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 61470] Driver does not turn on LCD backlight on resume
https://bugs.freedesktop.org/show_bug.cgi?id=61470 --- Comment #3 from webmas...@jamescobban.net --- Created attachment 75847 -- https://bugs.freedesktop.org/attachment.cgi?id=75847action=edit Xorg log -- 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: A patch referencing this bug report has been merged...
On Sat, Mar 02, 2013 at 07:35:45PM +0100, Florian Mickler wrote: On Wed, 30 Jan 2013 11:14:01 +0200 Jani Nikula jani.nik...@intel.com wrote: Hi Florian, all - First, thanks for your work on adding the bugzilla comments when patches referencing bugs get merged. I find it useful. Recently however there was a comment about a commit referencing a commit referencing the bug report. Turns out the comment was missing one level of indirection, it was really about a commit referencing a commit referencing a commit referencing the bug [1]. Do we really need go that far, or is that a bug in your scripts? I think three levels of indirection is more noise than signal; two might be still be okay. What do others think? BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56 Is it really a problem? I can change it of course, but I doubt it is worth the hassle. At the moment I just record sha1 - bug associations and if in a commit message, the mentioned (full!) sha1 is associated to a bug, I associate that commit with that bug. If someone goes to the trouble to actually mention the sha1 in a commit message, that probably means it really is an important connection. And if that commit is associated with a bug, then that should mean something too. Think about multiple attempts to fix a bug which get always reverted because the hardware is really acting up in different ways with every attempt... As it is, I don't think it is worth the trouble. If you feel strongly about the message, I can reword it to be somewhat unspecific about the level of indirection... what do you think? I think the multiple-indirection bug entries are ok, and could indeed be useful to stitch together the story of a bug (or help us remember to reopen a bug if we need to revert a patch). I guess drm/i915 hit a few more of those than other people since we're always citing commits in full (we paste --pretty=short into commit messages). And we also tend to cite a lot of commits, sometimes mentioning all relevant changes to the code in the past few years ;-) Together with our tendecy to track all bug reports in bugzilla that leads to the oddball useless commit entry in a bug. Cheers, Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61747] New: [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 Priority: medium Bug ID: 61747 Assignee: dri-devel@lists.freedesktop.org Summary: [r600g] GPU lockup when playing WoW with 3.8.1 kernel. Severity: major Classification: Unclassified OS: Linux (All) Reporter: ranki...@googlemail.com Hardware: x86-64 (AMD64) Status: NEW Version: git Component: Drivers/Gallium/r600 Product: Mesa Created attachment 75852 -- https://bugs.freedesktop.org/attachment.cgi?id=75852action=edit dmesg output, showing lockup and failed reset. Playing WoW on Fedora's kernel-3.8.1-201.fc18.x86_64, and the GPU locked up moments later. A GPU reset did not succeed in restoring anything, and I was forced to kill -HUP the Xorg process from a virtual console. Mesa's git HEAD is: commit 0b6e72f8d75a31ef233ad5be0c9f59497880657f Author: Brian Paul bri...@vmware.com Date: Fri Mar 1 17:36:34 2013 -0700 st/mesa: add switch case for ir_txf_ms to silence warning -- 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 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #1 from Chris Rankin ranki...@googlemail.com --- Created attachment 75853 -- https://bugs.freedesktop.org/attachment.cgi?id=75853action=edit Xorg.0.log file from the failed session. -- 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 61747] [r600g] GPU lockup when playing WoW with 3.8.1 kernel.
https://bugs.freedesktop.org/show_bug.cgi?id=61747 --- Comment #2 from Chris Rankin ranki...@googlemail.com --- I have successfully played WoW using this exact same version of Mesa and a stock x86_64 3.8.1 kernel with my RV790. -- 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/i915: Fix missing variable initilization
On Mon, Feb 25, 2013 at 04:05:38AM +0530, Syam Sidhardhan wrote:
Need to initialize the variable wait to false.
Signed-off-by: Syam Sidhardhan s.s...@samsung.com
Looks sane, thanks for the patch. Cc'ing Paulo in case I've missed
something.
-Daniel
---
drivers/gpu/drm/i915/intel_ddi.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/i915/intel_ddi.c
b/drivers/gpu/drm/i915/intel_ddi.c
index fc95ef0..5d0a687 100644
--- a/drivers/gpu/drm/i915/intel_ddi.c
+++ b/drivers/gpu/drm/i915/intel_ddi.c
@@ -1391,8 +1391,8 @@ void intel_ddi_prepare_link_retrain(struct drm_encoder
*encoder)
struct intel_dp *intel_dp = intel_dig_port-dp;
struct drm_i915_private *dev_priv = encoder-dev-dev_private;
enum port port = intel_dig_port-port;
- bool wait;
uint32_t val;
+ bool wait = false;
if (I915_READ(DP_TP_CTL(port)) DP_TP_CTL_ENABLE) {
val = I915_READ(DDI_BUF_CTL(port));
--
1.7.9.5
--
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
[Bug 61182] r600g causes KWin crashes with kernel 3.8
https://bugs.freedesktop.org/show_bug.cgi?id=61182 --- Comment #6 from Eugene Shalygin eugene.shaly...@gmail.com --- The same crash happens time to time when maximizing application windows -- 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: A patch referencing this bug report has been merged...
On Wed, 30 Jan 2013 11:14:01 +0200 Jani Nikula jani.nik...@intel.com wrote: Hi Florian, all - First, thanks for your work on adding the bugzilla comments when patches referencing bugs get merged. I find it useful. Recently however there was a comment about a commit referencing a commit referencing the bug report. Turns out the comment was missing one level of indirection, it was really about a commit referencing a commit referencing a commit referencing the bug [1]. Do we really need go that far, or is that a bug in your scripts? I think three levels of indirection is more noise than signal; two might be still be okay. What do others think? BR, Jani. [1] https://bugs.freedesktop.org/show_bug.cgi?id=52424#c56 Is it really a problem? I can change it of course, but I doubt it is worth the hassle. At the moment I just record sha1 - bug associations and if in a commit message, the mentioned (full!) sha1 is associated to a bug, I associate that commit with that bug. If someone goes to the trouble to actually mention the sha1 in a commit message, that probably means it really is an important connection. And if that commit is associated with a bug, then that should mean something too. Think about multiple attempts to fix a bug which get always reverted because the hardware is really acting up in different ways with every attempt... As it is, I don't think it is worth the trouble. If you feel strongly about the message, I can reword it to be somewhat unspecific about the level of indirection... what do you think? Regards, Flo p.s.: sorry for the late response, I'm having a bit of trouble with my mail setup at the moment and too much to do... ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [git pull] drm merge for 3.9-rc1
On Wed, Feb 27, 2013 at 5:39 AM, Linus Torvalds torva...@linux-foundation.org wrote: On Mon, Feb 25, 2013 at 4:05 PM, Dave Airlie airl...@linux.ie wrote: Highlights: i915: all over the map, haswell power well enhancements, valleyview macro horrors cleaned up, killing lots of legacy GTT code, Lowlight: There's something wrong with i915 DP detection or whatever. I get stuff like this: [5.710827] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [5.720810] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [5.730794] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [5.740782] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [5.750775] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! [5.750778] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa145003f . [8.149931] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa145003f I have the same messages after upgrading up to b0af9cd9aab60ceb17d3ebabb9fdf4ff0a99cf50 But in my case when I reboot computer the second monitor, that plugged via HDMI, didn't works, end when I run `xrandr`, I have next messages in kern.log Mar 3 18:09:15 home-spb kernel: [12321.758273] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa143003f Mar 3 18:09:15 home-spb kernel: [12321.771715] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.782712] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.793715] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.804719] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.815725] [drm:intel_dp_aux_wait_done] *ERROR* dp aux hw did not signal timeout (has irq: 1)! Mar 3 18:09:15 home-spb kernel: [12321.817293] [drm:intel_dp_aux_ch] *ERROR* dp_aux_ch not done status 0xa143003f # lspci | fgrep -i graph 00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09) I tested some commits, and here the results: - Breaked at v3.8-10206-gb0af9cd - Works normal v3.8-rc3-139-g34f2be4 - Works normal v3.8-rc3-188-g10aa17c - Works normal 6dc1c49 I've tested 0001-drm-i915-only-use-irq-for-dp-on-post-ilk.patch and it works for me. Thank, Dave. and after that the screen ends up black. It's happened twice now, but is not 100% repeatable. It looks like the message itself is new, but the black screen is also new and does seem to happen when I get the message, so... The second time I touched the power button, and the machine came back. Apparently the suspend/resume cycle made it all magically work: the suspend caused the same errors, but then the resume made it all good again. Some kind of missed initialization at bootup? It's not reliable enough to bisect, but I obviously suspect commit 9ee32fea5fe8 (drm/i915: irq-drive the dp aux communication) since that is where the message was added.. Btw, looking at that commit, what do you think the semantics of the timeout in something like done = wait_event_timeout(dev_priv-gmbus_wait_queue, C, 10); would be? What's that magic 10? It's some totally random number. Guys, it should be something meaningful. If you meant a tenth of a second, use HZ/10 or something. Because just the plain 10 is crazy. I happen to have CONFIG_HZ_1000=y, and you're apparently waiting for a hundreth of a second. Was that what you intended? Because if it was, it is still crap, since CONFIG_HZ might be 100, and then you're waiting for ten times longer. IOW, passing in a random number like that is crazy. It cannot possibly be right. I have no idea whether the timeout has anything to do with anything, but it reinforces my suspicion that there is something wrong with that commit. Linus -- 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/ -- Respectfully Azat Khuzhin Primary email a3at.m...@gmail.com ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
Re: [PATCH] ARM: dts: moving dt binding documents for video devices to common place
On Wed, 06 Feb 2013 09:51:39 -0500, Rahul Sharma rahul.sha...@samsung.com wrote: Binding Documents for drm-devices are placed in Documentation/devicetree/bindings/drm/*. But these devices are common for v4l framework, hence moved to a common place at Documentation/devicetree/bindings/video/. 'exynos_' prefix is added to associate them with exynos soc series. Signed-off-by: Rahul Sharma rahul.sha...@samsung.com Applied, thanks. A tip however, if you use the -M flag when posting patches it will show the files as moved instead of delete the old copy and create a new. It makes my life easier when that is done. g. ___ dri-devel mailing list dri-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/dri-devel
