Re: kern/57694 (rge(4) hang)

["Michael van Elst via gnats" <gnats-admin%NetBSD.org@localhost>]

The following reply was made to PR kern/57694; it has been noted by GNATS.

From: mlelstv%serpens.de@localhost (Michael van Elst)
To: gnats-bugs%netbsd.org@localhost
Cc: 
Subject: Re: kern/57694 (rge(4) hang)
Date: Sat, 9 Nov 2024 22:14:28 -0000 (UTC)

 gnats-admin%NetBSD.org@localhost ("matthew green via gnats") writes:
 
 >    1249         for (i =3D sc->rge_ldata.rge_rxq_considx; ; i =3D RGE_NEXT=
 > _RX_DESC(i)) {
 > ...
 >    1255                 cur_rx =3D &sc->rge_ldata.rge_rx_list[i];
 >    1256
 >    1257                 if (RGE_OWN(cur_rx))
 >    1258                         break;
 > ...
 >    1361         }
 >    1362
 >    1363         sc->rge_ldata.rge_rxq_considx =3D i;
 > 
 > if for some reason rge_rxq_considx ends up pointing to a desc
 > that is owned, then i is never changed from rge_rxq_considx and
 > the assignment on L1363 is a no-op.
 
 This is a ring buffer and all descriptors are processed until
 the loop hits a descriptor that is still 'owned' by the device,
 because no data had been received.
 rge_rxq_considx is updated correctly to the descriptor that
 needs to be checked when the next interrupt arrives.
 
 Maybe an interrupt is dropped and when you don't fetch
 all data, there might be a condition that no further
 interrupt is raised.
 
 Or maybe the chip firmware 'forgets' to clear the OWN bit
 under rare conditions. I've seen similar bugs before.