*ĝata Set Management TRIM supported (limit 8 blocks)Ģmin for SECURITY ERASE UNIT. * SMART Command Transport (SCT) feature set * READ_LOG_DMA_EXT equivalent to READ_LOG_EXTĭevice-initiated interface power management R/W multiple sector transfer: Max = 1Ĝurrent = 1ĭMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6Ĭycle time: no flow control=120ns IORDY flow control=120ns Standby timer values: spec'd by Standard, with device specific minimum Nominal Media Rotation Rate: Solid State Device
GENTOO CHECK SSD HEALTH CODE
Used: unknown (minor revision code 0x006d) Transport: Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6, SATA Rev 3.0 Here's some info I grabbed at various points.Ĭode: Select all $ sudo hdparm -I /dev/sda I've now confirmed both the adapter and the SSD work on my linux box. As the day wore on that simple /dev/sda1 partition mutated in an attempt to trap the issue, especially as it first looked like an ext4 bug. In the morning the filesystem was readonly.Įverything is new so obviously the problem could be anywhere.
GENTOO CHECK SSD HEALTH FULL
Happy that it was coming in at <50 degrees I set it off on a full build of gcc 7.4.0 (all stages + tests) overnight. It's got a pimoroni fan shim so to test it I performed a quick build of gcc 8.3.0 whilst watching the temperature. The next operation was simply to format the SSD (gpt,64G, ext4) then rsync /dev/mmcblk0p2 onto /dev/sda1 (the SSD), mounted as /mnt/tmp/ then adjust /boot/cmdline.txt and /mnt/tmp/etc/fstab to use the 'blkid' to place the UUID in both. Originally, it was a standard configuration. No difference.Īh, looks like I was a bit unclear. Oh, also tried the SSD on the Pi 4 usb2 port as well as the usb3. Would this bug be manifesting itself at a lower level than the filesystem? Put the "vl805_fw_013701.bin" image back.īegs the question: when the Pi 4 was using an LVM2 "gcc" folder for its sources, ditto for /tmp, why when it crapped out, did rootfs go readonly? Tried the '"vl805_fw_0137a8.bin" firmware but that just made things very slow and rather than the above errors there was a lengthy kernel panic. It won't get more than a couple of gig into /dev/mmcblk0p2 before rootfs goes readonly. Repeat but while it's doing that have it 'dd' the two sdcard partitions onto the SSD. I'm able to get the Pi 4 to render rootfs readonly pretty quickly: It first did it while building gcc 7.4.0 but it takes a while. Repeat with the usb->sata adapter used on the Pi 4.
Mounted the same LVM2 volumes and built gcc (esata caddy). I've just tested the SSD on my linux box.
I even replaced the ext4 rootfs later with an ext3 one on the offchance it was an ext4 bug. Gave up on that after a while, went retro and prepped the SSD on my linux box. Initially my linux box could not fix the journal error so I downloaded and built e2fsprogs-1.45.3.tar.xz for it. Initially I had the SSD mounted with "discard" option as it supports trim but took that out very early in the debug process (reinstalled OS from scratch). I created LVM2 for /var,/tmp and gcc build directory, the idea obviously being able to get at /var/log/ on my linux box but I guess systemd had gone awol. "ext4_find_entry:1442: inode N" (various values for N) which I think were preceded by "ext4_journal_check_start:61 Detected aborted journal" and am unsure if this was the first error onto the console in any case. My phone is a pig for not focusing on displays. Only errors to be had are on the console. I've spent the day doing all manner of tests for little result. Just wanted to reach out to see if anyone else if having this issue.
0 kommentar(er)
