Re: ucom console again [PATCH]

On Tue, Nov 25, 2025 at 08:32:24AM +0000, Nick Hudson wrote:
[calling usbd_transfer in callback fires lock-against-myself panic]
> This doesn't make sense. it's perfectly acceptable to call usbd_transfer
> from a callback.

Indeed it works, thank you for the hint! I am just a bit frustrated 
I did not note in the comment what lock triggered the lock-against-myself
panic. I will post an updated patch in about 10 hours.

> > On Qemu:
> > - boot -a sometime hang on a prompt. There is a race somewhere,
> >    I suspect it does not happen on real hardware because Qemu
> >    serial emulation is much faster than a real serial port.
> > - getty fails to start because uftdi.c fails ioctl TIOCSETA with
> >    USBD_STALLED. It seems so unrelated to my changes that I wonder
> >    it I am not hitting an unrelated bug.
> 
> both these should be easy to debug with qemu trace / attaching gdb.

We already discussed that bugs privately. 

On boot -a random hang: 
We get stuck in ucom_cnpoolc() here:
    while(!db_active && atomic_load_relaxed(&cn->cn_sending) == 1)
        usbd_dopoll(sc->sc_iface);

We have cn->cn_sending still set to 1. ucom_cnput_complete() is
never invoked. OTOH, ucomreadb() is still invoked on input, 

On getty failure, ioctl TIOCSETA calls uftdi_param() where we 
have this call that returns USBD_STALLED:
        req.bmRequestType = UT_WRITE_VENDOR_DEVICE;
        req.bRequest = FTDI_SIO_SET_BITMODE;
        USETW(req.wValue, FTDI_BITMODE_RESET << 8 | 0x00);
        USETW(req.wIndex, portno);
        USETW(req.wLength, 0);
        err = usbd_do_request(sc->sc_udev, &req, NULL);

Both problem only happen in Qemu but not on real hardware.
-- 
Emmanuel Dreyfus
[email protected]