Bug 1021306

Summary: GPU driver warning in journal
Product: [openSUSE] openSUSE Tumbleweed Reporter: Deleted Name <deleted>
Component: KernelAssignee: E-mail List <kernel-maintainers>
Status: RESOLVED DUPLICATE QA Contact: E-mail List <qa-bugs>
Severity: Normal    
Priority: P5 - None CC: deleted, jslaby, tiwai
Version: Current   
Target Milestone: ---   
Hardware: i586   
OS: SUSE Other   
Whiteboard:
Found By: --- Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---
Attachments: journalctl excerpt
installed kernel
available rc kernel version

Description Deleted Name 2017-01-22 10:48:04 UTC
Created attachment 711146 [details]
journalctl excerpt

I noticed some highlighted messages when looking at 'journalctl -b' and a warning which seems related to the intel video driver. Someone in the forum suggested that this may be a bug, so I am reporting it here. (Please see attachment)

The hardware is Acer Travelmate 2410:

http://www.laptopdirect.co.za/download/acer-travelmate-2410-series.php

Here is also the forum thread for reference:

https://forums.opensuse.org/showthread.php/522379-Video-playback-lag-after-upgrading-from-13-2
Comment 1 Takashi Iwai 2017-01-23 09:35:54 UTC
Could you check whether the issue is still present in 4.10-rc kernel in OBS Kernel:HEAD repo?  If yes, we need to report it to upstream, at best, bugzilla.freedesktop.org (category DRI/Intel).
Comment 2 Deleted Name 2017-01-23 10:13:57 UTC
(In reply to Takashi Iwai from comment #1)
> Could you check whether the issue is still present in 4.10-rc kernel in OBS
> Kernel:HEAD repo?  If yes, we need to report it to upstream, at best,
> bugzilla.freedesktop.org (category DRI/Intel).

Unfortunately this laptop has a very small hard disk without options for upgrade and the system partition doesn't have much space, so if I add another kernel just for the sake of this test I would need to remove it safely after that.

If you could explain how to do this test and then safely revert back to the stable kernel version and clean up the data added by the RC-kernel, I could do this. But please provide all necessary details as I am not an expert.

Thanks.
Comment 3 Takashi Iwai 2017-01-23 10:21:55 UTC
Well, the lack of the disk space is a problem.  If you have some disk space, you can just install the kernel while keeping the older kernels, test the new one, and uninstall the kernel again.  That's easy.

But if you have really too small disk space, even no space for an extra test kernel, it would make debugging extremely difficult, generally speaking...
Comment 4 Deleted Name 2017-01-23 10:40:08 UTC
Currently I have about 2GB free on the system partition.

If you think this will suffice for the test without a risk to break anything else, please provide the detailed steps to test and I will test.
Comment 5 Takashi Iwai 2017-01-23 10:59:03 UTC
Yeah, 2GB is very much enough! I thought it were in the level of a few MB :)

RC4 is already seen as fairly stable, so the breakage risk is very low.
If not, blame kernel people.

Just download kernel-default-4.10.rc4*.rpm from
  http://download.opensuse.org/repositories/Kernel:/HEAD/standard/x86_64/

then install it via
  zypper in kernel-default-4.10.rc4*.rpm

Reboot, and test it.  Once after checking whether the issue is present in 4.10 or not, you can uninstall it freely, simply by
  zypper rm kernel-default-4.10.rc4
Comment 6 Deleted Name 2017-01-23 11:10:23 UTC
Thanks. I will do that.

Just one more question:

Afaik installing a new kernel creates additional boot image. How do I clean that up after the test so that I revert to the regular one?
Comment 7 Takashi Iwai 2017-01-23 11:13:47 UTC
No, it doesn't create a boot image but create a new initrd.  The initrd file will be removed automatically when uninstalling the package, too.
Comment 8 Deleted Name 2017-02-10 13:32:57 UTC
Created attachment 713689 [details]
installed kernel

screenshot from yast
Comment 9 Deleted Name 2017-02-10 13:33:31 UTC
Created attachment 713690 [details]
available rc kernel version

screenshot from yast
Comment 10 Deleted Name 2017-02-10 13:34:08 UTC
Sorry for the slow reply. Here is the update:

1. I am glad I didn't install the kernel using the link you gave because I noticed that it is for 64 bit CPU and this laptop is 32 bit (which is also the main reason I moved from 13.2 to Tumbleweed and not to Leap).

2. I added the repository in yast:

http://download.opensuse.org/repositories/Kernel:/HEAD/standard/

3. Now under kernel-default I have only version 4.9.8 (installed, an problem is still there with it) and separately there is kernel-default-base which has a 4.10.rc7 version. I am attaching 2 screenshots.

Please let me know how to proceed.
Thanks.
Comment 11 Takashi Iwai 2017-02-13 15:11:03 UTC
(In reply to Name Deleted from comment #10)
> Sorry for the slow reply. Here is the update:
> 
> 1. I am glad I didn't install the kernel using the link you gave because I
> noticed that it is for 64 bit CPU and this laptop is 32 bit (which is also
> the main reason I moved from 13.2 to Tumbleweed and not to Leap).
> 
> 2. I added the repository in yast:
> 
> http://download.opensuse.org/repositories/Kernel:/HEAD/standard/
> 
> 3. Now under kernel-default I have only version 4.9.8 (installed, an problem
> is still there with it) and separately there is kernel-default-base which
> has a 4.10.rc7 version.

kernel-default-base is useless.  Please drop it.  There must be kernel-default.rpm with 4.10-rc version, and test this one instead.

Note that I don't say that the newer version shall fix the things automagically.  I guess rather it's still broken.  I'm asking to test the latest upstream version just to confirm that the problem is still there.  It's a mandatory procedure.

And, if the problem is really still seen in 4.10-rc, we need to report this to upstream -- that is, please open a new bug report on bugzilla.freedesktop.org, category DRI/Intel.  There the upstream devs will handle the issue.
Comment 12 Deleted Name 2017-02-13 22:42:55 UTC
(In reply to Takashi Iwai from comment #11)
> There must be
> kernel-default.rpm with 4.10-rc version, and test this one instead.

I understand that there must be but as you see on the screenshots yast shows only 4.9.8. Is something wrong with that repository? Should I remove the repository from yast and install this package manually:

http://download.opensuse.org/repositories/Kernel:/HEAD/standard/i586/kernel-default-4.10.rc7-1.1.gd9294c3.i586.rpm

Please let me know how to proceed. I want to give you good info.

> Note that I don't say that the newer version shall fix the things
> automagically.  I guess rather it's still broken.  I'm asking to test the
> latest upstream version just to confirm that the problem is still there. 
> It's a mandatory procedure.
> 
> And, if the problem is really still seen in 4.10-rc, we need to report this
> to upstream -- that is, please open a new bug report on
> bugzilla.freedesktop.org, category DRI/Intel.  There the upstream devs will
> handle the issue.

Yes. I understand you completely and I am willing to provide the info you need. Just please let me know how to do it properly as this is kernel and I am afraid not to break something.

Thank you so much.
Comment 13 Deleted Name 2017-03-04 20:46:49 UTC
I have just upgraded to stable kernel 4.10.1-1 using zypper dup. The issue remains.
Comment 14 Jiri Slaby 2017-08-23 08:48:40 UTC
Could you paste a full journactl -b with kernel 4.12? In the original report, the first warning is missing...
Comment 15 Deleted Name 2017-08-26 20:45:18 UTC
(In reply to Jiri Slaby from comment #14)
> Could you paste a full journactl -b with kernel 4.12? In the original
> report, the first warning is missing...

Yes but I would prefer not to post it publicly as it seems to contain too much info and I am cautious not to compromise the security of the system. So please advise how to extract only the info which you really need and how to send it privately.

Also please have a look at report 1054613 as it seems that 4.12 made things even far worse and now it is difficult to use the system as a whole.

Thanks.
Comment 16 Jiri Slaby 2017-08-28 07:09:12 UTC
It is actually enough to paste journalctl -k -- only the kernel log.
Comment 17 Deleted Name 2017-08-28 08:32:52 UTC
There it is (just hidden host, domain and UUID of disk):

http://paste.opensuse.org/4b5ba1fd

Please also have a look at bug #1054613 as it may be related to current one.

Thanks.
Comment 18 Jiri Slaby 2017-08-31 09:03:48 UTC
WARN_ON(!connector_state->crtc)
------------[ cut here ]------------
WARNING: CPU: 0 PID: 125 at ../drivers/gpu/drm/i915/intel_display.c:11250 intel_atomic_check.part.125+0xf2c/0x10a0 [i915]
Modules linked in: ...
CPU: 0 PID: 125 Comm: kworker/u4:2 Not tainted 4.12.8-1-default #1
EIP: intel_atomic_check.part.125+0xf2c/0x10a0 [i915]
EFLAGS: 00010282 CPU: 0
EAX: 0000001f EBX: f7314400 ECX: d60c90a8 EDX: 00000001
ESI: f562bc00 EDI: 00000000 EBP: f710bc9c ESP: f710bc48
 DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
CR0: 80050033 CR2: f8945424 CR3: 371ae000 CR4: 000006d0
Call Trace:
 ? drm_atomic_check_only+0x344/0x4d0 [drm]
 ? kmemdup+0x2a/0x40
 ? drm_atomic_get_plane_state+0xa3/0xf0 [drm]
 ? drm_atomic_commit+0x14/0x50 [drm]
 ? intel_get_load_detect_pipe+0x359/0x610 [i915]
 ? intel_crt_detect+0x36f/0x7f0 [i915]
 ? drm_mode_debug_printmodeline+0x47/0x50 [drm]
 ? intel_crt_detect_ddc+0xc0/0xc0 [i915]
 ? drm_helper_probe_detect+0x40/0x90 [drm_kms_helper]
 ? drm_helper_probe_single_connector_modes+0xb4/0x560 [drm_kms_helper]
 ? drm_setup_crtcs+0x62/0x920 [drm_kms_helper]
 ? update_load_avg+0x4c4/0x610
 ? drm_fb_helper_initial_config+0x53/0x3f0 [drm_kms_helper]
 ? pick_next_task_fair+0x509/0x5d0
 ? __switch_to+0x94/0x2d0
 ? intel_fbdev_initial_config+0x16/0x30 [i915]
 ? async_run_entry_fn+0x36/0x160
 ? process_one_work+0x152/0x350 
 ? worker_thread+0x41/0x3d0
 ? __wake_up_locked+0x11/0x20 
 ? kthread+0xf3/0x110
 ? process_one_work+0x350/0x350 
 ? kthread_park+0x70/0x70
 ? ret_from_fork+0x19/0x30
Code: 4d e4 e8 4c 75 25 dd 0f ff 58 8b 4d e4 5a 8b 55 dc e9 84 fb ff ff 68 04 bf 37 f8 68 11 9f 36 f8 89 55 dc 89 4d e4 e8 28 75 25 dd <0f> ff 58 8b 4d e4 5a 8b 55 dc e9 46 fb ff ff 68 84 bf 37 f8 6a
---[ end trace e106efafb7b3f853 ]---
Comment 19 Deleted Name 2017-08-31 09:09:59 UTC
What does this mean? Should I do anything?
Comment 20 Jiri Slaby 2017-08-31 09:12:46 UTC
It's a long-standing issue reported to upstream (Intel guys) and they does not seem to care much. You can ping them at the freedesktop bug, as there is a lot of users hitting this.

*** This bug has been marked as a duplicate of bug 999037 ***
Comment 21 Deleted Name 2017-08-31 09:25:28 UTC
Ok. Thanks for the info.