GPT vs MBR for swap devices

Mark Millard marklmi26-fbsd at yahoo.com
Wed Jun 20 01:44:04 UTC 2018


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].)

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.


===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)



More information about the freebsd-arm mailing list