From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Vetter Subject: Re: WARNING on i915 - intel_panel Date: Mon, 11 Aug 2014 11:22:07 +0200 Message-ID: <20140811092207.GC8727@phenom.ffwll.local> References: <8761ks28tm.fsf@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail-wg0-f46.google.com (mail-wg0-f46.google.com [74.125.82.46]) by gabe.freedesktop.org (Postfix) with ESMTP id EF1F589BFB for ; Mon, 11 Aug 2014 02:21:55 -0700 (PDT) Received: by mail-wg0-f46.google.com with SMTP id m15so8218954wgh.29 for ; Mon, 11 Aug 2014 02:21:55 -0700 (PDT) Content-Disposition: inline In-Reply-To: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: intel-gfx-bounces@lists.freedesktop.org Sender: "Intel-gfx" To: Pedro Ribeiro Cc: intel-gfx List-Id: intel-gfx@lists.freedesktop.org On Mon, Aug 11, 2014 at 12:38:41AM +0100, Pedro Ribeiro wrote: > On 2 June 2014 21:15, Pedro Ribeiro wrote: > > On 27 May 2014 08:15, Daniel Vetter wrote: > >> On Mon, May 26, 2014 at 9:44 PM, Pedro Ribeiro wrote: > >>> Kern.log is attached, but as you can see it does not contain the same > >>> verbose drm debug information as dmesg... Should I just keep piping > >>> dmesg to a file and then cat it all together? > >>> I never really understood why there are so many logs: kern, messages, > >>> syslog, instead of a single central log. > >> > >> Indeed, that one isn't useful either :( Next idea: Increase the > >> in-kernel dmesg buffer size and hope it all fits with log_buf_size=4M > >> (on the kernel cmdline). Maybe you can go even higher, not sure. > >> -Daniel > >> -- > >> Daniel Vetter > >> Software Engineer, Intel Corporation > >> +41 (0) 79 365 57 48 - http://blog.ffwll.ch > > > > Daniel, doesn't seem like that is working. > > > > I'll leave it be and try to test new kernels and see if it just goes > > away. I'll report back if it doesn't. > > > > Regards, > > Pedro > > Hi Daniel, > > the problem is still there with the latest 3.14.14. But the good news > is that I have finally been able to get a full dmesg log! > Please find it attached. I hope this helps and let me know what else I > need to do to assist. > > The log shows two hibernate-resume cycles, and you can see the bug > being triggered at line 4274. As I said previously this looks like it > doesn't affect the operation much, although it seems to happen very > frequently as I do more hibernate cycles. Yeah, log looks interesting, but I don't immediately see what's wrong. Can you please fiel a new bug on bugs.freedeskopt.org against DRI -> DRM (Intel) and please don't forget to put [regression] into the summary. Also, if you manually disable the lvds with e.g. $ xrandr --output LVDS1 --off ; xrandr --output LVDS1 --auto does it happen, too? Or do you only see this over a hibernate cycle? > PS: if I hibernate with a external monitor connected, and resume > without that monitor connected, will the kernel handle it correctly? Well the kernel won't do much, but it will generate a hotplug event to inform userspace that the configuration changed. Then userspace needs to figure out what to do - by default we keep pumping pixels to the screen presuming that the cable fell out for a bit and that the user will replug. But a good DE reconfigures or shows you a dialog box on one of the remaining enabled screens. -Daniel -- Daniel Vetter Software Engineer, Intel Corporation +41 (0) 79 365 57 48 - http://blog.ffwll.ch