Re: Filesystem errors on armv7 -current

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. 

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:
....
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