Bug 9777

Summary: Changing pl2303 terminal attributes causes data loss
Product: Drivers Reporter: Tom Hughes (tom)
Component: USBAssignee: Greg Kroah-Hartman (greg)
Status: VERIFIED CODE_FIX    
Severity: normal    
Priority: P1    
Hardware: All   
OS: Linux   
Kernel Version: 2.6.23 Subsystem:
Regression: --- Bisected commit-id:

Description Tom Hughes 2008-01-19 06:55:35 UTC
Latest working kernel version: 2.6.22.14
Earliest failing kernel version: 2.6.23.9
Distribution: Fedora (but tested with vanilla kernel.org kernels)
Hardware Environment:
Software Environment:
Problem Description:

Changing terminal attributes for a pl2303 USB serial port seems to cause received data to be lost, even when the mode passed to tcsetattr() is TCSANOW.

Steps to reproduce:

I encountered this problem reading from a GPS receiver using a program which calls tcsetattr() between reading each chunk of data in order to update read timeouts. With a 2.6.22 kernel this was working but an update to 2.6.23 caused it to stop working.

It appears that data is going missing when the terminal attributes are changed, leading to read timeouts and/or protocol errors depending on exactly what goes missing.

After some investigation with vanilla kernels I have determined that the immediate cause was a change to pl2303_set_termios() in drivers/usb/serial/pl2303.c by Alan Cox that removed code that used to return without doing anything if didn't think anything significant had changed in the terminal settings.

Obviously this isn't the root cause - it has just exposed what was presumably a pre-existing problem.
Comment 1 Greg Kroah-Hartman 2008-01-19 09:05:17 UTC
This has been fixed in 2.6.24-rc8, can you test to verify this?

Also, you can fix your userspace program to not do this, it isn't very good behavior to do lots of line change stuff to usb-serial devices, as it does increase latency and can cause side affects like this due to their cheap design.
Comment 2 Tom Hughes 2008-01-19 15:56:03 UTC
I can confirm that 2.6.24-rc8 appears to fix this problem.

It isn't actually my program - I'm writing a new driver for gpsbabel and it is the existing serial I/O code in gpsbabel that is setting the timeout before each read. I will pass your request on to the gpsbabel authors though.