IRC channel logs

<damo22>youpi: netbsd says it claims to explicitly disable interrupts with LEGSUP register but if LOCK_DEBUG is set it could be bad

<damo22>i just asked what if the irq is shared and the other device interrupts

<damo22>youpi: looks like the same bug on xhci

<damo22>#0 0x080fd037 in rumpuser_mutex_spin_p ()

<damo22>#1 0x080ec98d in rumpns_mutex_enter ()

<damo22>#4 0x080af680 in config_attach_internal ()

<damo22>#5 0x080af875 in rumpns_config_found_acquire ()

<damo22>#6 0x080af9da in rumpns_config_found ()

<damo22>#8 0x0810a0a2 in rumpns_usbd_probe_and_attach ()

<damo22>#0 0x080fd037 in rumpuser_mutex_spin_p (mtx=0x0) at ./buildrump.sh/src/lib/librumpuser/rumpuser_pth.c:166

<damo22>#1 0x080ec9bd in mutex_spin_enter (mtx=0x200ab4f8) at ./buildrump.sh/src/sys/rump/librump/rumpkern/locks.c:174

<damo22>#2 0x0818381c in xhci_intr (v=0x200ab000) at ./buildrump.sh/src/sys/rump/../dev/usb/xhci.c:1714

<damo22>#3 0x08123921 in wrapped_handler ()

<damo22>#4 0x081a35da in interrupt_demuxer ()

<youpi>not surprising...

<damo22>can we fix this by not using smp locking?

<damo22>ie define RUMP_LOCKS_UP

<youpi>depends how that ends up defining the mutex

<youpi>we still have concurrency anyway since we have threads

<youpi>really, it looks like a genuine bug in bsd

<youpi>which just happen not to affect them only by luck

<youpi>probably just because it's just in the rump case that something gets allocated etc.

<damo22>buildrump.sh/src/sys/rump/librump/rumpkern/locks_up.c

<damo22>okay, i can try asking them to fix it

<damo22>it seems like a common pattern they use to init the mutex after the intr registration though

<youpi>that's very surprising, it needs to be discussed with them

<youpi>perhaps there is some interrupt masking that we are missing in the scheme, that prevents this case

<damo22>youpi: i spoke with them, they admit its a bug and i wrote a report for them to look at

<youpi>ok, good :)

<damo22>#0 0x080fd037 in rumpuser_mutex_spin_p (mtx=0x0)

<damo22> at ./buildrump.sh/src/lib/librumpuser/rumpuser_pth.c:166

<damo22>#1 0x080ec98d in mutex_enter (mtx=0x834e4c0 <ugenif>)

<damo22> at ./buildrump.sh/src/sys/rump/librump/rumpkern/locks.c:164

<damo22>#2 0x081031eb in ugenif_get_unit (sc=0xe701000)

<damo22> at ./buildrump.sh/src/sys/rump/dev/lib/libusb/../../../../dev/usb/ugen.c:230

<damo22>#3 ugenif_attach (parent=0x2008a800, self=0x2008ae00, aux=0xde02c2c)

<damo22> at ./buildrump.sh/src/sys/rump/dev/lib/libusb/../../../../dev/usb/ugen.c:462

<damo22>#4 0x0810346d in ugen_attach (parent=0x2008a800, self=0x2008ae00, aux=0xde02d9c)

<damo22> at ./buildrump.sh/src/sys/rump/dev/lib/libusb/../../../../dev/usb/ugen.c:399

<damo22>hmm how does ugen_modcmd get called

<damo22>fixed the crash but i cant find /dev/ugen

<azert>damo22: can you do ls /dev inside rump?

<azert>Maybe it is /dev/ugen<N>

<azert>should be possible with rump_sys_readdir

2025-07-02.log