open blocking forever on usb serial device

[h1771t]

Hi,

Weird issue, open blocks forever on opening /dev/ttyUSBx sometimes. Specifically dmesg shows me usb device disconnect then reconnect (different issue I'm still trying to figure out). When this happens the usb serial device moves from ttyUSB0 to ttyUSB1, so I then terminate my program and start it again on ttyUSB1. This is when open blocks forever. If I stop the program and open ttyUSB1 on minicom, then close minicom and open my program, then open works fine. Seems minicom sets or resets something on ttyUSB1? I'm not really sure.

Info:
Bus 003 Device 049: ID 067b:2303 Prolific Technology, Inc. PL2303 Serial Port / Mobile Phone Data Cable

[580784.787037] pl2303 ttyUSB0: pl2303 converter now disconnected from ttyUSB0
[580785.242982] usb 3-1: pl2303 converter now attached to ttyUSB1

How I'm opening the port:

let port_settings = |mut settings: Settings| {
        settings.set_raw();
        settings.set_baud_rate(9600)?;
        settings.set_char_size(CharSize::Bits8);
        settings.set_stop_bits(StopBits::One);
        settings.set_parity(Parity::None);
        settings.set_flow_control(FlowControl::None);
        Ok(settings)
    };

    println!("port: {}", port);
    let s = match SerialPort::open(port, port_settings) {
        Ok(s) => s,
        Err(err) => {
            panic!("Error opening serial port: {}", err)
        }
    };
    println!("serial port opened");

OS: latest raspberry pi OS (Debian GNU/Linux 12 (bookworm))
arch: aarch64
Hardware: raspberry pi 5 model B rev 1.0 8GB

Any advice appreciated, I can supply any other info you might want, to diagnose.
Thanks

[de-vri-es]

This seems odd. Could you run your program with strace to see which syscall is blocking forever?

[atontini]

I had the same issue and I solved it this way:

1. I put the port inside an Option<>
2. I used take() to free the resource
3. Last but not least, I used drop() to ensure proper cleanup

After these steps I was able to reopen the serial port on the locked device.
In code, this translates to something like this:

let mut port: Arc<Mutex<Option<SerialPort>>>;
let mut guard = port.lock().unwrap();
if let Some(port) = (*guard).take() {
    drop(port);
    println!("Serial port closed");
}

Tell me if you need any further help.

[atontini]

@de-vri-es Should I update the documentation, or is it better for the library to have its own close function?

[h1771t]

This seems odd. Could you run your program with strace to see which syscall is blocking forever?

So I had to wait for the usb disconnect for this issue to repeat itself, which took 2 days. So when it happened, ttyUSB1 became ttyUSB0. So I closed my program, then tried to start it without strace on ttyUSB0 and it gave me the hanging behaviour. Then I closed it and ran it again with strace, doing so open did not hang and it ran normally. Weird. I will have to wait for it to happen again and try strace on it again but in this case, it seems using strace prevented open from hanging, I'm not even sure if that is possible or what I saw was a red herring.

[h1771t]

I had the same issue and I solved it this way:

Strange, is this related to multiple programs using the serial port at at the same time maybe? In my case when the usb reconnects, I stop my rust serial program completely (which should free up anything?), and then opening it again causes the issue (opening on a new ttyUSB due to the usb reconnect). And when it happens, I can open the new ttyUSB with minicom fine, close minicom, after which the rust program works again on that new ttyUSB.

[atontini]

I had the same issue and I solved it this way:

Strange, is this related to multiple programs using the serial port at at the same time maybe? In my case when the usb reconnects, I stop my rust serial program completely (which should free up anything?), and then opening it again causes the issue (opening on a new ttyUSB due to the usb reconnect). And when it happens, I can open the new ttyUSB with minicom fine, close minicom, after which the rust program works again on that new ttyUSB.

I believe the channel may be locked due to the code implementation. Before implementing the code I posted yesterday for closing the serial, I followed the same approach you mentioned regarding minicom - manually resetting the device using the AT+CFUN=16 command.

[de-vri-es]

Thanks for sharing!

I'm a bit confused though. The code doesn't do anything particular to the serial port. It's dropping it, but dropping it from an Arc<Mutex<Option<SerialPort>> or directly dropping it doesn't make a difference.

Does the code that deadlock use a Mutex?

Either way, terminating your program for sure closes the serial port. And there's no mandatory file locking in Linux, and we're not using advisory locks either. So I don't know of anything that should block when opening a serial port.

Reading, writing or flushing could block, but nothing else should.

[atontini]

Thanks for sharing!

I'm a bit confused though. The code doesn't do anything particular to the serial port. It's dropping it, but dropping it from an Arc<Mutex<Option<SerialPort>> or directly dropping it doesn't make a difference.

Does the code that deadlock use a Mutex?

Yes, but when I debugged the code using Arc::strong_count, it seems that the drop function didn't work because the Arc still had multiple references, so the reference count didn't reach zero. May am I missing something?

[de-vri-es]

@atontini: Thanks for the extra information. I can't know for sure, but I suspect you are getting a deadlock from the Mutex, not from the serial port. Opening the same port multiple times on Linux is possible (not always a good idea, but totally possible).

However, it sounds like the issue from @h1771t may be different, since the whole process was already terminated. I think strace is really the best way to figure out what is happening.

You might be able to reproduce the issue by manually unplugging the device while it is in use. This will almost certainly lead to the device being created with a different name when you plug it in again.

[de-vri-es]

Yes, but when I debugged the code using Arc::strong_count, it seems that the drop function didn't work because the Arc still had multiple references, so the reference count didn't reach zero. May am I missing something?

To be more specific on your issue: it must be something in your application that is keeping another clone of the Arc around. As long as any clone of the Arc is alive, the contents will not be dropped.

[h1771t]

You might be able to reproduce the issue by manually unplugging the device while it is in use

Noted thanks, the device is offsite at a client so I can't easily unplug it, when I go there again I will try reproduce it by unplugging it and report back.