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. PS: if I hibernate with a external monitor connected, and resume without that monitor connected, will the kernel handle it correctly? Regards, Pedro
Attachment:
dmesg.tar.gz
Description: GNU Zip compressed data
_______________________________________________ Intel-gfx mailing list Intel-gfx@xxxxxxxxxxxxxxxxxxxxx http://lists.freedesktop.org/mailman/listinfo/intel-gfx
