Re: armv7 kernel panic on swap exhaustion

On 3/2/26 06:28, bob prohaska 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? 

Messages like:

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 287, size: 16384

are not error messages or failure reports of themselves but could, in
this case, just in part be about the time taken in the retries somewhat
before the reties stop. Note:

swap_pager: indefinite wait buffer: bufobj: 0, blkno: 330456, size: 24576

matches the later:

swap_pager: I/O error - pagein failed; blkno 330456,size 24576, error 5

That last was the first error reported by the swap_pager --and is just
after the SCSI sense: MEDIUM ERROR related sequence of messages, so just
after the retries stop.

So far as I know, FreeBSD avoids attempting recovery from swap_pager I/O
errors.

The sequencing looks reasonably as-expected to me.

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

Plug the disk into a different RPi* as a data disk and run the tools
from there, looking at the problematical disk? The RPi* would not need
to be a RPi2B v1.1 --or even an RPi* at all.

smartmontools is a port-package from the port sysutils/smartmontools ,
for example.

On an aarch64 system, smartmontools should be available from upstream or
could be built on the system the failing media would be tested on.

> 
> Thanks for writing!
> 
> bob prohaska
> 
> 
> 


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