On Fri, 2019-10-11 at 10:21 +1000, Jonathan Matthew wrote: > On Mon, Oct 07, 2019 at 01:30:52PM -0400, Kurt Miller wrote: > > > > > > > > I hit the issue again using the latest snapshot which > > > includes the work-around. > > > > > > ahci0: log page read failed, slot 31 was still active. > > > ahci0: stopping the port, softreset slot 31 was still active. > > > ahci0: failed to reset port during timeout handling, disabling it > > > > > > No panic this time. > > > > > > The work-around helped with stability in the RAMDISK env where > > > it was very unstable. Perhaps it is still a good idea. > > > > > This time I got a panic so perhaps there's something helpful > > in the info below. I had 2x rm -rf on some larger directories > > going at the time of this panic: > I've been running a similar load on a desktop pc (amd64), copying and deleting > ports trees, 4 in parallel, ~4k iops on average, on a SATA SSD through an > ASM1061 card (looks exactly the same as the one in the pine64 store) for > around a day with no problems at all. Is it possible this is actually a > power problem? How are you powering the board and the SSD? >
It is possible power is related. I did add a USB fan on to the load of the RockPro64. My setup is RockPro64 with their PCIe SATA controller and the SSD. Power supply is 5A per their recommendation for this setup. The SSD is powered off the DC out for SATA on the board #23 in board layout. However, the USB fan is something I needed to do since the fan that goes with the NAS case gets its power from PWM controlled fan header (#4) that we don't have a driver for and provides no power without a driver. https://wiki.pine64.org/index.php/ROCKPro64_Main_Page#Board_layout I have moved the power for the fan off of the RockPro64 USB port. I will do some testing of an older snapshot without the diff with sysupgrade where it reproduces easier and let you know the outcome. Thanks, -Kurt
