Re: armv7 kernel panic on swap exhaustion

> On Mar 2, 2026, at 09:28, bob prohaska <[email protected]> wrote:
> 
> On Sun, Mar 01, 2026 at 08:13:24PM -0800, Mark Millard wrote:
>> On 3/1/26 18:15, bob prohaska wrote:
>>> 
>>> A Pi2B v1.1 (armv7) has paniced while running a -j3 buildworld.
>>> 
>>> I've put details at
>>> http://www.zefox.net/~fbsd/rpi2/panic_on_swap_exhaustion/
>>> 
>>> This particular machine has been patched for the 
>>> "panic on shutdown" problem, and that patch seemed
>>> to work: shutdown panics were reproducible and the
>>> patch made them go away completely. 
>>> 
>>> The panic reported in this message has never been 
>>> seen before; whether it touches on the same issue
>>> or is completely unrelated I've no idea. There are
>>> no behaviors suggesting a faulty hard disk but some
>>> of the console messages  might suggest otherwise.
>> 
>> For:
>> 
>> . . .
>> (da0:umass-sim0:0:0:0): SCSI sense: MEDIUM ERROR asc:10,0 (ID CRC or ECC
>> error)
>> . . .
>> (da0:umass-sim0:0:0:0): Error 5, Retries exhausted=32768)]error = 5
>> . . .
>> 
>> my understanding is:
>> 
>> ) "SCSI sense: MEDIUM ERROR asc:10,0 (ID CRC or ECC error)" indicates
>> that the data fails the CRC/ECC data check where it was trying to read:
>> Bad data.
>> 
>> ) "Error 5, Retries exhausted" indicates repeated attempts were made and
>> they all failed for the location in question.
>> 
>>> The disk is far from new and has been well-used.
>> 
>> My guess is that it is time to replace it.
> 
> I certainly don't disagree 8-)
> 
> But shouldn't the disk error preceed the indefinite wait
> if the disk error triggered the panic? 
> 
> As an aside, is there a disk testing program somewhere in
> the base system? There isn't room on the existing disk to 
> compile ports. 
> 
> Thanks for writing!
> 
> bob prohaska


Devices that are broken but don't admit it are a source of misbehavior.

In the case of a hard drive, a failing disk often spends a long time retrying every I/O request before giving up.  One of my earliest experiences with computers was recognizing the grinding sound a floppy drive made as it retried over and over.  From the first grind I knew I would get the mysterious message "CRC error" but I had to wait a while for it.

ZFS can't handle a drive that takes seconds retrying every I/O request.  Maybe the pager can't either.

I see the message "suppressing further ENXIO" in the console log.  If a later failure was for something essential that could cause the panic.  I don't recall if a failed pageout is fatal.

John Carr