On Mon, Aug 11, 2014 at 12:38:41AM +0100, Pedro Ribeiro wrote: > On 2 June 2014 21:15, Pedro Ribeiro <pedrib@xxxxxxxxx> wrote: > > On 27 May 2014 08:15, Daniel Vetter <daniel@xxxxxxxx> wrote: > >> On Mon, May 26, 2014 at 9:44 PM, Pedro Ribeiro <pedrib@xxxxxxxxx> 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 _______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
