GPT vs MBR for swap devices

bob prohaska fbsd at www.zefox.net
Wed Jun 20 02:32:41 UTC 2018


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


More information about the freebsd-arm mailing list