From owner-freebsd-arm@freebsd.org Sun Jun 17 00:00:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D687100307E for ; Sun, 17 Jun 2018 00:00:54 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D020074C28 for ; Sun, 17 Jun 2018 00:00:53 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5H010HL046581 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 16 Jun 2018 17:01:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5H010CB046580; Sat, 16 Jun 2018 17:01:00 -0700 (PDT) (envelope-from fbsd) Date: Sat, 16 Jun 2018 17:01:00 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180617000100.GA46435@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 00:00:54 -0000 On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Sat Jun 16 19:12:22 UTC 2018 (some by reference > to other web pages, which is what I quote from > here) : > > > Presently, the divided swap layout fails during -j4 buildworld with > > "out of swap" kills during the more frantic portions of buildworld. > > > > When all swap is placed on a single 3 GB USB mechanical disk partition > > the "out of swap" errors go away. Similarly, when swap is placed entirely > > on the microSD card in two partitions, one the original 1 GB partition > > plus a second 2 GB partition, the "out of swap" errors dissapear. > > Since the "multiple swap partitions across multiple > devices" context (my description) is what has problems, > it would be interesting to see swapinfo information > from around the time frame of the failures: how much is > used vs. available on each swap partition? Is only one > being (significantly) used? The small one (1 GiByte)? > > A related, additional example to try? . . . > > Since you report needing around 1.2 GiByte of swap, what > happens if you have a split but both devices have, say, > 1.5 GiByte of swap space for the partition used? If I read > right, you could shrink the 2GiByte microSD card partition > and the 3 GiByte USB mechanical disk partition and then use > that pair as a test. (This also avoids the message about > having too much swap. Also, I'm avoiding having significant > size differences between the partitions used.) Technically, > without the split, either partition should be sufficient > without the other involved. In such a context, does the > split still fail? Or does it only fail when one partition > is too small to be sufficient by itself? > Thus far I think OOM kills have been happening long before either partition fills, but it'll take better logging than I have set up now to be sure. Is there a simple way to log recurrent swap measurements to a file? Swapinfo doesn't seem to have the right options. It would be particularly convenient if the swap usage info could be appended to the gstat log file. At one point I tried top -n -d all | grep Swap >> gstat.log (I'm using tcsh) but nothing was added to gstat.log and since there was no interest in swap usage totals I gave up. > These suggestions are going a different direction than the > I/O rate investigation but also having I/O rate information > would not hurt. But I/O rate information can not substitute > for the swapinfo output here. Nor can top cover what I'd be > looking for: per partition usage figures are required, not > just grand total swap-space usage. > > If you can suggest commands I'll gladly try them. As this little fiasco is playing out, it looks like the lesson for me is don't attempt to interleave swap. Old ideas die slow, but they do die... Thanks for reading, and all your help! bob prohaska From owner-freebsd-arm@freebsd.org Sun Jun 17 03:38:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 11A2B100C021 for ; Sun, 17 Jun 2018 03:38:13 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-20.consmr.mail.ne1.yahoo.com (sonic302-20.consmr.mail.ne1.yahoo.com [66.163.186.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 A39BC7D868 for ; Sun, 17 Jun 2018 03:38:12 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: xnRLCrYVM1lvOLB4b050qUfR3ML9cImsZPZxVb_yMw1Rl6w2809udfLrXguSZ2A loQJcLQIM9aJtWIlK2olcBq.7Tt3hO.U59bCrb2ERl5YwCALQOa2vtpe6UQRDIjzf0UBCuqk2BSc 8T.2xPeXqXkKGVmJR0E0pydOh54.HI171R8TscMekxOhlffYXmF73Un4q8YKJ6Px2X8btnJRibbE O3xSOO7ZywdmK3H.g0QyyccUAJQ1Hi3KRJbi4dFgVJ6mv829KGqim2VzmRQC6FqKWHfv08gtP44Q _k9Zka9BunwPzdIM54IWj_sa9jDU5C_MDGnR0kP.BbFaIsdNvoGHBavRIatSN7JKSFk2Trm3S68s MhyaZgb1LwMnqOz88SLFeZcl1j.86WXDyqPsUaZ4Tvvu37tbxhSnBAJ0dEhJaOOjaG9r9L_4idIn axKrAmx1b0xPSj0FALMLRxNnDwl3FcHc2l7M4sVqnWW.Cu0lQCrBbq05u9RxCOitm3HYIxyRb76B lhOqCw1eh3JlNs3VecZmmZsiYzADqKfzBrIW93sF5mXsjzvEseJj5IB0qisoYEDdGuR_Cfo8zS2V CPOjOkvX3AsmSNF6ddLBzTO0APuP.2h4oi7nzzQz0Ud97RcTsg6ge2DF2ykYBeLPy9duiN6jbsUZ 0fqQgFBuRXbC5obYCEWUaoGMU.eymKWYjqfJbIX9zB5UBvtZUWOyIXhBoJei1VTdC9xLsElt9nrZ VOV8WfrP2Ieur1j7kVT3qPZ7TLZ3ldFIpkCUonNupR0OSxDSYti429Ijt96UHua3jnBEKPeFQbYx n8K0Bt6YVmcXSkgsvQ02Ae0ikvbP3ieRF_3xTZ6_.Xe8InxLmcyN5hLEqK3LHVJXG4b2A0izQnm7 yxRCfuneQNAe2ZIb91b9eUfcxyLxhvYc2uECJ._NswUL_YJwE62D_OXHSvQZ0i3DWlU3fi7zMD9o Q.o0- Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Sun, 17 Jun 2018 03:38:06 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp430.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID d93539a8b278c4f1a089533e26a170ec; Sun, 17 Jun 2018 03:38:03 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180617000100.GA46435@www.zefox.net> Date: Sat, 16 Jun 2018 20:38:02 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180617000100.GA46435@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 03:38:13 -0000 On 2018-Jun-16, at 5:01 PM, bob prohaska wrote: > On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >> bob prohaska fbsd at www.zefox.net wrote on >> Sat Jun 16 19:12:22 UTC 2018 (some by reference >> to other web pages, which is what I quote from >> here) : >>=20 >>> Presently, the divided swap layout fails during -j4 buildworld with >>> "out of swap" kills during the more frantic portions of buildworld. >>>=20 >>> When all swap is placed on a single 3 GB USB mechanical disk = partition >>> the "out of swap" errors go away. Similarly, when swap is placed = entirely >>> on the microSD card in two partitions, one the original 1 GB = partition=20 >>> plus a second 2 GB partition, the "out of swap" errors dissapear. >>=20 >> Since the "multiple swap partitions across multiple >> devices" context (my description) is what has problems, >> it would be interesting to see swapinfo information >> from around the time frame of the failures: how much is >> used vs. available on each swap partition? Is only one >> being (significantly) used? The small one (1 GiByte)? >>=20 >> A related, additional example to try? . . . >>=20 >> Since you report needing around 1.2 GiByte of swap, what >> happens if you have a split but both devices have, say, >> 1.5 GiByte of swap space for the partition used? If I read >> right, you could shrink the 2GiByte microSD card partition >> and the 3 GiByte USB mechanical disk partition and then use >> that pair as a test. (This also avoids the message about >> having too much swap. Also, I'm avoiding having significant >> size differences between the partitions used.) Technically, >> without the split, either partition should be sufficient >> without the other involved. In such a context, does the >> split still fail? Or does it only fail when one partition >> is too small to be sufficient by itself? >>=20 > Thus far I think OOM kills have been happening long before either > partition fills, but it'll take better logging than I have > set up now to be sure.=20 >=20 > Is there a simple way to log recurrent swap measurements to > a file? Swapinfo doesn't seem to have the right options. > It would be particularly convenient if the swap usage info > could be appended to the gstat log file. At one point I tried > top -n -d all | grep Swap >> gstat.log (I'm using tcsh) > but nothing was added to gstat.log and since there was no > interest in swap usage totals I gave up. >=20 >=20 >> These suggestions are going a different direction than the >> I/O rate investigation but also having I/O rate information >> would not hurt. But I/O rate information can not substitute >> for the swapinfo output here. Nor can top cover what I'd be >> looking for: per partition usage figures are required, not >> just grand total swap-space usage. >>=20 >>=20 > If you can suggest commands I'll gladly try them. As this little > fiasco is playing out, it looks like the lesson for me is don't > attempt to interleave swap. Old ideas die slow, but they do die... >=20 > Thanks for reading, and all your help! My notes will be for a context with: # echo $SHELL /bin/sh Initially I'll show just: # while true = = do swapinfo ; sleep 5 = = = done Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% ^C You could, of course, specify a different sleep time (in seconds). As for logging to a file, that is just some additional command line text: # while true = = do swapinfo ; sleep 5 = = = done > mmjnk.txt ^C FBSDUSSD# more mmjnk.txt Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Multiple processes writing to the same file in an uncoordinated manner need not produce nice lines with the text from just one program on each line. For now I do not intend to try to handle such issues and only give the above "just swapinfo" information logging in a specific file. But it is possible to get timestamps in the log file: # while true = = do date ; swapinfo ; sleep = 5 = = done > mmjnk.txt ^C FBSDUSSD# more mmjnk.txt = = Sat Jun 16 = 20:35:11 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Sat Jun 16 20:35:16 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Sat Jun 16 20:35:21 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% Of course the time here is "computer local" if it has not been set to track some standard. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Jun 17 05:51:03 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 728BA100F10A for ; Sun, 17 Jun 2018 05:51:03 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-20.consmr.mail.ne1.yahoo.com (sonic305-20.consmr.mail.ne1.yahoo.com [66.163.185.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 09E2380AEF for ; Sun, 17 Jun 2018 05:51:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: tNMbIlsVM1k1SPTcczNIQvADQayqt66QZuS8lJy32GJLgC1is_5jzkPnj8.w3Go HE4c04LUK4HTUEGkgHwPlalZSfnYsQasMcGjmSTYTVjEv.h7AgN3S3mGLLlJGlc2BI3LyU9uFgo0 IyczXlsTO8nphlaB7ewD7uNL1y16InOyBV5HWFxbqetwtMQPNltxFU4sYk1i8vPC5c7kW1tzim0D Kxuv5m2z2GxhzWSsP1NSTMeH7BwPjGeWgEW2HGx6MzWQm3EQnSiGj4EV0vi_7KcvJpGZxXz3fagD auVAdXrHKL6zpyAWrd3_IRIkYMSjPtDiexAi6DQ7N9LLvWNQMfTndzdh54xSQhSyUXSQaFWK8SWa eLJMyiMHGb2faH.S5jlZ1vRTKE5UMT1PuVTnaUZ2G7rovaXTO19qUzi0woKWoGVio.RWYpRjSlTk wFJ7l1aekqgGDEWVSdfk1QAjvlEvoRKP9K9IobhyF.LNA8X1j__WVikxolicfL5wgdbm0YUzKR1k ElauPRyHiPF9toVPuf88YBWrJtAd8bzdX7kcJGY4SXIgZYpeBm6bW7miPguBxSaWx.MhwP3SQAKq _dGqidAkVHTw4iZnx42JeOEMbMyA0ctIGNJTvAAUw2o0ZZsut86ntMp8Rq67_igiwU2M6rByBKwZ ipTmdRHCoioMYZZz2P9ZdcCizP4EiTfvwKajvN5xxOQC4XrPx4acz4fZYEh4ZV63t0zx00gP2XvY YDwsn9ZMgi2SxfMg3YvA5UxjqirHglKfeF_OYmSCxLVzSMFW4QGoZzS6NF.Y3IJm.wDd4.lUw3b. EdxPYSn7lHMbGZFhJjp5W5Vr0wMzompk_3AjVITWfJUEseiZF3MTzIlj8B8oEStnnOSfs3wY7W2M acc33o729kptGyTLHStKrYuZaPyku0NqxWOhLbLdQCO069mfjeDQ8nvQnfLyD2hztmgaq0fQTJxI WyzSgQWBm Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Sun, 17 Jun 2018 05:50:54 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp403.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9542fe526f3233e10b9107a3250cb7d6; Sun, 17 Jun 2018 05:50:51 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: Date: Sat, 16 Jun 2018 22:50:49 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <01510328-41E4-4A66-A12D-02DBA418A66B@yahoo.com> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180617000100.GA46435@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 05:51:03 -0000 On 2018-Jun-16, at 8:38 PM, Mark Millard wrote: > On 2018-Jun-16, at 5:01 PM, bob prohaska = wrote: >=20 >> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>> bob prohaska fbsd at www.zefox.net wrote on >>> Sat Jun 16 19:12:22 UTC 2018 (some by reference >>> to other web pages, which is what I quote from >>> here) : >>>=20 >>>> Presently, the divided swap layout fails during -j4 buildworld with >>>> "out of swap" kills during the more frantic portions of buildworld. >>>>=20 >>>> When all swap is placed on a single 3 GB USB mechanical disk = partition >>>> the "out of swap" errors go away. Similarly, when swap is placed = entirely >>>> on the microSD card in two partitions, one the original 1 GB = partition=20 >>>> plus a second 2 GB partition, the "out of swap" errors dissapear. >>>=20 >>> Since the "multiple swap partitions across multiple >>> devices" context (my description) is what has problems, >>> it would be interesting to see swapinfo information >>> from around the time frame of the failures: how much is >>> used vs. available on each swap partition? Is only one >>> being (significantly) used? The small one (1 GiByte)? >>>=20 >>> A related, additional example to try? . . . >>>=20 >>> Since you report needing around 1.2 GiByte of swap, what >>> happens if you have a split but both devices have, say, >>> 1.5 GiByte of swap space for the partition used? If I read >>> right, you could shrink the 2GiByte microSD card partition >>> and the 3 GiByte USB mechanical disk partition and then use >>> that pair as a test. (This also avoids the message about >>> having too much swap. Also, I'm avoiding having significant >>> size differences between the partitions used.) Technically, >>> without the split, either partition should be sufficient >>> without the other involved. In such a context, does the >>> split still fail? Or does it only fail when one partition >>> is too small to be sufficient by itself? >>>=20 >> Thus far I think OOM kills have been happening long before either >> partition fills, but it'll take better logging than I have >> set up now to be sure.=20 >>=20 >> Is there a simple way to log recurrent swap measurements to >> a file? Swapinfo doesn't seem to have the right options. >> It would be particularly convenient if the swap usage info >> could be appended to the gstat log file. At one point I tried >> top -n -d all | grep Swap >> gstat.log (I'm using tcsh) >> but nothing was added to gstat.log and since there was no >> interest in swap usage totals I gave up. >>=20 >>=20 >>> These suggestions are going a different direction than the >>> I/O rate investigation but also having I/O rate information >>> would not hurt. But I/O rate information can not substitute >>> for the swapinfo output here. Nor can top cover what I'd be >>> looking for: per partition usage figures are required, not >>> just grand total swap-space usage. >>>=20 >>>=20 >> If you can suggest commands I'll gladly try them. As this little >> fiasco is playing out, it looks like the lesson for me is don't >> attempt to interleave swap. Old ideas die slow, but they do die... >>=20 >> Thanks for reading, and all your help! >=20 > My notes will be for a context with: >=20 > # echo $SHELL > /bin/sh >=20 > Initially I'll show just: Well, looks like the notation I used did not go through to the lists well (missing text in what it is displaying to me viewed from . . ./2018-June/018046.html. Hopefully it made it to Bob P. okay. I'll try to add alternatives that might go through okay. > # while true = do = swapinfo ; sleep 5 = done > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > ^C Written as if it was on one line the above was: while true do swapinfo ; sleep 5 done > You could, of course, specify a different sleep time > (in seconds). >=20 > As for logging to a file, that is just some additional > command line text: >=20 > # while true = do = swapinfo ; sleep 5 = done > = mmjnk.txt > ^C > FBSDUSSD# more mmjnk.txt > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% This just added a greater-than sign and a file name after "done". > Multiple processes writing to the same file in an uncoordinated > manner need not produce nice lines with the text from just one > program on each line. >=20 > For now I do not intend to try to handle such issues and only > give the above "just swapinfo" information logging in a specific > file. >=20 > But it is possible to get timestamps in the log file: >=20 > # while true = do date = ; swapinfo ; sleep 5 = done > mmjnk.txt > ^C > FBSDUSSD# more mmjnk.txt = Sat Jun = 16 20:35:11 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Sat Jun 16 20:35:16 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% > Sat Jun 16 20:35:21 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0% >=20 > Of course the time here is "computer local" if it has not > been set to track some standard. Written as if it was on one line but without the greater than sign and file name after "done": while true do date ; swapinfo ; sleep 5 done =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sun Jun 17 10:46:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EFE611019A0A; Sun, 17 Jun 2018 10:46:50 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: from mail-vk0-x22f.google.com (mail-vk0-x22f.google.com [IPv6:2607:f8b0:400c:c05::22f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6EDA369579; Sun, 17 Jun 2018 10:46:50 +0000 (UTC) (envelope-from tvijlbrief@gmail.com) Received: by mail-vk0-x22f.google.com with SMTP id q135-v6so7978381vkh.1; Sun, 17 Jun 2018 03:46:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=yQQQvEItdWKGYqL+ZzwBYYq+CfZCIc+YIAUBJ5A07e4=; b=kxgTHUsyeIReo6HQre8KjaaepGIxC4Cuk8nvjU1SCy+cPMEHAtEZzuq6HyVqg6CWws 0hM6/Q22u9zxkRCbV+eU18LnQgHQco4K9jqaxWFhWKODVy/CieTCp4n6o+joG5vJ+Wdp oL/8YzDJFOB4igYQ5nHacktXSIcZNephl/bqO8keBuAujhDcyrVn219gpPvn7hZVgay5 wLT9EoM0uvW+jwjnYW/qjyMvCEGMULVzj1F8wINOaX1P7Hr8WEfeE/WYIPnvjJAujNsl dJhIO6SlR5gktxIS9g4f9IUWVskKW90SVuMVK9dztHLGYURREcM57ew1HHzYgZim+xXO Y8MA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=yQQQvEItdWKGYqL+ZzwBYYq+CfZCIc+YIAUBJ5A07e4=; b=RtOEsuMLPxhucYb7WCfQWvEqzqJIeGeXuWWAKdCJ75u7LejIzXfazUQemL2caarJ5A Su3fyLdtXoohWJBbVG3uDAJjHno3X84RBZt1oQjrOE6dZTcwggk1PEsn9sai6h24uSaC vQoyaRlL22US6YjhAzKUL2VKqn7ywtKSykG344WXls9NV8XjyBKlSoDe6yWAQVWt2CXc WGhOGok+ncKOG+aXj8yBb8NVs7p+0zZ4JBWDL06Cn5NNY48DRHmctCDvy9U/3yPCj1YA 8jJbNPSyLyKx4A2/2A/rlD/RNPVA6hSIT6P/9EsQ3JSTVWSLBkOI6i3m0E/myQJzlgAS 7QOA== X-Gm-Message-State: APt69E1WW/dnkTaMSV3kr/IDSrodD5z6dAD/2o8Jl53pd+YSZa+c1lpl 5KRtSpBpmoI6SDkirCqQQWvZhbL8nvyz3qLs0pPdPw== X-Google-Smtp-Source: ADUXVKJ7tFubujTPo68/pJejbyphNbYs1PnNc+Wkw5ZZqlXT5liCX3zsv0IOlSWdSkep7InV2bNMbJNNuGrA0IpuugE= X-Received: by 2002:a1f:a302:: with SMTP id m2-v6mr4783332vke.31.1529232409563; Sun, 17 Jun 2018 03:46:49 -0700 (PDT) MIME-Version: 1.0 From: Tom Vijlbrief Date: Sun, 17 Jun 2018 12:46:38 +0200 Message-ID: Subject: Panic on RPI boot with revision 335282 To: freebsd-arm , FreeBSD Current Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 10:46:51 -0000 I get an: panic: Assertion zone->uz_flags & UMA_ZONE_PCPU failed at /media/swan/src.svn/sys/vm/uma_core.c:2239 A one month old kernel runs fine, uma_core.c was edited at that location 9 days ago From owner-freebsd-arm@freebsd.org Sun Jun 17 13:21:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C8B8A101EB61 for ; Sun, 17 Jun 2018 13:21:44 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 65D956E49B for ; Sun, 17 Jun 2018 13:21:44 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1529241695; bh=vO9tg6EXV0WpZTZeZ/hLF13kEzwM12YH2AC5iKsmRmI=; h=To:From:Subject:Date; b=Tvgtb8+CLi2tCvj7+JhYEBfEXAY1gNZYKfF2i2v7pQmJpc2vXsxLH53D51PBkTCWp QQWpquG6/vFuWA3aHXZFaPRgtcaImnbQGp8ugsn2SOVwmoXi5dWqKd1ItUE2ECUziJ YrASiw9i3pY4tIKcCv6d9GpygpfkyD+Ub4v8cgv8= To: freebsd-arm@FreeBSD.org From: Per olof Ljungmark Subject: Raspberry Pi 2B and SSD drive Message-ID: Date: Sun, 17 Jun 2018 15:21:33 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 13:21:45 -0000 FBSD 11.2-RC1 How can I make good use of a USB SSD drive connected to the Pi? For instance, can I start from the SD card and then hand over everything to the SSD drive? From googling it does look like it is possible. Thanks! From owner-freebsd-arm@freebsd.org Sun Jun 17 13:46:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E2F70101FD70 for ; Sun, 17 Jun 2018 13:46:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 856D76F0E0 for ; Sun, 17 Jun 2018 13:46:06 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 68D662110A3 for ; Sun, 17 Jun 2018 09:44:59 -0400 (EDT) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id D84CC10AD4C for ; Sun, 17 Jun 2018 08:44:58 -0500 (CDT) Subject: Re: Raspberry Pi 2B and SSD drive To: freebsd-arm@freebsd.org References: From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= xsFNBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpylzsFNBFIX1zsBEADJr8hX90KTn3/79u2AKQrHjnV13/AuTO1yIazTdvXJ7sNlx6mm jrwWXPp5Ug8AYXDAe57Ifz4oyHTP0xmxOZpPG40JvtPzMt4sf+sifjbdZ6IVGmVi9wH3TltS 5lgLcQcjb8PEKtEy0vsoFy0jGdJsVzTYfhPOnVsHw/pNumaZV9001PIL7Xhnp5fOLhE3TJcb Hq/uFKtKaU3QhMuKu7XeS5prkUu4J96uwN+cOKKfuviVPL4qvlSD2m7YX+jGx2WhHum1z/st 5ZWPLjc/0+tlkdonAxAyGXaLYHYvfWtOiEHESjRcEaa6zkOhBtDZMQUtZuR6p+4d+bPN71RO FHZjNLn2B+BjgdgKXMhmb1HWldzGBNfzm2YdFpGS6QnXwQ/r5uucNy0kAzU4QR38XiWMJYlU RVeK1vtya5A5ef61Nhtubh9swS0cmMU7u3S8SnJyebtsOQo73CstByqdNyEqwb5mh2G9fKN0 H+zLukxNb1x/Gp2T4P0fdZzC5YY6xp7x8D6+UTjZMR5eulWI0W4rr2CzrM0wHqDbaYTh1dnS 0gsa9H/aH3UKeb88rQ9yUXRLR3MV3i288uD7GiY7jmayGq05sjyKNUBfJJTwrCKW4peMgwWF mY2ZPlOZoJ++WzZGMBCC2YEy5rTi91eclWvxIhPEbYhNTiAyS7Xx8J0dbQARAQABwsFlBBgB AgAPBQJSF9c7AhsMBQkJZgGAAAoJEG6/sivc5s0PYJgP/jnWJhGNDCzs6quF0U6VcnvbMCVl iUWXo4VkgGoCfvbkWLvSmIusJl4DOw7RIeFwyCA54O3FjSNuYCFP3ST14fHAC4Q3GVXA/dno Wh9cFI8hIekimigFaQibCqhP//eBXAuW/+LTMnXefrYtyPMLVfsYgzz4+jcfDMA9FtKBivnD gavoiDsBbWH54jsu9WLPGRTsfXA2ZFSH9BzIXykA0VONbUnzYouPVePLxFLJ35nyDyO1Gnj6 KgPf6X6kgwNgmfE6fGxobtq1By5y2AaSFKPuhx1FCHmSn6/O5LZPpWZh+FdPq6e/JBzLT4e5 /a4qKbfvaMmxP9SC5SizGu5vClxBfFRqti3Zap5sRn4zzUQi+NmeOe95pAPHDR+LOYEPsIb+ rARgcj0Eiso1Ye67HLUAPnR9CL4zw3CRzoEM8WR3E7/j3+jNB0hqKaYtxE4KzwWWj9p4pFrs 5Yl58hrg/mNfajxQMR3PBLWctmwjpQQRsbGym+gvdgfc+4LrOL0RAqf7ilPnixkK3w6W9Um+ lwj6z1seMqNO9GP8Ymo1avg7jZfHAA83BQzD6QiEl3H8Cy0CaxhpoB3QwMBfNzJ+PbXLJi0i qNyHOlJ93zHCh8r3kwtpA0FK9ht0AAk4T4xSmSSQdjuN4YWnE6Rv4u7ZXy2Gy8eH8WcLsTGw 5S8pynaD Message-ID: Date: Sun, 17 Jun 2018 08:44:58 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms080701060609000006010902" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 13:46:07 -0000 This is a cryptographically signed message in MIME format. --------------ms080701060609000006010902 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/17/2018 08:21, Per olof Ljungmark wrote: > FBSD 11.2-RC1 > > How can I make good use of a USB SSD drive connected to the Pi? > > For instance, can I start from the SD card and then hand over everythin= g > to the SSD drive? From googling it does look like it is possible. > > Thanks! > Yes, but.... The but being that it's still USB attached and won't be nearly as fast as you expect. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms080701060609000006010902 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNjE3MTM0NDU4 WjBPBgkqhkiG9w0BCQQxQgRASWn1Z9C4jX6Ofweh3A0IvzCA5brl719DZjXYGaALTAs7f8bs 4q/I/bpkF6Uxu6xgaxb5T+CIXTK3NAgixaxvXDBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgBtsAGO/T4Nj6EuOCZD2YYNiIk98Ngt8VBq1bLbigxury3NbTLEtWYW8FIxZUS88YbE l2Yfso60CbBRsOSjRr7rt6z4kYJsrIBFtu1IIP9+AggoG/jCkTX2GtVBptzAb7w2nVFcO7dW h5+41WaRI3AM2so9KVf+N84kCOPdP6Uh83coVcveN5U3dp8OwNUM9hYr0sB7lyFDyoXjXbFC hHKl9D9uxY4zXSGEyBjMUPnZDU1wcmpoXeGJHAJ0SEwWHCqaycrGOrk5ESeqm7ApdbWWlewZ fvKx7RLBwuAe098ksz7PtNu3dPIULnZo1mO48SIskBmrQXjZUzeCJ68Phm6Stgs3KLkQcPl0 DGetbTmk0iv7M6OWq6hNQLDK8mQfDyJ8wtbYzWiRIFtc5PHxYZHHepEi9Ezq5ZD785P25as6 in5mH7hvsPSKtnJltJJ2pv3Rtezea4ZF9sZcjRiIIWppaCbqqaZ+/Oj3UiAPfoJGFhKYd3l1 9tczRbqq1tReiC2lsqO10LDX9vd/9en+G4k5K7gbJ8j+g+wuTJ3RjWHOzmdj46of+4kaxPxn NdfypcQ25hX2PZvlLT7XDZwFH3ihdHpM13Q++gxr6NUPDJjqB3WNE/3sK8T9er4ykB4GC6ez q0qpCXqrrgIMQ1X3jz0lMyNrw9sl0tn+7BETGgV9mgAAAAAAAA== --------------ms080701060609000006010902-- From owner-freebsd-arm@freebsd.org Sun Jun 17 15:10:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6DD891022660 for ; Sun, 17 Jun 2018 15:10:24 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id F260E71A7C for ; Sun, 17 Jun 2018 15:10:23 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1529248222; bh=J3myjJGV08xfzqIN73QGQulm2Up/NHMv8egB/0yE8XQ=; h=From:Subject:To:Cc:Date; b=rFvJ3TI9u0NZZzbp2EFopYAVM++zhWdF2dHiIX/5g45Hnp+35nxoUWrB78O4Q1wb2 jc7s7Zq9iQjiCwL4rbZ+4Il2mktCDralcdfFL8nX1muqy74mq1aNClVm41DYnj16Bs gif9/odjtJPAkY6QfCcNBiH5ALwB+HHV0TPaj7E4= From: Per olof Ljungmark Subject: Raspberry Pi 2B and SSD drive To: freebsd-arm@FreeBSD.org Message-ID: <2f135d3f-8175-aecb-006f-424b876a5bce@nethead.se> Date: Sun, 17 Jun 2018 17:10:15 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 15:10:24 -0000 FBSD 11.2-RC1 How can I make good use of a USB SSD drive connected to the Pi? For instance, can I start from the SD card and then hand over everything to the SSD drive? From googling it does look like it is possible. Thanks! ... Yes, but.... The but being that it's still USB attached and won't be nearly as fast as you expect. ... Subscribed to the list now... I am not concerned about the performance, it is the wear. So, how do one load the OS from the SSD? I suppose I could boot the OS from the SD card and place most other filesystems on the SSD but would prefer to load the OS from the SSD drive. Have a feeling the mysterious /boot/msdos/config.txt is involved but I fail to locate any documentation, if there is one? From owner-freebsd-arm@freebsd.org Sun Jun 17 16:20:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 61B5310008B9 for ; Sun, 17 Jun 2018 16:20:57 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smarthost1.greenhost.nl (smarthost1.greenhost.nl [195.190.28.92]) (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 0049A74251 for ; Sun, 17 Jun 2018 16:20:56 +0000 (UTC) (envelope-from ronald-lists@klop.ws) Received: from smtp.greenhost.nl ([213.108.110.112]) by smarthost1.greenhost.nl with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.84_2) (envelope-from ) id 1fUaQ4-0005Lr-TV; Sun, 17 Jun 2018 18:20:49 +0200 Content-Type: text/plain; charset=iso-8859-15; format=flowed; delsp=yes To: freebsd-arm@freebsd.org, "Per olof Ljungmark" Subject: Re: Raspberry Pi 2B and SSD drive References: <2f135d3f-8175-aecb-006f-424b876a5bce@nethead.se> Date: Sun, 17 Jun 2018 18:20:43 +0200 MIME-Version: 1.0 Content-Transfer-Encoding: 7bit From: "Ronald Klop" Message-ID: In-Reply-To: <2f135d3f-8175-aecb-006f-424b876a5bce@nethead.se> User-Agent: Opera Mail/1.0 (Win32) X-Authenticated-As-Hash: bdb49c4ff80bd276e321aade33e76e02752072e2 X-Virus-Scanned: by clamav at smarthost1.samage.net X-Spam-Level: / X-Spam-Score: -0.2 X-Spam-Status: No, score=-0.2 required=5.0 tests=ALL_TRUSTED, BAYES_50 autolearn=disabled version=3.4.0 X-Scan-Signature: 353bb18b0f14186cd389c275975c39f5 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 16:20:57 -0000 On Sun, 17 Jun 2018 17:10:15 +0200, Per olof Ljungmark wrote: > FBSD 11.2-RC1 > > How can I make good use of a USB SSD drive connected to the Pi? > > For instance, can I start from the SD card and then hand over everything > to the SSD drive? From googling it does look like it is possible. > > Thanks! > > ... > > Yes, but.... > > The but being that it's still USB attached and won't be nearly as fast > as you expect. > > ... > > Subscribed to the list now... > > I am not concerned about the performance, it is the wear. > > So, how do one load the OS from the SSD? I suppose I could boot the OS > from the SD card and place most other filesystems on the SSD but would > prefer to load the OS from the SSD drive. > > Have a feeling the mysterious /boot/msdos/config.txt is involved but I > fail to locate any documentation, if there is one? It depends on the stage you want the boot to switch to the SSD. 1. load kernel from SD, but rootfs from SSD. You can set 'rootdev=/dev/da0s1' (device path to your FS on SSD) in /boot/loader.conf. Than the kernel will be loaded from SD, but the root FS will come from the SSD. This works best if you keep /boot as a separate FS on SD. (You can mount this FS on /boot in fstab.) 2. load kernel and rootfs from SSD. If you want to load the kernel from SSD also. You can edit some variables in u-boot. Interrupt the boot in the u-boot stage. Type 'showenv', edit some stuff and 'saveenv' will make the changes permanent in /boot/msdos/uboot.env. 3. load u-boot from SSD? Recent version of u-boot can also detect usb devices, so it might even be possible to boot without SD and only use SSD (So /boot/msdos is also on SSD). This is the theory. I did not try this. NB: I'm not an expert in u-boot. I might have written some mistakes in this mail. Good luck and have fun. Regards, Ronald. From owner-freebsd-arm@freebsd.org Sun Jun 17 16:26:55 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1DC071000BF6 for ; Sun, 17 Jun 2018 16:26:55 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22d.google.com (mail-it0-x22d.google.com [IPv6:2607:f8b0:4001:c0b::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEE0A746C6 for ; Sun, 17 Jun 2018 16:26:54 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22d.google.com with SMTP id 16-v6so8850516itl.5 for ; Sun, 17 Jun 2018 09:26:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9k41lyT9kMW+zswMac0+rRw3PCsN/cWLkH2glNMbLuE=; b=RBtOAM+RgDQGjPwT7eCzMx63OKrYZbk/ycqd9EfEcKycYatBCVodfgIqQjturSeADm h7bL7KKZmWrFIz7gsOQJ76CvMMBsiDyWO386lBwed1Fn87CPWI7h0luAVdU/iar0oQsr vcW6EtB0dm0VPU0fqYChCWoinD9y1ly1UkYop07p7z55JUs6sR2uRDDYNzLWlqdg4iJD qnOE1WSCqEUBBL2QyAFuyy53RsR//ZKRJWA9LqxU5sH9BvlStCqSrOmXNWDLBqGXpOLv 49fJOuT24iUbys0O9odo+5Zsy4S0YDJmuN0tyNe7e2DK4VrumUn92GOUukcPFD5PwqFW pV9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9k41lyT9kMW+zswMac0+rRw3PCsN/cWLkH2glNMbLuE=; b=eYK2VTMqQnNXJWLrpfqS6pjezTXaHumfTvnOJDSOfYk9Zmj95g60/wXnza5Z8L3lMd QcX0ctPqc//obUl427vx6/jaF7jQ1AfIKvDmzvFXEEi9AMrSyBMGHpNs+JRxEU1iOXw2 NyFwZ4Wc3vNqeYf+ERQO2C5EHzTwBl35kKTBexz2Y1ZWP8pEYgyWOKhNfwk3RkwCp4ET d0h2swc3EGrBJXhFwB7R7J8PhiPeSBw3HCcK0RZn9NT26k+QJ8uapX8i44t3TnffQTzL Y56BsjeViAOjQgxf7x4cG3fxYIVtzxbi9hSoEaVhaDKGUmwX4i3ab8lAyTqJTpc7J9NR 86mA== X-Gm-Message-State: APt69E0OVFntVYQr17p1iWhXREIyOmQxybRnk8o9JdXZWvdtnjLBjfUE YGnf/+DIPOyaBifLrHZ+upSqoAuQrYFazOQ1vDcW2A== X-Google-Smtp-Source: ADUXVKLhBvEsqhuY5p1NA9t05CThllCdkIoilKIEjyR204GbUu/7CfJ/p9Gq8aKJbYp1iZhw6xUidMyxXe+K9gK5w2Q= X-Received: by 2002:a02:6348:: with SMTP id j69-v6mr7626904jac.45.1529252813972; Sun, 17 Jun 2018 09:26:53 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Warner Losh Date: Sun, 17 Jun 2018 10:26:42 -0600 Message-ID: Subject: Re: Raspberry Pi 2B and SSD drive To: Karl Denninger Cc: freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 16:26:55 -0000 On Sun, Jun 17, 2018, 7:46 AM Karl Denninger wrote: > On 6/17/2018 08:21, Per olof Ljungmark wrote: > > FBSD 11.2-RC1 > > > > How can I make good use of a USB SSD drive connected to the Pi? > > > > For instance, can I start from the SD card and then hand over everything > > to the SSD drive? From googling it does look like it is possible. > > > > Thanks! > > > Yes, but.... > > The but being that it's still USB attached and won't be nearly as fast > as you expect. > Yes. You'll need a A20 based board or similar with built in SATA ports to get good speed. The RPi are good cheap boards, but they aren't so good for file servers or other applications needing high bandwidth. Warner > From owner-freebsd-arm@freebsd.org Sun Jun 17 18:33:14 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 48F6F100563F for ; Sun, 17 Jun 2018 18:33:14 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id C9385796A6 for ; Sun, 17 Jun 2018 18:33:13 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1529260391; bh=gPdS15wzmxae17WK9cS4LwbqOrQezeto6f6nD6QH9tk=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=3QEGP4ZaksDpE3SP6g8K/dYDH8xUqGTBYmK3gpa5D5I0qi72xge/N707Jn5bJ+W1N PygWRnuT3co/uzmIDb2qX5ZxJbomdYAAK6CMsbtbZMmdRnXox51QsNXqzRPn9BEciN GNBcbj7BPz3fdTQznOtjNA+b6NpdzCjCvGwQHRVY= Subject: Re: Raspberry Pi 2B and SSD drive To: Warner Losh , Karl Denninger Cc: freebsd-arm@freebsd.org References: From: Per olof Ljungmark Message-ID: <8f6c49b1-13e0-acf7-192d-1c7ccef95363@nethead.se> Date: Sun, 17 Jun 2018 20:33:09 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 18:33:14 -0000 On 06/17/18 18:26, Warner Losh wrote: > On Sun, Jun 17, 2018, 7:46 AM Karl Denninger wrote: > >> On 6/17/2018 08:21, Per olof Ljungmark wrote: >>> FBSD 11.2-RC1 >>> >>> How can I make good use of a USB SSD drive connected to the Pi? >>> >>> For instance, can I start from the SD card and then hand over everything >>> to the SSD drive? From googling it does look like it is possible. >>> >>> Thanks! >>> >> Yes, but.... >> >> The but being that it's still USB attached and won't be nearly as fast >> as you expect. >> > > Yes. You'll need a A20 based board or similar with built in SATA ports to > get good speed. The RPi are good cheap boards, but they aren't so good for > file servers or other applications needing high bandwidth. > I am not after speed, I am after greater reliability than what the SD card can offer. The Pi will do duty as a simple SMTP server and I have already tested with the SD card only and speed is good enough. From owner-freebsd-arm@freebsd.org Sun Jun 17 18:42:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8BDA410059DD for ; Sun, 17 Jun 2018 18:42:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 04C8B79BE4 for ; Sun, 17 Jun 2018 18:42:48 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5HIh1Br050213 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sun, 17 Jun 2018 11:43:02 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5HIh1SC050212; Sun, 17 Jun 2018 11:43:01 -0700 (PDT) (envelope-from fbsd) Date: Sun, 17 Jun 2018 11:43:01 -0700 From: bob prohaska To: Per olof Ljungmark Cc: freebsd-arm@FreeBSD.org, bob prohaska Subject: Re: Raspberry Pi 2B and SSD drive Message-ID: <20180617184301.GA50150@www.zefox.net> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 18:42:49 -0000 On Sun, Jun 17, 2018 at 03:21:33PM +0200, Per olof Ljungmark wrote: > FBSD 11.2-RC1 > > How can I make good use of a USB SSD drive connected to the Pi? > It might help if you indicated what constitutes "good use" 8-) > For instance, can I start from the SD card and then hand over everything > to the SSD drive? From googling it does look like it is possible. > Going out on a limb here, but I don't think it'll make much difference. Personally I like to leave root on microSD and keep /usr, /var, /tmp and swap on USB flash. Far as I know USB is the only mass storage connection interface, so that bottleneck is unavoidable. Having the booting bits separate from the scribbling bits offers a little protection against a totally unbootable system in case of user error or other mishap. It's still necessary to make provision for a serial console, since last I checked one can't talk to single user via USB keyboard. hth, bob prohaska > Thanks! > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Sun Jun 17 18:55:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DDDE71005EFD for ; Sun, 17 Jun 2018 18:55:50 +0000 (UTC) (envelope-from peo@nethead.se) Received: from ns1.nethead.se (ns1.nethead.se [5.150.237.139]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ns1.nethead.se", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 789F27A18C for ; Sun, 17 Jun 2018 18:55:50 +0000 (UTC) (envelope-from peo@nethead.se) X-Virus-Scanned: amavisd-new at Nethead AB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=nethead.se; s=NETHEADSE; t=1529261749; bh=9fxld01vnazNkaxqVPFH7HclUQsDsExaad3hCeDvS6k=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=qwQ0ZuqgVBztcwkSquNjwxd1nQJpKW6O4G+aTY7dDH+x6iZs0IAVohr3JDBiULsjX 0TTcGG87F0yd5nL+yfwWgnvgTupXDCZVJ1FB6Pmu4Yomx1JOWI99GXaDbOHLaMcEFU goPlFtrsFhhNGFJxsv+EGZOUuGho0OfWZo3jTJdo= Date: Sun, 17 Jun 2018 20:55:47 +0200 Message-ID: <20180617205547.Horde.0vOU2_N8C0NmcgeJBSHSR5m@webmail.nethead.se> From: Per olof Ljungmark To: bob prohaska Cc: freebsd-arm@freebsd.org Subject: Re: Raspberry Pi 2B and SSD drive References: <20180617184301.GA50150@www.zefox.net> In-Reply-To: <20180617184301.GA50150@www.zefox.net> User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 18:55:51 -0000 Hi, Quoting bob prohaska : > On Sun, Jun 17, 2018 at 03:21:33PM +0200, Per olof Ljungmark wrote: >> FBSD 11.2-RC1 >> >> How can I make good use of a USB SSD drive connected to the Pi? >> > It might help if you indicated what constitutes "good use" 8-) As just stated, a light duty smtp-server, and I need better reliability, not speed, than what a SD card usually offers. >> For instance, can I start from the SD card and then hand over everything >> to the SSD drive? From googling it does look like it is possible. >> > Going out on a limb here, but I don't think it'll make much difference. > > Personally I like to leave root on microSD and keep /usr, /var, /tmp > and swap on USB flash. Far as I know USB is the only mass storage > connection interface, so that bottleneck is unavoidable. > > Having the booting bits separate from the scribbling bits offers a little > protection against a totally unbootable system in case of user error or > other mishap. It's still necessary to make provision for a serial console, > since last I checked one can't talk to single user via USB keyboard. > Makes sense of course. From owner-freebsd-arm@freebsd.org Sun Jun 17 19:04:08 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 821F21006246 for ; Sun, 17 Jun 2018 19:04:08 +0000 (UTC) (envelope-from karl@denninger.net) Received: from colo1.denninger.net (colo1.denninger.net [104.236.120.189]) (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 F1BC77A4E6 for ; Sun, 17 Jun 2018 19:04:07 +0000 (UTC) (envelope-from karl@denninger.net) Received: from denninger.net (ip68-1-57-197.pn.at.cox.net [68.1.57.197]) by colo1.denninger.net (Postfix) with ESMTP id 3ED082110AB for ; Sun, 17 Jun 2018 15:04:06 -0400 (EDT) Received: from [192.168.10.23] (D13.Denninger.Net [192.168.10.23]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by denninger.net (Postfix) with ESMTPSA id C5B0310CF2E for ; Sun, 17 Jun 2018 14:04:05 -0500 (CDT) Subject: Re: Raspberry Pi 2B and SSD drive To: freebsd-arm@freebsd.org References: <20180617184301.GA50150@www.zefox.net> <20180617205547.Horde.0vOU2_N8C0NmcgeJBSHSR5m@webmail.nethead.se> From: Karl Denninger Openpgp: preference=signencrypt Autocrypt: addr=karl@denninger.net; prefer-encrypt=mutual; keydata= xsFNBFIX1zsBEADRcJfsQUl9oFeoMfLPJ1kql+3sIaYx0MfJAUhV9LnbWxr0fsWCskM1O4cV tHm5dqPkuPM4Ztc0jLotD1i9ubWvCHOlkLGxFOL+pFbjA+XZ7VKsC/xWmhMwJ3cM8HavK2OV SzEWQ/AEYtMi04IzGSwsxh/5/5R0mPHrsIomV5SbuiI0vjLuDj7fo6146AABI1ULzge4hBYW i/SHrqUrLORmUNBs6bxek79/B0Dzk5cIktD3LOfbT9EAa5J/osVkstMBhToJgQttaMIGv8SG CzpR/HwEokE+7DP+k2mLHnLj6H3kfugOF9pJH8Za4yFmw//s9cPXV8WwtZ2SKfVzn1unpKqf wmJ1PwJoom/d4fGvQDkgkGKRa6RGC6tPmXnqnx+YX4iCOdFfbP8L9rmk2sewDDVzHDU3I3ZZ 8hFIjMYM/QXXYszRatK0LCV0QPZuF7LCf4uQVKw1/oyJInsnH7+6a3c0h21x+CmSja9QJ+y0 yzgEN/nM89d6YTakfR+1xkYgodVmMy/bS8kmXbUUZG/CyeqCqc95RUySjKT2ECrf9GhhoQkl +D8n2MsrAUSMGB4GQSN+TIq9OBTpNuvATGSRuF9wnQcs1iSry+JNCpfRTyWp83uCNApe6oHU EET4Et6KDO3AvjvBMAX0TInTRGW2SQlJMuFKpc7Dg7tHK8zzqQARAQABzSNLYXJsIERlbm5p bmdlciA8a2FybEBkZW5uaW5nZXIubmV0PsLBfAQTAQIAJgUCUhfXOwIbIwUJCWYBgAYLCQgH AwIEFQIIAwQWAgMBAh4BAheAAAoJEG6/sivc5s0PLxQP/i6x/QFx9G4Cw7C+LthhLXIm7NSH AtNbz2UjySEx2qkoQQjtsK6mcpEEaky4ky6t8gz0/SifIfJmSmyAx0UhUQ0WBv1vAXwtNrQQ jJd9Bj6l4c2083WaXyHPjt2u2Na6YFowyb4SaQb83hu/Zs25vkPQYJVVE0JX409MFVPUa6E3 zFbd1OTr3T4yNUy4gNeQZfzDqDS8slbIks2sXeoJrZ6qqXVI0ionoivOlaN4T6Q0UYyXtigj dQvvhMt0aNowKFjRqrmSDRpdz+o6yg7Mp7qEZ1V6EZk8KqQTH6htpCTQ8i79ttK4LG6bstSF Re6Fwq52nbrcANrcdmtZXqjo+SGbUqJ8b1ggrxAsJ5MEhRh2peKrCgI/TjQo+ZxfnqEoR4AI 46Cyiz+/lcVvlvmf2iPifS3EEdaH3Itfwt7MxFm6mQORYs6skHDw3tOYB2/AdCW6eRVYs2hB RMAG4uwApZfZDKgRoE95PJmQjeTBiGmRPcsQZtNESe7I7EjHtCDLwtJqvD4HkDDQwpzreT6W XkyIJ7ns7zDfA1E+AQhFR6rsTFGgQZRZKsVeov3SbhYKkCnVDCvb/PKQCAGkSZM9SvYG5Yax 8CMry3AefKktf9fqBFg8pWqtVxDwJr56dhi0GHXRu3jVI995rMGo1fLUG5fSxiZ8L5sAtokh 9WFmQpylzsFNBFIX1zsBEADJr8hX90KTn3/79u2AKQrHjnV13/AuTO1yIazTdvXJ7sNlx6mm jrwWXPp5Ug8AYXDAe57Ifz4oyHTP0xmxOZpPG40JvtPzMt4sf+sifjbdZ6IVGmVi9wH3TltS 5lgLcQcjb8PEKtEy0vsoFy0jGdJsVzTYfhPOnVsHw/pNumaZV9001PIL7Xhnp5fOLhE3TJcb Hq/uFKtKaU3QhMuKu7XeS5prkUu4J96uwN+cOKKfuviVPL4qvlSD2m7YX+jGx2WhHum1z/st 5ZWPLjc/0+tlkdonAxAyGXaLYHYvfWtOiEHESjRcEaa6zkOhBtDZMQUtZuR6p+4d+bPN71RO FHZjNLn2B+BjgdgKXMhmb1HWldzGBNfzm2YdFpGS6QnXwQ/r5uucNy0kAzU4QR38XiWMJYlU RVeK1vtya5A5ef61Nhtubh9swS0cmMU7u3S8SnJyebtsOQo73CstByqdNyEqwb5mh2G9fKN0 H+zLukxNb1x/Gp2T4P0fdZzC5YY6xp7x8D6+UTjZMR5eulWI0W4rr2CzrM0wHqDbaYTh1dnS 0gsa9H/aH3UKeb88rQ9yUXRLR3MV3i288uD7GiY7jmayGq05sjyKNUBfJJTwrCKW4peMgwWF mY2ZPlOZoJ++WzZGMBCC2YEy5rTi91eclWvxIhPEbYhNTiAyS7Xx8J0dbQARAQABwsFlBBgB AgAPBQJSF9c7AhsMBQkJZgGAAAoJEG6/sivc5s0PYJgP/jnWJhGNDCzs6quF0U6VcnvbMCVl iUWXo4VkgGoCfvbkWLvSmIusJl4DOw7RIeFwyCA54O3FjSNuYCFP3ST14fHAC4Q3GVXA/dno Wh9cFI8hIekimigFaQibCqhP//eBXAuW/+LTMnXefrYtyPMLVfsYgzz4+jcfDMA9FtKBivnD gavoiDsBbWH54jsu9WLPGRTsfXA2ZFSH9BzIXykA0VONbUnzYouPVePLxFLJ35nyDyO1Gnj6 KgPf6X6kgwNgmfE6fGxobtq1By5y2AaSFKPuhx1FCHmSn6/O5LZPpWZh+FdPq6e/JBzLT4e5 /a4qKbfvaMmxP9SC5SizGu5vClxBfFRqti3Zap5sRn4zzUQi+NmeOe95pAPHDR+LOYEPsIb+ rARgcj0Eiso1Ye67HLUAPnR9CL4zw3CRzoEM8WR3E7/j3+jNB0hqKaYtxE4KzwWWj9p4pFrs 5Yl58hrg/mNfajxQMR3PBLWctmwjpQQRsbGym+gvdgfc+4LrOL0RAqf7ilPnixkK3w6W9Um+ lwj6z1seMqNO9GP8Ymo1avg7jZfHAA83BQzD6QiEl3H8Cy0CaxhpoB3QwMBfNzJ+PbXLJi0i qNyHOlJ93zHCh8r3kwtpA0FK9ht0AAk4T4xSmSSQdjuN4YWnE6Rv4u7ZXy2Gy8eH8WcLsTGw 5S8pynaD Message-ID: Date: Sun, 17 Jun 2018 14:04:05 -0500 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180617205547.Horde.0vOU2_N8C0NmcgeJBSHSR5m@webmail.nethead.se> Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha-512; boundary="------------ms060509030403020603050802" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 19:04:08 -0000 This is a cryptographically signed message in MIME format. --------------ms060509030403020603050802 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 6/17/2018 13:55, Per olof Ljungmark wrote: > Hi, > > Quoting bob prohaska : > >> On Sun, Jun 17, 2018 at 03:21:33PM +0200, Per olof Ljungmark wrote: >>> FBSD 11.2-RC1 >>> >>> How can I make good use of a USB SSD drive connected to the Pi? >>> >> It might help if you indicated what constitutes "good use" 8-) > > As just stated, a light duty smtp-server, and I need better > reliability, not speed, than what a SD card usually offers. > >>> For instance, can I start from the SD card and then hand over >>> everything >>> to the SSD drive? From googling it does look like it is possible. >>> >> Going out on a limb here, but I don't think it'll make much difference= =2E >> >> Personally I like to leave root on microSD and keep /usr, /var, /tmp >> and swap on USB flash. Far as I know USB is the only mass storage >> connection interface, so that bottleneck is unavoidable. >> >> Having the booting bits separate from the scribbling bits offers a >> little >> protection against a totally unbootable system in case of user error o= r >> other mishap. It's still necessary to make provision for a serial >> console, >> since last I checked one can't talk to single user via USB keyboard. >> > > Makes sense of course. > IMHO do not put "scribbling bits" on SD card; they're not made for it, it's wildly abusive to them to do so, and they *will* fail if subjected to that in a moderate-to-heavy load environment, at which point the unit usually panics and is unbootable when it comes back up. Oh, and it's also wildly *slow* too, so there's another reason not to. Putting that on a USB-attached spinning rust device works reasonable well; an SSD is gross overkill for this application and likely not much help too, as an SSD that takes an unexpected power loss and is not designed to be power-fail tolerant has a decent chance of coming back un-fsckable (or worse, it fsck's ok but has corruption that is invisible on it that causes an immediate panic when referenced) due to the lack of coherence in writes when the power goes off. Power-fail-safe SSDs are expensive; the only one I've found that's not ridiculously-so are the Intel 730 series, of which I own several -- they have passed repeated "plug pull" tests while running a Postgres test app that is intentionally designed to detect any sort of game-playing when it comes to claims of "I committed that write" when it really did not. --=20 Karl Denninger karl@denninger.net /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms060509030403020603050802 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" Content-Description: S/MIME Cryptographic Signature MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC DdgwggagMIIEiKADAgECAhMA5EiKghDOXrvfxYxjITXYDdhIMA0GCSqGSIb3DQEBCwUAMIGL MQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJTmljZXZpbGxlMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExITAf BgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQTAeFw0xNzA4MTcxNjQyMTdaFw0yNzA4 MTUxNjQyMTdaMHsxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkwFwYDVQQKDBBD dWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5c3RlbXMgQ0ExJTAjBgNVBAMMHEN1 ZGEgU3lzdGVtcyBMTEMgMjAxNyBJbnQgQ0EwggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIK AoICAQC1aJotNUI+W4jP7xQDO8L/b4XiF4Rss9O0B+3vMH7Njk85fZ052QhZpMVlpaaO+sCI KqG3oNEbuOHzJB/NDJFnqh7ijBwhdWutdsq23Ux6TvxgakyMPpT6TRNEJzcBVQA0kpby1DVD 0EKSK/FrWWBiFmSxg7qUfmIq/mMzgE6epHktyRM3OGq3dbRdOUgfumWrqHXOrdJz06xE9NzY vc9toqZnd79FUtE/nSZVm1VS3Grq7RKV65onvX3QOW4W1ldEHwggaZxgWGNiR/D4eosAGFxn uYeWlKEC70c99Mp1giWux+7ur6hc2E+AaTGh+fGeijO5q40OGd+dNMgK8Es0nDRw81lRcl24 SWUEky9y8DArgIFlRd6d3ZYwgc1DMTWkTavx3ZpASp5TWih6yI8ACwboTvlUYeooMsPtNa9E 6UQ1nt7VEi5syjxnDltbEFoLYcXBcqhRhFETJe9CdenItAHAtOya3w5+fmC2j/xJz29og1KH YqWHlo3Kswi9G77an+zh6nWkMuHs+03DU8DaOEWzZEav3lVD4u76bKRDTbhh0bMAk4eXriGL h4MUoX3Imfcr6JoyheVrAdHDL/BixbMH1UUspeRuqQMQ5b2T6pabXP0oOB4FqldWiDgJBGRd zWLgCYG8wPGJGYgHibl5rFiI5Ix3FQncipc6SdUzOQIDAQABo4IBCjCCAQYwHQYDVR0OBBYE FF3AXsKnjdPND5+bxVECGKtc047PMIHABgNVHSMEgbgwgbWAFBu1oRhUMNEzjODolDka5k4Q EDBioYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UEBwwJ TmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRhIFN5 c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYIJAKxAy1WBo2kY MBIGA1UdEwEB/wQIMAYBAf8CAQAwDgYDVR0PAQH/BAQDAgGGMA0GCSqGSIb3DQEBCwUAA4IC AQCB5686UCBVIT52jO3sz9pKuhxuC2npi8ZvoBwt/IH9piPA15/CGF1XeXUdu2qmhOjHkVLN gO7XB1G8CuluxofOIUce0aZGyB+vZ1ylHXlMeB0R82f5dz3/T7RQso55Y2Vog2Zb7PYTC5B9 oNy3ylsnNLzanYlcW3AAfzZcbxYuAdnuq0Im3EpGm8DoItUcf1pDezugKm/yKtNtY6sDyENj tExZ377cYA3IdIwqn1Mh4OAT/Rmh8au2rZAo0+bMYBy9C11Ex0hQ8zWcvPZBDn4v4RtO8g+K uQZQcJnO09LJNtw94W3d2mj4a7XrsKMnZKvm6W9BJIQ4Nmht4wXAtPQ1xA+QpxPTmsGAU0Cv HmqVC7XC3qxFhaOrD2dsvOAK6Sn3MEpH/YrfYCX7a7cz5zW3DsJQ6o3pYfnnQz+hnwLlz4MK 17NIA0WOdAF9IbtQqarf44+PEyUbKtz1r0KGeGLs+VGdd2FLA0e7yuzxJDYcaBTVwqaHhU2/ Fna/jGU7BhrKHtJbb/XlLeFJ24yvuiYKpYWQSSyZu1R/gvZjHeGb344jGBsZdCDrdxtQQcVA 6OxsMAPSUPMrlg9LWELEEYnVulQJerWxpUecGH92O06wwmPgykkz//UmmgjVSh7ErNvL0lUY UMfunYVO/O5hwhW+P4gviCXzBFeTtDZH259O7TCCBzAwggUYoAMCAQICEwCg0WvVwekjGFiO 62SckFwepz0wDQYJKoZIhvcNAQELBQAwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3Jp ZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBD QTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExMQyAyMDE3IEludCBDQTAeFw0xNzA4MTcyMTIx MjBaFw0yMjA4MTYyMTIxMjBaMFcxCzAJBgNVBAYTAlVTMRAwDgYDVQQIDAdGbG9yaWRhMRkw FwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRswGQYDVQQDDBJrYXJsQGRlbm5pbmdlci5uZXQw ggIiMA0GCSqGSIb3DQEBAQUAA4ICDwAwggIKAoICAQC+HVSyxVtJhy3Ohs+PAGRuO//Dha9A 16l5FPATr6wude9zjX5f2lrkRyU8vhCXTZW7WbvWZKpcZ8r0dtZmiK9uF58Ec6hhvfkxJzbg 96WHBw5Fumd5ahZzuCJDtCAWW8R7/KN+zwzQf1+B3MVLmbaXAFBuKzySKhKMcHbK3/wjUYTg y+3UK6v2SBrowvkUBC+jxNg3Wy12GsTXcUS/8FYIXgVVPgfZZrbJJb5HWOQpvvhILpPCD3xs YJFNKEPltXKWHT7Qtc2HNqikgNwj8oqOb+PeZGMiWapsatKm8mxuOOGOEBhAoTVTwUHlMNTg 6QUCJtuWFCK38qOCyk9Haj+86lUU8RG6FkRXWgMbNQm1mWREQhw3axgGLSntjjnznJr5vsvX SYR6c+XKLd5KQZcS6LL8FHYNjqVKHBYM+hDnrTZMqa20JLAF1YagutDiMRURU23iWS7bA9tM cXcqkclTSDtFtxahRifXRI7Epq2GSKuEXe/1Tfb5CE8QsbCpGsfSwv2tZ/SpqVG08MdRiXxN 5tmZiQWo15IyWoeKOXl/hKxA9KPuDHngXX022b1ly+5ZOZbxBAZZMod4y4b4FiRUhRI97r9l CxsP/EPHuuTIZ82BYhrhbtab8HuRo2ofne2TfAWY2BlA7ExM8XShMd9bRPZrNTokPQPUCWCg CdIATQIDAQABo4IBzzCCAcswPAYIKwYBBQUHAQEEMDAuMCwGCCsGAQUFBzABhiBodHRwOi8v b2NzcC5jdWRhc3lzdGVtcy5uZXQ6ODg4ODAJBgNVHRMEAjAAMBEGCWCGSAGG+EIBAQQEAwIF oDAOBgNVHQ8BAf8EBAMCBeAwHQYDVR0lBBYwFAYIKwYBBQUHAwIGCCsGAQUFBwMEMDMGCWCG SAGG+EIBDQQmFiRPcGVuU1NMIEdlbmVyYXRlZCBDbGllbnQgQ2VydGlmaWNhdGUwHQYDVR0O BBYEFLElmNWeVgsBPe7O8NiBzjvjYnpRMIHKBgNVHSMEgcIwgb+AFF3AXsKnjdPND5+bxVEC GKtc047PoYGRpIGOMIGLMQswCQYDVQQGEwJVUzEQMA4GA1UECAwHRmxvcmlkYTESMBAGA1UE BwwJTmljZXZpbGxlMRkwFwYDVQQKDBBDdWRhIFN5c3RlbXMgTExDMRgwFgYDVQQLDA9DdWRh IFN5c3RlbXMgQ0ExITAfBgNVBAMMGEN1ZGEgU3lzdGVtcyBMTEMgMjAxNyBDQYITAORIioIQ zl6738WMYyE12A3YSDAdBgNVHREEFjAUgRJrYXJsQGRlbm5pbmdlci5uZXQwDQYJKoZIhvcN AQELBQADggIBAJXboPFBMLMtaiUt4KEtJCXlHO/3ZzIUIw/eobWFMdhe7M4+0u3te0sr77QR dcPKR0UeHffvpth2Mb3h28WfN0FmJmLwJk+pOx4u6uO3O0E1jNXoKh8fVcL4KU79oEQyYkbu 2HwbXBU9HbldPOOZDnPLi0whi/sbFHdyd4/w/NmnPgzAsQNZ2BYT9uBNr+jZw4SsluQzXG1X lFL/qCBoi1N2mqKPIepfGYF6drbr1RnXEJJsuD+NILLooTNf7PMgHPZ4VSWQXLNeFfygoOOK FiO0qfxPKpDMA+FHa8yNjAJZAgdJX5Mm1kbqipvb+r/H1UAmrzGMbhmf1gConsT5f8KU4n3Q IM2sOpTQe7BoVKlQM/fpQi6aBzu67M1iF1WtODpa5QUPvj1etaK+R3eYBzi4DIbCIWst8MdA 1+fEeKJFvMEZQONpkCwrJ+tJEuGQmjoQZgK1HeloepF0WDcviiho5FlgtAij+iBPtwMuuLiL shAXA5afMX1hYM4l11JXntle12EQFP1r6wOUkpOdxceCcMVDEJBBCHW2ZmdEaXgAm1VU+fnQ qS/wNw/S0X3RJT1qjr5uVlp2Y0auG/eG0jy6TT0KzTJeR9tLSDXprYkN2l/Qf7/nT6Q03qyE QnnKiBXWAZXveafyU/zYa7t3PTWFQGgWoC4w6XqgPo4KV44OMYIFBzCCBQMCAQEwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBglghkgBZQMEAgMFAKCCAkUw GAYJKoZIhvcNAQkDMQsGCSqGSIb3DQEHATAcBgkqhkiG9w0BCQUxDxcNMTgwNjE3MTkwNDA1 WjBPBgkqhkiG9w0BCQQxQgRAjd3wL/recctE/Zdj59iiM6cM322Dm+exFm6MwlUcpuXTNF6I 2wLJTnm6oEjEt6PWT23Gc+nH/b41PQMJ7uri2DBsBgkqhkiG9w0BCQ8xXzBdMAsGCWCGSAFl AwQBKjALBglghkgBZQMEAQIwCgYIKoZIhvcNAwcwDgYIKoZIhvcNAwICAgCAMA0GCCqGSIb3 DQMCAgFAMAcGBSsOAwIHMA0GCCqGSIb3DQMCAgEoMIGjBgkrBgEEAYI3EAQxgZUwgZIwezEL MAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lzdGVtcyBM TEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0ZW1zIExM QyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTCBpQYLKoZIhvcNAQkQAgsxgZWg gZIwezELMAkGA1UEBhMCVVMxEDAOBgNVBAgMB0Zsb3JpZGExGTAXBgNVBAoMEEN1ZGEgU3lz dGVtcyBMTEMxGDAWBgNVBAsMD0N1ZGEgU3lzdGVtcyBDQTElMCMGA1UEAwwcQ3VkYSBTeXN0 ZW1zIExMQyAyMDE3IEludCBDQQITAKDRa9XB6SMYWI7rZJyQXB6nPTANBgkqhkiG9w0BAQEF AASCAgAdIJinV1WfNPxNs7/H0TP4M+LzTa7ItoWxeJ+Pob3KEstTKE3Nde2j7q0LamC7lC4w LTaJz6kTEbaw7Nr/CLBAu3dlV1Md3AicjliD4A4qzYmyk8TibWQzojAZM+zXzS8XmjZWaed5 VnsbYm9mMfs+Q45d612F05LGs81R26V3LTgo+6dDCchgVY6xmPb2/rm2ydlxK25RWyKWpyYS Q7sVFlArKLgqIJq1VrPHNpJFCMlwCAFzDMFG8H+yX+E9V5U7zKfNP1UEhGM2UWklLLIqSsXn opicGrHkkQi0QfT/QtmdVviaI+15mYlJZ8MyN0Wa/5mQLuDb6OYydcmKhNTzmTXlCNi7o1rA XNfwM2sJkhMVzDKIrgD9/u/cG52mPzTqL+JZihDbfv0Sz8FDeffJ+ihgF+cm3gg7Hv9TMoiT N/6h+Nyb2OYdncml9F4nD+7IXHJJRSjrDvmVM+NeXDU+1hKRpDfKBrfomn+/fQ4tmWuOPCDB dH2Z7QSTcrCqZkLAHBVb9aXQrJWLbrkH/cGUHIhBQhGe5EmGaD6iqdeKEw+hTfI5Fe0bVHt5 8ldHVRJr0ut5pkvC4uSsH9zyfM2ght2TDTEz9eVpo+9ePxXS76gD/kc3jssMl/XTUvgjjKNW mhLqf7Hc8h8LG2Fejm2pOkKKi/av75e2tMa6w15hGAAAAAAAAA== --------------ms060509030403020603050802-- From owner-freebsd-arm@freebsd.org Sun Jun 17 20:35:28 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 557F01008E93 for ; Sun, 17 Jun 2018 20:35:28 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound1a.eu.mailhop.org (outbound1a.eu.mailhop.org [52.58.109.202]) (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 D4CCE7DCC0 for ; Sun, 17 Jun 2018 20:35:27 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: f504dcd4-726d-11e8-afd2-4ddcc8249dd4 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound1.eu.mailhop.org (Halon) with ESMTPSA id f504dcd4-726d-11e8-afd2-4ddcc8249dd4; Sun, 17 Jun 2018 20:35:23 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5HKZLsq073029; Sun, 17 Jun 2018 14:35:21 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529267721.20460.29.camel@freebsd.org> Subject: Re: Raspberry Pi 2B and SSD drive From: Ian Lepore To: Per olof Ljungmark Cc: freebsd-arm@freebsd.org Date: Sun, 17 Jun 2018 14:35:21 -0600 In-Reply-To: <8f6c49b1-13e0-acf7-192d-1c7ccef95363@nethead.se> References: <8f6c49b1-13e0-acf7-192d-1c7ccef95363@nethead.se> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 20:35:28 -0000 On Sun, 2018-06-17 at 20:33 +0200, Per olof Ljungmark wrote: > On 06/17/18 18:26, Warner Losh wrote: > > > > On Sun, Jun 17, 2018, 7:46 AM Karl Denninger wrote: > > > > > > > > On 6/17/2018 08:21, Per olof Ljungmark wrote: > > > > > > > > FBSD 11.2-RC1 > > > > > > > > How can I make good use of a USB SSD drive connected to the Pi? > > > > > > > > For instance, can I start from the SD card and then hand over everything > > > > to the SSD drive? From googling it does look like it is possible. > > > > > > > > Thanks! > > > > > > > Yes, but.... > > > > > > The but being that it's still USB attached and won't be nearly as fast > > > as you expect. > > > > > Yes. You'll need a A20 based board or similar with built in SATA ports to > > get good speed. The RPi are good cheap boards, but they aren't so good for > > file servers or other applications needing high bandwidth. > > > I am not after speed, I am after greater reliability than what the SD > card can offer. The Pi will do duty as a simple SMTP server and I have > already tested with the SD card only and speed is good enough. I'm not sure why you think an sdcard is somehow unreliable. I ran an smtp+pop+imap server with both the primary and backup "disks" being sdcards for about 7 years, without a single glitch that entire time. I recently replaced the whole server with one that has a builtin mSata drive, but sdcard is still my backup solution for that machine since it has a builtin slot. At $work we ship products that use sdcards as their only storage device, and many of those products have a nominal 20-year service life. So far the longest that one has been in the field is 12 years, but we have had zero sdcard failures (with the exception of one embarassing incident where a whole batch of sdcards went bad in the first couple months of use, apparently because somewhere in the supply chain a batch of low-quality greymarket cards snuck in). As to the basic question of how to boot an rpi from a usb drive, my advice would be to have u-boot and ubldr.bin on an sdcard (just use the standard download image), and keep the kernel and all other filesystems on the usb drive. To make that work, there needs to be a "usb start" command that happens in u-boot before ubldr.bin is launched, and you need to "setenv loaderdev usb". -- Ian From owner-freebsd-arm@freebsd.org Sun Jun 17 21:00:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 192A91009D70 for ; Sun, 17 Jun 2018 21:00:25 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 820617EF68 for ; Sun, 17 Jun 2018 21:00:24 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id C192D19485 for ; Sun, 17 Jun 2018 21:00:23 +0000 (UTC) (envelope-from bugzilla-noreply@FreeBSD.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w5HL0Nwp017807 for ; Sun, 17 Jun 2018 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Received: (from bugzilla@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w5HL0N3L017804 for freebsd-arm@FreeBSD.org; Sun, 17 Jun 2018 21:00:23 GMT (envelope-from bugzilla-noreply@FreeBSD.org) Message-Id: <201806172100.w5HL0N3L017804@kenobi.freebsd.org> X-Authentication-Warning: kenobi.freebsd.org: bugzilla set sender to bugzilla-noreply@FreeBSD.org using -f From: bugzilla-noreply@FreeBSD.org To: freebsd-arm@FreeBSD.org Subject: Problem reports for freebsd-arm@FreeBSD.org that need special attention Date: Sun, 17 Jun 2018 21:00:23 +0000 MIME-Version: 1.0 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 21:00:25 -0000 To view an individual PR, use: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=(Bug Id). The following is a listing of current problems submitted by FreeBSD users, which need special attention. These represent problem reports covering all versions including experimental development code and obsolete releases. Status | Bug Id | Description ------------+-----------+--------------------------------------------------- New | 220297 | arch(7) rename arm64 to aarch64 respecting `uname 1 problems total for which you should take action. From owner-freebsd-arm@freebsd.org Sun Jun 17 21:11:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 82AF6100ADE4 for ; Sun, 17 Jun 2018 21:11:07 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (muon.bluestop.org [96.73.9.1]) (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 221787FE5B for ; Sun, 17 Jun 2018 21:11:06 +0000 (UTC) (envelope-from rebecca@bluestop.org) Received: from muon.bluestop.org (localhost [127.0.0.1]) by muon.bluestop.org (Postfix) with ESMTP id C501849466 for ; Sun, 17 Jun 2018 15:11:13 -0600 (MDT) Received: from muon.bluestop.org ([127.0.0.1]) by muon.bluestop.org (muon.bluestop.org [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id xasMSI7X1mUU for ; Sun, 17 Jun 2018 15:11:13 -0600 (MDT) Received: from [10.0.10.161] (gw.bluestop.org [96.73.9.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by muon.bluestop.org (Postfix) with ESMTPSA for ; Sun, 17 Jun 2018 15:11:13 -0600 (MDT) To: freebsd-arm From: Rebecca Cran Subject: Raspberry Pi Model B (1st vs 3rd gen) Message-ID: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> Date: Sun, 17 Jun 2018 15:11:00 -0600 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 21:11:07 -0000 I noticed on https://www.freebsd.org/where.html that there's a download for "RPI-B" (also mentioned at https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). It's obvious if you know the history (it was just the "Raspberry Pi Model B" and not the "Raspberry Pi 1 Model B") or look at the architecture in the download link (armv6) - but since there's now a "Model B" for the 3rd generation of boards, could we do what https://www.raspberrypi.org/products/ has done and add the generation number to any links/descriptions? -- Rebecca Cran From owner-freebsd-arm@freebsd.org Sun Jun 17 23:58:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 76813100F519 for ; Sun, 17 Jun 2018 23:58:40 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from mx6-out12.antispamcloud.com (mx6-out12.antispamcloud.com [95.211.2.203]) (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 D5B7D85E01 for ; Sun, 17 Jun 2018 23:58:39 +0000 (UTC) (envelope-from freebsd.ed.lists@sumeritec.com) Received: from [153.92.8.106] (helo=srv31.niagahoster.com) by mx64.antispamcloud.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89) (envelope-from ) id 1fUhZ0-0009tQ-0b; Mon, 18 Jun 2018 01:58:32 +0200 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=sumeritec.com; s=default; h=Content-Transfer-Encoding:Content-Type: MIME-Version:References:In-Reply-To:Message-ID:Subject:Cc:To:From:Date:Sender :Reply-To: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=+E2EIMhQ1JtnZTk7ZFgwWNko+Zp3IL6JtNIV+RquTLE=; b=TljIXXGz5wKCvW0yzGVrlE15l3 xN3QOnTSRjZwYmrHzHinMGPZz13Ga8+RKnMNl1gE8rfBdgu9I1nOcr5maWWVYkVc0Rz/gReEZ8KHD cYyruE3l3367x/Pr0Wt7/gr4JfodW8/xt8oP3MceKw/M3l+NSmM+GXSz1kmqz08ro5OKbax9EMzF+ +6g3MkF7hubfAJI7aou1oNzrqYTHhafrz44d0XGk7QlPg8ufu4jz+CJ3pf/YC5e43Z6xaP7qu/Cec dkuuWFgIvNCUJEHx90TCp+9+vNsnPsgYyqsqBgLsaKmmB/9qRWgs3iNPvzreB+TN+/1xDXIo8bUTW mvoESjWA==; Received: from [114.125.120.9] (port=58777 helo=X220.sumeritec.com) by srv31.niagahoster.com with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.89_1) (envelope-from ) id 1fUhYB-0005hB-Ll; Mon, 18 Jun 2018 06:57:42 +0700 Date: Mon, 18 Jun 2018 07:57:37 +0800 From: Erich Dollansky To: Rebecca Cran Cc: freebsd-arm Subject: Re: Raspberry Pi Model B (1st vs 3rd gen) Message-ID: <20180618075737.1a56dd6a.freebsd.ed.lists@sumeritec.com> In-Reply-To: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> References: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-OutGoing-Spam-Status: No, score=-1.0 X-AuthUser: freebsd.ed.lists@sumeritec.com X-Originating-IP: 153.92.8.106 X-AntiSpamCloud-Domain: out.niagahoster.com X-AntiSpamCloud-Username: niaga Authentication-Results: antispamcloud.com; auth=pass (login) smtp.auth=niaga@out.niagahoster.com X-AntiSpamCloud-Outgoing-Class: unsure X-AntiSpamCloud-Outgoing-Evidence: Combined (0.10) X-Recommended-Action: accept X-Filter-ID: EX5BVjFpneJeBchSMxfU5iwXp4BbJxppajl9sV9jcIx602E9L7XzfQH6nu9C/Fh9KJzpNe6xgvOx q3u0UDjvO8jQw5caK8IwZABiZKWeLhcpiENSU9LwDW8ZOXGe81awHIlKB3lhAPsqnFKTCP/MYy0q H/RI+UppDmZcjEC5USjkBVIZkFhCNgRdyBR5LOUkIeebqmNzITIBQB6uQcT8T1Wvx4/5aan/L8AH YrKyAYN5e4ybSGzS9KfGh8zW0MdMK9tLbEmaBmPsQT3aIsBQFVV/a2W6v0kBTOTssGG04/WGbxeN FDWVOXj6Y6ruIh9sKNZe/k0K3IChzid4Dxyja3bwQEeqdiLXJYHgJzfhaOlEDBffVZVjmVaNbG4Z JG7FYTGAEpH4i5yCagzIeXQ1Z7wz2MpogAD7xcut2fULfiLavr9ZeziRMVMQY2DtQVwLwIKgmomx /w0lkMMz3v1CUeWBOXp8nHKe0R+FkIqN7hkzc8fJy+zvdR6g6rtfYMVqVgW9/bktU41htiJ8fk7N kFpKIxrnUNn8Kw10IXx0Njyu51a4mYCGb5aYUpZ7NJBexiGu5p/pZKWI4gyuH22OSMpYjw3SpwiZ CpJ5vqdKVn0DnT/WOnMHRSukXiNLS5F/zWRfIqjy/UwfKhD46+PmjZ4keUpm7RmAZ+9XfQABpMoA EiHu8ZhCChRlnKWnZpS54LSZoIZde+3uPdV9etEiA8zJISPt/AvPfecye3y/ZUA1RalDwJQgBpmX a8cH4xBMy73MOqrXLABRanOiIktAS0GbOIlwP6U7nXQC9ighjoxY+b9ixPPW74g+kIpEo1csJyrJ B6q62m5zoTwwfO6oRCmBbeacOPnHEOWEFwOLsKX+0BWXgkXg4qhoZcXVnyJVjttAJ9vYj8Ojq5f6 ZTCiNY0p+LNPk4iPol61HlTzCg9WBb39uS1TjWG2Inx+Ts2Q0IhWJgCi1I5NpHyY7bC62Uk1f3Xo tzgoeKtj35zl+Z6vMdqIruBDTSEq9qNmK7Uo X-Report-Abuse-To: spam@quarantine1.antispamcloud.com X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 17 Jun 2018 23:58:40 -0000 Hi, On Sun, 17 Jun 2018 15:11:00 -0600 Rebecca Cran wrote: > I noticed on https://www.freebsd.org/where.html that there's > download for "RPI-B" (also mentioned at > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). It's obvious if > you know the history (it was just the "Raspberry Pi Model B" and not > the "Raspberry Pi 1 Model B") or look at the architecture in the > download link (armv6) - but since there's now a "Model B" for the 3rd > generation of boards, could we do what > https://www.raspberrypi.org/products/ has done and add the generation > number to any links/descriptions? > this is a good idea. Erich From owner-freebsd-arm@freebsd.org Mon Jun 18 00:31:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C555B1010090 for ; Mon, 18 Jun 2018 00:31:33 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id EF25286A99 for ; Mon, 18 Jun 2018 00:31:32 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5I0Q9KA025461 for ; Mon, 18 Jun 2018 10:26:10 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: Raspberry Pi Model B (1st vs 3rd gen) To: freebsd-arm References: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> From: Trev Message-ID: Date: Mon, 18 Jun 2018 10:26:09 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Mon, 18 Jun 2018 10:26:10 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 00:31:33 -0000 Rebecca Cran wrote on 18/06/2018 07:11: > I noticed on https://www.freebsd.org/where.html that there's a download > for "RPI-B" (also mentioned at > https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). It's obvious if > you know the history (it was just the "Raspberry Pi Model B" and not the > "Raspberry Pi 1 Model B") or look at the architecture in the download > link (armv6) - but since there's now a "Model B" for the 3rd generation > of boards, could we do what https://www.raspberrypi.org/products/ has > done and add the generation number to any links/descriptions? Good idea - and talking of the wiki, this line under external displays: "After writing the bootable image to the **compact flash** card, " looks a little suspicious :) From owner-freebsd-arm@freebsd.org Mon Jun 18 01:13:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51DFA101101B for ; Mon, 18 Jun 2018 01:13:50 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) Received: from cope.tawonga.bunyatech.com.au (2001-44b8-4170-0a00-0000-0000-0000-0002.static.ipv6.internode.on.net [IPv6:2001:44b8:4170:a00::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "150.101.221.139", Issuer "Bunya Technology Certification Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7264E87CBD for ; Mon, 18 Jun 2018 01:13:49 +0000 (UTC) (envelope-from bscott@bunyatech.com.au) X-Clacks-Overhead: GNU Terry Pratchett Received: from DHCP.tawonga.bunyatech.com.au (DHCP.tawonga.bunyatech.com.au [10.0.1.78] (may be forged)) (authenticated bits=0) by cope.tawonga.bunyatech.com.au (8.15.2/8.15.2/MSA) with ESMTPSA id w5I1DfON020426 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=OK); Mon, 18 Jun 2018 11:13:42 +1000 (AEST) (envelope-from bscott@bunyatech.com.au) Subject: Re: Raspberry Pi 2B and SSD drive To: Per olof Ljungmark , freebsd-arm@FreeBSD.org References: <2f135d3f-8175-aecb-006f-424b876a5bce@nethead.se> From: Brian Scott Message-ID: <5403d66f-929e-2abd-24e0-02eac395e3aa@bunyatech.com.au> Date: Mon, 18 Jun 2018 11:13:41 +1000 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <2f135d3f-8175-aecb-006f-424b876a5bce@nethead.se> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 01:13:50 -0000 Hi, I'm doing this with a spinning USB disk at the moment on my Raspberry-Pi 3. I never managed to make it work on my (256MB) RPi-B but suspect the problem was with the powered USB hub that I needed to use to power the disk. I have the /boot and /boot/msdos partitions on the sdcard and everything else on the USB attached disk. In the loader.conf file on the /boot partition I have: vfs.root.mountfrom="ufs:/dev/ufs/pi3_hdd" (pi3_hdd is the label I put on the ufs partition on the hard drive) I also have a directory on /boot called boot that contains hard links back to the files in /boot and symlinks to the directories on /boot. This gets me around the problem that when booting, the /boot partition is effectively the root partition for finding files and the loader seems to have some embedded /boot/.... file paths in it. In /etc/fstab I have: /dev/ufs/pi3_hdd   /       ufs     rw      1       1 /dev/ufs/pi3_boot   /boot   ufs     rw      1       2 /dev/msdosfs/PI3_MSDOS /boot/msdos msdosfs rw,noatime 1 3 /dev/label/pi3_swap    none    swap    sw     0       0 tmpfs /tmp      tmpfs   rw,mode=1777,size=50m   0       0 (I also have a swap partition on the usb drive that I have glabelled pi3_swap). I'm strongly considering moving /boot and /boot/msdos to be read only to further reduce any possibility of wear although it's very unusual for any write activity there anyway. I have a shell script that shuffles a snapshot image around into the two images (sd card and hdd) if you are interested. Hope this helps, Brian On 18/6/18 1:10 am, Per olof Ljungmark wrote: > FBSD 11.2-RC1 > > How can I make good use of a USB SSD drive connected to the Pi? > > For instance, can I start from the SD card and then hand over everything > to the SSD drive? From googling it does look like it is possible. > > Thanks! > > ... > > Yes, but.... > > The but being that it's still USB attached and won't be nearly as fast > as you expect. > > ... > > Subscribed to the list now... > > I am not concerned about the performance, it is the wear. > > So, how do one load the OS from the SSD? I suppose I could boot the OS > from the SD card and place most other filesystems on the SSD but would > prefer to load the OS from the SSD drive. > > Have a feeling the mysterious /boot/msdos/config.txt is involved but I > fail to locate any documentation, if there is one? > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Mon Jun 18 02:08:33 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D7250101276D for ; Mon, 18 Jun 2018 02:08:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic312-23.consmr.mail.gq1.yahoo.com (sonic312-23.consmr.mail.gq1.yahoo.com [98.137.69.204]) (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 6071F694F4 for ; Mon, 18 Jun 2018 02:08:32 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: wr.jyQwVM1kL9pcEtnZA1pr_UJLdfaD2S.4er_dVsQDCYVfRTfYgybe7Gf0Tpaw xdlBxOVmyReHm3xSY7xydezJCNiIM4q6Z8Ejs.iHf_MtybKbadImdQIWveVDFtD9oJDGNYQKEVtM qM6lmwRyqCyTJvhZSc8auhZ8zeZxbpStc.BTWUvX37pkq7aLRm03pX89Hl0Nzf_i5HwIv2kTncwO 3LsiyRPeclFk8t4S_DG7tT2x8D49ST3zFNFCWGxNZ.LDVC4z7DPrCXLkdAqpJ_LwGiDUJ9w5IslV 5udyYPPEsxOsGhkSExG9WaEy8B2.4z8Y96lg7BtfbQ660hDEbj_Q8MGMV7YqDWLTAJKpojMlYOHv ._q5wwKLOApWuY7NsiogentE5TQgJHdBzwpFZmgfhqhP9q01prnFprbfCZ2AJfFAX9Gg3GgqNFxY 0Ifi2nJVL_L8DUBynRndNmGqMchp__KXUCcERM_CojRw.RPRXE3301bHIQwqBhVn8ga3GgPiK4Yb eGBI9T971a3zPrOv9RNn9RFfN4b8LNIFKF_YUaVuPm_3YEWGLrhk2wlzh3FLBV5ElGPW5vwFolnd G9fUO0xWfb6645VfN6ktL.a5zldNyn5mCBmuZqSbXizi8u.b84g3OIYH.eQSFbUsCISy.36JMPhD jwA20jAMQ6aidEo9EiivXveU4PzzkKYxRyy7iFXhADwMbL6RoiIV6k8GrVOTBxzpX9Ae01SaRXMF UdJUa730iR9p3btWCvAQn5pUkC3PATJxaGY_3WJe53wy2OXAKUnA3LMvjrhnrs8nYtgp.8odXJvR KhrBajEUkM42lRd9Qyinoi5NbdsCNOGVvsMJ0idAt_bjhSVdvJ3RYHvGs.xjZPVeDaiqqQfmXgxo .77k5GGS0WHu45zv4.CgfzHbr8yNmJGjcEdnyiwJYyOGQdDbFsYRTsN4hhKH_EEi5_tdJgOfEenW 9Yu9EEQ-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic312.consmr.mail.gq1.yahoo.com with HTTP; Mon, 18 Jun 2018 02:08:30 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp402.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID bfd88b9a931dda3474c622968423409b; Mon, 18 Jun 2018 02:08:29 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: Raspberry Pi Model B (1st vs 3rd gen) From: Mark Millard In-Reply-To: <20180618075737.1a56dd6a.freebsd.ed.lists@sumeritec.com> Date: Sun, 17 Jun 2018 19:08:27 -0700 Cc: Rebecca Cran , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <67DD5BBC-3569-4D58-AA71-C7753AF8E2B4@yahoo.com> References: <8b489853-a7b9-2aaa-94af-e8b56f5136b9@bluestop.org> <20180618075737.1a56dd6a.freebsd.ed.lists@sumeritec.com> To: Erich Dollansky X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 02:08:33 -0000 On 2018-Jun-17, at 4:57 PM, Erich Dollansky wrote: > Hi, >=20 > On Sun, 17 Jun 2018 15:11:00 -0600 > Rebecca Cran wrote: >=20 >> I noticed on https://www.freebsd.org/where.html that there's=20 >> download for "RPI-B" (also mentioned at=20 >> https://wiki.freebsd.org/FreeBSD/arm/Raspberry%20Pi). It's obvious if=20= >> you know the history (it was just the "Raspberry Pi Model B" and not >> the "Raspberry Pi 1 Model B") or look at the architecture in the >> download link (armv6) - but since there's now a "Model B" for the 3rd >> generation of boards, could we do what >> https://www.raspberrypi.org/products/ has done and add the generation >> number to any links/descriptions? >>=20 > this is a good idea. Be warned for the nomenclature: Raspberry Pi 2 Model B V1.1 is Cortext-A7 (armv7, specifically BSM2836) Raspberry Pi 2 Model B V1.2 is Cortext-A53 (aarch64, specifically = BCM2837) The first is long out of production and various places that still list 2's "model B" as Cortex-A7 actually ship the Cortex-A53 variant. Even: https://www.raspberrypi.org/products/ links to: https://www.raspberrypi.org/products/raspberry-pi-2-model-b/ which describes the original Cortex-A7 version. The "Buy Now" button gives you selections of places selling the Cortex-A53 variant (V1.2) explicitly and others still listing the Cortex-A7 variant (V1.1) explicitly, despite what some ship when you order. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Mon Jun 18 23:04:13 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 740D11004568 for ; Mon, 18 Jun 2018 23:04:13 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E23F878C91 for ; Mon, 18 Jun 2018 23:04:12 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5IN4K1K081377 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 16:04:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5IN4Jxw081376; Mon, 18 Jun 2018 16:04:19 -0700 (PDT) (envelope-from fbsd) Date: Mon, 18 Jun 2018 16:04:19 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180618230419.GA81275@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 23:04:13 -0000 On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > > Since the "multiple swap partitions across multiple > devices" context (my description) is what has problems, > it would be interesting to see swapinfo information > from around the time frame of the failures: how much is > used vs. available on each swap partition? Is only one > being (significantly) used? The small one (1 GiByte)? > There are some preliminary observations at http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_swapinfo/1gbusbflash_1gbsdflash_swapinfo.log If you search for 09:44: (the time of the OOM kills) it looks like both swap partitions are equally used, but only 8% full. At this point I'm wondering if the gstat interval (presently 10 seconds) might well be shortened and the ten second sleep eliminated. On the runs that succeed swap usage changes little in twenty seconds, but the failures seem to to culminate rather briskly. Thanks for reading, and for your help! bob prohaska From owner-freebsd-arm@freebsd.org Mon Jun 18 23:42:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E500D1006454 for ; Mon, 18 Jun 2018 23:42:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic302-22.consmr.mail.ne1.yahoo.com (sonic302-22.consmr.mail.ne1.yahoo.com [66.163.186.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 7E1467A186 for ; Mon, 18 Jun 2018 23:42:24 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: HowYzncVM1mECcnus57RDf8tg3HwhVFPs3.7VXHVbm.Obv2JjRxRo5JJcqzKXRD qqmefl3Fv7kaew3qBqo0XoPB.47Q_yxRQ7RAeSqaEdaeZWxWY3xbGo9RyxuPXlXqSWsPKKanjyPo .jFh6sTrMfHZ.Mj8fEAP4vNrZ_seOQP0nOOnE2_OBWTm6lI33pqo5Xz9AHus7eTewX6EZpJnALHQ Wjcw5JNUMEDFHqxKUbBzu4W4jLK0yBkQC.ckE3cjpdMpwdX2ZXYqRsXwbALK7yxirxIR70tAK7Dl E4Ingg19qCC67DOjqtt4cQkcnDoGcE8HZ0RGlNZAaBPzswt5TZ8mlMtbkWf_y23_68oTEnvZ7IBv jUJqiXMUUFpEcB0DT119IHsXCy2BNXtUE3mTzxHnPm1yRx9HOaKFO7IkCpRIeRiDVH6Mcl_cjfrn of7dTG2DZxiSfb_ZSCoyFmqV9ybdd.y0TVlCPXVpGddeNFlLSeI45IGkyx4Vx_jxHAouwD1pXddR CJO2UO3QXQtfrT7BbuLNQKGATR8XjPcE5EAPHvBsRZPQi4.y4KRw5fSQZNsitDAzswZLBuR4iuLK TXhZJ42shfunPaawSSZLyQHtPOpvJ312lOSspZZc3b5JH74EJReQ3b_EixF4g0QoUhge6MpvEJga lnO1sbpn8Q.sdfHt4zysXF27xLjVB.4Y9Dri0fR3oOjFYY8Jd6bp.dqUYdNgcs8_oJrVN7TKYB5G b4vrJQqHioS9CnClDglscKKr1YgPPJA.9X9rjKRlJ.vwz.m4lwA6SFf1JXRB1XPkLFmD7aClFuca mZWLzYGF0uz1kpNe1JwGdOtzfzM1JtkDee9CBvYPBzqVDtLVWDYQnqOV2LPBtxrBSi2GrLdzw2c4 uyhSBHGtUFpV_.rT9PVz3rmejaWEilW7v0AYhpHCfdi0OBOV1GxknW3fp368ry7qkS8p39R3ZWHt cqXl9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.ne1.yahoo.com with HTTP; Mon, 18 Jun 2018 23:42:23 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp413.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID f77194a64898ad4c22342b0568e0bfa2; Mon, 18 Jun 2018 23:42:23 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180618230419.GA81275@www.zefox.net> Date: Mon, 18 Jun 2018 16:42:21 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jun 2018 23:42:25 -0000 On 2018-Jun-18, at 4:04 PM, bob prohaska wrote: > On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>=20 >> Since the "multiple swap partitions across multiple >> devices" context (my description) is what has problems, >> it would be interesting to see swapinfo information >> from around the time frame of the failures: how much is >> used vs. available on each swap partition? Is only one >> being (significantly) used? The small one (1 GiByte)? >>=20 > There are some preliminary observations at >=20 > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_= swapinfo/1gbusbflash_1gbsdflash_swapinfo.log >=20 > If you search for 09:44: (the time of the OOM kills) it looks like > both swap partitions are equally used, but only 8% full. >=20 > At this point I'm wondering if the gstat interval (presently 10 = seconds) > might well be shortened and the ten second sleep eliminated. On the = runs > that succeed swap usage changes little in twenty seconds, but the = failures > seem to to culminate rather briskly. One thing I find interesting somewhat before the OOM activity is the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along with having 46 or 33 L(q) and large %busy figures in the same lines --and 0 w/s on every line: Mon Jun 18 09:42:05 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 3412 1045164 0% /dev/mmcsd0s3b 1048576 3508 1045068 0% Total 2097152 6920 2090232 0% dT: 10.043s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d Mon Jun 18 09:42:25 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 3412 1045164 0% /dev/mmcsd0s3b 1048576 3508 1045068 0% Total 2097152 6920 2090232 0% The kBps figures for the writes are not very big above. There is an earlier example of something similar, again for da0 and da0d having the large ms/w (and ms/r here): Mon Jun 18 09:32:00 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 3516 1045060 0% /dev/mmcsd0s3b 1048576 3604 1044972 0% Total 2097152 7120 2090032 0% dT: 10.010s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 1 0 0 0.0 1 8 5.4 0 0 = 0.0 0.2 mmcsd0 6 1 0 1 373.9 1 18 1070 0 0 = 0.0 73.6 da0 0 0 0 0 0.0 0 7 6.1 0 0 = 0.0 0.1 mmcsd0s2 0 0 0 0 0.0 0 7 6.1 0 0 = 0.0 0.1 ufs/rootfs 4 1 0 1 373.9 1 18 1243 0 0 = 0.0 73.6 da0d Mon Jun 18 09:32:20 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 3516 1045060 0% /dev/mmcsd0s3b 1048576 3604 1044972 0% Total 2097152 7120 2090032 0% =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 19 00:55:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3DDB100AB23 for ; Tue, 19 Jun 2018 00:55:07 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 239D67D37B for ; Tue, 19 Jun 2018 00:55:06 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5J0tK91081624 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 17:55:21 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5J0tKTX081623; Mon, 18 Jun 2018 17:55:20 -0700 (PDT) (envelope-from fbsd) Date: Mon, 18 Jun 2018 17:55:20 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619005519.GB81275@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 00:55:07 -0000 On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: > > > On 2018-Jun-18, at 4:04 PM, bob prohaska wrote: > > > On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > >> > >> Since the "multiple swap partitions across multiple > >> devices" context (my description) is what has problems, > >> it would be interesting to see swapinfo information > >> from around the time frame of the failures: how much is > >> used vs. available on each swap partition? Is only one > >> being (significantly) used? The small one (1 GiByte)? > >> > > There are some preliminary observations at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_swapinfo/1gbusbflash_1gbsdflash_swapinfo.log > > > > If you search for 09:44: (the time of the OOM kills) it looks like > > both swap partitions are equally used, but only 8% full. > > > > At this point I'm wondering if the gstat interval (presently 10 seconds) > > might well be shortened and the ten second sleep eliminated. On the runs > > that succeed swap usage changes little in twenty seconds, but the failures > > seem to to culminate rather briskly. > > One thing I find interesting somewhat before the OOM activity is > the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along > with having 46 or 33 L(q) and large %busy figures in the same > lines --and 0 w/s on every line: > > Mon Jun 18 09:42:05 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 3412 1045164 0% > /dev/mmcsd0s3b 1048576 3508 1045068 0% > Total 2097152 6920 2090232 0% > dT: 10.043s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0 > 46 0 0 0 0.0 0 16 12355 0 0 0.0 85.9 da0 > 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3 > 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3a > 33 0 0 0 0.0 0 22 12318 0 0 0.0 114.1 da0d > Mon Jun 18 09:42:25 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 3412 1045164 0% > /dev/mmcsd0s3b 1048576 3508 1045068 0% > Total 2097152 6920 2090232 0% > > > The kBps figures for the writes are not very big above. > If it takes 12 seconds to write, I can understand the swapper getting impatient.... However, the delay is on /usr, not swap. In the subsequent 1 GB USB flash-alone test case at http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1gbusbflash_swapinfo.log the worst-case seems to be at time 13:45:00 dT: 13.298s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name 0 0 0 0 0.0 0 5 5.5 0 0 0.0 0.1 mmcsd0 9 84 0 0 0.0 84 1237 59.6 0 0 0.0 94.1 da0 0 0 0 0 0.0 0 5 5.5 0 0 0.0 0.1 mmcsd0s3 0 0 0 0 0.0 0 5 5.6 0 0 0.0 0.1 mmcsd0s3a 5 80 0 0 0.0 80 1235 47.2 0 0 0.0 94.1 da0b 4 0 0 0 0.0 0 1 88.1 0 0 0.0 0.7 da0d Mon Jun 18 13:45:00 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 22872 1025704 2% 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill a process. Thus far I'm baffled. Any suggestions? Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 19 01:31:45 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42411100EB15 for ; Tue, 19 Jun 2018 01:31:45 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic309-15.consmr.mail.bf2.yahoo.com (sonic309-15.consmr.mail.bf2.yahoo.com [74.6.129.125]) (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 DA9157F8C6 for ; Tue, 19 Jun 2018 01:31:44 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: hIRc1BwVM1k0lzW69WzN.J_D9WyMpC1lSXv63isFUmaYtSHQf44i.LPvNWBvRS0 eTsmQoqVo8Rd733cIc6YWxhssc0rVzt3K9PM3bdaFxgKg0egKYZZO6YlgEH2KvdyaOba6U4qF2eq 4qQEPCfIzClyE6lKnOn.Y.AbAdNdGENY2qvmYAE9FTbVqXzo9vP4wnj0ExfDzUTgLOXtDijV6M_t EIYgIDs2ajteODt90AFngmtUk8Fqgele3gy1SKpYNsCnz7wtqprxYe3_Cbp8Jb8JHQXJ63eiMpsA gaGfYiJMgRjj7i_80.m6lxsYAUL.2UObLRloChVTCf_VGUsEBnqe2H3HY4ALkxLabBfBkjcKvsgd 8Y3GfL_._r.K0MWa_DDnVTAvgSKTTUXOSc38fY1HcsgkL_ZKIomNaQZX_c66pyjq9szUlSiZhWP7 LubnJhPUIrTKxvfjkqpZddEL0hZBc1zH2COBwGOoxRfKhwt67XfhNoCZG6On_nT2tvrlbHKD.YfO Pjba.dzWHCK6leZho6KxZul6BMYY_CnTvORsHCij8YQbm7tam98QJ9wN7Ef0Pf3_HL4TvGHZNoWA 4li3oqK0U8C2cHaIq8xEw.YWu3FME8_G8Dn8Hf4beFKyMfXCOps.6TdJqMxsg3SP4yvbUMyHP.dK 8qu18AVaBiKODCfgawU5sa36LXjY2_.OWd4qFC98bz.fPom7xhxqQluIJ77haegpYOtnVUC0BbrF YusJQaewiPH1mPkbm2xD3DpRPK441y4wSVSX9PpDKxou0bpE369D4G5thXAAFjw6z8wqmW2Rq4XN 2XSlMSxDFb9xWbTth3e4NtL6zG5BnOH8MMEhetq3AAq259Gu0yoKdlM76IO_WdWuDxnU9UU29nJ4 SyH0h2htW3OyCx4Wk7On.1.6F6zz5PAdWmXck6TMKNaTYmVP6MnrPW4Rb.uLW6dsiIGeQtTpAHr5 GaZkcJg-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 Jun 2018 01:31:43 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 00590c10d664675a0a1708423a53c4f7; Tue, 19 Jun 2018 01:31:42 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180619005519.GB81275@www.zefox.net> Date: Mon, 18 Jun 2018 18:31:40 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 01:31:45 -0000 On 2018-Jun-18, at 5:55 PM, bob prohaska wrote: > On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: >>=20 >>=20 >> On 2018-Jun-18, at 4:04 PM, bob prohaska = wrote: >>=20 >>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>>>=20 >>>> Since the "multiple swap partitions across multiple >>>> devices" context (my description) is what has problems, >>>> it would be interesting to see swapinfo information >>>> from around the time frame of the failures: how much is >>>> used vs. available on each swap partition? Is only one >>>> being (significantly) used? The small one (1 GiByte)? >>>>=20 >>> There are some preliminary observations at >>>=20 >>> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_= swapinfo/1gbusbflash_1gbsdflash_swapinfo.log >>>=20 >>> If you search for 09:44: (the time of the OOM kills) it looks like >>> both swap partitions are equally used, but only 8% full. >>>=20 >>> At this point I'm wondering if the gstat interval (presently 10 = seconds) >>> might well be shortened and the ten second sleep eliminated. On the = runs >>> that succeed swap usage changes little in twenty seconds, but the = failures >>> seem to to culminate rather briskly. >>=20 >> One thing I find interesting somewhat before the OOM activity is >> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along >> with having 46 or 33 L(q) and large %busy figures in the same >> lines --and 0 w/s on every line: >>=20 >> Mon Jun 18 09:42:05 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >> dT: 10.043s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 >> 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a >> 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d >> Mon Jun 18 09:42:25 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >>=20 >>=20 >> The kBps figures for the writes are not very big above. >>=20 >=20 > If it takes 12 seconds to write, I can understand the swapper getting = impatient.... > However, the delay is on /usr, not swap. >=20 > In the subsequent 1 GB USB flash-alone test case at > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1g= busbflash_swapinfo.log > the worst-case seems to be at time 13:45:00 >=20 > dT: 13.298s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0 > 9 84 0 0 0.0 84 1237 59.6 0 0 = 0.0 94.1 da0 > 0 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0s3 > 0 0 0 0 0.0 0 5 5.6 0 0 = 0.0 0.1 mmcsd0s3a > 5 80 0 0 0.0 80 1235 47.2 0 0 = 0.0 94.1 da0b > 4 0 0 0 0.0 0 1 88.1 0 0 = 0.0 0.7 da0d > Mon Jun 18 13:45:00 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 22872 1025704 2% >=20 > 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill a = process. That is kBps instead of ms/w. I see a ms/w (and ms/r) that is fairly large (but notably smaller than the ms/w of over 12000): Mon Jun 18 13:12:58 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 0 1048576 0% dT: 10.400s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 4 0 0 0.0 4 66 3.4 0 0 = 0.0 1.3 mmcsd0 8 18 1 32 1991 17 938 2529 0 0 = 0.0 88.1 da0 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3a 6 11 1 32 1991 10 938 3207 0 0 = 0.0 94.7 da0d Mon Jun 18 13:13:19 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/da0b 1048576 0 1048576 0% Going in a different direction, I believe that you have reported needing more than 1 GiByte of swap space so the 1048576 "1K-blocks" would not be expected to be sufficient. So the specific failing point may well be odd but the build would not be expected to finish without an OOM for this context if I understand right. > Thus far I'm baffled. Any suggestions? Can you get a failure without involving da0, the drive that is sometimes showing these huge ms/w (and ms/r) figures? (This question presumes having sufficient swap space, so, say, 1.5 GiByte or more total.) Having the partition(s) each be sufficiently sized but for which the total would not produce the notice for too large of a swap space was my original "additional" suggestion. I still want to see what such does as a variation of a failing context. But now it would seem to be a good idea to avoid da0 and its sometimes large ms/w and /ms/r figures. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 19 01:35:41 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2CC81100F54A for ; Tue, 19 Jun 2018 01:35:41 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic317-28.consmr.mail.bf2.yahoo.com (sonic317-28.consmr.mail.bf2.yahoo.com [74.6.129.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 A908C800BA for ; Tue, 19 Jun 2018 01:35:40 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: ywC3BkIVM1lAfFGp_CCwymM9WiGEI4s1VNboTzPfFZhoor4QvYgUygK0EtmlaZK bJXjn__m5Un_lqUF8ND6judyKnyhucMM6HdXCTYU7NkYlTP7y3cOUy5GduWI0uYUdUpcBUdFP6HL zO7VVyNnoyOzbHDp.ic9LFAwNE1fEEWUolFnyDTnFz4AIUBjRewkMhjRSt.WJoUZecgWxXpX1Paw msAOdzI_5i7iQdZh12Ipga86s9vrUjDmY2i0lejmkI3._uV_fyjmcj_n.1tdI0rSZvPRSEWEP_Pp P6tW2GsX64TACkbd6dbjc19VAR00BQ6UGPVyfTT6wAA8oho8cbGm4WVmcDDkta45zz4H.e8C7RvA va4Oz97q3_vgqjCUZ4mbl_OhKoCPLHV5FmSMlWO9FMUVWU7f.fyjywJCwRg4XLO0y1zbxgVsuNlr EiUaNdDFypf7XH4CQMmRfrc6EndlYZhz_T7gYoCa8OPHWrbZOu4Aj.96uLb8zNAS9Phxb5LeXv5i qnAKNCSfvfvyNZP5eVs7eDrEjXn6.qC7neltx6lc4I8MykR.NWqCORiB2xmCwiOnG9aqDMvtpUva 3UeeESXYSRKAOyVc8Crq_1jBmznwHk04lz5wre2zU9xJzIR5Jq.yTpTE1cTd7zo4DSqUUm5iLfDc IzaH.dRcyMG1x7Hbiqx_0rqIWV4kM7EepkY.XNevNw2iJOFRlZh6kxpct872mLNn8Ou5OaTmblAh oZquNZgz1.eZf0x9mycOJhF9v3d0qzEi8R1mM2aOxcqeRBAS_sA2tGmwP7NJnHMlm3m29jzQcr83 NdqKTqSkfSS.WUq_jeP9qleq1yMPyZ3MlVhzxW4MKVewS8p._uezH33jZ7XcE39GvwINWx4q1Hdh 3VLakxDcAToIgxHNqkr0zH3Ae.AUoLl39fzjEGJiObux0l.GSvnVZBr2.TXaj0K9N21tTp0u9fyd K3D1a6g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic317.consmr.mail.bf2.yahoo.com with HTTP; Tue, 19 Jun 2018 01:35:33 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID db0d6207771e9698dd880c4300b50e2e; Tue, 19 Jun 2018 01:35:31 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: Date: Mon, 18 Jun 2018 18:35:29 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 01:35:41 -0000 On 2018-Jun-18, at 6:31 PM, Mark Millard wrote: > On 2018-Jun-18, at 5:55 PM, bob prohaska = wrote: >=20 >> On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: >>>=20 >>>=20 >>> On 2018-Jun-18, at 4:04 PM, bob prohaska = wrote: >>>=20 >>>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>>>>=20 >>>>> Since the "multiple swap partitions across multiple >>>>> devices" context (my description) is what has problems, >>>>> it would be interesting to see swapinfo information >>>>> from around the time frame of the failures: how much is >>>>> used vs. available on each swap partition? Is only one >>>>> being (significantly) used? The small one (1 GiByte)? >>>>>=20 >>>> There are some preliminary observations at >>>>=20 >>>> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_= swapinfo/1gbusbflash_1gbsdflash_swapinfo.log >>>>=20 >>>> If you search for 09:44: (the time of the OOM kills) it looks like >>>> both swap partitions are equally used, but only 8% full. >>>>=20 >>>> At this point I'm wondering if the gstat interval (presently 10 = seconds) >>>> might well be shortened and the ten second sleep eliminated. On the = runs >>>> that succeed swap usage changes little in twenty seconds, but the = failures >>>> seem to to culminate rather briskly. >>>=20 >>> One thing I find interesting somewhat before the OOM activity is >>> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along >>> with having 46 or 33 L(q) and large %busy figures in the same >>> lines --and 0 w/s on every line: >>>=20 >>> Mon Jun 18 09:42:05 PDT 2018 >>> Device 1K-blocks Used Avail Capacity >>> /dev/da0b 1048576 3412 1045164 0% >>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>> Total 2097152 6920 2090232 0% >>> dT: 10.043s w: 10.000s >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >>> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 >>> 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 >>> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 >>> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a >>> 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d >>> Mon Jun 18 09:42:25 PDT 2018 >>> Device 1K-blocks Used Avail Capacity >>> /dev/da0b 1048576 3412 1045164 0% >>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>> Total 2097152 6920 2090232 0% >>>=20 >>>=20 >>> The kBps figures for the writes are not very big above. >>>=20 >>=20 >> If it takes 12 seconds to write, I can understand the swapper getting = impatient.... >> However, the delay is on /usr, not swap. >>=20 >> In the subsequent 1 GB USB flash-alone test case at >> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1g= busbflash_swapinfo.log >> the worst-case seems to be at time 13:45:00 >>=20 >> dT: 13.298s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0 >> 9 84 0 0 0.0 84 1237 59.6 0 0 = 0.0 94.1 da0 >> 0 0 0 0 0.0 0 5 5.5 0 0 = 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 5 5.6 0 0 = 0.0 0.1 mmcsd0s3a >> 5 80 0 0 0.0 80 1235 47.2 0 0 = 0.0 94.1 da0b >> 4 0 0 0 0.0 0 1 88.1 0 0 = 0.0 0.7 da0d >> Mon Jun 18 13:45:00 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 22872 1025704 2% >>=20 >> 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill = a process. >=20 > That is kBps instead of ms/w. >=20 > I see a ms/w (and ms/r) that is fairly large (but notably > smaller than the ms/w of over 12000): >=20 > Mon Jun 18 13:12:58 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% > dT: 10.400s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 4 0 0 0.0 4 66 3.4 0 0 = 0.0 1.3 mmcsd0 > 8 18 1 32 1991 17 938 2529 0 0 = 0.0 88.1 da0 > 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3 > 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3a > 6 11 1 32 1991 10 938 3207 0 0 = 0.0 94.7 da0d > Mon Jun 18 13:13:19 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% >=20 >=20 > Going in a different direction, I believe that you have > reported needing more than 1 GiByte of swap space so the > 1048576 "1K-blocks" would not be expected to be sufficient. > So the specific failing point may well be odd but the build > would not be expected to finish without an OOM for this > context if I understand right. >=20 >> Thus far I'm baffled. Any suggestions? >=20 > Can you get a failure without involving da0, the drive that is > sometimes showing these huge ms/w (and ms/r) figures? (This question > presumes having sufficient swap space, so, say, 1.5 GiByte or more > total.) >=20 > Having the partition(s) each be sufficiently sized but for which > the total would not produce the notice for too large of a swap > space was my original "additional" suggestion. I still want to > see what such does as a variation of a failing context. But now > it would seem to be a good idea to avoid da0 and its sometimes > large ms/w and /ms/r figures. >=20 One more point: I'd suggest avoiding da0 for holding any log files or other such files that are being updated and used: Avoid da0 as much as possible, not just its swap partition(s). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 19 02:34:34 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CC86710156DD for ; Tue, 19 Jun 2018 02:34:34 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 02C9684510 for ; Tue, 19 Jun 2018 02:34:33 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5J2YNGB072795 for ; Tue, 19 Jun 2018 12:34:24 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices Cc: freebsd-arm@freebsd.org References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> From: Trev Message-ID: Date: Tue, 19 Jun 2018 12:34:23 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Tue, 19 Jun 2018 12:34:24 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 02:34:35 -0000 Mark Millard via freebsd-arm wrote on 19/06/2018 11:31: > Going in a different direction, I believe that you have > reported needing more than 1 GiByte of swap space so the > 1048576 "1K-blocks" would not be expected to be sufficient. > So the specific failing point may well be odd but the build > would not be expected to finish without an OOM for this > context if I understand right. Just for reference, with the 32 bit Rpi2, my peak swap usage (with nothing much other than make -j4 buildworld running) is 1.424GB. From owner-freebsd-arm@freebsd.org Tue Jun 19 03:42:19 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9987F101A0C9 for ; Tue, 19 Jun 2018 03:42:19 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 115AA8769E for ; Tue, 19 Jun 2018 03:42:18 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5J3gWIY085791 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 20:42:33 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5J3gWkt085790; Mon, 18 Jun 2018 20:42:32 -0700 (PDT) (envelope-from fbsd) Date: Mon, 18 Jun 2018 20:42:32 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619034232.GA81800@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 03:42:19 -0000 On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: > On 2018-Jun-18, at 5:55 PM, bob prohaska wrote: > > > On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: > >> > >> > >> On 2018-Jun-18, at 4:04 PM, bob prohaska wrote: > >> > >>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > >>>> > >>>> Since the "multiple swap partitions across multiple > >>>> devices" context (my description) is what has problems, > >>>> it would be interesting to see swapinfo information > >>>> from around the time frame of the failures: how much is > >>>> used vs. available on each swap partition? Is only one > >>>> being (significantly) used? The small one (1 GiByte)? > >>>> > >>> There are some preliminary observations at > >>> > >>> http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_swapinfo/1gbusbflash_1gbsdflash_swapinfo.log > >>> > >>> If you search for 09:44: (the time of the OOM kills) it looks like > >>> both swap partitions are equally used, but only 8% full. > >>> > >>> At this point I'm wondering if the gstat interval (presently 10 seconds) > >>> might well be shortened and the ten second sleep eliminated. On the runs > >>> that succeed swap usage changes little in twenty seconds, but the failures > >>> seem to to culminate rather briskly. > >> > >> One thing I find interesting somewhat before the OOM activity is > >> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along > >> with having 46 or 33 L(q) and large %busy figures in the same > >> lines --and 0 w/s on every line: > >> > >> Mon Jun 18 09:42:05 PDT 2018 > >> Device 1K-blocks Used Avail Capacity > >> /dev/da0b 1048576 3412 1045164 0% > >> /dev/mmcsd0s3b 1048576 3508 1045068 0% > >> Total 2097152 6920 2090232 0% > >> dT: 10.043s w: 10.000s > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0 > >> 46 0 0 0 0.0 0 16 12355 0 0 0.0 85.9 da0 > >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3 > >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3a > >> 33 0 0 0 0.0 0 22 12318 0 0 0.0 114.1 da0d > >> Mon Jun 18 09:42:25 PDT 2018 > >> Device 1K-blocks Used Avail Capacity > >> /dev/da0b 1048576 3412 1045164 0% > >> /dev/mmcsd0s3b 1048576 3508 1045068 0% > >> Total 2097152 6920 2090232 0% > >> > >> > >> The kBps figures for the writes are not very big above. > >> > > > > If it takes 12 seconds to write, I can understand the swapper getting impatient.... > > However, the delay is on /usr, not swap. > > > > In the subsequent 1 GB USB flash-alone test case at > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1gbusbflash_swapinfo.log > > the worst-case seems to be at time 13:45:00 > > > > dT: 13.298s w: 10.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > > 0 0 0 0 0.0 0 5 5.5 0 0 0.0 0.1 mmcsd0 > > 9 84 0 0 0.0 84 1237 59.6 0 0 0.0 94.1 da0 > > 0 0 0 0 0.0 0 5 5.5 0 0 0.0 0.1 mmcsd0s3 > > 0 0 0 0 0.0 0 5 5.6 0 0 0.0 0.1 mmcsd0s3a > > 5 80 0 0 0.0 80 1235 47.2 0 0 0.0 94.1 da0b > > 4 0 0 0 0.0 0 1 88.1 0 0 0.0 0.7 da0d > > Mon Jun 18 13:45:00 PDT 2018 > > Device 1K-blocks Used Avail Capacity > > /dev/da0b 1048576 22872 1025704 2% > > > > 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill a process. > > That is kBps instead of ms/w. > > I see a ms/w (and ms/r) that is fairly large (but notably > smaller than the ms/w of over 12000): > > Mon Jun 18 13:12:58 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% > dT: 10.400s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 0 4 0 0 0.0 4 66 3.4 0 0 0.0 1.3 mmcsd0 > 8 18 1 32 1991 17 938 2529 0 0 0.0 88.1 da0 > 0 4 0 0 0.0 4 63 3.5 0 0 0.0 1.3 mmcsd0s3 > 0 4 0 0 0.0 4 63 3.5 0 0 0.0 1.3 mmcsd0s3a > 6 11 1 32 1991 10 938 3207 0 0 0.0 94.7 da0d > Mon Jun 18 13:13:19 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 0 1048576 0% > > Yes, but again, it's on /usr, not swap. One could argue that there are other write delays, not seen here, that do affect swap. To forestall that objection I'll get rid of the ten second sleep in the script when the present test run finishes. > Going in a different direction, I believe that you have > reported needing more than 1 GiByte of swap space so the > 1048576 "1K-blocks" would not be expected to be sufficient. > So the specific failing point may well be odd but the build > would not be expected to finish without an OOM for this > context if I understand right. > Yes, the actual swap requirement seems to be slightly over 1.4 GB at the peak based on other tests. I fully expected a failure, but at a much higher swap utilization. > > Thus far I'm baffled. Any suggestions? > > Can you get a failure without involving da0, the drive that is > sometimes showing these huge ms/w (and ms/r) figures? (This question > presumes having sufficient swap space, so, say, 1.5 GiByte or more > total.) > If you mean not using da0, no; it holds /usr. If you mean not swapping to da0, yes it's been done. Having 3 GB swap on microSD works. Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical USB swap. That's easy to try. > Having the partition(s) each be sufficiently sized but for which > the total would not produce the notice for too large of a swap > space was my original "additional" suggestion. I still want to > see what such does as a variation of a failing context. I'm afraid you've lost me here. With two partitions, one USB and the other SD of one GB each OOM kills happen at 8% utilization, spread evenly across both. Does the size of the partition affect the speed of it? Capacity does not seem the problem. > it would seem to be a good idea to avoid da0 and its sometimes > large ms/w and /ms/r figures. > I think the next experiment will be to use 1 GB of SD swap and 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, and we know the USB mechanical swap is fast enough. If that combination works, maybe the trouble is congestion on da0. If the combo fails as before I'll be tempted to think it's USB or the swapper. Thanks for reading! bob prohaska > > From owner-freebsd-arm@freebsd.org Tue Jun 19 04:00:05 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 09DEF101B1A0 for ; Tue, 19 Jun 2018 04:00:05 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 7BDD887EDD for ; Tue, 19 Jun 2018 04:00:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5J40Iig085850 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 21:00:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5J40HRP085849; Mon, 18 Jun 2018 21:00:17 -0700 (PDT) (envelope-from fbsd) Date: Mon, 18 Jun 2018 21:00:17 -0700 From: bob prohaska To: Trev Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619040017.GB81800@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:00:05 -0000 On Tue, Jun 19, 2018 at 12:34:23PM +1000, Trev wrote: > > Just for reference, with the 32 bit Rpi2, my peak swap usage (with > nothing much other than make -j4 buildworld running) is 1.424GB. That's a surprise, I thought it would be much less. What is your swap and storage configuration? Thanks! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 19 04:05:31 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 257DC101B768 for ; Tue, 19 Jun 2018 04:05:31 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22b.google.com (mail-it0-x22b.google.com [IPv6:2607:f8b0:4001:c0b::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id ADBFE682E4 for ; Tue, 19 Jun 2018 04:05:30 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22b.google.com with SMTP id j135-v6so15242922itj.1 for ; Mon, 18 Jun 2018 21:05:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=sUhq158ZabJvVFOwv8J1NjsQjzIoAJl3QMYzpmmmjaI=; b=LG32Wck/Bj3albZC0y3gM95MM/+EA8vvVKshptA9+eapAe0oztRdNXT+isRXg1org+ /Urtb9nUqXeshLq1ubIVnBq6xu9ayQhwXXXMauihlRxyNypdG9y39lLkyubs8myeCjKU gWMdu+5WAq+WLlB8GvWYoOACjmnXFQhxZ+Rl0SKGolSvXYok6LRZIfGBFU/m7RreAzbj tUTvS7yfLoMH4Rel8XKNJPyOYwt3DyKMjHpMB+0I3aTruIiuisxUItnFzC6K8pB+hmlC taayAo3F3e6+KGNy2o+0rCSRt01CnSrXn1F7AngDWhHE5fj/BkIBR3kNnIRdGB7T4TP9 WOXw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=sUhq158ZabJvVFOwv8J1NjsQjzIoAJl3QMYzpmmmjaI=; b=U6dK/MAZFubPh4bP+DNRAlhgfaCGlytaoGUDoiMOXBkcAcIW5VZSpcne3pMjxccflX yyFiLNjJsIOIP/1qQS8P1VzbCRvhTny+5ul+hnPDOtAu/EhVNmDXi3DDFFOdweXMtDd6 wvfnmmynWzXhJVGay/xENr/PXf650JW9fLk1nAyTcUeXQ0513pi/rk71PVBLZkIDusUY R9aAkiBOBE34ys2BI0pV9lVowIoXT26kgOFvrAEnmNEUdiAQ9TPJwzKcSkRfUIUPxz99 B2f0Qr4MHbqPCh999dnBj2weQ8IEdx+xsqihJP37FEbKEWJ5+SmgvOkQ8FLy4zJ6Fjc9 h3ow== X-Gm-Message-State: APt69E3bnV4mnlF1v+W92WLBa08RO0zc0Vvu52zW3k8tjPxx0w2Y0rWJ kJBwcnTD6LFD9IiAb//+keh32rv71rQwoUh923OxOw== X-Google-Smtp-Source: ADUXVKKSACA/jyyuSbdQPiYmMXvabeB8JkkB2D88faYmOQD+q+0wliDlbikdkFOLjH2ZI8Jer1S6vkaD42l5r8ulhKE= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr11658213itc.36.1529381129856; Mon, 18 Jun 2018 21:05:29 -0700 (PDT) MIME-Version: 1.0 References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619034232.GA81800@www.zefox.net> In-Reply-To: <20180619034232.GA81800@www.zefox.net> From: Warner Losh Date: Mon, 18 Jun 2018 22:05:17 -0600 Message-ID: Subject: Re: GPT vs MBR for swap devices To: bob prohaska Cc: Mark Millard , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:05:31 -0000 On Mon, Jun 18, 2018, 9:44 PM bob prohaska wrote: > On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: > > On 2018-Jun-18, at 5:55 PM, bob prohaska wrote: > > > > > On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: > > >> > > >> > > >> On 2018-Jun-18, at 4:04 PM, bob prohaska > wrote: > > >> > > >>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: > > >>>> > > >>>> Since the "multiple swap partitions across multiple > > >>>> devices" context (my description) is what has problems, > > >>>> it would be interesting to see swapinfo information > > >>>> from around the time frame of the failures: how much is > > >>>> used vs. available on each swap partition? Is only one > > >>>> being (significantly) used? The small one (1 GiByte)? > > >>>> > > >>> There are some preliminary observations at > > >>> > > >>> > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdflash_swapinfo/1gbusbflash_1gbsdflash_swapinfo.log > > >>> > > >>> If you search for 09:44: (the time of the OOM kills) it looks like > > >>> both swap partitions are equally used, but only 8% full. > > >>> > > >>> At this point I'm wondering if the gstat interval (presently 10 > seconds) > > >>> might well be shortened and the ten second sleep eliminated. On the > runs > > >>> that succeed swap usage changes little in twenty seconds, but the > failures > > >>> seem to to culminate rather briskly. > > >> > > >> One thing I find interesting somewhat before the OOM activity is > > >> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along > > >> with having 46 or 33 L(q) and large %busy figures in the same > > >> lines --and 0 w/s on every line: > > >> > > >> Mon Jun 18 09:42:05 PDT 2018 > > >> Device 1K-blocks Used Avail Capacity > > >> /dev/da0b 1048576 3412 1045164 0% > > >> /dev/mmcsd0s3b 1048576 3508 1045068 0% > > >> Total 2097152 6920 2090232 0% > > >> dT: 10.043s w: 10.000s > > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > >> 0 0 0 0 0.0 0 9 10.8 0 0 > 0.0 0.1 mmcsd0 > > >> 46 0 0 0 0.0 0 16 12355 0 0 > 0.0 85.9 da0 > > >> 0 0 0 0 0.0 0 9 10.8 0 0 > 0.0 0.1 mmcsd0s3 > > >> 0 0 0 0 0.0 0 9 10.8 0 0 > 0.0 0.1 mmcsd0s3a > > >> 33 0 0 0 0.0 0 22 12318 0 0 > 0.0 114.1 da0d > > >> Mon Jun 18 09:42:25 PDT 2018 > > >> Device 1K-blocks Used Avail Capacity > > >> /dev/da0b 1048576 3412 1045164 0% > > >> /dev/mmcsd0s3b 1048576 3508 1045068 0% > > >> Total 2097152 6920 2090232 0% > > >> > > >> > > >> The kBps figures for the writes are not very big above. > > >> > > > > > > If it takes 12 seconds to write, I can understand the swapper getting > impatient.... > > > However, the delay is on /usr, not swap. > > > > > > In the subsequent 1 GB USB flash-alone test case at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/1gbusbflash_swapinfo.log > > > the worst-case seems to be at time 13:45:00 > > > > > > dT: 13.298s w: 10.000s > > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > > 0 0 0 0 0.0 0 5 5.5 0 0 > 0.0 0.1 mmcsd0 > > > 9 84 0 0 0.0 84 1237 59.6 0 0 > 0.0 94.1 da0 > > > 0 0 0 0 0.0 0 5 5.5 0 0 > 0.0 0.1 mmcsd0s3 > > > 0 0 0 0 0.0 0 5 5.6 0 0 > 0.0 0.1 mmcsd0s3a > > > 5 80 0 0 0.0 80 1235 47.2 0 0 > 0.0 94.1 da0b > > > 4 0 0 0 0.0 0 1 88.1 0 0 > 0.0 0.7 da0d > > > Mon Jun 18 13:45:00 PDT 2018 > > > Device 1K-blocks Used Avail Capacity > > > /dev/da0b 1048576 22872 1025704 2% > > > > > > 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill a > process. > > > > That is kBps instead of ms/w. > > > > I see a ms/w (and ms/r) that is fairly large (but notably > > smaller than the ms/w of over 12000): > > > > Mon Jun 18 13:12:58 PDT 2018 > > Device 1K-blocks Used Avail Capacity > > /dev/da0b 1048576 0 1048576 0% > > dT: 10.400s w: 10.000s > > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > > 0 4 0 0 0.0 4 66 3.4 0 0 > 0.0 1.3 mmcsd0 > > 8 18 1 32 1991 17 938 2529 0 0 > 0.0 88.1 da0 > > 0 4 0 0 0.0 4 63 3.5 0 0 > 0.0 1.3 mmcsd0s3 > > 0 4 0 0 0.0 4 63 3.5 0 0 > 0.0 1.3 mmcsd0s3a > > 6 11 1 32 1991 10 938 3207 0 0 > 0.0 94.7 da0d > > Mon Jun 18 13:13:19 PDT 2018 > > Device 1K-blocks Used Avail Capacity > > /dev/da0b 1048576 0 1048576 0% > > > > > Yes, but again, it's on /usr, not swap. Doesn't really matter to the swap page. If you have an average latency of 12s averaged over 10s, your system performance is beyond what the system can tolerate since there is a 30s timeout. . One could argue that there are other > write delays, not seen here, that do affect swap. To forestall that > objection > I'll get rid of the ten second sleep in the script when the present test > run > finishes. > Latencies north of 300ms are problematic. 12000ms would be unusable or worse. > Going in a different direction, I believe that you have > > reported needing more than 1 GiByte of swap space so the > > 1048576 "1K-blocks" would not be expected to be sufficient. > > So the specific failing point may well be odd but the build > > would not be expected to finish without an OOM for this > > context if I understand right. > > > Yes, the actual swap requirement seems to be slightly over 1.4 GB > at the peak based on other tests. I fully expected a failure, but > at a much higher swap utilization. > > > > > Thus far I'm baffled. Any suggestions? > > > > Can you get a failure without involving da0, the drive that is > > sometimes showing these huge ms/w (and ms/r) figures? (This question > > presumes having sufficient swap space, so, say, 1.5 GiByte or more > > total.) > > > If you mean not using da0, no; it holds /usr. If you mean not swapping > to da0, yes it's been done. Having 3 GB swap on microSD works. > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > USB swap. That's easy to try. > I'll have to graph the numbers still. But these huge latencies will make it non viable... > Having the partition(s) each be sufficiently sized but for which > > the total would not produce the notice for too large of a swap > > space was my original "additional" suggestion. I still want to > > see what such does as a variation of a failing context. > > I'm afraid you've lost me here. With two partitions, one USB and > the other SD of one GB each OOM kills happen at 8% utilization, > spread evenly across both. Does the size of the partition affect > the speed of it? Capacity does not seem the problem. > OOM hap pop ens when we can't get memory fast enough. Having lots of swap space is useless if it is too slow. > it would seem to be a good idea to avoid da0 and its sometimes > > large ms/w and /ms/r figures. > > > > I think the next experiment will be to use 1 GB of SD swap and > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, > and we know the USB mechanical swap is fast enough. If that > combination works, maybe the trouble is congestion on da0. If the combo > fails as before I'll be tempted to think it's USB or the swapper. > My money is still on super crappy NAND creating such a terrible bottleneck that we trigger OOM. Warner Thanks for reading! > > > bob prohaska > > > > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Jun 19 04:06:23 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30F74101B81F for ; Tue, 19 Jun 2018 04:06:23 +0000 (UTC) (envelope-from jau789@gmail.com) Received: from mail-lf0-x243.google.com (mail-lf0-x243.google.com [IPv6:2a00:1450:4010:c07::243]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 80B206836A for ; Tue, 19 Jun 2018 04:06:22 +0000 (UTC) (envelope-from jau789@gmail.com) Received: by mail-lf0-x243.google.com with SMTP id u5-v6so6683981lff.13 for ; Mon, 18 Jun 2018 21:06:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6glriyDf4a+64nCCpj+37V6kEySBvLdE32M1A+bi7dE=; b=aW8MbzRCIyGL87iJaVDVK3HCDgfArOfDyZVGwaNzF22b1BTTM9hKBSeVK61mI735qG tUWnErMyAis33AnqTlAYmxhcDA77R7rnBet4k6RSYbSLbvJZd2eU7HNtwss7TNWwqHCw Lv8NhtuAncRLa0GiQ2m0/0STGgQbcs05y4QlVn+aLiyz9SxggG/9pAJCNS3bPZHpKrsq PAd3BHx67kH9kfI6/tw1UGWlemGmS7fZozOxKG3K+afCbhzaofSIzziHC/aDkwnUX8d8 tyqOALtWGMnNls/UZDg2f7X7feCqE9DREV/Q9KJnYTxWJeUEi7McrBUOU7Ac02edGKVr c/Hg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=6glriyDf4a+64nCCpj+37V6kEySBvLdE32M1A+bi7dE=; b=rC0HzPb1Fq5Iay3D6mo3UjlduSJVvdQ9m/SliqHrSaGeCK0g2HtZFy82mnTZQGF2jv En73Mi9LojRpRxcO6i58SrdSoJ2UZbrkZ0vMB2aWdBvyHbVo0n/lA4Ba0l4V4lmLQtzR kDsJ/cr8EDWgM9V49Zme5CRi3oMJ55DH7W1cbtE+TKgFFTpNbg5E8Yk0VvF/2PflwtNP acaIdA56ui9wV2iQw7VE/Fnmv6R2h6VUQbVzvl7L7rLsWiPI/0IyImzEPGdRz0wRayj3 klPGYK2iFJ3Vxgn0SDGx0Nr+4h/TyTiHpFGtW2yIuWongVzntpdgwO7AbXGwnKn9SC8A OBlA== X-Gm-Message-State: APt69E26lJtroFBbygO+qeKj3z4TzSkXN6dy3lMPxoVjvrswVJUxdaXN 70FHagtCjQg/fSfiXbRQM5sWHQ== X-Google-Smtp-Source: ADUXVKJiVq/CV87rNQSUFtJHANEWMPcXU1LhqI3j/Jz/wkiDTEBh164MhG4+qe1CnllrealexEj0hA== X-Received: by 2002:a19:ee06:: with SMTP id g6-v6mr9346756lfb.77.1529381180474; Mon, 18 Jun 2018 21:06:20 -0700 (PDT) Received: from [192.168.1.193] (xdsl-205-1.nblnetworks.fi. [83.145.205.1]) by smtp.gmail.com with ESMTPSA id z68-v6sm2982278ljb.55.2018.06.18.21.06.19 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 Jun 2018 21:06:19 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: GPT vs MBR for swap devices From: Jukka Ukkonen X-Mailer: iPad Mail (15F79) In-Reply-To: <20180619034232.GA81800@www.zefox.net> Date: Tue, 19 Jun 2018 07:06:18 +0300 Cc: Mark Millard , freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <0C802675-9DE2-4446-B0F1-528D40C69C68@gmail.com> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619034232.GA81800@www.zefox.net> To: bob prohaska X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:06:23 -0000 Are you sure it is not /usr/obj activity which you are seeing when there are large write delays? On systems using traditional spinning disks for everything else it really makes sense to put /usr/obj on its own SSD making sure the SSD does not share an I/O channel with any other device. --jau > On 19 Jun 2018, at 6.42, bob prohaska wrote: >=20 >> On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: >>> On 2018-Jun-18, at 5:55 PM, bob prohaska wrote: >>>=20 >>>> On Mon, Jun 18, 2018 at 04:42:21PM -0700, Mark Millard wrote: >>>>=20 >>>>=20 >>>>> On 2018-Jun-18, at 4:04 PM, bob prohaska wrote= : >>>>>=20 >>>>>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote: >>>>>>=20 >>>>>> Since the "multiple swap partitions across multiple >>>>>> devices" context (my description) is what has problems, >>>>>> it would be interesting to see swapinfo information >>>>>> from around the time frame of the failures: how much is >>>>>> used vs. available on each swap partition? Is only one >>>>>> being (significantly) used? The small one (1 GiByte)? >>>>>>=20 >>>>> There are some preliminary observations at >>>>>=20 >>>>> http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_1gbsdfl= ash_swapinfo/1gbusbflash_1gbsdflash_swapinfo.log >>>>>=20 >>>>> If you search for 09:44: (the time of the OOM kills) it looks like >>>>> both swap partitions are equally used, but only 8% full. >>>>>=20 >>>>> At this point I'm wondering if the gstat interval (presently 10 second= s) >>>>> might well be shortened and the ten second sleep eliminated. On the ru= ns >>>>> that succeed swap usage changes little in twenty seconds, but the fail= ures >>>>> seem to to culminate rather briskly. >>>>=20 >>>> One thing I find interesting somewhat before the OOM activity is >>>> the 12355 ms/w and 12318 ms/w on da0 and da0d that goes along >>>> with having 46 or 33 L(q) and large %busy figures in the same >>>> lines --and 0 w/s on every line: >>>>=20 >>>> Mon Jun 18 09:42:05 PDT 2018 >>>> Device 1K-blocks Used Avail Capacity >>>> /dev/da0b 1048576 3412 1045164 0% >>>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>>> Total 2097152 6920 2090232 0% >>>> dT: 10.043s w: 10.000s >>>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps m= s/d %busy Name >>>> 0 0 0 0 0.0 0 9 10.8 0 0 0= .0 0.1 mmcsd0 >>>> 46 0 0 0 0.0 0 16 12355 0 0 0= .0 85.9 da0 >>>> 0 0 0 0 0.0 0 9 10.8 0 0 0= .0 0.1 mmcsd0s3 >>>> 0 0 0 0 0.0 0 9 10.8 0 0 0= .0 0.1 mmcsd0s3a >>>> 33 0 0 0 0.0 0 22 12318 0 0 0= .0 114.1 da0d >>>> Mon Jun 18 09:42:25 PDT 2018 >>>> Device 1K-blocks Used Avail Capacity >>>> /dev/da0b 1048576 3412 1045164 0% >>>> /dev/mmcsd0s3b 1048576 3508 1045068 0% >>>> Total 2097152 6920 2090232 0% >>>>=20 >>>>=20 >>>> The kBps figures for the writes are not very big above. >>>>=20 >>>=20 >>> If it takes 12 seconds to write, I can understand the swapper getting im= patient.... >>> However, the delay is on /usr, not swap. >>>=20 >>> In the subsequent 1 GB USB flash-alone test case at >>> http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbusbflash_swapinfo/= 1gbusbflash_swapinfo.log >>> the worst-case seems to be at time 13:45:00 >>>=20 >>> dT: 13.298s w: 10.000s >>> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms= /d %busy Name >>> 0 0 0 0 0.0 0 5 5.5 0 0 0.= 0 0.1 mmcsd0 >>> 9 84 0 0 0.0 84 1237 59.6 0 0 0.= 0 94.1 da0 >>> 0 0 0 0 0.0 0 5 5.5 0 0 0.= 0 0.1 mmcsd0s3 >>> 0 0 0 0 0.0 0 5 5.6 0 0 0.= 0 0.1 mmcsd0s3a >>> 5 80 0 0 0.0 80 1235 47.2 0 0 0.= 0 94.1 da0b >>> 4 0 0 0 0.0 0 1 88.1 0 0 0.= 0 0.7 da0d >>> Mon Jun 18 13:45:00 PDT 2018 >>> Device 1K-blocks Used Avail Capacity >>> /dev/da0b 1048576 22872 1025704 2% >>>=20 >>> 1.2 MB/s writing to swap seems not too shabby, hardly reason to kill a p= rocess. >>=20 >> That is kBps instead of ms/w. >>=20 >> I see a ms/w (and ms/r) that is fairly large (but notably >> smaller than the ms/w of over 12000): >>=20 >> Mon Jun 18 13:12:58 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >> dT: 10.400s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/= d %busy Name >> 0 4 0 0 0.0 4 66 3.4 0 0 0.= 0 1.3 mmcsd0 >> 8 18 1 32 1991 17 938 2529 0 0 0.= 0 88.1 da0 >> 0 4 0 0 0.0 4 63 3.5 0 0 0.= 0 1.3 mmcsd0s3 >> 0 4 0 0 0.0 4 63 3.5 0 0 0.= 0 1.3 mmcsd0s3a >> 6 11 1 32 1991 10 938 3207 0 0 0.= 0 94.7 da0d >> Mon Jun 18 13:13:19 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >>=20 >>=20 > Yes, but again, it's on /usr, not swap. One could argue that there are ot= her > write delays, not seen here, that do affect swap. To forestall that object= ion=20 > I'll get rid of the ten second sleep in the script when the present test r= un > finishes.=20 >=20 >=20 >> Going in a different direction, I believe that you have >> reported needing more than 1 GiByte of swap space so the >> 1048576 "1K-blocks" would not be expected to be sufficient. >> So the specific failing point may well be odd but the build >> would not be expected to finish without an OOM for this >> context if I understand right. >>=20 > Yes, the actual swap requirement seems to be slightly over 1.4 GB=20 > at the peak based on other tests. I fully expected a failure, but > at a much higher swap utilization. >=20 >=20 >>> Thus far I'm baffled. Any suggestions? >>=20 >> Can you get a failure without involving da0, the drive that is >> sometimes showing these huge ms/w (and ms/r) figures? (This question >> presumes having sufficient swap space, so, say, 1.5 GiByte or more >> total.) >>=20 > If you mean not using da0, no; it holds /usr. If you mean not swapping > to da0, yes it's been done. Having 3 GB swap on microSD works.=20 > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > USB swap. That's easy to try.=20 >=20 >> Having the partition(s) each be sufficiently sized but for which >> the total would not produce the notice for too large of a swap >> space was my original "additional" suggestion. I still want to >> see what such does as a variation of a failing context.=20 >=20 > I'm afraid you've lost me here. With two partitions, one USB and > the other SD of one GB each OOM kills happen at 8% utilization,=20 > spread evenly across both. Does the size of the partition affect > the speed of it? Capacity does not seem the problem. >=20 >> it would seem to be a good idea to avoid da0 and its sometimes >> large ms/w and /ms/r figures. >>=20 >=20 > I think the next experiment will be to use 1 GB of SD swap and > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, > and we know the USB mechanical swap is fast enough. If that > combination works, maybe the trouble is congestion on da0. If the combo > fails as before I'll be tempted to think it's USB or the swapper. >=20 > Thanks for reading! >=20 >=20 > bob prohaska >>=20 >>=20 > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" From owner-freebsd-arm@freebsd.org Tue Jun 19 04:14:52 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 66D81101C26A for ; Tue, 19 Jun 2018 04:14:52 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-22.consmr.mail.ne1.yahoo.com (sonic316-22.consmr.mail.ne1.yahoo.com [66.163.187.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 ECA8C68901 for ; Tue, 19 Jun 2018 04:14:51 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: woajSdAVM1kRNoceG5e.oLRq0yp2cg8Y21P_HV6Kkp8WOCPQE_5Aa401z47dj_W fZNhS0hBA9LNnDjX3NdxA_CmlJVh2pBBJJbNHkFAuW0xr20MYheLquFKnvuErOW86P33doE3uxJr gxpLrxB5gWQ1vH7lTqEM7UAJ0iiDXS3jv2h7WdsmxR1dbuC1PswBS6I3D.i50JUScjThLcU3AVba B2v0tXyZXQaGt2jxtiloG12hifPDqUtIR6qIDg5XFTx41aXKBpRaCrr8__rMCKYLwbTMVpCo5WyM IJfOW_nVZAY5u0YPSq8j.VEYsWc9NaDJYE1W2BqrGFLxMDjJc8TF3laEJzPlnw9MUt.Y4R7V4yeu IB.rqC14fciGOHhRsuMAVF31fdu4BZ812zeaGngKcb1GqKy1Ok_CZ7zwtq7w5kwKXNhN6DGSJe4i hXncu02j0Sm4gHiQHbZeAwNG.VMh93R1KHH6UDxTsjPfZZkUUMYGXM3WHNjkebWGivii_ARZBPDW BC1H9KGm0qTL_ciCGuuLWyXowX56nHo9lxVxokLvL2EenCeYLbL99hJDV3bL2wjFTQcDbQvWGJi5 gRAe43t5pMalwzOWf_0ajcF9rzsieXpjYpodU.O85aCsbgfCMilicSO8aVH4FxrgILTnlRf7jbLc ebfc8m_TTLCar9u.lBkEEkrjBVUgNiOMa5Zqcw6pznpAdFI3uvPC2fzXZv7skUfPW0iRrQVDR0em 7Jl52vvstOWd.3TT7xzvrml9VxTmME6OfYsNkPGEIeI3fxO.D2Bliptbqq4sAp6K5L3anLXnLAGB ruFGJeUOmxT4XktFpxQKRhCp5NV4x1zJkmQA9i44Dcr2BTixJsqQh7gP1dsl5FS4vQX1ML3sDvZK C5GPfjJf8veBe8dc3b4szV55.i_M1epeUD04M3jFaDFVrDvLcv9KTxoXI5Xr8EyhTB72KueB_Ih1 gI4I- Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Tue, 19 Jun 2018 04:14:50 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp407.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4773c1c9840e7207c1e63c06acabe7d3; Tue, 19 Jun 2018 04:14:49 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180619034232.GA81800@www.zefox.net> Date: Mon, 18 Jun 2018 21:14:48 -0700 Cc: freebsd-arm@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619034232.GA81800@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:14:52 -0000 On 2018-Jun-18, at 8:42 PM, bob prohaska wrote: > On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: >> On 2018-Jun-18, at 5:55 PM, bob prohaska = wrote: >>=20 >> . . . >> I see a ms/w (and ms/r) that is fairly large (but notably >> smaller than the ms/w of over 12000): >>=20 >> Mon Jun 18 13:12:58 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >> dT: 10.400s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 4 0 0 0.0 4 66 3.4 0 0 = 0.0 1.3 mmcsd0 >> 8 18 1 32 1991 17 938 2529 0 0 = 0.0 88.1 da0 >> 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3 >> 0 4 0 0 0.0 4 63 3.5 0 0 = 0.0 1.3 mmcsd0s3a >> 6 11 1 32 1991 10 938 3207 0 0 = 0.0 94.7 da0d >> Mon Jun 18 13:13:19 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 0 1048576 0% >>=20 >>=20 > Yes, but again, it's on /usr, not swap. One could argue that there = are other > write delays, not seen here, that do affect swap. To forestall that = objection=20 > I'll get rid of the ten second sleep in the script when the present = test run > finishes.=20 >=20 If the drive /dev/da0 has any partitions with large ms/w (or ms/r) figures sometimes, all partitions on the drive are likely subject to the same if /dev/da0 is a flash or SSD drive. At least that is my understanding. Also if /dev/da0 has any partition with an active I/O that takes a long time, it may well block I/O on any other partition on the same drive until it completes. (As far as I know for a USB flash and FreeBSD. I'm no expert at such issues.) My suggestions have been trying to see if eliminating all the large ms/w (and ms/r) on the drive(s) used for swap makes the problem go away, not just on the swap partitions. If FreeBSD might have more overall cross-device "large ms/w" interference was also something I was trying to avoid having any chance of being involved. (I've no clue if such has a chance of being an issue.) >> . .=20 >> Can you get a failure without involving da0, the drive that is >> sometimes showing these huge ms/w (and ms/r) figures? (This question >> presumes having sufficient swap space, so, say, 1.5 GiByte or more >> total.) >>=20 > If you mean not using da0, no; it holds /usr. If you mean not swapping > to da0, yes it's been done. Having 3 GB swap on microSD works.=20 > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > USB swap. That's easy to try.=20 For what I was thinking of testing you would have to have /usr and the rest being on some other drive than one that gets the large ms/w (and/or ms/r) figures: you would need to avoid that drive because all partitions on that drive are likely subject to the large ms/w (and ms/r) figures. Avoiding swap being on any partition of /dev/da0 is a less extreme form of isolating things. >> Having the partition(s) each be sufficiently sized but for which >> the total would not produce the notice for too large of a swap >> space was my original "additional" suggestion. I still want to >> see what such does as a variation of a failing context.=20 >=20 > I'm afraid you've lost me here. With two partitions, one USB and > the other SD of one GB each OOM kills happen at 8% utilization,=20 > spread evenly across both. Does the size of the partition affect > the speed of it? Capacity does not seem the problem. Being able to just turn off one of two partitions allows testing if it is having more than one that makes the difference if OOM killing of processes happens. (Similarly exchanging which is off.) But only if each is large enough to allow the run to complete. Not that such is the actual issue or likely, but imagine that some test for OOM process killing was using the size of the smallest active swap partition to test if OOM was needed instead of testing the total. (The log files are just sampling and are unlikely to show peak swap space "used" figures.) >> it would seem to be a good idea to avoid da0 and its sometimes >> large ms/w and /ms/r figures. >>=20 >=20 > I think the next experiment will be to use 1 GB of SD swap and > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, > and we know the USB mechanical swap is fast enough. If that > combination works, maybe the trouble is congestion on da0. If the = combo > fails as before I'll be tempted to think it's USB or the swapper. Sounds like a plan if large ms/w (and ms/r) figures for /dev/da0 can not interfere with other drives. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Tue Jun 19 04:27:54 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BA2ED101CE3D for ; Tue, 19 Jun 2018 04:27:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22a.google.com (mail-it0-x22a.google.com [IPv6:2607:f8b0:4001:c0b::22a]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 47F9169082 for ; Tue, 19 Jun 2018 04:27:53 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22a.google.com with SMTP id v83-v6so15278206itc.3 for ; Mon, 18 Jun 2018 21:27:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JSUW/2iZ4gCEhRTT3tdQrwocNXw/8GafkbQmDIZ+v/0=; b=pIxkrIqI0AV4ow3Kpl14YWHTbFrytQY1IfqLyASk1WSdpvl3B1ZHwHss/tabvfBscT fh6SQZqfjGmRKwTmvZKXwbY9pmgy2MN0TDCMV5CJZiJMcdJXMAZr0sdek5tuPA4C7dDN cgWZ9Z+JU//F/EVCD9u1ca+ReU7lf1DjCGhAj8VSDLsgc3lnE0fQMLMubv6BtWwIjGZP K3Y8UoQJtYw6Aclxt0x8ifHnlLvCgE3h2IarhGQgiSFc50vVvCI7/IpypRL+DMBhaaMU lOrvrVc+zG6Z8S5MFAu96qAIn+iShqBjYqnZR2EOmVDvPAaOSUzOLylWFO0cnv+0LxLs vDnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=JSUW/2iZ4gCEhRTT3tdQrwocNXw/8GafkbQmDIZ+v/0=; b=dhMyeZrqQX77ClDtTGK41pzictIstUBC13U+4xx1muqmF3jFB+uedXyyaj0KDIZ6jg UKW27Xyt0W1xYdRoWLFLreHytqcvYEfQQBOoeyDxh5Tv5W0FwMGgr/w4Fi28dt4glSDf VxGdqnlQF/JoxJ+pdoi5tFv3z6PyJJKB9erkRL7tsts5j+3duACc5E5KjwY6XHnHsrSr PDpM+E7RiOV7qRoykQ2dsaB5qjCdftWwZKqCZTj+kc1y+1Zhw6rpDEJnvecTh313jP/x 8JAkjulj/TavrQIvG+/Ek4pYEw/Kb5dBS9EYB6sA520WRFGtpMdDkHvesyTHkZ7M8RmK f3JA== X-Gm-Message-State: APt69E1eV4Az7WtfqKdfGjeCgHeQ3/wDKQI5Ps0fsiTahr6xzAUBO8Wl 2E++gXHskvPK8Kr3+6yasgryGbvct0rRnHRnzQUe1w== X-Google-Smtp-Source: ADUXVKKfQPs3Dl/SuDL0xDZxLKGI0+KPjzU391sF6SSHH05DaQsRd0Ir7oIs/g5d/cD9NEzEKslLmh4u4Gmph/jXNVQ= X-Received: by 2002:a02:9aba:: with SMTP id m55-v6mr12382371jak.140.1529382472344; Mon, 18 Jun 2018 21:27:52 -0700 (PDT) MIME-Version: 1.0 References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619034232.GA81800@www.zefox.net> <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com> In-Reply-To: <127A4F5A-086E-4825-81B8-89BC95677F0E@yahoo.com> From: Warner Losh Date: Mon, 18 Jun 2018 22:27:39 -0600 Message-ID: Subject: Re: GPT vs MBR for swap devices To: Mark Millard Cc: bob prohaska , freebsd-arm@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 04:27:54 -0000 On Mon, Jun 18, 2018, 10:15 PM Mark Millard via freebsd-arm < freebsd-arm@freebsd.org> wrote: > > > On 2018-Jun-18, at 8:42 PM, bob prohaska wrote: > > > On Mon, Jun 18, 2018 at 06:31:40PM -0700, Mark Millard wrote: > >> On 2018-Jun-18, at 5:55 PM, bob prohaska wrote: > >> > >> . . . > >> I see a ms/w (and ms/r) that is fairly large (but notably > >> smaller than the ms/w of over 12000): > >> > >> Mon Jun 18 13:12:58 PDT 2018 > >> Device 1K-blocks Used Avail Capacity > >> /dev/da0b 1048576 0 1048576 0% > >> dT: 10.400s w: 10.000s > >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps > ms/d %busy Name > >> 0 4 0 0 0.0 4 66 3.4 0 0 > 0.0 1.3 mmcsd0 > >> 8 18 1 32 1991 17 938 2529 0 0 > 0.0 88.1 da0 > >> 0 4 0 0 0.0 4 63 3.5 0 0 > 0.0 1.3 mmcsd0s3 > >> 0 4 0 0 0.0 4 63 3.5 0 0 > 0.0 1.3 mmcsd0s3a > >> 6 11 1 32 1991 10 938 3207 0 0 > 0.0 94.7 da0d > >> Mon Jun 18 13:13:19 PDT 2018 > >> Device 1K-blocks Used Avail Capacity > >> /dev/da0b 1048576 0 1048576 0% > >> > >> > > Yes, but again, it's on /usr, not swap. One could argue that there are > other > > write delays, not seen here, that do affect swap. To forestall that > objection > > I'll get rid of the ten second sleep in the script when the present test > run > > finishes. > > > > If the drive /dev/da0 has any partitions with large ms/w (or ms/r) > figures sometimes, all partitions on the drive are likely subject > to the same if /dev/da0 is a flash or SSD drive. At least that > is my understanding. > Yes partitioning is a logical thing. You never know for sure what is taking a long time or the cause. All you can see is the effect. Also if /dev/da0 has any partition with an active I/O that takes > a long time, it may well block I/O on any other partition on the > same drive until it completes. (As far as I know for a USB flash > and FreeBSD. I'm no expert at such issues.) > Usually with usb flash it does. SSDs have multiple channels to the NAND. USB often does not... My suggestions have been trying to see if eliminating all the > large ms/w (and ms/r) on the drive(s) used for swap makes the > problem go away, not just on the swap partitions. > > If FreeBSD might have more overall cross-device "large ms/w" > interference was also something I was trying to avoid having > any chance of being involved. (I've no clue if such has a > chance of being an issue.) > Large latencies usually means slow page cleaning. No page cleaning means OOM. Warner > >> . . > >> Can you get a failure without involving da0, the drive that is > >> sometimes showing these huge ms/w (and ms/r) figures? (This question > >> presumes having sufficient swap space, so, say, 1.5 GiByte or more > >> total.) > >> > > If you mean not using da0, no; it holds /usr. If you mean not swapping > > to da0, yes it's been done. Having 3 GB swap on microSD works. > > Which suggests an experiment: use 1 GB SD swap and 1.3 GB mechanical > > USB swap. That's easy to try. > > For what I was thinking of testing you would have to have /usr and the > rest being on some other drive than one that gets the large ms/w > (and/or ms/r) figures: you would need to avoid that drive because > all partitions on that drive are likely subject to the large > ms/w (and ms/r) figures. > > Avoiding swap being on any partition of /dev/da0 is a less extreme > form of isolating things. > > >> Having the partition(s) each be sufficiently sized but for which > >> the total would not produce the notice for too large of a swap > >> space was my original "additional" suggestion. I still want to > >> see what such does as a variation of a failing context. > > > > I'm afraid you've lost me here. With two partitions, one USB and > > the other SD of one GB each OOM kills happen at 8% utilization, > > spread evenly across both. Does the size of the partition affect > > the speed of it? Capacity does not seem the problem. > > Being able to just turn off one of two partitions allows testing if > it is having more than one that makes the difference if OOM killing > of processes happens. (Similarly exchanging which is off.) But only > if each is large enough to allow the run to complete. > > Not that such is the actual issue or likely, but imagine that some > test for OOM process killing was using the size of the smallest > active swap partition to test if OOM was needed instead of testing > the total. > > (The log files are just sampling and are unlikely to show peak swap > space "used" figures.) > > >> it would seem to be a good idea to avoid da0 and its sometimes > >> large ms/w and /ms/r figures. > >> > > > > I think the next experiment will be to use 1 GB of SD swap and > > 1.3 GB of mechanical USB swap. We know the SD swap is fast enough, > > and we know the USB mechanical swap is fast enough. If that > > combination works, maybe the trouble is congestion on da0. If the combo > > fails as before I'll be tempted to think it's USB or the swapper. > > Sounds like a plan if large ms/w (and ms/r) figures for /dev/da0 > can not interfere with other drives. > > === > Mark Millard > marklmi at yahoo.com > ( dsl-only.net went > away in early 2018-Mar) > > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > From owner-freebsd-arm@freebsd.org Tue Jun 19 05:10:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 42302101F84A for ; Tue, 19 Jun 2018 05:10:49 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 757B96A896 for ; Tue, 19 Jun 2018 05:10:48 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5J5AiHX025197 for ; Tue, 19 Jun 2018 15:10:44 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices To: Thomas Skibo via freebsd-arm References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619040017.GB81800@www.zefox.net> From: Trev Message-ID: <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> Date: Tue, 19 Jun 2018 15:10:44 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180619040017.GB81800@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Tue, 19 Jun 2018 15:10:44 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 05:10:49 -0000 bob prohaska wrote on 19/06/2018 14:00: > On Tue, Jun 19, 2018 at 12:34:23PM +1000, Trev wrote: >> >> Just for reference, with the 32 bit Rpi2, my peak swap usage (with >> nothing much other than make -j4 buildworld running) is 1.424GB. > > That's a surprise, I thought it would be much less. What is your > swap and storage configuration? root@rpi2 [/root] $ cat /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw,noatime 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 md1 /tmp mfs rw,noatime,-s100m 0 0 md2 /var/log mfs rw,noatime,-s15m 0 0 md3 /var/tmp mfs rw,noatime,-s15m 0 0 /dev/label/swap none swap sw 0 0 /dev/ufs/home /home ufs rw,noatime 2 2 /dev/ufs/usr /usr ufs rw,noatime 2 2 root@rpi2 [/root] $ gpart show => 63 30318529 mmcsd0 MBR (14G) 63 102375 1 !12 [active] (50M) 102438 30216154 2 freebsd (14G) => 0 30216154 mmcsd0s2 BSD (14G) 0 90 - free - (45K) 90 30216064 1 freebsd-ufs (14G) => 40 60567472 da0 GPT (29G) 40 8 - free - (4.0K) 48 4194304 1 freebsd-swap (2.0G) 4194352 54525952 2 freebsd-ufs (26G) 58720304 1847208 - free - (902M) => 40 60567472 da1 GPT (29G) 40 60567468 1 freebsd-ufs (29G) 60567508 4 - free - (2.0K) root@rpi2 [/root] $ mount /dev/ufs/rootfs on / (ufs, local, noatime, soft-updates) devfs on /dev (devfs, local) /dev/msdosfs/MSDOSBOOT on /boot/msdos (msdosfs, local, noatime) /dev/md1 on /tmp (ufs, local, noatime, soft-updates) /dev/md2 on /var/log (ufs, local, noatime, soft-updates) /dev/md3 on /var/tmp (ufs, local, noatime, soft-updates) /dev/ufs/home on /home (ufs, local, noatime, soft-updates) /dev/ufs/usr on /usr (ufs, local, noatime, soft-updates) da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 da0: < USB DISK 2.0 PMAP> Removable Direct Access SPC-4 SCSI device da0: Serial Number 070B6B2514ABD241 da0: 40.000MB/s transfers da0: 29574MB (60567552 512 byte sectors) da0: quirks=0x3 da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 da1: < USB DISK 2.0 PMAP> Removable Direct Access SPC-4 SCSI device da1: Serial Number 070B6B236F828891 da1: 40.000MB/s transfers da1: 29574MB (60567552 512 byte sectors) da1: quirks=0x3 da0 - 32G Emtec USB memory - houses /home and 2G swap partition da1 - 32G Emtec USB memory - houses /usr /usr/obj is linked to /home/obj From owner-freebsd-arm@freebsd.org Tue Jun 19 06:55:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 73904100092F for ; Tue, 19 Jun 2018 06:55:30 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id D73376EAA2 for ; Tue, 19 Jun 2018 06:55:29 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5J6thq9086282 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Mon, 18 Jun 2018 23:55:44 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5J6tgSH086281; Mon, 18 Jun 2018 23:55:42 -0700 (PDT) (envelope-from fbsd) Date: Mon, 18 Jun 2018 23:55:42 -0700 From: bob prohaska To: Jukka Ukkonen Cc: Mark Millard , freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619065542.GA85994@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619034232.GA81800@www.zefox.net> <0C802675-9DE2-4446-B0F1-528D40C69C68@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <0C802675-9DE2-4446-B0F1-528D40C69C68@gmail.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 06:55:30 -0000 On Tue, Jun 19, 2018 at 07:06:18AM +0300, Jukka Ukkonen wrote: > > Are you sure it is not /usr/obj activity which you are seeing when > there are large write delays? I am absolutely not sure. > On systems using traditional spinning disks for everything else > it really makes sense to put /usr/obj on its own SSD making sure > the SSD does not share an I/O channel with any other device. > Agreed that spreading throughput among channels is good. That's why I tried to split swap between microSD and USB. The RPI2 systems I've set up before use a USB flash drive for /usr, /var, /tmp and swap and they build world successfully. When I set up the RPI3 I thought it would be an improvement to split the swap between partitions on microSD and the USB flash drive. The suspicion I'm harboring is that the swapper on the Pi3 is somehow confounded by having two separate swap devices. The simplest test I can easily perform is to use one swap partiton on the microSD card and a second swap partition on a separate USB device. To start with that'll be a mechanical hard disk, which is generally accepted as well-behaved. Thanks for reading! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 19 12:23:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 60B271016648 for ; Tue, 19 Jun 2018 12:23:39 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E90847DF45 for ; Tue, 19 Jun 2018 12:23:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: by mailman.ysv.freebsd.org (Postfix) id A7D491016643; Tue, 19 Jun 2018 12:23:38 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7E5111016642 for ; Tue, 19 Jun 2018 12:23:38 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from raven.bwct.de (raven.bwct.de [195.149.99.3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "raven.bwct.de", Issuer "raven.bwct.de" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id E1D267DF43 for ; Tue, 19 Jun 2018 12:23:37 +0000 (UTC) (envelope-from ticso@cicely7.cicely.de) Received: from mail.cicely.de ([10.1.1.37]) by raven.bwct.de (8.15.2/8.15.2) with ESMTPS id w5JCAAfY064704 (version=TLSv1 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2018 14:10:11 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=cicely.de; s=default; t=1529410212; bh=Nzcp1C+dklc/HLygOxqu4s9cESnWBSzvSGAb6GhZKk4=; h=Date:From:To:Cc:Subject:Reply-To:References:In-Reply-To; b=Nv8OyiQp9MCv8NeEROCwDhQ8dnRrLHpG7GIvt3pjYalSVoBOf0PcKtNL6jEj8g2Uu cv8txsDZUwGTS/A1iMA7UZDcZ5Qz5WVNUtetqZk8Cp/nukUzS8OALIa5jI1MUWUs/I ziwovvfRnfiMvTv1fWyg7TP0aXJNZquds/Z2QSs0= Received: from cicely7.cicely.de (cicely7.cicely.de [10.1.1.9]) by mail.cicely.de (8.14.5/8.14.4) with ESMTP id w5JCA8sx010901 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL); Tue, 19 Jun 2018 14:10:08 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: from cicely7.cicely.de (localhost [127.0.0.1]) by cicely7.cicely.de (8.15.2/8.15.2) with ESMTPS id w5JCA7ud069712 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 14:10:07 +0200 (CEST) (envelope-from ticso@cicely7.cicely.de) Received: (from ticso@localhost) by cicely7.cicely.de (8.15.2/8.15.2/Submit) id w5JCA6cq069711; Tue, 19 Jun 2018 14:10:06 +0200 (CEST) (envelope-from ticso) Date: Tue, 19 Jun 2018 14:10:06 +0200 From: Bernd Walter To: Warner Losh Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-ID: <20180619121006.GB69230@cicely7.cicely.de> Reply-To: ticso@cicely.de References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Operating-System: FreeBSD cicely7.cicely.de 11.0-STABLE amd64 User-Agent: Mutt/1.5.11 X-Spam-Status: No, score=-2.9 required=5.0 tests=ALL_TRUSTED=-1, BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01 autolearn=ham version=3.3.0 X-Spam-Checker-Version: SpamAssassin 3.3.0 (2010-01-18) on spamd.cicely.de X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 12:23:39 -0000 On Tue, Jun 12, 2018 at 02:43:52PM -0600, Warner Losh wrote: > I have all these boards... > > But they are getting old and nearly are unobtanium these days. Were it not > for the clocks thing, they'd be fine to run -current (I have a slightly pre > new clock version running on a couple of boards). I think I'm with you: we > need a maintainer who has done the work to bring them up to date, or they > need to go. Would be sad to see A20 go, it was such a popular SoC and I own a couple of boards with them, but I also don't have the time to help maintaining the code. -- B.Walter http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. From owner-freebsd-arm@freebsd.org Tue Jun 19 13:24:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A3E821019930 for ; Tue, 19 Jun 2018 13:24:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 3DBA080417 for ; Tue, 19 Jun 2018 13:24:10 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id EB17A1019928; Tue, 19 Jun 2018 13:24:09 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D6E3C1019927 for ; Tue, 19 Jun 2018 13:24:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7DE9180414 for ; Tue, 19 Jun 2018 13:24:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f46.google.com (mail-lf0-f46.google.com [209.85.215.46]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id 1C2AA1C92C for ; Tue, 19 Jun 2018 13:24:09 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f46.google.com with SMTP id p23-v6so18423404lfh.11 for ; Tue, 19 Jun 2018 06:24:09 -0700 (PDT) X-Gm-Message-State: APt69E1nZMTWeWsNcYTKp1YzcpHBZH2ILZC2byw6myrVjcgPuxKGz5wW M6cdqacYbNay+KHdsQj59GI45valQ73YzJ0NbfQ= X-Google-Smtp-Source: ADUXVKKz4HIi177P8r1c10Sx6SKrLv4vBtYDi4AbEDm9hmdxusuKN0rav0grZbiFmRylDHf13akYbjmt8OszfIVNriA= X-Received: by 2002:a19:db18:: with SMTP id s24-v6mr10939194lfg.109.1529414647584; Tue, 19 Jun 2018 06:24:07 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 06:23:46 -0700 (PDT) In-Reply-To: <20180619121006.GB69230@cicely7.cicely.de> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180619121006.GB69230@cicely7.cicely.de> From: Kyle Evans Date: Tue, 19 Jun 2018 08:23:46 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 To: ticso@cicely.de Cc: Warner Losh , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 13:24:10 -0000 On Tue, Jun 19, 2018 at 7:10 AM, Bernd Walter wrote: > On Tue, Jun 12, 2018 at 02:43:52PM -0600, Warner Losh wrote: >> I have all these boards... >> >> But they are getting old and nearly are unobtanium these days. Were it not >> for the clocks thing, they'd be fine to run -current (I have a slightly pre >> new clock version running on a couple of boards). I think I'm with you: we >> need a maintainer who has done the work to bring them up to date, or they >> need to go. > > Would be sad to see A20 go, it was such a popular SoC and I own a couple > of boards with them, but I also don't have the time to help maintaining the > code. Hi, Consider A20 off the chopping block- I want my Banana Pi R1 to eventually be useful, so I added some basic clock support and we should boot on these things again. A10 probably won't go away unless we actually have reported problems- it's a similar enough SoC to the A20 that all of the clocks currently implemented should be the same between the two based on my reading of the documentation. I don't actually have any A10-based boards, though, so I can't volunteer to explicitly maintain/test it. Thanks, Kyle Evans From owner-freebsd-arm@freebsd.org Tue Jun 19 14:13:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B777B101C417 for ; Tue, 19 Jun 2018 14:13:25 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5668282B33 for ; Tue, 19 Jun 2018 14:13:25 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id 16BCD101C413; Tue, 19 Jun 2018 14:13:25 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 04038101C412 for ; Tue, 19 Jun 2018 14:13:25 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 66AE582B2F; Tue, 19 Jun 2018 14:13:24 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w5JED9Ee069694; Tue, 19 Jun 2018 07:13:09 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w5JED9TS069693; Tue, 19 Jun 2018 07:13:09 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201806191413.w5JED9TS069693@pdx.rh.CN85.dnsmgr.net> Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 In-Reply-To: To: Kyle Evans Date: Tue, 19 Jun 2018 07:13:09 -0700 (PDT) CC: ticso@cicely.de, "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 14:13:25 -0000 > On Tue, Jun 19, 2018 at 7:10 AM, Bernd Walter wrote: > > On Tue, Jun 12, 2018 at 02:43:52PM -0600, Warner Losh wrote: > >> I have all these boards... > >> > >> But they are getting old and nearly are unobtanium these days. Were it not > >> for the clocks thing, they'd be fine to run -current (I have a slightly pre > >> new clock version running on a couple of boards). I think I'm with you: we > >> need a maintainer who has done the work to bring them up to date, or they > >> need to go. > > > > Would be sad to see A20 go, it was such a popular SoC and I own a couple > > of boards with them, but I also don't have the time to help maintaining the > > code. > > Hi, > > Consider A20 off the chopping block- I want my Banana Pi R1 to > eventually be useful, so I added some basic clock support and we > should boot on these things again. > > A10 probably won't go away unless we actually have reported problems- > it's a similar enough SoC to the A20 that all of the clocks currently > implemented should be the same between the two based on my reading of > the documentation. I don't actually have any A10-based boards, though, > so I can't volunteer to explicitly maintain/test it. If an A10 board landed in your mailbox would you be willing to keep it inline with your A20 work? > Thanks, > Kyle Evans -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jun 19 14:28:41 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5B7EB101D483 for ; Tue, 19 Jun 2018 14:28:41 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id E5B9A83B36 for ; Tue, 19 Jun 2018 14:28:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id A60DA101D47E; Tue, 19 Jun 2018 14:28:40 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92032101D47D for ; Tue, 19 Jun 2018 14:28:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3D0E283B31 for ; Tue, 19 Jun 2018 14:28:40 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: from mail-lf0-f45.google.com (mail-lf0-f45.google.com [209.85.215.45]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) (Authenticated sender: kevans) by smtp.freebsd.org (Postfix) with ESMTPSA id CEDE81CF44 for ; Tue, 19 Jun 2018 14:28:39 +0000 (UTC) (envelope-from kevans@freebsd.org) Received: by mail-lf0-f45.google.com with SMTP id g21-v6so30484415lfb.4 for ; Tue, 19 Jun 2018 07:28:39 -0700 (PDT) X-Gm-Message-State: APt69E3Kes1lh/JRzvXK1RVe4Q5tN6pCLnkEKLkniyEPGbvZt6sdqPYg zUTeVBY3322G2lwtT6pVkd7XHlKv1TUMmcMlIa4= X-Google-Smtp-Source: ADUXVKJIPaoJx0bsPUcIkh7kExmrHrw8vFlGkFZjMcPsWPg4mgDipK4m2zBg3/BN23mN3HkqsElxykGU3379lZ7OrEA= X-Received: by 2002:a19:8d15:: with SMTP id p21-v6mr9285518lfd.99.1529418518490; Tue, 19 Jun 2018 07:28:38 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a2e:8582:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 07:28:17 -0700 (PDT) In-Reply-To: <201806191413.w5JED9TS069693@pdx.rh.CN85.dnsmgr.net> References: <201806191413.w5JED9TS069693@pdx.rh.CN85.dnsmgr.net> From: Kyle Evans Date: Tue, 19 Jun 2018 09:28:17 -0500 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 To: "Rodney W. Grimes" Cc: "freebsd-arm@freebsd.org" , ticso@cicely.de Content-Type: text/plain; charset="UTF-8" X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 14:28:41 -0000 On Tue, Jun 19, 2018 at 9:13 AM, Rodney W. Grimes wrote: >> On Tue, Jun 19, 2018 at 7:10 AM, Bernd Walter wrote: >> > On Tue, Jun 12, 2018 at 02:43:52PM -0600, Warner Losh wrote: >> >> I have all these boards... >> >> >> >> But they are getting old and nearly are unobtanium these days. Were it not >> >> for the clocks thing, they'd be fine to run -current (I have a slightly pre >> >> new clock version running on a couple of boards). I think I'm with you: we >> >> need a maintainer who has done the work to bring them up to date, or they >> >> need to go. >> > >> > Would be sad to see A20 go, it was such a popular SoC and I own a couple >> > of boards with them, but I also don't have the time to help maintaining the >> > code. >> >> Hi, >> >> Consider A20 off the chopping block- I want my Banana Pi R1 to >> eventually be useful, so I added some basic clock support and we >> should boot on these things again. >> >> A10 probably won't go away unless we actually have reported problems- >> it's a similar enough SoC to the A20 that all of the clocks currently >> implemented should be the same between the two based on my reading of >> the documentation. I don't actually have any A10-based boards, though, >> so I can't volunteer to explicitly maintain/test it. > > If an A10 board landed in your mailbox would you be willing to > keep it inline with your A20 work? Sure. =) > >> Thanks, >> Kyle Evans > > -- > Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Tue Jun 19 15:42:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C084710222AB for ; Tue, 19 Jun 2018 15:42:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3CBEE873A0 for ; Tue, 19 Jun 2018 15:42:56 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5JFh9Tm088291 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 08:43:10 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5JFh95Q088290; Tue, 19 Jun 2018 08:43:09 -0700 (PDT) (envelope-from fbsd) Date: Tue, 19 Jun 2018 08:43:09 -0700 From: bob prohaska To: Trev Cc: Thomas Skibo via freebsd-arm , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619154309.GA88240@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619040017.GB81800@www.zefox.net> <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 15:42:57 -0000 On Tue, Jun 19, 2018 at 03:10:44PM +1000, Trev wrote: > bob prohaska wrote on 19/06/2018 14:00: > > On Tue, Jun 19, 2018 at 12:34:23PM +1000, Trev wrote: > >> > >> Just for reference, with the 32 bit Rpi2, my peak swap usage (with > >> nothing much other than make -j4 buildworld running) is 1.424GB. > > > > That's a surprise, I thought it would be much less. What is your > > swap and storage configuration? > > > root@rpi2 [/root] $ cat /etc/fstab > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw,noatime 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > md1 /tmp mfs rw,noatime,-s100m 0 0 > md2 /var/log mfs rw,noatime,-s15m 0 0 > md3 /var/tmp mfs rw,noatime,-s15m 0 0 > /dev/label/swap none swap sw 0 0 > /dev/ufs/home /home ufs rw,noatime 2 2 > /dev/ufs/usr /usr ufs rw,noatime 2 2 > > > root@rpi2 [/root] $ gpart show > => 63 30318529 mmcsd0 MBR (14G) > 63 102375 1 !12 [active] (50M) > 102438 30216154 2 freebsd (14G) > > => 0 30216154 mmcsd0s2 BSD (14G) > 0 90 - free - (45K) > 90 30216064 1 freebsd-ufs (14G) > > => 40 60567472 da0 GPT (29G) > 40 8 - free - (4.0K) > 48 4194304 1 freebsd-swap (2.0G) > 4194352 54525952 2 freebsd-ufs (26G) > 58720304 1847208 - free - (902M) > > => 40 60567472 da1 GPT (29G) > 40 60567468 1 freebsd-ufs (29G) > 60567508 4 - free - (2.0K) > > > root@rpi2 [/root] $ mount > /dev/ufs/rootfs on / (ufs, local, noatime, soft-updates) > devfs on /dev (devfs, local) > /dev/msdosfs/MSDOSBOOT on /boot/msdos (msdosfs, local, noatime) > /dev/md1 on /tmp (ufs, local, noatime, soft-updates) > /dev/md2 on /var/log (ufs, local, noatime, soft-updates) > /dev/md3 on /var/tmp (ufs, local, noatime, soft-updates) > /dev/ufs/home on /home (ufs, local, noatime, soft-updates) > /dev/ufs/usr on /usr (ufs, local, noatime, soft-updates) > > > da0 at umass-sim0 bus 0 scbus0 target 0 lun 0 > da0: < USB DISK 2.0 PMAP> Removable Direct Access SPC-4 SCSI device > da0: Serial Number 070B6B2514ABD241 > da0: 40.000MB/s transfers > da0: 29574MB (60567552 512 byte sectors) > da0: quirks=0x3 > > da1 at umass-sim1 bus 1 scbus1 target 0 lun 0 > da1: < USB DISK 2.0 PMAP> Removable Direct Access SPC-4 SCSI device > da1: Serial Number 070B6B236F828891 > da1: 40.000MB/s transfers > da1: 29574MB (60567552 512 byte sectors) > da1: quirks=0x3 > > > da0 - 32G Emtec USB memory - houses /home and 2G swap partition > da1 - 32G Emtec USB memory - houses /usr > > > /usr/obj is linked to /home/obj > _______________________________________________ Are da0 and da1 mechanical disks, or flash? What's the motive for using /dev/md for /tmp and /var ? It does appear that /usr/obj and swap share da0, the same setup I have, and potentially a source of congestion. How old is your Pi2? Mine is the early version, armv7. Later models are armv8. They're identified as V1.1 and V1.2, I think. Thanks for posting! bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 19 19:10:17 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CAAEC100892E for ; Tue, 19 Jun 2018 19:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x232.google.com (mail-it0-x232.google.com [IPv6:2607:f8b0:4001:c0b::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 3E99B71266 for ; Tue, 19 Jun 2018 19:10:17 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x232.google.com with SMTP id j135-v6so2007071itj.1 for ; Tue, 19 Jun 2018 12:10:17 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=PEFz7wWXV2twl9zgX/ThTl4OwbiL+qoQCkRD7u4kcdE=; b=s4h2/nexdCR6PNXqZyoR8Gwj4dlXUYWgIfL627QBWAXIg+hedEnzFf90Xy58LgUyD3 B2psKw6fjB4+EPmWNE4qG9QRnz3p2ITNBJLUV5usak9CbWnKiOcPMI/WCb1hSUKT+Xr+ eN/tsirQArFy8Zi9NPmkUJj+objE/CkDvMw7b8x9Ts6WbdS2SUDYVwT8TMgeWRy1BBrd hkN7Z+7KRKviHb65KcFevZXTFTGRe2wxwBzv3Bihqva3ia2Jp3FasnmL6lbe1Z750Mts YmtLvbpq8JXgxgnHS5Q3uhP+4TTc8G9ZbRoLswwuYWgmrrvxTHfXYtD2iJBz4+9+HsJf L13g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=PEFz7wWXV2twl9zgX/ThTl4OwbiL+qoQCkRD7u4kcdE=; b=AGRskem8q+RuayCeZu1eDdKU2cYkqCP8NbdaBrz6/ApzKz6d34At2Id3tdnhJr7fbt 7ejU7UbkKwr7rK6VsdEwKHJgYEWkJF2A5gxPj83z7r1Hz6Qqf58PRsK2wjcdyhHGf2Ut Z0pid4zLZ4oS8HEzMnRJjfWmr5410ZHDQcfAFb8ka8p49cIcSn2lUsl9uw9TAOJYdTBA 67zISlptpUi83BQy8zfPSl5nIbfN7a7CWMTgrR0Qk9u5G6m9/X2tlAduPKobxMIOVnir aCZsa/O/Mqs26E/3Rcc2KsAaW46C9Fti5Yt18lMqYF/KT8MGoy46hNweYod6KmM3DY60 1P0Q== X-Gm-Message-State: APt69E02S8t53DYBO06YrhxqLqi2HJaDg4BNk9rZyifmTknBWzP49WZF XFUYJYExHRt8MlyBHi59saR3DOK7u11nl8TZC/ARRA== X-Google-Smtp-Source: ADUXVKJvL+QL8elY/UDBS0sv76+DiyJrbl3aQ2DH6rGhA2YC9NrS3dyKvZagN+DEM0mrw5GtDTeDGLqqyCnXpvo7Kgc= X-Received: by 2002:a02:6348:: with SMTP id j69-v6mr15146346jac.45.1529435416460; Tue, 19 Jun 2018 12:10:16 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 12:10:15 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180614175622.GC35161@www.zefox.net> <201806142110.w5ELAL0N046840@pdx.rh.CN85.dnsmgr.net> <20180615035225.GA37370@www.zefox.net> From: Warner Losh Date: Tue, 19 Jun 2018 13:10:15 -0600 X-Google-Sender-Auth: uKGH4OpjYjdAG2cyAZzZtZn1BdQ Message-ID: Subject: Re: GPT vs MBR for swap devices To: bob prohaska Cc: "Rodney W. Grimes" , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 19:10:18 -0000 On Thu, Jun 14, 2018 at 10:00 PM, Warner Losh wrote: > > > On Thu, Jun 14, 2018, 9:52 PM bob prohaska wrote: > >> On Thu, Jun 14, 2018 at 02:10:21PM -0700, Rodney W. Grimes wrote: >> > >> > It might be interesting to do in order the swapon >> > commands to 1G USB flash, 1G SD flash, 2G SD flash, >> >> It seems clear that USB flash swap, alone or in any >> combination, fails early in buildworld. > > > I think that's because USB flash can't swap fast enough to keep up with > the page demand. You might be able to confirm this by looking at the write > rates to the swap portions for the various other media with gstat. I > suspect it's FTL is doing more expensive garbage collection under a swap > work load leading to long pauses from time to time that the VM system > responds to by starting OOM too soon. > Looking at the data posted, I see that we have a 2s latency averaged over 10s. This means that the drive is basically unresponsive. So the average latency is 2s. That means that the max latency is likely way more than that (likely as much as 10-20s if my experience with SSD latency distributions can be trusted). The latency bounces around a bit (and there appears to be some missing data), but this is what I expected to see. Now, maybe we have an issue with the USB stack that's causing this (missed interrupts leading to polling 'saving' the day after a massively long time, for example), or the USB drives are as bad as I've experiences them to be. In any event, if we can't retire the dirty pages fast enough, we'll get into OOM to try to cope with too many dirty pages. The different control loops in the system to moderate these things have some 'hidden' assumptions that we can launder pages faster than this, so I think we're falling off the rails when we can't, even when we have available swap space. Warner From owner-freebsd-arm@freebsd.org Tue Jun 19 21:23:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 7DF64100F86E for ; Tue, 19 Jun 2018 21:23:07 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id A451D76AB3 for ; Tue, 19 Jun 2018 21:23:06 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5JLN2a5071189 for ; Wed, 20 Jun 2018 07:23:03 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices To: freebsd-arm@freebsd.org References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619040017.GB81800@www.zefox.net> <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> <20180619154309.GA88240@www.zefox.net> From: Trev Message-ID: <4bfdd1a3-a99b-13a0-28e2-f27b691586f1@sentry.org> Date: Wed, 20 Jun 2018 07:23:02 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180619154309.GA88240@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Wed, 20 Jun 2018 07:23:03 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 21:23:07 -0000 bob prohaska wrote on 20/06/2018 01:43: > On Tue, Jun 19, 2018 at 03:10:44PM +1000, Trev wrote: >> bob prohaska wrote on 19/06/2018 14:00: [...] >> da0 - 32G Emtec USB memory - houses /home and 2G swap partition >> da1 - 32G Emtec USB memory - houses /usr >> >> /usr/obj is linked to /home/obj > Are da0 and da1 mechanical disks, or flash? As above, Emtec USB2 memory keys. > What's the motive for using /dev/md for /tmp > and /var ? /tmp, /var/tmp and /var/log are using /dev/md to save the sdcard from excessive writes. /tmp at least is also used during buildworld and needed bumping up from whatever the default size was to its current 100MB so as not to be exhausted during builds. > How old is your Pi2? Mine is the early version, > armv7. Later models are armv8. They're identified > as V1.1 and V1.2, I think. It's an original rpi2 with an ARM Cortex-A7. From owner-freebsd-arm@freebsd.org Tue Jun 19 21:59:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E92CB1011879 for ; Tue, 19 Jun 2018 21:59:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 66544781E3 for ; Tue, 19 Jun 2018 21:59:49 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5JM006n089378 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 15:00:01 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5JM00tt089377; Tue, 19 Jun 2018 15:00:00 -0700 (PDT) (envelope-from fbsd) Date: Tue, 19 Jun 2018 15:00:00 -0700 From: bob prohaska To: Warner Losh Cc: "Rodney W. Grimes" , "freebsd-arm@freebsd.org" , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619220000.GA89266@www.zefox.net> References: <20180614175622.GC35161@www.zefox.net> <201806142110.w5ELAL0N046840@pdx.rh.CN85.dnsmgr.net> <20180615035225.GA37370@www.zefox.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 21:59:50 -0000 On Tue, Jun 19, 2018 at 01:10:15PM -0600, Warner Losh wrote: > On Thu, Jun 14, 2018 at 10:00 PM, Warner Losh wrote: > > > > > > > On Thu, Jun 14, 2018, 9:52 PM bob prohaska wrote: > > > >> On Thu, Jun 14, 2018 at 02:10:21PM -0700, Rodney W. Grimes wrote: > >> > > >> > It might be interesting to do in order the swapon > >> > commands to 1G USB flash, 1G SD flash, 2G SD flash, > >> > >> It seems clear that USB flash swap, alone or in any > >> combination, fails early in buildworld. > > My statement is now known to be mistaken. Failures happen when USB flash swap is placed on the same device as /usr. USB flash swap or USB mechanical swap works fine when placed on a device remote from /usr > > > > I think that's because USB flash can't swap fast enough to keep up with > > the page demand. You might be able to confirm this by looking at the write > > rates to the swap portions for the various other media with gstat. I > > suspect it's FTL is doing more expensive garbage collection under a swap > > work load leading to long pauses from time to time that the VM system > > responds to by starting OOM too soon. > > > > Looking at the data posted, I see that we have a 2s latency averaged over > 10s. This means that the drive is basically unresponsive. So the average > latency is 2s. That means that the max latency is likely way more than that > (likely as much as 10-20s if my experience with SSD latency distributions > can be trusted). The latency bounces around a bit (and there appears to be > some missing data), but this is what I expected to see. > > Now, maybe we have an issue with the USB stack that's causing this (missed > interrupts leading to polling 'saving' the day after a massively long time, > for example), or the USB drives are as bad as I've experiences them to be. > In any event, if we can't retire the dirty pages fast enough, we'll get > into OOM to try to cope with too many dirty pages. The different control > loops in the system to moderate these things have some 'hidden' assumptions > that we can launder pages faster than this, so I think we're falling off > the rails when we can't, even when we have available swap space. > One more test has completed. The Pi3 was configured with 1 GB swap on the microSD card. It was expected to run out of swap and start the OOM assassin. Instead, it ran until the swap usage hit a little over 80% and then traffic with da0d (/usr, likely /usr/obj) got stuck. Traffic to da0d remained stuck for several sampling cycles, swap usage dropped to a few percent, and I finally pulled the plug when the debugger would not start. The console messages are of a sort seen before and might suggest hardware trouble, but after rebooting and fsck the machine seems just fine and is running another test. It's completely unclear to me what triggered the USB stoppage. The relevant files are at http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/ I hope they're useful. Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Tue Jun 19 23:55:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 655171016D0D for ; Tue, 19 Jun 2018 23:55:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id AE6B17C1EC for ; Tue, 19 Jun 2018 23:55:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5JNtIP0089690 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 16:55:19 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5JNtHYk089689; Tue, 19 Jun 2018 16:55:17 -0700 (PDT) (envelope-from fbsd) Date: Tue, 19 Jun 2018 16:55:17 -0700 From: bob prohaska To: Trev Cc: freebsd-arm@freebsd.org, bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180619235517.GA89572@www.zefox.net> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619040017.GB81800@www.zefox.net> <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> <20180619154309.GA88240@www.zefox.net> <4bfdd1a3-a99b-13a0-28e2-f27b691586f1@sentry.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4bfdd1a3-a99b-13a0-28e2-f27b691586f1@sentry.org> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 19 Jun 2018 23:55:11 -0000 On Wed, Jun 20, 2018 at 07:23:02AM +1000, Trev wrote: > bob prohaska wrote on 20/06/2018 01:43: > > On Tue, Jun 19, 2018 at 03:10:44PM +1000, Trev wrote: > >> bob prohaska wrote on 19/06/2018 14:00: > [...] > >> da0 - 32G Emtec USB memory - houses /home and 2G swap partition > >> da1 - 32G Emtec USB memory - houses /usr > >> > >> /usr/obj is linked to /home/obj > So traffic for both /usr/obj and swap has to go through da0? I'm surprised you aren't seeing difficulties similar to mine. > > Are da0 and da1 mechanical disks, or flash? > > As above, Emtec USB2 memory keys. > Sorry, didn't recognize the brand name. A brief web search suggests they aren't particularly fast at 4k random write. Do you know of any performance data? From what I've seen on the web it's rather surprising your setup does not have problems as mine does. > > What's the motive for using /dev/md for /tmp > > and /var ? > > /tmp, /var/tmp and /var/log are using /dev/md to save the sdcard from > excessive writes. /tmp at least is also used during buildworld and > needed bumping up from whatever the default size was to its current > 100MB so as not to be exhausted during builds. > > > How old is your Pi2? Mine is the early version, > > armv7. Later models are armv8. They're identified > > as V1.1 and V1.2, I think. > > It's an original rpi2 with an ARM Cortex-A7. Apologies for not thinking to ask earlier, but what version of FreeBSD are you using? Right now my test Pi2 is on 11-stable, swap usage appears to peak at around 140 MB. However, /var and /tmp are on flash partitions, not md. Thanks for writing! bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 20 00:54:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id E63EB1019EAB for ; Wed, 20 Jun 2018 00:54:17 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1DE8C7E864 for ; Wed, 20 Jun 2018 00:54:16 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5K0sCQP098847 for ; Wed, 20 Jun 2018 10:54:13 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices Cc: freebsd-arm@freebsd.org References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180618230419.GA81275@www.zefox.net> <20180619005519.GB81275@www.zefox.net> <20180619040017.GB81800@www.zefox.net> <47b8ff7c-2fa7-a6fe-ee43-ed4239b478b8@sentry.org> <20180619154309.GA88240@www.zefox.net> <4bfdd1a3-a99b-13a0-28e2-f27b691586f1@sentry.org> <20180619235517.GA89572@www.zefox.net> From: Trev Message-ID: <7551febe-ca03-10d8-a005-3b0f5d83580d@sentry.org> Date: Wed, 20 Jun 2018 10:54:12 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180619235517.GA89572@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Wed, 20 Jun 2018 10:54:13 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 00:54:18 -0000 bob prohaska wrote on 20/06/2018 09:55: >>> /usr/obj is linked to /home/obj > So traffic for both /usr/obj and swap has to go through da0? > I'm surprised you aren't seeing difficulties similar to mine. Yep - and yep, no issues. >>> Are da0 and da1 mechanical disks, or flash? >> As above, Emtec USB2 memory keys. > Sorry, didn't recognize the brand name. A brief web search > suggests they aren't particularly fast at 4k random write. > Do you know of any performance data? From what I've seen > on the web it's rather surprising your setup does not have > problems as mine does. I experimented with a bunch of memory keys (Verbatim USB3, Kingston USB2, SanDisk USB2, Toshiba USB2, unbranded promotionals from conferences etc) and the Emtec were the best performing (although I went through two 16GB Emtecs that corrupted from day one within minutes unlike the 32GB ones which have now been in use for 6 months). When I say "best performing" I mean specifically they survived buildworlds without any corruption and scored better in the naive diskinfo tests. > Apologies for not thinking to ask earlier, but what > version of FreeBSD are you using? Right now my test > Pi2 is on 11-stable, swap usage appears to peak > at around 140 MB. However, /var and /tmp are on > flash partitions, not md. Currently FreeBSD 11.2-PRERELEASE #0 r335242: Sun Jun 17 15:58:33 AEST 2018 - I've been tracking 11-STABLE and updating more or less weekly. From owner-freebsd-arm@freebsd.org Wed Jun 20 01:44:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 419DF101CE58 for ; Wed, 20 Jun 2018 01:44:04 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic302-2.consmr.mail.bf2.yahoo.com (sonic302-2.consmr.mail.bf2.yahoo.com [74.6.135.41]) (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 D4A7C809B9 for ; Wed, 20 Jun 2018 01:44:03 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: NFXG9_QVM1mK0Tv5BkkZroJBro7fVFmewsIdhlkAmHrTZQtL098WEzPHwi4QrKO DqKyxLEOEZjq.HJRmAmqA1kZaa1J_X732dwoA9mi9v7NtdIC2NIjWHBrCS82wdYN3Tvc.AVd7Aok wYuGysyyJm6hFA9qHCTGv32AyHGEe.DaxWg0aLz7J5NUM73lwbAoto4HhN9o5TMbApESc4VK37YQ H1Y12E1J1TjN5BMVcgE0H.DqDFAdW8sUOMw9.zcadVYqXc1AlcwwtKVPUmlBQjmljgs4uRVg7q20 iFYAD5WPY2D77Qrr_NcWfWNVrWjlMZBltwb1FLJU4QgtSAXOAtTpd5qfGgIFlRzSeKX8JL4OBSpl bEwLyTfsi.BeRn6hTlDAm.HBk7BybmBiwGHcW5IevBoYHxsNq1hhGFqCu_7snoPTmssPTPZyBHnV _fGKAT4bCAsGytnMi4BRYQdoCyeb.US5qAhFDcREJdTiJD5.srAy3aZ.X28Kc5D3PnXG8KlaOE.M _w16uOpsR9BcoXEIW8ztGYKRHV9cqCkZOlD7O6abqFIduMlPR36O8BXG8Lzljtl2aLv32Dhxz5RK eQ1PHPDS_PNlzfBl8M_hnL7NWlyWVtzHvdatZo72JZQsaLNW.w5ItyzDABKGc_RHDWFx8h8mfJd1 kcQa.HIQu0Q6iAAflr2z2hqKPUZAYQYursApxDU2nCyzsEx_TWh_30IBnp7nevWsdcz0JUmGdAAu PrGkWpxyHhcliZlllIph.9FwtrSELl8b2Olx10Kfa1.T91DIEtPTDY6QoddgiILgGB9lk5DtAJKQ lndgQT0B5fFcaFn6N6OSTFP._jlzP4oLG7tZ8plxd86XGfmOmtl1YMfq2.GpIpw3rAybmygmVn6W 9CR6WZf9llt5SD78YMQO2rP_M2BLMfK.XEKO5uPIoqHqMr.kLuYhXIgaZiqSL6jAzJZYv4mK7fEq FmbgpCIyI7A.zQA0bsdxQRKtMczHkV61c_wK8JgLa94j7L5v0LoA9lmhhbsx1ZagV2s3vNY375w- - Received: from sonic.gate.mail.ne1.yahoo.com by sonic302.consmr.mail.bf2.yahoo.com with HTTP; Wed, 20 Jun 2018 01:44:03 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp422.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID edfe701a211bfa40199ba14ac37a458a; Wed, 20 Jun 2018 01:44:02 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices Message-Id: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> Date: Tue, 19 Jun 2018 18:44:00 -0700 To: bob prohaska , freebsd-arm X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 01:44:04 -0000 bob prohaska fbsd at www.zefox.net wrote on Tue Jun 19 21:59:50 UTC 2018 : > One more test has completed. The Pi3 was configured with 1 GB swap on = the=20 > microSD card. It was expected to run out of swap and start the OOM = assassin.=20 > Instead, it ran until the swap usage hit a little over 80% and then=20 > traffic with da0d (/usr, likely /usr/obj) got stuck.=20 >=20 > Traffic to da0d remained stuck for several sampling cycles, swap > usage dropped to a few percent, and I finally pulled the plug when the > debugger would not start. The console messages are of a sort seen = before > and might suggest hardware trouble, but after rebooting and fsck the = machine > seems just fine and is running another test. It's completely unclear = to me=20 > what triggered the USB stoppage. >=20 > The relevant files are at >=20 > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/ >=20 > I hope they're useful. where the referenced place includes this console messaging in one of the files: > r =3D 5 > :48 www init[51271]: can't exec getty '/usr/libexec/getty' for port = /dev/ttyu0: Input/output error > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00=20= > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00=20= > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00=20= > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00=20= > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00=20= > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D 5 > g_vfs_done():da0d[WRITE(offset=3D36764549120, length=3D32768)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D36862820352, length=3D32768)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D36984651776, length=3D65536)]error =3D = 5 > g_vfs_done():da0d[READ(offset=3D39455948800, length=3D32768)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D51207864320, length=3D32768)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D51207962624, length=3D32768)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D51228348416, length=3D4096)]error =3D = 5 > g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 > :45 www init[51281]: can't exec getty '/usr/libexec/getty' for port = /dev/ttyu0: Input/output error As I understand this it indicates that the drive /dev/da0 is failing to execute some requests and returning error status information to FreeBSD. I view this as evidence that you need to get the materials off that drive and need to quit using the drive that was /dev/da0. (Or similar status for connections or other stages between the rpi3 and /dev/da0 [inclusive of both].) One classic problem, when not using a powered hub, is the rpi3 sometimes not providing sufficient quality power to the USB device(s) plugged in. Whatever the case, with the above happening, it is not reasonable to expect things to work. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 20 02:32:40 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id CB961101F2AF for ; Wed, 20 Jun 2018 02:32:40 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 3951181D95 for ; Wed, 20 Jun 2018 02:32:39 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5K2Wr4N090073 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 19 Jun 2018 19:32:54 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5K2Wr2W090072; Tue, 19 Jun 2018 19:32:53 -0700 (PDT) (envelope-from fbsd) Date: Tue, 19 Jun 2018 19:32:53 -0700 From: bob prohaska To: Mark Millard Cc: freebsd-arm , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180620023253.GA89924@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 02:32:41 -0000 On Tue, Jun 19, 2018 at 06:44:00PM -0700, Mark Millard wrote: > bob prohaska fbsd at www.zefox.net wrote on > Tue Jun 19 21:59:50 UTC 2018 : > > > One more test has completed. The Pi3 was configured with 1 GB swap on the > > microSD card. It was expected to run out of swap and start the OOM assassin. > > Instead, it ran until the swap usage hit a little over 80% and then > > traffic with da0d (/usr, likely /usr/obj) got stuck. > > > > Traffic to da0d remained stuck for several sampling cycles, swap > > usage dropped to a few percent, and I finally pulled the plug when the > > debugger would not start. The console messages are of a sort seen before > > and might suggest hardware trouble, but after rebooting and fsck the machine > > seems just fine and is running another test. It's completely unclear to me > > what triggered the USB stoppage. > > > > The relevant files are at > > > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/ > > > > I hope they're useful. > > where the referenced place includes this console messaging in > one of the files: > > > r = 5 > > :48 www init[51271]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain > > (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 00 > > (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error > > (da0:umass-sim0:0:0:0): Error 5, Retries exhausted > > g_vfs_done():da0d[WRITE(offset=20709376, length=4096)]error = 5 > > g_vfs_done():da0d[WRITE(offset=36764549120, length=32768)]error = 5 > > g_vfs_done():da0d[WRITE(offset=36862820352, length=32768)]error = 5 > > g_vfs_done():da0d[WRITE(offset=36984651776, length=65536)]error = 5 > > g_vfs_done():da0d[READ(offset=39455948800, length=32768)]error = 5 > > g_vfs_done():da0d[WRITE(offset=51207864320, length=32768)]error = 5 > > g_vfs_done():da0d[WRITE(offset=51207962624, length=32768)]error = 5 > > g_vfs_done():da0d[WRITE(offset=51228348416, length=4096)]error = 5 > > g_vfs_done():da0d[WRITE(offset=65536, length=4096)]error = 5 > > :45 www init[51281]: can't exec getty '/usr/libexec/getty' for port /dev/ttyu0: Input/output error > > > As I understand this it indicates that the drive /dev/da0 is > failing to execute some requests and returning error status > information to FreeBSD. > > I view this as evidence that you need to get the materials > off that drive and need to quit using the drive that was > /dev/da0. (Or similar status for connections or other stages > between the rpi3 and /dev/da0 [inclusive of both].) > Possibly. An alternative to which I subscribe (for the moment) posits that FreeBSD has started talking rubbish to da0 and da0 is responding appropriately. The problem dissapears on reboot. > One classic problem, when not using a powered hub, is the rpi3 > sometimes not providing sufficient quality power to the USB > device(s) plugged in. > A powered hub is running da1 and da2. Most important, rebooting and fsck clears the difficulty. If that didn't happen I'd agree with you. > Whatever the case, with the above happening, it is not reasonable > to expect things to work. > Indeed! 8-) Thanks for reading, bob prohaska From owner-freebsd-arm@freebsd.org Wed Jun 20 02:50:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92185101FFD7 for ; Wed, 20 Jun 2018 02:50:18 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic310-15.consmr.mail.bf2.yahoo.com (sonic310-15.consmr.mail.bf2.yahoo.com [74.6.135.125]) (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 38393824D5 for ; Wed, 20 Jun 2018 02:50:18 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: BUyqDQ0VM1kH6CUKFagT_R9F5Kps_LXFbrMDbct3jv_M73EFqDdnUhEF2msbV7w eZDqs9Y3yRI9S7_Ret89M.tcuMOg3f2ROoAfi75fWBpxOeqgdwTm.i.GqB3.Gm9uDicQa0c.15RB VOKEEcPmcaFZJ.rIEk5xAYcxND8p0WasZkhKRwi1.GkwAHMV.kiVcvrKIY4idnMPVzRtInP8cXF_ bKbYJIXqIkyc9cP1pveWp.DmtgJnBFklFMzvxXRuVgJArKk9zHeTdZse.r5TiEDQj9Qg4mOGckUr KiZZjijdV_UzGvxxQLxQ1b6qSQGxbEn_VDZq3QiYh4OgSeMy_yvclGh.9SGCOjVbBpWxJ9a.AV0G Nxb1NZ4aj8f3e46AFdQOq_W52CIq6UvFPpDej3i5y9NIlRgtULarVp5C2slVuZeGI1.6jMC91zYp zeOFyVf4vct1fRiXI94s7s3_J5_MxweMB5Ux7o4FlcEbqk9BkcojiMDbWuDwd6FaMrc0xlGPLHgY c47hbSksWaRIvt4i8nl.SgN14PssaBCjkLz25AhUM8dgAuTGMhfc_NvdIvHc055Cf.vcWC0FTONd EL.2ooGasxURN68fg8aEisNhJx4gnuTTjahBu_6PNG07QGUorzbnuNPwFckNDTmataDXd6AWUHhR lm8y9.eAl0pEn4v_N7rpgjWt4NJRbOI_cYv1pDEgHqvBinX_vDIvHP9u_BhxJnMJ0C9tqUzF0wos cVCnpElRlg0JtVX5fu9aX9v7bGpDoZXpuYB_yXX4RzETeeOnVDtIjF8AyQBGjl67mGOnXQ9qLuWK aYoA3ce4efZRvSIa5NNN4nqCiZYbcT2_HKcEAD3jY9xFK1Z231glfXWmjJ.fvo06RdQ_OUBpI3Wi KU.jOQ4igmop_pNt2Znbe1rAvSb.mKNf3cEuRdgcpu.9dAoSRLjHUUoEFOBgfDNJsuDYTsgo.KKw .9lb5lOv6.Y8GrryjcCeF_cM9FJ46SAs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic310.consmr.mail.bf2.yahoo.com with HTTP; Wed, 20 Jun 2018 02:50:11 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp429.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID ef0bce9bcfd1e1322947972220d182d4; Wed, 20 Jun 2018 02:50:07 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180620023253.GA89924@www.zefox.net> Date: Tue, 19 Jun 2018 19:50:05 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <382F3BE3-219E-4C44-9D9E-45C4A7F86B69@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 02:50:18 -0000 On 2018-Jun-19, at 7:32 PM, bob prohaska wrote: > On Tue, Jun 19, 2018 at 06:44:00PM -0700, Mark Millard wrote: >> bob prohaska fbsd at www.zefox.net wrote on >> Tue Jun 19 21:59:50 UTC 2018 : >>=20 >>> One more test has completed. The Pi3 was configured with 1 GB swap = on the=20 >>> microSD card. It was expected to run out of swap and start the OOM = assassin.=20 >>> Instead, it ran until the swap usage hit a little over 80% and then=20= >>> traffic with da0d (/usr, likely /usr/obj) got stuck.=20 >>>=20 >>> Traffic to da0d remained stuck for several sampling cycles, swap >>> usage dropped to a few percent, and I finally pulled the plug when = the >>> debugger would not start. The console messages are of a sort seen = before >>> and might suggest hardware trouble, but after rebooting and fsck the = machine >>> seems just fine and is running another test. It's completely unclear = to me=20 >>> what triggered the USB stoppage. >>>=20 >>> The relevant files are at >>>=20 >>> = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/ >>>=20 >>> I hope they're useful. >>=20 >> where the referenced place includes this console messaging in >> one of the files: >>=20 >>> r =3D 5 >>> :48 www init[51271]: can't exec getty '/usr/libexec/getty' for port = /dev/ttyu0: Input/output error >>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 = 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain >>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 = 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain >>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 = 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain >>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 = 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain >>> (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 00 80 00 00 08 = 00=20 >>> (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an = error >>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted >>> g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D = 5 >>> g_vfs_done():da0d[WRITE(offset=3D36764549120, length=3D32768)]error = =3D 5 >>> g_vfs_done():da0d[WRITE(offset=3D36862820352, length=3D32768)]error = =3D 5 >>> g_vfs_done():da0d[WRITE(offset=3D36984651776, length=3D65536)]error = =3D 5 >>> g_vfs_done():da0d[READ(offset=3D39455948800, length=3D32768)]error =3D= 5 >>> g_vfs_done():da0d[WRITE(offset=3D51207864320, length=3D32768)]error = =3D 5 >>> g_vfs_done():da0d[WRITE(offset=3D51207962624, length=3D32768)]error = =3D 5 >>> g_vfs_done():da0d[WRITE(offset=3D51228348416, length=3D4096)]error =3D= 5 >>> g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 >>> :45 www init[51281]: can't exec getty '/usr/libexec/getty' for port = /dev/ttyu0: Input/output error >>=20 >>=20 >> As I understand this it indicates that the drive /dev/da0 is >> failing to execute some requests and returning error status >> information to FreeBSD. >>=20 >> I view this as evidence that you need to get the materials >> off that drive and need to quit using the drive that was >> /dev/da0. (Or similar status for connections or other stages >> between the rpi3 and /dev/da0 [inclusive of both].) >>=20 > Possibly. An alternative to which I subscribe (for the moment) > posits that FreeBSD has started talking rubbish to da0 and da0=20 > is responding appropriately. The problem dissapears on reboot.=20 I go the other direction: no one else is seeing such issues as far as I can see from the lists. It seems unlikely that FreeBSD would only get the above sort of "talking rubbish" thing for your drive instead of fairly generally. So, unless other folks are also seeing such behavior, including the above sorts of messages, my guess is the problem is not FreeBSD's generation of rubbish. >> One classic problem, when not using a powered hub, is the rpi3 >> sometimes not providing sufficient quality power to the USB >> device(s) plugged in. >>=20 > A powered hub is running da1 and da2. Most important, rebooting and=20 > fsck clears the difficulty. If that didn't happen I'd agree with you.=20= But not /dev/da0 (the problem drive)? I've had such power problems and messages in the past. And normally fsck would make the file system appear to be usable. (But there still could be lots of corruption of some file content in various files that were being written. I sometimes managed to verify such. I tended to delete and reconstruct to avoid such.) >> Whatever the case, with the above happening, it is not reasonable >> to expect things to work. >>=20 > Indeed! 8-) Folks may be more inclined to investigate further if you can reproduce such problems and messages without that specific drive involved (not even attached to the rpi3 during the reproduction). =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Wed Jun 20 03:51:49 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6009F1022CFC for ; Wed, 20 Jun 2018 03:51:49 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EE1FC84F0B for ; Wed, 20 Jun 2018 03:51:48 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.ysv.freebsd.org (Postfix) id A46321022CF6; Wed, 20 Jun 2018 03:51:48 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 92AD81022CF5 for ; Wed, 20 Jun 2018 03:51:48 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4898384F09 for ; Wed, 20 Jun 2018 03:51:48 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 9ACE724933; Wed, 20 Jun 2018 03:51:47 +0000 (UTC) Date: Wed, 20 Jun 2018 03:51:46 +0000 From: Mark Linimon To: Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-ID: <20180620035146.GC29485@lonesome.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 03:51:49 -0000 So now that Kyle has volunteered to look after A20, I'd like to continue this thread: On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > I want to remove A31 support for FreeBSD 12: > - My A31 board (BananapiM1) just died today after a long time of being > my arm32 reference board. Is someone willing to pick up A31, or should we still phase it out? > - I don't want the code to stay like the old 32 bits rockchip or > amlogic code that can't even boot nowadays. I think this would be a good time to drop support for things that have gotten into this state. Do you have a complete list? Does anyone else have any objections? fwiw, I've updated the wiki to note that A20 will continue to be supported, and A10 probably will be. But there are still a number of boards listed there as "supported" that probably have not seen updates for years (specificially, some of the development boards). I'd rather let people know what we recommend for new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be in that list ... are the CubieBoard and WandBoard still popular? What do people think? mcl From owner-freebsd-arm@freebsd.org Wed Jun 20 04:51:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 59AC11025423 for ; Wed, 20 Jun 2018 04:51:50 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id EA02C86E44 for ; Wed, 20 Jun 2018 04:51:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id A54B61025422; Wed, 20 Jun 2018 04:51:49 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 93AA91025421 for ; Wed, 20 Jun 2018 04:51:49 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 1937386E42 for ; Wed, 20 Jun 2018 04:51:48 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w5K4pe6H072813; Tue, 19 Jun 2018 21:51:40 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w5K4peq1072812; Tue, 19 Jun 2018 21:51:40 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 In-Reply-To: <20180620035146.GC29485@lonesome.com> To: Mark Linimon Date: Tue, 19 Jun 2018 21:51:40 -0700 (PDT) CC: Emmanuel Vadot , "freebsd-arm@freebsd.org" X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 04:51:50 -0000 > So now that Kyle has volunteered to look after A20, I'd like to > continue this thread: > > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > > I want to remove A31 support for FreeBSD 12: > > - My A31 board (BananapiM1) just died today after a long time of being > > my arm32 reference board. > > Is someone willing to pick up A31, or should we still phase it out? > > > - I don't want the code to stay like the old 32 bits rockchip or > > amlogic code that can't even boot nowadays. > > I think this would be a good time to drop support for things that have > gotten into this state. Do you have a complete list? Does anyone else > have any objections? > > fwiw, I've updated the wiki to note that A20 will continue to be > supported, and A10 probably will be. Kyle Evans who stepped up to do the A20 has agreed to take on the A10 if I get him an appropriate board. We (Kyle and I) have come to the decision that this should be a CubieBoard 1. I am presently hunting the back dark corners for one, they are avaliable on ebay here and there for not too much money still as well. > But there are still a number of boards listed there as "supported" that > probably have not seen updates for years (specificially, some of the > development boards). I'd rather let people know what we recommend for > new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be > in that list ... are the CubieBoard and WandBoard still popular? > > What do people think? > > mcl > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Wed Jun 20 05:24:29 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 498BA1000CCD for ; Wed, 20 Jun 2018 05:24:29 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id CE01787DC6 for ; Wed, 20 Jun 2018 05:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 8E34D1000CCC; Wed, 20 Jun 2018 05:24:28 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 51BE31000CCB for ; Wed, 20 Jun 2018 05:24:28 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id DDF2387DC5 for ; Wed, 20 Jun 2018 05:24:27 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id n7-v6so3745058itn.1 for ; Tue, 19 Jun 2018 22:24:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=I/PGHCl/Lbd+8WDY3CFp3Y7vVv4nbMzFkALDHfkqeo0=; b=RqA+1hI5xTEisRPgBymC+L8D7pEXgGmIX+pthCTZ0VmjfSlXIrR4NrdCkoCd9fkFZk z0NyKgN56+D+xkbncBMx9L2XzRLysSmFdDJBGxSBpZzSuy7WkQqgIlM/MmwNbPLWIWW9 KZnFkodNORwjgFUa0HjZZGeTLvqaMr92VgODEq/TWWbLXZrvLmVF2j40kIoeo6QQZZP9 +xVW7pEYwstqp85BR4vnFHF3Q+aFgDqEcafpRYiI4Ns1TYTfZBkkrAiFwbz8xW0/6s87 77re+yNbjh5MMBK6Zv4Rs9UKwVBp+PKnMXIqmkQ1a1jgJMMihNJQNSm6pMyQqry4pVfZ JRaA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=I/PGHCl/Lbd+8WDY3CFp3Y7vVv4nbMzFkALDHfkqeo0=; b=jDD392+vtmDB9vgE42C65xgi4gyb8zlCBSp/IfrgAGhDGY3+s1NhT0hsZTiqt75oK3 nWvAEyqWdMsgL0Qng8VeeelI6fpopIhyeTVRLbMU/VxyJajVzzQcKbENjgb/sjQE/bKB d7Cp1LOjVB/9MWXrcG53RpQ6ZaHZ8qYMRWXYVLK2reO8BIOduMTyePYDGb2k0CMNoStg aC1y1eyxgDgeWQpkamc9uZYYB5s0rRhoogwA7WV/0yN3t8pkUo4uJOF7EWbquBR1FJcK KzsHbsUKoQUbAYgV6Q/VIoBgyRT1oc4BoQgcJvRJcFmS9pMB/rhrRyTWvYjaJTsGyMCS 73xw== X-Gm-Message-State: APt69E1EJH8Te3IBcYGBzFwCNJEaTsT8H2rc84uyUnkKmZwjMhqYeRzT yMVd7baynAnZ9/d/+hiVX8JVDToLts9wZ7nuJ/HWig== X-Google-Smtp-Source: ADUXVKK0ep05sIXUBIRORG6yOH9bfHEwyyHfP2nPfwwEVjvlmWA/1cckQsGyIrg0Pm1rcRtiS8sREL/pRm/GA78Z/qQ= X-Received: by 2002:a24:5b81:: with SMTP id g123-v6mr410025itb.1.1529472266946; Tue, 19 Jun 2018 22:24:26 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 22:24:26 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> References: <20180620035146.GC29485@lonesome.com> <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 19 Jun 2018 23:24:26 -0600 X-Google-Sender-Auth: qVpxH7kUJSTLdOiSxlEF8iUxAxo Message-ID: Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 To: "Rodney W. Grimes" Cc: Mark Linimon , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 05:24:29 -0000 On Tue, Jun 19, 2018 at 10:51 PM, Rodney W. Grimes < freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > So now that Kyle has volunteered to look after A20, I'd like to > > continue this thread: > > > > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > > > I want to remove A31 support for FreeBSD 12: > > > - My A31 board (BananapiM1) just died today after a long time of being > > > my arm32 reference board. > > > > Is someone willing to pick up A31, or should we still phase it out? > > > > > - I don't want the code to stay like the old 32 bits rockchip or > > > amlogic code that can't even boot nowadays. > > > > I think this would be a good time to drop support for things that have > > gotten into this state. Do you have a complete list? Does anyone else > > have any objections? > > > > fwiw, I've updated the wiki to note that A20 will continue to be > > supported, and A10 probably will be. > > Kyle Evans who stepped up to do the A20 has agreed to take on > the A10 if I get him an appropriate board. We (Kyle and I) have > come to the decision that this should be a CubieBoard 1. I > am presently hunting the back dark corners for one, they are > avaliable on ebay here and there for not too much money still > as well. > I'm almost positive I have an A10 based board. It's either the CubieBoard or the MarsBoard. Both of which are just very lightly re-warmed reference designs. Then again, they are only $50 on ebay. The biggest issue I see is that it's the only Allwinner board to be single core. Warner From owner-freebsd-arm@freebsd.org Wed Jun 20 05:34:00 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 3835A1001438 for ; Wed, 20 Jun 2018 05:34:00 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id B822968315 for ; Wed, 20 Jun 2018 05:33:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mailman.ysv.freebsd.org (Postfix) id 6E2F7100142E; Wed, 20 Jun 2018 05:33:59 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 494A2100142D for ; Wed, 20 Jun 2018 05:33:59 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: from mail-it0-x22e.google.com (mail-it0-x22e.google.com [IPv6:2607:f8b0:4001:c0b::22e]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id CEEEA68314 for ; Wed, 20 Jun 2018 05:33:58 +0000 (UTC) (envelope-from wlosh@bsdimp.com) Received: by mail-it0-x22e.google.com with SMTP id v83-v6so3824326itc.3 for ; Tue, 19 Jun 2018 22:33:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20150623.gappssmtp.com; s=20150623; h=mime-version:sender:in-reply-to:references:from:date:message-id :subject:to:cc; bh=amG05OkIMnWvF8IUwPH03mA81VU1YOEMU8Gu9YyNJw8=; b=e+tyFw9/ES8cZOQb5R3ebdHzpqfoVApeGGrJJQnZ2PNNpmMbd0/cJQ3HpA3AlAw9vG KKKV0i3Mkgj8Sjqe1PgO7C4lgduoJR0BYXIvh3U8rUyVPnr1GS2M4QwKEpYoO+DLxz1F tpMaFuv+1D4/DY4kJJ9CL/ZgtDWP1FB/+GbNMhmRu8LAzAHvP7wWSXVgmmKWE7QkhaLe E6DZqU1o9ago8sO4gLlcvWT1PIBAHQNb/gyoPr/yu59WPHKbIcS3NT4dhkd1p8AIQrmq c5JDzQ1S2qhANi6L5CcJCH+vG5IZ6sAzxjuMVpyYjh3PhLSIdMPUwZjjZPnek58Dx9Fg EDqA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:sender:in-reply-to:references:from :date:message-id:subject:to:cc; bh=amG05OkIMnWvF8IUwPH03mA81VU1YOEMU8Gu9YyNJw8=; b=tePjqbdRjNmz3EQZTyfkZhaJw6CkzAI/bGXfn1ETk9Exl8aqQyaUrQatJDOssANBRI z2IhVinZ/Foxhe8ZXEGTnOt1Oed7tnOjcsNwHPf+NEjgYeG0w8MNQhX7YIKtfJZQd0D2 uoXojubUD2delZEZkVeIuNGqYU2t8ahufOXXg+IdiRxoI/UbKmI589KUyWlKfc4dzy12 GwcJJ4cid/Hr7Julw/3Nvxt8KQfxXMAWISzxdbBTjEGnjUkcv55FdArp8nA1JKHlmvDc M3ZzmTRfu/xsuRJytoDcdby/bnqqJJxnJNsGdd759pzN7sJ7EZjzxcOYitncvnc7Jd+L Jclg== X-Gm-Message-State: APt69E2HFtY0o+b8+GQpKIgfevnIMUK/gUOtHywUQuBrstPQADQaPonm eUJoU8KpEOpVyW4Ph15QwlCQvHlEflDwMeOAYwRJow== X-Google-Smtp-Source: ADUXVKLRrlnK1EF6TzcNOivAHBVv8PhILrZqHvPgGgA4Z9azrhuNDNsc/epi/J8Abg6D5Nbfs08uPQ9mwOGhBAiy/EE= X-Received: by 2002:a24:64ce:: with SMTP id t197-v6mr452292itc.36.1529472837975; Tue, 19 Jun 2018 22:33:57 -0700 (PDT) MIME-Version: 1.0 Sender: wlosh@bsdimp.com Received: by 2002:a4f:5945:0:0:0:0:0 with HTTP; Tue, 19 Jun 2018 22:33:57 -0700 (PDT) X-Originating-IP: [2603:300b:6:5100:1052:acc7:f9de:2b6d] In-Reply-To: References: <20180620035146.GC29485@lonesome.com> <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> From: Warner Losh Date: Tue, 19 Jun 2018 23:33:57 -0600 X-Google-Sender-Auth: 6mCatvOtSYSp5l-9_hi14xQgVcM Message-ID: Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 To: "Rodney W. Grimes" Cc: Mark Linimon , "freebsd-arm@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 05:34:00 -0000 On Tue, Jun 19, 2018 at 11:24 PM, Warner Losh wrote: > > > On Tue, Jun 19, 2018 at 10:51 PM, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > >> > So now that Kyle has volunteered to look after A20, I'd like to >> > continue this thread: >> > >> > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: >> > > I want to remove A31 support for FreeBSD 12: >> > > - My A31 board (BananapiM1) just died today after a long time of >> being >> > > my arm32 reference board. >> > >> > Is someone willing to pick up A31, or should we still phase it out? >> > >> > > - I don't want the code to stay like the old 32 bits rockchip or >> > > amlogic code that can't even boot nowadays. >> > >> > I think this would be a good time to drop support for things that have >> > gotten into this state. Do you have a complete list? Does anyone else >> > have any objections? >> > >> > fwiw, I've updated the wiki to note that A20 will continue to be >> > supported, and A10 probably will be. >> >> Kyle Evans who stepped up to do the A20 has agreed to take on >> the A10 if I get him an appropriate board. We (Kyle and I) have >> come to the decision that this should be a CubieBoard 1. I >> am presently hunting the back dark corners for one, they are >> avaliable on ebay here and there for not too much money still >> as well. >> > > I'm almost positive I have an A10 based board. It's either the CubieBoard > or the MarsBoard. Both of which are just very lightly re-warmed reference > designs. > Yes. I have one running 11.0 release right now... I should upgrade that to 11.2 for testing Warner From owner-freebsd-arm@freebsd.org Wed Jun 20 08:27:27 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id B9FCF100A832 for ; Wed, 20 Jun 2018 08:27:27 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 58F53701D9 for ; Wed, 20 Jun 2018 08:27:27 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: by mailman.ysv.freebsd.org (Postfix) id 0F718100A82F; Wed, 20 Jun 2018 08:27:27 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id F0F18100A82E for ; Wed, 20 Jun 2018 08:27:26 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from out.alvermark.net (out.alvermark.net [185.34.136.138]) (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 8FFC7701D5 for ; Wed, 20 Jun 2018 08:27:26 +0000 (UTC) (envelope-from jakob@alvermark.net) Received: from c-42bc70d5.06-431-73746f70.bbcust.telenor.se ([213.112.188.66] helo=mail.alvermark.net) by out.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1fVYSS-0004Qg-4E; Wed, 20 Jun 2018 10:27:16 +0200 Received: from [192.168.67.32] by mail.alvermark.net with esmtpsa (TLSv1.2:ECDHE-RSA-AES128-GCM-SHA256:128) (Exim 4.90_1 (FreeBSD)) (envelope-from ) id 1fVYSR-000M9A-Jw; Wed, 20 Jun 2018 10:27:15 +0200 Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 To: "Rodney W. Grimes" , Mark Linimon Cc: "freebsd-arm@freebsd.org" References: <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> From: Jakob Alvermark Message-ID: Date: Wed, 20 Jun 2018 10:27:15 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:27:27 -0000 On 06/20/18 06:51, Rodney W. Grimes wrote: >> So now that Kyle has volunteered to look after A20, I'd like to >> continue this thread: >> >> On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: >>> I want to remove A31 support for FreeBSD 12: >>> - My A31 board (BananapiM1) just died today after a long time of being >>> my arm32 reference board. >> Is someone willing to pick up A31, or should we still phase it out? >> >>> - I don't want the code to stay like the old 32 bits rockchip or >>> amlogic code that can't even boot nowadays. >> I think this would be a good time to drop support for things that have >> gotten into this state. Do you have a complete list? Does anyone else >> have any objections? >> >> fwiw, I've updated the wiki to note that A20 will continue to be >> supported, and A10 probably will be. > Kyle Evans who stepped up to do the A20 has agreed to take on > the A10 if I get him an appropriate board. We (Kyle and I) have > come to the decision that this should be a CubieBoard 1. I > am presently hunting the back dark corners for one, they are > avaliable on ebay here and there for not too much money still > as well. Maybe this could be an alternative? https://www.olimex.com/Products/OLinuXino/A10/A10-OLinuXino-LIME-n4GB/open-source-hardware From their FAQ: How long this board will be available? This board will be available forever Jakob From owner-freebsd-arm@freebsd.org Wed Jun 20 08:32:07 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id ED97A100AC98 for ; Wed, 20 Jun 2018 08:32:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 82B2170619 for ; Wed, 20 Jun 2018 08:32:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 4340F100AC97; Wed, 20 Jun 2018 08:32:06 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 30F68100AC96 for ; Wed, 20 Jun 2018 08:32:06 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 954B770612 for ; Wed, 20 Jun 2018 08:32:05 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 1e9231f0; Wed, 20 Jun 2018 10:31:56 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=wt+TqWYHt9vq//fefzXB3eqxqAY=; b=Kcouxo2lHuJtcf2EVhp1vceWQl8e zn6vMKO+o2HAfdhBeHKWv6lmKV2s0qCN72XfojdA976AV0wPOnSKgCblcLdV/7CU MgFqEWXgm1z/Da3rBhaOS2RDR+xZ/MR9O4u4TktWFjA9cCQFECMoial0M0swrP7Q Rh+x6L/TaFl5DYU= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=dddveM8a8Zpksoe5AfgkgDUhaujcUBmhovgrbxlLsG/pEjw+ZLHyCQBG OadK6QnnaG3P97CzB4eDmMCfwxgBTINuVfVPsNjjKU+oaR2As0kt6NbcCkI/IxYL LHsOhP+teyzcdTbvLwPxjbdpRQj6fag7ak/dtttkyJlPw5RqI+c= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id e2cf5f5a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 20 Jun 2018 10:31:56 +0200 (CEST) Date: Wed, 20 Jun 2018 10:31:56 +0200 From: Emmanuel Vadot To: Mark Linimon Cc: "freebsd-arm@freebsd.org" Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-Id: <20180620103156.a1a4c3e11f669f124b2a3858@bidouilliste.com> In-Reply-To: <20180620035146.GC29485@lonesome.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:32:07 -0000 On Wed, 20 Jun 2018 03:51:46 +0000 Mark Linimon wrote: > So now that Kyle has volunteered to look after A20, I'd like to > continue this thread: > > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > > I want to remove A31 support for FreeBSD 12: > > - My A31 board (BananapiM1) just died today after a long time of being > > my arm32 reference board. > > Is someone willing to pick up A31, or should we still phase it out? Given that A31 is close to A20 in term of drivers and that the clocks are done it can stay. > > - I don't want the code to stay like the old 32 bits rockchip or > > amlogic code that can't even boot nowadays. > > I think this would be a good time to drop support for things that have > gotten into this state. Do you have a complete list? Does anyone else > have any objections? I think that this is the complete list :) > fwiw, I've updated the wiki to note that A20 will continue to be > supported, and A10 probably will be. > > But there are still a number of boards listed there as "supported" that > probably have not seen updates for years (specificially, some of the > development boards). I'd rather let people know what we recommend for > new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be > in that list ... are the CubieBoard and WandBoard still popular? > > What do people think? > > mcl -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Jun 20 08:33:24 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id D80F0100AED7 for ; Wed, 20 Jun 2018 08:33:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 6F328706FD for ; Wed, 20 Jun 2018 08:33:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id 332B3100AED6; Wed, 20 Jun 2018 08:33:23 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 10D41100AED5 for ; Wed, 20 Jun 2018 08:33:23 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 87B0A706FC for ; Wed, 20 Jun 2018 08:33:22 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 3ff2d7bf; Wed, 20 Jun 2018 10:33:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=5PvtF9Q5zx+9/nLM3j2Lnn4sqfc=; b=RsGDoypP8cGrtgouyZIawRlleNys 93rBxd22sDRaKDQkVKYZXqbCD8n24zlG29kWu116gy7OZYw/f//LNTGd41cpkqZz Fxm3OL22BeJwwm79h9hKo6PgcbPRPk0tQeFdRJ7bpa26EfLxIOiYDIn+t/cGPASe m06cnc1AsJUxzV0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=ZA/DNHFiUnvTVIZt3urU3Kk4XKbFsAMWTjWlClNlcTg6nUpttNu6yjNs QWOSb6Rv4+ZdjfetslubJD7Vnm0yjhdM0cNfI1koRZwhnWrUQg1bXNWDkGTMy+ku XnNt8ZBRJru4xRDw7Vk7dpJzZkqp0CWP+wo6jZW8oj7V4olNXyM= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id 8ab1369a TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 20 Jun 2018 10:33:20 +0200 (CEST) Date: Wed, 20 Jun 2018 10:33:20 +0200 From: Emmanuel Vadot To: Warner Losh Cc: "Rodney W. Grimes" , "freebsd-arm@freebsd.org" , Mark Linimon Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-Id: <20180620103320.0d456038ecc4841f7eafb737@bidouilliste.com> In-Reply-To: References: <20180620035146.GC29485@lonesome.com> <201806200451.w5K4peq1072812@pdx.rh.CN85.dnsmgr.net> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 08:33:24 -0000 On Tue, 19 Jun 2018 23:24:26 -0600 Warner Losh wrote: > On Tue, Jun 19, 2018 at 10:51 PM, Rodney W. Grimes < > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > > So now that Kyle has volunteered to look after A20, I'd like to > > > continue this thread: > > > > > > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > > > > I want to remove A31 support for FreeBSD 12: > > > > - My A31 board (BananapiM1) just died today after a long time of being > > > > my arm32 reference board. > > > > > > Is someone willing to pick up A31, or should we still phase it out? > > > > > > > - I don't want the code to stay like the old 32 bits rockchip or > > > > amlogic code that can't even boot nowadays. > > > > > > I think this would be a good time to drop support for things that have > > > gotten into this state. Do you have a complete list? Does anyone else > > > have any objections? > > > > > > fwiw, I've updated the wiki to note that A20 will continue to be > > > supported, and A10 probably will be. > > > > Kyle Evans who stepped up to do the A20 has agreed to take on > > the A10 if I get him an appropriate board. We (Kyle and I) have > > come to the decision that this should be a CubieBoard 1. I > > am presently hunting the back dark corners for one, they are > > avaliable on ebay here and there for not too much money still > > as well. > > > > I'm almost positive I have an A10 based board. It's either the CubieBoard > or the MarsBoard. Both of which are just very lightly re-warmed reference > designs. > > Then again, they are only $50 on ebay. > > The biggest issue I see is that it's the only Allwinner board to be single > core. A13 is also single core, it's somewhat close to A10 and A20. I have a board but didn't booted it in a long time. > Warner > _______________________________________________ > freebsd-arm@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-arm > To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org" -- Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Jun 20 11:07:44 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C9E921012723 for ; Wed, 20 Jun 2018 11:07:44 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 5F58576373 for ; Wed, 20 Jun 2018 11:07:44 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: by mailman.ysv.freebsd.org (Postfix) id 1F7411012722; Wed, 20 Jun 2018 11:07:44 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EC0041012721 for ; Wed, 20 Jun 2018 11:07:43 +0000 (UTC) (envelope-from jedi@jeditekunum.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 86D9076372 for ; Wed, 20 Jun 2018 11:07:43 +0000 (UTC) (envelope-from jedi@jeditekunum.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1529493763; h=Feedback-ID: X-Smtpcorp-Track:To:Date:Subject:Message-Id:From:Reply-To:Sender: List-Unsubscribe; bh=wSm+KBLinRtFs5vSOUfZrwuEdOzkp6hVjeW923rsi9s=; b=iKVajluI NT0PRG0yNe2p75EdtPdx9hjn2PDM6xfFGBtMjOI+hFe/g6oSZgXY9sxfbZQ7fTHty2hjpiqb3dat3 MnQs2nuIRPFIw6Y0pJnbbP79K8EXEQ+4twLxki+gDgSq08txdrvVTw0D1wZdC04u7hhYcRga4ZUPH XRp0w5gKxRxWPGXA7X40/P1LPLGPg26AU41UytAWzTGZW6UuL0rq4XnZP6DDy+V3o9n/m1E3T9GO4 uCcLzvD+7ql//TAE8nM+LMFdJdf0ElnfGUm9aC2pXlbwy9USsr/peGfn8AmDANFxvNDExmZgD5+Wg qgUVRs4J5fEfSI7quCJ5hc3lhg==; From: Jedi Tek'Unum Message-Id: Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Date: Wed, 20 Jun 2018 06:07:27 -0500 In-Reply-To: <20180620035146.GC29485@lonesome.com> Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" To: Mark Linimon References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> X-Mailer: Apple Mail (2.3445.8.2) X-Smtpcorp-Track: 1fVaxbDIIPNSRh.KnVx_ijlq Feedback-ID: 207158m:207158azGM_-I:207158sGJtTIjJl7:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 11:07:45 -0000 On Jun 19, 2018, at 10:51 PM, Mark Linimon wrote: > development boards). I'd rather let people know what we recommend for > new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be > in that list ... are the CubieBoard and WandBoard still popular? I=E2=80=99ve found the NanoPi NEO series more desirable than the similar = OrangePi models. Heatsink. Metal case. OLED/button board. = http://www.friendlyarm.com Perfect for = many really small projects. I=E2=80=99m still using Linux on mine as there isn=E2=80=99t = out-of-the-box support from FreeBSD. I did find a build that someone had = done awhile back that seemed to work. I suspect the differences are = minor. Unfortunately, I don=E2=80=99t have the time to learn the details = of board support to contribute at this time. The support for =E2=80=9Clarger=E2=80=9D boards is great. I hope there = is a continued expansion downward - all the way to IoT scale. The NEO / = Zero style boards are getting close. While a bit larger, they are = cheaper - and obviously far more powerful - than things like an AdaFruit = Feather or Particle Photon = . How long until we see hardware that shrinks = down to those sizes and is unix-capable? From owner-freebsd-arm@freebsd.org Wed Jun 20 13:22:37 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 897D71019473 for ; Wed, 20 Jun 2018 13:22:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 2479C7A71E for ; Wed, 20 Jun 2018 13:22:37 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: by mailman.ysv.freebsd.org (Postfix) id D25711019470; Wed, 20 Jun 2018 13:22:36 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BF769101946F for ; Wed, 20 Jun 2018 13:22:36 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2B0687A71D for ; Wed, 20 Jun 2018 13:22:35 +0000 (UTC) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: from pdx.rh.CN85.dnsmgr.net (localhost [127.0.0.1]) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3) with ESMTP id w5KDMVqU074633; Wed, 20 Jun 2018 06:22:31 -0700 (PDT) (envelope-from freebsd-rwg@pdx.rh.CN85.dnsmgr.net) Received: (from freebsd-rwg@localhost) by pdx.rh.CN85.dnsmgr.net (8.13.3/8.13.3/Submit) id w5KDMVq4074632; Wed, 20 Jun 2018 06:22:31 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <201806201322.w5KDMVq4074632@pdx.rh.CN85.dnsmgr.net> Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 In-Reply-To: To: Warner Losh Date: Wed, 20 Jun 2018 06:22:31 -0700 (PDT) CC: "freebsd-arm@freebsd.org" , Mark Linimon X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 13:22:37 -0000 > On Tue, Jun 19, 2018 at 11:24 PM, Warner Losh wrote: > > > > On Tue, Jun 19, 2018 at 10:51 PM, Rodney W. Grimes < > > freebsd-rwg@pdx.rh.cn85.dnsmgr.net> wrote: > > > >> > So now that Kyle has volunteered to look after A20, I'd like to > >> > continue this thread: > >> > > >> > On Tue, Jun 12, 2018 at 10:32:48PM +0200, Emmanuel Vadot wrote: > >> > > I want to remove A31 support for FreeBSD 12: > >> > > - My A31 board (BananapiM1) just died today after a long time of > >> being > >> > > my arm32 reference board. > >> > > >> > Is someone willing to pick up A31, or should we still phase it out? > >> > > >> > > - I don't want the code to stay like the old 32 bits rockchip or > >> > > amlogic code that can't even boot nowadays. > >> > > >> > I think this would be a good time to drop support for things that have > >> > gotten into this state. Do you have a complete list? Does anyone else > >> > have any objections? > >> > > >> > fwiw, I've updated the wiki to note that A20 will continue to be > >> > supported, and A10 probably will be. > >> > >> Kyle Evans who stepped up to do the A20 has agreed to take on > >> the A10 if I get him an appropriate board. We (Kyle and I) have > >> come to the decision that this should be a CubieBoard 1. I > >> am presently hunting the back dark corners for one, they are > >> avaliable on ebay here and there for not too much money still > >> as well. > >> > > > > I'm almost positive I have an A10 based board. It's either the CubieBoard > > or the MarsBoard. Both of which are just very lightly re-warmed reference > > designs. > > > > Yes. I have one running 11.0 release right now... I should upgrade that to > 11.2 for testing That would be greatly appreciated! -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-arm@freebsd.org Wed Jun 20 14:58:39 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 75E36101D5B0 for ; Wed, 20 Jun 2018 14:58:39 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id F18647DB20 for ; Wed, 20 Jun 2018 14:58:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id B1898101D5AF; Wed, 20 Jun 2018 14:58:38 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 9D488101D5AE for ; Wed, 20 Jun 2018 14:58:38 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 161B07DB1F for ; Wed, 20 Jun 2018 14:58:37 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 6415ef2c-749a-11e8-b829-b3adae557cda X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 6415ef2c-749a-11e8-b829-b3adae557cda; Wed, 20 Jun 2018 14:58:30 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5KEwSKa081844; Wed, 20 Jun 2018 08:58:28 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529506708.20460.72.camel@freebsd.org> Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 From: Ian Lepore To: Mark Linimon , Emmanuel Vadot Cc: "freebsd-arm@freebsd.org" Date: Wed, 20 Jun 2018 08:58:28 -0600 In-Reply-To: <20180620035146.GC29485@lonesome.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 14:58:39 -0000 On Wed, 2018-06-20 at 03:51 +0000, Mark Linimon wrote: > So now that Kyle has volunteered to look after A20, I'd like to > continue this thread: > > [...] > > But there are still a number of boards listed there as "supported" that > probably have not seen updates for years (specificially, some of the > development boards).  I'd rather let people know what we recommend for > new arm users.  I expect RPi, Pine64, OrangePi, and BeagleBone to be > in that list ... are the CubieBoard and WandBoard still popular? Wandboard, and most other things imx6-based, still work and are reasonably well-supported, and I'm even still actively writing new drivers for them as needed. The imx5-based systems (exynos, and a couple dev/eval boards) are still somewhat supported (I have a board and will try to fix anything anyone reports), but were never widely used. -- Ian From owner-freebsd-arm@freebsd.org Wed Jun 20 15:04:50 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 738E3101DB55 for ; Wed, 20 Jun 2018 15:04:50 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 124F57E202 for ; Wed, 20 Jun 2018 15:04:50 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: by mailman.ysv.freebsd.org (Postfix) id BD133101DB54; Wed, 20 Jun 2018 15:04:49 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id AB67E101DB53 for ; Wed, 20 Jun 2018 15:04:49 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from mail.soaustin.net (mail.soaustin.net [18.222.6.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.soaustin.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 5FAF77E1FF; Wed, 20 Jun 2018 15:04:49 +0000 (UTC) (envelope-from linimon@lonesome.com) Received: from lonesome.com (unknown [18.188.142.31]) by mail.soaustin.net (Postfix) with ESMTPSA id 8196B24936; Wed, 20 Jun 2018 15:04:48 +0000 (UTC) Date: Wed, 20 Jun 2018 15:04:47 +0000 From: Mark Linimon To: Ian Lepore Cc: Emmanuel Vadot , "freebsd-arm@freebsd.org" Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-ID: <20180620150446.GA29313@lonesome.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> <1529506708.20460.72.camel@freebsd.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1529506708.20460.72.camel@freebsd.org> User-Agent: Mutt/1.5.21 (2010-09-15) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:04:50 -0000 On Wed, Jun 20, 2018 at 08:58:28AM -0600, Ian Lepore wrote: > Wandboard, and most other things imx6-based, still work and are > reasonably well-supported, and I'm even still actively writing new > drivers for them as needed. I did look through the u-boot ports yesterday and now see that they were added in 2015 -- I would have guessed 2012 or something. So I'm wrong in this case. mcl From owner-freebsd-arm@freebsd.org Wed Jun 20 15:11:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4894E101E0A4 for ; Wed, 20 Jun 2018 15:11:01 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DABCB7E87B for ; Wed, 20 Jun 2018 15:11:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: by mailman.ysv.freebsd.org (Postfix) id 9B020101E0A3; Wed, 20 Jun 2018 15:11:00 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 88AA6101E0A2 for ; Wed, 20 Jun 2018 15:11:00 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from pmta2.delivery6.ore.mailhop.org (pmta2.delivery6.ore.mailhop.org [54.200.129.228]) (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 10ABC7E876 for ; Wed, 20 Jun 2018 15:10:59 +0000 (UTC) (envelope-from ian@freebsd.org) X-MHO-RoutePath: aGlwcGll X-MHO-User: 2241d7cd-749c-11e8-b829-b3adae557cda X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (unknown [67.177.211.60]) by outbound2.ore.mailhop.org (Halon) with ESMTPSA id 2241d7cd-749c-11e8-b829-b3adae557cda; Wed, 20 Jun 2018 15:10:58 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id w5KFAvkV081903; Wed, 20 Jun 2018 09:10:57 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <1529507457.20460.75.camel@freebsd.org> Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 From: Ian Lepore To: Mark Linimon Cc: "freebsd-arm@freebsd.org" Date: Wed, 20 Jun 2018 09:10:57 -0600 In-Reply-To: <20180620150446.GA29313@lonesome.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> <1529506708.20460.72.camel@freebsd.org> <20180620150446.GA29313@lonesome.com> Content-Type: text/plain; charset="ISO-8859-1" X-Mailer: Evolution 3.18.5.1 FreeBSD GNOME Team Port Mime-Version: 1.0 Content-Transfer-Encoding: 8bit X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:11:01 -0000 On Wed, 2018-06-20 at 15:04 +0000, Mark Linimon wrote: > On Wed, Jun 20, 2018 at 08:58:28AM -0600, Ian Lepore wrote: > > > > Wandboard, and most other things imx6-based, still work and are > > reasonably well-supported, and I'm even still actively writing new > > drivers for them as needed. > I did look through the u-boot ports yesterday and now see that they > were added in 2015 -- I would have guessed 2012 or something.  So I'm > wrong in this case. > > mcl At one time there was a port for the imx6-based Utilite system. I'm not sure if it was ever committed or existed only in patch form. Either way, I'm also not sure it ever worked and not sure that system was ever properly supported. At one point I looked into buying one so we could support it better, but it's so ridiculously overpriced that I didn't bother, figuring nobody was going to pay that much for obsolete hardware like 32gb SSD drives anyway, so support isn't really important. -- Ian From owner-freebsd-arm@freebsd.org Wed Jun 20 15:16:10 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 69066101E84A for ; Wed, 20 Jun 2018 15:16:10 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id DFB317F34A for ; Wed, 20 Jun 2018 15:16:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: by mailman.ysv.freebsd.org (Postfix) id A3509101E83E; Wed, 20 Jun 2018 15:16:09 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 91D0A101E83D for ; Wed, 20 Jun 2018 15:16:09 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.blih.net", Issuer "mail.blih.net" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 052CC7F346 for ; Wed, 20 Jun 2018 15:16:08 +0000 (UTC) (envelope-from manu@bidouilliste.com) Received: from mail.blih.net (mail.blih.net [212.83.177.182]) by mail.blih.net (OpenSMTPD) with ESMTP id 9ef64dca; Wed, 20 Jun 2018 17:16:06 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; s=mail; bh=lrP/5JhbTJUw31tMO+aLkEBHdLQ=; b=G9HNbmKWVWun4YOt8Nu/CQo3LqaH KWzDzTngmRpWmWjbgB/MtYHscOFZNK4FY+28s0xBC5wGFy2wHsoCNEtqAIgV2W/M JxeUqZKg9SMIIn/zJEVECglU68TB9XyJLxkN7r4sX+W63rhefTgPcHU1dhBSOGDq poQ+4gULRgOZ1qI= DomainKey-Signature: a=rsa-sha1; c=nofws; d=bidouilliste.com; h=date :from:to:cc:subject:message-id:in-reply-to:references :mime-version:content-type:content-transfer-encoding; q=dns; s= mail; b=lhdVW8NgFJToC0/LxQ3ByCFYwd1trxEf5sBYMcAESiUH07BglNOYRcaI D2qyGY9Q+k/dCCE6fjbZqJEBK0EfTAj/c3RA+QBqCrlDGUy86dz5GFgS+aBYCGBH cdS2TX82UQcnu4xowEG+tuYJtCchRtzbZwl40VL+do5deh6owmg= Received: from skull.home.blih.net (ip-9.net-89-3-105.rev.numericable.fr [89.3.105.9]) by mail.blih.net (OpenSMTPD) with ESMTPSA id ae7f66eb TLS version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO; Wed, 20 Jun 2018 17:16:06 +0200 (CEST) Date: Wed, 20 Jun 2018 17:16:05 +0200 From: Emmanuel Vadot To: Jedi Tek'Unum Cc: Mark Linimon , "freebsd-arm@freebsd.org" Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 Message-Id: <20180620171605.b66d2e87f7a1e126279892b8@bidouilliste.com> In-Reply-To: References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> X-Mailer: Sylpheed 3.7.0 (GTK+ 2.24.32; amd64-portbld-freebsd12.0) Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:16:10 -0000 On Wed, 20 Jun 2018 06:07:27 -0500 Jedi Tek'Unum wrote: > On Jun 19, 2018, at 10:51 PM, Mark Linimon wrote: > > development boards). I'd rather let people know what we recommend for > > new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be > > in that list ... are the CubieBoard and WandBoard still popular? >=20 > I?ve found the NanoPi NEO series more desirable than the similar OrangePi= models. Heatsink. Metal case. OLED/button board. http://www.friendlyarm.co= m Perfect for many really small projects. >=20 > I?m still using Linux on mine as there isn?t out-of-the-box support from = FreeBSD. I did find a build that someone had done awhile back that seemed t= o work. I suspect the differences are minor. Unfortunately, I don?t have th= e time to learn the details of board support to contribute at this time. Mhm, it is suppored out of the box for a lot of the NanoPi NEO (I think I have them all). But in 12 due to drivers and more importantly DTS. > The support for ?larger? boards is great. I hope there is a continued exp= ansion downward - all the way to IoT scale. The NEO / Zero style boards are= getting close. While a bit larger, they are cheaper - and obviously far mo= re powerful - than things like an AdaFruit Feather or Particle Photon . How long unt= il we see hardware that shrinks down to those sizes and is unix-capable? >=20 --=20 Emmanuel Vadot From owner-freebsd-arm@freebsd.org Wed Jun 20 15:33:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6C072101F8AE for ; Wed, 20 Jun 2018 15:33:51 +0000 (UTC) (envelope-from jeditekunum@gmail.com) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 07DD98010C for ; Wed, 20 Jun 2018 15:33:51 +0000 (UTC) (envelope-from jeditekunum@gmail.com) Received: by mailman.ysv.freebsd.org (Postfix) id BCAD1101F8AD; Wed, 20 Jun 2018 15:33:50 +0000 (UTC) Delivered-To: arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A9D9C101F8AC for ; Wed, 20 Jun 2018 15:33:50 +0000 (UTC) (envelope-from jeditekunum@gmail.com) Received: from a1i76.smtp2go.com (a1i76.smtp2go.com [43.228.184.76]) (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 4787680109 for ; Wed, 20 Jun 2018 15:33:50 +0000 (UTC) (envelope-from jeditekunum@gmail.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=smtpservice.net; s=m4fue0.a1-4.dyn; x=1529509730; h=Feedback-ID: X-Smtpcorp-Track:To:Message-Id:Date:From:Subject:Reply-To:Sender: List-Unsubscribe; bh=e60/HijdiD9XY8nzigTtumOmTuLREAJTDusGqBPGNbQ=; b=yW0YSlLh OhbQ0DvIyjloFjipH3dhd+sCXeBr66y0dnMlm7Gh9+9hOicU+ZSqzrrnEPJdBO4KGCXyfGruueK1r yr/CywGgJetjwSLfm6gy74WqYLeQdoCPwfxkIEDAej7RO6zzazC37y44uhwFH4pj16Mbm64VsbVd0 1NfdAUty0bx6UQ5w3o5uTRnSUVYaSJU4V+9DZopTZC2++0gaFkxkaF4vGNimzT7BMlwqBTW0EnnMr 5t0iX6fzKVpcPQjaOx7c4HuAqKxf13KVT7NTJRbnk4yE2bxBMM+nt1HiRiVL1uOFLQST7BR48JwC4 /4jLxv69fyhbo8IpHaw3SDpGtw==; Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (1.0) Subject: Re: De-orbit Allwinner A10/A20/A31 for 12.0 From: Jedi Tek'Unum X-Mailer: iPad Mail (15E302) In-Reply-To: <20180620171605.b66d2e87f7a1e126279892b8@bidouilliste.com> Date: Wed, 20 Jun 2018 10:33:42 -0500 Cc: "freebsd-arm@freebsd.org" Content-Transfer-Encoding: quoted-printable Message-Id: <8954B76B-4198-4675-8312-ED5CE1A3C067@gmail.com> References: <20180612223248.f95d9ce3961187576e220614@bidouilliste.com> <20180620035146.GC29485@lonesome.com> <20180620171605.b66d2e87f7a1e126279892b8@bidouilliste.com> To: Emmanuel Vadot X-Smtpcorp-Track: 1fVf7UmPZIs2Ve.KMePlEN32 Feedback-ID: 207158m:207158azGM_-I:207158sGJtTIjJl7:SMTPCORP X-Report-Abuse: Please forward a copy of this message, including all headers, to X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 15:33:51 -0000 > On Jun 20, 2018, at 10:16 AM, Emmanuel Vadot wrote= : >=20 > On Wed, 20 Jun 2018 06:07:27 -0500 > Jedi Tek'Unum wrote: >=20 >>> On Jun 19, 2018, at 10:51 PM, Mark Linimon wrote:= >>> development boards). I'd rather let people know what we recommend for >>> new arm users. I expect RPi, Pine64, OrangePi, and BeagleBone to be >>> in that list ... are the CubieBoard and WandBoard still popular? >>=20 >> I?ve found the NanoPi NEO series more desirable than the similar OrangePi= models. Heatsink. Metal case. OLED/button board. http://www.friendlyarm.com= Perfect for many really small projects. >>=20 >> I?m still using Linux on mine as there isn?t out-of-the-box support from = FreeBSD. I did find a build that someone had done awhile back that seemed to= work. I suspect the differences are minor. Unfortunately, I don?t have the t= ime to learn the details of board support to contribute at this time. >=20 > Mhm, it is suppored out of the box for a lot of the NanoPi NEO (I > think I have them all). But in 12 due to drivers and more importantly > DTS. Great! It has been awhile since I checked CURRENT. Much appreciated. Thank y= ou!= From owner-freebsd-arm@freebsd.org Wed Jun 20 22:20:51 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 79670100F942 for ; Wed, 20 Jun 2018 22:20:51 +0000 (UTC) (envelope-from willecowell@keemail.me) Received: from w1.tutanota.de (w1.tutanota.de [81.3.6.162]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "tutanota.de", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 1837377639 for ; Wed, 20 Jun 2018 22:20:50 +0000 (UTC) (envelope-from willecowell@keemail.me) Received: from w1.tutanota.de (unknown [192.168.1.162]) by w1.tutanota.de (Postfix) with ESMTP id 83D43FBF108 for ; Wed, 20 Jun 2018 22:20:41 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=keemail.me; s=20161216; t=1529533241; bh=qFKEDefPjWrLdQgxLMZPxkOw8jf9PWhPMRsZP3fsrUU=; h=Date:From:To:Subject:From; b=xpvekSy9gIjTwIfu9vHoUjCRreNtzgDjsrie5yxvjvlHUKv8Fo1pdlCvEpBinI9C8 kIuvihf8/CBCrYLQQd8kpPbRRheATaXTRNqEEH6JXqCJgJB+dr9CdanGVXteTQPLcs x2EhGhxh/HCjNT/6wIktNJXYyF/tncJYCyvOfYyLQJHbee1hn+v9vkIlvYdLTf9pD2 0UQqGMsgerzx7lrsC+M+ct+c1wOjOXkH2FCVVj/rogjs6+DAczhQ1oR8ceq7OBWKpn zdPxEfkQRrmtyC4kIjGF9fduejnwa8sZM1H5b0dpmV2NfUJ6C8dJjSYZZIV7wU+NBi ULLS4Y9X77aRQ== Date: Thu, 21 Jun 2018 00:20:41 +0200 (CEST) From: To: Message-ID: Subject: Raspberry Pi 2 high interrupts MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.26 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 20 Jun 2018 22:20:51 -0000 Hello, I have 4 Raspberry Pi 2's that I have been setting up FreeBSD-CURRENT, and noticed that 3 of them exhibit an unusually high interrupt causing the load averages to be 2.0 on 2 of them and 1.0 on another. Nothing changes if they are idle or under load (make -j4 buildworld) I have put the output of dmesg, "systat -vm" and "vmstat -i" in to 2 different pastebin links. https://pastebin.com/jXLgywRr https://pastebin.com/N6LBY2H9 The 4 Raspberry Pi 2 are identical, only difference between each pair is the Micro SD card. From owner-freebsd-arm@freebsd.org Thu Jun 21 07:28:20 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 41C9E10117D4 for ; Thu, 21 Jun 2018 07:28:20 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 7EAC27049D for ; Thu, 21 Jun 2018 07:28:19 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5L7S8pO094498 for ; Thu, 21 Jun 2018 17:28:08 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices Cc: freebsd-arm References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> From: Trev Message-ID: Date: Thu, 21 Jun 2018 17:28:08 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <20180620023253.GA89924@www.zefox.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Thu, 21 Jun 2018 17:28:08 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 07:28:20 -0000 I gave in and bought an Raspberry Pi 3B+ and now I've been bitten by Bob's OOM assassin too... % gpart show => 63 31116225 mmcsd0 MBR (15G) 63 2016 - free - (1.0M) 2079 102312 1 fat32lba [active] (50M) 104391 31008825 2 freebsd (15G) 31113216 3072 - free - (1.5M) => 0 31008825 mmcsd0s2 BSD (15G) 0 57 - free - (29K) 57 31008768 1 freebsd-ufs (15G) => 40 60567472 da0 GPT (29G) 40 4194304 1 freebsd-swap (2.0G) 4194344 56373168 2 freebsd-ufs (27G) % cat /etc/fstab # Custom /etc/fstab for FreeBSD embedded images /dev/ufs/rootfs / ufs rw,noatime 1 1 /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 md1 /tmp mfs rw,noatime,-s100m 0 0 md2 /var/log mfs rw,noatime,-s15m 0 0 md3 /var/tmp mfs rw,noatime,-s15m 0 0 /dev/ufs/swap none swap sw 0 0 /dev/ufs/usr /usr ufs rw,noatime 2 2 da0 is a brand new 32G EMTEC USB2 memory key housing /usr and swap partitions. FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 make -j4 buildworld resulted in: Jun 21 17:05:12 rpi3 kernel: pid 10326 (c++), uid 0, was killed: out of swap space --- CodeGen/AsmPrinter/CodeViewDebug.o --- c++: error: unable to execute command: Killed c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) Target: aarch64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: 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. c++: note: diagnostic msg: I happened to have been watching top (5 second interval) at the time and of the 2G swap, only 45M was shown to be in use. From owner-freebsd-arm@freebsd.org Thu Jun 21 14:16:30 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 0EC4B1020408 for ; Thu, 21 Jun 2018 14:16:30 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic305-3.consmr.mail.bf2.yahoo.com (sonic305-3.consmr.mail.bf2.yahoo.com [74.6.133.42]) (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 A7F0D7E4C0 for ; Thu, 21 Jun 2018 14:16:29 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: XMpKwX0VM1lLLVL_LeqX51wND0PJkGyTUGSJ48btKXCrdkmBXah6tOtWjL7qHoa Z7yKsohofZ9gMgyCMKl.6N0caz5L4c3FXp4vAgrI1iXv4R2AS49WS1EfNhXllC8kZgOL9yNhjHuH oT8zTeam9unnF9vwnZvCiq3fDZt7r8OnnCtOzF6N4p0kia5ujc6d4PtI7JwbeOb5jjYZslp.Az0J 9V4gEHdRjccnaBo253y__zjVDdm_Y2.ECfR.Xk4SEcZNFHJ_fmup6sQo.2hF8fOkw5SKjNqhd3hW bgS5FIgtPEMw5et2yt.StcPxIp5TP4VHK9Iz61ccFf6oCkiN7e.vZTBAaBIbfQI.9YK_jkLNMiMa ERQhZ9rYv61gN5qTR8FuxvH2NP6mlGFnRjPeK38cMyZTND8xmLU8RMpOQcPSbJ.cB3pXXO.RIwsJ WSdfrxf0Pv4y624Jxs5bPjnU71pnvNSGvs0EGU5LdGJ6uXYqQzFwN308fSChu.dN3Tk4uZxdL40R ZIkQ3KOhcV4kIBHwqawAkjDjXvZ5myi6U8mTiynsc0qKreBw64dsD1nkmBqi24GQbfB7fBUXNajS vfaxsGb2nfhEZOacJXX4jcfLCmAKHBKkv4mbeiwkfpxnB0jSj8p4mB5QCUEa9PrlUQR46sr2VIB5 vQ4d.7f.E4AJamTX.p5j84eIMgBODzJ4sZWxqP1dCsObtSkjFMPbQCoBjuN2rmbjah5u5B4er1ml rAL6xhMXEpsCpXTpsHXYBaS4hEJeRio2jAyy1y4ATJJSZjbstiJFCgxSZ6KiMlDnPgQceKIhg_PE wvE1YoxMgJSntmvj.PyH50gkLJNFohD68Jdc7oGuD2DGWx6GBeIrR_0IVyOkguMPm5uzOdjS938A QZY4kAHixZ47_ZQkri7kbHFAgr8NXvxZz6vOotNNWedk54oGoz58Tjoxr.8Du2IiyE1Jp9mEPfgt TndejFi1fPHJlS_uq3sOLeuh8ooFSOuqbgBm_5Xs- Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.bf2.yahoo.com with HTTP; Thu, 21 Jun 2018 14:16:22 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp411.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 9e2a860759b4dcedf1d8f71cfaaa0c2b; Thu, 21 Jun 2018 14:16:21 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: Date: Thu, 21 Jun 2018 07:16:19 -0700 Cc: freebsd-arm , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> To: Trev X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:16:30 -0000 On 2018-Jun-21, at 12:28 AM, Trev wrote: > I gave in and bought an Raspberry Pi 3B+ and now I've been bitten by = Bob's OOM assassin too... >=20 > % gpart show > =3D> 63 31116225 mmcsd0 MBR (15G) > 63 2016 - free - (1.0M) > 2079 102312 1 fat32lba [active] (50M) > 104391 31008825 2 freebsd (15G) > 31113216 3072 - free - (1.5M) >=20 > =3D> 0 31008825 mmcsd0s2 BSD (15G) > 0 57 - free - (29K) > 57 31008768 1 freebsd-ufs (15G) >=20 > =3D> 40 60567472 da0 GPT (29G) > 40 4194304 1 freebsd-swap (2.0G) > 4194344 56373168 2 freebsd-ufs (27G) >=20 > % cat /etc/fstab > # Custom /etc/fstab for FreeBSD embedded images > /dev/ufs/rootfs / ufs rw,noatime 1 1 > /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 > md1 /tmp mfs rw,noatime,-s100m 0 0 > md2 /var/log mfs rw,noatime,-s15m 0 0 > md3 /var/tmp mfs rw,noatime,-s15m 0 0 > /dev/ufs/swap none swap sw 0 0 > /dev/ufs/usr /usr ufs rw,noatime 2 2 >=20 > da0 is a brand new 32G EMTEC USB2 memory key housing /usr and swap = partitions. >=20 > FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 >=20 > make -j4 buildworld resulted in: >=20 > Jun 21 17:05:12 rpi3 kernel: pid 10326 (c++), uid 0, was killed: out = of swap space > --- CodeGen/AsmPrinter/CodeViewDebug.o --- > c++: error: unable to execute command: Killed > c++: error: clang frontend command failed due to signal (use -v to see = invocation) > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on = LLVM 6.0.0) > Target: aarch64-unknown-freebsd12.0 > Thread model: posix > InstalledDir: /usr/bin > c++: 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. > c++: note: diagnostic msg: >=20 > I happened to have been watching top (5 second interval) at the time = and of the 2G swap, only 45M was shown to be in use. Are you getting errors such as those listed in: https://lists.freebsd.org/pipermail/freebsd-arm/2018-June/018091.html ? If not, your context may be a better test case than Bob P.'s. It looks like the latest from Bob P. is that when his /dev/da0 is not used for swap (and so has far less I/O) his builds finish, apparently without logging errors: = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_1.3gbusbmech= anical_swapinfo/readme where he writes: > This test used the 1 GB SD flash swap partition plus a 1.3 GB = partition=20 > on a USB mechanical disk. The -j4 buildworld ran to completion without > obvious errors, serving mostly to suggest there's nothing wrong with=20= > the read/write behavior of /dev/da0, the USB flash drive holding /usr > and with it /usr/obj. (I do not share his conclusion about /dev/da0 based on the smaller amount of I/O when it was not used for swapping.) As far as I know the swap system is far more dependent on timely I/O than the other I/O involved in a build. Even without errors considered Bob was getting things like the large ms/w figures below: > Mon Jun 18 09:42:05 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 3412 1045164 0% > /dev/mmcsd0s3b 1048576 3508 1045068 0% > Total 2097152 6920 2090232 0% > dT: 10.043s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name > 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 > 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 > 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 > 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a > 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d > Mon Jun 18 09:42:25 PDT 2018 > Device 1K-blocks Used Avail Capacity > /dev/da0b 1048576 3412 1045164 0% > /dev/mmcsd0s3b 1048576 3508 1045068 0% > Total 2097152 6920 2090232 0% Are you getting such during the swapping activity? Overall: the I/O errors (if any) and the large ms/w (or ms/r) figures are things to look for. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Thu Jun 21 14:51:57 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2F640102123D for ; Thu, 21 Jun 2018 14:51:57 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic316-20.consmr.mail.ne1.yahoo.com (sonic316-20.consmr.mail.ne1.yahoo.com [66.163.187.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 B7FE780023 for ; Thu, 21 Jun 2018 14:51:56 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 1PRuHQ0VM1lbQ7R.5tvt6811p0f_AdFH2NKgaDqK35BGztNB05FhNtyT7U9fo9g L0jgnQSS2fxCm4GGgPR2P0sefj_ZIejLeczBr2vH8kcBDM3sw_9kpC3KIEEi10OG.H79SjF2HeLf eY8saHWpL1G0UWM1pPR2RJD9lu6PvpRlYDp0pH4JpLuJ4fx3rkCPlctm1BhxiKC_4RutNqm6THfN L1LUEsNPKbDJNP7nJ3bPsKrF5z2Oc5TxP8pyzEMUUJjV997E.mnGL9OUamR7Iquf5g8eBvpjrjVR HY3brUPH5jJZ3vqLrTmIGRbuESqRABGFw3MJt0wLeP9w_oBrQCeQx3LGaaxYunojzkQQhEGkLYZ3 MxMWlZ2Qgfj54jEU789hOIPFIox7mDd.Zfo0.6GmgEtRboT1iD_Dhwh5QV7jUbKGfzZ9I9OZ.oNB yY7cSBZdvO7PTodCweZBTew6z.BspNrkSWCBhB74rIyu9VQtthKafKEZzcSDMih9oV1x_9Z.oQY3 wzNYe3Wyh7kVEhd5uk68NfD.3i48XCY6ftVJMzPp3Y5hYFGt_RTRqDjrMuIvoFMx2lI7F2cx.VxK Er6ySU0fgcNddUvAkm.m2a0P5LfUMNKQw87xoE50GX00Z4TwkSQJ3BzVOwud.6QVStVuGTACj1Pz 1rScVKrzIsJZLPxc8O3.9HNi9XAQAChVnDjsefRUSr5uGMuZKD4hs62Sx7XB.Gg2ixuigZCGhqUm 5B3Z47Gb17ag_P4zY5HlcI1Iw.VDLeUGdW4HjDL1Wqzq0EiTnfas0Md1xWOMedTfcOQH5GxxtH_o yxS_VlIzUcgxLoBsSzj2Z6WBcA2l6fG99og3RM6jnqYvbHyHC5.HhcQzISQGCbPoKqxZ6D493NN0 YHWeEYxX1TQGO7gIVMUkYL66Yzx4tyCpX.BVapONccG5NBNkgYkVuPthskX5hS0WIa1uSYqDP8cx 3jK1JPXL3uDxC94AAOIONsX312.ImJ2WjIHTFOpL9 Received: from sonic.gate.mail.ne1.yahoo.com by sonic316.consmr.mail.ne1.yahoo.com with HTTP; Thu, 21 Jun 2018 14:51:50 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp417.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 232f9b9aef0456802dee70440538f97f; Thu, 21 Jun 2018 14:51:49 +0000 (UTC) From: Mark Millard Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices Date: Thu, 21 Jun 2018 07:51:48 -0700 References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> To: freebsd-arm , bob prohaska In-Reply-To: <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> Message-Id: <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 21 Jun 2018 14:51:57 -0000 [When I send to Trev, my Email is rejected as spam. This happens even for a direct send without the list address or other addresses involved. I do not see evidence of why in what I get back in the "unable to deliver" notice. The below is just a resend with this note added: no new technical content.] On 2018-Jun-21, at 7:16 AM, Mark Millard wrote: > On 2018-Jun-21, at 12:28 AM, Trev wrote: >=20 >> I gave in and bought an Raspberry Pi 3B+ and now I've been bitten by = Bob's OOM assassin too... >>=20 >> % gpart show >> =3D> 63 31116225 mmcsd0 MBR (15G) >> 63 2016 - free - (1.0M) >> 2079 102312 1 fat32lba [active] (50M) >> 104391 31008825 2 freebsd (15G) >> 31113216 3072 - free - (1.5M) >>=20 >> =3D> 0 31008825 mmcsd0s2 BSD (15G) >> 0 57 - free - (29K) >> 57 31008768 1 freebsd-ufs (15G) >>=20 >> =3D> 40 60567472 da0 GPT (29G) >> 40 4194304 1 freebsd-swap (2.0G) >> 4194344 56373168 2 freebsd-ufs (27G) >>=20 >> % cat /etc/fstab >> # Custom /etc/fstab for FreeBSD embedded images >> /dev/ufs/rootfs / ufs rw,noatime 1 1 >> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >> md1 /tmp mfs rw,noatime,-s100m 0 0 >> md2 /var/log mfs rw,noatime,-s15m 0 0 >> md3 /var/tmp mfs rw,noatime,-s15m 0 0 >> /dev/ufs/swap none swap sw 0 0 >> /dev/ufs/usr /usr ufs rw,noatime 2 2 >>=20 >> da0 is a brand new 32G EMTEC USB2 memory key housing /usr and swap = partitions. >>=20 >> FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 = root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC = arm64 >>=20 >> make -j4 buildworld resulted in: >>=20 >> Jun 21 17:05:12 rpi3 kernel: pid 10326 (c++), uid 0, was killed: out = of swap space >> --- CodeGen/AsmPrinter/CodeViewDebug.o --- >> c++: error: unable to execute command: Killed >> c++: error: clang frontend command failed due to signal (use -v to = see invocation) >> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on = LLVM 6.0.0) >> Target: aarch64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: 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. >> c++: note: diagnostic msg: >>=20 >> I happened to have been watching top (5 second interval) at the time = and of the 2G swap, only 45M was shown to be in use. >=20 > Are you getting errors such as those listed in: >=20 > https://lists.freebsd.org/pipermail/freebsd-arm/2018-June/018091.html >=20 > ? If not, your context may be a better test case than Bob P.'s. >=20 > It looks like the latest from Bob P. is that when his /dev/da0 > is not used for swap (and so has far less I/O) his builds finish, > apparently without logging errors: >=20 > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_1.3gbusbmech= anical_swapinfo/readme >=20 > where he writes: >=20 >> This test used the 1 GB SD flash swap partition plus a 1.3 GB = partition=20 >> on a USB mechanical disk. The -j4 buildworld ran to completion = without >> obvious errors, serving mostly to suggest there's nothing wrong with=20= >> the read/write behavior of /dev/da0, the USB flash drive holding /usr >> and with it /usr/obj. >=20 >=20 > (I do not share his conclusion about /dev/da0 based on the smaller > amount of I/O when it was not used for swapping.) >=20 > As far as I know the swap system is far more dependent on timely > I/O than the other I/O involved in a build. >=20 > Even without errors considered Bob was getting things like the > large ms/w figures below: >=20 >> Mon Jun 18 09:42:05 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >> dT: 10.043s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0 >> 46 0 0 0 0.0 0 16 12355 0 0 = 0.0 85.9 da0 >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 9 10.8 0 0 = 0.0 0.1 mmcsd0s3a >> 33 0 0 0 0.0 0 22 12318 0 0 = 0.0 114.1 da0d >> Mon Jun 18 09:42:25 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >=20 >=20 > Are you getting such during the swapping activity? >=20 > Overall: the I/O errors (if any) and the large ms/w (or ms/r) figures > are things to look for. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jun 22 01:09:04 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 620031007720 for ; Fri, 22 Jun 2018 01:09:04 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CCC2577263 for ; Fri, 22 Jun 2018 01:09:03 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5M19Cws098393 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Thu, 21 Jun 2018 18:09:13 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5M19BST098392; Thu, 21 Jun 2018 18:09:11 -0700 (PDT) (envelope-from fbsd) Date: Thu, 21 Jun 2018 18:09:11 -0700 From: bob prohaska To: Mark Millard Cc: Trev , freebsd-arm , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180622010911.GA98112@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 01:09:04 -0000 On Thu, Jun 21, 2018 at 07:16:19AM -0700, Mark Millard wrote: > > > > It looks like the latest from Bob P. is that when his /dev/da0 > is not used for swap (and so has far less I/O) his builds finish, > apparently without logging errors: > > A little more testing has been completed. With enough swap not on da0 -j4 buildworld finishes. It does not seem to matter what the swap is on: SD flash, USB flash or USB mechanical. With any swap on da0 -j4 buildworld does not finish because of intervention by OOMA (the out of memory assassin). Occasionally, OOMA runs amok, killing processes not obviously consuming lots of memory. With not enough swap not on da0 the result is somewhat surprising. In three trials of using 1 GB of swap on the SD card, the machine reported it was out of swap, the OOM assassin did not come to the rescue and eventually the machine stalled. The log files of gstat and swapinfo data are at http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/1gbsdflash_swapinfo.log http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/newtest/2nd1gbsdflash_swapinfo.log and http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/newtest/3rdtest/3rd1gbsdflash_swapinfo.log Each directory also holds what I could gather from the console and buildworld. The errors on the console seem to suggest a loss of communication with da0. Could something like usbdump be used to shed more light on what's going on? Thanks to all for reading! bob prohaska From owner-freebsd-arm@freebsd.org Fri Jun 22 02:09:02 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 946C9100A6DB for ; Fri, 22 Jun 2018 02:09:02 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id AEF7979874 for ; Fri, 22 Jun 2018 02:09:01 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5M28uFf015372 for ; Fri, 22 Jun 2018 12:08:56 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices To: freebsd-arm References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> From: Trev Message-ID: Date: Fri, 22 Jun 2018 12:08:56 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Fri, 22 Jun 2018 12:08:56 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 02:09:02 -0000 Mark Millard via freebsd-arm wrote on 22/06/2018 00:51: > On 2018-Jun-21, at 12:28 AM, Trev wrote: > >> I gave in and bought an Raspberry Pi 3B+ and now I've been bitten by Bob's OOM assassin too... >> >> % gpart show >> => 63 31116225 mmcsd0 MBR (15G) >> 63 2016 - free - (1.0M) >> 2079 102312 1 fat32lba [active] (50M) >> 104391 31008825 2 freebsd (15G) >> 31113216 3072 - free - (1.5M) >> >> => 0 31008825 mmcsd0s2 BSD (15G) >> 0 57 - free - (29K) >> 57 31008768 1 freebsd-ufs (15G) >> >> => 40 60567472 da0 GPT (29G) >> 40 4194304 1 freebsd-swap (2.0G) >> 4194344 56373168 2 freebsd-ufs (27G) >> >> % cat /etc/fstab >> # Custom /etc/fstab for FreeBSD embedded images >> /dev/ufs/rootfs / ufs rw,noatime 1 1 >> /dev/msdosfs/MSDOSBOOT /boot/msdos msdosfs rw,noatime 0 0 >> md1 /tmp mfs rw,noatime,-s100m 0 0 >> md2 /var/log mfs rw,noatime,-s15m 0 0 >> md3 /var/tmp mfs rw,noatime,-s15m 0 0 >> /dev/ufs/swap none swap sw 0 0 >> /dev/ufs/usr /usr ufs rw,noatime 2 2 >> >> da0 is a brand new 32G EMTEC USB2 memory key housing /usr and swap partitions. >> >> FreeBSD 12.0-CURRENT #0 r335317: Mon Jun 18 17:37:04 UTC 2018 root@releng3.nyi.freebsd.org:/usr/obj/usr/src/arm64.aarch64/sys/GENERIC arm64 >> >> make -j4 buildworld resulted in: >> >> Jun 21 17:05:12 rpi3 kernel: pid 10326 (c++), uid 0, was killed: out of swap space >> --- CodeGen/AsmPrinter/CodeViewDebug.o --- >> c++: error: unable to execute command: Killed >> c++: error: clang frontend command failed due to signal (use -v to see invocation) >> FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0) >> Target: aarch64-unknown-freebsd12.0 >> Thread model: posix >> InstalledDir: /usr/bin >> c++: 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. >> c++: note: diagnostic msg: >> >> I happened to have been watching top (5 second interval) at the time and of the >> 2G swap, only 45M was shown to be in use. > Are you getting errors such as those listed in: > > https://lists.freebsd.org/pipermail/freebsd-arm/2018-June/018091.html No - I have no such errors. > If not, your context may be a better test case than Bob P.'s. > > It looks like the latest from Bob P. is that when his /dev/da0 > is not used for swap (and so has far less I/O) his builds finish, > apparently without logging errors: > > http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_1.3gbusbmechanical_swapinfo/readme > > where he writes: > >> This test used the 1 GB SD flash swap partition plus a 1.3 GB partition >> on a USB mechanical disk. The -j4 buildworld ran to completion without >> obvious errors, serving mostly to suggest there's nothing wrong with >> the read/write behavior of /dev/da0, the USB flash drive holding /usr >> and with it /usr/obj. > > (I do not share his conclusion about /dev/da0 based on the smaller > amount of I/O when it was not used for swapping.) > > As far as I know the swap system is far more dependent on timely > I/O than the other I/O involved in a build. > > Even without errors considered Bob was getting things like the > large ms/w figures below: > >> Mon Jun 18 09:42:05 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% >> dT: 10.043s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0 >> 46 0 0 0 0.0 0 16 12355 0 0 0.0 85.9 da0 >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3 >> 0 0 0 0 0.0 0 9 10.8 0 0 0.0 0.1 mmcsd0s3a >> 33 0 0 0 0.0 0 22 12318 0 0 0.0 114.1 da0d >> Mon Jun 18 09:42:25 PDT 2018 >> Device 1K-blocks Used Avail Capacity >> /dev/da0b 1048576 3412 1045164 0% >> /dev/mmcsd0s3b 1048576 3508 1045068 0% >> Total 2097152 6920 2090232 0% > > Are you getting such during the swapping activity? I have seen similar large mw/w when buildworld is writing to da0, I haven't noticed it when swapping but it's possible. Unfortunately my rpi3B+ is not a direct comparison with the rpi2B because I only had the one USB2 memory device holding /usr, /usr/obj and swap. I'll try moving swap to a dedicated USB2 memory device. From owner-freebsd-arm@freebsd.org Fri Jun 22 02:29:01 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 2265B100AB46 for ; Fri, 22 Jun 2018 02:29:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic303-20.consmr.mail.ne1.yahoo.com (sonic303-20.consmr.mail.ne1.yahoo.com [66.163.188.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 9253B79ED7 for ; Fri, 22 Jun 2018 02:29:00 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: 7sbMD7EVM1mlOL79P13a2P7yqHZtBdLMwbVfDsJMfupgXJSr3VhZdIy1efHqx54 jiNxENmkQEjrh8YhA2pDfix5JyyUysM9aCOcYQyEc2LfKfrlLC6wGb404z_eHRTwCOhN0dPjf72F plZaZAUYacHRE2qKC_aidtVU5WA6ckz4nRbbHd5eGfY0eFTtVfTDluSXoqbWr_tKZBhgGTt9.zW_ haZ9AoVjzEQDDOllG8ugX4XeNHp6W.ySlSD8jmQh9Ny.JAACfqHczvh.dS5Qrf063B941olQy_DW bjzMygsxjfIzmn_nph4oErTdS_3e30cef9oVkzGf1GwxLMfb1cZK96RrZPetsW70vfTE..6YwB4F HE_JJAfHISfO1.XJp5z5vIvMkhVxw7lUBejXXDMp0e.qKg60oXQ6Jj74FSZ6y5Z3AQ9AMO6LYEOm MTuZE8v3oB.k_ql33F9ODpKBanGlNL9dZnhRsfsocpE7RgoJfcO3GqDQJ_PDsoA5XOMHUqpcLHGP oH3i_46aspDNn1on6OeJKFMVm1GMr34dtGfDHB5QE5nYgirll0Tb8WbsdKS0Ha746m4cwbCqa2ax mizEj7qm__yUaRbFnHlAUa_TVeLZ7Va4EZtaHg8D.VvBBteIEup8CN5DGfMphVrWgv4aRTCGQc8n 54AAKgIUCL6ub4T0Ivanere9BGxYGMZW8rJF0rYCR9nPLQypPWJtWiAaea_ca5lAG7ihBe5RK.i4 ALhYIqociOtlSDL0dQLnenS19ezzrGzvrzMJzLWSC4DdGhic_RvreJcOTjpHtWGWPtvgOEGJIGgo NZkEnOTIKqJjhq7VTKk0Q3Yx_cdkBnQHsf_Gm7Kdob0s1_8_pVK0l2gajbeIPfRYX4bKWRUYCZ6d Ewg_fbCYBg6CeQLovPmWbnJ_PhEXP2AWInEPmIu9Rsx9k6HapY8uAwNrqtQcbys60QRKy6.5.6Ly 6Zd3YeHeRbfIB2eaGoVOOPQwzGEmP Received: from sonic.gate.mail.ne1.yahoo.com by sonic303.consmr.mail.ne1.yahoo.com with HTTP; Fri, 22 Jun 2018 02:28:53 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp432.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5e3d057d192a4d935ad9fec89f9404b3; Fri, 22 Jun 2018 02:28:48 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180622010911.GA98112@www.zefox.net> Date: Thu, 21 Jun 2018 19:28:45 -0700 Cc: Trev , freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <73352F3D-75B9-4509-9F96-0B4559375977@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <20180622010911.GA98112@www.zefox.net> To: bob prohaska X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 02:29:01 -0000 On 2018-Jun-21, at 6:09 PM, bob prohaska wrote: > On Thu, Jun 21, 2018 at 07:16:19AM -0700, Mark Millard wrote: >>=20 >>=20 >>=20 >> It looks like the latest from Bob P. is that when his /dev/da0 >> is not used for swap (and so has far less I/O) his builds finish, >> apparently without logging errors: >>=20 >>=20 > A little more testing has been completed.=20 >=20 > With enough swap not on da0 -j4 buildworld finishes. It does not seem = to=20 > matter what the swap is on: SD flash, USB flash or USB mechanical. = With=20 > any swap on da0 -j4 buildworld does not finish because of intervention > by OOMA (the out of memory assassin). Occasionally, OOMA runs amok, > killing processes not obviously consuming lots of memory.=20 >=20 > With not enough swap not on da0 the result is somewhat surprising.=20 >=20 > In three trials of using 1 GB of swap on the SD card, the machine = reported it was out > of swap, the OOM assassin did not come to the rescue and eventually = the machine > stalled. The log files of gstat and swapinfo data are at > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/1gb= sdflash_swapinfo.log > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/new= test/2nd1gbsdflash_swapinfo.log > and > = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/new= test/3rdtest/3rd1gbsdflash_swapinfo.log >=20 > Each directory also holds what I could gather from the console and = buildworld. >=20 > The errors on the console seem to suggest a loss of communication with = da0. Could=20 > something like usbdump be used to shed more light on what's going on?=20= I'm afraid that tracking things down to USB protocol level traces is outside the range I'm familiar with (other than with a logic analyzer with USB support). I'll note that in 2nd1gbsdflash_swapinfo.log I see more examples of large ms/w figures (and ms/r) for /dev/da0 (and some of its partitions). For example: dT: 10.071s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 4 4 61 1.5 0 7 5.8 0 0 = 0.0 0.7 mmcsd0 8 1 0 3 27995 1 20 25706 0 0 = 0.0 275.9 da0 0 0 0 0 0.0 0 7 5.9 0 0 = 0.0 0.1 mmcsd0s2 0 4 4 61 1.5 0 0 0.0 0 0 = 0.0 0.6 mmcsd0s3 0 0 0 0 0.0 0 7 5.9 0 0 = 0.0 0.1 ufs/rootfs 0 4 4 61 1.5 0 0 0.0 0 0 = 0.0 0.6 mmcsd0s3b 4 0 0 0 0.0 0 7 27710 0 0 = 0.0 277.9 da0a 4 1 0 3 27996 1 14 24370 0 0 = 0.0 275.8 da0d The console.log for that run showed: swap_pager_getswapspace(17): failed swap_pager_getswapspace(32): failed swap_pager_getswapspace(24): failed swap_pager_getswapspace(18): failed swap_pager_getswapspace(32): failed swap_pager_getswapspace(24): failed swap_pager_getswapspace(18): failed swap_pager_getswapspace(13): failed (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 18 02 00 00 00 40 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error swap_pager_getswapspace(23): failed (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain swap_pager_getswapspace(12): failed swap_pager_getswapspace(13): failed few minute delay wap_pager_getswapspace(19): failed swap_pager_getswapspace(12): failed swap_pager_getswapspace(9): failed (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 10 01 80 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 2 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 10 01 80 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 1 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 10 01 80 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 10 01 80 00 00 20 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0a[WRITE(offset=3D827523072, length=3D32768)]error =3D 5 g_vfs_done():da0a[WRITE(offset=3D830046208, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51207667712, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51207864320, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51207962624, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51228348416, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51650527232, length=3D32768)]error =3D = 5 g_vfs_done():da0a[WRITE(offset=3D277078016, length=3D4096)]error =3D 5 g_vfs_done():da0a[READ(offset=3D537067520, length=3D16384)]error =3D 5 (da0:umass-sim0:0:0:0): WRITE(10). CDB: 2a 00 00 40 9e 00 00 00 08 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 3 more tries remain (End of "showed".) So it appears that swap activity on /dev/da0 is not required in order to have the problems on /dev/da0 . I suspect that with a drive that does not have the above problems, the OOM process might have handled the out-of-swap without hanging up. (Or at least had a better chance of doing so.) For: = http://www.zefox.net/~fbsd/rpi3/swaptests/newtests/1gbsdflash_swapinfo/new= test/3rdtest/3rd1gbsdflash_swapinfo.log using grep I find some large (>9999) figures for da0 (or its = partitions). (The grep is lucky because large figures in other columns could be matched.) $ grep "[0-9][0-9][0-9][0-9][0-9].*da0" = /Users/markmi/Downloads/3rd1gbsdflash_swapinfo.log.txt | more 45 2 0 0 0.0 2 116 11360 0 0 = 0.0 104.9 da0 40 1 0 0 0.0 1 110 11343 0 0 = 0.0 104.5 da0d 40 3 0 4 15306 2 79 11040 0 0 = 0.0 102.4 da0 35 3 0 4 15306 2 85 10481 0 0 = 0.0 102.9 da0d 0 0 0 0 0.0 0 3 10843 0 0 = 0.0 108.4 da0a for which the first 4 with ms/r or ms/w being large are in: Thu Jun 21 07:42:19 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 0 1048576 0% dT: 10.211s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 7 6.9 0 0 = 0.0 0.1 mmcsd0 45 2 0 0 0.0 2 116 11360 0 0 = 0.0 104.9 da0 40 1 0 0 0.0 1 110 11343 0 0 = 0.0 104.5 da0d Thu Jun 21 07:42:29 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 0 1048576 0% dT: 10.019s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 40 3 0 4 15306 2 79 11040 0 0 = 0.0 102.4 da0 35 3 0 4 15306 2 85 10481 0 0 = 0.0 102.9 da0d Thu Jun 21 07:42:39 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 0 1048576 0% and the last (large ms/w) is in: Thu Jun 21 14:23:04 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 55100 993476 5% dT: 10.003s w: 10.000s L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name 0 0 0 0 0.0 0 15 19.6 0 0 = 0.0 0.5 mmcsd0 23 91 43 1382 46.5 48 3052 601.3 0 0 = 0.0 99.2 da0 0 0 0 0 0.0 0 3 12.5 0 0 = 0.0 0.1 mmcsd0s2 0 0 0 0 0.0 0 12 21.5 0 0 = 0.0 0.3 mmcsd0s3 0 0 0 0 0.0 0 3 12.5 0 0 = 0.0 0.1 ufs/rootfs 0 0 0 0 0.0 0 12 21.5 0 0 = 0.0 0.3 mmcsd0s3a 0 0 0 0 0.0 0 3 10843 0 0 = 0.0 108.4 da0a 12 67 43 1382 46.6 24 3049 656.4 0 0 = 0.0 115.4 da0d Thu Jun 21 14:23:14 PDT 2018 Device 1K-blocks Used Avail Capacity /dev/mmcsd0s3b 1048576 55100 993476 5% I do not find >9999 for mmc*'s for ms/w or ms/r in that file. The console had: swap_pager_getswapspace(14): failed swap_pager_getswapspace(11): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(13): failed swap_pager_getswapspace(10): failed (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 18 bb c0 00 00 40 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Retrying command, 0 more tries remain swap_pager_getswapspace(7): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(7): failed swap_pager_getswapspace(9): failed swap_pager_getswapspace(8): failed swap_pager_getswapspace(8): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(9): failed swap_pager_getswapspace(8): failed swap_pager_getswapspace(24): failed swap_pager_getswapspace(18): failed swap_pager_getswapspace(14): failed swap_pager_getswapspace(11): failed swap_pager_getswapspace(6): failed swap_pager_getswapspace(7): failed swap_pager_getswapspace(10): failed swap_pager_getswapspace(11): failed swap_pager_getswapspace(6): failed (da0:umass-sim0:0:0:0): READ(10). CDB: 28 00 00 18 bb c0 00 00 40 00=20 (da0:umass-sim0:0:0:0): CAM status: CCB request completed with an error (da0:umass-sim0:0:0:0): Error 5, Retries exhausted g_vfs_done():da0d[WRITE(offset=3D65536, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D20709376, length=3D4096)]error =3D 5 g_vfs_done():da0d[READ(offset=3D17288822784, length=3D32768)]error =3D 5 g_vfs_done():vm_fault: pager read error, pid 51522 (c++) da0d[WRITE(offset=3D51207864320, length=3D32768)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51207962624, length=3D32768)]error =3D = 5 g_vfs_done():da0d[WRITE(offset=3D51228348416, length=3D4096)]error =3D 5 g_vfs_done():da0d[WRITE(offset=3D51655704576, length=3D32768)]error =3D = 5 g_vfs_done():da0a[READ(offset=3D829915136, length=3D32768)]error =3D 5 Fatal data abort: . . . (omitted register dump) . . . [ thread pid 496 tid 100100 ] Stopped at cluster_write+0x228: ldr x9, [x8, #80]! db>=20 =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Fri Jun 22 04:27:59 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 4C7D2100D44A for ; Fri, 22 Jun 2018 04:27:59 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (shadow.sentry.org [210.8.237.106]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "shadow.sentry.org", Issuer "COMODO RSA Domain Validation Secure Server CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 6CD4E7D3F8 for ; Fri, 22 Jun 2018 04:27:58 +0000 (UTC) (envelope-from freebsd-arm@sentry.org) Received: from shadow.sentry.org (localhost [127.0.0.1]) by shadow.sentry.org (8.15.2/8.15.2) with ESMTP id w5M4RsY1053864 for ; Fri, 22 Jun 2018 14:27:54 +1000 (AEST) (envelope-from freebsd-arm@sentry.org) Subject: Re: GPT vs MBR for swap devices References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <20180622010911.GA98112@www.zefox.net> <73352F3D-75B9-4509-9F96-0B4559375977@yahoo.com> From: Trev To: freebsd-arm Message-ID: <4f68fe89-47bd-1efc-0447-7deb6f07a3be@sentry.org> Date: Fri, 22 Jun 2018 14:27:54 +1000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.3 MIME-Version: 1.0 In-Reply-To: <73352F3D-75B9-4509-9F96-0B4559375977@yahoo.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.2 (shadow.sentry.org [0.0.0.0]); Fri, 22 Jun 2018 14:27:54 +1000 (AEST) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 04:27:59 -0000 Mark Millard wrote on 22/06/2018 12:28: > I'll note that in 2nd1gbsdflash_swapinfo.log I see more examples of > large ms/w figures (and ms/r) for /dev/da0 (and some of its > partitions). For example: > > dT: 10.071s w: 10.000s > L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps ms/d %busy Name > 0 4 4 61 1.5 0 7 5.8 0 0 0.0 0.7 mmcsd0 > 8 1 0 3 27995 1 20 25706 0 0 0.0 275.9 da0 > 0 0 0 0 0.0 0 7 5.9 0 0 0.0 0.1 mmcsd0s2 > 0 4 4 61 1.5 0 0 0.0 0 0 0.0 0.6 mmcsd0s3 > 0 0 0 0 0.0 0 7 5.9 0 0 0.0 0.1 ufs/rootfs > 0 4 4 61 1.5 0 0 0.0 0 0 0.0 0.6 mmcsd0s3b > 4 0 0 0 0.0 0 7 27710 0 0 0.0 277.9 da0a > 4 1 0 3 27996 1 14 24370 0 0 0.0 275.8 da0d For writes, I've seen ms/w that high or indeed higher on my rpi2B but the make -j4 buildworld still completes without error (running FreeBSD 11-STABLE). From owner-freebsd-arm@freebsd.org Fri Jun 22 05:05:18 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C3B2C100E5D2 for ; Fri, 22 Jun 2018 05:05:17 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) Received: from sonic305-20.consmr.mail.ne1.yahoo.com (sonic305-20.consmr.mail.ne1.yahoo.com [66.163.185.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 389377E4C6 for ; Fri, 22 Jun 2018 05:05:17 +0000 (UTC) (envelope-from marklmi26-fbsd@yahoo.com) X-YMail-OSG: .dLEuXwVM1lHSq8QxRlyVl0ovvJJ4sLZ.6bKNi9HzQXw.oJi94A0tNhCQdSPX4w RAaxqsHFUEr6H0wi.21XuWIyaEQw9KQCtKtsUfuFOyej.tRuZgyEZmDbqzFWDV3rG8KWTCJWbKCA 7JEyoVab7LRhefY.k7y.PxDY3_R1iSgQTx9ztc2lTx_lBKfL8JkBqwowsRoXxe4smXVp3WCfiEMv vJQLlviEU2gJ3vT2mfj2MqwnUHqBUgVsZfYrCoBhBwSNJAJdnHtEK.m0.bPlhnX8bB8WuX_zDbE2 FJ364IBn_vJaxDYm5w_P2BNVZ28F4iekOjLtnKdpGMhyJpnlgjIurPhQ0B9QFVmTqk.G7U3zFPxV ybVdDUMNP4VwtMRCUZKiOlKrKqSfdhg0S4lK6KnJEO0_2mGSHIj2qzq5CSz_8peH23FsFjHSEQ.Q 7uRBxmruhE0LDArp9ZrHSt0iLClwSrsQ8zRNHITBZkeDEB0KzoMyFUMQBEVbN3s0p4xmM_j.DPAS ZNtgo6bYLhOUXchr56cZ3UOiLqKObOoYegm682RtH40b.Rj60Al.IOul8lmIReJHAcUMrRd5aMGw rz.YWFh4BJhqnXvrKD97SO0YC46JrTkXYk_5zZBMq4LDFWbJNAwvY2VpzOFwHdn_0L.JoZF_YC1j WeYPIUA9ZnN_UtNdZT5pKq1_wlDBQcK7XqJ91fFPCO4Ty4JWxgftkHW4GLL8rbjoe.aV4XtjoRK8 nmhpx.q.N3oSNKSm4hHr5uAAXmZL5l26M8MMFQkMHS7bIBBbmmm591YlvCKB6M4CBLjpsgWt2GLG .TzfXd6_VWkvZy9c8vulqwPyxzS563ypqDJrRt_uWPRcKimslknqgHGu3Rq_JsqEo_SikhI.Mpyk UX3obvDELgMMrWx9kgwo2DDEWJRuUx8O_21ydY.F3XWhQsFqgV4cDGSLgR.djlKNXJ_3AjWCyVwI rNC_esArPwa_nqjkmsgeITqYxaTEBv8Ie Received: from sonic.gate.mail.ne1.yahoo.com by sonic305.consmr.mail.ne1.yahoo.com with HTTP; Fri, 22 Jun 2018 05:05:16 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp412.mail.ne1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8e2842d41c01540ab53a8545ac6bd1be; Fri, 22 Jun 2018 05:05:14 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <4f68fe89-47bd-1efc-0447-7deb6f07a3be@sentry.org> Date: Thu, 21 Jun 2018 22:05:13 -0700 Cc: freebsd-arm Content-Transfer-Encoding: quoted-printable Message-Id: <18ECD5F3-880C-42FD-A767-8019F94D18C0@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <20180622010911.GA98112@www.zefox.net> <73352F3D-75B9-4509-9F96-0B4559375977@yahoo.com> <4f68fe89-47bd-1efc-0447-7deb6f07a3be@sentry.org> To: Trev X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 22 Jun 2018 05:05:18 -0000 On 2018-Jun-21, at 9:27 PM, Trev wrote: > Mark Millard wrote on 22/06/2018 12:28: >> I'll note that in 2nd1gbsdflash_swapinfo.log I see more examples of >> large ms/w figures (and ms/r) for /dev/da0 (and some of its >> partitions). For example: >> dT: 10.071s w: 10.000s >> L(q) ops/s r/s kBps ms/r w/s kBps ms/w d/s kBps = ms/d %busy Name >> 0 4 4 61 1.5 0 7 5.8 0 0 = 0.0 0.7 mmcsd0 >> 8 1 0 3 27995 1 20 25706 0 0 = 0.0 275.9 da0 >> 0 0 0 0 0.0 0 7 5.9 0 0 = 0.0 0.1 mmcsd0s2 >> 0 4 4 61 1.5 0 0 0.0 0 0 = 0.0 0.6 mmcsd0s3 >> 0 0 0 0 0.0 0 7 5.9 0 0 = 0.0 0.1 ufs/rootfs >> 0 4 4 61 1.5 0 0 0.0 0 0 = 0.0 0.6 mmcsd0s3b >> 4 0 0 0 0.0 0 7 27710 0 0 = 0.0 277.9 da0a >> 4 1 0 3 27996 1 14 24370 0 0 = 0.0 275.8 da0d >=20 > For writes, I've seen ms/w that high or indeed higher on my rpi2B but = the make -j4 buildworld still completes without error (running FreeBSD = 11-STABLE). >=20 Just to be sure: The large ms/w figures where on a drive with the/an in-use swap partition? What -r?????? version(s) of base/stable/11/ ? =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jun 23 14:32:11 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 5D5401022DE8 for ; Sat, 23 Jun 2018 14:32:11 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (www.zefox.net [50.1.20.27]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "www.zefox.org", Issuer "www.zefox.org" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id CA6AE8417E for ; Sat, 23 Jun 2018 14:32:10 +0000 (UTC) (envelope-from fbsd@www.zefox.net) Received: from www.zefox.net (localhost [127.0.0.1]) by www.zefox.net (8.15.2/8.15.2) with ESMTPS id w5NEWJgS006947 (version=TLSv1.2 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Sat, 23 Jun 2018 07:32:20 -0700 (PDT) (envelope-from fbsd@www.zefox.net) Received: (from fbsd@localhost) by www.zefox.net (8.15.2/8.15.2/Submit) id w5NEWI9A006946; Sat, 23 Jun 2018 07:32:18 -0700 (PDT) (envelope-from fbsd) Date: Sat, 23 Jun 2018 07:32:18 -0700 From: bob prohaska To: Trev Cc: freebsd-arm , bob prohaska Subject: Re: GPT vs MBR for swap devices Message-ID: <20180623143218.GA6905@www.zefox.net> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.24 (2015-08-30) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 14:32:11 -0000 On Fri, Jun 22, 2018 at 12:08:56PM +1000, Trev wrote: > > > Unfortunately my rpi3B+ is not a direct comparison with the rpi2B > because I only had the one USB2 memory device holding /usr, /usr/obj and > swap. I'll try moving swap to a dedicated USB2 memory device. Have you considered putting a swapfile on the microSD card? That's one of the things I have not tried. A swap partition on SD seems to work. A swapfile is easier to try and may work. hth, bob prohaska From owner-freebsd-arm@freebsd.org Sat Jun 23 14:50:06 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id A791C10239EA for ; Sat, 23 Jun 2018 14:50:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic307-9.consmr.mail.gq1.yahoo.com (sonic307-9.consmr.mail.gq1.yahoo.com [98.137.64.33]) (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 2C5D884D76 for ; Sat, 23 Jun 2018 14:50:06 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: OB7mX5QVM1mDViKZXwZs7eFxxajlt9y0zJP9n7Jrhd52rMj_rebGNc6CVXwDhEh ROXj_SeO6pP8TUrM.owjmCw7LG3qSY_P9UV1i0HOzSJbB1rB3bHPsu0joUFnVhJb2K7shwRGA2bc 0_RGdQGuVh0sjjzbwvkaIAQkcnMfqG06Jjl.vatP8rgCIGUAyB7vn6nF8eSdk3QpXPeLGD56yytw IRPNQYOZIz8l5MPMReVZT7wwvuTFAg9IEkZZ4BUSAp65kYIoG2QlHHbP0Y_ufOEPIAFd.FfHRzUz zSmhJD_J.gepv8l0pSpcRv6HXeouRn6oMfdYX4myIcMNAU.eakU0RG9NOAN1EVrRAreTMktL1vmC lcbGAObmp3XgyaZABbKNKcsQz6kPH3aDc227ePHOXW6ioA9ZgOI.MAqWLO36GccuTHo20cYn4Yjv 8be.RKAe3ek8SlxewRd7B0ew5E8yiiqKHuet1A3YbkFOTNSl4STbzzNsWJGrkKh9aDreXl4LdWgs m0MP4gHP_Eg1Y5GB_BSNWkXE9wL96kQ2vR64PAjmLLn8CV371O6VxJFsDIpM32ZLPHxwKDusYx1A YUfvAn6dIn9KlzVU3F0r1mncMJmnGA1Gtnhi.JmIWqkgEDtciSLqKpo3toUHMY4AUsjr175NbULp oo7ls21l.rA5mK9.W2Yc1OxsL.cLgD1gK6PvpIe6nyuKW0G4fgakLmvMjXfcsluACsVoEm8uVW_8 OavBaygKQUpJrBwIpzlhIQ3GT4ezzIUyO8O8oHgstClCGMIGc75u8ses2XRYhxyqhwZylHfUST6f x2qq4EDTlkJThM7PPcmzV9KAddALprV6wAjGWYKMFRQmZCUWeIKavBrciq1vcvXc0kStNl8iGgLC v49J8POZegWJhaOskG8oZjOTApb9aXixmFz6XJQMn6sc_Gmdwt8uHzbutfKohWtebD1rkq89u21L w4gpVCHLtypjfbVb1VsuNcQ7b5717_gGy0Owztj_.h2.llXNlObJVZGg- Received: from sonic.gate.mail.ne1.yahoo.com by sonic307.consmr.mail.gq1.yahoo.com with HTTP; Sat, 23 Jun 2018 14:49:59 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp402.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 8e5f773237357dafdac6adc6524ae7e3; Sat, 23 Jun 2018 14:49:54 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: GPT vs MBR for swap devices From: Mark Millard In-Reply-To: <20180623143218.GA6905@www.zefox.net> Date: Sat, 23 Jun 2018 07:49:53 -0700 Cc: freebsd-arm , bob prohaska Content-Transfer-Encoding: quoted-printable Message-Id: <03C2D3C4-6E90-4054-AF79-BD7FE2B7958D@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> <20180620023253.GA89924@www.zefox.net> <1D86911D-20D1-494A-822B-1C07C5598CB1@yahoo.com> <10CAC122-399D-459E-9153-ABD7E753777E@yahoo.com> <20180623143218.GA6905@www.zefox.net> To: Trev X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 14:50:07 -0000 On 2018-Jun-23, at 7:32 AM, bob prohaska wrote: > On Fri, Jun 22, 2018 at 12:08:56PM +1000, Trev wrote: >>=20 >>=20 >> Unfortunately my rpi3B+ is not a direct comparison with the rpi2B=20 >> because I only had the one USB2 memory device holding /usr, /usr/obj = and=20 >> swap. I'll try moving swap to a dedicated USB2 memory device. >=20 > Have you considered putting a swapfile on the microSD card? That's one > of the things I have not tried. A swap partition on SD seems to work.=20= > A swapfile is easier to try and may work.=20 See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D206048 for why I would not recommend using a swap file. In particular comment 7 is a quote: > On 2017-Feb-13, at 7:20 PM, Konstantin Belousov wrote > on the freebsd-arm list: >=20 > . . . >=20 > swapfile write requires the write request to come through the = filesystem > write path, which might require the filesystem to allocate more memory > and read some data. E.g. it is known that any ZFS write request > allocates memory, and that write request on large UFS file might = require > allocating and reading an indirect block buffer to find the block = number > of the written block, if the indirect block was not yet read. >=20 > As result, swapfile swapping is more prone to the trivial and = unavoidable > deadlocks where the pagedaemon thread, which produces free memory, = needs > more free memory to make a progress. Swap write on the raw partition = over > simple partitioning scheme directly over HBA are usually safe, while = e.g. > zfs over geli over umass is the worst construction. Comment 3 from Tom Vijlbrief even reports a way to reproduce such a problem with swap files: > This is not related to ARM or USB, I can reproduce it in a VirtualBox = amd64 client with the standard emulated hard disk. >=20 > . . . >=20 > stress -d 2 -m 3 --vm-keep >=20 > will hang the system as well. (This was on 2016-Jan-22.) Another reproduction report is Comment 5 from Sevan Janiyan: > In my case, to reproduce the behaviour, boot PI, add swap file as per = handbook instructions[1], run cat /somefile > /someotherfile >=20 > In this case /somefile is a 4GB file containing garbage from = /dev/urandom =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) From owner-freebsd-arm@freebsd.org Sat Jun 23 15:53:25 2018 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 6B8711025F9A for ; Sat, 23 Jun 2018 15:53:25 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from mxrelay.ysv.freebsd.org (mxrelay.ysv.freebsd.org [IPv6:2001:1900:2254:206a::19:3]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mxrelay.ysv.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id D0134888C6 for ; Sat, 23 Jun 2018 15:53:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mxrelay.ysv.freebsd.org (Postfix) with ESMTPS id 373201A580 for ; Sat, 23 Jun 2018 15:53:24 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id w5NFrOqP069249 for ; Sat, 23 Jun 2018 15:53:24 GMT (envelope-from bugzilla-noreply@freebsd.org) Received: (from www@localhost) by kenobi.freebsd.org (8.15.2/8.15.2/Submit) id w5NFrOQO069248 for freebsd-arm@FreeBSD.org; Sat, 23 Jun 2018 15:53:24 GMT (envelope-from bugzilla-noreply@freebsd.org) X-Authentication-Warning: kenobi.freebsd.org: www set sender to bugzilla-noreply@freebsd.org using -f From: bugzilla-noreply@freebsd.org To: freebsd-arm@FreeBSD.org Subject: [Bug 227648] kernel panic when compiling FreeBSD-CURRENT for BBB with MMCCAM kernconf file Date: Sat, 23 Jun 2018 15:53:24 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: arm X-Bugzilla-Version: CURRENT X-Bugzilla-Keywords: crash X-Bugzilla-Severity: Affects Only Me X-Bugzilla-Who: dev.madaari@gmail.com X-Bugzilla-Status: Closed X-Bugzilla-Resolution: FIXED X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-arm@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_status resolution Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.26 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 23 Jun 2018 15:53:25 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D227648 udit agarwal changed: What |Removed |Added ---------------------------------------------------------------------------- Status|New |Closed Resolution|--- |FIXED --=20 You are receiving this mail because: You are the assignee for the bug.=