From nobody Mon Jun 7 20:54:11 2021 X-Original-To: freebsd-current@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id 8382D1666182 for ; Mon, 7 Jun 2021 20:54:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qv1-xf2a.google.com (mail-qv1-xf2a.google.com [IPv6:2607:f8b0:4864:20::f2a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 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 4FzQb82qfdz4ZD9 for ; Mon, 7 Jun 2021 20:54:12 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qv1-xf2a.google.com with SMTP id x6so4740337qvx.4 for ; Mon, 07 Jun 2021 13:54:12 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=G7d0TNkpCTn0Arra4+T/ecnnZirSr02hM8tpI64wT3o=; b=fQNVVSZgAi8gKscJiyz3kubZS1pIt//QK4azARPNAuUOhfqrqSZ9EnfygsXxfm0H44 nPKOJ6lFTlOdX0t91ZUG9tuYstcYhd8ItDqQSDtTJEtaPcDNcIKJWlsXplluZ5iKaqU4 G6aUmZmC+s71l+NAf18w9dK/skTfRsSzK68/XK3S4S7EHHg2pRIxoZbZDGOWFBoyJH0j MRyuRn9bjFGhyRHTSZC4D5ZxRj2AyEM9NUZACtFYLWU4p5Vzyzph6SL2Gvq9/LlWudCg HACCzMNaMwud2BMuS/KiKdAG0kos6mAtGo9nXBbvZ6B0btiBomX4BbH1phXsvTu9deOO XV+w== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition:in-reply-to; bh=G7d0TNkpCTn0Arra4+T/ecnnZirSr02hM8tpI64wT3o=; b=bZNhPmK1cP5Vi5SrURrFiNSJJYpcYoV+44UIedfXiYtlloUaiLOa++up78L7Yd99Yk H7mY4SK4LwRh7glRwARfkIA1mJlI245DpbJdQQhrrnj1/yB4fPRUJGSLB4BLEJWEhq/v zfx0cXeIn4edw0aW/ba2Flwsp2dAEW5NgGmMo0ZDDvzP9GklH8epahBuU1wruXh8vzft GF5rwWO26qBaN6L5KH1SbKTAJpbduj1dCwaUggJ0thBV++C8pBFHdyHMIdxlvdpSnoac xt0nNsPaFiBDmeR8po6PEdGV2F9SVoLZ8aJ8/k6wXSGomoqIj25l14OaUr3G97uiSb53 mGQw== X-Gm-Message-State: AOAM53228xeVfJj0FF7SqLih0PTEgSbNl//2L8VH+zb2DEQGWEPeWFWs qpcs28lGrWQkFKOfNLl10hU= X-Google-Smtp-Source: ABdhPJyLOCxEDPiduZdqLLYtm3LHQ8+GWcY9T/FCz2EWIg0P3CE+/Sjnar6m40MBg8iO1SxeVbBNrg== X-Received: by 2002:a05:6214:2a88:: with SMTP id jr8mr19659959qvb.46.1623099251183; Mon, 07 Jun 2021 13:54:11 -0700 (PDT) Received: from nuc ([142.126.172.178]) by smtp.gmail.com with ESMTPSA id q18sm5005510qkc.27.2021.06.07.13.54.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 07 Jun 2021 13:54:10 -0700 (PDT) Date: Mon, 7 Jun 2021 16:54:11 -0400 From: Mark Johnston To: Gary Jennejohn Cc: freebsd-current@freebsd.org Subject: Re: kernel panic while copying files Message-ID: References: <20210607090109.08ecb130@ernst.home> List-Id: Discussions about the use of FreeBSD-current List-Archive: https://lists.freebsd.org/archives/freebsd-current List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-current@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210607090109.08ecb130@ernst.home> X-Rspamd-Queue-Id: 4FzQb82qfdz4ZD9 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N On Mon, Jun 07, 2021 at 11:01:09AM +0200, Gary Jennejohn wrote: > I've seen this panic three times in the last two days: > > [first panic] > Unread portion of the kernel message buffer: > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x801118000 > fault code = supervisor write data, page not present > instruction pointer = 0x20:0xffffffff808d2212 > stack pointer = 0x28:0xfffffe00dbc8c760 > frame pointer = 0x28:0xfffffe00dbc8c7a0 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 28 (dom0) > trap number = 12 > panic: page fault > cpuid = 3 > time = 1622963058 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00dbc8c410 > vpanic() at vpanic+0x181/frame 0xfffffe00dbc8c460 > panic() at panic+0x43/frame 0xfffffe00dbc8c4c0 > trap_fatal() at trap_fatal+0x387/frame 0xfffffe00dbc8c520 > trap_pfault() at trap_pfault+0x4f/frame 0xfffffe00dbc8c580 > trap() at trap+0x253/frame 0xfffffe00dbc8c690 > calltrap() at calltrap+0x8/frame 0xfffffe00dbc8c690 > --- trap 0xc, rip = 0xffffffff808d2212, rsp = 0xfffffe00dbc8c760, rbp = 0xfffffe00dbc8c7a0 --- > zone_release() at zone_release+0x1f2/frame 0xfffffe00dbc8c7a0 > bucket_drain() at bucket_drain+0xda/frame 0xfffffe00dbc8c7d0 > bucket_cache_reclaim_domain() at bucket_cache_reclaim_domain+0x30a/frame 0xfffffe00dbc8c830 > zone_reclaim() at zone_reclaim+0x162/frame 0xfffffe00dbc8c880 > uma_reclaim_domain() at uma_reclaim_domain+0xa2/frame 0xfffffe00dbc8c8b0 > vm_pageout_worker() at vm_pageout_worker+0x41e/frame 0xfffffe00dbc8cb70 > vm_pageout() at vm_pageout+0x21e/frame 0xfffffe00dbc8cbb0 > fork_exit() at fork_exit+0x7e/frame 0xfffffe00dbc8cbf0 > fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00dbc8cbf0 > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > > __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55 > 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu, > pc_curthread))); > > One difference was that in the second and third panics the fault virtual > address was 0x0. But the backtrace was the same. > > Relevant info from the info.x files: > Architecture: amd64 > Architecture Version: 2 > Version String: FreeBSD 14.0-CURRENT #33 main-n247184-1970d693039: Sat Jun > 5 09:58:55 CEST 2021 > > CPU: AMD Ryzen 5 1600 Six-Core Processor (3194.09-MHz K8-class CPU) > Origin="AuthenticAMD" Id=0x800f11 Family=0x17 Model=0x1 Stepping=1 > AMD Features=0x2e500800 > AMD Features2=0x35c233ff > AMD Extended Feature Extensions ID EBX=0x1007 > > I have 16GiB of memory in the box. > > The panic occurred while copying files from an internal SATA SSD to a > SATA 8TB disk in an external USB3 docking station. The panic seems to > occur quite quickly, after only a few files have been copied. > > swap is on a different internal disk. > > I can poke around in the crash dumps with kgdb if anyone wants more > information. Are you running with invariants configured in the kernel? If not, please try to reproduce this in a kernel with options INVARIANT_SUPPORT options INVARIANTS configured. A stack trace with line numbers would also be helpful.