From owner-freebsd-current@freebsd.org Thu Sep 26 20:51:42 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B974C134224 for ; Thu, 26 Sep 2019 20:51:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: from mail-oi1-f196.google.com (mail-oi1-f196.google.com [209.85.167.196]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 46fRtQ5CZCz3xY3; Thu, 26 Sep 2019 20:51:42 +0000 (UTC) (envelope-from asomers@gmail.com) Received: by mail-oi1-f196.google.com with SMTP id w17so3330918oiw.8; Thu, 26 Sep 2019 13:51:42 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sLX2NWT2NJPRs/dGvFJdWXDVqfFpFyidGDbOH8Kbvc0=; b=c66SmPx7NwVa6RYtIHyi/E0ER8wUbUwb6q9GFs5CSS2hkPoCFbI2pNwpuu+wea5tqj C4Qyj+DXm7tQoaIfxDkozVLlOzDhPiPiFJkTqVlP3pmzrNpehP5jbZUYJf3HZuyLOhYT AwBzNbBqA6yyEu01IQ7tYxWnMDdhFQuxL5ozAD88G/DYXPedU2Uc1zTLD0Y/17jHA1Zm Yxw5tG1d1yLNY/1ySIZiZ4iTsBFctm8FPl45xdMvkBq4iXpWOcnF6UvKUMfzO0tkMT76 xDiuNw+vsxuKR9Ce1vDg7Eb9YS+94a99Ip9khIQNlZOWmCaAcx+6rWLxVefUVfd88QkU EfAg== X-Gm-Message-State: APjAAAU5lNytj2psmPWHAIIXYeZtjSO9ropEjpyJCq5SSN7Fc0BevJAf 9UoRDWjodNV/Xl8C5V1dqWgl2WNhA7CEJ3XQqO+OFshUXu0= X-Google-Smtp-Source: APXvYqz7bn4pHKBH60B2yVGLvI8Zqh+J7eStY/RJlJD3hjpzDnun3+yEvzHN+Fwf5yRmV7nBJfpA0CP6IFgxz9XoFiY= X-Received: by 2002:aca:3a08:: with SMTP id h8mr3940145oia.55.1569531100716; Thu, 26 Sep 2019 13:51:40 -0700 (PDT) MIME-Version: 1.0 References: <20190926170241.GG44691@kib.kiev.ua> <20190926172924.GH44691@kib.kiev.ua> In-Reply-To: From: Alan Somers Date: Thu, 26 Sep 2019 14:51:29 -0600 Message-ID: Subject: Re: panic: Unregistered use of FPU in kernel To: "Conrad E. Meyer" Cc: Konstantin Belousov , FreeBSD CURRENT X-Rspamd-Queue-Id: 46fRtQ5CZCz3xY3 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-6.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-0.999,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 26 Sep 2019 20:51:42 -0000 You're right, cem. gdb and ddb show the same data. Here it is from gdb: 0xffffffff8113b30e : 0xf2 0x48 0x0f 0x38 0xf1 0xde 0xf2 0x48 0xffffffff8113b316 : 0x0f 0x38 0xf1 0xc7 0x48 0x8b 0x32 0xf2 0xffffffff8113b31e : 0x4c 0x0f 0x38 0xf1 0xde 0x48 0x8d 0x72 0xffffffff8113b326 : 0x08 0x48 0x81 0xc2 0x08 0xff 0xff 0xff 0xffffffff8113b32e : 0x4c 0x39 0xca 0x72 0xcd 0x44 0x0f 0xb6 0xffffffff8113b336 : 0xc9 0x0f 0xb6 0xfd 0x89 0xca 0xc1 0xea 0xffffffff8113b33e : 0x10 0x0f 0xb6 0xd2 0xc1 0xe9 0x18 0x42 0xffffffff8113b346 : 0x33 0x1c 0x8d 0x80 0x11 0xf9 0x81 0x33 Here are the last few console messages from before the panic: virtio_pci1: port 0xc000-0xc03f mem 0xfc098000-0xfc 098fff,0xfebf4000-0xfebf7fff irq 10 at device 6.0 on pci0 virtio_pci2: port 0xc040-0xc07f mem 0xfc099000-0xfc09 9fff,0xfebf8000-0xfebfbfff irq 11 at device 7.0 on pci0 vtblk0: on virtio_pci2 vtblk0: 34816MB (71303296 512 byte sectors) virtio_pci3: port 0xc120-0xc13f mem 0xfebfc000-0xfe bfffff irq 11 at device 8.0 on pci0 vtballoon0: on virtio_pci3 acpi_syscontainer0: on acpi0 acpi_syscontainer1: port 0xaf00-0xaf0b on acpi0 acpi_syscontainer2: port 0xafe0-0xafe3 on acpi0 acpi_syscontainer3: port 0xae00-0xae13 on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 atkbd0: irq 1 on atkbdc0 panic: Unregistered use of FPU in kernel On Thu, Sep 26, 2019 at 2:19 PM Conrad Meyer wrote: > This kinda just looks like ddb doesn't know how to disassemble crc32q? > Which might not be too surprising. > > Note that it also truncates the qword constant in "add" at +167/+0xa7. > That one isn't corruption; just a DDB bug. > > Can you print the faulting %rip and dump a few bytes at that address > in both ddb and gdb (assuming ddb can't disassemble crc32q)? > > Best, > Conrad > > On Thu, Sep 26, 2019 at 1:12 PM Alan Somers wrote: > > > > On Thu, Sep 26, 2019 at 11:29 AM Konstantin Belousov < > kostikbel@gmail.com> > > wrote: > > > > > On Thu, Sep 26, 2019 at 11:20:51AM -0600, Alan Somers wrote: > > > > On Thu, Sep 26, 2019 at 11:02 AM Konstantin Belousov < > > > kostikbel@gmail.com> > > > > wrote: > > > > > > > > > On Thu, Sep 26, 2019 at 09:45:43AM -0600, Alan Somers wrote: > > > > > > The latest VM snapshot > > > > > (FreeBSD-13.0-CURRENT-amd64-20190920-r352544.qcow2) > > > > > > instapanics on boot: > > > > > > > > > > > > panic: Unregistered use of FPU in kernel > > > > > > > > > > > > stack trace: > > > > > > ... > > > > > > sse42_crc32c > > > > > > readsuper > > > > > > ffs_sbget > > > > > > g_label_ufs_taste_common > > > > > > g_label_taste > > > > > > g_new_provider_event > > > > > > g_run_events > > > > > > fork_exit > > > > > > ... > > > > > > > > > > > > Has anybody touched this area recently? I'll try to narrow down > the > > > > > commit > > > > > > range. > > > > > > > > > > Start with disassembling the faulting instruction. I suspect that > > > somehow > > > > > vital compiler switches like -mno-sse got omitted in the build. > > > > > > > > > > > > > No problem with compiler switches here. The C file uses inline > assembly > > > to > > > > generate a crc32q instruction, in crc32_sse42.c:257. But why would > that > > > > generate a floating point exception? The instruction doesn't appear > to > > > be > > > > using any floating point registers. This is on a Kaby Lake CPU. > > > > > > > > crc32q %rsi, %rbx > > > > > > No idea, this instruction does not generate #NP at all. > > > > > > Provide exact script of the panic and backtrace, > > > together with the disassembly of the function which contained the > faulted > > > instruction. Do disassemble from ddb, in case text was corrupted. > > > > > > > Ok, here's the full stack trace: > > #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > > #1 doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:392 > > #2 0xffffffff804a1edb in db_dump (dummy=, > > dummy2=, dummy3=, dummy4=) > > at /usr/src/sys/ddb/db_command.c:575 > > #3 0xffffffff804a1c8f in db_command (last_cmdp=, > > cmd_table=, dopager=1) at > > /usr/src/sys/ddb/db_command.c:482 > > #4 0xffffffff804a1a04 in db_command_loop () > > at /usr/src/sys/ddb/db_command.c:535 > > #5 0xffffffff804a4cbf in db_trap (type=, code= > out>) > > at /usr/src/sys/ddb/db_main.c:252 > > #6 0xffffffff80c1e55c in kdb_trap (type=3, code=0, tf=) > > at /usr/src/sys/kern/subr_kdb.c:692 > > #7 0xffffffff811957df in trap (frame=0xfffffe00907e8d20) > > at /usr/src/sys/amd64/amd64/trap.c:621 > > #8 > > > > Your guess about corrupted text was prescient. Here is the disassembly > > according to ddb: > > > https://people.freebsd.org/~asomers/Screenshot_fbsd-head_2019-09-26_13%3A51%3A34.png > > And here is the disassembly of the same section according to gdb: > > 0xffffffff8113b2e0 : mov %rsi,%r9 > > 0xffffffff8113b2e3 : sub $0xffffffffffffff80,%r9 > > 0xffffffff8113b2e7 : add $0x100,%rsi > > 0xffffffff8113b2ee : mov %r11,%rbx > > 0xffffffff8113b2f1 : xor %eax,%eax > > 0xffffffff8113b2f3 : xor %r11d,%r11d > > 0xffffffff8113b2f6 : nopw %cs:0x0(%rax,%rax,1) > > 0xffffffff8113b300 : mov %rsi,%rdx > > 0xffffffff8113b303 : mov -0x100(%rsi),%rsi > > 0xffffffff8113b30a : mov -0x80(%rdx),%rdi > > 0xffffffff8113b30e : crc32q %rsi,%rbx > > 0xffffffff8113b314 : crc32q %rdi,%rax > > 0xffffffff8113b31a : mov (%rdx),%rsi > > 0xffffffff8113b31d : crc32q %rsi,%r11 > > 0xffffffff8113b323 : lea 0x8(%rdx),%rsi > > 0xffffffff8113b327 : add $0xffffffffffffff08,%rdx > > 0xffffffff8113b32e : cmp %r9,%rdx > > 0xffffffff8113b331 : > > jb 0xffffffff8113b300 > > 0xffffffff8113b333 : movzbl %cl,%r9d > > 0xffffffff8113b337 : movzbl %ch,%edi > > 0xffffffff8113b33a : mov %ecx,%edx > > > > Care to guess what's causing the corruption? > > -Alan > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to " > freebsd-current-unsubscribe@freebsd.org" >