|
Bugzilla – Full Text Bug Listing |
| Summary: | GPU driver warning in journal | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | Deleted Name <deleted> |
| Component: | Kernel | Assignee: | 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
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). (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. 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... 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. 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 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? 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. Created attachment 713689 [details]
installed kernel
screenshot from yast
Created attachment 713690 [details]
available rc kernel version
screenshot from yast
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. (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. (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. I have just upgraded to stable kernel 4.10.1-1 using zypper dup. The issue remains. Could you paste a full journactl -b with kernel 4.12? In the original report, the first warning is missing... (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. It is actually enough to paste journalctl -k -- only the kernel log. 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. 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 ]--- What does this mean? Should I do anything? 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 *** Ok. Thanks for the info. |