Re: kernel panic on shutdoen/reboot

Vitaliy Makkoveev <[email protected]> Thu, 18 Jun 2026 08:13:14 +0000
Newsgroups gmane.os.openbsd.bugs
Message-ID <[email protected]>
On Thu, Jun 18, 2026 at 11:05:58AM +1000, David Gwynne wrote:
> On Tue, Jun 02, 2026 at 12:23:45AM +0000, Vitaliy Makkoveev wrote:
> > On Mon, Jun 01, 2026 at 09:59:41PM +0200, Alexander Bluhm wrote:
> > > On Mon, Jun 01, 2026 at 06:24:38AM +0300, Vitaliy Makkoveev wrote:
> > > > On Mon, May 25, 2026 at 04:45:26PM +0200, [email protected] wrote:
> > > > > >Synopsis:	<Kernel panic at shutdoen/reboot when rad is enabled>
> > > > > >Category:	
> > > > > >Environment:
> > > > > 	System      : OpenBSD 7.9
> > > > > 	Details     : OpenBSD 7.9 (GENERIC.MP) #222: Wed May  6 18:07:56 MDT 2026
> > > > > 			 [email protected]:/usr/src/sys/arch/arm64/compile/GENERIC.MP
> > > > > 
> > > > > 	Architecture: OpenBSD.arm64
> > > > > 	Machine     : arm64
> > > > > >Description:
> > > > > 	When rad is enabled, the system panics at shutdoen/reboot, no orderly reboot possible
> > > > > >How-To-Repeat:
> > > > > 	rcctl enable rad
> > > > > 	rcctl start rad
> > > > > 	shutdowen -r now
> > > > > 	... panic
> > > > > 	... reboot
> > > > > 	rcctl disable rad
> > > > > 	rcctl stop rad
> > > > > 	... panic
> > > > > 	... reboot
> > > > > 	rcctl check rad
> > > > > 	rad (failed)
> > > > >         shutdown -r now
> > > > > 	... ok
> > > > > >Fix:
> > > > > 	disable rad
> > > > > 
> > > > 
> > > > Hello,
> > > > 
> > > > I have no cad(4) device and I have no ability to compile this diff, so
> > > > I'm sending it offlist. Does it help?
> > > 
> > > In November 2025 I sent this diff, but nobody tested it.
> > > 
> > > https://marc.info/?l=openbsd-bugs&m=176314127606140&w=2
> > > 
> > 
> > I'm not happy with sleeping malloc under exclusive netlock. Can we do
> > sc_{tx,rx}buf allocation at probe time? Or even declare them as arrays
> > like bse(4)?
> 
> i borrowed an rpi5 and was able to reproduce the problem. i tested
> bluhm@s diff (with taskq_del renamed to task_del like below) and
> it fixed the bug. it also survives WITNESS, and generally makes
> sense to me, so it is ok by me.
> 
> i'll borrow another rpi5 next week and work on reducing the sleeping
> points, but i would like bluhm@ to commit his change now. it's
> objectively better than the current situation.
> 

I tried to by rpi5, but all available of them were bootlegs with
soldering evidences. It's great that someone else had tested it.

I have no objections to commit this diff as is.

> > 
> > > Index: dev/fdt/if_cad.c
> > > ===================================================================
> > > RCS file: /data/mirror/openbsd/cvs/src/sys/dev/fdt/if_cad.c,v
> > > diff -u -p -r1.16 if_cad.c
> > > --- dev/fdt/if_cad.c	17 Sep 2025 09:17:12 -0000	1.16
> > > +++ dev/fdt/if_cad.c	3 Jan 2026 21:58:47 -0000
> > > @@ -589,22 +589,10 @@ cad_ioctl(struct ifnet *ifp, u_long cmd,
> > >  {
> > >  	struct cad_softc *sc = ifp->if_softc;
> > >  	struct ifreq *ifr = (struct ifreq *)data;
> > > -	int error = 0, netlock_held = 1;
> > > +	int error = 0;
> > >  	int s;
> > >  
> > > -	switch (cmd) {
> > > -	case SIOCGIFMEDIA:
> > > -	case SIOCSIFMEDIA:
> > > -	case SIOCGIFSFFPAGE:
> > > -		netlock_held = 0;
> > > -		break;
> > > -	}
> > > -
> > > -	if (netlock_held)
> > > -		NET_UNLOCK();
> > >  	rw_enter_write(&sc->sc_cfg_lock);
> > > -	if (netlock_held)
> > > -		NET_LOCK();
> > >  	s = splnet();
> > >  
> > >  	switch (cmd) {
> > > @@ -722,9 +710,6 @@ cad_up(struct cad_softc *sc)
> > >  
> > >  	rw_assert_wrlock(&sc->sc_cfg_lock);
> > >  
> > > -	/* Release lock for memory allocation. */
> > > -	NET_UNLOCK();
> > > -
> > >  	if (sc->sc_dma64)
> > >  		flags |= BUS_DMA_64BIT;
> > >  
> > > @@ -880,8 +865,6 @@ cad_up(struct cad_softc *sc)
> > >  		}
> > >  	}
> > >  
> > > -	NET_LOCK();
> > > -
> > >  	/*
> > >  	 * Set MAC address filters.
> > >  	 */
> > > @@ -985,9 +968,6 @@ cad_down(struct cad_softc *sc)
> > >  	ifq_clr_oactive(&ifp->if_snd);
> > >  	ifp->if_timer = 0;
> > >  
> > > -	/* Avoid lock order issues with barriers. */
> > > -	NET_UNLOCK();
> > > -
> > >  	timeout_del_barrier(&sc->sc_tick);
> > >  
> > >  	/* Disable data transfer. */
> > > @@ -1011,7 +991,7 @@ cad_down(struct cad_softc *sc)
> > >  	/* Wait for activity to cease. */
> > >  	intr_barrier(sc->sc_ih);
> > >  	ifq_barrier(&ifp->if_snd);
> > > -	taskq_del_barrier(systq, &sc->sc_statchg_task);
> > > +	task_del(systq, &sc->sc_statchg_task);
> > >  
> > >  	/* Disable the packet clock as it is not needed any longer. */
> > >  	clock_disable(sc->sc_node, GEM_CLK_TX);
> > > @@ -1059,8 +1039,6 @@ cad_down(struct cad_softc *sc)
> > >  	cad_dmamem_free(sc, sc->sc_rxring);
> > >  	sc->sc_rxring = NULL;
> > >  	sc->sc_rxdesc = NULL;
> > > -
> > > -	NET_LOCK();
> > >  }
> > >  
> > >  uint8_t
> > > @@ -1683,8 +1661,14 @@ void
> > >  cad_statchg_task(void *arg)
> > >  {
> > >  	struct cad_softc *sc = arg;
> > > +	struct ifnet *ifp = &sc->sc_ac.ac_if;
> > >  
> > > -	clock_set_frequency(sc->sc_node, GEM_CLK_TX, sc->sc_tx_freq);
> > > +	rw_enter_write(&sc->sc_cfg_lock);
> > > +
> > > +	if ((ifp->if_flags & IFF_RUNNING))
> > > +		clock_set_frequency(sc->sc_node, GEM_CLK_TX, sc->sc_tx_freq);
> > > +
> > > +	rw_exit_write(&sc->sc_cfg_lock);
> > >  }
> > >  
> > >  struct cad_dmamem *
> > > 
> > 
>