Bug 93580

It happend again, I could not switch tty after it happend, but no kernel panic.

i have verified the memory (well the ram) with memtest

*** Bug 93992 has been marked as a duplicate of this bug. ***

Please try kernel v4.5 or later.

I just had the same issue with kernel 4.5.4 on Archlinux using a lenovo Thinkpad T60.

$ uname -a
Linux thinkpad 4.5.4-1-ARCH #1 SMP PREEMPT Wed May 11 22:21:28 CEST 2016 x86_64 GNU/Linux

$ lspci -vnn | grep VGA -A 1
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller [8086:27a2] (rev 03) (prog-if 00 [VGA controller])
	Subsystem: Lenovo ThinkPad R60/T60/X60 series [17aa:201a]

kernel log:
BUG: unable to handle kernel NULL pointer dereference at 00000000000000a0
IP: [<ffffffffa08855a8>] intel_fbdev_restore_mode+0x48/0x80 [i915]
PGD 733a3067 PUD 733cc067 PMD 0 
Oops: 0000 [#1] PREEMPT SMP 
Modules linked in: mousedev iTCO_wdt iTCO_vendor_support ppdev i915 coretemp pcmcia kvm drm_
 af_alg dm_crypt dm_mod sd_mod sr_mod cdrom ata_generic pata_acpi atkbd libps2 ahci libahci 
CPU: 1 PID: 395 Comm: Xorg.wrap Not tainted 4.5.4-1-ARCH #1
Hardware name: LENOVO 1952VYF/1952VYF, BIOS 79ETD2WW (2.12 ) 04/12/2007
task: ffff88007a3db400 ti: ffff8800733c4000 task.ti: ffff8800733c4000
RIP: 0010:[<ffffffffa08855a8>]  [<ffffffffa08855a8>] intel_fbdev_restore_mode+0x48/0x80 [i91
RSP: 0018:ffff8800733c7dc0  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffff880079edbc00 RCX: 0000000000000000
RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffff88000006c060
RBP: ffff8800733c7dc8 R08: 0000000000000000 R09: ffff88007ef157b0
R10: ffff88007a315600 R11: 0000000000000001 R12: ffff88000006c000
R13: ffff88007b410ad8 R14: ffff88000006c088 R15: ffff880079edbcc0
FS:  00007fea41061700(0000) GS:ffff88007ef00000(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: 00000000000000a0 CR3: 0000000073397000 CR4: 00000000000006e0
Stack:
 ffff88000006c000 ffff8800733c7dd8 ffffffffa08b139e ffff8800733c7df8
 ffffffffa04c1b8e 0000000000000000 ffff88000006c000 ffff8800733c7e68
 ffffffffa04c1fcf 0000000800000001 ffff88007abad768 0000000000000246
Call Trace:
 [<ffffffffa08b139e>] i915_driver_lastclose+0xe/0x20 [i915]
 [<ffffffffa04c1b8e>] drm_lastclose+0x2e/0x140 [drm]
 [<ffffffffa04c1fcf>] drm_release+0x32f/0x510 [drm]
 [<ffffffff811f18cf>] __fput+0x9f/0x1e0
 [<ffffffff811f1a4e>] ____fput+0xe/0x10
 [<ffffffff81095458>] task_work_run+0x78/0xa0
 [<ffffffff810036aa>] exit_to_usermode_loop+0xba/0xc0
 [<ffffffff81003bee>] syscall_return_slowpath+0x4e/0x60
 [<ffffffff815b5808>] int_ret_from_sys_call+0x25/0x8f
Code: e8 ae f4 dd ff 85 c0 74 0c f6 05 b3 6c c7 ff 01 75 35 5b 5d c3 48 8b 43 08 48 8d 78 60
RIP  [<ffffffffa08855a8>] intel_fbdev_restore_mode+0x48/0x80 [i915]
 RSP <ffff8800733c7dc0>
CR2: 00000000000000a0
---[ end trace c62f437557d31865 ]---

*** Bug 96554 has been marked as a duplicate of this bug. ***

Is it possible to get patch https://patchwork.freedesktop.org/patch/93560/ and https://patchwork.freedesktop.org/patch/93561/ that you gavae me in #96554 for 4.7-rc4?

They don't apply cleanly there.

This is the rejected hunk:

--- drivers/gpu/drm/i915/intel_fbdev.c
+++ drivers/gpu/drm/i915/intel_fbdev.c
@@ -551,12 +550,14 @@ static void intel_fbdev_destroy(struct drm_device *dev,
 	drm_fb_helper_fini(&ifbdev->helper);
 
 	if (ifbdev->fb) {
-		mutex_lock(&dev->struct_mutex);
+		mutex_lock(&ifbdev->helper.dev->struct_mutex);
 		intel_unpin_fb_obj(&ifbdev->fb->base, BIT(DRM_ROTATE_0));
-		mutex_unlock(&dev->struct_mutex);
+		mutex_unlock(&ifbdev->helper.dev->struct_mutex);
 
 		drm_framebuffer_remove(&ifbdev->fb->base);
 	}
+
+	kfree(ifbdev);
 }
 
 /

I realized that wasn't very clear. The patch that isn't applied cleanly is https://patchwork.freedesktop.org/patch/93560/ .

Here you go https://cgit.freedesktop.org/~ickle/linux-2.6/log/?h=for-bug93580

Unfortunately those patches didn't solve the issue for me.

What happens is that the external monitors goes black, the display on the laptop sort of fades into noice and the audio starts repeating the last few seconds (If I'm listening to music)

I still haven't found a pattern here.

I obviously mean it fades to noise.

Spelling is hard :)

Is there any change in the oops? That would be useful to know, could you please attach a fresh copy with the patches applied?

(In reply to Kim Lidström from comment #10)
> Unfortunately those patches didn't solve the issue for me.

Does the patch fix the issue for other reporters? Maybe a different issue?

(In reply to Jani Nikula from comment #13)
> (In reply to Kim Lidström from comment #10)
> > Unfortunately those patches didn't solve the issue for me.
> 
> Does the patch fix the issue for other reporters? Maybe a different issue?

I know that it fixes an oops that I was able to trigger locally, but as stated in the changelog I believe that was only possible due to how I enabled the whole module/builtin to load asynchronously.

I suspect (And have suspected all along) that my issue is a separate issue

In fact I wasn't all too sure if the message I posted was related to the crash or if it just was a coincidence that that was the last thing that happened before the box crashed.

The thing is that when the box freezes like this I can't do ANYTHING. The only solution is a hard reboot

I will see if I can get some debug output from the module with drm.debug=0xe

Created attachment 124760 [details]
New journal with patches applied

Hi!
I attached the log output I could retrieve from the last freeze.

I'm running 4.7.0-rc5 with the patches applied and drm.debug=0xe

(In reply to Kim Lidström from comment #17)
> Hi!
> I attached the log output I could retrieve from the last freeze.
> 
> I'm running 4.7.0-rc5 with the patches applied and drm.debug=0xe

I don't see the fbdev issue in there, but lots of
kernel: WARNING: CPU: 3 PID: 970 at drivers/gpu/drm/i915/intel_pm.c:3647 skl_update_other_pipe_wm+0x177/0x180 [i915]
kernel: WARN_ON(!wm_changed)

Please do file a separate but for that WARN and mention all steps that lead up to the freeze, even if just "it freezes at random with no forewarning".

I am going to tentatively close this fbdev one following:

commit e77018f7618960f7ec0e73e63868514ff16f8ddc
Author: Chris Wilson <chris@chris-wilson.co.uk>
Date:   Tue Jun 21 09:16:55 2016 +0100

    drm/i915/fbdev: Flush mode configuration before lastclose

Please do reopen if you can reproduce the fbdev oops on a recent (-nightly) kernel.

But isn't there already an issue about that warning? https://bugs.freedesktop.org/show_bug.cgi?id=89055

(In reply to Kim Lidström from comment #19)
> But isn't there already an issue about that warning?
> https://bugs.freedesktop.org/show_bug.cgi?id=89055

yes, you are correct Kim, and this should be fixed (landing in kernel 4.8).

So aren't we back to square one now? :)

From what I can tell (By reading the reports and trying out the patches with earlier kernels) that warning is not the cause of these freezes.

(In reply to Kim Lidström from comment #21)
> So aren't we back to square one now? :)
> 
> From what I can tell (By reading the reports and trying out the patches with
> earlier kernels) that warning is not the cause of these freezes.

We think we have all of the issues you're seeing fixed in drm-intel-nightly branch of http://cgit.freedesktop.org/drm-intel, and the fixes are headed to v4.8 kernel. Please reopen if you can reproduce these issues with drm-intel-nightly. Thanks.

Alright then! This is good. I'll be trying the nightly today.