Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-03 00:14:38) > For comparison, here's another one produced by the same kernel, on the > same laptop, but a different hard drive. > > The OS was installed on a USB stick that I'd boot the laptop off > of. Recently I started getting lags when copying to / from the stick, > so I moved the OS to an external SSD. > > Everything else stayed the same, and booting the same kernel resulted > in the same type of freeze. I still have no explanation for how the use-after-free is possible here. The list iteration and destruction are both guarded by the struct_mutex. However, we have just pushed some extra assertions into drm-tip, https://cgit.freedesktop.org/drm-tip If you could please compile and test a kernel built using that branch and enable CONFIG_DRM_I915_DEBUG_GEM (which depends on CONFIG_DRM_I915_WERROR). I'm hoping that will catch the culprit in the act. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
I've cloned your https://anongit.freedesktop.org/git/drm-tip.git and am now trying to build it (just the master; I haven't tried previous commits). The build fails at the modules stage with Makefile:1015: recipe for target 'drivers' failed make: *** [drivers] Error 2 What is the earliest commit I can try to build so it will still include the config options you mention? I'm sure I'm just missing something obvious.. On Wed, Jan 03, 2018 at 12:49:10PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-03 00:14:38) > > For comparison, here's another one produced by the same kernel, on the > > same laptop, but a different hard drive. > > > > The OS was installed on a USB stick that I'd boot the laptop off > > of. Recently I started getting lags when copying to / from the stick, > > so I moved the OS to an external SSD. > > > > Everything else stayed the same, and booting the same kernel resulted > > in the same type of freeze. > > I still have no explanation for how the use-after-free is possible here. > The list iteration and destruction are both guarded by the struct_mutex. > > However, we have just pushed some extra assertions into drm-tip, > https://cgit.freedesktop.org/drm-tip If you could please compile and > test a kernel built using that branch and enable > CONFIG_DRM_I915_DEBUG_GEM (which depends on CONFIG_DRM_I915_WERROR). I'm > hoping that will catch the culprit in the act. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-03 13:46:42) > I've cloned your > > https://anongit.freedesktop.org/git/drm-tip.git > > and am now trying to build it (just the master; I haven't tried > previous commits). The build fails at the modules stage with > > Makefile:1015: recipe for target 'drivers' failed > make: *** [drivers] Error 2 > > What is the earliest commit I can try to build so it will still > include the config options you mention? > > I'm sure I'm just missing something obvious.. Make sure you have the drm-tip branch. It should compile fine, if not show the last few lines that tell us what the actual error is. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
On Wed, Jan 03, 2018 at 01:47:56PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-03 13:46:42) > > I've cloned your > > > > https://anongit.freedesktop.org/git/drm-tip.git > > > > and am now trying to build it (just the master; I haven't tried > > previous commits). The build fails at the modules stage with > > > > Makefile:1015: recipe for target 'drivers' failed > > make: *** [drivers] Error 2 > > > > What is the earliest commit I can try to build so it will still > > include the config options you mention? > > > > I'm sure I'm just missing something obvious.. > > Make sure you have the drm-tip branch. That's the one. `git branch` returns drm-tip. > It should compile fine, if not > show the last few lines that tell us what the actual error is. When I run a script that makes bzImage and modules and then tries to install, I get multiple errors to the effect that the modules to be installed cannot be found: INSTALL sound/synth/snd-util-mem.ko cp: cannot stat 'sound/synth/snd-util-mem.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/synth/snd-util-mem.ko': No such file INSTALL sound/usb/6fire/snd-usb-6fire.ko cp: cannot stat 'sound/usb/6fire/snd-usb-6fire.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/6fire/snd-usb-6fire.ko': No such file INSTALL sound/usb/caiaq/snd-usb-caiaq.ko cp: cannot stat 'sound/usb/caiaq/snd-usb-caiaq.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/caiaq/snd-usb-caiaq.ko': No such file INSTALL sound/usb/hiface/snd-usb-hiface.ko cp: cannot stat 'sound/usb/hiface/snd-usb-hiface.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/hiface/snd-usb-hiface.ko': No such file INSTALL sound/usb/line6/snd-usb-line6.ko cp: cannot stat 'sound/usb/line6/snd-usb-line6.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-line6.ko': No such file INSTALL sound/usb/line6/snd-usb-pod.ko cp: cannot stat 'sound/usb/line6/snd-usb-pod.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-pod.ko': No such file INSTALL sound/usb/line6/snd-usb-podhd.ko cp: cannot stat 'sound/usb/line6/snd-usb-podhd.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-podhd.ko': No such file INSTALL sound/usb/line6/snd-usb-toneport.ko cp: cannot stat 'sound/usb/line6/snd-usb-toneport.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-toneport.ko': No such file INSTALL sound/usb/line6/snd-usb-variax.ko cp: cannot stat 'sound/usb/line6/snd-usb-variax.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-variax.ko': No such file INSTALL sound/usb/misc/snd-ua101.ko cp: cannot stat 'sound/usb/misc/snd-ua101.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/misc/snd-ua101.ko': No such file INSTALL sound/usb/snd-usb-audio.ko cp: cannot stat 'sound/usb/snd-usb-audio.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/snd-usb-audio.ko': No such file INSTALL sound/usb/snd-usbmidi-lib.ko cp: cannot stat 'sound/usb/snd-usbmidi-lib.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/snd-usbmidi-lib.ko': No such file INSTALL sound/usb/usx2y/snd-usb-us122l.ko cp: cannot stat 'sound/usb/usx2y/snd-usb-us122l.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/usx2y/snd-usb-us122l.ko': No such file INSTALL sound/usb/usx2y/snd-usb-usx2y.ko cp: cannot stat 'sound/usb/usx2y/snd-usb-usx2y.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/usx2y/snd-usb-usx2y.ko': No such file INSTALL sound/x86/snd-hdmi-lpe-audio.ko cp: cannot stat 'sound/x86/snd-hdmi-lpe-audio.ko': No such file or directory strip: '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/x86/snd-hdmi-lpe-audio.ko': No such file INSTALL virt/lib/irqbypass.ko On the other hand, when I run `make bzImage modules` it stops abruptly with the two lines I sent. Here's the final segment I can see on the screen: LD [M] drivers/net/wire
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-03 14:03:40) > > On Wed, Jan 03, 2018 at 01:47:56PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-03 13:46:42) > > > I've cloned your > > > > > > https://anongit.freedesktop.org/git/drm-tip.git > > > > > > and am now trying to build it (just the master; I haven't tried > > > previous commits). The build fails at the modules stage with > > > > > > Makefile:1015: recipe for target 'drivers' failed > > > make: *** [drivers] Error 2 > > > > > > What is the earliest commit I can try to build so it will still > > > include the config options you mention? > > > > > > I'm sure I'm just missing something obvious.. > > > > Make sure you have the drm-tip branch. > > That's the one. `git branch` returns drm-tip. > > > It should compile fine, if not > > show the last few lines that tell us what the actual error is. > > When I run a script that makes bzImage and modules and then tries to > install, I get multiple errors to the effect that the modules to be > installed cannot be found: > > INSTALL sound/synth/snd-util-mem.ko > cp: cannot stat 'sound/synth/snd-util-mem.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/synth/snd-util-mem.ko': > No such file > INSTALL sound/usb/6fire/snd-usb-6fire.ko > cp: cannot stat 'sound/usb/6fire/snd-usb-6fire.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/6fire/snd-usb-6fire.ko': > No such file > INSTALL sound/usb/caiaq/snd-usb-caiaq.ko > cp: cannot stat 'sound/usb/caiaq/snd-usb-caiaq.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/caiaq/snd-usb-caiaq.ko': > No such file > INSTALL sound/usb/hiface/snd-usb-hiface.ko > cp: cannot stat 'sound/usb/hiface/snd-usb-hiface.ko': No such file or > directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/hiface/snd-usb-hiface.ko': > No such file > INSTALL sound/usb/line6/snd-usb-line6.ko > cp: cannot stat 'sound/usb/line6/snd-usb-line6.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-line6.ko': > No such file > INSTALL sound/usb/line6/snd-usb-pod.ko > cp: cannot stat 'sound/usb/line6/snd-usb-pod.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-pod.ko': > No such file > INSTALL sound/usb/line6/snd-usb-podhd.ko > cp: cannot stat 'sound/usb/line6/snd-usb-podhd.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-podhd.ko': > No such file > INSTALL sound/usb/line6/snd-usb-toneport.ko > cp: cannot stat 'sound/usb/line6/snd-usb-toneport.ko': No such file or > directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-toneport.ko': > No such file > INSTALL sound/usb/line6/snd-usb-variax.ko > cp: cannot stat 'sound/usb/line6/snd-usb-variax.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/line6/snd-usb-variax.ko': > No such file > INSTALL sound/usb/misc/snd-ua101.ko > cp: cannot stat 'sound/usb/misc/snd-ua101.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/misc/snd-ua101.ko': > No such file > INSTALL sound/usb/snd-usb-audio.ko > cp: cannot stat 'sound/usb/snd-usb-audio.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/snd-usb-audio.ko': > No such file > INSTALL sound/usb/snd-usbmidi-lib.ko > cp: cannot stat 'sound/usb/snd-usbmidi-lib.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/snd-usbmidi-lib.ko': > No such file > INSTALL sound/usb/usx2y/snd-usb-us122l.ko > cp: cannot stat 'sound/usb/usx2y/snd-usb-us122l.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/usx2y/snd-usb-us122l.ko': > No such file > INSTALL sound/usb/usx2y/snd-usb-usx2y.ko > cp: cannot stat 'sound/usb/usx2y/snd-usb-usx2y.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/kernel/sound/usb/usx2y/snd-usb-usx2y.ko': > No such file > INSTALL sound/x86/snd-hdmi-lpe-audio.ko > cp: cannot stat 'sound/x86/snd-hdmi-lpe-audio.ko': No such file or directory > strip: > '/axiomatic/data/users/achirvas/lnx//lib/modules/4.15.0-rc6-x-void-noslb+/ke
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-03 14:48:26) > Here's the log for the make bzImage and modules without ccache. > > I ran it with j8 still because otherwise it would take very long, but > if I run out of options I'll try plain too.. > > In the meantime I'd like to try some other configs; maybe specific > drivers are messing me up. > > I swear to god it was working all right yesterday.. drivers/gpu/drm/i915/intel_dpio_phy.c:442:1: error: the frame size of 1168 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] Go into the kconfig compiler options and increase the limit or disable the warning. See CONFIG_FRAME_WARN. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Thank you for that! I'd been getting used to seeing warnings to that effect, so got complacent and stopped checking for errors.. In any case, it's now compiled and installed, and I will report back with any new logs if / when another hang occurs. On Wed, Jan 03, 2018 at 02:53:45PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-03 14:48:26) > > Here's the log for the make bzImage and modules without ccache. > > > > I ran it with j8 still because otherwise it would take very long, but > > if I run out of options I'll try plain too.. > > > > In the meantime I'd like to try some other configs; maybe specific > > drivers are messing me up. > > > > I swear to god it was working all right yesterday.. > > drivers/gpu/drm/i915/intel_dpio_phy.c:442:1: error: the frame size of > 1168 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > Go into the kconfig compiler options and increase the limit or disable > the warning. See CONFIG_FRAME_WARN. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
All right, here's the dmesg from the kernel compiled from drm-tip (in sync with upstream at the time of the compilation earlier today), with CONFIG_DRM_I915_DEBUG_GEM=y I crashed it by opening 20+ xterm windows. Doesn't always do it though (tried this before). On Wed, Jan 03, 2018 at 11:31:31AM -0500, Alexandru Chirvasitu wrote: > Thank you for that! > > I'd been getting used to seeing warnings to that effect, so got > complacent and stopped checking for errors.. > > In any case, it's now compiled and installed, and I will report back > with any new logs if / when another hang occurs. > > On Wed, Jan 03, 2018 at 02:53:45PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-03 14:48:26) > > > Here's the log for the make bzImage and modules without ccache. > > > > > > I ran it with j8 still because otherwise it would take very long, but > > > if I run out of options I'll try plain too.. > > > > > > In the meantime I'd like to try some other configs; maybe specific > > > drivers are messing me up. > > > > > > I swear to god it was working all right yesterday.. > > > > drivers/gpu/drm/i915/intel_dpio_phy.c:442:1: error: the frame size of > > 1168 bytes is larger than 1024 bytes [-Werror=frame-larger-than=] > > > > Go into the kconfig compiler options and increase the limit or disable > > the warning. See CONFIG_FRAME_WARN. > > -Chris [0.00] microcode: microcode updated early to revision 0x62, date = 2017-04-27 [0.00] Linux version 4.15.0-rc6-drm-debug+ (root@axiomatic) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Wed Jan 3 11:04:15 EST 2018 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-drm-debug+ root=UUID=1e9f6fc3-400d-44b7-838c-93777e2f0662 ro loglevel=4 slub_debug=P page_poison=1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00C00
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > All right, here's the dmesg from the kernel compiled from drm-tip (in > sync with upstream at the time of the compilation earlier today), with > > CONFIG_DRM_I915_DEBUG_GEM=y > > I crashed it by opening 20+ xterm windows. Doesn't always do it though > (tried this before). Sorry, still stumped. It's still the same use-after-free and no asserts hit. Can you keep KASAN enabled but disable slab/page poisoning? Hmm, I think it has to be page poisoning doing the 0x6b as SLAB_POISON is disabled by default. (You could check by enabling slabstats can looking in sysfs.) My goal is to get that kasan trace telling me who about the freed object. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
I'll try. I need a bit of clarification: On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > > All right, here's the dmesg from the kernel compiled from drm-tip (in > > sync with upstream at the time of the compilation earlier today), with > > > > CONFIG_DRM_I915_DEBUG_GEM=y > > > > I crashed it by opening 20+ xterm windows. Doesn't always do it though > > (tried this before). > > Sorry, still stumped. It's still the same use-after-free and no asserts > hit. Can you keep KASAN enabled but disable slab/page poisoning? Hmm, I > think it has to be page poisoning doing the 0x6b as SLAB_POISON is > disabled by default. Would this have to be through a new compilation, or would it do to just remove the poisoning kernel parameter on boot? > (You could check by enabling slabstats can looking in sysfs.) Sorry, I was having some trouble parsing this; what do I check again and how? Does 'slabstats' refer to another kernel config option or something else? I apologize, most of these options I'm fiddling with are not familiar to me.. > My goal is to get that kasan trace telling me who about the > freed object. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-05 19:37:24) > I'll try. I need a bit of clarification: > > On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > > > All right, here's the dmesg from the kernel compiled from drm-tip (in > > > sync with upstream at the time of the compilation earlier today), with > > > > > > CONFIG_DRM_I915_DEBUG_GEM=y > > > > > > I crashed it by opening 20+ xterm windows. Doesn't always do it though > > > (tried this before). > > > > Sorry, still stumped. It's still the same use-after-free and no asserts > > hit. Can you keep KASAN enabled but disable slab/page poisoning? Hmm, I > > think it has to be page poisoning doing the 0x6b as SLAB_POISON is > > disabled by default. > > Would this have to be through a new compilation, or would it do to > just remove the poisoning kernel parameter on boot? CONFIG_PAGE_POISONING > > > (You could check by enabling slabstats can looking in sysfs.) > > Sorry, I was having some trouble parsing this; what do I check again > and how? > > Does 'slabstats' refer to another kernel config option or something > else? It would be CONFIG_SLUB_STATS and then you would a /sys/kernel/slab/i915_dependency/ directory with all the details of the slab, and in particular a poison file showing the status (and allowing it to modified) of slab poisoning Ok, it looks like poisoning is only available if CONFIG_SLUB_DEBUG is set. Since it is not set, don't worry about it ;) -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
OK, I then plan to try with the previous config, plus these modifications: CONFIG_PAGE_POISONING not set CONFIG_SLUB_STATS=y I'm a little puzzled about this: On Fri, Jan 05, 2018 at 07:51:01PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-05 19:37:24) > > I'll try. I need a bit of clarification: > > > > On Fri, Jan 05, 2018 at 05:52:25PM +, Chris Wilson wrote: > > > Quoting Alexandru Chirvasitu (2018-01-03 21:53:15) > > > > All right, here's the dmesg from the kernel compiled from drm-tip (in > > > > sync with upstream at the time of the compilation earlier today), with > > > > > > > > CONFIG_DRM_I915_DEBUG_GEM=y > > > > > > > > I crashed it by opening 20+ xterm windows. Doesn't always do it though > > > > (tried this before). > > > > > > Sorry, still stumped. It's still the same use-after-free and no asserts > > > hit. Can you keep KASAN enabled but disable slab/page poisoning? Hmm, I > > > think it has to be page poisoning doing the 0x6b as SLAB_POISON is > > > disabled by default. > > > > Would this have to be through a new compilation, or would it do to > > just remove the poisoning kernel parameter on boot? > > CONFIG_PAGE_POISONING > > > > > > (You could check by enabling slabstats can looking in sysfs.) > > > > Sorry, I was having some trouble parsing this; what do I check again > > and how? > > > > Does 'slabstats' refer to another kernel config option or something > > else? > > It would be CONFIG_SLUB_STATS and then you would a > /sys/kernel/slab/i915_dependency/ directory with all the details of the > slab, and in particular a poison file showing the status (and allowing > it to modified) of slab poisoning > > Ok, it looks like poisoning is only available if CONFIG_SLUB_DEBUG is > set. Since it is not set, don't worry about it ;) I actually do have SLUB_DEBUG set to 'y' in the kernel whose dmesg I last sent you. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-05 19:58:42) > OK, I then plan to try with the previous config, plus these > modifications: > > CONFIG_PAGE_POISONING not set > CONFIG_SLUB_STATS=y > > I'm a little puzzled about this: [snip] > > It would be CONFIG_SLUB_STATS and then you would a > > /sys/kernel/slab/i915_dependency/ directory with all the details of the > > slab, and in particular a poison file showing the status (and allowing > > it to modified) of slab poisoning > > > > Ok, it looks like poisoning is only available if CONFIG_SLUB_DEBUG is > > set. Since it is not set, don't worry about it ;) > > I actually do have SLUB_DEBUG set to 'y' in the kernel whose dmesg I > last sent you. Ah, ok. I was looking at the config attached the first mail. Turn off SLUB_DEBUG for now to give ourselves the best chance at getting something from kasan. I hope it's worth the effort... -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Will do. On Fri, Jan 05, 2018 at 08:02:48PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-05 19:58:42) > > OK, I then plan to try with the previous config, plus these > > modifications: > > > > CONFIG_PAGE_POISONING not set > > CONFIG_SLUB_STATS=y > > > > I'm a little puzzled about this: > > [snip] > > > > It would be CONFIG_SLUB_STATS and then you would a > > > /sys/kernel/slab/i915_dependency/ directory with all the details of the > > > slab, and in particular a poison file showing the status (and allowing > > > it to modified) of slab poisoning > > > > > > Ok, it looks like poisoning is only available if CONFIG_SLUB_DEBUG is > > > set. Since it is not set, don't worry about it ;) > > > > I actually do have SLUB_DEBUG set to 'y' in the kernel whose dmesg I > > last sent you. > > Ah, ok. I was looking at the config attached the first mail. Turn off > SLUB_DEBUG for now to give ourselves the best chance at getting > something from kasan. I hope it's worth the effort... No worries, worth it at my end already. And thanks! Will get back when I have another crash. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-05 22:05:18) > Here we go. > > I have > > CONFIG_PAGE_POISONING not set > CONFIG_SLUB_STATS=y > CONFIG_SLUB_DEBUG not set > CONFIG_KASAN=y > > .config attached along as well for verification, in case I missed > anything. > > Again crashed by an attempt to open a terminal window. Gotcha, diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c index b21322b50419..96cf46a10b4e 100644 --- a/drivers/gpu/drm/i915/i915_gem.c +++ b/drivers/gpu/drm/i915/i915_gem.c @@ -472,7 +472,7 @@ static void __fence_set_priority(struct dma_fence *fence, int prio) struct drm_i915_gem_request *rq; struct intel_engine_cs *engine; - if (!dma_fence_is_i915(fence)) + if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence)) return; rq = to_request(fence); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Thank you! I'll apply that more elaborate patch you sent in the longer message to my clone of the repo and see if it still freezes. On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-05 22:05:18) > > Here we go. > > > > I have > > > > CONFIG_PAGE_POISONING not set > > CONFIG_SLUB_STATS=y > > CONFIG_SLUB_DEBUG not set > > CONFIG_KASAN=y > > > > .config attached along as well for verification, in case I missed > > anything. > > > > Again crashed by an attempt to open a terminal window. > > Gotcha, > > diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c > index b21322b50419..96cf46a10b4e 100644 > --- a/drivers/gpu/drm/i915/i915_gem.c > +++ b/drivers/gpu/drm/i915/i915_gem.c > @@ -472,7 +472,7 @@ static void __fence_set_priority(struct dma_fence *fence, > int prio) > struct drm_i915_gem_request *rq; > struct intel_engine_cs *engine; > > - if (!dma_fence_is_i915(fence)) > + if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence)) > return; > > rq = to_request(fence); ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
On Sat, Jan 06, 2018 at 08:24:43AM -0500, Alexandru Chirvasitu wrote: > Thank you! > > I'll apply that more elaborate patch you sent in the longer message to > my clone of the repo and see if it still freezes. > I'm on it now with no freezes yet, despite trying my best :). I have a question though: > On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-05 22:05:18) > > > Here we go. > > > > > > I have > > > > > > CONFIG_PAGE_POISONING not set > > > CONFIG_SLUB_STATS=y > > > CONFIG_SLUB_DEBUG not set > > > CONFIG_KASAN=y > > > > > > .config attached along as well for verification, in case I missed > > > anything. > > > > > > Again crashed by an attempt to open a terminal window. > > > > Gotcha, > > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c > > b/drivers/gpu/drm/i915/i915_gem.c > > index b21322b50419..96cf46a10b4e 100644 > > --- a/drivers/gpu/drm/i915/i915_gem.c > > +++ b/drivers/gpu/drm/i915/i915_gem.c > > @@ -472,7 +472,7 @@ static void __fence_set_priority(struct dma_fence > > *fence, int prio) > > struct drm_i915_gem_request *rq; > > struct intel_engine_cs *engine; > > > > - if (!dma_fence_is_i915(fence)) > > + if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence)) > > return; > > > > rq = to_request(fence); I went back to Linus' tree and compared the respective i915_gem.c files in the 4.14 and 4.15-rc6 commits. The offending piece of code seems to be in both, so I am wondering why I was not getting freezes before 4.15-rc. Is the other change (in drivers/gpu/drm/i915/intel_lrc.c) crucial too? The line GEM_BUG_ON(prio == I915_PRIORITY_INVALID); is caught by the diff, so that region of *that* file differs between 4.14 and 4.15-rc. I suppose it might also be that my distro's maintainers modify the 4.14 code in some fashion; I have not checked. ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-06 16:38:35)
> On Sat, Jan 06, 2018 at 08:24:43AM -0500, Alexandru Chirvasitu wrote:
> > Thank you!
> >
> > I'll apply that more elaborate patch you sent in the longer message to
> > my clone of the repo and see if it still freezes.
> >
>
> I'm on it now with no freezes yet, despite trying my best :).
>
> I have a question though:
>
> > On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote:
> > > Quoting Alexandru Chirvasitu (2018-01-05 22:05:18)
> > > > Here we go.
> > > >
> > > > I have
> > > >
> > > > CONFIG_PAGE_POISONING not set
> > > > CONFIG_SLUB_STATS=y
> > > > CONFIG_SLUB_DEBUG not set
> > > > CONFIG_KASAN=y
> > > >
> > > > .config attached along as well for verification, in case I missed
> > > > anything.
> > > >
> > > > Again crashed by an attempt to open a terminal window.
> > >
> > > Gotcha,
> > >
> > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > b/drivers/gpu/drm/i915/i915_gem.c
> > > index b21322b50419..96cf46a10b4e 100644
> > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > @@ -472,7 +472,7 @@ static void __fence_set_priority(struct dma_fence
> > > *fence, int prio)
> > > struct drm_i915_gem_request *rq;
> > > struct intel_engine_cs *engine;
> > >
> > > - if (!dma_fence_is_i915(fence))
> > > + if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence))
> > > return;
> > >
> > > rq = to_request(fence);
>
> I went back to Linus' tree and compared the respective i915_gem.c
> files in the 4.14 and 4.15-rc6 commits. The offending piece of code
> seems to be in both, so I am wondering why I was not getting freezes before
> 4.15-rc.
Yeah, I debated adding a fixes for commit 6b5e90f58c56
("drm/i915/scheduler: Boost priorities for flips") that introduced this
code, but decided it's just an optimisation at this point and that we
should only regard commit 1f181225f8ec ("drm/i915/execlists: Keep
request->priority for its lifetime") for introducing the breakage. Prior
to commit 1f18122 the guard at the start of execlists_schedule(prio <=
rq->priotree.priority) is sufficient to avoid manipulating retired
fences, and so we were avoiding this bug.
-Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Thanks!
It's also a mystery to me why I never had any crashes on any of the
other systems running on this machine running the same (unpatched)
kernels.
I'm assuming the window manager might have something to do with it:
all of the others are on i3 and the buggy one's openbox, so perhaps
tiling vs. stacking makes a difference?
The one pattern I noticed to the crashes was that they occurred upon
opening a new window.
On Sat, Jan 06, 2018 at 05:34:51PM +, Chris Wilson wrote:
> Quoting Alexandru Chirvasitu (2018-01-06 16:38:35)
> > On Sat, Jan 06, 2018 at 08:24:43AM -0500, Alexandru Chirvasitu wrote:
> > > Thank you!
> > >
> > > I'll apply that more elaborate patch you sent in the longer message to
> > > my clone of the repo and see if it still freezes.
> > >
> >
> > I'm on it now with no freezes yet, despite trying my best :).
> >
> > I have a question though:
> >
> > > On Sat, Jan 06, 2018 at 10:43:20AM +, Chris Wilson wrote:
> > > > Quoting Alexandru Chirvasitu (2018-01-05 22:05:18)
> > > > > Here we go.
> > > > >
> > > > > I have
> > > > >
> > > > > CONFIG_PAGE_POISONING not set
> > > > > CONFIG_SLUB_STATS=y
> > > > > CONFIG_SLUB_DEBUG not set
> > > > > CONFIG_KASAN=y
> > > > >
> > > > > .config attached along as well for verification, in case I missed
> > > > > anything.
> > > > >
> > > > > Again crashed by an attempt to open a terminal window.
> > > >
> > > > Gotcha,
> > > >
> > > > diff --git a/drivers/gpu/drm/i915/i915_gem.c
> > > > b/drivers/gpu/drm/i915/i915_gem.c
> > > > index b21322b50419..96cf46a10b4e 100644
> > > > --- a/drivers/gpu/drm/i915/i915_gem.c
> > > > +++ b/drivers/gpu/drm/i915/i915_gem.c
> > > > @@ -472,7 +472,7 @@ static void __fence_set_priority(struct dma_fence
> > > > *fence, int prio)
> > > > struct drm_i915_gem_request *rq;
> > > > struct intel_engine_cs *engine;
> > > >
> > > > - if (!dma_fence_is_i915(fence))
> > > > + if (dma_fence_is_signaled(fence) || !dma_fence_is_i915(fence))
> > > > return;
> > > >
> > > > rq = to_request(fence);
> >
> > I went back to Linus' tree and compared the respective i915_gem.c
> > files in the 4.14 and 4.15-rc6 commits. The offending piece of code
> > seems to be in both, so I am wondering why I was not getting freezes before
> > 4.15-rc.
>
> Yeah, I debated adding a fixes for commit 6b5e90f58c56
> ("drm/i915/scheduler: Boost priorities for flips") that introduced this
> code, but decided it's just an optimisation at this point and that we
> should only regard commit 1f181225f8ec ("drm/i915/execlists: Keep
> request->priority for its lifetime") for introducing the breakage. Prior
> to commit 1f18122 the guard at the start of execlists_schedule(prio <=
> rq->priotree.priority) is sufficient to avoid manipulating retired
> fences, and so we were avoiding this bug.
> -Chris
___
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-06 18:44:29) > Thanks! > > It's also a mystery to me why I never had any crashes on any of the > other systems running on this machine running the same (unpatched) > kernels. > > I'm assuming the window manager might have something to do with it: > all of the others are on i3 and the buggy one's openbox, so perhaps > tiling vs. stacking makes a difference? It just takes the right pattern of activity. The logic upon retiring a request does try to strip the fences from all the objects listening to the fence, but we can only do that so long as all the fences on the object have been signaled. So for starters, it needs an object being used by multiple timelines (different processes and/or engines) and then retirement has to be run at just the right frequency to not see all of those fences not to be completed. (Even more for this failure, it must have a retired exclusive/write fence paired with active shared/read fences.) It is that timing issue that has made it so rare, it's a pattern that we definitely do not expose in our testing. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Got it. I suppose that explains why it was so unreliably reproducible.. In any case, the patch is holding strong still with plenty of activity since, so it's looking good. Thak you for all of this; very instructive. On Sat, Jan 06, 2018 at 08:55:00PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-06 18:44:29) > > Thanks! > > > > It's also a mystery to me why I never had any crashes on any of the > > other systems running on this machine running the same (unpatched) > > kernels. > > > > I'm assuming the window manager might have something to do with it: > > all of the others are on i3 and the buggy one's openbox, so perhaps > > tiling vs. stacking makes a difference? > > It just takes the right pattern of activity. The logic upon retiring a > request does try to strip the fences from all the objects listening to > the fence, but we can only do that so long as all the fences on the > object have been signaled. So for starters, it needs an object being > used by multiple timelines (different processes and/or engines) and then > retirement has to be run at just the right frequency to not see all of > those fences not to be completed. (Even more for this failure, it must > have a retired exclusive/write fence paired with active shared/read > fences.) It is that timing issue that has made it so rare, it's a > pattern that we definitely do not expose in our testing. > -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2017-12-30 17:31:32) > Short description: I get freezes of my desktop completely eliminating > mouse / keyboard functionality. > > I’m on an UltraLap 5330, Processor: i7-7500U, Memory: 32 GB DDR4-2133 > Video Card: Intel HD (included). It's running Void linux 64 bit. That > distro's latest kernel is 4.14.8, but I've been trying out the 4.15-rc > kernels. This has happened with rc3, rc4 and currently rc5. > > I can ssh into the frozen machine and roam around freely. Xorg shows > as when I do, and nothing I have tried on the command line > has succeeded in restroing functionality (killing processes, changing > runlevels, etc.; there's no visible response from the computer). Only > reboots resolve the matter (button reboots or issued as commands > through ssh). > > While ssh-d in I can get the dmesg log, which is attached. The > relevant portion is presumably the trace at the very end. I can't find how this can happen, the lists here are serialized by struct_mutex. (The poison would indicate that the elements p->dfs_link points to are freed, not p itself.) If you could run with lockdep (to verify that the locks are indeed held here) and kasan to find the alloc/free of the struct being used-after-free, that would be extremely valuable. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2017-12-31 16:52:36) > I see lockdep is configured (though I'm not familiar with the feature; > the config came with it, and I made oldconfig), but I'll need to > recompile for kasan. > > I'll do that over the next few days, but once done, what would I get > back to you with? Again logs if / when the problem occurs? I'm still > unable to trigger it reliably. The new dmesg, I expect kasan will print a few warnings before it oopses again. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Compiled a couple of kernels with kasan enabled. I don't yet have a crash, but on the system that has been crashing I have the following kasan distress signals on bootup (dmesg attached): [0.027746] == [0.027759] BUG: KASAN: use-after-free in kernel_poison_pages+0xa6/0x140 [0.027765] Write of size 4096 at addr 88080b39 by task swapper/0/1 [0.027774] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.15.0-rc5-x-void #1 [0.027775] Hardware name: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [0.027776] Call Trace: [0.027782] dump_stack+0x5c/0x7a [0.027785] print_address_description+0x6b/0x290 [0.027787] kasan_report+0x28f/0x380 [0.027790] ? kernel_poison_pages+0xa6/0x140 [0.027792] memset+0x1f/0x40 [0.027795] kernel_poison_pages+0xa6/0x140 [0.027798] __free_pages_ok+0x14c/0x460 [0.027802] release_pebs_buffer+0xae/0xd0 [0.027804] release_ds_buffers+0x9c/0x110 [0.027808] x86_release_hardware+0x86/0xa0 [0.027810] hw_perf_event_destroy+0xa/0x20 [0.027813] _free_event+0x179/0x540 [0.027816] perf_event_release_kernel+0x21e/0x3a0 [0.027819] ? perf_event_create_kernel_counter+0x15a/0x190 [0.027823] hardlockup_detector_perf_init+0x2c/0x3c [0.027826] lockup_detector_init+0x24/0x7e [0.027829] kernel_init_freeable+0x152/0x2f5 [0.027831] ? rest_init+0xd0/0xd0 [0.027833] kernel_init+0xf/0x11a [0.027835] ? rest_init+0xd0/0xd0 [0.027837] ret_from_fork+0x1f/0x30 [0.027842] The buggy address belongs to the page: [0.027848] page:ae05d3d5 count:0 mapcount:0 mapping: (null) index:0x0 [0.027854] flags: 0x17ffe00() [0.027860] raw: 017ffe00 [0.027867] raw: dead0100 dead0200 [0.027872] page dumped because: kasan: bad access detected [0.027878] Memory state around the buggy address: [0.027883] 88080b38ff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.027889] 88080b38ff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 [0.027895] >88080b39: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.027900]^ [0.027904] 88080b390080: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.027912] 88080b390100: ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff [0.027917] == [0.027923] Disabling lock debugging due to kernel taint I'll follow up on the crashes when they happen, but I thought this might be of some use. Incidentally, I've compiled two kernels with kasan on: one using the bad system's config (with make oldconfig), and one using the one on the system that doesn't crash on the same machine. The latter does *not* spit out the trace in dmesg (regardless of which system I boot it on), while the former only complains on the bad system (boots fine on the good OS). So it must be specific to the kernel configuration + kernel parameters, but I don't know how. I haven't mesed with the kernel parameters myself: they are whatever the two respective GRUB installations came with by default on the two systems. I can attach whatever's needed and try out whatever you think might be helpful, but I figured I'd keep the message light with just the kasan trace dmesg attachment. On Sun, Dec 31, 2017 at 04:54:14PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2017-12-31 16:52:36) > > I see lockdep is configured (though I'm not familiar with the feature; > > the config came with it, and I made oldconfig), but I'll need to > > recompile for kasan. > > > > I'll do that over the next few days, but once done, what would I get > > back to you with? Again logs if / when the problem occurs? I'm still > > unable to trigger it reliably. > > The new dmesg, I expect kasan will print a few warnings before it oopses > again. > -Chris [0.00] microcode: microcode updated early to revision 0x62, date = 2017-04-27 [0.00] Linux version 4.15.0-rc5-x-void (root@axiomatic) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Sun Dec 31 17:02:30 EST 2017 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc5-x-void root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P page_poison=1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstat
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
All right, we're in business with the new dmesg: It hung again, with a 4.15-rc6 kernel with kasan support. The new dmesg is attached; the trace is longer now, as you expected. And thanks! On Sun, Dec 31, 2017 at 04:54:14PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2017-12-31 16:52:36) > > I see lockdep is configured (though I'm not familiar with the feature; > > the config came with it, and I made oldconfig), but I'll need to > > recompile for kasan. > > > > I'll do that over the next few days, but once done, what would I get > > back to you with? Again logs if / when the problem occurs? I'm still > > unable to trigger it reliably. > > The new dmesg, I expect kasan will print a few warnings before it oopses > again. > -Chris [0.00] microcode: microcode updated early to revision 0x62, date = 2017-04-27 [0.00] Linux version 4.15.0-rc6-x-void (root@axiomatic) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Sun Dec 31 18:23:05 EST 2017 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P page_poison=1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00C000 mask 7FC000 uncachable [0.00] 1 base 00A000 mask 7FE000 uncachable [0.00] 2 base 009000 mask 7FF000 uncachable [0.00] 3 base 008E00 mask 7FFE00 uncachable [0.00] 4 base 008D80 mask 7FFF80 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [0.00] 9 disabled [0.00] x86/PAT: Configuration [0-7]: WB WC UC- UC WB WP UC- WT [0.00] e820: last_pfn = 0x8d3ff max_arch_pfn = 0x4 [0.00] found SMP MP-table at [mem 0x000fccb0-0x000fccbf] mapp
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > All right, we're in business with the new dmesg: It hung again, with a > 4.15-rc6 kernel with kasan support. > > The new dmesg is attached; the trace is longer now, as you expected. Ok, still the same poison but kasan didn't report a use-after-free. Odd. Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop anyone else from overwriting the i915_dependency. -Chris ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
Attached. Crashed quite a bit faster than before this time. It always seems to have something to do with opening and alt-tabbing between windows. This time what produced the crash was an attempt to open a new terminal. The hanging happened right after issuing the keyboard shortcut, before the focus had time to switch to the newly-opened terminal window. Still unable to crash it reliably though, so there's no telling how promptly I can produce these. On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote: > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > > All right, we're in business with the new dmesg: It hung again, with a > > 4.15-rc6 kernel with kasan support. > > > > The new dmesg is attached; the trace is longer now, as you expected. > > Ok, still the same poison but kasan didn't report a use-after-free. Odd. > > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop > anyone else from overwriting the i915_dependency. > -Chris [0.00] microcode: microcode updated early to revision 0x62, date = 2017-04-27 [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue Jan 2 13:03:34 EST 2018 [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P page_poison=1 [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 bytes, using 'compacted' format. [0.00] e820: BIOS-provided physical RAM map: [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved [0.00] BIOS-e820: [mem 0xff00-0x] reserved [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable [0.00] NX (Execute Disable) protection: active [0.00] random: fast init done [0.00] SMBIOS 3.0.0 present. [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS 5.12 02/17/2017 [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved [0.00] e820: remove [mem 0x000a-0x000f] usable [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 [0.00] MTRR default type: write-back [0.00] MTRR fixed ranges enabled: [0.00] 0-9 write-back [0.00] A-B uncachable [0.00] C-F write-protect [0.00] MTRR variable ranges enabled: [0.00] 0 base 00C000 mask 7FC000 uncachable [0.00] 1 base 00A000 mask 7FE000 uncachable [0.00] 2 base 009000 mask 7FF000 uncachable [0.00] 3 base 008E00 mask 7FFE00 uncachable [0.00] 4 base 008D80 mask 7FFF80 uncachable [0.00] 5 disabled [0.00] 6 disabled [0.00] 7 disabled [0.00] 8 disabled [
Re: [Intel-gfx] PROBLEM: i915 causes complete desktop freezes in 4.15-rc5
For comparison, here's another one produced by the same kernel, on the same laptop, but a different hard drive. The OS was installed on a USB stick that I'd boot the laptop off of. Recently I started getting lags when copying to / from the stick, so I moved the OS to an external SSD. Everything else stayed the same, and booting the same kernel resulted in the same type of freeze. On Tue, Jan 02, 2018 at 04:39:22PM -0500, Alexandru Chirvasitu wrote: > Attached. Crashed quite a bit faster than before this time. > > It always seems to have something to do with opening and alt-tabbing > between windows. This time what produced the crash was an attempt to > open a new terminal. > > The hanging happened right after issuing the keyboard shortcut, before > the focus had time to switch to the newly-opened terminal window. > > Still unable to crash it reliably though, so there's no telling how > promptly I can produce these. > > > > > On Tue, Jan 02, 2018 at 04:53:45PM +, Chris Wilson wrote: > > Quoting Alexandru Chirvasitu (2018-01-01 21:13:57) > > > All right, we're in business with the new dmesg: It hung again, with a > > > 4.15-rc6 kernel with kasan support. > > > > > > The new dmesg is attached; the trace is longer now, as you expected. > > > > Ok, still the same poison but kasan didn't report a use-after-free. Odd. > > > > Can you disable CONFIG_SLAB_MERGE_DEFAULT and try again? This will stop > > anyone else from overwriting the i915_dependency. > > -Chris > [0.00] microcode: microcode updated early to revision 0x62, date = > 2017-04-27 > [0.00] Linux version 4.15.0-rc6-x-void-noslb (root@axiomatic) (gcc > version 5.4.0 20160609 (Ubuntu 5.4.0-6ubuntu1~16.04.5)) #1 SMP PREEMPT Tue > Jan 2 13:03:34 EST 2018 > [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.15.0-rc6-x-void-noslb > root=UUID=66d5a55f-8ca3-47a1-850d-a0886325481c ro loglevel=4 slub_debug=P > page_poison=1 > [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point > registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x002: 'SSE registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x004: 'AVX registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x008: 'MPX bounds registers' > [0.00] x86/fpu: Supporting XSAVE feature 0x010: 'MPX CSR' > [0.00] x86/fpu: xstate_offset[2]: 576, xstate_sizes[2]: 256 > [0.00] x86/fpu: xstate_offset[3]: 832, xstate_sizes[3]: 64 > [0.00] x86/fpu: xstate_offset[4]: 896, xstate_sizes[4]: 64 > [0.00] x86/fpu: Enabled xstate features 0x1f, context size is 960 > bytes, using 'compacted' format. > [0.00] e820: BIOS-provided physical RAM map: > [0.00] BIOS-e820: [mem 0x-0x0009c3ff] usable > [0.00] BIOS-e820: [mem 0x0009c400-0x0009] reserved > [0.00] BIOS-e820: [mem 0x000e-0x000f] reserved > [0.00] BIOS-e820: [mem 0x0010-0x86ebbfff] usable > [0.00] BIOS-e820: [mem 0x86ebc000-0x871bbfff] ACPI NVS > [0.00] BIOS-e820: [mem 0x871bc000-0x880e2fff] usable > [0.00] BIOS-e820: [mem 0x880e3000-0x880e3fff] ACPI NVS > [0.00] BIOS-e820: [mem 0x880e4000-0x880e4fff] reserved > [0.00] BIOS-e820: [mem 0x880e5000-0x8c227fff] usable > [0.00] BIOS-e820: [mem 0x8c228000-0x8cb97fff] reserved > [0.00] BIOS-e820: [mem 0x8cb98000-0x8cc67fff] usable > [0.00] BIOS-e820: [mem 0x8cc68000-0x8cfe1fff] ACPI NVS > [0.00] BIOS-e820: [mem 0x8cfe2000-0x8d3fdfff] reserved > [0.00] BIOS-e820: [mem 0x8d3fe000-0x8d3fefff] usable > [0.00] BIOS-e820: [mem 0x8d3ff000-0x8fff] reserved > [0.00] BIOS-e820: [mem 0xe000-0xefff] reserved > [0.00] BIOS-e820: [mem 0xfe00-0xfe010fff] reserved > [0.00] BIOS-e820: [mem 0xfec0-0xfec00fff] reserved > [0.00] BIOS-e820: [mem 0xfed0-0xfed00fff] reserved > [0.00] BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > [0.00] BIOS-e820: [mem 0xff00-0x] reserved > [0.00] BIOS-e820: [mem 0x0001-0x00086eff] usable > [0.00] NX (Execute Disable) protection: active > [0.00] random: fast init done > [0.00] SMBIOS 3.0.0 present. > [0.00] DMI: Notebook N24_25BU/N24_25BU, BIOS > 5.12 02/17/2017 > [0.00] e820: update [mem 0x-0x0fff] usable ==> reserved > [0.00] e820: remove [mem 0x000a-0x000f] usable > [0.00] e820: last_pfn = 0x86f000 max_arch_pfn = 0x4 > [0.00] MTRR default type: write-back > [0.00] MTRR
