[Bug 984047] New: BUG: unable to handle kernel NULL pointer dereference at (null)
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 Bug ID: 984047 Summary: BUG: unable to handle kernel NULL pointer dereference at (null) Classification: openSUSE Product: openSUSE Distribution Version: Leap 42.1 Hardware: x86-64 OS: openSUSE 42.1 Status: NEW Severity: Critical Priority: P5 - None Component: Kernel Assignee: kernel-maintainers@forge.provo.novell.com Reporter: vanjab@icetec.com QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- On the latest Leap(4.1.21-14-xen) running Xen kernel we get deadlocks when switching console (either by Ctl-Alt-F1, or by logging out in graphical session). Reproduce by: a) start with xen kernel b) once up and showing login screen try to switch to textual console via Ctl-Alt-Fn c) or graphically login and then log out (logout seems to trigger console switch) Locked processes (and the whole GUI and eventually the server): /sbin/agetty /sbin/showconsole Kernel has an error in the log: Jun 08 14:46:29 az-waltham-push kernel: BUG: unable to handle kernel NULL pointer dereference at (null) Jun 08 14:46:29 az-waltham-push kernel: IP: [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: PGD ec58e067 PUD f8839067 PMD 0 Jun 08 14:46:29 az-waltham-push kernel: Oops: 0010 [#1] SMP Jun 08 14:46:29 az-waltham-push kernel: Modules linked in: bnep bluetooth rfkill tun ebtable_filter ebtables ip6table_filter ip6_tables iptable_filter ip_tables x_tables af_packet bridge stp llc iscsi_ibft iscsi_boot_sysfs xfs libcrc32c blktap blktap2 ipmi_ssif pciback coretemp crc Jun 08 14:46:29 az-waltham-push kernel: crc32c_intel ttm xhci_pci ehci_pci ehci_hcd xhci_hcd drm i2c_core usbcore usb_common sg Jun 08 14:46:29 az-waltham-push kernel: CPU: 6 PID: 1749 Comm: X Not tainted 4.1.21-14-xen #1 Jun 08 14:46:29 az-waltham-push kernel: Hardware name: Silicon Mechanics Rackform iServ R135.v5.1/X10SLM+-LN4F, BIOS 3.0 04/24/2015 Jun 08 14:46:29 az-waltham-push kernel: task: ffff8801d6f5a3d0 ti: ffff8801cdb7c000 task.ti: ffff8801cdb7c000 Jun 08 14:46:29 az-waltham-push kernel: RIP: e030:[<0000000000000000>] [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: RSP: e02b:ffff8801cdb7f3d0 EFLAGS: 00010206 Jun 08 14:46:29 az-waltham-push kernel: RAX: 4000000001000000 RBX: ffff8801e97d39c0 RCX: 0000000000000002 Jun 08 14:46:29 az-waltham-push kernel: RDX: 4000000001000000 RSI: 0000000000000000 RDI: ffff8801e97d39c0 Jun 08 14:46:29 az-waltham-push kernel: RBP: ffff8801e58d1000 R08: 00000000000f6fff R09: 000000000000003c Jun 08 14:46:29 az-waltham-push kernel: R10: 0000000000007ff0 R11: ffffffffa00891b9 R12: ffff8801e97d39c0 Jun 08 14:46:29 az-waltham-push kernel: R13: 0000000000000000 R14: 00000000000007e9 R15: 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: FS: 00007f70bba028c0(0000) GS:ffff8801e4780000(0000) knlGS:0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: CS: e033 DS: 0000 ES: 0000 CR0: 0000000080050033 Jun 08 14:46:29 az-waltham-push kernel: CR2: 0000000000000000 CR3: 00000001cc57d000 CR4: 0000000000042660 Jun 08 14:46:29 az-waltham-push kernel: Stack: Jun 08 14:46:29 az-waltham-push kernel: ffffffff8013c1ed 0000000000000001 ffffffff8004eeb9 00000000f6005000 Jun 08 14:46:29 az-waltham-push kernel: ffffc90001800000 00000000f67ee000 ffff8801e97d39c0 ffff8801e58d1000 Jun 08 14:46:29 az-waltham-push kernel: 0000000000000000 4000000001000000 00000000000007e9 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: Call Trace: Jun 08 14:46:29 az-waltham-push kernel: Inexact backtrace: Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8013c1ed>] ? free_pages_prepare+0x1dd/0x2d0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8004eeb9>] ? iomem_map_sanity_check+0x89/0xd0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8013d176>] ? free_hot_cold_page+0x26/0x1a0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa008cbd2>] ? ttm_put_pages+0x152/0x1c0 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0084384>] ? ttm_mem_global_free_zone+0x24/0x80 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa008cc99>] ? ttm_pool_unpopulate+0x59/0x70 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00851ed>] ? ttm_tt_destroy+0x5d/0x70 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00898c1>] ? ttm_bo_move_memcpy+0x361/0x630 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8001377e>] ? __switch_to+0x22e/0x940 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801718ad>] ? free_vmap_area_noflush+0x2d/0x60 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0086f86>] ? ttm_bo_handle_move_mem+0x256/0x5b0 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0087a11>] ? ttm_bo_mem_space+0x181/0x350 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00880c8>] ? ttm_bo_validate+0x1e8/0x200 [ttm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa01214ca>] ? ast_bo_pin+0x7a/0xa0 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011f077>] ? ast_crtc_do_set_base.isra.14.constprop.24+0xe7/0x390 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011d2b5>] ? ast_set_index_reg_mask+0x45/0x70 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa011feac>] ? ast_crtc_mode_set+0xb8c/0xc90 [ast] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00e08fb>] ? drm_crtc_helper_set_mode+0x2eb/0x520 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00e197b>] ? drm_crtc_helper_set_config+0x8bb/0xae0 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa01476d8>] ? drm_mode_set_config_internal+0x68/0x100 [drm] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ec280>] ? restore_fbdev_mode+0xc0/0xe0 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ee130>] ? drm_fb_helper_restore_fbdev_mode_unlocked+0x20/0x60 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa00ee192>] ? drm_fb_helper_set_par+0x22/0x50 [drm_kms_helper] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80386d2e>] ? fb_set_var+0x15e/0x3b0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa0291de5>] ? btrfs_buffer_uptodate+0x55/0x80 [btrfs] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffffa02b0fe7>] ? btrfs_get_token_32+0x57/0xf0 [btrfs] Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8037e10b>] ? fbcon_blank+0x1cb/0x2b0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803fac05>] ? do_unblank_screen+0xa5/0x1c0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803f1414>] ? vt_ioctl+0x584/0x10f0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8003cdcc>] ? ptep_set_access_flags+0x4c/0x80 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80161ef5>] ? do_wp_page+0x235/0x650 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff803e4647>] ? tty_ioctl+0x207/0xd30 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801644b5>] ? handle_mm_fault+0xdc5/0x1920 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a41df>] ? do_vfs_ioctl+0x2ff/0x520 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff8031af99>] ? lockref_put_or_lock+0x9/0x50 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a870e>] ? dput+0x10e/0x220 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff800e10cc>] ? __audit_syscall_entry+0xac/0xf0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80022bfb>] ? syscall_trace_enter_phase1+0xfb/0x160 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff801a4481>] ? SyS_ioctl+0x81/0xa0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff80064f7c>] ? task_work_run+0xac/0xe0 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff805f205d>] ? system_call_fastpath+0x16/0x76 Jun 08 14:46:29 az-waltham-push kernel: [<ffffffff805f2010>] ? __entry_text_start+0x8/0x8 Jun 08 14:46:29 az-waltham-push kernel: Code: Bad RIP value. Jun 08 14:46:29 az-waltham-push kernel: RIP [< (null)>] (null) Jun 08 14:46:29 az-waltham-push kernel: RSP <ffff8801cdb7f3d0> Jun 08 14:46:29 az-waltham-push kernel: CR2: 0000000000000000 Jun 08 14:46:29 az-waltham-push kernel: ---[ end trace dddd722ac706bdd1 ]--- Hardware: - as you can see from the log above, it is a plain Silicon Mechanics server with supermicro X10SLM+-LN4F motherboard (ASpeed VGA controller) Tried on multiple servers in case hardware was to blame, but it always locked just the same. I can provide more info if needed. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 http://bugzilla.opensuse.org/show_bug.cgi?id=984047#c1 Takashi Iwai <tiwai@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com, | |vanjab@icetec.com Flags| |needinfo?(vanjab@icetec.com | |) --- Comment #1 from Takashi Iwai <tiwai@suse.com> --- Thank your for a report. Could you give a few more information? - Does this happen only with Xen kernel, or does it happen with kernel-default? Also what about kernel-vanilla? - Is it a regression from the earlier 4.1.x kernel? - Is it a regression from earlier distro releases? Also, just to be sure, please confirm whether the problem persists with the latest 4.1.x kernel in OBS Kernel:openSUSE-42.1 repo: http://download.opensuse.org/repositories/Kernel:/openSUSE-42.1/standard/ -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 http://bugzilla.opensuse.org/show_bug.cgi?id=984047#c2 --- Comment #2 from Vanja Bucic <vanjab@icetec.com> --- - Seems to have issues only on Xen kernel - Don't know if it is a regression from an earlier version, we have been using only SLES11 and SLES12 so far - regarding trying a kernel from different repo, I won't be able to try it in the next 2 weeks as schedule won't allow it. We were in a bind so we opted for vmware player for this server. We never had any issues with Xen and SLES11/12, and we were unpleasantly surprised with fragility of Leap (like the inability to unlock Gnome GUI session after it is locked due to inactivity). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 http://bugzilla.opensuse.org/show_bug.cgi?id=984047#c3 --- Comment #3 from Takashi Iwai <tiwai@suse.com> --- (In reply to Vanja Bucic from comment #2)
- Seems to have issues only on Xen kernel
So, it doesn't happen if you run 4.1.x kernel-default, right?
- Don't know if it is a regression from an earlier version, we have been using only SLES11 and SLES12 so far
You didn't test the older 4.1.x kernels? The first kernel on Leap is 4.1.12. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 http://bugzilla.opensuse.org/show_bug.cgi?id=984047#c4 --- Comment #4 from Vanja Bucic <vanjab@icetec.com> --- (In reply to Takashi Iwai from comment #3)
(In reply to Vanja Bucic from comment #2)
- Seems to have issues only on Xen kernel
So, it doesn't happen if you run 4.1.x kernel-default, right?
- Don't know if it is a regression from an earlier version, we have been using only SLES11 and SLES12 so far
You didn't test the older 4.1.x kernels? The first kernel on Leap is 4.1.12.
- It does not happen on the default kernel, only after we boot with the Xen kernel. - Did not test with older kernels. We run a default install with update repos enabled, so we start with the most up-to-date 42.1 version. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=984047 Marc Menges <m.menges@seam.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |m.menges@seam.de -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com