From owner-freebsd-ppc@freebsd.org Fri Jan 24 13:10:30 2020 Return-Path: Delivered-To: freebsd-ppc@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9A8DE237ABA for ; Fri, 24 Jan 2020 13:10:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from freefall.freebsd.org (freefall.freebsd.org [96.47.72.132]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 483zyt2ZThz40sL for ; Fri, 24 Jan 2020 13:10:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: by freefall.freebsd.org (Postfix) id 4F6001F6C3; Fri, 24 Jan 2020 13:10:30 +0000 (UTC) Delivered-To: powerpc@localmail.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits)) (Client CN "mx1.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by freefall.freebsd.org (Postfix) with ESMTPS id 497DA1F6C1 for ; Fri, 24 Jan 2020 13:10:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic306-20.consmr.mail.gq1.yahoo.com (sonic306-20.consmr.mail.gq1.yahoo.com [98.137.68.83]) (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 483zys28Dzz40sJ for ; Fri, 24 Jan 2020 13:10:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: BY6YE1YVM1kJwDziwUbeLd6tW_fzBQZc8jwyt8FazEBxJ.mfEKIxU9wf9vcKtdg JvTxVNaxBJb3TzfD7FrzQ6xnF1mZLTiJpUmen2a5.cS3cDjGUm3UutREJtjplepcyyPE18UeB_TG VcT4Q1zTu7q5T4hgNxdcTETme_SSMNxRl1RFISR6InP7.A.MOyXOBtUhthDpcZn3_IAV4cUXvBVt oISmpK0EU7rXm.s2b93jaPgJ5ONa2ZEovjXPDKo.d6FkM7ZTN55mHAhPJVuX5CQ2ahQc5TMkwRjc g3s_iiVDLzAX0oR1uxu4iCBHzAvEB.1FntmSFd7sWTFsnahpwHnXef5uXpfNQGMC4bJy4embt8OZ YH2U1GxT.FKPlFtpZMq.dbneOqsKypOIUbEeoedl.GDuEP2RgfPmbvc9Yc0h2LhJ.7px5_ilXde1 w0nh4_sYKOZTbJAHI9R3_hiCmw7gh1C2MwTAIAQqx30GPPx0RPsp1Aw2V7ijOqcOlxQS5onBM9zs W9pVSnLkCF6R6vYZ757yY2ib5xYcfc8zZhfjMUOtI23MTqnGjbvFW_1HCe7PHJOfyfzXNuRBZ4lA Zk_odEkS9k6.FMp_ekkduXuSM821Q_qEtewVYlX37SVy1qd7pxuh0Tafi0i_7SWjlSwpSE9W.i5w mwZcoBoQecd_2jI_ZcU.BaFy2MHm1YWEASjQiV589Du6As6m0RU2p3ndUMxbaf1bQFioUbYloo1w bFhnKssZ.YrHeXn6yjBQRG3zPew6ihJyBbWbcTVcbJ.quIXDLo8s1u3iNpeVKac.MMEHebnHohHn k5ntyGfxG_yPGVZNb1eWie9y1wsHbKnLPYVTs7EV7v02dbYt3uiMZpGDqZjs0Ttz0u7RK1xJtYAb BFsz48L5FT.Kr3Y49RhIDKHxVA_o8uRLaRSgzJKAz_rFvFtklJsgvFDqmUDpN5d_Hw3ozoBKO5jL 5.34qOVn4uCyCNWH4DGkUqokW4ZwP4g7tLnsnAUixwPwwwxsAVhkRZLEFEtYTLT3OmJk7czgXlvu Pb.TeQt1vcMNTlMlgpSB4X1Qcq2GtT.GP0pdsBSztDGMcoyOVCNDfKojNAk74jq7n36Ztd9MHWG6 oKerHekIHSJiaed38dBNXkaWYjjgRuv98OwB_Hiw6FDSq_ahZgOWjpHriLVFWxfbiwjD0LOJB2Ua epMWj.pvLSJ5.xLBbCPU.UeQLg5g9qgNNU7mHGjH7Nbmm6m9shkE._wLd3A7ZyAWd4q5smxfpS1U idlSIuhzOzYB138yNuLb1S4A4bGfiU4Q17EdzFlrv8vfYD63dg4Kjssvo_Uk8IQIOOfPdgnJsW46 SDlSNNiR.Di.tzm8TP7MAR8zRSucF5Oni4p1lLRvL2XURfOsg.4J9adeFPqJOCTV4vpIGmtFhXzY yUKjEeh4S9ptZ5YlIoBcp41JJvNOkLVo2ors- Received: from sonic.gate.mail.ne1.yahoo.com by sonic306.consmr.mail.gq1.yahoo.com with HTTP; Fri, 24 Jan 2020 13:10:27 +0000 Received: by smtp415.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8acac524e373b63a8b07709a20556e50; Fri, 24 Jan 2020 13:10:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\)) Subject: Re: panic: data storage interrupt trap when building world on PowerMac G5 From: Mark Millard In-Reply-To: Date: Fri, 24 Jan 2020 05:10:22 -0800 Cc: Michael Tuexen , "powerpc@freebsd.org" , Justin Hibbits Content-Transfer-Encoding: 7bit Message-Id: <3F27CA51-8DC9-43C8-A2AB-63F055641276@yahoo.com> References: <7722F637-2C3D-4199-B2C9-F0616B0A5AE1@freebsd.org> <20200123134114.75d9c771@titan.knownspace> <4652291B-6D2B-4D21-9F01-576913DF0B54@macmic.franken.de> To: Francis Little X-Mailer: Apple Mail (2.3608.40.2.2.4) X-Rspamd-Queue-Id: 483zys28Dzz40sJ X-Spamd-Bar: / X-Spamd-Result: default: False [-0.74 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ptr:yahoo.com]; FREEMAIL_FROM(0.00)[yahoo.com]; MV_CASE(0.50)[]; DKIM_TRACE(0.00)[yahoo.com:+]; DMARC_POLICY_ALLOW(-0.50)[yahoo.com,reject]; FROM_EQ_ENVFROM(0.00)[]; RCVD_TLS_LAST(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[yahoo.com]; ASN(0.00)[asn:36647, ipnet:98.137.64.0/21, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[yahoo.com.dwl.dnswl.org : 127.0.5.0]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.59)[-0.586,0]; R_DKIM_ALLOW(-0.20)[yahoo.com:s=s2048]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; MIME_GOOD(-0.10)[text/plain]; IP_SCORE(0.00)[ip: (3.16), ipnet: 98.137.64.0/21(0.85), asn: 36647(0.68), country: US(-0.05)]; IP_SCORE_FREEMAIL(0.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(0.35)[0.346,0]; RCVD_IN_DNSWL_NONE(0.00)[83.68.137.98.list.dnswl.org : 127.0.5.0]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-ppc@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Porting FreeBSD to the PowerPC List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 24 Jan 2020 13:10:30 -0000 On 2020-Jan-24, at 04:27, Francis Little wrote: > I'm not getting panics, I get similar errors to this: > > cc: error: unable to execute command: Abort trap (core dumped) > cc: error: clang frontend command failed due to signal (use -v to see > invocation) > FreeBSD clang version 9.0.1 (git@github.com:llvm/llvm-project.git > c1a0a213378a458fbea1a5c77b315c7dce08fd05) (based on LLVM 9.0.1) > Target: powerpc64-unknown-freebsd13.0 > Thread model: posix > InstalledDir: /usr/bin > cc: note: diagnostic msg: PLEASE submit a bug report to > https://bugs.freebsd.org/submit/ and include the crash backtrace, > preprocessed source, and associated run script. > cc: note: diagnostic msg: > ******************** > > PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: > Preprocessed source(s) and associated run script(s) are located at: > cc: note: diagnostic msg: /tmp/addsf3-67691f.c > cc: note: diagnostic msg: /tmp/addsf3-67691f.sh > cc: note: diagnostic msg: > > ******************** > *** [addsf3.o] Error code 254 > > make[4]: stopped in /usr/src/lib/libcompiler_rt > 1 error > > make[4]: stopped in /usr/src/lib/libcompiler_rt > *** [lib/libcompiler_rt__PL] Error code 2 > > make[3]: stopped in /usr/src > 1 error > > make[3]: stopped in /usr/src > *** [libraries] Error code 2 > > make[2]: stopped in /usr/src > 1 error > > make[2]: stopped in /usr/src > *** [_libraries] Error code 2 > > make[1]: stopped in /usr/src > 1 error > > make[1]: stopped in /usr/src > *** [buildworld] Error code 2 > > make: stopped in /usr/src > > make: stopped in /usr/src Is the console ( or dmesg or /var/log/messages ) showing the likes of: pid . . . , jid 0, uid 0, was killed: out of swap space ? If yes, then is it also showing the likes of: . . . sentinel kernel: swap_pager_getswapspace(32): failed If it shows both then you likely really are low on swap/paging space. (The first message's wording is a misnomer.) If it only shows the first, then you are not likely to actually be low on swap/paging space. But FreeBSD does such kills for the free RAM just staying too low for too many tries at increasing it. On small arm boards folks have this problem with buildworld a lot during its llvm related build activity. How much RAM is there? Building with a smaller -jN can help avoid such issues. But there may be alternatives. The below notes may or may not prove useful for your FreeBSD head-based context. For delaying how long free RAM staying low is tolerated, one can increase vm.pageout_oom_seq from 12 to larger. The management of slow paging I've less experience with but do have some notes about below. Examples follow that I use in contexts with sufficient RAM that I do not have to worry about out of swap/page space. These I've set in /etc/sysctl.conf . (Of course, I'm not trying to deliberately run out of RAM.) # # Delay when persisstent low free RAM leads to # Out Of Memory killing of processes: vm.pageout_oom_seq=120 (I'll note that figures like 1024 or 1200 or even more are possible. This is controlling how many tries at regaining sufficient free RAM that that level would be tolerated long-term. After that it starts Out Of Memory kills to get some free RAM.) # # For plunty of swap/paging space (will not # run out), avoid pageout delays leading to # Out Of Memory killing of processes: vm.pfault_oom_attempts=-1 (Note: In my context "plunty" really means sufficient RAM that paging is rare. But others have reported on using the -1 in contexts where paging was heavy at times and OOM kills had been happening that were eliminated by the assignment.) I've no experience with the below alternative to that -1 use: # # For possibly insufficient swap/paging space # (might run out), increase the pageout delay # that leads to Out Of Memory killing of # processes: #vm.pfault_oom_attempts= ??? #vm.pfault_oom_wait= ??? # (The multiplication is the total but there # are other potential tradoffs in the factors # multiplied, even for nearly the same total.) I'm not claiming that these 3 vm.???_oom_??? figures are always sufficient. Nor am I claiming that tunables are always available that would be sufficient. Nor that it is easy to find the ones that do exist that might help for specific OOM kill issues. I have seen reports of OOM kills for other reasons when both vm.pageout_oom_seq and vm.pfault_oom_attempts=-1 were in use. As I understand, FreeBSD did not report what kind of condition lead to the decision to do an OOM kill. (I do not remember the vm.pageout_oom_seq figures from those reports but no figure is designed to make the delay unbounded. There may be large enough figures to effectively be bounded beyond any reasonable time to wait for an oom.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)