kern/60494: Non-MP safe TULIP driver on GENERIC kernel causes apparent spinlock in ifmedia_match during boot

["gary%kisaracorporation.com@localhost via gnats" <gnats-admin%NetBSD.org@localhost>]

>Number:         60494
>Category:       kern
>Synopsis:       Non-MP safe TULIP driver on GENERIC kernel causes apparent spinlock in ifmedia_match during boot
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Thu Jul 23 23:35:00 +0000 2026
>Originator:     Gary Sparkes
>Release:        11.99.6
>Organization:
Kisara Development
>Environment:
NetBSD test.local 11.99.6 NetBSD 11.99.6 (GENERIC) #0 Thu May 14 01:42:43 UTC 2026 mkrepro%mkrepro.NetBSD.org@localhost:/usr/src/sys/arch/alpha/compile/GENERIC alpha
>Description:
On the ES40 emulation platform, when booting with a single configured NIC, NetBSD becomes stuck in a spinlock. 

When diagnosing this as an emulation side issue, I noticed the guest was stuck in a tight spinlock-like loop on the debugging side.

An MP (two or more CPU configuration) exposes more information, in the form of 

[  81.9098060] cpu1[638 ifconfig]: hogging kernel lock
[  81.9107815] at 0xfffffc00009937c8 pc 0xfffffc000114dbe8
[  81.9127402] ipi_msg_cpu_handler() at netbsd:ipi_msg_cpu_handler+0xa8
[  81.9146894] printf() at netbsd:printf_nolog+0xd0
[  81.9156655] --- root of call graph ----

Some information/discussion available here: https://github.com/ES40-Emu/es40/issues/130

This happens to us specifically because we complete autonegotiation and return media status immediately on the CSR write. I suspect, should physical hardware complete fast enough for some reason, that it would also catch this edge. 

I note the comment at the top of if_media.c points out an edge scenario, and that the initial report of the INSTALL working but GENERIC having the defect, eventually points at GENERIC being compiled MULTIPROCESSOR.

When a delay in completion of autonegotiation was introduced into the emulator, we no longer got caught in a tight guest loop and boot proceeded successfully and normally.  The introduced delay was only 50ms. 

We appear to be in....

sys_ioctl -> isoo_ioctl -> doifioctl -> tlp_ioctl -> ether_ioctl -> ifmedia_ioctl(SIOCSIFMEDIA) -> ifmedia_change -> tlp_mediachange -> tlp_init -> tlp_2114x_isv_tmsw_set -> tlp_2114x_nway_servce -> tlp_2114x_nway_statchg -> ifmedia_match -> mutex_spin_enter 

we end up bouncing between pc fffffc00010ef350 and fffffc000113c50

fffffc00010ef350 being mutex_vector_enter+0x5c0 
fffffc0001113c50 being nullop+0x0 

Digging in.....
>How-To-Repeat:
Install NetBSD on the ES40 emualtor, configure NIC on NetBSD to boot with tlp0 configured for autonegotiate, boot installed system. 

ES40 configuration will of course require at least an emulated NIC, the 53c810 scsi controller should be the only adapter used.

In effect, any scenario where the tulip DEC21142/21143 completes SIA autonegotiate immediately should trigger this. 
>Fix:
>From diagnosis, I believe changing if_media.c's ifmedia_match() to use the IFMEDIA_LOCK_FOR_LEGACY and IFMEDIA_UNLOCK_FOR_LEGACY 

ifmedia_change() already does this.

I'm guessing the tulip driver doesn't get much exercise these days....

Or, I suppose, convert/fix the tulip driver to be MP safe, as the comment at the top of if_media.c states. 

Removing media autoselect from the config may also be a workaround, but I have not confirmed that. 

As well, introducing a delay into autonegotiation on the emulation side hides this, but I think this sufficiently points to a flaw/edge case that could see light in some scenario and isn't alpha-specific.