From nobody Mon Oct 11 04:48:17 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 7B79317E9293 for ; Mon, 11 Oct 2021 04:48:32 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x532.google.com (mail-ed1-x532.google.com [IPv6:2a00:1450:4864:20::532]) (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 4HSRBl0t1rz4ZjR for ; Mon, 11 Oct 2021 04:48:31 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x532.google.com with SMTP id w19so2715095edd.2 for ; Sun, 10 Oct 2021 21:48:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oOfpZ+Cc8pB2ve7MSPD8xsKmWNzn+0I5V4/uF51cDQ4=; b=g6aRlPt0IuKOM388u8DlfiVprRzS+OmRdXuxSptbJl3BU3a44f3dK35letbiR2dakq XpRd5t0VouWe4GHPyyxVUjkh82E4OGywxux+oNemeKx6SNakC5onn4ySl8ZKxGZIUl3X UmD8MHaO8P1fWHQz3QTTaJ97mvLjLWOeh/OMf2cwilAH7qWmAms5BvZcq4K8o6xzbEnQ 7t6uZ42yJueCOi7l1r5D7RH5MT2RKMqostC7mhxk9gq0z1mqor1Q3O4RijcQ2uByYcLq udVNtVWFBgFvg7MErJI/qgBpQpGXIQVpQ4PhIyLbWU5zZLz5lsnlTfqOvTSYHHeaOXxO C6Dg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oOfpZ+Cc8pB2ve7MSPD8xsKmWNzn+0I5V4/uF51cDQ4=; b=HItUU5TpPj0KNilFbEACuo0YnFc+5nPyeHYMsx1Nx3d40IgEDfR4MkVGtpxK0nDtjV AXGveXPm8xPCX8agoZxcCF78W6RISqW/rpirnKgeYBtAA7VBEVwskJ3Q60DSC+M9pLlW plEJKYIXUPtUR/oudhPeKvLxHFBEKGCpiH8hsau1UEqQqduJ5Xb5iHxx+r2EGqlH7bju pwV0/xJSinHaZFogrsazxUssiX9bHZBW4KG6p1yI4M+CtYOa3QBz3XVWZbg3ut+kOBpr v23PYUV6JpT5mJJZrvQSXDTKs4AkrPA0YsCaGmwx52Ou/pI8QMmWEP1WGWRiIf5qePJP RQ4w== X-Gm-Message-State: AOAM5304NoLWxlGi/fm2locoDH0IhMLlcCoCjliQeX39aXdM4QsX/UyB VMvLwqWSgw731i4BKbXCqnFOTytjYR3rx5IVzBgTnSxT5G4= X-Google-Smtp-Source: ABdhPJwYtOK0YJKmKiGiEOE9GphREeSX12b3ssgP5dNbNZVQtMGcrLD6P6Mc+jVdbaA2V3lJlbd0LEhs66a58NKt4b4= X-Received: by 2002:a50:9d83:: with SMTP id w3mr38546620ede.305.1633927708431; Sun, 10 Oct 2021 21:48:28 -0700 (PDT) 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 References: In-Reply-To: From: Pavel Timofeev Date: Sun, 10 Oct 2021 22:48:17 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Warner Losh Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000a65a9e05ce0c7004" X-Rspamd-Queue-Id: 4HSRBl0t1rz4ZjR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=g6aRlPt0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::532 as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-2.74 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MIME_GOOD(-0.10)[multipart/alternative]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.99)[-0.994]; NEURAL_SPAM_SHORT(0.26)[0.256]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; MID_RHS_MATCH_FROMTLD(0.00)[]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::532:from]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:~,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[]; RCVD_COUNT_TWO(0.00)[2] X-ThisMailContainsUnwantedMimeParts: Y --000000000000a65a9e05ce0c7004 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner Losh = : > > > On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: > >> >> >> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner Lo= sh : >> >>> >>> >>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote: >>> >>>> >>>> >>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warner= Losh : >>>> >>>>> >>>>> >>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> Warner Losh : >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>>> wrote: >>>>>>> >>>>>>>> Pavel Timofeev : >>>>>>>> >>>>>>>> > >>>>>>>> > Chuck Tuffli : >>>>>>>> > >>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev >>>>>>>> wrote: >>>>>>>> >> > >>>>>>>> >> > Hello >>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the latest >>>>>>>> >> 14.0-CURRENT >>>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>>> >> > nvme0: Missing interrupt >>>>>>>> >> > message I get sometimes on the console. >>>>>>>> >> > It seems like I get it only after the reboot of the laptop, i= . >>>>>>>> e. not >>>>>>>> >> > getting that message if I power cycle the laptop, at least I >>>>>>>> haven't >>>>>>>> >> seen >>>>>>>> >> > them for now in such cases. >>>>>>>> >> > So when the laptop is rebooted I can't even take advantage of >>>>>>>> >> > nvmecontrol(8) quickly. >>>>>>>> >> > Well, it still works, but it takes tens of seconds to return >>>>>>>> the output. >>>>>>>> >> ... >>>>>>>> >> > dmesg when power cycled - >>>>>>>> >> > >>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>>>>>> >> > dmesg when rebooted - >>>>>>>> >> > >>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>>>>>> >> >>>>>>>> >> I'm sort of curious about the time stamps for the log messages >>>>>>>> in the >>>>>>>> >> failing case. Something like: >>>>>>>> >> >>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>> >> >>>>>>>> >> --chuck >>>>>>>> >> >>>>>>>> > >>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>> missing some >>>>>>>> > configuration for that? >>>>>>>> > >>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>> > nvme0: mem >>>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f >>>>>>>> at device >>>>>>>> > 0.0 on pci6 >>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, MPSMA= X >>>>>>>> 0 >>>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvme0: Missing interrupt >>>>>>>> > nvd0: NVMe namespace >>>>>>>> > GEOM: new disk nvd0 >>>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>> > >>>>>>>> >>>>>>>> >>>>>>>> Ah, sorry, provided wrong output. >>>>>>>> Here is what you requested: >>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >>>>>>>> at device >>>>>>>> 0.0 on pci6 >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 >>>>>>>> MSI-X >>>>>>>> vectors (17 supported) >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for MSI= -X >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>>> 1023, CQR, >>>>>>>> TO 20 >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD 0= , >>>>>>>> NSSRS, >>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>> NVMe >>>>>>>> namespace >>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 by= te >>>>>>>> sectors) >>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>> >>>>>>> >>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and hw.cam.nda.nvd_comp= at=3D1 >>>>>>> in the boot loader and reboot? Same thing except nda where nvd was? >>>>>>> Or does >>>>>>> it work? >>>>>>> >>>>>>> Something weird is going on in the interrupt assignment, I think, >>>>>>> but I >>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>> >>>>>>> Warner >>>>>>> >>>>>> >>>>>> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compat= ? >>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>> >>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still se= e >>>>>> nvme0: Missing interrupt >>>>>> and now also >>>>>> Root mount waiting for: CAM >>>>>> messages besides those >>>>>> >>>>> >>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by defaul= t >>>>> these >>>>> days. >>>>> >>>>> I'll take a look on monday starting at the differences in interrupt >>>>> assignment that >>>>> are apparent when you cold boot vs reboot. >>>>> >>>>> Thanks for checking... I'd hoped this was a cheap fix, but also didn'= t >>>>> really >>>>> expect it to be. >>>>> >>>>> Warner >>>>> >>>>> >>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>> worse now. >>>> So clean poweron works as before. >>>> But if rebooted nvme drive refuses to work, while before the code >>>> upgrade it was just complaining about missing interrupts. >>>> >>>> currently dmesg show this: >>>> nvme0: mem >>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at d= evice >>>> 0.0 on pci6 >>>> nvd0: NVMe namespace >>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>> nvme0: mem >>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at d= evice >>>> 0.0 on pci6 >>>> >>> >>> Why is this showing up twice? Or is everything above this line left ove= r >>> from the first, working boot? >>> >>> >>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>> nvme0: timeout with nothing complete, resetting >>>> nvme0: Resetting controller due to a timeout. >>>> nvme0: RECOVERY_WAITING >>>> nvme0: resetting controller >>>> nvme0: aborting outstanding admin command >>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:0000000= 0 >>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>> nvme0: nvme_identify_controller failed! >>>> nvme0: waiting >>>> >>> >>> Clearly something bad is going on with the drive here... We looked into >>> the completion queues when we didn't get an interrupt and there was not= hing >>> complete there.... >>> >>> The only thing I can think of is that this means there's a phase error >>> between the drive and the system. I recently removed a second reset and >>> made it an option NVME_2X_RESET. Can you see if adding >>> 'options NVME_2X_RESET' to your kernel config fixes this? >>> >>> Warner >>> >>> >>>> nvme0: mem >>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at d= evice >>>> 0.0 on pci6 >>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>> nvme0: timeout with nothing complete, resetting >>>> nvme0: Resetting controller due to a timeout. >>>> nvme0: RECOVERY_WAITING >>>> nvme0: resetting controller >>>> nvme0: aborting outstanding admin command >>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:0000000= 0 >>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>> nvme0: nvme_identify_controller failed! >>>> nvme0: waiting >>>> >>>> >> >> Sorry, it's showing twice due to multiple reboots. For one boot it's lik= e: >> nvme0: mem >> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at dev= ice >> 0.0 on pci6 >> nvme0: RECOVERY_START 9633303481 vs 9365971423 >> nvme0: timeout with nothing complete, resetting >> nvme0: Resetting controller due to a timeout. >> nvme0: RECOVERY_WAITING >> nvme0: resetting controller >> nvme0: aborting outstanding admin command >> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >> nvme0: nvme_identify_controller failed! >> nvme0: waiting >> >> Well, neither Windows not Linux have any problems with the device. I >> understand they may be hiding it or workaround somehow. >> > > Yea, I'm trying to figure out why your machine is different than mine, an= d > what Windows or Linux do that is different. It may be dodgy hardware, but > others have no trouble... > > I'll try setting NVME_2X_RESET in the kernel config and report back in a >> while. >> > > Thanks. If it helps, that tells me something. If it doesn't, that tells m= e > something else. > > I suspect that it is somewhere else in the system, tbh, but I need to fin= d > it systematically. > > Warner > Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed anything. I. e it didn't help. --000000000000a65a9e05ce0c7004-- From nobody Mon Oct 11 05:00:40 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 7FA8017EBAAA for ; Mon, 11 Oct 2021 05:00:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4HSRT62nqBz4dN3 for ; Mon, 11 Oct 2021 05:00:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id q13so11361274uaq.2 for ; Sun, 10 Oct 2021 22:00:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=03zEoFrzc1//R3vlsBCnn7qprHVlcenWP/hvWy8YEI4=; b=OS/gbMNqCKNVOAuRlipLkuMghJj/UZ0MGJa4J1yiQTazR8x+pl5KoqyYn/9spWIONP fAVQ2zIvrh0XEU1tp7C99xv5IAo8h4dTDyn6yBxl/LPFjDWUGA1ZuzCYOw8SavYCBchM vbPLW9g98H7aq2VDwohjZx2gn9hO2i6HNKU3U3RRLPCOXf8yoGbOFPZlkayra0oGchfh izC3ObX2jO/t7F05NQVn9duzLAl9cxUU/vaI2Xi0V6Gsp3IU+oIMg1WZ03ThRtpfruK7 bOaJS4iRhh4B1hWFx3vxeQ21uCmnbHIAwDjht5fFraNPPkefHmMmmQ6uCqki24V1WTHB Tajg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=03zEoFrzc1//R3vlsBCnn7qprHVlcenWP/hvWy8YEI4=; b=eiu/eguPiwJ+affbusDVH1ApGfCAX0m+I/lHWQRUhfYSFHq1fWZZRzR4zXxjKbP5V1 CnXvqaKpREJ1PA5igMoK6zltztD988WtVNJCL8paxI78DK/ZyjUZyYbh1haWGO1o4mOg V9MvkgtLmEvmzoB2V2tPcU5KCz6L6etUzLNlAurOm+CS4mNFyFUJIAIPR4sqRcWzXkFY XRW+Dl3jRLrImdxgW/E4wW4Nvv0BTa3Bq+2OXAda5pjCMDBdd8Ir16WNXwk8sp506me3 KxWJRPJmJIlLQ3E5gnvgCBI0gdZ719CXl5ejv8vB9UG20C6/mQ2lWhRfy4e1L0fHiuNb lMAQ== X-Gm-Message-State: AOAM531DB2xnwKW6rcm84Mw3oGr5Cw8a97kbjsI8ipGI37nvkUYEolg1 G+qN0wpKbIK2U9EgrlOAchLJJU/ESZUkbniox7+k0g== X-Google-Smtp-Source: ABdhPJzvN89+5WDWcxgXhAZrTZnUpnYTUK4TuGbrQKUAwO3Fk4jZk3ScsFVmc6s811w+EVjKGppZLwoOF6b/xKaAvRc= X-Received: by 2002:ab0:55c9:: with SMTP id w9mr12609700uaa.77.1633928452107; Sun, 10 Oct 2021 22:00:52 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Sun, 10 Oct 2021 23:00:40 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Pavel Timofeev Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000fa0e4205ce0c9cba" X-Rspamd-Queue-Id: 4HSRT62nqBz4dN3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000fa0e4205ce0c9cba Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev wrote: > =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner Los= h : > >> >> >> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >> >>> >>> >>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner L= osh : >>> >>>> >>>> >>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev wrote= : >>>> >>>>> >>>>> >>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warne= r Losh : >>>>> >>>>>> >>>>>> >>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> Warner Losh : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Pavel Timofeev : >>>>>>>>> >>>>>>>>> > >>>>>>>>> > Chuck Tuffli : >>>>>>>>> > >>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>> >> > >>>>>>>>> >> > Hello >>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the lates= t >>>>>>>>> >> 14.0-CURRENT >>>>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>>>> >> > nvme0: Missing interrupt >>>>>>>>> >> > message I get sometimes on the console. >>>>>>>>> >> > It seems like I get it only after the reboot of the laptop, >>>>>>>>> i. e. not >>>>>>>>> >> > getting that message if I power cycle the laptop, at least I >>>>>>>>> haven't >>>>>>>>> >> seen >>>>>>>>> >> > them for now in such cases. >>>>>>>>> >> > So when the laptop is rebooted I can't even take advantage o= f >>>>>>>>> >> > nvmecontrol(8) quickly. >>>>>>>>> >> > Well, it still works, but it takes tens of seconds to return >>>>>>>>> the output. >>>>>>>>> >> ... >>>>>>>>> >> > dmesg when power cycled - >>>>>>>>> >> > >>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>>>>>>> >> > dmesg when rebooted - >>>>>>>>> >> > >>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>>>>>>> >> >>>>>>>>> >> I'm sort of curious about the time stamps for the log messages >>>>>>>>> in the >>>>>>>>> >> failing case. Something like: >>>>>>>>> >> >>>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>> >> >>>>>>>>> >> --chuck >>>>>>>>> >> >>>>>>>>> > >>>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>>> missing some >>>>>>>>> > configuration for that? >>>>>>>>> > >>>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>> > nvme0: mem >>>>>>>>> > >>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff= at device >>>>>>>>> > 0.0 on pci6 >>>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >>>>>>>>> MPSMAX 0 >>>>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvme0: Missing interrupt >>>>>>>>> > nvd0: NVMe namespace >>>>>>>>> > GEOM: new disk nvd0 >>>>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>>> > >>>>>>>>> >>>>>>>>> >>>>>>>>> Ah, sorry, provided wrong output. >>>>>>>>> Here is what you requested: >>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >>>>>>>>> at device >>>>>>>>> 0.0 on pci6 >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 >>>>>>>>> MSI-X >>>>>>>>> vectors (17 supported) >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for >>>>>>>>> MSI-X >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>>>> 1023, CQR, >>>>>>>>> TO 20 >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD >>>>>>>>> 0, NSSRS, >>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>> NVMe >>>>>>>>> namespace >>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 >>>>>>>>> byte >>>>>>>>> sectors) >>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>>> >>>>>>>> >>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and >>>>>>>> hw.cam.nda.nvd_compat=3D1 >>>>>>>> in the boot loader and reboot? Same thing except nda where nvd was= ? >>>>>>>> Or does >>>>>>>> it work? >>>>>>>> >>>>>>>> Something weird is going on in the interrupt assignment, I think, >>>>>>>> but I >>>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>> >>>>>>> Do you mean kern.cam.nda.nvd_compat instead of hw.cam.nda.nvd_compa= t? >>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>>> >>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still s= ee >>>>>>> nvme0: Missing interrupt >>>>>>> and now also >>>>>>> Root mount waiting for: CAM >>>>>>> messages besides those >>>>>>> >>>>>> >>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by defau= lt >>>>>> these >>>>>> days. >>>>>> >>>>>> I'll take a look on monday starting at the differences in interrupt >>>>>> assignment that >>>>>> are apparent when you cold boot vs reboot. >>>>>> >>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >>>>>> didn't really >>>>>> expect it to be. >>>>>> >>>>>> Warner >>>>>> >>>>>> >>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>>> worse now. >>>>> So clean poweron works as before. >>>>> But if rebooted nvme drive refuses to work, while before the code >>>>> upgrade it was just complaining about missing interrupts. >>>>> >>>>> currently dmesg show this: >>>>> nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at = device >>>>> 0.0 on pci6 >>>>> nvd0: NVMe namespace >>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>> nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at = device >>>>> 0.0 on pci6 >>>>> >>>> >>>> Why is this showing up twice? Or is everything above this line left >>>> over from the first, working boot? >>>> >>>> >>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>>> nvme0: timeout with nothing complete, resetting >>>>> nvme0: Resetting controller due to a timeout. >>>>> nvme0: RECOVERY_WAITING >>>>> nvme0: resetting controller >>>>> nvme0: aborting outstanding admin command >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:000000= 00 >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>> nvme0: nvme_identify_controller failed! >>>>> nvme0: waiting >>>>> >>>> >>>> Clearly something bad is going on with the drive here... We looked int= o >>>> the completion queues when we didn't get an interrupt and there was no= thing >>>> complete there.... >>>> >>>> The only thing I can think of is that this means there's a phase error >>>> between the drive and the system. I recently removed a second reset an= d >>>> made it an option NVME_2X_RESET. Can you see if adding >>>> 'options NVME_2X_RESET' to your kernel config fixes this? >>>> >>>> Warner >>>> >>>> >>>>> nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at = device >>>>> 0.0 on pci6 >>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>>> nvme0: timeout with nothing complete, resetting >>>>> nvme0: Resetting controller due to a timeout. >>>>> nvme0: RECOVERY_WAITING >>>>> nvme0: resetting controller >>>>> nvme0: aborting outstanding admin command >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:000000= 00 >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>> nvme0: nvme_identify_controller failed! >>>>> nvme0: waiting >>>>> >>>>> >>> >>> Sorry, it's showing twice due to multiple reboots. For one boot it's >>> like: >>> nvme0: mem >>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at de= vice >>> 0.0 on pci6 >>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >>> nvme0: timeout with nothing complete, resetting >>> nvme0: Resetting controller due to a timeout. >>> nvme0: RECOVERY_WAITING >>> nvme0: resetting controller >>> nvme0: aborting outstanding admin command >>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>> nvme0: nvme_identify_controller failed! >>> nvme0: waiting >>> >>> Well, neither Windows not Linux have any problems with the device. I >>> understand they may be hiding it or workaround somehow. >>> >> >> Yea, I'm trying to figure out why your machine is different than mine, >> and what Windows or Linux do that is different. It may be dodgy hardware= , >> but others have no trouble... >> >> I'll try setting NVME_2X_RESET in the kernel config and report back in a >>> while. >>> >> >> Thanks. If it helps, that tells me something. If it doesn't, that tells >> me something else. >> >> I suspect that it is somewhere else in the system, tbh, but I need to >> find it systematically. >> >> Warner >> > > Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed > anything. I. e it didn't help. > While it would have been nice to have this be the fix, I'm not that surprised either. It was the biggest change of late, apart from the big re-arrangement that I'd done. So the other changes have moved from the occasional missing interrupt message (which the old code would get when a command wasn't completed in the timeou= t period, but that we found to be done when we scanned the completion queue. Now the device is detected fine (as before), but then doesn't do I/O at all (including not completing the identify command!) and is worse. This is unexpected and I'm trying understand what happens on reboot that 'changes'the working state and why the new code behaves so differently. Warner --000000000000fa0e4205ce0c9cba-- From nobody Mon Oct 11 17:07:08 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 EB6C218155C8 for ; Mon, 11 Oct 2021 17:07:16 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [IPv6:2001:470:8d59:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSlb80DwSz4X4W for ; Mon, 11 Oct 2021 17:07:16 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:subject:subject:from:from:content-language :user-agent:mime-version:date:date:message-id; s=201508; t= 1633972028; bh=hWljcdKLwY1ZuypXDUZ27C5Cpjo2a3MtTaRXw7E0GIo=; b=N s64kp8rfBWiud/bN/nwR5fGSKjoZS/QWRbCRY4X56WIj/VS/ZYM/Gbclz+AZ6FXX emzkNft3tV2oyBZxnofgZfkYCPxGLmdjUbtLdkJcrCv/bv0h3N7E8lE3VaiDwG29 cMPZxoedMfx0bPe2ZeG7x/DMt2q201MEYQcO2SFs/c= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 79D1E4416D for ; Mon, 11 Oct 2021 13:07:08 -0400 (EDT) Message-ID: Date: Mon, 11 Oct 2021 13:07:08 -0400 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Content-Language: en-NZ To: freebsd-current Subject: drm-devel-kmod build failures Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSlb80DwSz4X4W X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=protected-networks.net header.s=201508 header.b="N s64kp8"; dmarc=pass (policy=reject) header.from=protected-networks.net; spf=pass (mx1.freebsd.org: domain of imb@protected-networks.net designates 2001:470:8d59:1::8 as permitted sender) smtp.mailfrom=imb@protected-networks.net X-Spamd-Result: default: False [-4.00 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[protected-networks.net:s=201508]; MID_RHS_MATCH_FROM(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[protected-networks.net:+]; DMARC_POLICY_ALLOW(-0.50)[protected-networks.net,reject]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N After the latest freebsd version bump in param.h, I tried to rebuild the DRM modules. It failed with .. --- dma-buf.o --- /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1: error: conflicting types for 'dma_buf_stat' dma_buf_stat(struct file *fp, struct stat *sb, ^ /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18: note: previous declaration is here static fo_stat_t dma_buf_stat; ^ 1 error generated. *** [dma-buf.o] Error code 1 make[3]: stopped in /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi 1 error make[3]: stopped in /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi I get a similar error with drm-current-kmod. What changed? imb From nobody Mon Oct 11 17:31:15 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 A091417F4708 for ; Mon, 11 Oct 2021 17:31:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: from mail-ot1-x32d.google.com (mail-ot1-x32d.google.com [IPv6:2607:f8b0:4864:20::32d]) (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 4HSm6y3yGFz4k15 for ; Mon, 11 Oct 2021 17:31:22 +0000 (UTC) (envelope-from mjguzik@gmail.com) Received: by mail-ot1-x32d.google.com with SMTP id c26-20020a056830349a00b0054d96d25c1eso22553199otu.9 for ; Mon, 11 Oct 2021 10:31:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=qoJpQ0tFyE4fNcaGrjc5HH3EY1e7Ac1x90L8b2yhliI=; b=FVooVdtPPsQps/y8vHmvEUq6jcjTor+o3wdZXoZhx/uANDhGHFS5j2B8FWciZ779vo LizD/hGTMwpmFuud+dwntSK998HXKCItVc0EoEwNXxw5oHX9FH6UIToZJMuvnDAKGZgE WoQavQPRbE+V95oK8E3SASuh/QnUIVhITU85ZWC1dKrCM5GZmhTW66/8j2EI6JEcodeS jfEFCU2JGOha2BOMK5onFTYDRhoKRZlyQYWqtfY8UOdXFGCi7GTgX45HpnJJhzCZIZv2 89GrkV4/yC3zIS9Fhxfurl1CrPutRW/7ZEBs2EAqI5RNAMUYk34MGK7ACuJiODgOeTUS AVsA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=qoJpQ0tFyE4fNcaGrjc5HH3EY1e7Ac1x90L8b2yhliI=; b=7FhptDWgL4UDZE3GMU4wsvBqjXmHsTiYN3ukFHrICAyPoEhm4M2nQq+AYhDi5O75wE fWsmEA1C0ALAL0XCh29Nd7AopsIqwjZlXORDLvWiEUOXmfTq99cmkTwdT0qz+jWOOWlb /gF4RLOIFaPgtDejOFaHLZ9+XjpZLkOpyiUewn8GT75vd7wypMqbVRvwIoTPqFDvh8RA jR6CcFIMQYWPQXddZc/IruANSDjqQjBM/Pen6gbMD1v2J2UcsbvphxevdpL8alNjrW1Z Qi4tGHIk8S4hCuMbs4U7T4G0n+p1sHCBX0QaWHLsI7WPkpMwOU5H+UerctykIseXnP9r dR9w== X-Gm-Message-State: AOAM531tCk1Il53eL6v8Vb2ELiQM/hzyWqWOCiQiTpb/eqv0NnwZYvDP 6rdB7u/UBrO3aNPPEXGWyhnROmejUmDG8r1eBk8A4182 X-Google-Smtp-Source: ABdhPJzoL4/mGLzWlc78HSjF1y26bVEpGfwhE1HnZr7PC4235V2aw5954h/bd0ybvDTkCPryP1uYDIPcxppdcUJyv2o= X-Received: by 2002:a9d:1ab:: with SMTP id e40mr12753013ote.281.1633973475888; Mon, 11 Oct 2021 10:31:15 -0700 (PDT) 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 Received: by 2002:ac9:126d:0:b0:3b4:5824:6a18 with HTTP; Mon, 11 Oct 2021 10:31:15 -0700 (PDT) In-Reply-To: References: From: Mateusz Guzik Date: Mon, 11 Oct 2021 19:31:15 +0200 Message-ID: Subject: Re: drm-devel-kmod build failures To: imb@protected-networks.net Cc: freebsd-current Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HSm6y3yGFz4k15 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N This should do it (untested): diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c index 37b268afa..f05de73fa 100644 --- a/drivers/dma-buf/dma-buf.c +++ b/drivers/dma-buf/dma-buf.c @@ -117,9 +117,15 @@ dma_buf_close(struct file *fp, struct thread *td) return (0); } +#if __FreeBSD_version >= 1400037 +static int +dma_buf_stat(struct file *fp, struct stat *sb, + struct ucred *active_cred __unused) +#else static int dma_buf_stat(struct file *fp, struct stat *sb, struct ucred *active_cred __unused, struct thread *td __unused) +#endif { /* XXX need to define flags for st_mode */ On 10/11/21, Michael Butler via freebsd-current wrote: > After the latest freebsd version bump in param.h, I tried to rebuild the > DRM modules. It failed with .. > > --- dma-buf.o --- > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1: > > error: conflicting types for 'dma_buf_stat' > dma_buf_stat(struct file *fp, struct stat *sb, > ^ > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18: > > note: previous declaration is here > static fo_stat_t dma_buf_stat; > ^ > 1 error generated. > *** [dma-buf.o] Error code 1 > > make[3]: stopped in > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi > 1 error > > make[3]: stopped in > /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi > > I get a similar error with drm-current-kmod. What changed? > > imb > > -- Mateusz Guzik From nobody Mon Oct 11 17:51:08 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 746D617FDD24 for ; Mon, 11 Oct 2021 17:51:20 +0000 (UTC) (envelope-from imb@protected-networks.net) Received: from mail.protected-networks.net (mail.protected-networks.net [202.12.127.228]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mail.protected-networks.net", Issuer "R3" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSmZ02N6fz4rrF for ; Mon, 11 Oct 2021 17:51:20 +0000 (UTC) (envelope-from imb@protected-networks.net) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d= protected-networks.net; h=content-transfer-encoding:content-type :content-type:in-reply-to:from:from:references:content-language :subject:subject:user-agent:mime-version:date:date:message-id; s=201508; t=1633974669; bh=LP7SCKo/EmJTuyfs/jBC6jc1qoqQjtXWhpmF 10xZotg=; b=SqayWorZAuqQ4pL6f0jYJadCYKYlIaCMZ+pMEwQkJI5McyDefAZ2 AMXPp9E4uAslKrxUhVVc1vrrDmI/Ts4YDWipaWDePhDneBquThU295o9dkBTx/3f 524vNZdWjjx4OO2JrRYLtQjI2xVUUJOM/WVamqwWQluU+FDRAFW3JKA= Received: from [192.168.1.10] (toshi.auburn.protected-networks.net [192.168.1.10]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (Client did not present a certificate) (Authenticated sender: imb@mail.protected-networks.net) by mail.protected-networks.net (Postfix) with ESMTPSA id 26DA146994; Mon, 11 Oct 2021 13:51:09 -0400 (EDT) Message-ID: <12599410-d74c-b87d-2bd7-103e6beeb6c3@protected-networks.net> Date: Mon, 11 Oct 2021 13:51:08 -0400 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: drm-devel-kmod build failures Content-Language: en-NZ To: Mateusz Guzik Cc: freebsd-current References: In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HSmZ02N6fz4rrF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: imb@protected-networks.net From: Michael Butler via freebsd-current X-Original-From: Michael Butler X-ThisMailContainsUnwantedMimeParts: N Thanks - that works :-) On 10/11/21 13:31, Mateusz Guzik wrote: > This should do it (untested): > > diff --git a/drivers/dma-buf/dma-buf.c b/drivers/dma-buf/dma-buf.c > index 37b268afa..f05de73fa 100644 > --- a/drivers/dma-buf/dma-buf.c > +++ b/drivers/dma-buf/dma-buf.c > @@ -117,9 +117,15 @@ dma_buf_close(struct file *fp, struct thread *td) > return (0); > } > > +#if __FreeBSD_version >= 1400037 > +static int > +dma_buf_stat(struct file *fp, struct stat *sb, > + struct ucred *active_cred __unused) > +#else > static int > dma_buf_stat(struct file *fp, struct stat *sb, > struct ucred *active_cred __unused, struct thread *td __unused) > +#endif > { > > /* XXX need to define flags for st_mode */ > > > On 10/11/21, Michael Butler via freebsd-current > wrote: >> After the latest freebsd version bump in param.h, I tried to rebuild the >> DRM modules. It failed with .. >> >> --- dma-buf.o --- >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:121:1: >> >> error: conflicting types for 'dma_buf_stat' >> dma_buf_stat(struct file *fp, struct stat *sb, >> ^ >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/drivers/dma-buf//dma-buf.c:70:18: >> >> note: previous declaration is here >> static fo_stat_t dma_buf_stat; >> ^ >> 1 error generated. >> *** [dma-buf.o] Error code 1 >> >> make[3]: stopped in >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi >> 1 error >> >> make[3]: stopped in >> /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.5.19_4/linuxkpi >> >> I get a similar error with drm-current-kmod. What changed? >> >> imb >> >> > > From nobody Tue Oct 12 01:11:26 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 B001E12DEFE9 for ; Tue, 12 Oct 2021 01:11:39 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.gq1.yahoo.com (sonic302-20.consmr.mail.gq1.yahoo.com [98.137.68.146]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HSyL23GgZz3Lyv for ; Tue, 12 Oct 2021 01:11:38 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634001091; bh=ICjTyFxlKvNKc3/d4MMZAehZPZ+LNRgNpB8G3bwnobE=; h=From:Subject:Date:To:References:From:Subject:Reply-To; b=DO/qXFCPqoVEWHuDD343SbA5EzZ2jygv09IMifzu6rw/xphIQyVk4mj6IH3RDytOxH5qiGXJC9Pi0WEzMHxFZf+X+RlFyts1qNNUXAH+WstWqumVF4p2+IvNm9uwdrm8ueKWfBfTXI0H9gMjqDFKqjaNpbSzMpOj52kxIyqk6lPS7vEsRaKwDGxMTUgmOUOhKk3AVozESZJkeDLG8ASlL4YNW2zZIP3biBUmLcH1LJrhq1KSYTOyh2tktffcj0LLlhHfCvfN0668Ldvibgeog8KQM3b4bjItJjfBzYJZHyOckWgdf5v1Phx53v3b3MH3app7lM7xa/B3y5sCGF36Ag== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634001091; bh=yRYJYjpL6dWQrImarUQoeKNg7JHOHvFTVNDbdvBGIEe=; h=X-Sonic-MF:From:Subject:Date:To:From:Subject; b=iQksubGQ7jlASaWTonyZ7jKvxWRLg1BWNOBHvetM0tsctimv+AVoleqEvFE4hx+cjuMxEDJ0rFb5NSVPL8crvQJL3+xUG7FshG1wbsuIXolVQ1MFjij3s5BfOLK9JoJO8MGCxou+nMcVMPSkH0Dmq1yKB81WpCj3zWN7+dJJzHULpi5iLejnMNoY781idFYYkYsgOF9Z0XOSJzrVvU8rU2l7R5Ua/HbI93b33nCLncYYgDvsQ3KLBCzgDj56Ea9eSGamWBQcXne95N5VKLKhgcI+9eC6U1zcbkNA8Kr/H014QOqIppwM5rzjmGH/apBruV4abYkNfOFlvhvIZ5g90Q== X-YMail-OSG: 6PZM_xwVM1lVkHmG7VRO0b2cMkFYoCT8WzQWAh4juxMZ_6E4L4EDrY2nTuF0Dnx EEMXQGsa_IzBBJ.xOTRKrK9hvyqwVTvZCfGAoSgXKQVteqiPrtvIirLjBonCkednNuNXH8a6gtJD tnhii6BUfWuyjKEdiCJU2E0ZlGD2OsaPYIt6uGk1wvOKfYPXcTUnukbksKXrqnckfA1UgYNWjFjH qklSSKoiL5m2e8TJG1ed9mBv9UbhvJXn692fUPUCrtwjoTseW7mEw2DEKOZXfUcDFffH30suCMlN UAXnPiq4L0rjSDDx9JBTr0.f_z2I._l7TyBEwdCDqeAIJenynSVGpuWW_diAhnNPIvzoZIZThDN. a3rWK.23IRD13pLFRqBIPjAdu9y4YJMHpLpiR7vBSDWaSxBH1KRWfT4EtjFaJlVgDU29Ji9J2C0K QqwfVrQqZth5_WrOLwwUZDYY16orQ2ynLTmbLH8qwkIKajq_Igh8wmkYqR31NQlDe4aKmZP3iLX0 wU_00bX0SSsSFGTeZqHcvUAcn9YHz3M7pFC8YGjogvhuhs9lFVnWIaqW6_rbnhAmNp36qV.KtTdh x6FQYyMLdjRDL5xs8ZnFgcvfrfNC5DBrTIVgO1HIrXN6GBrSWRYkwqQ2qyeqSPZoGtNd2L_08Vr. poz_5EUHPo5x14aFBDx_JNRmmUhHeqizpvVPm_L4369jYbGHO3k.cTYF1.QPP1WOCSqz5GQQKK9x NhmtHgXKxhrna.b6nu2UaTJHn1QXNNE_IjavbyPOSc812TABdsl8IxZ2.WRUtHO0bwi9YSwCNwXY 2LpgGfN8npz0MJvyybmlQxtNBX5b_hzAwQOjq05WIL6q7YK1UuhXNXAOehPbW_.IZx7EufEsno_c 4TW.UuX0ak9UZxEO.zUfgui9DshzmCVEXHISqz8t9XARCDJ_EAb4Q_bJN9ALfixWjCUPPgTvM.Sj fXmuOkbv_UZRtFE1XoudT2bUQz62pyziYjNZKFm7DnQc41siTMi64FT3puw_7cR69lbXMkYq8Qux iGqr6eDGw0vRpNicZMDqh990qlLtmleaBz8y8NtQREk4gDh8OZS1HcrOBK.3wulaZhe7_OnGC9WM Ao90fjgclNTFPz.SeQJYVmaVs3egFf5qKOszeiLX9ZWgY90BZOIQNUaDhEaULqSXHMKQE2v..S3q 5rUWtGZhqDaAJAbCAR1QQbvdQOQSwN3pXO91t7un08lbA9FwIUvoJ84ghsHuRYJzWdNaJlBQOTE4 .DUyFPePep9Fa4Mm_s5zen7eyyoHQAcEqkcFWVimyz0CKaE4KEsMuypWQqZZaNkeeXHMxm7F.H75 fzMvvvMsgUIaOoEobwoSW69MphdD..fNeCf.BtOjgPKBTy9DoFJy1cyJXOvYRdZqtN9_rKVC9kEG 2d6ZQoeAvp2FpyQrc1PhLo3CWyZDk2DGHRn2QiqDW.jN1KfvMVRzLrl4FwANqm7YqqCKl2O94zm6 T7MUSvAsSahFUPfl3DhMNARUo4cZOKG3xpMPHwi0ECL0_ouot.YZQgvGYbh2UdQ_if5JYUjhaT0r iIwqD1SgI3dYFlk6Xe.VtzVrpEdlNYCaePSsXnAnjtNZ.rbH4f6BOvCISa9GHs4L12ybJ2fcmDSW WttWKO8cbX9Xs6SH1RxIneDOyw3RCyAXfGWwG7ioK3oIrxNv3.T.tJZMYyRvhNoXeDqFM4l5eQgH iA8itGCGK0ya7cazeBm46F6fYWJ3klu9qMeHYUGK9DGYpdw9__8w1yavb9_LPb2vVHXggWAE_JZf gnJ0F0wuBpsBx12rHFfeusqb2O._56OrprA2cKrzhPHUtALX3FOGm_gM0IGd92s8Xa2_a5s_ONXE X6ilwDSSTXDwQsyON4WNeLlE_vpYuZ01qlct.icH96uOmMoWySOFOORRljhDH9uGtjGolyt1SsPF 8v96_kCVuJOgCKujmnwpiilYR3uv8deB0cbNrHxurO4TbKHoQ.xzSsxk348Fc6hR04e49Uvw4mLl 9nnfj4BJiWx_bgS_l7YEob_E28g8bdydKWUpSc0l4o9N0P.bZNjh8QzT.hNyZXBGJY0LWGCyJtxT FCrxBiU94hcaXsQdzNc1atDWl6MyoFqdlxOX3ZiLfjGKjpwheZyMu06v9mqFV9SoTLsjUdIYHyEp LJX1zuQeAfa2QUSK7LhTXvCfuyrc._XWC4ZPTyt1E7_lxhhOSdxy33ScSxTrvxqCwOIewKIBvDVW s2VMMYsjrkWdBFH2jOfW_wn5CXo9rzGWeq33EH_G.tcV7 X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Oct 2021 01:11:31 +0000 Received: by kubenode528.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID f335e29d007d0f7f37e0aabe87a96415; Tue, 12 Oct 2021 01:11:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable 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 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login Message-Id: Date: Mon, 11 Oct 2021 18:11:26 -0700 To: Free BSD , freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) References: X-Rspamd-Queue-Id: 4HSyL23GgZz3Lyv X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=yahoo.com header.s=s2048 header.b="DO/qXFCP"; dmarc=pass (policy=reject) header.from=yahoo.com; spf=pass (mx1.freebsd.org: domain of marklmi@yahoo.com designates 98.137.68.146 as permitted sender) smtp.mailfrom=marklmi@yahoo.com X-Spamd-Result: default: False [-3.49 / 15.00]; RCVD_TLS_LAST(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; NEURAL_HAM_MEDIUM(-0.99)[-0.994]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com:dkim]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; NEURAL_HAM_LONG(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[yahoo.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[98.137.68.146:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US]; RCVD_COUNT_TWO(0.00)[2]; MID_RHS_MATCH_FROM(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[98.137.68.146:from] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N I did not even get a chance to finish typing a command after login for the fist boot after updating: Fatal kernel mode data abort: 'Translation Fault (L2)' on read trapframe: 0xe18d6998 FSR=3D00000007, FAR=3Dfffffff4, spsr=3Da0000013 r0 =3D00000001, r1 =3D00000000, r2 =3D00000000, r3 =3D00000000 r4 =3Dd8ce7100, r5 =3D000007d0, r6 =3D90001010, r7 =3D00000000 r8 =3Dc08dfc10, r9 =3D00000001, r10=3Dc08dfc1c, r11=3De18d6aa8 r12=3De18d69e0, ssp=3De18d6a28, slr=3De18d6a28, pc =3De18d6a4c panic: Fatal abort cpuid =3D 0 time =3D 1633999791 KDB: stack backtrace: db_trace_self() at db_trace_self pc =3D 0xc062ef7c lr =3D 0xc007eb58 = (db_trace_self_wrapper+0x30) sp =3D 0xe18d6770 fp =3D 0xe18d6888 db_trace_self_wrapper() at db_trace_self_wrapper+0x30 pc =3D 0xc007eb58 lr =3D 0xc030ee04 (vpanic+0x17c) sp =3D 0xe18d6890 fp =3D 0xe18d68b0 r4 =3D 0x00000100 r5 =3D 0x00000000 r6 =3D 0xc07cac38 r7 =3D 0xc0941d68 vpanic() at vpanic+0x17c pc =3D 0xc030ee04 lr =3D 0xc030ec88 (vpanic) sp =3D 0xe18d68b8 fp =3D 0xe18d68bc r4 =3D 0xe18d6998 r5 =3D 0x00000013 r6 =3D 0xfffffff4 r7 =3D 0x00000007 r8 =3D 0x00000007 r9 =3D 0xda5e9000 r10 =3D 0xfffffff4 vpanic() at vpanic pc =3D 0xc030ec88 lr =3D 0xc0652f68 (abort_align) sp =3D 0xe18d68c4 fp =3D 0xe18d68f0 r4 =3D 0x00000007 r5 =3D 0x00000007 r6 =3D 0xda5e9000 r7 =3D 0xfffffff4 r8 =3D 0xe18d68bc r9 =3D 0xc030ec88 r10 =3D 0xe18d68c4 abort_align() at abort_align pc =3D 0xc0652f68 lr =3D 0xc0652a90 (abort_handler+0x2a8) sp =3D 0xe18d68f8 fp =3D 0xe18d6990 r4 =3D 0x00000013 r5 =3D 0xfffffff4 abort_handler() at abort_handler+0x2a8 pc =3D 0xc0652a90 lr =3D 0xc063191c (exception_exit) sp =3D 0xe18d6998 fp =3D 0xe18d6aa8 r4 =3D 0xd8ce7100 r5 =3D 0x000007d0 r6 =3D 0x90001010 r7 =3D 0x00000000 r8 =3D 0xc08dfc10 r9 =3D 0x00000001 r10 =3D 0xc08dfc1c exception_exit() at exception_exit pc =3D 0xc063191c lr =3D 0xe18d6a28 (0xe18d6a28) sp =3D 0xe18d6a28 fp =3D 0xe18d6aa8 r0 =3D 0x00000001 r1 =3D 0x00000000 r2 =3D 0x00000000 r3 =3D 0x00000000 r4 =3D 0xd8ce7100 r5 =3D 0x000007d0 r6 =3D 0x90001010 r7 =3D 0x00000000 r8 =3D 0xc08dfc10 r9 =3D 0x00000001 r10 =3D 0xc08dfc1c r12 =3D 0xe18d69e0 ucom_cons_softc() at 0xe18d6a4c pc =3D 0xe18d6a4c lr =3D 0xe18d6a28 (0xe18d6a28) sp =3D 0xe18d6a28 fp =3D 0xe18d6aa8 KDB: enter: panic [ thread pid 894 tid 100135 ] Stopped at kdb_enter+0x58: ldrb r15, [r15, r15, ror r15]! db> It is not reliably repeatable. Unsure if I can get a repeat at all. There is this "mixer" oddity for each boot: Feeding entropy: . mixer: 75:75: no such device mixer: 75:75: no such device mixer: 75:75: no such device mixer: 25:25: no such device mixer: 75:75: no such device mixer: 75:75: no such device mixer: =3Drec: no such device lo0: link state changed to UP (in case that matters for some reason). For reference: # uname -apKU FreeBSD OPiP2E_RPi2v11 14.0-CURRENT FreeBSD 14.0-CURRENT #10 = main-n249978-032448cd2c52-dirty: Sat Oct 9 02:11:35 PDT 2021 = root@CA72_16Gp_ZFS:/usr/obj/BUILDs/main-CA7-nodbg-clang/usr/main-src/arm.a= rmv7/sys/GENERIC-NODBG-CA7 arm armv7 1400036 1400036 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Oct 12 08:43:45 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 901CD17F8535; Tue, 12 Oct 2021 08:44:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [88.99.82.50]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HT8N439m4z3Q3x; Tue, 12 Oct 2021 08:44:04 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2020.home.selasky.org (unknown [178.17.145.105]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 6C2FA260245; Tue, 12 Oct 2021 10:43:57 +0200 (CEST) Subject: Re: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login To: marklmi@yahoo.com, Free BSD , freebsd-current References: From: Hans Petter Selasky Message-ID: Date: Tue, 12 Oct 2021 10:43:45 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.14.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HT8N439m4z3Q3x X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On 10/12/21 3:11 AM, Mark Millard via freebsd-arm wrote: > There is this "mixer" oddity for each boot: > > Feeding entropy: . > mixer: 75:75: no such device > mixer: 75:75: no such device > mixer: 75:75: no such device > mixer: 25:25: no such device > mixer: 75:75: no such device > mixer: 75:75: no such device > mixer: =rec: no such device > lo0: link state changed to UP > > (in case that matters for some reason). Hi, Add this script to /etc/rc.d/ and you'll be fine from now on. https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/mixer Then run: service mixer stop && service mixer start And the problem should go away. See "git: 903873ce1560 - main - Implement and use new mixer(3) library for FreeBSD" --HPS From nobody Tue Oct 12 10:59:00 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 0489E17E5309 for ; Tue, 12 Oct 2021 10:59:08 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: from mail-vk1-xa34.google.com (mail-vk1-xa34.google.com [IPv6:2607:f8b0:4864:20::a34]) (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 4HTCMv2Ymbz4nSZ for ; Tue, 12 Oct 2021 10:59:07 +0000 (UTC) (envelope-from grarpamp@gmail.com) Received: by mail-vk1-xa34.google.com with SMTP id m199so9189707vka.6 for ; Tue, 12 Oct 2021 03:59:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=ak2D1sffqzoba0ljEIDlZSDRgRdlDbZC13TOwCnfis8=; b=aTQ5z/wrZivMKnrhThmqCkZBiEfo213yfm9mZv3mabewpw+GfV49gV92+seZmhFL8y MsGrKQq9+laNbXqPLWR9fGw92QdGh7w/A0MZ7PSX0BhLk8mm4TBQREIkbNztnh2JrvgV OZONOoUUa0jCUJGRXJe90gVhIYoGNEG02AT7ex/dxvZn9zzaNjEaZqztlJBKCdDvxvii AbZwTrskMqXjrvWVvcurjXte8RvSqCvU+zg6T5VHeZ+ADM+2695vk1gsY/BR4hrafvYq WuvSzjySfbgWQW5y0Cdxl7wuWGj+aHGGP5pWkM3WO24nXjt1WwwmdobZy9x/MeiS43pQ jyLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=ak2D1sffqzoba0ljEIDlZSDRgRdlDbZC13TOwCnfis8=; b=Qm4X7izbqhB5uRNKTwTx9SLDzyhrvZS++hZVmkSxj5lDQj7NYqyNK+MHCe001NPfkg OsuKcKQ/ZBIo3PjUAYuQZveJjfXlWc6ORl2NWILYLz4+vNjnDMP0eCidyOs7TVvnmxdJ WflV4qD4Re3nEsU5ryaRiZmyPkrDyUn7slS1yKAykq9EJJi+3omkKowaIvxhw8v9S2gF oiqqtcZ7kRnuNsW6gJOZXcbnVaS6YZWfjgAfgY1fbNXd41QHuDSWdZHjD6xyt7SDf0WR mP1euaKMG3MVf/zQkZIN96wCiFGZhvA0/LIuH2/GI160rS57IjKPpkyFUbQonMhvWZjb DfVw== X-Gm-Message-State: AOAM5315qaVmVOCGDb/HPWkpiKjTqiBbXY6kk/aB+xyvDA/i85ag4F2s lPFgVTDOdPNfB+CG/vseYxracUkkzcx4qIViCYkJHmKN3ruDkvo3 X-Google-Smtp-Source: ABdhPJxaSiO11qndzMsg5hKjSA/I32c2KAno5Je6VaMC3hlFEEm91eSCjQKqpe+/TLLKU4qhHjeC3hm5KvI8nfxXeAo= X-Received: by 2002:a1f:9f10:: with SMTP id i16mr25373538vke.0.1634036340947; Tue, 12 Oct 2021 03:59:00 -0700 (PDT) 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 Received: by 2002:a59:938c:0:b0:236:ed6d:8851 with HTTP; Tue, 12 Oct 2021 03:59:00 -0700 (PDT) In-Reply-To: <6B2E21D5-0DF1-4BCC-A27C-DFFBB201FB52@gmail.com> References: <6B2E21D5-0DF1-4BCC-A27C-DFFBB201FB52@gmail.com> From: grarpamp Date: Tue, 12 Oct 2021 06:59:00 -0400 Message-ID: Subject: Re: [HEADSUP] making /bin/sh the default shell for root To: freebsd-current@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 4HTCMv2Ymbz4nSZ X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="aTQ5z/wr"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grarpamp@gmail.com designates 2607:f8b0:4864:20::a34 as permitted sender) smtp.mailfrom=grarpamp@gmail.com X-Spamd-Result: default: False [-4.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; MID_RHS_MATCH_FROMTLD(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a34:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N > No. The system shell is supposed to make the system usable > by the users. Actually, the real problem is that the easiest way > to shoot one's own foot is by changing the language (say, the > shell) spoken by default by FreeBSD. Well, the FreeBSD system speaks sh for its own use, this is clearly documented as the shell called by init(8), and later by rc(8), it should probably be the root:0 entry at least for consistancy. No other shell is called by the FreeBSD system there. Whatever the users want for their own shells is really up to them to decide after that. "Default" is bit of low context word, as there is no falling back to some shell occuring, no filling in for some missing option, etc. Maybe use word "shipped" or "root" instead. Everyone said they already do, and will continue to, exec whatever shell they like, whether after login, or by changing the entry. So in addition to the user being ultimately responsible for their own box and usage, this well announced entry for UPDATING cannot therein really be responsible for any user self-shooting. > This is non-sense. Well, FreeBSD does not add every shell in base, does not add every app to base, etc. Some reasons for those limits should be obvious. This update gives further distilling clarity by limiting the number of shipped uid 0 entries to 1, with that 1 being sh. > Every unix user should know that it's > possible to changing the used shell by using > chsh and this includes root. Then for every user, this update is not a problem. > BTW, toor default to sh, not tcsh. No one said that the toor entry does not use sh. Cheers :) From nobody Tue Oct 12 12:21:26 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 1BFF318070E6 for ; Tue, 12 Oct 2021 12:21:30 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x436.google.com (mail-wr1-x436.google.com [IPv6:2a00:1450:4864:20::436]) (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 4HTFBx1vPZz3k4S for ; Tue, 12 Oct 2021 12:21:29 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x436.google.com with SMTP id o20so66202095wro.3 for ; Tue, 12 Oct 2021 05:21:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=L/D93UD2UUopE6QAMLh+iKUbWnm4JUzx9fRVRCXR8lY=; b=QY/r7NT8zHdzX7bXN1rxcfmfY5FJtZL8Ue6xROhmvo6/iBCvzdOxTPI/j1Aqz1gy2m mt/yCFWbzWBtEOAXvGN6VEVoHAfzNfrnDMprtoa5Zjtqz5yUG573Vh9a0PZzPamFzEo3 WSQnRr51DhWUkRd6WRjQ0TUcH8MTvameo4zATHd3Vi6xIMehXNzDyRX6p2upe1lhm782 EKlIturp9l4BMfkkIY0e4yGAzQAEDRxO3gSz9l5HTjC10WK2wbiy58tW2PIRURRfg7PU MqEMVzPGdt1c4zMvZccjdUUfhznSOHLBp1CzWmOQrEGiZMa5pj/l50AUCSmw6smAHPGu X0aA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=L/D93UD2UUopE6QAMLh+iKUbWnm4JUzx9fRVRCXR8lY=; b=lQVGKOGoFvLxp92bwt03mPvsBehaBeTClBBBsMWDX5WIw8+u1P7V8OaY1LxulzjK+/ ZOD7/FCOfexmFrojIGJcxjZlTFH3mDClynoQSfg14s/fo00SvLkfaH5Xl31ke1QctVxe Bb9U0MZAhjH8jxocUi6X4UpVoDTE6Jq6dvtji9Nnbsa70lZ+XgeauBTp5sggWcNM6hIf FH1fhaZZpu/II7BQhEP3sW4zlLvaRPsRWKGCpX8WaleQy8aQ9zN+n2E4cuvOHmgl6gaf TWa1Ob3LKIw67g2eVf9FZFnJ5IlVmdWpEAY95GzPrStD1jnMmvAGlpq+WrZZbBk62guR /Nzg== X-Gm-Message-State: AOAM531vOSuLeuvXqTcNeAn7K3nFZ9t+4HPlQMCdwUCdt0HselS1PFU8 C028lVQEfUhXXDPpu6N5rbU9qTYvhaQ= X-Google-Smtp-Source: ABdhPJw0O1R9H743uM7oXtSyo3ogWqsiPKRZUErCAYgUg1ZhpxRoal2j42BA5GcXYVbZu0PTflbY7A== X-Received: by 2002:a5d:47cb:: with SMTP id o11mr31142763wrc.184.1634041288128; Tue, 12 Oct 2021 05:21:28 -0700 (PDT) Received: from ernst.home (p5b3becad.dip0.t-ipconnect.de. [91.59.236.173]) by smtp.gmail.com with ESMTPSA id e16sm8820991wrw.17.2021.10.12.05.21.27 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 05:21:27 -0700 (PDT) Date: Tue, 12 Oct 2021 14:21:26 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20211012142126.66036897@ernst.home> In-Reply-To: References: <6B2E21D5-0DF1-4BCC-A27C-DFFBB201FB52@gmail.com> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HTFBx1vPZz3k4S X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="QY/r7NT8"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::436 as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [-1.99 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.236.173:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.976]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(0.99)[0.989]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::436:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 12 Oct 2021 06:59:00 -0400 grarpamp wrote: > > No. The system shell is supposed to make the system usable > > by the users. Actually, the real problem is that the easiest way > > to shoot one's own foot is by changing the language (say, the > > shell) spoken by default by FreeBSD. > > Well, the FreeBSD system speaks sh for its own use, this is clearly > documented as the shell called by init(8), and later by rc(8), > it should probably be the root:0 entry at least for consistancy. > No other shell is called by the FreeBSD system there. > Whatever the users want for their own shells is really up > to them to decide after that. > > "Default" is bit of low context word, as there is no falling > back to some shell occuring, no filling in for some missing > option, etc. Maybe use word "shipped" or "root" instead. > > Everyone said they already do, and will continue to, > exec whatever shell they like, whether after login, > or by changing the entry. So in addition to the user > being ultimately responsible for their own box and usage, > this well announced entry for UPDATING cannot therein > really be responsible for any user self-shooting. > > > This is non-sense. > > Well, FreeBSD does not add every shell in base, > does not add every app to base, etc. > Some reasons for those limits should be obvious. > This update gives further distilling clarity by > limiting the number of shipped uid 0 entries to 1, > with that 1 being sh. > > > Every unix user should know that it's > > possible to changing the used shell by using > > chsh and this includes root. > > Then for every user, this update is not a problem. > I've been using UNIX both privately and professionally since 1984 and I must admit that I never heard of chsh before seeing this e-mail. I simply use vipw; it's the logical way to do this sort of thing IMHO. But I suppose that this is the way to go for users who don't have root access (which I always have). > > BTW, toor default to sh, not tcsh. > > No one said that the toor entry does not use sh. > -- Gary Jennejohn From nobody Tue Oct 12 12:42:48 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 9A2E717EAC14 for ; Tue, 12 Oct 2021 12:42:59 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail.madpilot.net (vogon.madpilot.net [159.69.1.99]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTFgk3PcPz3rKF for ; Tue, 12 Oct 2021 12:42:58 +0000 (UTC) (envelope-from mad@madpilot.net) Received: from mail (mail [192.168.254.3]) by mail.madpilot.net (Postfix) with ESMTP id 4HTFgb44jFz6pMy for ; Tue, 12 Oct 2021 14:42:51 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=madpilot.net; h= content-transfer-encoding:content-type:content-type:in-reply-to :from:from:references:content-language:subject:subject:date:date :message-id:received; s=bjowvop61wgh; t=1634042569; x= 1635856970; bh=gHRbcShfY42MPA/HKTzlwUXqrhb/zS9i0ePtJ/rfTxE=; b=b rTYqxSuCdvuQ38uHXKrS/I0Y9uwzRyLylOnwObc2Ym2jW7IjMnVDNJ1z230/aLXj 2utPUqmjdUEJJUR5QQpib6AW74H0w6j/rZR2Qs7uFXZ9YuJYEFlk+rqJ05AzGWD0 mV9qz8Eq0OI+HQiBfKKo+HAl4FUMsWDyCQkgbKwhxbEW2lTTO92LHMbCinnJl0PD +gm6FT7ev8VkugONDftE8RytMwtU0yG5hbmpmJuNpKH2mLR14ri5r5eARaIKaj8L eD/hlavMSbBXOxpv8kr1TlkwbWse5o1MRfJ71mjRwe8IDuBpy2y/jffjy1zAtQNv wo+//OMItCaFGLnNf14iw== Received: from mail.madpilot.net ([192.168.254.3]) by mail (mail.madpilot.net [192.168.254.3]) (amavisd-new, port 10026) with ESMTP id ZrRxveZE8QIX for ; Tue, 12 Oct 2021 14:42:49 +0200 (CEST) Message-ID: Date: Tue, 12 Oct 2021 14:42:48 +0200 Subject: Re: [HEADSUP] making /bin/sh the default shell for root Content-Language: en-US To: freebsd-current@freebsd.org References: <6B2E21D5-0DF1-4BCC-A27C-DFFBB201FB52@gmail.com> <20211012142126.66036897@ernst.home> In-Reply-To: <20211012142126.66036897@ernst.home> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HTFgk3PcPz3rKF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=madpilot.net header.s=bjowvop61wgh header.b="b rTYqxS"; dmarc=pass (policy=quarantine) header.from=madpilot.net; spf=pass (mx1.freebsd.org: domain of mad@madpilot.net designates 159.69.1.99 as permitted sender) smtp.mailfrom=mad@madpilot.net X-Spamd-Result: default: False [-2.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[madpilot.net:s=bjowvop61wgh]; FROM_HAS_DN(0.00)[]; MISSING_MIME_VERSION(2.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-0.997]; RCVD_COUNT_THREE(0.00)[3]; R_SPF_ALLOW(-0.20)[+mx]; DKIM_TRACE(0.00)[madpilot.net:+]; DMARC_POLICY_ALLOW(-0.50)[madpilot.net,quarantine]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:24940, ipnet:159.69.0.0/16, country:DE]; MID_RHS_MATCH_FROM(0.00)[] Reply-To: mad@madpilot.net From: Guido Falsi via freebsd-current X-Original-From: Guido Falsi X-ThisMailContainsUnwantedMimeParts: N 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 On 12/10/21 14:21, Gary Jennejohn wrote: > On Tue, 12 Oct 2021 06:59:00 -0400 > grarpamp wrote: > >>> No. The system shell is supposed to make the system usable >>> by the users. Actually, the real problem is that the easiest way >>> to shoot one's own foot is by changing the language (say, the >>> shell) spoken by default by FreeBSD. >> >> Well, the FreeBSD system speaks sh for its own use, this is clearly >> documented as the shell called by init(8), and later by rc(8), >> it should probably be the root:0 entry at least for consistancy. >> No other shell is called by the FreeBSD system there. >> Whatever the users want for their own shells is really up >> to them to decide after that. >> >> "Default" is bit of low context word, as there is no falling >> back to some shell occuring, no filling in for some missing >> option, etc. Maybe use word "shipped" or "root" instead. >> >> Everyone said they already do, and will continue to, >> exec whatever shell they like, whether after login, >> or by changing the entry. So in addition to the user >> being ultimately responsible for their own box and usage, >> this well announced entry for UPDATING cannot therein >> really be responsible for any user self-shooting. >> >>> This is non-sense. >> >> Well, FreeBSD does not add every shell in base, >> does not add every app to base, etc. >> Some reasons for those limits should be obvious. >> This update gives further distilling clarity by >> limiting the number of shipped uid 0 entries to 1, >> with that 1 being sh. >> >>> Every unix user should know that it's >>> possible to changing the used shell by using >>> chsh and this includes root. >> >> Then for every user, this update is not a problem. >> > > I've been using UNIX both privately and professionally since 1984 > and I must admit that I never heard of chsh before seeing this > e-mail. I simply use vipw; it's the logical way to do this sort > of thing IMHO. But I suppose that this is the way to go for users > who don't have root access (which I always have). AFAIK only root can use vipw, while chsh is usable by all system users. Guess you've been root since 1984 :) -- Guido Falsi From nobody Tue Oct 12 13:37:36 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 40A6417E24C2 for ; Tue, 12 Oct 2021 13:37:41 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: from mail-wr1-x42c.google.com (mail-wr1-x42c.google.com [IPv6:2a00:1450:4864:20::42c]) (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 4HTGtr0jMWz4cyx for ; Tue, 12 Oct 2021 13:37:40 +0000 (UTC) (envelope-from gljennjohn@gmail.com) Received: by mail-wr1-x42c.google.com with SMTP id i12so54374084wrb.7 for ; Tue, 12 Oct 2021 06:37:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:in-reply-to:references:reply-to :mime-version:content-transfer-encoding; bh=MomcGJGkNp05Pu9OKGFuyru96Se9UwQhWyC0PQ6vMCY=; b=J/5zbAk9QoIVAeoc0SNMSiLNJ+9obWte0UcSmx/IJKB1uekc0WRgQydQXNzuAoRbnV nCrHUG5aLEigLA8o0xrjVM8gvkINEgFAUawKSTE33Im1rqrZ+r9J4dC8yMomgdaWveY3 k3wp5e2/mkR0dGCz7c0yIKtaW5QSf45znN4Us2OCVvr4VxG3PJRTwLCj/6qgEgLOmn7m OShkgfZnJKOYGSzoblkVPHozD6qN1h/L6yit0sBpLjsxPlCnZBe5vGgGUjAM8MJGeWAC Ao7dIoY9Q9bJmSjPAHlPSxaOFdG2YYy5/fYk6ACzJMP+f6sA3BuGqVK0PUNTTXDYlqum SJyA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:in-reply-to :references:reply-to:mime-version:content-transfer-encoding; bh=MomcGJGkNp05Pu9OKGFuyru96Se9UwQhWyC0PQ6vMCY=; b=tgpNudgAzrVkac7NXZeWlARD3mV695cTA6tvQ5Z6Lua9WiGT2SAVopQoJXnQI78BN5 kwCDx42Q+qGIEQwkRI5rGah5dg01EqtLY4wNYFljavKvNxD4d4fYoz8ZZfWJE5wl3bxM +cjLOdDUH2bUUI0gOeo+j4pDSfyqk2rLeyose/DfOWBlcQoOU/i9jXwUhezPcnwHFqqE XcYNDnVBC4uBwCHtrPv8a38fQ1MnD3R5kWroT1onqhPny4WLbLu4l5eXPKyEyKuov/EY 9+w5kitpOm9YKtPytoFPORty7lSv2w7xL+mAduaVVj2vsznlv8CRdX5i2E8QyfmmI6+p K+mw== X-Gm-Message-State: AOAM5312sGqvkmW9KRPvE1fW+/fnZPq4ghRnk9Vf9dg6deLhFp3/8bTB BrpGu4uJWzjtdEnHxyO/85c4/6Pw2iU= X-Google-Smtp-Source: ABdhPJyWPZxPHTEohWSI1GFeRa/4ODsqqsGS4e4GjSOx0L4mlkka0ZFk1V0y9oZqAS2+R3A945WgcA== X-Received: by 2002:a05:6000:1449:: with SMTP id v9mr32725563wrx.137.1634045858484; Tue, 12 Oct 2021 06:37:38 -0700 (PDT) Received: from ernst.home (p5b3becad.dip0.t-ipconnect.de. [91.59.236.173]) by smtp.gmail.com with ESMTPSA id o19sm11076069wrg.60.2021.10.12.06.37.36 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Oct 2021 06:37:37 -0700 (PDT) Date: Tue, 12 Oct 2021 15:37:36 +0200 From: Gary Jennejohn To: freebsd-current@freebsd.org Subject: Re: [HEADSUP] making /bin/sh the default shell for root Message-ID: <20211012153736.1321828c@ernst.home> In-Reply-To: References: <6B2E21D5-0DF1-4BCC-A27C-DFFBB201FB52@gmail.com> <20211012142126.66036897@ernst.home> Reply-To: gljennjohn@gmail.com X-Mailer: Claws Mail 3.18.0 (GTK+ 2.24.33; amd64-portbld-freebsd14.0) 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-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 4HTGtr0jMWz4cyx X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="J/5zbAk9"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of gljennjohn@gmail.com designates 2a00:1450:4864:20::42c as permitted sender) smtp.mailfrom=gljennjohn@gmail.com X-Spamd-Result: default: False [1.99 / 15.00]; HAS_REPLYTO(0.00)[gljennjohn@gmail.com]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; REPLYTO_ADDR_EQ_FROM(0.00)[]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RECEIVED_SPAMHAUS_PBL(0.00)[91.59.236.173:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_SPAM_SHORT(1.00)[1.000]; MIME_GOOD(-0.10)[text/plain]; FREEMAIL_REPLYTO(0.00)[gmail.com]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_SPAM_MEDIUM(1.00)[0.998]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_SPAM_LONG(1.00)[0.996]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::42c:from]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N On Tue, 12 Oct 2021 14:42:48 +0200 Guido Falsi via freebsd-current wrote: > On 12/10/21 14:21, Gary Jennejohn wrote: > > On Tue, 12 Oct 2021 06:59:00 -0400 > > grarpamp wrote: > > > >>> No. The system shell is supposed to make the system usable > >>> by the users. Actually, the real problem is that the easiest way > >>> to shoot one's own foot is by changing the language (say, the > >>> shell) spoken by default by FreeBSD. > >> > >> Well, the FreeBSD system speaks sh for its own use, this is clearly > >> documented as the shell called by init(8), and later by rc(8), > >> it should probably be the root:0 entry at least for consistancy. > >> No other shell is called by the FreeBSD system there. > >> Whatever the users want for their own shells is really up > >> to them to decide after that. > >> > >> "Default" is bit of low context word, as there is no falling > >> back to some shell occuring, no filling in for some missing > >> option, etc. Maybe use word "shipped" or "root" instead. > >> > >> Everyone said they already do, and will continue to, > >> exec whatever shell they like, whether after login, > >> or by changing the entry. So in addition to the user > >> being ultimately responsible for their own box and usage, > >> this well announced entry for UPDATING cannot therein > >> really be responsible for any user self-shooting. > >> > >>> This is non-sense. > >> > >> Well, FreeBSD does not add every shell in base, > >> does not add every app to base, etc. > >> Some reasons for those limits should be obvious. > >> This update gives further distilling clarity by > >> limiting the number of shipped uid 0 entries to 1, > >> with that 1 being sh. > >> > >>> Every unix user should know that it's > >>> possible to changing the used shell by using > >>> chsh and this includes root. > >> > >> Then for every user, this update is not a problem. > >> > > > > I've been using UNIX both privately and professionally since 1984 > > and I must admit that I never heard of chsh before seeing this > > e-mail. I simply use vipw; it's the logical way to do this sort > > of thing IMHO. But I suppose that this is the way to go for users > > who don't have root access (which I always have). > > AFAIK only root can use vipw, while chsh is usable by all system users. > Which is pretty much what I wrote above. > Guess you've been root since 1984 :) > On the systems I've had control of, always. I started out with 4.2BSD running on a VAX, which didn't have chpass, so csh was the default. The VAX was used to cross-compile AT&T III/IV/V to run on Motorola CPUs. I always had full control of the target machines, although the Bourne shell was pretty much the only shell available then. After relocating for that employer from Berkeley to Germany I helped administer the VAX, so I had to have root access. Unfortunately, the german spinoff went tits up in 1989 and I decided to stay in Germany. And, no matter where I was employed after that, I was always able to get root access, which I never abused. But since 2000 I've administered my own FreeBSD machines at home as a freelancer (but I'm now retired), so root access is always required. -- Gary Jennejohn From nobody Tue Oct 12 15:31:48 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 1F1E917F04A6 for ; Tue, 12 Oct 2021 15:32:00 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [IPv6:2001:1640:5::8:31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTKQl2kk5z3nf1 for ; Tue, 12 Oct 2021 15:31:59 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id EB0FC10A32E5 for ; Tue, 12 Oct 2021 17:31:50 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 489E11056B1E for ; Tue, 12 Oct 2021 17:31:49 +0200 (CEST) Received: from hermann.fritz.box (dynamic-2a01-0c22-a4ce-1b00-742c-bcef-4a23-f23c.c22.pool.telefonica.de [IPv6:2a01:c22:a4ce:1b00:742c:bcef:4a23:f23c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 1A40F10B4FAD for ; Tue, 12 Oct 2021 17:31:49 +0200 (CEST) Date: Tue, 12 Oct 2021 17:31:48 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: git: "overlay" of own remote-branch on official freebsd-ports repo Message-ID: <20211012173148.1d2f138c@hermann.fritz.box> 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-Transfer-Encoding: 7bit X-Rspamd-UID: dea267 X-Rspamd-UID: 93362c X-Rspamd-Queue-Id: 4HTKQl2kk5z3nf1 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:31) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [0.02 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.87)[-0.870]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_SPAM_LONG(0.99)[0.990]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N I do not know whether I'm right in this list, but since the subject is mutual so common in development and GIT, I have the strong feeling I'm right here. Im quite new to git, so apologizes for any inconvenience reading my question. Using poudriere on 14-CURRENT to create a selection of packages also includes updating the ports tree on a regular basis. I maintain some "special" ports not official part of the FreeBSD ports tree and some other ports are part of those I'm supposed to maintain. I keep personally track of the changes in a git repo of my own. Now I'd like to "overlay" the official portas repo by that of mine to include changes. With SVN, there was no problem to have local changes not overwritten by regular updates of the ports tree as long as the specific port in question wasn't updated by the official site. In git, this behaviour seems to have changed, any changes I made so far are gone after poudriere is adviced to update the tree. I'd like to ask how FreeBSD developers and maintainers do the trick. If there is an official cookbook fpr maintainers (I haven't found it yet ...), please be so kind and refer to it. Any advice is welcome. Kind regards and thanks in advance, O. Hartmann From nobody Tue Oct 12 16:01:00 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 DDEF617FE3CA for ; Tue, 12 Oct 2021 16:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x934.google.com (mail-ua1-x934.google.com [IPv6:2607:f8b0:4864:20::934]) (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 4HTL4R5gjqz4Rlq for ; Tue, 12 Oct 2021 16:01:11 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x934.google.com with SMTP id u5so19373866uao.13 for ; Tue, 12 Oct 2021 09:01:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=cGBRnEO6bAuyx/V6DnH5kdKP+9wLn3Ne2RU+8BInzMc=; b=EeEmdLJibq8sUK+rk8BAjUnBVnBVP3tio5mxVbMRj6C4wxfcNCEZ1qFz7Jr9ydeD3V ihBOo/JKZTK7iIXfY6z1m38foGUCpSdiWErh3UunBJzVJg4nerM9hA13v+rEkQ9K1vOD ZN3jBQ4nzgpIeMSD99pFRxjEgia1nCX5V2qU+8rtNn9NTK9xHETyG6oxf1j6G5iF9hQ2 z69kHrPUwaNNHUmIq/2mmBLfGPmDx2TvM3u4/bcqq/cnWKgZwZ/9tgJxU3WvvsoCt2+Q jnjg2SuT7T7XjFYoWjt4e/ZJ/EaJE09XZpxsdkR3Cj7c0Beai+109LlTUQYANZ7nzZZo uaeA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=cGBRnEO6bAuyx/V6DnH5kdKP+9wLn3Ne2RU+8BInzMc=; b=RBandWbUqucFZ76JYxmEAlWQUyFHt7cbMFPnQ2RBjH28IpcHbjxmAc7jk0PagwF/+s JJlcDoXX6mxSohfFzgVAQMmkWviK61h2rVwNtmA2s2nS7Wv5aNLvbq6Y+PqzbQgWSGvB P8B3GZ3m/7wcawOGJ0cgeioJq32vYiWarQxwUc8X+sp5T6VqlrjHswgFBVvojrsMPymY mNulDMjs5YD33dhROcn/pjfHCc3RelTxJlFBFI8Wepr7zcDs+atQ1qnp+9qZgbPPPxSb 7xNU9qD+pF5mWCq368HYNEVgzJwr6+obX6dCzmK1+HD7s2RQto1gwkQmPSxWevd6/LjA RuhA== X-Gm-Message-State: AOAM531bZdZBLkgzI3ATZrpR9cTdEGkb5Zr7q1CyNb3gOVvbsyB0ExIn d64uFL3BqUQucKYaHECX0v9nmcdmCjuvGIDCpLXeOgz45KI= X-Google-Smtp-Source: ABdhPJyArRJ3sLfF7ObLuG3BEFNTxKnGmmQfuUzP3/ZwrbttgXPzPYYVk2kTfHLGsOMD+bbgrHyyOniEzpUm304C8ww= X-Received: by 2002:a67:fc8b:: with SMTP id x11mr17153539vsp.12.1634054471119; Tue, 12 Oct 2021 09:01:11 -0700 (PDT) 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 References: <20211012173148.1d2f138c@hermann.fritz.box> In-Reply-To: <20211012173148.1d2f138c@hermann.fritz.box> From: Warner Losh Date: Tue, 12 Oct 2021 10:01:00 -0600 Message-ID: Subject: Re: git: "overlay" of own remote-branch on official freebsd-ports repo To: FreeBSD User Cc: FreeBSD CURRENT Content-Type: multipart/alternative; boundary="0000000000004b888805ce29f4e9" X-Rspamd-Queue-Id: 4HTL4R5gjqz4Rlq X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --0000000000004b888805ce29f4e9 Content-Type: text/plain; charset="UTF-8" On Tue, Oct 12, 2021 at 9:32 AM FreeBSD User wrote: > I do not know whether I'm right in this list, but since the subject is > mutual so common > in development and GIT, I have the strong feeling I'm right here. > > Im quite new to git, so apologizes for any inconvenience reading my > question. > > Using poudriere on 14-CURRENT to create a selection of packages also > includes updating > the ports tree on a regular basis. I maintain some "special" ports not > official part of > the FreeBSD ports tree and some other ports are part of those I'm supposed > to maintain. I > keep personally track of the changes in a git repo of my own. > > Now I'd like to "overlay" the official portas repo by that of mine to > include changes. > With SVN, there was no problem to have local changes not overwritten by > regular updates > of the ports tree as long as the specific port in question wasn't updated > by the official > site. In git, this behaviour seems to have changed, any changes I made so > far are gone > after poudriere is adviced to update the tree. > > I'd like to ask how FreeBSD developers and maintainers do the trick. If > there is an > official cookbook fpr maintainers (I haven't found it yet ...), please be > so kind and > refer to it. Any advice is welcome. > tl;dr: branches are cheap and well supported in git. You just make a branch for your local changes, and update that however you see fit. For ports I have like that, I've just created a branch in git. I rebase the branch forward each time I update. For me, though, the branch is mostly uncommitted in upstream changes that may not be ready for some reason... There's two ways to do this. You can just merge, which is OK if you aren't upstreaming the changes, or you can rebase if the changes or a subset of the changes likely will end up in FreeBSD. Others might recommend stash, but I find it too unwieldy for more than a couple of things. So the workflow would be: git clone -o freebsd freebsd-ports cd freebsd-ports git checkout -b hartmann-specials Now, you can use poudriere-ports with the -B hartmann-specials and your local repo as the source of truth. to update cd freebsd-ports git checkout main git pull --rebase # or --ff-only, I use --rebase because I push and it's habit git rebase -i main hartmann-specials Note: if you need to have multiple trees with this branch you are modifying, then a git pull --rebase will let you cope with the forced-pushes this method would require. You can also do it with git merge on hartmann-specials if you don't need to keep the changes separate or you have a lot of downstreams that would get cranky, which doesn't sound like the case here. Warner --0000000000004b888805ce29f4e9-- From nobody Tue Oct 12 16:42: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 DB6F517FBAC8 for ; Tue, 12 Oct 2021 16:42:22 +0000 (UTC) (envelope-from felix@palmen-it.de) Received: from stef.palmen-it.de (stef.palmen-it.de [IPv6:2001:470:1f0b:bbb:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTLzy0M2mz4kr4 for ; Tue, 12 Oct 2021 16:42:21 +0000 (UTC) (envelope-from felix@palmen-it.de) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=palmen-it.de; s=20200414; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:To:From:Date:Sender:Reply-To:Cc: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=sAIcS/4Zu7Q/wcqqF0lJl/gT3SdhDWg7ACbpJshGe4Q=; b=Zosm2byAbd2oGkdEO2kwc/xgU1 dbYDh85SwS3LFopdvBgfHq4O30UCSI5fcXoGrfDafV0Og4wR42QRe3k6ZHcskx25BoWYCaQWdlSRQ 4SKN9QJQKNqEV24urU9Cc4Fpjb4uBck2S14lKyuN73zcMWFClVC2up/POb+EQTuq1I4pBLASkVRUj Oz3ZAp5000dVVRD3yvQ4ODv0iengFsgr1ndQ4dDj5cZgcuo8Q4f+4SSlAPlFVdcwnfZ0kSM+Z+LrI afa3ADL7muUEwWSTonLP9uKdZ3zHinhT51g6aHUOvfw4itV/cFDnQ5GiAq8doOi6TFn31caXfXLIx ahbN4e8w==; Received: from [192.168.71.101] (helo=mail.home.palmen-it.de) by stef.palmen-it.de with esmtps (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1maKqy-002y3a-SM for freebsd-current@freebsd.org; Tue, 12 Oct 2021 18:42:12 +0200 Received: from nexus.home.palmen-it.de ([192.168.99.2]) by mail.home.palmen-it.de with esmtpsa (TLS1.3) tls TLS_CHACHA20_POLY1305_SHA256 (Exim 4.94.2 (FreeBSD)) (envelope-from ) id 1maKqy-0000IZ-Hp for freebsd-current@freebsd.org; Tue, 12 Oct 2021 16:42:12 +0000 Date: Tue, 12 Oct 2021 18:42:11 +0200 From: Felix Palmen To: freebsd-current@freebsd.org Subject: Re: git: "overlay" of own remote-branch on official freebsd-ports repo Message-ID: <20211012164211.nl7gmpu74io5lndo@nexus.home.palmen-it.de> Mail-Followup-To: freebsd-current@freebsd.org X-Face: /1K@t"h.}e~pR@]c7HorQ!T`F^RJCa'BCr#e>IKA{>C/9OTGB4|xh"y2{?1Z5M i2w"AH^pN_LlHR^{+f',_Np~;.B;!M/bL}*qk]p5*r7F5vW};{:@4u5S?T&f0$7BJ-71Q5SV]:v$`5 A0[DZ:=?S52x8HJ~5@^P_\T@MsjG{R( Organization: palmen-it.de References: <20211012173148.1d2f138c@hermann.fritz.box> 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: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="fsieiwvezpx2nbjh" Content-Disposition: inline In-Reply-To: User-Agent: NeoMutt/20210205 X-Rspamd-Queue-Id: 4HTLzy0M2mz4kr4 X-Spamd-Bar: -------- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=palmen-it.de header.s=20200414 header.b=Zosm2byA; dmarc=pass (policy=none) header.from=palmen-it.de; spf=pass (mx1.freebsd.org: domain of felix@palmen-it.de designates 2001:470:1f0b:bbb:1::1 as permitted sender) smtp.mailfrom=felix@palmen-it.de X-Spamd-Result: default: False [-8.80 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[palmen-it.de:s=20200414]; NEURAL_HAM_LONG(-1.00)[-1.000]; FROM_HAS_DN(0.00)[]; DWL_DNSWL_MED(-2.00)[palmen-it.de:dkim]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:470:1f0b:bbb:1::1]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; TO_DN_NONE(0.00)[]; RCVD_DKIM_ARC_DNSWL_MED(-0.50)[]; RCPT_COUNT_ONE(0.00)[1]; HAS_ORG_HEADER(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; MID_RHS_MATCH_FROMTLD(0.00)[]; RCVD_IN_DNSWL_MED(-0.20)[2001:470:1f0b:bbb:1::1:from]; DKIM_TRACE(0.00)[palmen-it.de:+]; DMARC_POLICY_ALLOW(-0.50)[palmen-it.de,none]; NEURAL_HAM_SHORT(-1.00)[-1.000]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; SIGNED_PGP(-2.00)[]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:6939, ipnet:2001:470::/32, country:US]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N --fsieiwvezpx2nbjh Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable * Warner Losh [20211012 10:01]: > tl;dr: branches are cheap and well supported in git. You just make a bran= ch > for your > local changes, and update that however you see fit. >=20 > For ports I have like that, I've just created a branch in git. I rebase t= he > branch forward > each time I update. +1, I do basically the same. I'd say having a local branch in your local repo is one ot the killer features of git over svn. I just do a few details slightly different, maybe it helps as one possible example. I only fetch 'main' from the official repo and rebase my 'local' branch onto that. During the rebase, it's easy to solve any conflicts with changes in 'main'. You still keep a list of your local commits, well organized. I recently decided to also publish my local branch. So now I just have two remotes on my local ports repo, the official FreeBSD repo and another one on github, looking like this: # git remote -v origin https://github.com/Zirias/zfbsd-ports.git (fetch) origin https://github.com/Zirias/zfbsd-ports.git (push) upstream https://git.freebsd.org/ports.git (fetch) upstream https://git.freebsd.org/ports.git (push) With that and remote branch tracking set up correctly, I just need these commands (I have them in a script) to update from the official repo, rebase and force push to my github repo: git checkout local git fetch upstream main:main && git rebase main git push -f --all BTW, git leaves working copy changes alone if possible, so maybe it's poudriere's way of using git that erases them =E2=80=93 just use git direct= ly instead of poudriere. And then, I always hated having random local changes not organized in any way, this quickly grows into a maintenance nightmare, so I'm very thankful I can now easily use git branches instead. --=20 Dipl.-Inform. Felix Palmen ,.//.......... {web} http://palmen-it.de {jabber} [see email] ,//palmen-it.de {pgp public key} http://palmen-it.de/pub.txt // """"""""""" {pgp fingerprint} A891 3D55 5F2E 3A74 3965 B997 3EF2 8B0A BC02 DA2A --fsieiwvezpx2nbjh Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEzBAABCAAdFiEEqJE9VV8uOnQ5ZbmXPvKLCrwC2ioFAmFlutUACgkQPvKLCrwC 2iof4wgAtWj71NFTzAhgsE67y+po529rv/x7Rrt8E9LQGQk+PMJ2RU+2CiOGFZoZ UbAB4Qeta6BRZDIrcy3G70GYrNtrAktrS+ZBPQ4i9kbEhPO9ODQ5+ky/z/PCwGh5 iTdT7siFvdiG5wJ6yy2VDMcwfxSg1ZEn/kCtuEoqlXMCiRlOGtozc3kvkxSMkbrC Qv0s2Tqfjgi2rFEdcSU1P2AekQStmtY+X8ADVGcn9xFbSfnf203qvxosP2CglFQ/ 0uDzFJJpg5HVHryGaRfO08m/OayyCHG686vXkh7k3Y0C4/ql+4xUfPJdpAPz5DUo E9UuGiI4d3dQc5WVIyhoLL5WXjH0AA== =YhUn -----END PGP SIGNATURE----- --fsieiwvezpx2nbjh-- From nobody Tue Oct 12 18:01:56 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 94AAC17F626B for ; Tue, 12 Oct 2021 18:02:03 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: from spindle.one-eyed-alien.net (spindle.one-eyed-alien.net [199.48.129.229]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTNlv3Yxvz3QbW for ; Tue, 12 Oct 2021 18:02:03 +0000 (UTC) (envelope-from brooks@spindle.one-eyed-alien.net) Received: by spindle.one-eyed-alien.net (Postfix, from userid 3001) id E80293C0199; Tue, 12 Oct 2021 18:01:56 +0000 (UTC) Date: Tue, 12 Oct 2021 18:01:56 +0000 From: Brooks Davis To: FreeBSD User Cc: FreeBSD CURRENT Subject: Re: git: "overlay" of own remote-branch on official freebsd-ports repo Message-ID: <20211012180156.GA90843@spindle.one-eyed-alien.net> References: <20211012173148.1d2f138c@hermann.fritz.box> 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: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="T4sUOijqQbZv57TR" Content-Disposition: inline In-Reply-To: <20211012173148.1d2f138c@hermann.fritz.box> User-Agent: Mutt/1.9.4 (2018-02-28) X-Rspamd-Queue-Id: 4HTNlv3Yxvz3QbW X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: N --T4sUOijqQbZv57TR Content-Type: text/plain; charset=us-ascii Content-Disposition: inline On Tue, Oct 12, 2021 at 05:31:48PM +0200, FreeBSD User wrote: > I'd like to ask how FreeBSD developers and maintainers do the trick. If there is an > official cookbook fpr maintainers (I haven't found it yet ...), please be so kind and > refer to it. Any advice is welcome. If you only want to add extra ports, I'd recommend maintaining a separate repo for use with the ports collection's under-documented overlay feature. This avoids the need to rebase or merge your trees. You create the overlay in poudriere with something like: poudriere ports -c -p cheri-ports-overlay -U https://github.com/CTSRD-CHERI/cheri-ports-overlay.git -m git -B main You then use it by adding -O cheri-ports-overlay to your other poudriere commands like poudriere bulk. Note that you may need to install poudriere-devel or install it by hand to get this feature. -- Brooks --T4sUOijqQbZv57TR Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQEcBAEBAgAGBQJhZc2UAAoJEKzQXbSebgfAmhgH/1hsILj4lVebowxbksUyB/iX wX2n2wfH3ovnO8WSXTNwmcpxxvIHp8R78RtYPn83Zq6Hg5VKsrU4Vn5cKV7ttfrx W0c4AHfojEVeBDkbADy56lukVZjrCTK/ftfRjRpgrCxpJBk7pABeBjHdIgHId/OQ cE3Ue+Iv5YKwY+Wn89lMUfnYPdbsuQALyMKEeeAodQzoaYJeHCj1KDe562QLBEUo GsNmJ70O2dIZ7WdIgg2Gv4SoRQ8AUg+LNQeo2KprlmoWM1cJvrDbtyEOir1GuSun q95KVabgamCxOua/deubLsxTTtBg6dGREgHRQIysrwvFocT1l1I10rHWvKXdRIQ= =2uLf -----END PGP SIGNATURE----- --T4sUOijqQbZv57TR-- From nobody Tue Oct 12 18:39:55 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 83E80180763F for ; Tue, 12 Oct 2021 18:40:06 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (mail.lysator.liu.se [IPv6:2001:6b0:17:f0a0::3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTPbn1bsGz3tcG for ; Tue, 12 Oct 2021 18:40:05 +0000 (UTC) (envelope-from pen@lysator.liu.se) Received: from mail.lysator.liu.se (localhost [127.0.0.1]) by mail.lysator.liu.se (Postfix) with ESMTP id DB4D640004 for ; Tue, 12 Oct 2021 20:39:55 +0200 (CEST) Received: by mail.lysator.liu.se (Postfix, from userid 1004) id C87A640005; Tue, 12 Oct 2021 20:39:55 +0200 (CEST) X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on bernadotte.lysator.liu.se X-Spam-Level: X-Spam-Status: No, score=-0.9 required=5.0 tests=ALL_TRUSTED,AWL,HTML_MESSAGE autolearn=disabled version=3.4.2 X-Spam-Score: -0.9 Received: from smtpclient.apple (vpn-64.twilight.ifm.liu.se [130.236.167.64]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.lysator.liu.se (Postfix) with ESMTPSA id D198340004 for ; Tue, 12 Oct 2021 20:39:53 +0200 (CEST) From: Peter Eriksson Content-Type: multipart/alternative; boundary="Apple-Mail=_D3BCACE6-ED8F-48FE-A21A-AEE636A6A5EC" 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 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Panic in pipe_write from syslogd in 12.2? Message-Id: <0FFAABE0-F260-4FE0-8B1D-1F179C502170@lysator.liu.se> Date: Tue, 12 Oct 2021 20:39:55 +0200 To: freebsd-current X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Virus-Scanned: ClamAV using ClamSMTP X-Rspamd-Queue-Id: 4HTPbn1bsGz3tcG X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=pass (policy=none) header.from=liu.se; spf=pass (mx1.freebsd.org: domain of pen@lysator.liu.se designates 2001:6b0:17:f0a0::3 as permitted sender) smtp.mailfrom=pen@lysator.liu.se X-Spamd-Result: default: False [0.55 / 15.00]; RCVD_TLS_LAST(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; MV_CASE(0.50)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-0.38)[-0.382]; NEURAL_SPAM_MEDIUM(0.93)[0.925]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_HAM_SHORT(-0.69)[-0.694]; DMARC_POLICY_ALLOW(-0.50)[liu.se,none]; R_SPF_ALLOW(-0.20)[+a:mail.lysator.liu.se]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:1653, ipnet:2001:6b0::/32, country:EU]; SUBJECT_ENDS_QUESTION(1.00)[]; MID_RHS_MATCH_FROM(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --Apple-Mail=_D3BCACE6-ED8F-48FE-A21A-AEE636A6A5EC Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 I just noticed that a couple of my 12.2-RELEASE-p4 running servers = have=E2=80=A6 8263, 14474 and 3831 defunct subprocesses from syslogd and = also seems to have stopped writing to the log files=E2=80=A6 When I = tried to kill syslogd on a fourth server (with some X000 defunct = processes) the machine panic=E2=80=99ed and rebooted. I seem to have a vague memory of this being a known bug/someone saw = something similar or perhaps even solved in later patch releases? But my = google-fu seems to be failing me today. Anyone else remember? (The one that panic=E2=80=99ed is now running -p10 instead which they = should have done a long time ago but=E2=80=A6) I reported it on the FreeBSD bugzilla: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D259084 = Output from one that still is running: # egrep syslogd /var/log/sys/15:10/procstat-kk-a.log 9212 101640 syslogd - mi_switch+0xd4 = sleepq_catch_signals+0x403 sleepq_wait_sig+0xf _sleep+0x1de = pipe_write+0x583 dofilewrite+0xb0 sys_write+0xc0 amd64_syscall+0x387 = fast_syscall_common+0xf8 Output from the one that panic=E2=80=99ed: Fatal trap 12: page fault while in kernel mode cpuid =3D 20; apic id =3D 14 fault virtual address =3D 0x410 fault code =3D supervisor read data, page not present instruction pointer =3D 0x20:0xffffffff80b9f55c stack pointer =3D 0x28:0xfffffe14debc6710 frame pointer =3D 0x28:0xfffffe14debc6790 code segment =3D base r = x0, limit 0xfffff, type 0x1b =3D DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags =3D interrupt enabled, resume, IOPL =3D 0 current process =3D 9277 (sshd) trap number =3D 12 panic: page fault cpuid =3D 20 time =3D 1633990484 KDB: stack backtrace: #0 0xffffffff80c0ad75 at kdb_backtrace+0x65 #1 0xffffffff80bbf02b at vpanic+0x17b #2 0xffffffff80bbeea3 at panic+0x43 #3 0xffffffff8108e911 at trap_fatal+0x391 #4 0xffffffff8108e96f at trap_pfault+0x4f #5 0xffffffff8108dfb6 at trap+0x286 #6 0xffffffff81066c28 at calltrap+0x8 #7 0xffffffff80c6365f at unp_pcb_owned_lock2_slowpath+0x12f #8 0xffffffff80c61e0f at uipc_send+0x139f #9 0xffffffff80c55b7a at sosend_generic+0x4ca #10 0xffffffff80c55f90 at sosend+0x50 #11 0xffffffff80c5cc55 at kern_sendit+0x225 #12 0xffffffff80c5cfcc at sendit+0x19c #13 0xffffffff80c5ce1d at sys_sendto+0x4d #14 0xffffffff8108f4c7 at amd64_syscall+0x387 #15 0xffffffff8106754e at fast_syscall_common+0xf8 Uptime: 212d21h35m47s - Peter --Apple-Mail=_D3BCACE6-ED8F-48FE-A21A-AEE636A6A5EC-- From nobody Tue Oct 12 19:36:36 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 C636817F4D31 for ; Tue, 12 Oct 2021 19:36:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.gq1.yahoo.com (sonic302-22.consmr.mail.gq1.yahoo.com [98.137.68.148]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTQsF3ZHgz4gfF for ; Tue, 12 Oct 2021 19:36:49 +0000 (UTC) (envelope-from marklmi@yahoo.com) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634067402; bh=h5C7I8LCAcw5Q4tEf0GHCCzPXTDoAElXQo57LM/SV8Q=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=dyM8Olg+WNwd2QHISUWqTwBU4IwfXLZOEEetCE6tDVB2V2vtGeJhFKNesGGa6YTGZuXeWd34AqvzOfB8+ZwFk71mEobWf1AoyW+H0elSJw/Wy1A6yNahMCjDLvP4OSS5r7oMc7GL4Ybgb0Jok+1XmQ3J4t4GUjK3LMrtcSHWbQC+k2W577Qy1pXlitMJap3yX86auw0xVMqN+VasUXz0Tw965LZzIg5IoY128lH/vYcOKUUCsrKuKOcFMRmuBTHZl7rkV7WT74ghrseZW4DiwYMvEbXuIxenvKe9a5X4cVBqeI3Mm+eoTDC+HKIBoQ5ISWEjmxdw6r3wO6Nhr3oc2w== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1634067402; bh=5wMbPGyxCIAXoiBWepl2aw8BJKqZTh1Dl0B6muUXFLG=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=UdGmI8rBdohkBe5V+d6LsSECUo+OW4tNHmFYhEpOHDooevd369fkRaIWoivkEsLHOcgJKy/WH7KR7VMHzZCF1ckuJ7x2AsX4gDtnVWZvRCVvYEPx0GJtgClTwsOhlrAXOOieV0kC1oAZxCt+bdn+87qtP35WAepVjCS8ViGL0Ok7rUkkWsGG66Z7T2P6v+g9DdrTBa74nBKlP4IdZf1HTM0GVjqYIpsAoBYIH6QtRtnOVprBL6fNRlsSAc1sgelV11G5NXNUfo2FjMCHmzqTcWhPaUTi0xxe5P8nhrGOeqyb9kOYSEDUq/7HYo5vmlRGLF1Ht+v91ElQ/AxLVBSy/Q== X-YMail-OSG: .SJ6O6oVM1kgznPnQCxITgMWyE90m9AnjWRFvy9FGYp4wTnacH8PPL9x8bHe7ld t80vOmrMyYy4vt1Vdv63QEp66zVkf5ppeCiyd48HlewzOMca7kOsrrewMPANdAf.QFPv3u0LMrzM rTsUkXLXvDeXGjhVDzmUjkM3IIZC6bSynmImKJIV9JWpKf4l9GUGZvkFUWyF6DEefjQsjckBJRNI yLzEBcT3XdQfN7A78GCJy3JwY5czz.4aOHC_03EmtxuMQsiUjSDwkVhm_MPDFWR3usiQNoRxwCuF t6MAlM1sLD0fFOQUL8zbWe12YkNhzn5NFsST5PISKIRVl2NH0AH2Z6GIR0_elU.nWC9b8OPARo0a O9rbJPGe9NTW8eiNjOZq01n.B.WrnHlJp0LDu1XfSFnwRaJ2UIpujMaBzwPgF8bpwyBQgoxJJWBP r1.Peic6taipAttYv2szzHF5Z0IDf3FJbiRI32I3BARb2sVJsO2r.tJ1tIk7HpMBV_EK62e00afZ HL1R_1FXR0H0CI5UzJudWNdcVnkc1oK66aEJCIcT05SDpgD2w6ArmDnjUipSKpS1M1J5cr4UkfMC r4bv3IUIQcRdR.NtyHzTvOGy6Xy_SivYH3mc.KqXcP5QFb.5ojSfaa8A06Vq5bD3wJXBRb9eiCmJ kWXj1iGLdUUOT5dIvRvI9lRUvLo9AV8DGBL9Ec8BZYRmTvOk2inpNy_yquH.GFw1njNT7AitnITC TDi5Taz3.KzWSqdLF42XSs_OX7lmRZMiID5ShGYHv9zwFsDqVr6rh8e75znTu9R9lsuXZvcYoBe_ kYu8rnINWt1ZRPNJEAZ1HK8NlCH8FU1vU1PvLOTmZ_zC0CSMwc8Z7pqfu.q39Vt9h_ba9k.wytrv 9FJguQS5La3XX1N.vPeu7TBgvNM_Tr4QjI7kTZT8kwPrKvP49DDn0zoAN1JTx0SCRO2.1sWFFwFv rhl04g9GvpydIFHULX5yXS5I9uD3c5W0l3sxAOcP8a.DQe17TxEAmULUxEjAE_DWU2Sobra8BWwG wOGQKqLfz5.5uC0sYC.46.mk3M2uUzAfWtoDf9A0HCejYqUA58_QiBiCZRUEjVo8WX9dbzHadigY Njg8jkePGlRV_GYobbX.QS3fA6t..CSxLfSfD0j88ksTnLrcwWq3Wf7lA0wWnIA_wSp0rVmU5Trq uMCgTvOIUdCmDsZq81hQoU6WnfjMHl6CQdFonv_XuBHLIxu6V2D_No_0oa1Yv9cU6PqdM71EiFF0 4uyriq00QVY4PE9VCHlnDW8MtL_JvUOAG3d67efPrU1kya61dFHiZH_tYHqiEKuMuWpmBVTWKkQf B09PseOwt7v_YpRhNRmFaYVfr.pG2N4VCpU16odOZBcm56gRNzoj8DTRC6SHUi5uAyAyKr0iGdF. e4SHHBw25sIToY8ZGYTpC.5cl.vSEzzFVkITjVdvib._lxfiGnwaBqi2KUMRlaqZ12nRx_UR31_v gQnwXHwaGOCeITE3NCJCNpRD_2FcDc1O.4nEgr0f1ceT18pYj6s2q.wcODnWZ5uoenPCeuUMueeI lBzqEiBJ_WBUr4.3g1S688VKNA4evqeQpDEJY6XTOVa83yHnjL01sXbyZQBR60kIH27IkzXyRFw2 VcwZTB3QIPZJfMvS1U9QIijZGrB3G0M1PZoKDL2RPhrCrur1LPpQTBRLO7_9g3md.FIhQllXXW2J MvlCLzT0MG.yCBWS952RotQMwlH1wSyYu7XVr7T9.vspuCLHxqjPlvuX84ELKwR5RxnqPLYq3zfY NND7viEficNAOYK1LEnnqPwwdyPtFE4F1OJ7NsE4mQ5Qd4nLpnIKYZqHFTtpK95NhlVTWyn5ZZJc jdMldXfnDztHZ.ELLJX4Prb49N9g0d7Z9GwK_Mo2P0EiYH0hFAUXONvV70qou8x4tN.NiseQgxzX D_Lw._Drz56EVaL0DiXraPA.3jhtrntRansr7ZCAJagb0tVi0zGHaDNMFkbA61R.LcTYguIhMugB Do2dEIuuZigLSv0jhHmSzBhWmjODrLtmGVQl.f_uM_yYvdBfn5bUSHg9P40U5l47VvAcx76KgU4N jbponX9EgRXjeHsaKPKGQ4Cbeyl.3iVRPV9Z4BWAWWTzd1TRJZ.DL.27nWWqJk87Oc9BfQF0.CTQ pHofAbn5wwIMCBGJQ9EvHFUG4ifWcSMpw.Ujmiak4auZmyQ06K2tpJlos4F1upk26TXRXdKVwGbZ GwNEmp1neLCH8_H0CW8WFqC0AYxjNnuworO7NfrHa0u5tpShxJtnQz5yUC8KfGRKnf7o_fq56DqZ oaJnuWhpyntbx_2J2Skzaw1Ty_WAushLvqtvg4HGeHMrgWZL__VB9qev81EHN9hWxgFEu X-Sonic-MF: Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.gq1.yahoo.com with HTTP; Tue, 12 Oct 2021 19:36:42 +0000 Received: by kubenode520.mail-prod1.omega.gq1.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID b60da538148605756499374c12b210c8; Tue, 12 Oct 2021 19:36:37 +0000 (UTC) Content-Type: text/plain; charset=us-ascii 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 (Mac OS X Mail 14.0 \(3654.120.0.1.13\)) Subject: Re: After updating main (so: 14) Orange Pi+ 2E panicked: ucom_cons_softc "'Translation Fault (L2)' on read" while typing first command after login In-Reply-To: Date: Tue, 12 Oct 2021 12:36:36 -0700 Cc: Free BSD , freebsd-current Content-Transfer-Encoding: quoted-printable Message-Id: References: To: Hans Petter Selasky X-Mailer: Apple Mail (2.3654.120.0.1.13) X-Rspamd-Queue-Id: 4HTQsF3ZHgz4gfF X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] Reply-To: marklmi@yahoo.com From: Mark Millard via freebsd-arm X-Original-From: Mark Millard X-ThisMailContainsUnwantedMimeParts: N On 2021-Oct-12, at 01:43, Hans Petter Selasky = wrote: > On 10/12/21 3:11 AM, Mark Millard via freebsd-arm wrote: >> There is this "mixer" oddity for each boot: >> Feeding entropy: . >> mixer: 75:75: no such device >> mixer: 75:75: no such device >> mixer: 75:75: no such device >> mixer: 25:25: no such device >> mixer: 75:75: no such device >> mixer: 75:75: no such device >> mixer: =3Drec: no such device >> lo0: link state changed to UP >> (in case that matters for some reason). >=20 > Hi, >=20 > Add this script to /etc/rc.d/ and you'll be fine from now on. > https://cgit.freebsd.org/src/tree/libexec/rc/rc.d/mixer >=20 > Then run: > service mixer stop && service mixer start >=20 > And the problem should go away. >=20 > See "git: 903873ce1560 - main - Implement and use new mixer(3) library = for FreeBSD" Copying /usr/main-src/libexec/rc/rc.d/mixer and then doing the stop/start sequence made the boot messages go away. Thanks. (I've never done anything explicit with mixer or such. The default installation must have involved it, despite this file not being put in place by the update.) =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From nobody Tue Oct 12 19:56:40 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 D91ED17FD8DA for ; Tue, 12 Oct 2021 19:56:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa2c.google.com (mail-vk1-xa2c.google.com [IPv6:2607:f8b0:4864:20::a2c]) (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 4HTRJT3JRxz4nMR for ; Tue, 12 Oct 2021 19:56:57 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa2c.google.com with SMTP id x207so238209vke.2 for ; Tue, 12 Oct 2021 12:56:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJZkU06BwyU9+sTfuEQ9DMkavrdMjFyB6zmANmkCLOA=; b=wjJoa/3b2RHuO9ttJZJpmWig3sPe4vodkM6Xag1AJ2IduEV2woRG/rBnn+O+YPl2C1 wS7I6/Pt9COqFYMf85863//9Tn3EpyJ0wEecXp3JnGcyKAIRayRJMfguYstJuBdzwa6K hPhQr7Vbu+o271yLFhyCQ+RtAgpBGqnGg/SD5jxonlJ87fxFPOVl7WTYYJVTe8E/wXBb jp2viAf7iH0lQReH0DG9ziW0mNu1WgK5ohLrMI7y+cpk8C7anjRVB8bT/1tLduH7MouL yM+RGIVariJ5fhk9zkBkwEeYzKGiBtJuvNBI3sA74iczjweukPQfZc8L4vBiLq5nmlZe UWPA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oJZkU06BwyU9+sTfuEQ9DMkavrdMjFyB6zmANmkCLOA=; b=Lp5Mv1F88LgyPhMxPkZH7504WZovPOjuhxfDgsC8kCRYRD/VAZvymInfq8gT7NUo76 U6L5FcozHn/GaA5MFGVTrEvt9quPaZ6RBDIoTe23/w1kp7lgH9fSGFrBKE4g3EHacGUL Vm+j0PbcqdPI0n/jylgKokZHcYccdTSIpo0dS8PAJmZ7rG5Nwr0tLBSUuzFuU3LnOn/q UXl+q2zF0Q1C8C2VclzyYAmgPoEvLIBQu6IF2RrDrhwuwiAyRRneF1HE15rYZXE6xct3 q962iHYhWQ2KNrx3VY6ofTSqzFQMHZFQdfQoWTtDm7TTYSh6W+4xVL9P+Z4BVIphmjGm +muw== X-Gm-Message-State: AOAM5328YlcVahzVMI4G4A4lxAwYF3zVegKY7hmvLGE+cNg/V7xTLO/+ apOi2E/BUK3YxJfkUUWzUaF562M5ILGwJEczP5iCAQ== X-Google-Smtp-Source: ABdhPJwBtwTXtN/vTe/6BMdKLXe9TRkHEFUHmm9Ud72HnpDuPtZa3HK4p/cSy6bL7KuCKA5Xth7ZlhA11yKacyHw+7E= X-Received: by 2002:a1f:2d83:: with SMTP id t125mr29159743vkt.23.1634068611364; Tue, 12 Oct 2021 12:56:51 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Tue, 12 Oct 2021 13:56:40 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Pavel Timofeev Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="0000000000001e8fb705ce2d3faa" X-Rspamd-Queue-Id: 4HTRJT3JRxz4nMR X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b="wjJoa/3b"; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a2c) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-2.99 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_HAM_SHORT(-0.99)[-0.995]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a2c:from]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: Y --0000000000001e8fb705ce2d3faa Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable One piece of data that would be good to have: nvmecontrol identify nvme0 There's an optional feature that none of my drives have, but that the Linux driver does oddly weird things when enabled. The output of that command will help me understand if that may be in play. Maybe we need to do oddly weird things too :) Warner On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: > > > On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev wrote: > >> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner Lo= sh : >> >>> >>> >>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >>> >>>> >>>> >>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner = Losh : >>>> >>>>> >>>>> >>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev >>>>> wrote: >>>>> >>>>>> >>>>>> >>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Warn= er Losh : >>>>>> >>>>>>> >>>>>>> >>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> Warner Losh : >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> Pavel Timofeev : >>>>>>>>>> >>>>>>>>>> > >>>>>>>>>> > Chuck Tuffli : >>>>>>>>>> > >>>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >>>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>>> >> > >>>>>>>>>> >> > Hello >>>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the late= st >>>>>>>>>> >> 14.0-CURRENT >>>>>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>>>>> >> > nvme0: Missing interrupt >>>>>>>>>> >> > message I get sometimes on the console. >>>>>>>>>> >> > It seems like I get it only after the reboot of the laptop, >>>>>>>>>> i. e. not >>>>>>>>>> >> > getting that message if I power cycle the laptop, at least = I >>>>>>>>>> haven't >>>>>>>>>> >> seen >>>>>>>>>> >> > them for now in such cases. >>>>>>>>>> >> > So when the laptop is rebooted I can't even take advantage = of >>>>>>>>>> >> > nvmecontrol(8) quickly. >>>>>>>>>> >> > Well, it still works, but it takes tens of seconds to retur= n >>>>>>>>>> the output. >>>>>>>>>> >> ... >>>>>>>>>> >> > dmesg when power cycled - >>>>>>>>>> >> > >>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8Sw= J >>>>>>>>>> >> > dmesg when rebooted - >>>>>>>>>> >> > >>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bx= h >>>>>>>>>> >> >>>>>>>>>> >> I'm sort of curious about the time stamps for the log message= s >>>>>>>>>> in the >>>>>>>>>> >> failing case. Something like: >>>>>>>>>> >> >>>>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>> >> >>>>>>>>>> >> --chuck >>>>>>>>>> >> >>>>>>>>>> > >>>>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>>>> missing some >>>>>>>>>> > configuration for that? >>>>>>>>>> > >>>>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>> > nvme0: mem >>>>>>>>>> > >>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f at device >>>>>>>>>> > 0.0 on pci6 >>>>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >>>>>>>>>> MPSMAX 0 >>>>>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>> > nvd0: NVMe namespace >>>>>>>>>> > GEOM: new disk nvd0 >>>>>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>>>> > >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Ah, sorry, provided wrong output. >>>>>>>>>> Here is what you requested: >>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: me= m >>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104ff= f >>>>>>>>>> at device >>>>>>>>>> 0.0 on pci6 >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 >>>>>>>>>> MSI-X >>>>>>>>>> vectors (17 supported) >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for >>>>>>>>>> MSI-X >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>>>>> 1023, CQR, >>>>>>>>>> TO 20 >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD >>>>>>>>>> 0, NSSRS, >>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>> 512GB> NVMe >>>>>>>>>> namespace >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 >>>>>>>>>> byte >>>>>>>>>> sectors) >>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>> >>>>>>>>> >>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and >>>>>>>>> hw.cam.nda.nvd_compat=3D1 >>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd >>>>>>>>> was? Or does >>>>>>>>> it work? >>>>>>>>> >>>>>>>>> Something weird is going on in the interrupt assignment, I think, >>>>>>>>> but I >>>>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>>>> >>>>>>>>> Warner >>>>>>>>> >>>>>>>> >>>>>>>> Do you mean kern.cam.nda.nvd_compat instead >>>>>>>> of hw.cam.nda.nvd_compat? >>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>>>> >>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still >>>>>>>> see >>>>>>>> nvme0: Missing interrupt >>>>>>>> and now also >>>>>>>> Root mount waiting for: CAM >>>>>>>> messages besides those >>>>>>>> >>>>>>> >>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by defa= ult >>>>>>> these >>>>>>> days. >>>>>>> >>>>>>> I'll take a look on monday starting at the differences in interrupt >>>>>>> assignment that >>>>>>> are apparent when you cold boot vs reboot. >>>>>>> >>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >>>>>>> didn't really >>>>>>> expect it to be. >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>> >>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>>>> worse now. >>>>>> So clean poweron works as before. >>>>>> But if rebooted nvme drive refuses to work, while before the code >>>>>> upgrade it was just complaining about missing interrupts. >>>>>> >>>>>> currently dmesg show this: >>>>>> nvme0: mem >>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at= device >>>>>> 0.0 on pci6 >>>>>> nvd0: NVMe namespace >>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>> nvme0: mem >>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at= device >>>>>> 0.0 on pci6 >>>>>> >>>>> >>>>> Why is this showing up twice? Or is everything above this line left >>>>> over from the first, working boot? >>>>> >>>>> >>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>>>> nvme0: timeout with nothing complete, resetting >>>>>> nvme0: Resetting controller due to a timeout. >>>>>> nvme0: RECOVERY_WAITING >>>>>> nvme0: resetting controller >>>>>> nvme0: aborting outstanding admin command >>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>> cdw11:00000000 >>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>> nvme0: nvme_identify_controller failed! >>>>>> nvme0: waiting >>>>>> >>>>> >>>>> Clearly something bad is going on with the drive here... We looked >>>>> into the completion queues when we didn't get an interrupt and there = was >>>>> nothing complete there.... >>>>> >>>>> The only thing I can think of is that this means there's a phase erro= r >>>>> between the drive and the system. I recently removed a second reset a= nd >>>>> made it an option NVME_2X_RESET. Can you see if adding >>>>> 'options NVME_2X_RESET' to your kernel config fixes this? >>>>> >>>>> Warner >>>>> >>>>> >>>>>> nvme0: mem >>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at= device >>>>>> 0.0 on pci6 >>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>>>> nvme0: timeout with nothing complete, resetting >>>>>> nvme0: Resetting controller due to a timeout. >>>>>> nvme0: RECOVERY_WAITING >>>>>> nvme0: resetting controller >>>>>> nvme0: aborting outstanding admin command >>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>> cdw11:00000000 >>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>> nvme0: nvme_identify_controller failed! >>>>>> nvme0: waiting >>>>>> >>>>>> >>>> >>>> Sorry, it's showing twice due to multiple reboots. For one boot it's >>>> like: >>>> nvme0: mem >>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at d= evice >>>> 0.0 on pci6 >>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >>>> nvme0: timeout with nothing complete, resetting >>>> nvme0: Resetting controller due to a timeout. >>>> nvme0: RECOVERY_WAITING >>>> nvme0: resetting controller >>>> nvme0: aborting outstanding admin command >>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:0000000= 0 >>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>> nvme0: nvme_identify_controller failed! >>>> nvme0: waiting >>>> >>>> Well, neither Windows not Linux have any problems with the device. I >>>> understand they may be hiding it or workaround somehow. >>>> >>> >>> Yea, I'm trying to figure out why your machine is different than mine, >>> and what Windows or Linux do that is different. It may be dodgy hardwar= e, >>> but others have no trouble... >>> >>> I'll try setting NVME_2X_RESET in the kernel config and report back in = a >>>> while. >>>> >>> >>> Thanks. If it helps, that tells me something. If it doesn't, that tells >>> me something else. >>> >>> I suspect that it is somewhere else in the system, tbh, but I need to >>> find it systematically. >>> >>> Warner >>> >> >> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed >> anything. I. e it didn't help. >> > > While it would have been nice to have this be the fix, I'm not that > surprised either. > It was the biggest change of late, apart from the big re-arrangement that > I'd done. > > So the other changes have moved from the occasional missing interrupt > message > (which the old code would get when a command wasn't completed in the > timeout > period, but that we found to be done when we scanned the completion queue= . > Now > the device is detected fine (as before), but then doesn't do I/O at all > (including not > completing the identify command!) and is worse. This is unexpected and I'= m > trying > understand what happens on reboot that 'changes'the working state and why > the > new code behaves so differently. > > Warner > --0000000000001e8fb705ce2d3faa-- From nobody Wed Oct 13 00:51:29 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 8C65717F69BE for ; Wed, 13 Oct 2021 00:51:42 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x52d.google.com (mail-ed1-x52d.google.com [IPv6:2a00:1450:4864:20::52d]) (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 4HTYrZ2n7Fz3lb3 for ; Wed, 13 Oct 2021 00:51:42 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x52d.google.com with SMTP id t16so2941991eds.9 for ; Tue, 12 Oct 2021 17:51:42 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Oj3Xpt1V0q83D+gfImnbEIYOHiwg66NlaNuh91QH6a0=; b=SN4AkpH7isv6zU578WhNXBnLac/S+vLQPpQjbeWhxuQs227IoczuB2LG8t375XvH4w 1IgR4MfCVFwPMKwCQpUnPOyYF3kaih1PLnb4ESIfAER0kB3nbdROjBQcmHG1979/vsaa YAGsqDePNv60ojqXhcFUAVSb1Dik3P0q253iGewpcapkCxYSAP7Xoflw4UC6E2O/dN9r XSd6n6ruXYPAU6xFTFXb8LwoMnSNrbVXnqMxjgDI7M/eR1aN/BC3SxN5gHWTR53lNG/+ UX6CV0MYGB7Sj2O711q8+HOZBikHO1+3IURTQ2MRDwGokwZxzgWJAPStmRpmgpABOikP crmQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Oj3Xpt1V0q83D+gfImnbEIYOHiwg66NlaNuh91QH6a0=; b=F/MOSeXkdh9ptIlOvu77aYkmOPzFP9aLoLcPM9nFIVr252LFZHo/IvqwhEeixLE1Ao qJcvk/FqP2flvyk3cVDxRZIPXpWxuZUhBn7Ebf0tsSqXNYKFJvcFYQ6g4v1DJkCsiaMy Hf1UyLFhEgvY/CrQfkCfwxpeBGhQiStGGueSp50zbySyhpysP+59M2Suogp7nVQrPAYL Q7ti365LuY35n7G92Lw/1uhTLaD5eVWAo834wyQkv8qgb3AZlK5SOWtBeU7al+kZ3hzz CR+BLcrX8tSvYen7rjyv9fNHndOxwJXtcRT9pbdQiVWynC9FNHR5x4f8aigRin3Rn5Uy 9v4w== X-Gm-Message-State: AOAM530OCjjF6O2jsDTYdHUpH25tt9Or8ihjH8UKZDNl5lC5XESmPJ4g OBtOe4Fto8wR7nWSYlXlP7Qi94oJt1Hws3gB0Fk= X-Google-Smtp-Source: ABdhPJxlAnBPyLtWtumHkwjAM7ApNY/R04zRXfQrYJdJEZhwGz/tV7LC3xx+nAs2nz6ghmlMvy7OYQgyCBAj3p1LQyo= X-Received: by 2002:a17:907:1c0e:: with SMTP id nc14mr36864868ejc.103.1634086301078; Tue, 12 Oct 2021 17:51:41 -0700 (PDT) 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 References: In-Reply-To: From: Pavel Timofeev Date: Tue, 12 Oct 2021 18:51:29 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Warner Losh Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="00000000000082166e05ce315d6d" X-Rspamd-Queue-Id: 4HTYrZ2n7Fz3lb3 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000082166e05ce315d6d Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=82, 12 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 13:56, Warner Losh= : > One piece of data that would be good to have: > > nvmecontrol identify nvme0 > > There's an optional feature that none of my drives have, but that the > Linux driver does oddly > weird things when enabled. The output of that command will help me > understand if that may > be in play. Maybe we need to do oddly weird things too :) > > Warner > > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: > >> >> >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev wrote= : >> >>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner L= osh : >>> >>>> >>>> >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >>>> >>>>> >>>>> >>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warner= Losh : >>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, War= ner Losh : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Warner Losh : >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Pavel Timofeev : >>>>>>>>>>> >>>>>>>>>>> > >>>>>>>>>>> > Chuck Tuffli : >>>>>>>>>>> > >>>>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >>>>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>>>> >> > >>>>>>>>>>> >> > Hello >>>>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the >>>>>>>>>>> latest >>>>>>>>>>> >> 14.0-CURRENT >>>>>>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>>>>>> >> > nvme0: Missing interrupt >>>>>>>>>>> >> > message I get sometimes on the console. >>>>>>>>>>> >> > It seems like I get it only after the reboot of the laptop= , >>>>>>>>>>> i. e. not >>>>>>>>>>> >> > getting that message if I power cycle the laptop, at least >>>>>>>>>>> I haven't >>>>>>>>>>> >> seen >>>>>>>>>>> >> > them for now in such cases. >>>>>>>>>>> >> > So when the laptop is rebooted I can't even take advantage >>>>>>>>>>> of >>>>>>>>>>> >> > nvmecontrol(8) quickly. >>>>>>>>>>> >> > Well, it still works, but it takes tens of seconds to >>>>>>>>>>> return the output. >>>>>>>>>>> >> ... >>>>>>>>>>> >> > dmesg when power cycled - >>>>>>>>>>> >> > >>>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8S= wJ >>>>>>>>>>> >> > dmesg when rebooted - >>>>>>>>>>> >> > >>>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38B= xh >>>>>>>>>>> >> >>>>>>>>>>> >> I'm sort of curious about the time stamps for the log >>>>>>>>>>> messages in the >>>>>>>>>>> >> failing case. Something like: >>>>>>>>>>> >> >>>>>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>> >> >>>>>>>>>>> >> --chuck >>>>>>>>>>> >> >>>>>>>>>>> > >>>>>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>>>>> missing some >>>>>>>>>>> > configuration for that? >>>>>>>>>>> > >>>>>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>> > nvme0: mem >>>>>>>>>>> > >>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104f= ff at device >>>>>>>>>>> > 0.0 on pci6 >>>>>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >>>>>>>>>>> MPSMAX 0 >>>>>>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>> > nvd0: NVMe namespace >>>>>>>>>>> > GEOM: new disk nvd0 >>>>>>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>>>>> > >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ah, sorry, provided wrong output. >>>>>>>>>>> Here is what you requested: >>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: m= em >>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104f= ff >>>>>>>>>>> at device >>>>>>>>>>> 0.0 on pci6 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate = 5 >>>>>>>>>>> MSI-X >>>>>>>>>>> vectors (17 supported) >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for >>>>>>>>>>> MSI-X >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>>>>>> 1023, CQR, >>>>>>>>>>> TO 20 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTR= D >>>>>>>>>>> 0, NSSRS, >>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.= 3 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>>> 512GB> NVMe >>>>>>>>>>> namespace >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 >>>>>>>>>>> byte >>>>>>>>>>> sectors) >>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and >>>>>>>>>> hw.cam.nda.nvd_compat=3D1 >>>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd >>>>>>>>>> was? Or does >>>>>>>>>> it work? >>>>>>>>>> >>>>>>>>>> Something weird is going on in the interrupt assignment, I think= , >>>>>>>>>> but I >>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>>>>> >>>>>>>>>> Warner >>>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead >>>>>>>>> of hw.cam.nda.nvd_compat? >>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>>>>> >>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still >>>>>>>>> see >>>>>>>>> nvme0: Missing interrupt >>>>>>>>> and now also >>>>>>>>> Root mount waiting for: CAM >>>>>>>>> messages besides those >>>>>>>>> >>>>>>>> >>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by >>>>>>>> default these >>>>>>>> days. >>>>>>>> >>>>>>>> I'll take a look on monday starting at the differences in interrup= t >>>>>>>> assignment that >>>>>>>> are apparent when you cold boot vs reboot. >>>>>>>> >>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >>>>>>>> didn't really >>>>>>>> expect it to be. >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>>> >>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>>>>> worse now. >>>>>>> So clean poweron works as before. >>>>>>> But if rebooted nvme drive refuses to work, while before the code >>>>>>> upgrade it was just complaining about missing interrupts. >>>>>>> >>>>>>> currently dmesg show this: >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t device >>>>>>> 0.0 on pci6 >>>>>>> nvd0: NVMe namespace >>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t device >>>>>>> 0.0 on pci6 >>>>>>> >>>>>> >>>>>> Why is this showing up twice? Or is everything above this line left >>>>>> over from the first, working boot? >>>>>> >>>>>> >>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>> nvme0: RECOVERY_WAITING >>>>>>> nvme0: resetting controller >>>>>>> nvme0: aborting outstanding admin command >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>> cdw11:00000000 >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>> nvme0: nvme_identify_controller failed! >>>>>>> nvme0: waiting >>>>>>> >>>>>> >>>>>> Clearly something bad is going on with the drive here... We looked >>>>>> into the completion queues when we didn't get an interrupt and there= was >>>>>> nothing complete there.... >>>>>> >>>>>> The only thing I can think of is that this means there's a phase >>>>>> error between the drive and the system. I recently removed a second = reset >>>>>> and made it an option NVME_2X_RESET. Can you see if adding >>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? >>>>>> >>>>>> Warner >>>>>> >>>>>> >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t device >>>>>>> 0.0 on pci6 >>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>> nvme0: RECOVERY_WAITING >>>>>>> nvme0: resetting controller >>>>>>> nvme0: aborting outstanding admin command >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>> cdw11:00000000 >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>> nvme0: nvme_identify_controller failed! >>>>>>> nvme0: waiting >>>>>>> >>>>>>> >>>>> >>>>> Sorry, it's showing twice due to multiple reboots. For one boot it's >>>>> like: >>>>> nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at = device >>>>> 0.0 on pci6 >>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >>>>> nvme0: timeout with nothing complete, resetting >>>>> nvme0: Resetting controller due to a timeout. >>>>> nvme0: RECOVERY_WAITING >>>>> nvme0: resetting controller >>>>> nvme0: aborting outstanding admin command >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:000000= 00 >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>> nvme0: nvme_identify_controller failed! >>>>> nvme0: waiting >>>>> >>>>> Well, neither Windows not Linux have any problems with the device. I >>>>> understand they may be hiding it or workaround somehow. >>>>> >>>> >>>> Yea, I'm trying to figure out why your machine is different than mine, >>>> and what Windows or Linux do that is different. It may be dodgy hardwa= re, >>>> but others have no trouble... >>>> >>>> I'll try setting NVME_2X_RESET in the kernel config and report back in >>>>> a while. >>>>> >>>> >>>> Thanks. If it helps, that tells me something. If it doesn't, that tell= s >>>> me something else. >>>> >>>> I suspect that it is somewhere else in the system, tbh, but I need to >>>> find it systematically. >>>> >>>> Warner >>>> >>> >>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed >>> anything. I. e it didn't help. >>> >> >> While it would have been nice to have this be the fix, I'm not that >> surprised either. >> It was the biggest change of late, apart from the big re-arrangement tha= t >> I'd done. >> >> So the other changes have moved from the occasional missing interrupt >> message >> (which the old code would get when a command wasn't completed in the >> timeout >> period, but that we found to be done when we scanned the completion >> queue. Now >> the device is detected fine (as before), but then doesn't do I/O at all >> (including not >> completing the identify command!) and is worse. This is unexpected and >> I'm trying >> understand what happens on reboot that 'changes'the working state and wh= y >> the >> new code behaves so differently. >> >> Warner >> > Sure, here it is: Controller Capabilities/Features =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D Vendor ID: 1c5c Subsystem Vendor ID: 1c5c Serial Number: ND03N46381010423H Model Number: PC611 NVMe SK hynix 512GB Firmware Version: 11000111 Recommended Arb Burst: 4 IEEE OUI Identifier: 2e e4 ac Multi-Path I/O Capabilities: Not Supported Max Data Transfer Size: 262144 bytes Sanitize Crypto Erase: Not Supported Sanitize Block Erase: Supported Sanitize Overwrite: Not Supported Sanitize NDI: Not Supported Sanitize NODMMAS: Undefined Controller ID: 0x0001 Version: 1.3.0 Admin Command Set Attributes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D Security Send/Receive: Supported Format NVM: Supported Firmware Activate/Download: Supported Namespace Management: Not Supported Device Self-test: Supported Directives: Not Supported NVMe-MI Send/Receive: Not Supported Virtualization Management: Not Supported Doorbell Buffer Config: Not Supported Get LBA Status: Not Supported Sanitize: block, Abort Command Limit: 4 Async Event Request Limit: 8 Number of Firmware Slots: 3 Firmware Slot 1 Read-Only: No Per-Namespace SMART Log: No Error Log Page Entries: 256 Number of Power States: 5 Total NVM Capacity: 0 bytes Unallocated NVM Capacity: 0 bytes Firmware Update Granularity: 00 (Not Reported) Host Buffer Preferred Size: 0 bytes Host Buffer Minimum Size: 0 bytes NVM Command Set Attributes =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D Submission Queue Entry Size Max: 64 Min: 64 Completion Queue Entry Size Max: 16 Min: 16 Number of Namespaces: 1 Compare Command: Supported Write Uncorrectable Command: Supported Dataset Management Command: Supported Write Zeroes Command: Supported Save Features: Supported Reservations: Not Supported Timestamp feature: Supported Verify feature: Not Supported Fused Operation Support: Not Supported Format NVM Attributes: Per-NS Erase, Per-NS Format Volatile Write Cache: Present NVM Subsystem Name: --00000000000082166e05ce315d6d-- From nobody Wed Oct 13 02:46:52 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 43B2018074B4 for ; Wed, 13 Oct 2021 02:47:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-ua1-x92e.google.com (mail-ua1-x92e.google.com [IPv6:2607:f8b0:4864:20::92e]) (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 4HTcPf0Cjjz4pt8 for ; Wed, 13 Oct 2021 02:47:02 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-ua1-x92e.google.com with SMTP id u5so1632368uao.13 for ; Tue, 12 Oct 2021 19:47:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=b0p6Dmn9/ut95/e4T+C6xVSloxlUEd4rnCNgWqyONJM=; b=BVB79uBXFPmkAwpGsuRVjHR1bdgeymCYXZq9N7Sl7FhTGQsWveslbJ2fDI4eeFKJAQ ce57dA9X56pLJnEDHzS/Bd6U0AifKbhUsZEJ8/DHcgyoO4ZMXdmO0yZJRvGl6gOPGNpB NeDMtEEUYlH8BWXlWFHTue8pimO4n4zDJA4R+n0N1ZiAmsnBMAK4f8L1cfdKne+JFLm8 TiXHmEi2FTVd6HGSTuko8Sb5Vl3eznhsvJLycS4a9A6sth7oq9v5lmWfalmrGr8K55KE ZAIwNGGT36PDtvq5JlSvk5HRTdq6sYUnfVcztDofhPTNv+TOQRDkx8E8VwwQ3piL+jOm qZPg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b0p6Dmn9/ut95/e4T+C6xVSloxlUEd4rnCNgWqyONJM=; b=W7N5+Is5AZR+P3TcqPl5evRbE/TTG5DhSIFXV2nM3jsVpCIHGB5AHGYDavnCqi1CwD ufj/akbZ+BrQmJ6JEzYaLqL0G77bnCtnmtRl2OYcbawgF99e2lHblkZiZlXUa4XRiBzR JQszytzSVi2WA3QG+SySnkarljbEOnaeT3zmfff2A6Srlw/jHGeHiaiyXcIQa1ZLmHgG zUrSx1vu//FA+meABs9tMcaTzjgFV6N+xDu+W3XcgPs+RZ93gQzSUykHgcxn0TwZd4+5 5CRcz3mdfujllyYYKZd3af7CmIz6Axw3PO1J3T2BitVmUES3lTHLvjubwjZMf0AB2/g4 IJww== X-Gm-Message-State: AOAM5336T82XnURTelGtoKOeRNQ16Is7O/q6VrWEjxNY0U/SLpQqbDC/ PYZWZ949yPu1y7JUPZmwuTntCZ8l8b5D57ANWeWGlQ== X-Google-Smtp-Source: ABdhPJy5TVii8L3Qvl9kSqcLg5sIeSWs/DsIj17yVkQMKf3xDb59YW4HKzyEW/srfVvPOfVirJYZFpAFWhphCIvZTtg= X-Received: by 2002:a05:6102:6ce:: with SMTP id m14mr35807105vsg.42.1634093221265; Tue, 12 Oct 2021 19:47:01 -0700 (PDT) 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 References: In-Reply-To: From: Warner Losh Date: Tue, 12 Oct 2021 20:46:52 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Pavel Timofeev Cc: Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="000000000000fbda0c05ce32f93e" X-Rspamd-Queue-Id: 4HTcPf0Cjjz4pt8 X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-ThisMailContainsUnwantedMimeParts: Y --000000000000fbda0c05ce32f93e Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Tue, Oct 12, 2021 at 6:51 PM Pavel Timofeev wrote: > > > =D0=B2=D1=82, 12 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 13:56, Warner Lo= sh : > >> One piece of data that would be good to have: >> >> nvmecontrol identify nvme0 >> >> There's an optional feature that none of my drives have, but that the >> Linux driver does oddly >> weird things when enabled. The output of that command will help me >> understand if that may >> be in play. Maybe we need to do oddly weird things too :) >> >> Warner >> >> On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: >> >>> >>> >>> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev >>> wrote: >>> >>>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner = Losh : >>>> >>>>> >>>>> >>>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >>>>> >>>>>> >>>>>> >>>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warne= r Losh : >>>>>> >>>>>>> >>>>>>> >>>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, Wa= rner Losh : >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>>>>>> wrote: >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Warner Losh : >>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev < >>>>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>>>> >>>>>>>>>>>> Pavel Timofeev : >>>>>>>>>>>> >>>>>>>>>>>> > >>>>>>>>>>>> > Chuck Tuffli : >>>>>>>>>>>> > >>>>>>>>>>>> >> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >>>>>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>>>>> >> > >>>>>>>>>>>> >> > Hello >>>>>>>>>>>> >> > I've got a Dell Latitude 7400 and tried installing the >>>>>>>>>>>> latest >>>>>>>>>>>> >> 14.0-CURRENT >>>>>>>>>>>> >> > (main-n248636-d20e9e02db3) on it. >>>>>>>>>>>> >> > Despite other things the weird one which concerns me is >>>>>>>>>>>> >> > nvme0: Missing interrupt >>>>>>>>>>>> >> > message I get sometimes on the console. >>>>>>>>>>>> >> > It seems like I get it only after the reboot of the >>>>>>>>>>>> laptop, i. e. not >>>>>>>>>>>> >> > getting that message if I power cycle the laptop, at leas= t >>>>>>>>>>>> I haven't >>>>>>>>>>>> >> seen >>>>>>>>>>>> >> > them for now in such cases. >>>>>>>>>>>> >> > So when the laptop is rebooted I can't even take advantag= e >>>>>>>>>>>> of >>>>>>>>>>>> >> > nvmecontrol(8) quickly. >>>>>>>>>>>> >> > Well, it still works, but it takes tens of seconds to >>>>>>>>>>>> return the output. >>>>>>>>>>>> >> ... >>>>>>>>>>>> >> > dmesg when power cycled - >>>>>>>>>>>> >> > >>>>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8= SwJ >>>>>>>>>>>> >> > dmesg when rebooted - >>>>>>>>>>>> >> > >>>>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38= Bxh >>>>>>>>>>>> >> >>>>>>>>>>>> >> I'm sort of curious about the time stamps for the log >>>>>>>>>>>> messages in the >>>>>>>>>>>> >> failing case. Something like: >>>>>>>>>>>> >> >>>>>>>>>>>> >> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>>> >> >>>>>>>>>>>> >> --chuck >>>>>>>>>>>> >> >>>>>>>>>>>> > >>>>>>>>>>>> > Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>>>>>> missing some >>>>>>>>>>>> > configuration for that? >>>>>>>>>>>> > >>>>>>>>>>>> > $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>>> > nvme0: mem >>>>>>>>>>>> > >>>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104= fff at device >>>>>>>>>>>> > 0.0 on pci6 >>>>>>>>>>>> > nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>>>>>> > nvme0: using IRQs 133-137 for MSI-X >>>>>>>>>>>> > nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>>>>>> > nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >>>>>>>>>>>> MPSMAX 0 >>>>>>>>>>>> > nvme0: Version: 0x00010300: 1.3 >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvme0: Missing interrupt >>>>>>>>>>>> > nvd0: NVMe namespace >>>>>>>>>>>> > GEOM: new disk nvd0 >>>>>>>>>>>> > nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>>>>>> > >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Ah, sorry, provided wrong output. >>>>>>>>>>>> Here is what you requested: >>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: >>>>>>>>>>>> mem >>>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104= fff >>>>>>>>>>>> at device >>>>>>>>>>>> 0.0 on pci6 >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate >>>>>>>>>>>> 5 MSI-X >>>>>>>>>>>> vectors (17 supported) >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for >>>>>>>>>>>> MSI-X >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQE= S >>>>>>>>>>>> 1023, CQR, >>>>>>>>>>>> TO 20 >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: >>>>>>>>>>>> DSTRD 0, NSSRS, >>>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1= .3 >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>>>> 512GB> NVMe >>>>>>>>>>>> namespace >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 51= 2 >>>>>>>>>>>> byte >>>>>>>>>>>> sectors) >>>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and >>>>>>>>>>> hw.cam.nda.nvd_compat=3D1 >>>>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd >>>>>>>>>>> was? Or does >>>>>>>>>>> it work? >>>>>>>>>>> >>>>>>>>>>> Something weird is going on in the interrupt assignment, I >>>>>>>>>>> think, but I >>>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>>>>>> >>>>>>>>>>> Warner >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead >>>>>>>>>> of hw.cam.nda.nvd_compat? >>>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>>>>>> >>>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I stil= l >>>>>>>>>> see >>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>> and now also >>>>>>>>>> Root mount waiting for: CAM >>>>>>>>>> messages besides those >>>>>>>>>> >>>>>>>>> >>>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by >>>>>>>>> default these >>>>>>>>> days. >>>>>>>>> >>>>>>>>> I'll take a look on monday starting at the differences in >>>>>>>>> interrupt assignment that >>>>>>>>> are apparent when you cold boot vs reboot. >>>>>>>>> >>>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >>>>>>>>> didn't really >>>>>>>>> expect it to be. >>>>>>>>> >>>>>>>>> Warner >>>>>>>>> >>>>>>>>> >>>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>>>>>> worse now. >>>>>>>> So clean poweron works as before. >>>>>>>> But if rebooted nvme drive refuses to work, while before the code >>>>>>>> upgrade it was just complaining about missing interrupts. >>>>>>>> >>>>>>>> currently dmesg show this: >>>>>>>> nvme0: mem >>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff = at device >>>>>>>> 0.0 on pci6 >>>>>>>> nvd0: NVMe namespace >>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>> nvme0: mem >>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff = at device >>>>>>>> 0.0 on pci6 >>>>>>>> >>>>>>> >>>>>>> Why is this showing up twice? Or is everything above this line left >>>>>>> over from the first, working boot? >>>>>>> >>>>>>> >>>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>>> nvme0: RECOVERY_WAITING >>>>>>>> nvme0: resetting controller >>>>>>>> nvme0: aborting outstanding admin command >>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>>> cdw11:00000000 >>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>>> nvme0: nvme_identify_controller failed! >>>>>>>> nvme0: waiting >>>>>>>> >>>>>>> >>>>>>> Clearly something bad is going on with the drive here... We looked >>>>>>> into the completion queues when we didn't get an interrupt and ther= e was >>>>>>> nothing complete there.... >>>>>>> >>>>>>> The only thing I can think of is that this means there's a phase >>>>>>> error between the drive and the system. I recently removed a second= reset >>>>>>> and made it an option NVME_2X_RESET. Can you see if adding >>>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? >>>>>>> >>>>>>> Warner >>>>>>> >>>>>>> >>>>>>>> nvme0: mem >>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff = at device >>>>>>>> 0.0 on pci6 >>>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>>> nvme0: RECOVERY_WAITING >>>>>>>> nvme0: resetting controller >>>>>>>> nvme0: aborting outstanding admin command >>>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>>> cdw11:00000000 >>>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>>> nvme0: nvme_identify_controller failed! >>>>>>>> nvme0: waiting >>>>>>>> >>>>>>>> >>>>>> >>>>>> Sorry, it's showing twice due to multiple reboots. For one boot it's >>>>>> like: >>>>>> nvme0: mem >>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at= device >>>>>> 0.0 on pci6 >>>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >>>>>> nvme0: timeout with nothing complete, resetting >>>>>> nvme0: Resetting controller due to a timeout. >>>>>> nvme0: RECOVERY_WAITING >>>>>> nvme0: resetting controller >>>>>> nvme0: aborting outstanding admin command >>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>> cdw11:00000000 >>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>> nvme0: nvme_identify_controller failed! >>>>>> nvme0: waiting >>>>>> >>>>>> Well, neither Windows not Linux have any problems with the device. I >>>>>> understand they may be hiding it or workaround somehow. >>>>>> >>>>> >>>>> Yea, I'm trying to figure out why your machine is different than mine= , >>>>> and what Windows or Linux do that is different. It may be dodgy hardw= are, >>>>> but others have no trouble... >>>>> >>>>> I'll try setting NVME_2X_RESET in the kernel config and report back i= n >>>>>> a while. >>>>>> >>>>> >>>>> Thanks. If it helps, that tells me something. If it doesn't, that >>>>> tells me something else. >>>>> >>>>> I suspect that it is somewhere else in the system, tbh, but I need to >>>>> find it systematically. >>>>> >>>>> Warner >>>>> >>>> >>>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't change= d >>>> anything. I. e it didn't help. >>>> >>> >>> While it would have been nice to have this be the fix, I'm not that >>> surprised either. >>> It was the biggest change of late, apart from the big re-arrangement >>> that I'd done. >>> >>> So the other changes have moved from the occasional missing interrupt >>> message >>> (which the old code would get when a command wasn't completed in the >>> timeout >>> period, but that we found to be done when we scanned the completion >>> queue. Now >>> the device is detected fine (as before), but then doesn't do I/O at all >>> (including not >>> completing the identify command!) and is worse. This is unexpected and >>> I'm trying >>> understand what happens on reboot that 'changes'the working state and >>> why the >>> new code behaves so differently. >>> >>> Warner >>> >> > > Sure, here it is: > Thanks. Good news / bad news based on this... > Controller Capabilities/Features > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D > Vendor ID: 1c5c > Subsystem Vendor ID: 1c5c > Serial Number: ND03N46381010423H > Model Number: PC611 NVMe SK hynix 512GB > OK. I have a PC511 256GB that I've been trying to get rotated into my test harness... I'll make it next up tomorrow based on this... With luck, it will have the same problem as yours. It was in a batch of drives I got to try to sort out reported problems... (unluck of the draw that it was pushed to the back of the list....) > Firmware Version: 11000111 > Recommended Arb Burst: 4 > IEEE OUI Identifier: 2e e4 ac > Multi-Path I/O Capabilities: Not Supported > Max Data Transfer Size: 262144 bytes > Sanitize Crypto Erase: Not Supported > Sanitize Block Erase: Supported > Sanitize Overwrite: Not Supported > Sanitize NDI: Not Supported > Sanitize NODMMAS: Undefined > Controller ID: 0x0001 > Version: 1.3.0 > > Admin Command Set Attributes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D > Security Send/Receive: Supported > Format NVM: Supported > Firmware Activate/Download: Supported > Namespace Management: Not Supported > Device Self-test: Supported > Directives: Not Supported > NVMe-MI Send/Receive: Not Supported > Virtualization Management: Not Supported > Doorbell Buffer Config: Not Supported > Get LBA Status: Not Supported > Hmmm, I was hoping it was related to Doorbell Buffer Config. > Sanitize: block, > Abort Command Limit: 4 > Async Event Request Limit: 8 > Number of Firmware Slots: 3 > Firmware Slot 1 Read-Only: No > Per-Namespace SMART Log: No > Error Log Page Entries: 256 > Number of Power States: 5 > Total NVM Capacity: 0 bytes > Unallocated NVM Capacity: 0 bytes > Firmware Update Granularity: 00 (Not Reported) > Host Buffer Preferred Size: 0 bytes > Host Buffer Minimum Size: 0 bytes > > NVM Command Set Attributes > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D > Submission Queue Entry Size > Max: 64 > Min: 64 > Completion Queue Entry Size > Max: 16 > Min: 16 > Number of Namespaces: 1 > These are all typical / normal as well... > Compare Command: Supported > Write Uncorrectable Command: Supported > Dataset Management Command: Supported > Write Zeroes Command: Supported > Save Features: Supported > Reservations: Not Supported > Timestamp feature: Supported > Verify feature: Not Supported > Fused Operation Support: Not Supported > Format NVM Attributes: Per-NS Erase, Per-NS Format > Volatile Write Cache: Present > Also typical, except write uncorrectable (which we don't use). Warner > NVM Subsystem Name: > > > --000000000000fbda0c05ce32f93e-- From nobody Wed Oct 13 06:16:47 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 8392717F4137 for ; Wed, 13 Oct 2021 06:17:04 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTj402fYjz3FHF; Wed, 13 Oct 2021 06:17:04 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 0CCAF10A32EF; Wed, 13 Oct 2021 08:16:56 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 2F33110B4FAD; Wed, 13 Oct 2021 08:16:54 +0200 (CEST) Received: from freyja (p5de887d0.dip0.t-ipconnect.de [93.232.135.208]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id E31EA10A75E3; Wed, 13 Oct 2021 08:16:53 +0200 (CEST) Date: Wed, 13 Oct 2021 08:16:47 +0200 From: FreeBSD User To: Brooks Davis Cc: FreeBSD CURRENT Subject: Re: git: "overlay" of own remote-branch on official freebsd-ports repo Message-ID: <20211013081647.5e1d857e@freyja> In-Reply-To: <20211012180156.GA90843@spindle.one-eyed-alien.net> References: <20211012173148.1d2f138c@hermann.fritz.box> <20211012180156.GA90843@spindle.one-eyed-alien.net> 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-Transfer-Encoding: 7bit X-Rspamd-UID: 355b4c X-Rspamd-UID: 98742e X-Rspamd-Queue-Id: 4HTj402fYjz3FHF 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 Tue, 12 Oct 2021 18:01:56 +0000 Brooks Davis wrote: > On Tue, Oct 12, 2021 at 05:31:48PM +0200, FreeBSD User wrote: > > I'd like to ask how FreeBSD developers and maintainers do the trick. If > > there is an official cookbook fpr maintainers (I haven't found it yet ...), > > please be so kind and refer to it. Any advice is welcome. > > If you only want to add extra ports, I'd recommend maintaining a > separate repo for use with the ports collection's under-documented > overlay feature. This avoids the need to rebase or merge your trees. > > You create the overlay in poudriere with something like: > > poudriere ports -c -p cheri-ports-overlay -U > https://github.com/CTSRD-CHERI/cheri-ports-overlay.git -m git -B main > > You then use it by adding -O cheri-ports-overlay to your other poudriere > commands like poudriere bulk. > > Note that you may need to install poudriere-devel or install it by hand > to get this feature. > > -- Brooks Hello, that sounds very good and usefull. Thank you very much Kind regards, Oliver From nobody Wed Oct 13 06:18:32 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 6213D17F4A22 for ; Wed, 13 Oct 2021 06:18:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [85.220.129.30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HTj5t1Z38z3G12 for ; Wed, 13 Oct 2021 06:18:42 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id 694621067555; Wed, 13 Oct 2021 08:18:35 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id CABBE10A75DF; Wed, 13 Oct 2021 08:18:33 +0200 (CEST) Received: from freyja (p5de887d0.dip0.t-ipconnect.de [93.232.135.208]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 8414D10A75DE; Wed, 13 Oct 2021 08:18:33 +0200 (CEST) Date: Wed, 13 Oct 2021 08:18:32 +0200 From: FreeBSD User To: Warner Losh Cc: FreeBSD CURRENT Subject: Re: git: "overlay" of own remote-branch on official freebsd-ports repo Message-ID: <20211013081832.299a1b06@freyja> In-Reply-To: References: <20211012173148.1d2f138c@hermann.fritz.box> 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-Transfer-Encoding: 7bit X-Rspamd-UID: ac2750 X-Rspamd-UID: d19752 X-Rspamd-Queue-Id: 4HTj5t1Z38z3G12 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 Tue, 12 Oct 2021 10:01:00 -0600 Warner Losh wrote: > On Tue, Oct 12, 2021 at 9:32 AM FreeBSD User wrote: > > > I do not know whether I'm right in this list, but since the subject is > > mutual so common > > in development and GIT, I have the strong feeling I'm right here. > > > > Im quite new to git, so apologizes for any inconvenience reading my > > question. > > > > Using poudriere on 14-CURRENT to create a selection of packages also > > includes updating > > the ports tree on a regular basis. I maintain some "special" ports not > > official part of > > the FreeBSD ports tree and some other ports are part of those I'm supposed > > to maintain. I > > keep personally track of the changes in a git repo of my own. > > > > Now I'd like to "overlay" the official portas repo by that of mine to > > include changes. > > With SVN, there was no problem to have local changes not overwritten by > > regular updates > > of the ports tree as long as the specific port in question wasn't updated > > by the official > > site. In git, this behaviour seems to have changed, any changes I made so > > far are gone > > after poudriere is adviced to update the tree. > > > > I'd like to ask how FreeBSD developers and maintainers do the trick. If > > there is an > > official cookbook fpr maintainers (I haven't found it yet ...), please be > > so kind and > > refer to it. Any advice is welcome. > > > > tl;dr: branches are cheap and well supported in git. You just make a branch > for your > local changes, and update that however you see fit. > > For ports I have like that, I've just created a branch in git. I rebase the > branch forward > each time I update. For me, though, the branch is mostly uncommitted in > upstream > changes that may not be ready for some reason... There's two ways to do > this. > You can just merge, which is OK if you aren't upstreaming the changes, or > you can > rebase if the changes or a subset of the changes likely will end up in > FreeBSD. > > Others might recommend stash, but I find it too unwieldy for more than a > couple > of things. > > So the workflow would be: > > git clone -o freebsd freebsd-ports > cd freebsd-ports > git checkout -b hartmann-specials > > > Now, you can use poudriere-ports with the -B hartmann-specials and your > local repo as the source of truth. > > to update > > cd freebsd-ports > git checkout main > git pull --rebase # or --ff-only, I use > --rebase because I push and it's habit > git rebase -i main hartmann-specials > > Note: if you need to have multiple trees with this branch you are modifying, > then a git pull --rebase will let you cope with the forced-pushes this > method > would require. You can also do it with git merge on hartmann-specials if you > don't need to keep the changes separate or you have a lot of downstreams > that would get cranky, which doesn't sound like the case here. > > Warner As I wrote, I'm quite new to git and always surprised. Thanks for the help and the neat tip. I'll try. Kind regards and thanks, Oliver From nobody Wed Oct 13 14:46:29 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 17B251805717 for ; Wed, 13 Oct 2021 14:46:34 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: from mail-qt1-x82c.google.com (mail-qt1-x82c.google.com [IPv6:2607:f8b0:4864:20::82c]) (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 4HTwMs6phFz3syy for ; Wed, 13 Oct 2021 14:46:33 +0000 (UTC) (envelope-from markjdb@gmail.com) Received: by mail-qt1-x82c.google.com with SMTP id z24so2712089qtv.9 for ; Wed, 13 Oct 2021 07:46:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to; bh=Ny6CwDbROpuZPpBCPMdEZQKH7OHfqwBYFlmIiv1forE=; b=mVJye9+R+qUKRNdwyWiiTrsjbXlYaeLMqre4OrPMfcz8kzwmv37R6Dj+EccM/bJQQ+ JqosYp/igeMZMyzFB9U/0Ea8RH+1dqJcP+8u0mF0jqoh35vBo0dMJkAkL36PB9nHmRCw A9JIIosgOGUp/pLFhYzNbSLmvrIIquxXo8dSCpIJWD6F50O/HDGC3KWV6ji4doS4ibL3 iWQDKDFQP1wT77gYbOd+NmeVcaCUM/h2QogotlCnPzdjIK8Vy+XYNIRjr2HiPfdfRKCL jaZSeyNvh1NBXFFdMr5Ad/17imor/8MTv1MQxA1bfaCCQ9v0fHuoTINjsvcg2qD36eoH P8jA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to; bh=Ny6CwDbROpuZPpBCPMdEZQKH7OHfqwBYFlmIiv1forE=; b=qz9doORnYlwcBiKDe1na2AWPzVsNWg7878LaMR8ncV80FZ/2Q0snSZRfQCA4ZNQb9t RLLQSDCh3oU6fEmejBhuo+6i52PuSsCczJvVECYd+3WnFrvmuTP5i7IpZfKGAtxAOV8k C0d4Pgrh6Q6fRUA/Ucs4P8wzETwNgZaY09DA+1KUJ5ifbluPFRx19V4qXk2WQngvtlSy xeckWhqm1F3DLJICdEBWcSesJzVEY+TV8yUeML0Oj8BBe5CXFd39xaX4z9tyG8qTXsIS 1MpeRvx3xE2DElnZSuoEZZwfR1qnAXldq8iWaEXALJvCEGttcL7ARDJg4ZY/ySbq/5Oc T/eQ== X-Gm-Message-State: AOAM5319Xn9/l15HA0bMrudTTogY57QMR6lMcvE5CRTYhlB5J1Rx6Y5S ZgG5R2aMKchU+xThIgbh7Bk= X-Google-Smtp-Source: ABdhPJwtw1iercHpBwIQvbuGOjd0EP7w3DNgw3SbuN+DKRE17zCn0ol2QH7vZcRGFvjiaP9XgDCLbQ== X-Received: by 2002:ac8:7319:: with SMTP id x25mr29920982qto.147.1634136393383; Wed, 13 Oct 2021 07:46:33 -0700 (PDT) Received: from nuc ([142.126.186.191]) by smtp.gmail.com with ESMTPSA id t11sm6039660qkm.92.2021.10.13.07.46.31 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 13 Oct 2021 07:46:31 -0700 (PDT) Date: Wed, 13 Oct 2021 10:46:29 -0400 From: Mark Johnston To: Peter Eriksson Cc: freebsd-current Subject: Re: Panic in pipe_write from syslogd in 12.2? Message-ID: References: <0FFAABE0-F260-4FE0-8B1D-1F179C502170@lysator.liu.se> 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=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <0FFAABE0-F260-4FE0-8B1D-1F179C502170@lysator.liu.se> X-Rspamd-Queue-Id: 4HTwMs6phFz3syy 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 Tue, Oct 12, 2021 at 08:39:55PM +0200, Peter Eriksson wrote: > I just noticed that a couple of my 12.2-RELEASE-p4 running servers have… 8263, 14474 and 3831 defunct subprocesses from syslogd and also seems to have stopped writing to the log files… When I tried to kill syslogd on a fourth server (with some X000 defunct processes) the machine panic’ed and rebooted. > > I seem to have a vague memory of this being a known bug/someone saw something similar or perhaps even solved in later patch releases? But my google-fu seems to be failing me today. Anyone else remember? I don't believe we've released a patch that would fix this. The unix domain socket code has been refactored a fair bit with respect to locking since 12.2, and I believe this panic will be fixed in 12.3. In particular, I've seen one other report of a similar panic that went away after https://cgit.freebsd.org/src/commit/?id=ccdadf1a9bb64156e4a62bb6207c37b841467cb7 . > (The one that panic’ed is now running -p10 instead which they should have done a long time ago but…) > > > I reported it on the FreeBSD bugzilla: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=259084 > > > Output from one that still is running: > # egrep syslogd /var/log/sys/15:10/procstat-kk-a.log > 9212 101640 syslogd - mi_switch+0xd4 sleepq_catch_signals+0x403 sleepq_wait_sig+0xf _sleep+0x1de pipe_write+0x583 dofilewrite+0xb0 sys_write+0xc0 amd64_syscall+0x387 fast_syscall_common+0xf8 > > Output from the one that panic’ed: > Fatal trap 12: page fault while in kernel mode > cpuid = 20; apic id = 14 > fault virtual address = 0x410 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff80b9f55c > stack pointer = 0x28:0xfffffe14debc6710 > frame pointer = 0x28:0xfffffe14debc6790 > code segment = base r x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 9277 (sshd) > trap number = 12 > panic: page fault > cpuid = 20 > time = 1633990484 > KDB: stack backtrace: > #0 0xffffffff80c0ad75 at kdb_backtrace+0x65 > #1 0xffffffff80bbf02b at vpanic+0x17b > #2 0xffffffff80bbeea3 at panic+0x43 > #3 0xffffffff8108e911 at trap_fatal+0x391 > #4 0xffffffff8108e96f at trap_pfault+0x4f > #5 0xffffffff8108dfb6 at trap+0x286 > #6 0xffffffff81066c28 at calltrap+0x8 > #7 0xffffffff80c6365f at unp_pcb_owned_lock2_slowpath+0x12f > #8 0xffffffff80c61e0f at uipc_send+0x139f > #9 0xffffffff80c55b7a at sosend_generic+0x4ca > #10 0xffffffff80c55f90 at sosend+0x50 > #11 0xffffffff80c5cc55 at kern_sendit+0x225 > #12 0xffffffff80c5cfcc at sendit+0x19c > #13 0xffffffff80c5ce1d at sys_sendto+0x4d > #14 0xffffffff8108f4c7 at amd64_syscall+0x387 > #15 0xffffffff8106754e at fast_syscall_common+0xf8 > Uptime: 212d21h35m47s > > - Peter > From nobody Wed Oct 13 19:16:57 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 BC3C1180FA82 for ; Wed, 13 Oct 2021 19:17:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HV2Mx4dBcz4nK6; Wed, 13 Oct 2021 19:17:01 +0000 (UTC) (envelope-from se@freebsd.org) Received: from [IPV6:2003:cd:5f26:fa00:d066:1f81:2b65:dd01] (p200300cd5f26fa00d0661f812b65dd01.dip0.t-ipconnect.de [IPv6:2003:cd:5f26:fa00:d066:1f81:2b65:dd01]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id F14B02A121; Wed, 13 Oct 2021 19:17:00 +0000 (UTC) (envelope-from se@freebsd.org) Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> Date: Wed, 13 Oct 2021 21:16:57 +0200 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 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd Content-Language: en-US To: Alan Somers , Rick Macklem Cc: FreeBSD Current References: From: Stefan Esser In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="------------rAniKDyxOGZkJfpaCq0OESz0" X-ThisMailContainsUnwantedMimeParts: N This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --------------rAniKDyxOGZkJfpaCq0OESz0 Content-Type: multipart/mixed; boundary="------------EEdhK1bOA4Das8gBMjlZTkpN"; protected-headers="v1" From: Stefan Esser To: Alan Somers , Rick Macklem Cc: FreeBSD Current Message-ID: <540e31f1-1403-073c-201d-a4495c0a8226@freebsd.org> Subject: Re: RFC: Use of VOP_ALLOCATE() by NFSV4.2 nfsd References: In-Reply-To: --------------EEdhK1bOA4Das8gBMjlZTkpN Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Am 10.10.21 um 05:52 schrieb Alan Somers: > On Sat, Oct 9, 2021 at 7:13 PM Rick Macklem wrot= e>> This leads me to a couple of questions: >> - Is there a good reason for not using vop_stdallocate() for ZFS? >=20 > Yes. posix_fallocate is supposed to guarantee that subsequent writes > to the file will not fail with ENOSPC. But ZFS, being a copy-on-write > file system, cannot possibly guarantee that. See SVN r325320. This is not entirely true: ZFS supports reservations and it could thus support the pre-allocation of space that is later "filled". This reservations would be substracted from the free space sum, and it would be guaranteed that this free space is available for the file for which the pre-allocation has been requested. This would require that the allocate() call recorded the block range for which an allocation is requested (and for which no disk blocks are currently allocated) without assignment of any backing blocks at that time. Later writes to that range would allocate disk blocks and at the same time reduce the amount that is reserved and remove that range (that is now allocated) from the recorded pre-allocation range. This would of course require the addition of block ranges that are reserved but not yet backed by disk blocks to the znode, and of the total count of blocks reserved for this purpose in addition to other types of reservations in a separate variable. >> - Should I try and support both file system types via vop_stdallocate(= ) >> or not support Allocate at all? >=20 > Since you can't possibly support it for ZFS (not to mention other file > systems like fusefs) you'll have to not support it at all. While I do think that an allocate() operation could be implemented in ZFS, it is obvious that this does not apply to all possible fusefs filesystems (which do not even need to support the concept of an allocation of blocks or ranges). Regards, STefan --------------EEdhK1bOA4Das8gBMjlZTkpN-- --------------rAniKDyxOGZkJfpaCq0OESz0 Content-Type: application/pgp-signature; name="OpenPGP_signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="OpenPGP_signature" -----BEGIN PGP SIGNATURE----- wsB5BAABCAAjFiEEo3HqZZwL7MgrcVMTR+u171r99UQFAmFnMKkFAwAAAAAACgkQR+u171r99UTX uggAoaiHzUyFTltPYsFAUFoNXWblniMk8WAHwOQ9gDGDIuwIJ04UR+F3n0HXDE23S7T4PBLl6qxB z9NVrAgcr1/kAypCtltWgtJwrHymlME/JdwjiBz7hp2yZoGGHfikrPa4LklcRsPjQEL/4cVBg//d JDElHDXbH1NgAN+kZbtF5a1zBkn4gxaQAInt/ixi7uJ5YM2wx/TUVntb9fIg7O2ujpnjzzr9cJcb gLvaT/Nl9XnjMvOBIn93lvDPaJlcbl8zySPj2jSVZGZUX6dIj5jz2WmGhLg89IMfFU9BFC6DwFBd eFDBRZCew5k+QsjB03SHG2m18TmQFPrmVqPsA/AwAQ== =cXQE -----END PGP SIGNATURE----- --------------rAniKDyxOGZkJfpaCq0OESz0-- From nobody Fri Oct 15 07:52:33 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 B602F181062E for ; Fri, 15 Oct 2021 07:52:36 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp5.goneo.de (smtp5.goneo.de [IPv6:2001:1640:5::8:30]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HVz5H6gJNz3sV6 for ; Fri, 15 Oct 2021 07:52:35 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp5.goneo.de (Postfix) with ESMTPS id AD5CE10B4FA8 for ; Fri, 15 Oct 2021 09:52:34 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id 8D878104D4B2 for ; Fri, 15 Oct 2021 09:52:34 +0200 (CEST) Received: from hermann.fritz.box (dynamic-2a01-0c22-a4c2-fd00-1101-a44e-b71e-b327.c22.pool.telefonica.de [IPv6:2a01:c22:a4c2:fd00:1101:a44e:b71e:b327]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 5E6D5105C667 for ; Fri, 15 Oct 2021 09:52:34 +0200 (CEST) Date: Fri, 15 Oct 2021 09:52:33 +0200 From: FreeBSD User To: FreeBSD CURRENT Subject: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call Message-ID: <20211015095233.19c841d0@hermann.fritz.box> 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-Transfer-Encoding: 7bit X-Rspamd-UID: 05943a X-Rspamd-UID: 57e218 X-Rspamd-Queue-Id: 4HVz5H6gJNz3sV6 X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of freebsd@walstatt-de.de has no SPF policy when checking 2001:1640:5::8:30) smtp.mailfrom=freebsd@walstatt-de.de X-Spamd-Result: default: False [1.17 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt-de.de]; AUTH_NA(1.00)[]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[4]; TO_DN_ALL(0.00)[]; NEURAL_SPAM_MEDIUM(0.37)[0.369]; NEURAL_SPAM_LONG(1.00)[1.000]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:25394, ipnet:2001:1640::/32, country:DE]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[2001:1640:5::8:30:from] X-ThisMailContainsUnwantedMimeParts: N After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also updating port graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following message: [~] firefox Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system callgraphics/libdrm. info on packages installed: [~] pkg info -x drm drm-fbsd13-kmod-5.4.144.g20211013 drm-kmod-g20190710_1 libdrm-2.4.107_1,1 linux-c7-libdrm-2.4.97 It doesn't matter whether to update the ports (including firefox) from a regular FreeBSD ports repo or, in my case, compiling special kernel related kmod port like drm-fbsd13-kmod manually on each kernel build. The ports package of graphics/drm-fbsd13-kmod seems to be behind the version of drm-fbsd13-kmod-5.4.144.g20211013 when updating from regular package host, but it doesn't matter, the result then is the same: Bad system call on Firefox. So FreeBSD 13-STABLE seems to be the culprit. What happened? I saw the Linux KPI changed again, so might this trigger this? Kind regards, O. Hartmann From nobody Fri Oct 15 20:20:55 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 9FF7C18000CB for ; Fri, 15 Oct 2021 20:20:58 +0000 (UTC) (envelope-from jbeich@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWHhp46SJz4Ttl; Fri, 15 Oct 2021 20:20:58 +0000 (UTC) (envelope-from jbeich@freebsd.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1634329258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MNb1dq1rRwgqmTei7LUGvG5nswWJqkM4jvfhyxDSxlY=; b=kaB4ocamkhB7dmKVPC4Q6mIXva8G3igk9GkfxDMkS/wzFVG0OGmrmonFPPp+BhaPwR3CWM byu5VQ5MFDjsFxADqxHc65UO5Vi+DSXmAOVYeMamYAM2XonKuB7J07uIzQVk3KDrlSqj/z XJX2TMHgtX6M1+r8XJ0E0lcjfbGstM9YfJBx2lVdJrOC9Gkf8nInpTM5VxZWpSf4C904IZ RpY/MMRRm/auwwK8OTOd/SXpziMQV8IjnChqTtDLBgmq9HXJh6RWmL/Jkm44VeFS82K3xG O8qpbqQKDRaBv2eUsZCjCdhMxPMG/oC3a4hASQhz7jBeqIB2Mx+ncBFazhP65A== Received: by freefall.freebsd.org (Postfix, from userid 1354) id 7C36C3090; Fri, 15 Oct 2021 20:20:58 +0000 (UTC) From: Jan Beich To: FreeBSD User Cc: FreeBSD CURRENT Subject: Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call References: <20211015095233.19c841d0@hermann.fritz.box> Date: Fri, 15 Oct 2021 22:20:55 +0200 In-Reply-To: <20211015095233.19c841d0@hermann.fritz.box> (FreeBSD User's message of "Fri, 15 Oct 2021 09:52:33 +0200") Message-ID: <35p2-jazc-wny@FreeBSD.org> 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 ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1634329258; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=MNb1dq1rRwgqmTei7LUGvG5nswWJqkM4jvfhyxDSxlY=; b=dk3mRBJws68pkPmWdAviZdwm3Wbov+adSMnqGlhdGDpWdKpRjE3DG/krcxZuGsLvJj+fBl 6XXsvMDr5d+uJzSVAcrD2BGAH2oMgTNQZt5hn+TkNFzGhPsIH8OWuy78OfyyifW3JhFmov mXK9jmKorcwgx+RBX0BDLsTlfns5TruPBn1ywqG313CucLaZLKa1LkTTC+t2iBusZ239cq SQg6+AWdjU8w0sDZXjjuM+uBjOvszR9ALjFjzmVC6qVpauhFtN1UsP1doFanXON7Z0qPBd 00iMsWRf+WmcfjFjXkw25MIUBF3t7tIb7O8oo47BARlX2xupX4vxzOJmW8zRkQ== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1634329258; a=rsa-sha256; cv=none; b=PMHApJ/DJYNBJFwwXhhMOBjiWHRxaXQj909zpkkwXRParE7/SPd6riyHa5RkDWCqDeTfg+ +AdeiM5blvBw9gq4e9ghs+PIMLW85e/gxYBDiKdmRLAzbI6Z60hyj1nECWSiivO+GgyuGx OUSRsko6v5BW45XRhZpg1UXW8WJduONrQS8lRkWIG4ixKPUrD9m7OWS0LsJ6QF7UBH6qpo AzJGg5geE6XYPYmsHjjLrf626NYLDolUi1qrywh/CVNLM2D6MqI/NcJ1k2vlmm2PjE9HTR Xu5dZjjrszbOPwlBdGBUexBX8RG1R0UtGBZz9aRV56DJFfe4vZoYQ/YDCn7Shg== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-ThisMailContainsUnwantedMimeParts: N FreeBSD User writes: > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also updating port > graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm to > libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following message: Which revision "13-STABLE" was before the update? If you didn't change any kernel options (and bump into a pilot error) bisecting may help. > > [~] firefox > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system > callgraphics/libdrm. Run under truss(1) or ktrace(1) (enable tracing descendants) to get the syscall name or number. For example, Firefox requires CAPABILITIES for cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. [1] https://github.com/rust-lang/libc/pull/2406 From nobody Fri Oct 15 20:25:01 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 BD1DF1803548 for ; Fri, 15 Oct 2021 20:25:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from kib.kiev.ua (kib.kiev.ua [IPv6:2001:470:d5e7:1::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWHnl30gLz4X8m; Fri, 15 Oct 2021 20:25:15 +0000 (UTC) (envelope-from kostikbel@gmail.com) Received: from tom.home (kib@localhost [127.0.0.1]) by kib.kiev.ua (8.16.1/8.16.1) with ESMTPS id 19FKP1HD097826 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO); Fri, 15 Oct 2021 23:25:04 +0300 (EEST) (envelope-from kostikbel@gmail.com) DKIM-Filter: OpenDKIM Filter v2.10.3 kib.kiev.ua 19FKP1HD097826 Received: (from kostik@localhost) by tom.home (8.16.1/8.16.1/Submit) id 19FKP1mu097825; Fri, 15 Oct 2021 23:25:01 +0300 (EEST) (envelope-from kostikbel@gmail.com) X-Authentication-Warning: tom.home: kostik set sender to kostikbel@gmail.com using -f Date: Fri, 15 Oct 2021 23:25:01 +0300 From: Konstantin Belousov To: Jan Beich Cc: FreeBSD User , FreeBSD CURRENT Subject: Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call Message-ID: References: <20211015095233.19c841d0@hermann.fritz.box> <35p2-jazc-wny@FreeBSD.org> 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: <35p2-jazc-wny@FreeBSD.org> X-Spam-Status: No, score=-1.0 required=5.0 tests=ALL_TRUSTED,BAYES_00, DKIM_ADSP_CUSTOM_MED,FORGED_GMAIL_RCVD,FREEMAIL_FROM, NML_ADSP_CUSTOM_MED autolearn=no autolearn_force=no version=3.4.5 X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on tom.home X-Rspamd-Queue-Id: 4HWHnl30gLz4X8m 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 Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote: > FreeBSD User writes: > > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also updating port > > graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, graphics/libdrm to > > libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with the following message: > > Which revision "13-STABLE" was before the update? If you didn't change > any kernel options (and bump into a pilot error) bisecting may help. > > > > > [~] firefox > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system > > callgraphics/libdrm. > > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the > syscall name or number. For example, Firefox requires CAPABILITIES for > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. > > [1] https://github.com/rust-lang/libc/pull/2406 If you set kern.lognosys=3, it should be quite loud advertized which syscall was missed, ie. console + control terminal. terminal) From nobody Fri Oct 15 23:48:01 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 82916180C9F5 for ; Fri, 15 Oct 2021 23:48:12 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-TO1-obe.outbound.protection.outlook.com (mail-to1can01on0607.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5d::607]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "DigiCert Cloud Services CA-1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWNHv0Ttqz4Qt8 for ; Fri, 15 Oct 2021 23:48:11 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=aLlWxSF4aMAWfdUgoyy0YB8bEvCj5qY4st5uI92UHss+IN6rhMGlpR2bgUFv4JXhbcH3mWAtyNOUBADRb1+kCpAIkL6gvD7TpgWrlY1YTj+q0UM37O7uKN0AC+WJQqByuBV9m8Q9p3Oiw/VweTxyO4Bzvo09KpeCabhGvhu8VZ2zI/NkwtepQISPBoMb5SqNRzDrK3hjT5NJWkMiqSI3X07zmT9ltc/RPvRfJMJ+cK7/hGcIccNX4zWhN/CoZfHOOaqhsz+8qxGM37K3IU3sgZ54rfBeEJSgkAPNCs/ppRqsFwKwrAG69Q4+gXYOYrH3DD27ez3+sq/hzTobr7SZ1Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=b2G3M1m5yvxZM6TTP4kiXc3ds66LO6KO7zf7HFgYbGM=; b=hBaYjyTZih9ada/nN7TNkqp9C23z5/xcQtCYqYIUQsysFaN+IOUi61uV+TpC9U5QqZ0Sft9zTwMESRJpXHPAgwIEniC0M/f6Z+V1quAZHPLQYMUa9m8p7vL6yEO9IXw5vLxsSYdT9SyDB2AOW8ORsoi03tgx6VtSARWuyyYgt6J4ViEdUigrg8Q8Xml8eHUOlbQhfPug9FTuSPjTc4JKiT3docze0afU+NBoTXoPByTX5Md/fHdqRWu9THRr6/RMhcnVdnedsAIjLJBMo9YBj9cC8+1qoQb+DHDd6IWrwcRMmuwmSs6waC1OC9WEj6TiEHGj1k5OnteO1ZwfJQW0Uw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=b2G3M1m5yvxZM6TTP4kiXc3ds66LO6KO7zf7HFgYbGM=; b=e8jGmFRngvcf9B0x4xI75gEegiKMEqpprETE+oAX3rdwcrDGKglOYJAZ32DKxiLZEiW/KsAYiglHCJF87xYxKv1B83Eye6OT086TqadRZqTucu12NOOO3hY9cxpM344/OHMDGYqQat/JxxagKfIOspUCjMC0bDzowk1qOJrfSpyGseUfTyYZuGHC+URv9NYu5zynv+OnIe8oHI6oJfftIDiQA349yk8t6owOI1o34DGKDggjC1kIP9SxCrhz4R5K0wASYSu/fYxeDDhHgk5n2RWJqKyetiTO49qGef9bLlU6rWhTPlWm+KVgx/f7rpBRDkpJf/1xmMIG3hzYAcJjLQ== Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:19::29) by QB1PR01MB3121.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:3f::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4608.17; Fri, 15 Oct 2021 23:48:01 +0000 Received: from YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12]) by YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM ([fe80::7091:13ac:171f:1c12%5]) with mapi id 15.20.4608.017; Fri, 15 Oct 2021 23:48:01 +0000 From: Rick Macklem To: FreeBSD Current Subject: How do I find out what changed for an freebsd release update? Thread-Topic: How do I find out what changed for an freebsd release update? Thread-Index: AQHXwh6/bt4wOvrQ60CoFu3T8MW4pw== Date: Fri, 15 Oct 2021 23:48:01 +0000 Message-ID: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: suggested_attachment_session_id: b89b41f2-3adf-e706-64fa-d446cb535300 x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 77d9332e-d7d9-45ec-efb0-08d99036397b x-ms-traffictypediagnostic: QB1PR01MB3121: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:8882; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: DE6IeuJHob7yuQbfrCY+nLOp8tXzAZSSG3IAVXsKyThVBTU52nOHEu6zxrbxkxp2a15/4B0L551NQlTbnRliGcLyKWlieeSDK6/JDCBHNLoDdztFR7FXmbPyYaBKjKezSJtfSc2O5kGkdlk6SBjVCpjGWZQqfMpfa7llBeHrxhxkH6sMGcXsbcwvgEU8R9Vcfmb01Lf1L0RX3sdt0E+4BHfQ9k4JCQmRqRptTxjxgxDL3+a60yzmRykfXcTs1H8WQZnwfUhN+ItRp2FsUtdu4iVBg6jdhJFbzacgySQMJfZDSuNavFNowHyVqgDJfmQ1S9Qxu6JWoj1HBuW1mOgO3awJfJJIg+c8E+sym/wMsF4+xA2t7CtwxlGLy5zADBX0PAnVeKWPv5yXmJSmvdduSw8CC/ZQ/5lIlRs80Z6NW1edRuBbhrZpSXgVBidJzfJ7YhzfjdPEOIooRHS0yyvyp4C40ER6AWXIFfgefR+0+Cbzkvv1XmWrUNeSlMwNirroHGUuzw/Gho7XrXKUGLYXeqL9oOuNlLlG2OueSQnZQL7xxq9uICKwtkGqlg2IgxEKK20/q42DQPJ/2EOoeJWbb8xb0vCjnMavk4dmuXCvmlkdO0wD/rZytNgBy7OoQ5i2x4DKW6DUS1T8fEe7SurjmBt8Sm5RKdKl4GAkr878vxuxtHmvpZJQktd7B6zbFlA3mBWsv4xhs+i2K2UkuKHraKQRK508wc9fqzJbtc4/jMU= x-forefront-antispam-report: CIP:255.255.255.255;CTRY:;LANG:en;SCL:1;SRV:;IPV:NLI;SFV:NSPM;H:YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM;PTR:;CAT:NONE;SFS:(366004)(55016002)(7696005)(83380400001)(8936002)(52536014)(33656002)(122000001)(9686003)(8676002)(38070700005)(15650500001)(38100700002)(6506007)(186003)(64756008)(71200400001)(76116006)(66556008)(66946007)(2906002)(66446008)(6916009)(5660300002)(66476007)(86362001)(316002)(508600001)(558084003)(91956017)(786003)(20533002);DIR:OUT;SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?RJ/chEIztAVXIn/8mgp9LD57sLJtXf7eoAQWrcOaRZkxxfwjyWU7f8WhXM?= =?iso-8859-1?Q?6KQXjNerX8diX/E/JaJNOeLlTP5WFEurdog0sRohOcma86+ju0ROQDhsSh?= =?iso-8859-1?Q?lgpSG3WXvfjweY/UPHDH/K4NxJSkw495s5bNtOv1IyWuK2qdV67+vAYglL?= =?iso-8859-1?Q?+Jlh6y8g9VpXsPzK2EnJ1f86JCw/Zo/ELnhiLgyIPJP/rv0dAf3gzgu7G7?= =?iso-8859-1?Q?2DP9KwAzLxSItujN/ZuzFBKcZq4YRSNS1nVgWzuPLtJ8kHtrs2UECqnl9V?= =?iso-8859-1?Q?AhFCf/sLrbAebJaRQIHBUPaAEyBM5cjRZCAJoi8EYG/MnNjEXUNLg9jHP5?= =?iso-8859-1?Q?PesrSaM+SRj2ClE9HXXyNJ6k0oRuQ8uEZidWHW/eMHJtIzVU9GJ3JIYdUz?= =?iso-8859-1?Q?SkLZ4Ql7RrVFT6Xz2KaHE1JdHzKKfvb2TXR5eH0C2riyBE+ZzF17Cu1NCh?= =?iso-8859-1?Q?mZZ2q18J6xvqbuGXAeJhoquCxW+YkfC2NJeVK3UzT1fdASjVoJy0q73RqO?= =?iso-8859-1?Q?2IY4pVUoCq8pJDuHceIz6p/z44YfgIq2LDTNNc9jF4UvthtE7RYwuLnnoB?= =?iso-8859-1?Q?UjG1GP1cf6pw0CZ7WrSQfosdlcnPYWzXgIlDCFP79xUWBRv78aMUvroQLX?= =?iso-8859-1?Q?DFdSgfjjIb2tOzbzfh0UVx9Vmd2TLU91Zq7HMb1LE9U0B3K+z0FHevEUNk?= =?iso-8859-1?Q?2E4+RGrqscXyGHJdXOgolaxwhpSyGlp999W70ubMInKW0LP0n56c9iw4up?= =?iso-8859-1?Q?ESKtQOWlC8GpZfS47OfauEISpj1lY3FeCPJo/WDatzYUSIPfaUFC2bmnbu?= =?iso-8859-1?Q?MS532NolPWkmYmIk5vDbpByHgdZ1Q0jlMMWLqsdrvseS5V+GHPb4j7Hm5g?= =?iso-8859-1?Q?jxCRmLuP2Ct7RGLSVXmu58sKRwYsdN5gRB8roa1MWLac3YMNR8aQalagd7?= =?iso-8859-1?Q?vttDp5DPn3CNWTGQiG+MU/zxZE20AM+6/mguExktLDwv17iqGf9DeyFsdn?= =?iso-8859-1?Q?fonkgyz896VVN4cf68ZwK00y2ophyBfOULbGyjqIcImwSmLyqnYnms2SDT?= =?iso-8859-1?Q?IqVNGdbVhOCN5dBX7XfDOApPRG5uNrvZCqxtUzWriRF3bIyAyOT2Pej/UQ?= =?iso-8859-1?Q?GI7D5/QyTvtlEKzTy1aNHijACUie9KBq/8tmLS6jI4mM5vo/sYQ1jLGX5B?= =?iso-8859-1?Q?XAc7ujlZpgzUlKaFtJiFp1gKHMSNdOl1ZARdY3w0uulGbBXQ0r4U5gCAPm?= =?iso-8859-1?Q?z3Zr3BQMtvmGFUuN+cGsrs8IuGC50gBuON9+jipVRR+Wg2u1e8MwpTbq8N?= =?iso-8859-1?Q?xX+TwlcM7si25iIzTGVbB0aeCWl8zCYhDOsAZs3+iYL1ZZtOe/XmQQ8YfU?= =?iso-8859-1?Q?GaVrn+F9EPTLfbn02CPyGQD9v9DQ+RXZUf7MSMhTnDZ6kO79iYirDXNlkx?= =?iso-8859-1?Q?mX+iaCXiLbdCYlo5?= x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable 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 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: YQXPR0101MB0968.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 77d9332e-d7d9-45ec-efb0-08d99036397b X-MS-Exchange-CrossTenant-originalarrivaltime: 15 Oct 2021 23:48:01.6083 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: SXNQS4qOtIZEH2D48h9ITCdfW6Mr32RScGy7+wuzwNGHVdxdIhCxPBtCKNwOjfvmn92knb9QHw+U6e+HRt9gpA== X-MS-Exchange-Transport-CrossTenantHeadersStamped: QB1PR01MB3121 X-Rspamd-Queue-Id: 4HWNHv0Ttqz4Qt8 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector2 header.b=e8jGmFRn; arc=pass ("microsoft.com:s=arcselector9901:i=1"); dmarc=pass (policy=none) header.from=uoguelph.ca; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5d::607 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-3.00 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector2]; FREEFALL_USER(0.00)[rmacklem]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; MIME_GOOD(-0.10)[text/plain]; NEURAL_SPAM_SHORT(1.00)[1.000]; NEURAL_HAM_LONG(-1.00)[-1.000]; RCPT_COUNT_ONE(0.00)[1]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[uoguelph.ca:+]; DMARC_POLICY_ALLOW(-0.50)[uoguelph.ca,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; RCVD_TLS_LAST(0.00)[]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-ThisMailContainsUnwantedMimeParts: N Hi,=0A= =0A= PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when=0A= the server was upgraded from 12.2-p8 to 12.2-p9.=0A= I know that nothing changed in NFS server code, but how can I find out=0A= what did get changed by that update?=0A= =0A= Thanks in advance for any help, rick=0A= From nobody Sat Oct 16 04:15:15 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 E3ECD180FBA4 for ; Sat, 16 Oct 2021 04:15:29 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from smtp6.goneo.de (smtp6.goneo.de [85.220.129.31]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWVDK4Zbcz4YkT; Sat, 16 Oct 2021 04:15:29 +0000 (UTC) (envelope-from freebsd@walstatt-de.de) Received: from hub1.goneo.de (hub1.goneo.de [IPv6:2001:1640:5::8:52]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by smtp6.goneo.de (Postfix) with ESMTPS id 7668B1097A86; Sat, 16 Oct 2021 06:15:21 +0200 (CEST) Received: from hub1.goneo.de (localhost [127.0.0.1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits)) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPS id A324210A75DE; Sat, 16 Oct 2021 06:15:19 +0200 (CEST) Received: from hermann (unknown [46.183.103.8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by hub1.goneo.de (Postfix) with ESMTPSA id 3DFB410A32F5; Sat, 16 Oct 2021 06:15:19 +0200 (CEST) Date: Sat, 16 Oct 2021 06:15:15 +0200 From: FreeBSD User To: Konstantin Belousov Cc: Jan Beich , FreeBSD CURRENT Subject: Re: 13-STABLE/drm-fbsd13-kmod: Firefox crash: Bad system call Message-ID: <20211016061515.6dec74e4@hermann> In-Reply-To: References: <20211015095233.19c841d0@hermann.fritz.box> <35p2-jazc-wny@FreeBSD.org> 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-Transfer-Encoding: 7bit X-Rspamd-UID: 6d388e X-Rspamd-UID: 85614a X-Rspamd-Queue-Id: 4HWVDK4Zbcz4YkT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N On Fri, 15 Oct 2021 23:25:01 +0300 Konstantin Belousov wrote: > On Fri, Oct 15, 2021 at 10:20:55PM +0200, Jan Beich wrote: > > FreeBSD User writes: > > > > > After updating 13-STABLE to 13.0-STABLE #3 stable/13-n247671-70db230dcbd: Thu Oct 14 > > > 20:48:53 CEST 2021 amd64 on a Lenovo E540 notebook with Intel iGPU and also > > > updating port graphics/drm-fbsd13-kmod to drm-fbsd13-kmod-5.4.144.g20211013, > > > graphics/libdrm to libdrm-2.4.107_1,1, Firefox (firefox-93.0_1,2) crashes now with > > > the following message: > > > > Which revision "13-STABLE" was before the update? If you didn't change > > any kernel options (and bump into a pilot error) bisecting may help. > > > > > > > > [~] firefox > > > Crash Annotation GraphicsCriticalError: |[C0][GFX1-]: Receive IPC close with > > > reason=AbnormalShutdown (t=0.216076) Exiting due to channel error. Bad system > > > callgraphics/libdrm. > > > > Run under truss(1) or ktrace(1) (enable tracing descendants) to get the > > syscall name or number. For example, Firefox requires CAPABILITIES for > > cap_rights_{limit,init} and COMPAT_FREEBSD11 [1] for pre-ino64 via Rust. > > > > [1] https://github.com/rust-lang/libc/pull/2406 > > If you set kern.lognosys=3, it should be quite loud advertized which syscall > was missed, ie. console + control terminal. > terminal) > Hello, thanks for the fast response. I changed indeed one single kernel parameter: commenting out the COMPAT_FREEBSD11. I think Jan Beich pointed towards the right thing. Thanks for the help and soryy for the noise. Kind regards, O. Hartmann From nobody Sat Oct 16 05:04:40 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 C37B617F3A6E for ; Sat, 16 Oct 2021 05:04:49 +0000 (UTC) (envelope-from herbert@gojira.at) Received: from mail.bsd4all.net (mail.bsd4all.net [94.130.200.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "mail.bsd4all.net", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4HWWKD4CJRz4nsM for ; Sat, 16 Oct 2021 05:04:48 +0000 (UTC) (envelope-from herbert@gojira.at) Date: Sat, 16 Oct 2021 07:04:40 +0200 DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=gojira.at; s=mail202005; t=1634360680; bh=IT9hCRo93og4hPCO/QEdyU+BsW10MAXlAj2haojFUBo=; h=Date:From:To:Subject:Message-ID:MIME-Version:Content-Type; b=kNzWPJLFgRmUdwJn1QQn4VqSNObMVyQOoK0xPCC79WAbkkK7FKhngHRsQOfs8ZGqp oPvYTx2oZXzk4AgbM1zy8v8XZVnbC6Fb82cP6JXHhtx6A74Z6eyAsIi0EWTXWQLQei hhWDeXp+f5KafUsBOHDRdDHuSPgriX82dqRGs+4zbmPfqxB0gHsvd2aNewrOOPuskL UKopgVurmojnA8O41kbenmDChyUiLl8ASJz/LSjmiRVREB80qsa30zSKHKfV2v3wpC Jf7wT1NfPtkosniLLO/y5prwKuettWZ3cb7U7DwxyeBpZiduGhqm53M5S6J71w+veu qvhyj79y9FPvg== From: "Herbert J. Skuhra" To: freebsd-current@freebsd.org Subject: Re: How do I find out what changed for an freebsd release update? Message-ID: References: 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: X-Rspamd-Queue-Id: 4HWWKD4CJRz4nsM X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gojira.at header.s=mail202005 header.b=kNzWPJLF; dmarc=none; spf=pass (mx1.freebsd.org: domain of herbert@gojira.at designates 94.130.200.20 as permitted sender) smtp.mailfrom=herbert@gojira.at X-Spamd-Result: default: False [-2.31 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gojira.at:s=mail202005]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:94.130.200.20]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; DMARC_NA(0.00)[gojira.at]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000]; DKIM_TRACE(0.00)[gojira.at:+]; NEURAL_HAM_SHORT(-0.81)[-0.814]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:24940, ipnet:94.130.0.0/16, country:DE] X-ThisMailContainsUnwantedMimeParts: N On Fri, Oct 15, 2021 at 11:48:01PM +0000, Rick Macklem wrote: > Hi, > > PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when > the server was upgraded from 12.2-p8 to 12.2-p9. > I know that nothing changed in NFS server code, but how can I find out > what did get changed by that update? > > Thanks in advance for any help, rick 1. Check UPDATING https://cgit.freebsd.org/src/tree/UPDATING?h=releng/12.2 2. git log and git diff e.g.: git diff 6e927d10c587..2430d82b40ea -- Herbert From nobody Sun Oct 17 05:56:10 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 96D1117F79E7 for ; Sun, 17 Oct 2021 05:56:20 +0000 (UTC) (envelope-from SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl) Received: from smtp-relay-int.realworks.nl (smtp-relay-int.realworks.nl [194.109.157.24]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4HX8QB5DH5z3n2v for ; Sun, 17 Oct 2021 05:56:18 +0000 (UTC) (envelope-from SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl) Date: Sun, 17 Oct 2021 07:56:10 +0200 (CEST) DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=klop.ws; s=rw1; t=1634450171; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to; bh=/k6+hul9XsyAwvwGQ5wpfc0ohtczXH233eOCQvpG/+0=; b=/xg6Du2ew0WS5/fSAOJt60NqOIut2sIODytNDnPz6MyV9nrUxLlWqqAPOG1rDYTLD0hzHj H58CE9Kbn8M399DA== From: Ronald Klop To: Rick Macklem , FreeBSD Current Message-ID: <252291676.7109.1634450170773@localhost> In-Reply-To: Subject: Re: How do I find out what changed for an freebsd release update? 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: multipart/alternative; boundary="----=_Part_7108_1412820454.1634450170772" X-Mailer: Realworks (579.119.a6bae4a) Importance: Normal X-Priority: 3 (Normal) X-Rspamd-Queue-Id: 4HX8QB5DH5z3n2v X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=klop.ws header.s=rw1 header.b="/xg6Du2e"; dmarc=pass (policy=none) header.from=klop.ws; spf=pass (mx1.freebsd.org: domain of "SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl" designates 194.109.157.24 as permitted sender) smtp.mailfrom="SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl" X-Spamd-Result: default: False [-2.20 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[klop.ws:s=rw1]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:194.109.157.0/24]; NEURAL_HAM_LONG(-1.00)[-1.000]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; NEURAL_HAM_SHORT(-1.00)[-1.000]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[klop.ws:+]; RCPT_COUNT_TWO(0.00)[2]; HAS_X_PRIO_THREE(0.00)[3]; RCVD_IN_DNSWL_NONE(0.00)[194.109.157.24:from]; DMARC_POLICY_ALLOW(-0.50)[klop.ws,none]; FORGED_SENDER(0.30)[ronald-lists@klop.ws,SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[194.109.157.24:from]; MID_RHS_NOT_FQDN(0.50)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:3265, ipnet:194.109.0.0/16, country:NL]; SUBJECT_ENDS_QUESTION(1.00)[]; FROM_NEQ_ENVFROM(0.00)[ronald-lists@klop.ws,SRS0=ZXRV=PF=klop.ws=ronald-lists@realworks.nl] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: Y ------=_Part_7108_1412820454.1634450170772 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit See https://cgit.freebsd.org/src/log/?h=releng/12.2 Everything on 2021-06-29. Regards, Ronald. Van: Rick Macklem Datum: 16 oktober 2021 01:49 Aan: FreeBSD Current Onderwerp: How do I find out what changed for an freebsd release update? > > > Hi, > > PR#259163 reports a problem w.r.t. the NFSv3 server that surfaced when > the server was upgraded from 12.2-p8 to 12.2-p9. > I know that nothing changed in NFS server code, but how can I find out > what did get changed by that update? > > Thanks in advance for any help, rick > > > > > ------=_Part_7108_1412820454.1634450170772-- From nobody Sun Oct 17 12:24:29 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 DF21918041F9 for ; Sun, 17 Oct 2021 12:24:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (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 4HXK2917vPz3FVp for ; Sun, 17 Oct 2021 12:24:33 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id v127so6282004wme.5 for ; Sun, 17 Oct 2021 05:24:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:to:content-language:from :subject:content-transfer-encoding; bh=5vsVcA0W3qwRpSxIs6LT+9e9z///Ep1kaSbJHNqY48Q=; b=cZGC/VPG6EXUf+C1XPO18fd4RwcjRjU+gzYu1yUHbhVuh4WvUJcGKiL3LaCf9XGgBP p3ka6hMYyCbfDxQ7+XavSI6l7QLMD2v0NOULAXBojKOvatB1jtkIjo4Ya6XhXJcSZ0+1 WPu21vDEroJdkFh8rv6E9vrS+WqDuhzt03TknRXfQgBTRGdfJk4+cXW6ZA4noLfZUC0d WndwQHe4uReW8JbxtStKaZZu82Jq7N5gQxb3dsG3p+iKDJB+d2WrJ6c9S5q5ukEvRCQd Zzs2wuhCG0t4WsfGHrBQzPw6Bd27KwXu/dMuEQFZVYKfoNM+RfCFTUUlw18nyUt0O8jH nAEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:to :content-language:from:subject:content-transfer-encoding; bh=5vsVcA0W3qwRpSxIs6LT+9e9z///Ep1kaSbJHNqY48Q=; b=uPfQi0W7PmEvdYNqpb7w+KKECf1GonVTC4V+TNxThFXnwec7FeyP8pPfdt+MgDENal vSxdCVF09zPb/hPsprhTCEgcM8mPqY46bn37gPIsibqcugGILpkoyKPlJ6bUinf+Fzrs cFKbGhwZSqQ04aIoP4ebUFeUlc5NkLWMEj/+B+M0CP5MEH5IlejSB5RJWtJQSYMRINdh poZw169bXqO8VwuVxMzysymhEbn/SW7ZPUoVhmrkS2firrqbV9Np2W3YqlFq8xPAI4+g ISuQW+pItW+zqmNSKBb/H1HWPh2VajlsxPyfoSoQ/w8QQh2F3yXBGVaMx3Fq3+ZI1764 ROkg== X-Gm-Message-State: AOAM532+e6FnEUu055Mm3fh3Qsglb2aoGGGHxmiWWwQmKFcyukQkf3yU R4BXT1804a2467M5HggOJSW8vyuxRTw= X-Google-Smtp-Source: ABdhPJzlQpSso474hC5ZpLXBtXJCDwd/zPQsr8LQBcUsqie9frXlU8+lDa0xMB2p9pqfdqxPPo1rng== X-Received: by 2002:a05:600c:2303:: with SMTP id 3mr38481535wmo.123.1634473471904; Sun, 17 Oct 2021 05:24:31 -0700 (PDT) Received: from ?IPV6:2001:470:1f1c:a0::2? (tunnel642390-pt.tunnel.tserv1.lon2.ipv6.he.net. [2001:470:1f1c:a0::2]) by smtp.gmail.com with ESMTPSA id c17sm10035199wrq.4.2021.10.17.05.24.31 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 05:24:31 -0700 (PDT) Message-ID: Date: Sun, 17 Oct 2021 13:24:29 +0100 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 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:91.0) Gecko/20100101 Thunderbird/91.2.0 To: FreeBSD Current Content-Language: en-GB From: Graham Perrin Subject: =?UTF-8?Q?VMMR0InitVM_=e2=80=a6_kernel_panic=3a_fatal_trap_9=3a_gen?= =?UTF-8?Q?eral_protection_fault_while_in_kernel_mode?= Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HXK2917vPz3FVp X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b="cZGC/VPG"; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-1.67 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; NEURAL_HAM_MEDIUM(-0.42)[-0.420]; FROM_HAS_DN(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; NEURAL_HAM_LONG(-1.00)[-0.996]; RCPT_COUNT_ONE(0.00)[1]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from]; NEURAL_SPAM_SHORT(0.75)[0.751]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim] X-ThisMailContainsUnwantedMimeParts: N Is it worth opening a bug for what's below? GENERIC-NODEBUG, main-n249988-2c614481fd5 Gut feeling: it might be very difficult to reproduce. From : … Unread portion of the kernel message buffer: VMMR0InitVM: eflags=246 fKernelFeatures=0x0 (SUPKERNELFEATURES_SMAP=0) Fatal trap 9: general protection fault while in kernel mode cpuid = 3; apic id = 03 instruction pointer     = 0x20:0xffffffff810bc0a6 stack pointer           = 0x28:0xfffffe00c5303ba0 frame pointer           = 0x28:0xfffffe00c5303ba0 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         = 19 (arc_reap) trap number             = 9 panic: general protection fault cpuid = 3 time = 1634464447 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfffffe00c53038a0 vpanic() at vpanic+0x187/frame 0xfffffe00c5303900 panic() at panic+0x43/frame 0xfffffe00c5303960 trap_fatal() at trap_fatal+0x387/frame 0xfffffe00c53039c0 trap() at trap+0x8b/frame 0xfffffe00c5303ad0 calltrap() at calltrap+0x8/frame 0xfffffe00c5303ad0 --- trap 0x9, rip = 0xffffffff810bc0a6, rsp = 0xfffffe00c5303ba0, rbp = 0xfffffe00c5303ba0 --- pmap_invalidate_all_pcid_noinvpcid_cb() at pmap_invalidate_all_pcid_noinvpcid_cb+0x36/frame 0xfffffe00c5303ba0 smp_targeted_tlb_shootdown() at smp_targeted_tlb_shootdown+0x2b7/frame 0xfffffe00c5303c20 pmap_invalidate_all() at pmap_invalidate_all+0x117/frame 0xfffffe00c5303c90 pmap_remove() at pmap_remove+0x5ae/frame 0xfffffe00c5303d10 _kmem_unback() at _kmem_unback+0x32/frame 0xfffffe00c5303d60 kmem_free() at kmem_free+0x2d/frame 0xfffffe00c5303d80 keg_free_slab() at keg_free_slab+0xdc/frame 0xfffffe00c5303dc0 keg_drain_domain() at keg_drain_domain+0x1c1/frame 0xfffffe00c5303e00 zone_reclaim() at zone_reclaim+0x1aa/frame 0xfffffe00c5303e50 arc_kmem_reap_soon() at arc_kmem_reap_soon+0x61/frame 0xfffffe00c5303e80 arc_reap_cb() at arc_reap_cb+0x9/frame 0xfffffe00c5303e90 zthr_procedure() at zthr_procedure+0xba/frame 0xfffffe00c5303ef0 fork_exit() at fork_exit+0x8a/frame 0xfffffe00c5303f30 fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe00c5303f30 --- trap 0x4dda280, rip = 0x100000000, rsp = 0, rbp = 0x1a99c090 --- KDB: enter: panic … fstat USER     CMD          PID   FD MOUNT      INUM MODE         SZ|DV R/W grahampe VirtualBoxVM  3085 root /             4 drwxr-xr-x 37  r … Context: lines 1285–1372. From nobody Sun Oct 17 17:25:06 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 9DB5917F3E24 for ; Sun, 17 Oct 2021 17:25:26 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-vk1-xa31.google.com (mail-vk1-xa31.google.com [IPv6:2607:f8b0:4864:20::a31]) (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 4HXRjK4jpsz4QvL for ; Sun, 17 Oct 2021 17:25:25 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-vk1-xa31.google.com with SMTP id u206so664454vke.10 for ; Sun, 17 Oct 2021 10:25:25 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=SoBF4malL7CC/1IUYFglF+IRxasao6yGn38amBT5Rxc=; b=Ig1K16iM5Y9H9ycuRp7yz5UMv6tAGTCSUqkqsvjBGSRtljmzmUqqo6dcpqd4o6z6zx iEFXk990O/Xe83W3mGv0lKVK3l/MJhUSmOVNvjcJO2l1FTo4M4ZlVBqMaQBgkP7SjY5k vOIgoi93o0R/Brlvw/1Z040rc6AM2+4959u+edFKxc3FeRAKLFva+Q7OU003qbX5rYQL p9MrrIlvDLkb5IzL6lYB9lYh0miyvW6lg7sYvha9WnMLXNt0fwt5uDu61KlhMn0CZlwL pS19YVfRwEi0yjO7fbSrWgHDMo7Y73tk4Fs56sq2RxEmqdBtQA4DlyLYQDeMOSfBR99j jMXg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=SoBF4malL7CC/1IUYFglF+IRxasao6yGn38amBT5Rxc=; b=PiYiyTQHfVHrfpx95TpYcmEaTa7oyqFKmSLyHQC207xvDIyymHVAqkDRM3UnaNrwOA fQdZg1HJ6yo8KA37KB1tcSqbETMnT5Ms1yFAez1kkMOydr75JRorL2QGZRbDsAmEaVQI EteqN1OK5UHWMGB8XQ0Ew0CLWdoq30wzYpvpy2ICdI6U1DGEO/FlQ/Sk9wOBLENi6OUm 5JW2aDmWryMpHOh+jk+UN9Lrcb8d6gBlkCxWZTTam4UVFNt/W9MPStPA8iQ4hvtcMemn EnofekTcE8+IcfBY9yNdxVPfWt4KMUdSw2krz8HZvz9LRFGMqyPQa3Bdel5Etrs8D1Qv akpA== X-Gm-Message-State: AOAM533KkYCAQoFOgcXwYsUOdZnP5AkIjkLuEbtXGM9tcHNPofqMPgvg 3Sdb/8bY94dWAJTwTTdHuwhIGX6a99Dda2p8keRe2t5J X-Google-Smtp-Source: ABdhPJw7+DzBpxEZBYYpCzVey2wGm45caFx3PR0awLnX67DBMdjrD5CZ3d0hmnKejmRn9NugVdGW29iPnj2bk6dhhAQ= X-Received: by 2002:a1f:2006:: with SMTP id g6mr21588864vkg.22.1634491519049; Sun, 17 Oct 2021 10:25:19 -0700 (PDT) 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 References: <4fa413f4-f167-ce1d-ce2f-a2a05a34dc32@gmail.com> In-Reply-To: <4fa413f4-f167-ce1d-ce2f-a2a05a34dc32@gmail.com> From: Warner Losh Date: Sun, 17 Oct 2021 11:25:06 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Alexander Motin Cc: Pavel Timofeev , Chuck Tuffli , freebsd-current Content-Type: multipart/alternative; boundary="00000000000062875c05ce8fb65b" X-Rspamd-Queue-Id: 4HXRjK4jpsz4QvL X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=bsdimp-com.20210112.gappssmtp.com header.s=20210112 header.b=Ig1K16iM; dmarc=none; spf=none (mx1.freebsd.org: domain of wlosh@bsdimp.com has no SPF policy when checking 2607:f8b0:4864:20::a31) smtp.mailfrom=wlosh@bsdimp.com X-Spamd-Result: default: False [-1.00 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; RCVD_COUNT_TWO(0.00)[2]; R_DKIM_ALLOW(-0.20)[bsdimp-com.20210112.gappssmtp.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[bsdimp.com]; TO_MATCH_ENVRCPT_SOME(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[bsdimp-com.20210112.gappssmtp.com:+]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::a31:from]; NEURAL_HAM_SHORT(-1.00)[-1.000]; R_SPF_NA(0.00)[no SPF record]; FREEMAIL_TO(0.00)[gmail.com]; FORGED_SENDER(0.30)[imp@bsdimp.com,wlosh@bsdimp.com]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; FROM_NEQ_ENVFROM(0.00)[imp@bsdimp.com,wlosh@bsdimp.com]; RCVD_TLS_ALL(0.00)[]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org] X-ThisMailContainsUnwantedMimeParts: Y --00000000000062875c05ce8fb65b Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Oct 17, 2021, 11:19 AM Alexander Motin wrote: > It may be a noise, but comparing logs I see in reboot case also > "acpi_ec0: not getting interrupts, switched to polled mode". I am > thinking whether the problem may be caused not by SSD, but by some > resource conflict/misconfiguration in the system. Pavel, can you > compare `devinfo -vr` and `lspci -vvvvv` in both cases. looking for any > differences? Are you running the latest BIOS? > I'm leaning the same way since I have an identical drive not showing problems in my system. It's also weird that the completion record for the identify didn't show up after reboot. It makes me think it went to the wrong place or didn't make it back up the bridge hierarchy. Warner On 12.10.2021 15:56, Warner Losh wrote: > > One piece of data that would be good to have: > > > > nvmecontrol identify nvme0 > > > > There's an optional feature that none of my drives have, but that the > Linux > > driver does oddly > > weird things when enabled. The output of that command will help me > > understand if that may > > be in play. Maybe we need to do oddly weird things too :) > > > > Warner > > > > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: > > > >> > >> > >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev > wrote: > >> > >>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner= Losh : > >>> > >>>> > >>>> > >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote= : > >>>> > >>>>> > >>>>> > >>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warn= er Losh : > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev > >>>>>> wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, W= arner Losh : > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Warner Losh : > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev < > timp87@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Pavel Timofeev : > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Chuck Tuffli : > >>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < > >>>>>>>>>>> timp87@gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hello > >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the > latest > >>>>>>>>>>>>> 14.0-CURRENT > >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it. > >>>>>>>>>>>>>> Despite other things the weird one which concerns me is > >>>>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>>>> message I get sometimes on the console. > >>>>>>>>>>>>>> It seems like I get it only after the reboot of the laptop= , > >>>>>>>>>>> i. e. not > >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at least= I > >>>>>>>>>>> haven't > >>>>>>>>>>>>> seen > >>>>>>>>>>>>>> them for now in such cases. > >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantage > of > >>>>>>>>>>>>>> nvmecontrol(8) quickly. > >>>>>>>>>>>>>> Well, it still works, but it takes tens of seconds to retu= rn > >>>>>>>>>>> the output. > >>>>>>>>>>>>> ... > >>>>>>>>>>>>>> dmesg when power cycled - > >>>>>>>>>>>>>> > >>>>>>>>>>> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ > >>>>>>>>>>>>>> dmesg when rebooted - > >>>>>>>>>>>>>> > >>>>>>>>>>> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm sort of curious about the time stamps for the log > messages > >>>>>>>>>>> in the > >>>>>>>>>>>>> failing case. Something like: > >>>>>>>>>>>>> > >>>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>>>> > >>>>>>>>>>>>> --chuck > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Well, I can't see timestamps in the verbose boot log. Am I > >>>>>>>>>>> missing some > >>>>>>>>>>>> configuration for that? > >>>>>>>>>>>> > >>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>>> nvme0: mem > >>>>>>>>>>>> > >>>>>>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > >>>>>>>>>>>> 0.0 on pci6 > >>>>>>>>>>>> nvme0: attempting to allocate 5 MSI-X vectors (17 supported) > >>>>>>>>>>>> nvme0: using IRQs 133-137 for MSI-X > >>>>>>>>>>>> nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 > >>>>>>>>>>>> nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, > >>>>>>>>>>> MPSMAX 0 > >>>>>>>>>>>> nvme0: Version: 0x00010300: 1.3 > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvd0: NVMe namespace > >>>>>>>>>>>> GEOM: new disk nvd0 > >>>>>>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Ah, sorry, provided wrong output. > >>>>>>>>>>> Here is what you requested: > >>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: > mem > >>>>>>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > >>>>>>>>>>> at device > >>>>>>>>>>> 0.0 on pci6 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocat= e > 5 > >>>>>>>>>>> MSI-X > >>>>>>>>>>> vectors (17 supported) > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 fo= r > >>>>>>>>>>> MSI-X > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQ= ES > >>>>>>>>>>> 1023, CQR, > >>>>>>>>>>> TO 20 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: > DSTRD > >>>>>>>>>>> 0, NSSRS, > >>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: > 1.3 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>>>> 512GB> NVMe > >>>>>>>>>>> namespace > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 5= 12 > >>>>>>>>>>> byte > >>>>>>>>>>> sectors) > >>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and > >>>>>>>>>> hw.cam.nda.nvd_compat=3D1 > >>>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd > >>>>>>>>>> was? Or does > >>>>>>>>>> it work? > >>>>>>>>>> > >>>>>>>>>> Something weird is going on in the interrupt assignment, I > think, > >>>>>>>>>> but I > >>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. > >>>>>>>>>> > >>>>>>>>>> Warner > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead > >>>>>>>>> of hw.cam.nda.nvd_compat? > >>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. > >>>>>>>>> > >>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I sti= ll > >>>>>>>>> see > >>>>>>>>> nvme0: Missing interrupt > >>>>>>>>> and now also > >>>>>>>>> Root mount waiting for: CAM > >>>>>>>>> messages besides those > >>>>>>>>> > >>>>>>>> > >>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by > default > >>>>>>>> these > >>>>>>>> days. > >>>>>>>> > >>>>>>>> I'll take a look on monday starting at the differences in > interrupt > >>>>>>>> assignment that > >>>>>>>> are apparent when you cold boot vs reboot. > >>>>>>>> > >>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also > >>>>>>>> didn't really > >>>>>>>> expect it to be. > >>>>>>>> > >>>>>>>> Warner > >>>>>>>> > >>>>>>>> > >>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got eve= n > >>>>>>> worse now. > >>>>>>> So clean poweron works as before. > >>>>>>> But if rebooted nvme drive refuses to work, while before the code > >>>>>>> upgrade it was just complaining about missing interrupts. > >>>>>>> > >>>>>>> currently dmesg show this: > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> nvd0: NVMe namespace > >>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> > >>>>>> > >>>>>> Why is this showing up twice? Or is everything above this line lef= t > >>>>>> over from the first, working boot? > >>>>>> > >>>>>> > >>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 > >>>>>>> nvme0: timeout with nothing complete, resetting > >>>>>>> nvme0: Resetting controller due to a timeout. > >>>>>>> nvme0: RECOVERY_WAITING > >>>>>>> nvme0: resetting controller > >>>>>>> nvme0: aborting outstanding admin command > >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > >>>>>>> cdw11:00000000 > >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>>>> nvme0: nvme_identify_controller failed! > >>>>>>> nvme0: waiting > >>>>>>> > >>>>>> > >>>>>> Clearly something bad is going on with the drive here... We looked > >>>>>> into the completion queues when we didn't get an interrupt and > there was > >>>>>> nothing complete there.... > >>>>>> > >>>>>> The only thing I can think of is that this means there's a phase > error > >>>>>> between the drive and the system. I recently removed a second rese= t > and > >>>>>> made it an option NVME_2X_RESET. Can you see if adding > >>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? > >>>>>> > >>>>>> Warner > >>>>>> > >>>>>> > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 > >>>>>>> nvme0: timeout with nothing complete, resetting > >>>>>>> nvme0: Resetting controller due to a timeout. > >>>>>>> nvme0: RECOVERY_WAITING > >>>>>>> nvme0: resetting controller > >>>>>>> nvme0: aborting outstanding admin command > >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > >>>>>>> cdw11:00000000 > >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>>>> nvme0: nvme_identify_controller failed! > >>>>>>> nvme0: waiting > >>>>>>> > >>>>>>> > >>>>> > >>>>> Sorry, it's showing twice due to multiple reboots. For one boot it'= s > >>>>> like: > >>>>> nvme0: mem > >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t > device > >>>>> 0.0 on pci6 > >>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 > >>>>> nvme0: timeout with nothing complete, resetting > >>>>> nvme0: Resetting controller due to a timeout. > >>>>> nvme0: RECOVERY_WAITING > >>>>> nvme0: resetting controller > >>>>> nvme0: aborting outstanding admin command > >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > cdw11:00000000 > >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>> nvme0: nvme_identify_controller failed! > >>>>> nvme0: waiting > >>>>> > >>>>> Well, neither Windows not Linux have any problems with the device. = I > >>>>> understand they may be hiding it or workaround somehow. > >>>>> > >>>> > >>>> Yea, I'm trying to figure out why your machine is different than min= e, > >>>> and what Windows or Linux do that is different. It may be dodgy > hardware, > >>>> but others have no trouble... > >>>> > >>>> I'll try setting NVME_2X_RESET in the kernel config and report back > in a > >>>>> while. > >>>>> > >>>> > >>>> Thanks. If it helps, that tells me something. If it doesn't, that > tells > >>>> me something else. > >>>> > >>>> I suspect that it is somewhere else in the system, tbh, but I need t= o > >>>> find it systematically. > >>>> > >>>> Warner > >>>> > >>> > >>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't chang= ed > >>> anything. I. e it didn't help. > >>> > >> > >> While it would have been nice to have this be the fix, I'm not that > >> surprised either. > >> It was the biggest change of late, apart from the big re-arrangement > that > >> I'd done. > >> > >> So the other changes have moved from the occasional missing interrupt > >> message > >> (which the old code would get when a command wasn't completed in the > >> timeout > >> period, but that we found to be done when we scanned the completion > queue. > >> Now > >> the device is detected fine (as before), but then doesn't do I/O at al= l > >> (including not > >> completing the identify command!) and is worse. This is unexpected and > I'm > >> trying > >> understand what happens on reboot that 'changes'the working state and > why > >> the > >> new code behaves so differently. > >> > >> Warner > >> > > > > -- > Alexander Motin > --00000000000062875c05ce8fb65b-- From nobody Sun Oct 17 17:25:42 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 0775017F3FCA for ; Sun, 17 Oct 2021 17:26:02 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 4HXRk124rGz4RCW for ; Sun, 17 Oct 2021 17:26:01 +0000 (UTC) (envelope-from mavbsd@gmail.com) Received: by mail-qt1-x830.google.com with SMTP id o12so13355355qtq.7 for ; Sun, 17 Oct 2021 10:26:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=yQcH7AjWknzl3HrYHTt3ctq0oqEdc5hLcePYzH993+g=; b=nyYVczny8gNpo7Kc4CW7YVH44vAug19ayWqCDsQ720czrLEzNL9XTWmSScHb8s3zoN cBjU+KRED9+W8RLZtl8LfVhY7des6xkAn5FMBLDM5dyWyf4Ij5NrJ288lwfLYGhAapvp bIn/Nki9e5GrWG6HuF4Jzuw5Nz4wAk6aFAL0fOcE2+/9PTjRw7iNPRCM+ILtxqOBCaUH QMUQVPwwy7tG4Iwjsn86xcKfX8HeFTI8g7LlTL7HUPbnPM/5iFKxrNHcyadqYNHn6hyE odOlw14H+GutH7uTEW20j6GyYgLHXJpn6nLc2gtOK0R1yPwBz1IgCOwENLq9e8vGJvDz 6LuA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=yQcH7AjWknzl3HrYHTt3ctq0oqEdc5hLcePYzH993+g=; b=Z4H5giRXL1MAmmTX9ztAy/mPtnnPkxWqnHvzh3MCflUnMOE5WYJIbA6fJJ6MblrIFw wuavJnMAjmWvoJBrrBwrvRDGJE37FUq5Nesx9Xj8ef83yEiZA3w3/vlBjk+rejn6jtoP IS9JJiWEBhmcE/jHk0N0CHiVmu/4FrtRVDBOXcHlIUYuTzQkBFUof1t6sid1OhvrdYpB F1uD0D0fZyteI83D/GymcWuRuDEcmFKoxRqBJikO3u/3KokDKAOVHiDmBF15NPVzhCE9 k9+ucwKriEZrRiM3SRZmJ9WHZVcFEPS9WIc9XlaANJaj/+5DcPOOh3OCzh3d4ssDq1w7 TpXQ== X-Gm-Message-State: AOAM531h4qfSXi9j/SA+ltzp2YpVSD2v3py7Hxe9tREn5sHKl+0ZseLd e9u3nY0E20F36BfO9fCW0DNEQU4SWMHTR4Tw X-Google-Smtp-Source: ABdhPJx/Pg93wtuBR2aQSL3zCWs7t0QmcwyBxFzlrhhONnrDqWsD6/djFx1UXevNb87BnAbwkj0I4Q== X-Received: by 2002:ac8:5794:: with SMTP id v20mr9157844qta.243.1634491554553; Sun, 17 Oct 2021 10:25:54 -0700 (PDT) Received: from spectre.mavhome.dp.ua ([8.46.75.2]) by smtp.gmail.com with ESMTPSA id c5sm5375637qkm.10.2021.10.17.10.25.48 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 17 Oct 2021 10:25:54 -0700 (PDT) Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Warner Losh , Pavel Timofeev Cc: Chuck Tuffli , freebsd-current References: From: Alexander Motin Message-ID: <3712e2a7-1180-9918-3af2-67531a9ead9f@FreeBSD.org> Date: Sun, 17 Oct 2021 13:25:42 -0400 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:78.0) Gecko/20100101 Thunderbird/78.13.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Rspamd-Queue-Id: 4HXRk124rGz4RCW X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=nyYVczny; dmarc=none; spf=pass (mx1.freebsd.org: domain of mavbsd@gmail.com designates 2607:f8b0:4864:20::830 as permitted sender) smtp.mailfrom=mavbsd@gmail.com X-Spamd-Result: default: False [-1.20 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; NEURAL_HAM_SHORT(-1.00)[-1.000]; FREEMAIL_TO(0.00)[bsdimp.com,gmail.com]; FORGED_SENDER(0.30)[mav@FreeBSD.org,mavbsd@gmail.com]; RECEIVED_SPAMHAUS_PBL(0.00)[8.46.75.2:received]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; FROM_NEQ_ENVFROM(0.00)[mav@FreeBSD.org,mavbsd@gmail.com]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[FreeBSD.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::830:from]; FREEMAIL_CC(0.00)[gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: N It may be a noise, but comparing logs I see in reboot case also "acpi_ec0: not getting interrupts, switched to polled mode". I am thinking whether the problem may be caused not by SSD, but by some resource conflict/misconfiguration in the system. Pavel, can you compare `devinfo -vr` and `lspci -vvvvv` in both cases. looking for any differences? Are you running the latest BIOS? On 12.10.2021 15:56, Warner Losh wrote: > One piece of data that would be good to have: > > nvmecontrol identify nvme0 > > There's an optional feature that none of my drives have, but that the Linux > driver does oddly > weird things when enabled. The output of that command will help me > understand if that may > be in play. Maybe we need to do oddly weird things too :) > > Warner > > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: > >> >> >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev wrote: >> >>> сб, 9 окт. 2021 г. в 14:59, Warner Losh : >>> >>>> >>>> >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote: >>>> >>>>> >>>>> >>>>> пт, 8 окт. 2021 г. в 14:49, Warner Losh : >>>>> >>>>>> >>>>>> >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev >>>>>> wrote: >>>>>> >>>>>>> >>>>>>> >>>>>>> сб, 21 авг. 2021 г. в 15:22, Warner Losh : >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev >>>>>>>> wrote: >>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> Warner Losh : >>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev >>>>>>>>>> wrote: >>>>>>>>>> >>>>>>>>>>> Pavel Timofeev : >>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Chuck Tuffli : >>>>>>>>>>>> >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < >>>>>>>>>>> timp87@gmail.com> wrote: >>>>>>>>>>>>>> >>>>>>>>>>>>>> Hello >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the latest >>>>>>>>>>>>> 14.0-CURRENT >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it. >>>>>>>>>>>>>> Despite other things the weird one which concerns me is >>>>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>>>> message I get sometimes on the console. >>>>>>>>>>>>>> It seems like I get it only after the reboot of the laptop, >>>>>>>>>>> i. e. not >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at least I >>>>>>>>>>> haven't >>>>>>>>>>>>> seen >>>>>>>>>>>>>> them for now in such cases. >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantage of >>>>>>>>>>>>>> nvmecontrol(8) quickly. >>>>>>>>>>>>>> Well, it still works, but it takes tens of seconds to return >>>>>>>>>>> the output. >>>>>>>>>>>>> ... >>>>>>>>>>>>>> dmesg when power cycled - >>>>>>>>>>>>>> >>>>>>>>>>> https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ >>>>>>>>>>>>>> dmesg when rebooted - >>>>>>>>>>>>>> >>>>>>>>>>> https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh >>>>>>>>>>>>> >>>>>>>>>>>>> I'm sort of curious about the time stamps for the log messages >>>>>>>>>>> in the >>>>>>>>>>>>> failing case. Something like: >>>>>>>>>>>>> >>>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>>>> >>>>>>>>>>>>> --chuck >>>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> Well, I can't see timestamps in the verbose boot log. Am I >>>>>>>>>>> missing some >>>>>>>>>>>> configuration for that? >>>>>>>>>>>> >>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>>> nvme0: mem >>>>>>>>>>>> >>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device >>>>>>>>>>>> 0.0 on pci6 >>>>>>>>>>>> nvme0: attempting to allocate 5 MSI-X vectors (17 supported) >>>>>>>>>>>> nvme0: using IRQs 133-137 for MSI-X >>>>>>>>>>>> nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 >>>>>>>>>>>> nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, >>>>>>>>>>> MPSMAX 0 >>>>>>>>>>>> nvme0: Version: 0x00010300: 1.3 >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvme0: Missing interrupt >>>>>>>>>>>> nvd0: NVMe namespace >>>>>>>>>>>> GEOM: new disk nvd0 >>>>>>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> Ah, sorry, provided wrong output. >>>>>>>>>>> Here is what you requested: >>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: mem >>>>>>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff >>>>>>>>>>> at device >>>>>>>>>>> 0.0 on pci6 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocate 5 >>>>>>>>>>> MSI-X >>>>>>>>>>> vectors (17 supported) >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 for >>>>>>>>>>> MSI-X >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQES >>>>>>>>>>> 1023, CQR, >>>>>>>>>>> TO 20 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: DSTRD >>>>>>>>>>> 0, NSSRS, >>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: 1.3 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>>> 512GB> NVMe >>>>>>>>>>> namespace >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 512 >>>>>>>>>>> byte >>>>>>>>>>> sectors) >>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> What happens if you set hw.nvme.use_nvd=0 and >>>>>>>>>> hw.cam.nda.nvd_compat=1 >>>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd >>>>>>>>>> was? Or does >>>>>>>>>> it work? >>>>>>>>>> >>>>>>>>>> Something weird is going on in the interrupt assignment, I think, >>>>>>>>>> but I >>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. >>>>>>>>>> >>>>>>>>>> Warner >>>>>>>>>> >>>>>>>>> >>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead >>>>>>>>> of hw.cam.nda.nvd_compat? >>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. >>>>>>>>> >>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I still >>>>>>>>> see >>>>>>>>> nvme0: Missing interrupt >>>>>>>>> and now also >>>>>>>>> Root mount waiting for: CAM >>>>>>>>> messages besides those >>>>>>>>> >>>>>>>> >>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=1 by default >>>>>>>> these >>>>>>>> days. >>>>>>>> >>>>>>>> I'll take a look on monday starting at the differences in interrupt >>>>>>>> assignment that >>>>>>>> are apparent when you cold boot vs reboot. >>>>>>>> >>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also >>>>>>>> didn't really >>>>>>>> expect it to be. >>>>>>>> >>>>>>>> Warner >>>>>>>> >>>>>>>> >>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got even >>>>>>> worse now. >>>>>>> So clean poweron works as before. >>>>>>> But if rebooted nvme drive refuses to work, while before the code >>>>>>> upgrade it was just complaining about missing interrupts. >>>>>>> >>>>>>> currently dmesg show this: >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device >>>>>>> 0.0 on pci6 >>>>>>> nvd0: NVMe namespace >>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device >>>>>>> 0.0 on pci6 >>>>>>> >>>>>> >>>>>> Why is this showing up twice? Or is everything above this line left >>>>>> over from the first, working boot? >>>>>> >>>>>> >>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 >>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>> nvme0: RECOVERY_WAITING >>>>>>> nvme0: resetting controller >>>>>>> nvme0: aborting outstanding admin command >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>> cdw11:00000000 >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>> nvme0: nvme_identify_controller failed! >>>>>>> nvme0: waiting >>>>>>> >>>>>> >>>>>> Clearly something bad is going on with the drive here... We looked >>>>>> into the completion queues when we didn't get an interrupt and there was >>>>>> nothing complete there.... >>>>>> >>>>>> The only thing I can think of is that this means there's a phase error >>>>>> between the drive and the system. I recently removed a second reset and >>>>>> made it an option NVME_2X_RESET. Can you see if adding >>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? >>>>>> >>>>>> Warner >>>>>> >>>>>> >>>>>>> nvme0: mem >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device >>>>>>> 0.0 on pci6 >>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 >>>>>>> nvme0: timeout with nothing complete, resetting >>>>>>> nvme0: Resetting controller due to a timeout. >>>>>>> nvme0: RECOVERY_WAITING >>>>>>> nvme0: resetting controller >>>>>>> nvme0: aborting outstanding admin command >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 >>>>>>> cdw11:00000000 >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>>>> nvme0: nvme_identify_controller failed! >>>>>>> nvme0: waiting >>>>>>> >>>>>>> >>>>> >>>>> Sorry, it's showing twice due to multiple reboots. For one boot it's >>>>> like: >>>>> nvme0: mem >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at device >>>>> 0.0 on pci6 >>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 >>>>> nvme0: timeout with nothing complete, resetting >>>>> nvme0: Resetting controller due to a timeout. >>>>> nvme0: RECOVERY_WAITING >>>>> nvme0: resetting controller >>>>> nvme0: aborting outstanding admin command >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 cdw11:00000000 >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 >>>>> nvme0: nvme_identify_controller failed! >>>>> nvme0: waiting >>>>> >>>>> Well, neither Windows not Linux have any problems with the device. I >>>>> understand they may be hiding it or workaround somehow. >>>>> >>>> >>>> Yea, I'm trying to figure out why your machine is different than mine, >>>> and what Windows or Linux do that is different. It may be dodgy hardware, >>>> but others have no trouble... >>>> >>>> I'll try setting NVME_2X_RESET in the kernel config and report back in a >>>>> while. >>>>> >>>> >>>> Thanks. If it helps, that tells me something. If it doesn't, that tells >>>> me something else. >>>> >>>> I suspect that it is somewhere else in the system, tbh, but I need to >>>> find it systematically. >>>> >>>> Warner >>>> >>> >>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't changed >>> anything. I. e it didn't help. >>> >> >> While it would have been nice to have this be the fix, I'm not that >> surprised either. >> It was the biggest change of late, apart from the big re-arrangement that >> I'd done. >> >> So the other changes have moved from the occasional missing interrupt >> message >> (which the old code would get when a command wasn't completed in the >> timeout >> period, but that we found to be done when we scanned the completion queue. >> Now >> the device is detected fine (as before), but then doesn't do I/O at all >> (including not >> completing the identify command!) and is worse. This is unexpected and I'm >> trying >> understand what happens on reboot that 'changes'the working state and why >> the >> new code behaves so differently. >> >> Warner >> > -- Alexander Motin From nobody Sun Oct 17 23:52:39 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 716E01807817 for ; Sun, 17 Oct 2021 23:53:01 +0000 (UTC) (envelope-from timp87@gmail.com) Received: from mail-ed1-x529.google.com (mail-ed1-x529.google.com [IPv6:2a00:1450:4864:20::529]) (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 4HXcJX0mwPz3nHn for ; Sun, 17 Oct 2021 23:53:00 +0000 (UTC) (envelope-from timp87@gmail.com) Received: by mail-ed1-x529.google.com with SMTP id r18so63714512edv.12 for ; Sun, 17 Oct 2021 16:53:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=0WcXOHsVdlh4RXa39QpRTASmlpy56Xqh5/f0EO1pR/I=; b=L+zdRsd22a0/1HRo1i/9wXarVtVtUWuvvXbmEt4H9JNC0d3/Kizc7DOWUR2Is3w2Ta VkAKwX0VQHnrHieQLml+AgrcIfkWq61mnxyp2/jFkxos3qRwvR4GnHlsnQ+MKz4fblbc 66hRd3mjYJsGWzeCVx7a9tiS0tp7POBqjztUcmkrO0jh3SLwXLlAFQDqEX6/VWIndIyB 3LUyHHAx9A2o5SyggXQSmvZwO//DdT288IzEkkVDBm2fEAeuUJjgeskLi2t3Ba0NpEvT xPBuy5BdoaN2eXeYXBlxUJqmF6USVX2aXW4ExSYf/KGg78gqq3EDMDEY7BV4WV4z20MO 7vvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=0WcXOHsVdlh4RXa39QpRTASmlpy56Xqh5/f0EO1pR/I=; b=tML4gFwYMPtZi01xraZLWNIaMfP11Z6s2x5YhWpJA/dRGel3LtzNjBbM+YRz6WDT3+ rG7EgJo6KwlcbOZNpUUj6/+30VrBVbiR4Ilt15qa87yeJRAwICwREZwdgud16sPFxhPA Jd3ya04J27fsnpm5Wi+PmOQBHHvDQu6DaKGjcwVZ/HDTEL3N2DPwYy0QbmsDDGEgWUR9 I6wVwQEJQBUhfBZQqMyjEhqTg3B3DAmnloS4XHmykwmgNO0K2zPR6FnA9fZ80KcMEOTx /mRvK26ge8LTsL2SnM5p4hdAMfFHBMVptPL304ggyoOKX0AIG+Rv64ORSbiCGuuYZvZo sz/A== X-Gm-Message-State: AOAM532oO2e/3vFkEfprTZBzFyChl/icbM13VDzv8JffyEMRXmSupmMP uTw1L9eJTIeHWuiulIun/hrklOas3AKaukfbBXzQVbqm96A= X-Google-Smtp-Source: ABdhPJxFhTVfmkqy8dTqsOPF/ETMyzd8dke1ANGplqqcg+GMNoQT2I7fR2G7uJnXFYv4E8q7EbSwY2x6cAVbjFi+J/s= X-Received: by 2002:a05:6402:3489:: with SMTP id v9mr39845235edc.130.1634514771412; Sun, 17 Oct 2021 16:52:51 -0700 (PDT) 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 References: <4fa413f4-f167-ce1d-ce2f-a2a05a34dc32@gmail.com> In-Reply-To: <4fa413f4-f167-ce1d-ce2f-a2a05a34dc32@gmail.com> From: Pavel Timofeev Date: Sun, 17 Oct 2021 17:52:39 -0600 Message-ID: Subject: Re: Dell Latitude 7400 - nvme0: Missing interrupt To: Alexander Motin Cc: Warner Losh , Chuck Tuffli , freebsd-current Content-Type: multipart/mixed; boundary="00000000000054b6a805ce952077" X-Rspamd-Queue-Id: 4HXcJX0mwPz3nHn X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20210112 header.b=L+zdRsd2; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of timp87@gmail.com designates 2a00:1450:4864:20::529 as permitted sender) smtp.mailfrom=timp87@gmail.com X-Spamd-Result: default: False [-1.45 / 15.00]; FREEMAIL_FROM(0.00)[gmail.com]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36]; HAS_ATTACHMENT(0.00)[]; MID_RHS_MATCH_FROMTLD(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.45)[-0.449]; FREEMAIL_TO(0.00)[gmail.com]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:+,3:~,4:~,5:~,6:~,7:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20210112]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[multipart/mixed,multipart/alternative,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[1.000]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::529:from]; RCVD_COUNT_TWO(0.00)[2]; FREEMAIL_CC(0.00)[bsdimp.com,gmail.com,freebsd.org]; RCVD_TLS_ALL(0.00)[] X-ThisMailContainsUnwantedMimeParts: Y --00000000000054b6a805ce952077 Content-Type: multipart/alternative; boundary="00000000000054b6a705ce952075" --00000000000054b6a705ce952075 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable =D0=B2=D1=81, 17 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 11:19, Alexander M= otin : > It may be a noise, but comparing logs I see in reboot case also > "acpi_ec0: not getting interrupts, switched to polled mode". I am > thinking whether the problem may be caused not by SSD, but by some > resource conflict/misconfiguration in the system. Pavel, can you > compare `devinfo -vr` and `lspci -vvvvv` in both cases. looking for any > differences? Are you running the latest BIOS? > > On 12.10.2021 15:56, Warner Losh wrote: > > One piece of data that would be good to have: > > > > nvmecontrol identify nvme0 > > > > There's an optional feature that none of my drives have, but that the > Linux > > driver does oddly > > weird things when enabled. The output of that command will help me > > understand if that may > > be in play. Maybe we need to do oddly weird things too :) > > > > Warner > > > > On Sun, Oct 10, 2021 at 11:00 PM Warner Losh wrote: > > > >> > >> > >> On Sun, Oct 10, 2021 at 10:48 PM Pavel Timofeev > wrote: > >> > >>> =D1=81=D0=B1, 9 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:59, Warner= Losh : > >>> > >>>> > >>>> > >>>> On Sat, Oct 9, 2021, 8:44 AM Pavel Timofeev wrote= : > >>>> > >>>>> > >>>>> > >>>>> =D0=BF=D1=82, 8 =D0=BE=D0=BA=D1=82. 2021 =D0=B3. =D0=B2 14:49, Warn= er Losh : > >>>>> > >>>>>> > >>>>>> > >>>>>> On Fri, Oct 8, 2021 at 2:42 PM Pavel Timofeev > >>>>>> wrote: > >>>>>> > >>>>>>> > >>>>>>> > >>>>>>> =D1=81=D0=B1, 21 =D0=B0=D0=B2=D0=B3. 2021 =D0=B3. =D0=B2 15:22, W= arner Losh : > >>>>>>> > >>>>>>>> > >>>>>>>> > >>>>>>>> On Sat, Aug 21, 2021 at 3:06 PM Pavel Timofeev > >>>>>>>> wrote: > >>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Warner Losh : > >>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> On Fri, Aug 20, 2021 at 10:42 PM Pavel Timofeev < > timp87@gmail.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> Pavel Timofeev : > >>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Chuck Tuffli : > >>>>>>>>>>>> > >>>>>>>>>>>>> On Mon, Aug 16, 2021 at 7:43 PM Pavel Timofeev < > >>>>>>>>>>> timp87@gmail.com> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Hello > >>>>>>>>>>>>>> I've got a Dell Latitude 7400 and tried installing the > latest > >>>>>>>>>>>>> 14.0-CURRENT > >>>>>>>>>>>>>> (main-n248636-d20e9e02db3) on it. > >>>>>>>>>>>>>> Despite other things the weird one which concerns me is > >>>>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>>>> message I get sometimes on the console. > >>>>>>>>>>>>>> It seems like I get it only after the reboot of the laptop= , > >>>>>>>>>>> i. e. not > >>>>>>>>>>>>>> getting that message if I power cycle the laptop, at least= I > >>>>>>>>>>> haven't > >>>>>>>>>>>>> seen > >>>>>>>>>>>>>> them for now in such cases. > >>>>>>>>>>>>>> So when the laptop is rebooted I can't even take advantage > of > >>>>>>>>>>>>>> nvmecontrol(8) quickly. > >>>>>>>>>>>>>> Well, it still works, but it takes tens of seconds to retu= rn > >>>>>>>>>>> the output. > >>>>>>>>>>>>> ... > >>>>>>>>>>>>>> dmesg when power cycled - > >>>>>>>>>>>>>> > >>>>>>>>>>> > https://drive.google.com/file/d/1dB27oB1O2CcnZy6DvOOhmFO8SN8V8SwJ > >>>>>>>>>>>>>> dmesg when rebooted - > >>>>>>>>>>>>>> > >>>>>>>>>>> > https://drive.google.com/file/d/1DsKTMkihp_OmUcirByLaVO4o2mU38Bxh > >>>>>>>>>>>>> > >>>>>>>>>>>>> I'm sort of curious about the time stamps for the log > messages > >>>>>>>>>>> in the > >>>>>>>>>>>>> failing case. Something like: > >>>>>>>>>>>>> > >>>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>>>> > >>>>>>>>>>>>> --chuck > >>>>>>>>>>>>> > >>>>>>>>>>>> > >>>>>>>>>>>> Well, I can't see timestamps in the verbose boot log. Am I > >>>>>>>>>>> missing some > >>>>>>>>>>>> configuration for that? > >>>>>>>>>>>> > >>>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>>> nvme0: mem > >>>>>>>>>>>> > >>>>>>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff at devi= ce > >>>>>>>>>>>> 0.0 on pci6 > >>>>>>>>>>>> nvme0: attempting to allocate 5 MSI-X vectors (17 supported) > >>>>>>>>>>>> nvme0: using IRQs 133-137 for MSI-X > >>>>>>>>>>>> nvme0: CapLo: 0x140103ff: MQES 1023, CQR, TO 20 > >>>>>>>>>>>> nvme0: CapHi: 0x00000030: DSTRD 0, NSSRS, CSS 1, MPSMIN 0, > >>>>>>>>>>> MPSMAX 0 > >>>>>>>>>>>> nvme0: Version: 0x00010300: 1.3 > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvme0: Missing interrupt > >>>>>>>>>>>> nvd0: NVMe namespace > >>>>>>>>>>>> GEOM: new disk nvd0 > >>>>>>>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) > >>>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> > >>>>>>>>>>> Ah, sorry, provided wrong output. > >>>>>>>>>>> Here is what you requested: > >>>>>>>>>>> $ grep "nv\(me\|d\)" /var/log/messages > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: > mem > >>>>>>>>>>> > 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > >>>>>>>>>>> at device > >>>>>>>>>>> 0.0 on pci6 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: attempting to allocat= e > 5 > >>>>>>>>>>> MSI-X > >>>>>>>>>>> vectors (17 supported) > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: using IRQs 133-137 fo= r > >>>>>>>>>>> MSI-X > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapLo: 0x140103ff: MQ= ES > >>>>>>>>>>> 1023, CQR, > >>>>>>>>>>> TO 20 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: CapHi: 0x00000030: > DSTRD > >>>>>>>>>>> 0, NSSRS, > >>>>>>>>>>> CSS 1, MPSMIN 0, MPSMAX 0 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Version: 0x00010300: > 1.3 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: >>>>>>>>>>> 512GB> NVMe > >>>>>>>>>>> namespace > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: GEOM: new disk nvd0 > >>>>>>>>>>> Aug 21 04:34:36 nostromo kernel: nvd0: 488386MB (1000215216 5= 12 > >>>>>>>>>>> byte > >>>>>>>>>>> sectors) > >>>>>>>>>>> Aug 21 04:34:42 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:35:36 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> Aug 21 04:35:50 nostromo kernel: nvme0: Missing interrupt > >>>>>>>>>>> > >>>>>>>>>> > >>>>>>>>>> What happens if you set hw.nvme.use_nvd=3D0 and > >>>>>>>>>> hw.cam.nda.nvd_compat=3D1 > >>>>>>>>>> in the boot loader and reboot? Same thing except nda where nvd > >>>>>>>>>> was? Or does > >>>>>>>>>> it work? > >>>>>>>>>> > >>>>>>>>>> Something weird is going on in the interrupt assignment, I > think, > >>>>>>>>>> but I > >>>>>>>>>> wanted to get any nvd vs nda issues out of the way first. > >>>>>>>>>> > >>>>>>>>>> Warner > >>>>>>>>>> > >>>>>>>>> > >>>>>>>>> Do you mean kern.cam.nda.nvd_compat instead > >>>>>>>>> of hw.cam.nda.nvd_compat? > >>>>>>>>> kern.cam.nda.nvd_compat is 1 by default now. > >>>>>>>>> > >>>>>>>>> So I tried to set hw.nvme.use_nvd to 1 as suggested, but I sti= ll > >>>>>>>>> see > >>>>>>>>> nvme0: Missing interrupt > >>>>>>>>> and now also > >>>>>>>>> Root mount waiting for: CAM > >>>>>>>>> messages besides those > >>>>>>>>> > >>>>>>>> > >>>>>>>> OK. That all makes sense. I'd forgotten that nvd_compat=3D1 by > default > >>>>>>>> these > >>>>>>>> days. > >>>>>>>> > >>>>>>>> I'll take a look on monday starting at the differences in > interrupt > >>>>>>>> assignment that > >>>>>>>> are apparent when you cold boot vs reboot. > >>>>>>>> > >>>>>>>> Thanks for checking... I'd hoped this was a cheap fix, but also > >>>>>>>> didn't really > >>>>>>>> expect it to be. > >>>>>>>> > >>>>>>>> Warner > >>>>>>>> > >>>>>>>> > >>>>>>> I've recently upgraded to main-n249974-17f790f49f5 and it got eve= n > >>>>>>> worse now. > >>>>>>> So clean poweron works as before. > >>>>>>> But if rebooted nvme drive refuses to work, while before the code > >>>>>>> upgrade it was just complaining about missing interrupts. > >>>>>>> > >>>>>>> currently dmesg show this: > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> nvd0: NVMe namespace > >>>>>>> nvd0: 488386MB (1000215216 512 byte sectors) > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> > >>>>>> > >>>>>> Why is this showing up twice? Or is everything above this line lef= t > >>>>>> over from the first, working boot? > >>>>>> > >>>>>> > >>>>>>> nvme0: RECOVERY_START 9585870784 vs 9367036288 > >>>>>>> nvme0: timeout with nothing complete, resetting > >>>>>>> nvme0: Resetting controller due to a timeout. > >>>>>>> nvme0: RECOVERY_WAITING > >>>>>>> nvme0: resetting controller > >>>>>>> nvme0: aborting outstanding admin command > >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > >>>>>>> cdw11:00000000 > >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>>>> nvme0: nvme_identify_controller failed! > >>>>>>> nvme0: waiting > >>>>>>> > >>>>>> > >>>>>> Clearly something bad is going on with the drive here... We looked > >>>>>> into the completion queues when we didn't get an interrupt and > there was > >>>>>> nothing complete there.... > >>>>>> > >>>>>> The only thing I can think of is that this means there's a phase > error > >>>>>> between the drive and the system. I recently removed a second rese= t > and > >>>>>> made it an option NVME_2X_RESET. Can you see if adding > >>>>>> 'options NVME_2X_RESET' to your kernel config fixes this? > >>>>>> > >>>>>> Warner > >>>>>> > >>>>>> > >>>>>>> nvme0: mem > >>>>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff > at device > >>>>>>> 0.0 on pci6 > >>>>>>> nvme0: RECOVERY_START 9362778467 vs 9361830561 > >>>>>>> nvme0: timeout with nothing complete, resetting > >>>>>>> nvme0: Resetting controller due to a timeout. > >>>>>>> nvme0: RECOVERY_WAITING > >>>>>>> nvme0: resetting controller > >>>>>>> nvme0: aborting outstanding admin command > >>>>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > >>>>>>> cdw11:00000000 > >>>>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>>>> nvme0: nvme_identify_controller failed! > >>>>>>> nvme0: waiting > >>>>>>> > >>>>>>> > >>>>> > >>>>> Sorry, it's showing twice due to multiple reboots. For one boot it'= s > >>>>> like: > >>>>> nvme0: mem > >>>>> 0xcc100000-0xcc103fff,0xcc105000-0xcc105fff,0xcc104000-0xcc104fff a= t > device > >>>>> 0.0 on pci6 > >>>>> nvme0: RECOVERY_START 9633303481 vs 9365971423 > >>>>> nvme0: timeout with nothing complete, resetting > >>>>> nvme0: Resetting controller due to a timeout. > >>>>> nvme0: RECOVERY_WAITING > >>>>> nvme0: resetting controller > >>>>> nvme0: aborting outstanding admin command > >>>>> nvme0: IDENTIFY (06) sqid:0 cid:15 nsid:0 cdw10:00000001 > cdw11:00000000 > >>>>> nvme0: ABORTED - BY REQUEST (00/07) sqid:0 cid:15 cdw0:0 > >>>>> nvme0: nvme_identify_controller failed! > >>>>> nvme0: waiting > >>>>> > >>>>> Well, neither Windows not Linux have any problems with the device. = I > >>>>> understand they may be hiding it or workaround somehow. > >>>>> > >>>> > >>>> Yea, I'm trying to figure out why your machine is different than min= e, > >>>> and what Windows or Linux do that is different. It may be dodgy > hardware, > >>>> but others have no trouble... > >>>> > >>>> I'll try setting NVME_2X_RESET in the kernel config and report back > in a > >>>>> while. > >>>>> > >>>> > >>>> Thanks. If it helps, that tells me something. If it doesn't, that > tells > >>>> me something else. > >>>> > >>>> I suspect that it is somewhere else in the system, tbh, but I need t= o > >>>> find it systematically. > >>>> > >>>> Warner > >>>> > >>> > >>> Surprisingly, setting NVME_2X_RESET in the kernel config hasn't chang= ed > >>> anything. I. e it didn't help. > >>> > >> > >> While it would have been nice to have this be the fix, I'm not that > >> surprised either. > >> It was the biggest change of late, apart from the big re-arrangement > that > >> I'd done. > >> > >> So the other changes have moved from the occasional missing interrupt > >> message > >> (which the old code would get when a command wasn't completed in the > >> timeout > >> period, but that we found to be done when we scanned the completion > queue. > >> Now > >> the device is detected fine (as before), but then doesn't do I/O at al= l > >> (including not > >> completing the identify command!) and is worse. This is unexpected and > I'm > >> trying > >> understand what happens on reboot that 'changes'the working state and > why > >> the > >> new code behaves so differently. > >> > >> Warner > >> > > > > -- > Alexander Motin > Thanks for the reply. It's using the latest firmware. This is the first thing I do in such case. Attaching devinfo and lspci output. These are diffs showing the difference between clean boot and a reboot: $ diff -u devinfo.ok devinfo.nok --- devinfo.ok 2021-10-17 17:48:07.964346000 -0600 +++ devinfo.nok 2021-10-17 17:48:07.886881000 -0600 @@ -214,10 +214,6 @@ nvme0 pnpinfo vendor=3D0x1c5c device=3D0x1639 subvendor=3D0x1c= 5c subdevice=3D0x1639 class=3D0x010802 at slot=3D0 function=3D0 dbsf=3Dpci0:59= :0:0 handle=3D\_SB_.PCI0.RP13.PXSX Interrupt request lines: 0x85 - 0x86 - 0x87 - 0x88 - 0x89 pcib7 memory window: 0xcc100000-0xcc103fff 0xcc104000-0xcc104fff $ diff -u lspci.ok lspci.nok --- lspci.ok 2021-10-17 17:48:15.894470000 -0600 +++ lspci.nok 2021-10-17 17:48:15.341379000 -0600 @@ -132,7 +132,7 @@ Flags: PMEClk- DSI+ D1- D2- AuxCurrent=3D0mA PME(D0+,D1-,D2-,D3hot+,D3col= d+) Status: D0 NoSoftRst+ PME-Enable- DSel=3D0 DScale=3D0 PME- Capabilities: [d0] MSI: Enable+ Count=3D1/1 Maskable- 64bit+ - Address: 00000000fee06000 Data: 0033 + Address: 00000000fee06000 Data: 0034 Capabilities: [40] Express (v2) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- FLReset+ --00000000000054b6a705ce952075-- --00000000000054b6a805ce952077--