Re: Filesystem errors on armv7 -current

On Mon, Oct 19, 2026 at 11:16 AM bob prohaska <fbsd@www.zefox.net> wrote:

> On Mon, Oct 19, 2026 at 09:57:34AM -0600, Warner Losh wrote:
> > On Mon, Oct 19, 2026 at 9:40 AM bob prohaska <fbsd@www.zefox.net> wrote:
> >
> > > A Pi2B running
> > > FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #76
> > > main-n289925-6c305c3c3129: Sun Oct 11 15:20:02 PDT 2026
> > >  bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC arm
> armv7
> > > 1600027 1600028
> > >
> > > is reporting errors during installworld of the form
> > >
> > > /usr: inode 67896768: check-hash failed
> > >
> > > and
> > >
> > > UFS /dev/da0s2d (/usr) cylinder checkhash failed: cg 846, cgp:
> 0xce917fd
> > > != bp: 0x4e2a15c5
> > >
> >
> > So this is a data corruption bug. Almost certainly. It may be related to
> > caching (or memory observability), or it may be something else. If the
> > errors are on boot, then something is writing it before the system went
> > down. If this occurs at runtime, it is likely a transfer error.
> >
> >
> > > There's an old bug report,
> > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=267654
> > >
> > > which looks somewhat similar but is marked "Closed FIXED".
> > >
> >
> > So symptoms may be the same, but the root cause is likely different.
> >
> >
> > > So far, the errors have not resulted in any build or install stoppages,
> > > but the install and reboot haven't completed yet.
> > >
> > > Is it worth reporting this behavior as a new bug? Old bug? Other? Not?
> > >
> >
> > New bug. For the love of all that's holy, do not reopen the old bug.
> >
> 8-)
>
> >
> > > It's true that the kernel lags world by one index digit. Not sure how
> > > that happened.
> > >
> > > I can post console output, but it's mostly repetitive, as if the
> > > errors correct eventually or are ignored.
> > >
> > > /etc/fstab contains
> > >
> > > # more /etc/fstab
> > > # Custom /etc/fstab for FreeBSD embedded images
> > > #/dev/ufs/rootfs                /               ufs     rw
>   1
> > >             1
> > > #/dev/msdosfs/EFI               /boot/efi       msdosfs rw,noatime
>   0
> > >             0
> > > #tmpfs                  /tmp            tmpfs   rw,mode=1777    0
>  0
> > >
> > > /dev/da0s2a     /       ufs     rw      1       1
> > > /dev/da0s2d    /usr    ufs     rw      1       1
> > > /dev/da0s1      /boot/msdos msdosfs rw,noatime 0 0
> > > /dev/da0s2b     none    swap    sw
> > >
> > > Swap is
> > >
> > > # swapinfo
> > > Device          1K-blocks     Used    Avail Capacity
> > > /dev/da0s2b       1843200    15644  1827556     1%
> > > so below the warning limit
> > >
> > > The storage device is SATA spinning rust on
> > > ugen0.6: <JMS578 SATA 6Gb/s JMicron Technology Corp. / JMicron USA
> > > Technology Corp.> at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON
> (500mA)
> > >
> >
> > So  what's the actual disk? It could be that the disk is going bad too.
> If I'm not mistaken, it's a Seagate, 1TB, bought from Amazon.
>
> > Though JMicron has a history of dodgy adapters (though that history
> > pre-dates this one, I think).
> >
> > tl;dr: This is rare data corruption, but any is bad. So far, though,
> there
> > doesn't seem to be enough to trace the problem.  I suggest A/B tests if
> you
> > can, starting with a different non-JMicron-based USB adapter.
>
> I do have a StarTech usb2-only usb-sata adapter which can be tried.
>
> Oddly enough, in the last few reboots the most common problem, disk
> detection failure in uboot, has been absent.
>

OK, Change in behavior also suggests a wider array of things to look at...


> Installworld completed successfully, no reported errors.
>
> The first reboot to multi-user ended in a panic during shutdown, an
> old problem. It started with
> ...
> smscphy0: detached
> smsc0: warning: MII is busy
> Kernel page faultmiibus0: detached
>  with the following non-sleepable locks held:
> exclusive sleep mutex smsc0 (smsc0) r = 0 (0xd739ff70) locked @
> /usr/src/sys/dev/usb/net/if_smsc.c:665
> stack backtrace:
>

So we're panicking elsewhere. This suggests maybe it's not a storage
problem, or a dma/cache problem at all. It suggests maybe a power issue and
power drops just enough to cause data corruption. Perhaps you can find a
more powerful power supply to test this theory?

Warner


> ....
> and went downhill from there 8-)
>
> Rebooting from the debugger to single user and starting fsck -fy
> stimulated a string of errors and corrections, a re-run came up clean.
> However, /usr/lost+found is now populated with about 50 files.
>
> The system now reports
> # uname -apKU
> FreeBSD pelorus.zefox.org 16.0-CURRENT FreeBSD 16.0-CURRENT #1
> main-5bf3e2a14111: Mon Oct 19 00:03:30 PDT 2026     bob@pelorus.zefox.org:/usr/obj/usr/src/arm.armv7/sys/GENERIC
> arm armv7 1600028 1600028
>
> As a sanity check I'm re-running buildworld, just to see if it
> completes. I'll try the Startech usb-sata adapter if trouble persists.
>
> Thanks for writing!
>
> bob prohaska
>
>