Bug 1687 - Opening port fails on Linux >= 5.11.21 (fixed in sp upstream)
Summary: Opening port fails on Linux >= 5.11.21 (fixed in sp upstream)
Status: RESOLVED FIXED
Alias: None
Product: libserialport
Classification: Unclassified
Component: Portability (show other bugs)
Version: 0.1.1
Hardware: x86 Linux
: Normal critical
Target Milestone: ---
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2021-05-26 12:51 CEST by Peter Holzer
Modified: 2021-09-11 19:01 CEST (History)
6 users (show)



Attachments
lsusb, ltrace, strace (11.83 KB, text/plain)
2021-05-26 12:51 CEST, Peter Holzer
Details
workaround invalid termiox (1.19 KB, patch)
2021-06-11 19:11 CEST, karlp
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Holzer 2021-05-26 12:51:59 CEST
Created attachment 732 [details]
lsusb, ltrace, strace

Hi,

this issue is fixed in the development version of libserialport.

For the record: after upgrading to Fedora Kernel 5.11.21 opening a port fails with ENOTTY.
The problem is also present on newer Fedora Kernels and Vanilla Linux 5.13.RC3.

openat(AT_FDCWD, "/dev/ttyUSB0", O_RDWR|O_NOCTTY|O_NONBLOCK) = 3
ioctl(3, TCGETS, {B9600 opost isig icanon echo ...}) = 0
ioctl(3, TIOCMGET, [TIOCM_DTR|TIOCM_RTS]) = 0
ioctl(3, TCGETX, 0x14f4920)             = -1 ENOTTY (Inappropriate ioctl for device)

Please find lsusb, ltrace, strace in the attachment.

Opening ports without libserialport-0.1.1 or with the development snapshot works.

BR
Peter
Comment 1 Peter Holzer 2021-05-26 13:33:38 CEST
Tested wrong build, issue is only present on the Fedora build.
Building libserialport-0.1.1 myself works.
Can be closed.
Comment 2 karlp 2021-06-11 19:11:05 CEST
I doubt this should be "resolved" as it's still very much an issue on modern kernels. (5.11.22 here)

The termiox infrastructure was apparently simply removed, see https://www.spinics.net/lists/linux-serial/msg41926.html

Patch attached that disables the termiox check, and results in functional libserialport again.
Comment 3 karlp 2021-06-11 19:11:36 CEST
Created attachment 733 [details]
workaround invalid termiox
Comment 4 Gerhard Sittig 2021-06-13 08:20:57 CEST
Closer look at Linux kernel revisions suggests that the user space view 
of libserialport is mostly appropriate while Linux kernel versions may 
have opened a window of inconsistency.  See 'git logps --grep termiox -i' 
and 'git describe --contains $COMMIT' on the kernel.org source repo:

Kernel 5.11 dropped the TERMIOX support code but kept the struct in the 
header file. That's when presence of support gets detected while support 
is actually missing.

Kernel 5.12 also dropped the header declaration. Which should result in a 
working combination with verbatim libserialport mainline. Which is good 
assuming that 5.12 is a long term version. Assumes that executing kernel 
and user space are in sync. Could be an issue when building on one machine 
and running on another.

Kernel 5.13 changed the previously returned -EINVAL return code (which 
translates to invalid parameters) to -ENOTTY (unsupported ioctl for the 
device type). Which may result in higher severity.

Kernel source code commit messages suggest that TERMIOX was never taking 
effect. It was introduced in 2008 but no driver ever referenced it. That's 
why it was removed starting in 2020-12. We may get away with termios2 in 
all installations. Though that's a guess, needs verification.

Re-opening the report, it isn't solved, just wasn't seen again by the OP.
Comment 5 Dan Horák 2021-07-01 10:15:44 CEST
Fot the record, I have just updated the libserialport package in Fedora to include Karl's workaround.
Comment 6 Martin Ling 2021-07-01 11:52:22 CEST
For context: without the termiox ioctls, there is no way on Linux to set some of the advanced flow control options supported in our API:

- RTS/CTS hardware flow control is all-or-nothing; you can't set one direction without the other.

- DTR/DSR hardware flow control is not possible to enable at all.

Had I known these features weren't actually wired up in the kernel and weren't going to be, I'd probably have left those options out of the libserialport API.

They're effectively only available on Windows now, and the idea was always to have our API present a lowest common denominator of the serial options available over most mainstream operating systems.

But nothing we can do about it now.

We should merge Karl's patch as a minimum to make the library usable on newer kernels, and also see about dropping the dead termiox support code in serialport.c and linux_termios.c.
Comment 7 Gerhard Sittig 2021-07-01 18:09:18 CEST
Karl's quick workaround as of comment 3 went mainline in commit 6f9b03e597ea. 
The configuration will skip the termiox presence check. Complete removal of 
the now obsolete termiox support code in libserialport remains for later.
Comment 8 Tim Small 2021-07-10 08:49:15 CEST
FWIW, the breaking kernel change seems to have been backported to the 5.10 LTS kernel series with v5.10.37, so it will impact distros which use or plan to use this LTS kernel series (e.g. Debian 11) see Debian bug: https://bugs.debian.org/990863 and presumably other distros which use "backported" or "hardware enablement" kernels etc.
Comment 9 Marvin Sielenkemper 2021-09-11 19:01:13 CEST
The problem also occurs on Gentoo systems.
I have created an updated ebuild for libserialport which applies Karl's patch. It can be found here:
https://github.com/sielenk/gentoo-ebuild-repository/tree/main/dev-libs/libserialport