Date: Tue, 19 Jun 2018 19:32:53 -0700 From: bob prohaska <fbsd@www.zefox.net> To: Mark Millard <marklmi26-fbsd@yahoo.com> Cc: freebsd-arm <freebsd-arm@freebsd.org>, bob prohaska <fbsd@www.zefox.net> Subject: Re: GPT vs MBR for swap devices Message-ID: <20180620023253.GA89924@www.zefox.net> In-Reply-To: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com> References: <25F1A4BA-FBFC-4C32-85DD-5F5BA71A2B1A@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20180620023253.GA89924>