Re: Filesystem errors on armv7 -current

On 10/19/26 10:18, bob prohaska 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. 
> 
> 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.

What about any newer security Email reports? Are they still showing find
reporting the various "Input/output error" messages? In the published
file they repeated for 2 distinct find commands.

(There was also some "Invalid argument" ones in the file you had uploaded.)

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


-- 
===
Mark Millard
marklmi at yahoo.com