From nobody Tue Jun 27 16:47:12 2023 X-Original-To: freebsd-arm@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 4Qr9cN0npRz4kXLD for ; Tue, 27 Jun 2023 16:47:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-24.consmr.mail.gq1.yahoo.com (sonic303-24.consmr.mail.gq1.yahoo.com [98.137.64.205]) (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 did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 4Qr9cM5Pwhz4MbX for ; Tue, 27 Jun 2023 16:47:31 +0000 (UTC) (envelope-from marklmi@yahoo.com) Authentication-Results: mx1.freebsd.org; none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687884449; bh=igKu9cQKhjqWjWBz3UMXf+dBC4pFY8/YZWUcSGoQQFE=; h=Subject:From:In-Reply-To:Date:Cc:References:To:From:Subject:Reply-To; b=ULACcVHoo0y3GVmok0l+Ehkhy2tw5lh5a3xQqTasVbmVm4ShcRV5TBkfqgv9gt+gFJonxTpp7uZE01xmtvL3eJN7MX9vn+ifNLXRZ5uLzBh6QmHEHq2OuzJzQTmctIYVL2dNbG5YES5h6rCoxvyhRmgJflY3xQ5c1CS/YDFlexgbo4tvHIIxejEkYiAjcTyvMrL618ecyH1+e3QW7tsRbOFyc6Yt6J0P5+/T6VeMUfEoIcuzHJLMLMODdSenZt1N9syxivACkOdYTjqqGV/XKeM2WmWQXNZpUo+i7JgEmLlggKEf6IFTXlA382gDk1HPEyjiP4NvfTHSLM338+l/xw== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1687884449; bh=0Lh6Ad3VsowgX9YR1HMI7zpt3uiUdV699ArqnwCkUu5=; h=X-Sonic-MF:Subject:From:Date:To:From:Subject; b=oj14t/7CABL1ZC2rc6XmmvzXfYnvpT/AVbj8CqEdJnxGLLMBYiZWYxR/hEx+YJ3g73FKbPwGDGZQc88SCBtdnmor4bJFAva1d5t0/9qNQzg/QPA2ewMRn7pKH8N+jkcKeq50cV1aiiKlrboJnDdSVqt1VSViu5i0kw6Nbcf1RXf1ICMQDAFyzcvFd5yMNJf0L6Dg2d3mms5yUiZf5CprA5anZiEDimbZpAnu2PAayVw8R9kVkgVQECJo2rUHsxAQDYum6cW44zHG0wo7Oly/4T9TdiNs8bhe0KzEm6XcJmQBmpSBZeOUxIutk8/XFoByvR6QYsw6ZnAM9kEMnEXMPw== X-YMail-OSG: xXfKZYYVM1knkklmFIqwEYaj7.jQYDmqFEzg02P1cFwkpSG2JTkVo8WQAeuvN2W nBeV34tLC1BRQdq4EuZKqadFZV3y0Tmm5FyvcV19y2YW4WYI8pvPhir4VVvryW07soxMrXOUkkCX 9GrFYlI7aBMU_6g3iL_OqK92qYNl5hcIEMW57ow0WhQHthK0Pf6X7dE_dgYYuWgnndcR4kBg4KRx EuA4e2PxTG61At2fcyx0yqBvUxPZ0LJpj5tsy3Az_Slp7D2O9H6AXKryvmiqogDoINMlpLz6FPP6 WqLMz5jGXZUTi.BJPAC1UutX9k99AiDcyU9231iu28BCIuXcznBnM.JyTnSpLCUBQEBMaJ.GaoZe sBDQlbMe6tW6bUMcdsXwiduazR5AMkz5YAkdKUdxdGC3Lz4Bnsv_Bi6evtgnRdYdabgAVq8PrUc_ 2psTa8ELoRriK2EgXb_jBevlrp2glzW0W52mW84RXiSabUo4fiH9Nla1KlBJqhvK99W3aQDTNiNN oEWG8G4ROJ2C9TVaW92VA2JzABnN.50vSNBgmkJUb0nEzuOF_U.pIUOeSy7Gj34MZZ45wSFk7zvh 12Ck9HM1XJGg2g1wwbrJKG3HRRZBK4cQObRv9Xo2tRNgVp3YGuwVjbCpwFSb1t8PV.HixPNXg9xc vsYqD2VVbLa3Rfva7D68KaTbDRCV2No9GYN79t7oX8tYX4EmqdBWLa6c0PqD6jAB5Gs6bRfQUPcX O2WA9c8NNxbjCTjop7X88.5pB23wEdkI.fJmiXlEl8vqTz81MRjWzaxCcJk7L.9FLHXLpOaekIUi tR80mq5hA2ZWHRpN6CkS_ix50Z4MqNNME52g7jyQZeGPOSqOAIyz2NqLajNBxPDeXVL_aKLBWdIe orPRHK2255TTArdXjPwcgaVWRobvUtgUrC4h9vrNjD5xL7vsahgsUQCzye3_u5j.eUTGrY9Mez8o xI3MpU8dS6LCebqmLCUlWo_JkVvBKyvCDjtoYCpcqLxR_AryU96WbZK_hGC5zE7w0VuKpXZ_uO_K h8opcHvSoZEytO0V8JJQxyeZiZXAbXUSpQViPR90UOTT936zDTNg8Rb6G3FccpBdXoxhFpryh3.k neMG1qzplOWhdYVYbQtgrq.sf.rsOQEpHj_cb1HZJVCtGZt6PeC4D7sAPQoMzz9JUF0F7tupx1kg H_UGnprQEZgv2AB8gLy7HqkJO29ilRWDrU_TNJzyouJssYEHDUYQaeLGKT7aXXA3nzm_BcEc7MlX QpNLwfEHbBY9SXK9tSfC5hxOF8ZJpMI5rFLJ5LxJ.HovkejwShIWjbSOe0Gl.4Qb8BbkTVNyaNGC u.tyYTuBWhEJ9GbaZDfwAzG7b9X8hXnvq_ZL72F6XwJ3CPJaKbOAXAhOvZDbcyuTaRXGjV2amgAU EIheFSRn_NMb.QYOi5NB4DcuZnjlA_Lv.xzM3GJsrtTT2r74fKclmXy5amQssKBHnIoaLdctQaZc ihMaOxAs51ID0uL0YJq24tkezH9QNuOCDd7KTpUIylTomhN5i2bChZ2FDa6NWV.WFIaBFl2JvQTz AsyqYEs36jYn.KXCsKDo.B32h042ngxXEEb4jyzEdLb9uplfyg42DeAskj6LvCdytNBQUQwcD7M2 HgWvU28DF0Gjlmmoa61pag1j.uNrL_.HKoV.7xwAY0lxU26zRftP1U3U89rWQdP31nJVWznV6vTn GUWQkJ07kppDmhdks8.Sa6HWXeMeExX.Px1D9ZReOLjShJoNb2Vvym3wmkUXbLN_1.46Hofd_xH5 gTxbbi_.P9Qbn9ddcbQMO53kjgURanJEAHyOuQ4o96MxtDHmJ_gU9HnIjKvtQdPLkn0A8OaIr_ku 10AWBsYpBy.TU3RFK2NRiq.UV5Za4JNgW.T0xDRMFgKM0m5vmHR7NFGDa6h8RP0isnUmmilQ.Ocj oJjEEg54hhNehEVHV3_X4Vke3OEGBiCZTtghFyGqy6bZ0SS_6e2PEzBiNyRdOPw1qB.UAXdD7hcq 2Kafcg1fqQqaKvjmhbmotM65y8D_S.7.844uhUpC0hGMtjH.PiRsbrW.a5Hy69XLg3ovcJUbJnY2 1l2tyIFJTne8_Sb1Y_Vada7XzLKrHAVnOu2XtchEJc0nsMSrbrgpVJ7kq6Nqv3g0MZx46esLCO3A oSzSQ5ISniYHMFq_Uj_GrwsS2hxJ5Hz4zvOyC2trKI5H0WBwGBMZL39Rzrbc.kDiTImjMmVIsBPq cY5HfGR_fP7GGyb9AX9CPNRkI1K_J9rUnJe.Qkd6sZ1pfcLdLkcrdhPgKqmSvkOSvpvNSNP9Mlz6 B X-Sonic-MF: X-Sonic-ID: de64ebfd-270e-4549-992e-1d20dcf9b8f1 Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.gq1.yahoo.com with HTTP; Tue, 27 Jun 2023 16:47:29 +0000 Received: by hermes--production-ne1-7f4ff455bb-kwpfb (Yahoo Inc. Hermes SMTP Server) with ESMTPA ID d0c3128cc2fbefb65301d1d527e97a6d; Tue, 27 Jun 2023 16:47:27 +0000 (UTC) Content-Type: text/plain; charset=us-ascii List-Id: Porting FreeBSD to ARM processors List-Archive: https://lists.freebsd.org/archives/freebsd-arm List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-arm@freebsd.org Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Subject: Re: -current on armv7 stuck with flashing disk light From: Mark Millard In-Reply-To: Date: Tue, 27 Jun 2023 09:47:12 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: References: To: bob prohaska X-Mailer: Apple Mail (2.3731.600.7) X-Rspamd-Queue-Id: 4Qr9cM5Pwhz4MbX X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/20, country:US] X-Rspamd-Pre-Result: action=no action; module=replies; Message is reply to one we originated X-ThisMailContainsUnwantedMimeParts: N On Jun 27, 2023, at 09:29, bob prohaska wrote: > On Mon, Jun 26, 2023 at 07:57:05PM -0700, Mark Millard wrote: >> On Jun 26, 2023, at 19:12, bob prohaska wrote: >> >>> A Pi2 freshly updated to >>> FreeBSD 14.0-CURRENT #41 main-c3e58ace31: Mon Jun 26 17:06:01 PDT 2023 >>> bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm >>> got stuck with a flashing USB disk LED after starting a -j3 buildworld. >>> No response to debugger escape, had to pull the plug. I'm confused. That says "stuck with a flashing USB disk LED". But: http://nemesis.zefox.com/~bob/fbsd/rpi2/20230623/readme says: "the disk had gone to sleep mode. Both LEDs were off" Are these two different examples with variable behavior across the examples? >> If I understand right, the LED flashing means the disk >> had not stopped doing I/O: the system was still running, >> doing disk activity. (But I do not have a description >> of what your drive documentation says about how the >> drive handles the LED and what various patterns/colors >> may mean.) >> >> If the processes associated with processing input that >> would identify the debugger escape had the kernel stacks >> involved swapped out to swap space, I doubt that the >> debugger escape would work until/unless the kernel >> stacks are brought back into kernel RAM. >> >> Avoiding the specific way of losing control is why I >> have in /etc/sysctl.conf : >> >> # >> # Together this pair avoids swapping out the process kernel stacks. >> # This avoids processes for interacting with the system from being >> # hung-up by such. >> vm.swap_enabled=0 >> vm.swap_idle_enabled=0 >> > > This combination was tried and didn't seem to have any consistent > effect. It's commented out at the moment. By not having them, we have no way to know if the relevant kernel stacks had been moved to swap space. Having them is part of problem isolation/identification even when other forms of loss of control happen. The 2 lines serve more than one goal. >> (No claim such is the only way to lose control.) >> >> You might be able to get a clue if their was disk I/O going >> on based on modification times on files you know would have >> been modified periodically for some time (minutes) before >> you pulled the plug --but not modified on reboot and later >> activity. May be a log file that would only be modified by >> the build that you had been trying to do? >> > > There are log files for build and disk activity (for a cold > hang, no disk activity at all) at > http://nemesis.zefox.com/~bob/fbsd/rpi2/20230623/ So this is a different hangup? > In this case the top window was via ssh. Lately I've > taken to running top on the serial console in hopes > that will help distinguish system hangs from USB hangs. If you want to identify system hangs, please put back: vm.swap_enabled=0 vm.swap_idle_enabled=0 otherwise all you may be seeing is the relevant kernel stacks having been moved to swap space. That is not a form of system hang relative to overall activity, leaving more uncertainty about what top no longer displaying updates implies. You can use sysctl to adjust the live context as well. > >> (You did not indicate how long you let it run with the >> status "possibly hung up".) >> > IIRC it was about half an hour. It was already stuck, so I > don't know the actual time No logs or other files with modification times that might indicate if there was activity during that around 0.5 hr? (Timestamps in files can also serve.) >>> Reboot with kernel.old, >>> FreeBSD 14.0-CURRENT #40 main-c1cbabe8ae: Tue Jun 20 03:58:47 PDT 2023 >>> bob@www.zefox.com:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm >>> seems ok, I'll try to run buildworld with that. > > The kernel.old -j3 buildworld is still running, no complaints so far. > If it succeeds I'll experiment with usbtop. === Mark Millard marklmi at yahoo.com