Opening /dev/ttyUSB0 hangs, pl2303.ko module

Same probleme here. The workaround works fine :)

I can confirm this bug.
Tried to connect my Garmin eTrex GPS via USB/Serial cable. Trying to read data from the device gpsbabel simply hangs. After the modprobe workaround it works...

Please fix!

Regards,
  Andreas Weller

Same problem with a cp210x module -- except the workaround doesn't work

Used to work in 10.04

May or may not be related to http://forum.nginx.org/read.php?30,135400,135554

Certainly, the device I'm connecting to doesn't set DCD. The app I'm trying is closed-source, though, so I've asked those guys to change it to test.

You can check for DCD with "statserial /dev/ttyUSB0"

Like Berend, I have hit this problem setting up my cp210x based-LCD display with the SureElec driver in lcdproc. Exact same problem that is described for this bug: a call to open in the LCD driver that never returns. The workaround mentioned doesn't work for me.

I have found as an odd workaround though that if I run "screen /dev/ttyUSB0" and then kill screen (this only appears to work if I kill it, not if I close it nicely) I can then use /dev/ttyUSB0 properly.

Same problem with cp210x, but I was able to make it work.
After initialization in non-blocking mode it starts working well in blocking mode.

Same issue with Pololu USB-RS232 converter. I think this is confirmed.

Same problem with a PL-2303HX chip (Prolific). I tried to chmod 777 /dev/ttyUSB0, but it was useless.
The workaround worked, thank you ;-)

Nevertheless, it worked perfectly with gtkterm !?!

Same problem with generic PL-2303 adapter. Workaround worked.

I was hit with this problem using my GPS tracking application on a 2.6.38 Kernel. After much researching it seems this is NOT a driver bug but a CHANGE in the kernel Serial API semantics.

What has happened is that the API now blocks when a Serial device is not indicating it is ready. This included 'open' on a serial device which now can block.

Since lots of RS232 serial devices do not bother with any control signals such as DCD (data carrier detect) they never indicate they are ready and open blocks. This is the 'HANG' we are seeing, There are several workarounds:

1. Wire the RS232 "DCD" signal correctly. This is often not an option. In my case I am reading from a GPS mouse which has a built in RS232 to USB convertor.

2. Open the serial device non-blocking and set the CLOCAL flag on the device. From the tty_ioctl documentation:

Marking a line as local

If the CLOCAL flag for a line is off, the hardware carrier detect (DCD) signal is significant, and an open(2) of the corresponding tty will block until DCD is asserted, unless the O_NONBLOCK flag is given. If CLOCAL is set, the line behaves as if DCD is always asserted. The software carrier flag is usually turned on for local devices, and is off for lines with modems.

In my code I open and explicitly set CLOCAL

    qDebug ( devPath );
    file = open(devPath.ascii(), O_RDONLY | O_NONBLOCK);
    if ( file != -1 ) {
        // serial port needs to be setup
        struct termios term;
        bool ok = tcgetattr ( file, &term ) == 0;
        cfmakeraw ( &term );
        term.c_iflag |= CLOCAL;
        cfsetispeed( &term, B4800 );
        ok &= tcsetattr ( file, TCSAFLUSH, &term ) == 0;
      ....

Sadly after you 'open' a device non-blocking you cannot change it back to blocking. The simplist solution is to use a 'poll' before you 'read' to wait for new data to arrive.

        // read byte from non blocking file
        pollfd pfd;
        pfd.fd = file;
        pfd.events = POLLIN;
        int ok = poll( &pfd, 1, -1 );
        if ( ok < 0 ) {
             // poll failed
        }
        char buf[1];
        ssize_t ch = read( file, buf, 1 );
        if ( ch < 1 ) {
             // read error

3. A third alternative, which I have not tried, is to use "stty" to set the serial device CLOCAL before your application starts.

Hopefully this help clear up the issue. I would recommend setting this bugs status to INVALID. Possibly the perceived regression on the USB serial drivers could be resolved in that they default to being CLOCAL which is what I assume was the case before. But another change to the Kernal semantics would probably just confuse the issue!

Michael, thanks for the information. Can you elaborate on how removing then reinstalling this kernel module (pl2303) works around the new kernel semantics. It doesn't seem like it should work if the problem is really with the hardware flow control of the device. So I'm wondering if there isn't still some problem with this driver that has been exposed by the new kernel semantics.

I was wondering about that phenomena too! For me removing and reinstalling pl2303 only worked for a short period, after about 30s it stopped working.

As far as I can tell from the comments on the bug the semantics changed somewhere in Maverik so CLOCAL is not set for all USB serial drivers. Thinking about it, I not sure if this is directly a kernel change or due to a change in Ubuntu automatic configuration of the device when it is seen.

It also seems from the comments that the workaround only works for the pl2303 driver. So that there is possibly a very minor bug that is part of this drivers implementation. One would have to do some investigating looking at how the terminal settings change. I only had the hardware that I found the problem on for a day, so personally I can't investigate any further !

I think even if this isn't a bug against the kernel, it's still a bug that leaves a lot of users in the lurch. Maybe rather than marking it as invalid, it would be better to figure out what to assign it to. For many people, for a variety of reasons, patching the source code to their affected applications in order to work with the new serial API semantics isn't an option. Assuming, of course, we're certain this isn't a bug in the kernel.

Same probleme, ubuntu 11.04 doesn't resolve it

upstream kernel patch d14fc1a (USB: serial: handle Data Carrier Detect changes) is likely the remedy

I have a couple of older TEMPer USB-to-Serial Thermometers that depend on this module, so Michael Stevens comment (#12) about the behaviour was very helpful for me...

The programs the TEMPer's depend on (TEMPer.c and temper-read-temp (temper-read-temp, part of temper-tools-1.0 from roaringpenguin.com) both block on the serial port open bit (I guess they don't do the DCD properly)... Here's what the change looks like now that it works again.

- fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY );
+ fd = open(MODEMDEVICE, O_RDWR | O_NOCTTY | O_NONBLOCK ); // O_NONBLOCK: In Linux 2.6+ serial ports became able to block, we don't want that here.

Workaround is here: http://ubuntuforums.org/showthread.php?p=11579035#post11579035

- CH

Hi

I had the same problem with an RS232 express card solved using the workaround but now i must execute the 2 commands every time i reboot the pc.
Could you, please, tell me how to avoid this little inconvenience ?
thanks.

Still an issue with the pl2303 module in Precise. Workaround works.

John Stebbins, this bug was reported a while ago and there hasn't been any activity in it recently. We were wondering if this is still an issue? Can you try with the latest development release of Ubuntu? ISO CD images are available from http://cdimage.ubuntu.com/releases/ .

If it remains an issue, could you run the following command in the development release from a Terminal (Applications->Accessories->Terminal). It will automatically gather and attach updated debug information to this report.

apport-collect -p linux <replace-with-bug-number>

Also, if you could test the latest upstream kernel available that would be great. It will allow additional upstream developers to examine the issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do not test the kernel in the daily folder, but the one all the way at the bottom. Once you've tested the upstream kernel, please remove the 'needs-upstream-testing' tag. This can be done by clicking on the yellow pencil icon next to the tag located at the bottom of the bug description and deleting the 'needs-upstream-testing' text. As well, please comment on which kernel version specifically you tested.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream', and comment as to why specifically you were unable to test it.

Please let us know your results. Thanks in advance.

In ubuntu 12.04 I do not have this issue anymore. I think that it was
already solved in ubuntu 11.10 .

-Oz

On 07/25/2012 09:57 AM, Christopher M. Penalver wrote:
> John Stebbins, this bug was reported a while ago and there hasn't been
> any activity in it recently. We were wondering if this is still an
> issue? Can you try with the latest development release of Ubuntu? ISO CD
> images are available from http://cdimage.ubuntu.com/releases/ .
>
> If it remains an issue, could you run the following command in the
> development release from a Terminal
> (Applications->Accessories->Terminal). It will automatically gather and
> attach updated debug information to this report.
>
> apport-collect -p linux <replace-with-bug-number>
>
> Also, if you could test the latest upstream kernel available that would
> be great. It will allow additional upstream developers to examine the
> issue. Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please do
> not test the kernel in the daily folder, but the one all the way at the
> bottom. Once you've tested the upstream kernel, please remove the
> 'needs-upstream-testing' tag. This can be done by clicking on the yellow
> pencil icon next to the tag located at the bottom of the bug description
> and deleting the 'needs-upstream-testing' text. As well, please comment
> on which kernel version specifically you tested.
>
> If this bug is fixed in the mainline kernel, please add the following
> tag 'kernel-fixed-upstream'.
>
> If the mainline kernel does not fix this bug, please add the tag:
> 'kernel-bug-exists-upstream'.
>
> If you are unable to test the mainline kernel, for example it will not
> boot, please add the tag: 'kernel-unable-to-test-upstream', and comment
> as to why specifically you were unable to test it.
>
> Please let us know your results. Thanks in advance.
>
> ** Changed in: linux (Ubuntu)
> Status: Confirmed => Incomplete
>

We have 12.04 and experienced this problem.
Usage with gtkterm - no problem, communication ok.

With blocking usage, it blocked (sometimes) on open using:

    fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_SYNC );
or
    fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY );

After hours of testing we found out that those lines (directly executed afterwards) solves the problem ... strange:

    fd = open("/dev/ttyUSB0", O_RDWR | O_NOCTTY | O_NONBLOCK);
    fcntl(fd, F_SETFL, 0); //restore normal (blocking) behavior

Now we can read and write as under 10.10. We hope that helps other developers.

Extension to my comment above: Reading is then only possible byte by byte.
We solved the problem by an udev rule that modprobes the pl2303 (_once_) as described at the beginning.
That's working, but we appreciate a nicer solution or a fix.

I noticed this bug today, after upgrading to 12.04.1.
It seems Michael Stevens (#12) is right and it's a change on the kernel semantics, because to me this happens with regular serial ports (I have a serial port PCI card to add 2 more ports to the machine).

This is a serious regression on the kernel behavior. Unconfigured serial ports now freeze when opened, instead of just failing, meaning many old programs need to be fixed to work with the new behavior.

And this is not so trivial as many many think. I work with a lot of serial, paralel and it's USB equivalent devices (USB serial, usblp and raw USB) and there are a lot of device quirks in there. There are devices that simply don't work with O_NONBLOCK and many serial ones use 3 wire serial cables, with no flow control and no shunts -- and modern techs don't knows how to make cables anymore when it requires soldering.

To me this is chaos in support calls...

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]

Stefan Felkel / Nuno Lucas, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

Alexander Menk, if you have a bug in Ubuntu, could you please file a new report by executing the following in a terminal:
ubuntu-bug linux

For more on this, please see the Ubuntu Kernel team article:
https://wiki.ubuntu.com/KernelTeam/KernelTeamBugPolicies#Filing_Kernel_Bug_reports

the Ubuntu Bug Control team and Ubuntu Bug Squad team article:
https://wiki.ubuntu.com/Bugs/BestPractices#X.2BAC8-Reporting.Focus_on_One_Issue

and Ubuntu Community article:
https://help.ubuntu.com/community/ReportingBugs#Bug_reporting_etiquette

When opening up the new report, please feel free to subscribe me to it.

Please note, not filing a new report may delay your problem being addressed as quickly as possible.

Thank you for your understanding.

[Expired for linux (Ubuntu) because there has been no activity for 60 days.]