Bug 431379 - System freeze on reading from usb-serial device
Summary: System freeze on reading from usb-serial device
Alias: None
Product: Fedora
Classification: Fedora
Component: kernel
Version: 8
Hardware: i686
OS: Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-02-03 21:50 UTC by Dmitry Burstein
Modified: 2008-03-16 23:27 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-03-16 19:27:57 UTC
Type: ---

Attachments (Terms of Use)
Perl script for reading raw data from AT91xx based GPS-Loggers (14.39 KB, text/plain)
2008-02-03 21:50 UTC, Dmitry Burstein
no flags Details
NMI watchdog screenshot (148.49 KB, image/jpeg)
2008-03-03 19:01 UTC, Dmitry Burstein
no flags Details
NMI watchdog screenshot in fb mode (128.49 KB, image/jpeg)
2008-03-03 21:59 UTC, Dmitry Burstein
no flags Details
Fix for recursive lock-taking (1.07 KB, patch)
2008-03-05 07:21 UTC, Pete Zaitcev
no flags Details | Diff
/proc/bus/usb/devices (4.08 KB, text/plain)
2008-03-05 18:05 UTC, Dmitry Burstein
no flags Details
Pete's patch adapted to kernel version (1.18 KB, patch)
2008-03-05 22:29 UTC, Dmitry Burstein
no flags Details | Diff

Description Dmitry Burstein 2008-02-03 21:50:51 UTC
Description of problem:
When trying to "sysread" (perl script) from a AT91xx-based GPS device, connected
via "usbserial" kernel module, the system freezes. Nothing seems to work,
besides the "Reset" button.
Examining the messages file after a reboot reveals nothing.

Version-Release number of selected component (if applicable):
kernel version:

How reproducible:
every time the sysread is called

Steps to Reproduce:
1. Connect the "Gisteq PhotoTrackr Lite" device via USB cable
2. Run "modprobe usbsusbserial vendor=0x03EB product=0x6126"
3. Run a script containing a "sysread" command from previously opened stream
Actual results:
The system freezes.

Expected results:
The same script, on the same computer/port/cable/device combination, running
Knoppix 5.1.1 Live DVD, continues to run and produces the expected output.

Additional info:
The Knoppix DVD runs kernel version 2.6.19(.1). The original perl script,
causing the system freeze, can be downloaded from it's author's site:

Comment 1 Dmitry Burstein 2008-02-03 21:50:51 UTC
Created attachment 293841 [details]
Perl script for reading raw data from AT91xx based GPS-Loggers

Comment 2 Dmitry Burstein 2008-02-07 22:32:59 UTC
I've just checked it with the last kernel version. Unfortunately,
with the same results: complete system freeze.

Comment 3 Pete Zaitcev 2008-02-14 03:02:16 UTC
It is vital to convert the freeze into an oops (with NMI watchdog).
But first... Dmitry, did you try this on the text console (Alt-F1)?
What does happen in that case? No messages?

Comment 4 Dmitry Burstein 2008-02-16 22:37:24 UTC
When running from a console, I just got the script printing the "Opened
/dev/ttyUSB0" message, immediately followed by system freeze.
When booting with "nmi_watchdog=1", the NMI dumped on the screen some info, but
the system still got completely unresponsive - with just "Caps Lock" and "Scroll
Lock" flashing. I had to reboot it with the "reset" switch, and next time added
"panic=10" to the boot options, which worked. But unfortunately, the "messages"
file doesn't contain any helpful information regarding the lockup: the last
message recorded there is about new usbserial device connected on /dev/ttyUSB0.
Anyway, as I myself have absolutely no experience in kernel debugging, I'll be
happy to follow your further recommendations, and to inform you on the results.
Thanks ahead.

Comment 5 Dmitry Burstein 2008-02-22 21:39:23 UTC
I've tried it on - with the same results :-(

Comment 6 Dmitry Burstein 2008-03-03 19:01:40 UTC
Created attachment 296661 [details]
NMI watchdog screenshot

Well, I felt really silly doing this, but I really didn't know any better way:
attached is the screenshot (literally!) of what happened when the system became
frost. After this, only the reset button worked.
I hope it will provide you some clue on what's going on, or at least any idea
on how to get some more information.
Thanks ahead.

Comment 7 Chuck Ebbert 2008-03-03 21:06:04 UTC
Can you capture that with the console in 50-line mode (vga=1) or framebuffer
mode (vga=791)?

Comment 8 Dmitry Burstein 2008-03-03 21:59:32 UTC
Created attachment 296683 [details]
NMI watchdog screenshot in fb mode

Here it is: the screen captured in fb mode.

Comment 9 Pete Zaitcev 2008-03-05 05:00:04 UTC
Awesome, thanks a lot.

The traditional answer is, the generic usb-serial is not useable this
way and it _will_ lock up (depending on settings of setserial
/dev/ttyUSB0 low_latency perhaps). The solution is to beat those
who suggest "modprobe usbsusbserial vendor=0x03EB product=0x6126"
with a stick with rusty nails; suggest them to propose patches
to real subdrivers (e.g. pl2303).

However, I always wanted to see a case of it actually locking up
with a traceback, so thanks. I may be able to fix this now.

Comment 10 Pete Zaitcev 2008-03-05 07:21:58 UTC
Created attachment 296859 [details]
Fix for recursive lock-taking

This seems too simple to be true. I'll poke Greg K-H about it.

Comment 11 Dmitry Burstein 2008-03-05 17:25:39 UTC
Thanks a lot, I hope your patch will fix it. How can I test it? Can you attach
compiled module for kernel release? It's been at least 5 years
since I've compiled a kernel myself, and I'm not sure I still can do it properly
- without inserting any artifacts of my own :-(

Comment 12 Pete Zaitcev 2008-03-05 17:48:01 UTC
I have submitted the patch upstream, so there's going to be a discussion
and a decision if the solution is appropriate. If outcome is positive,
the patch recirculates through upstream.

If Chuck threw it into Fedora pool for testing, it would be great.

Dmitry, I have a request: please attach your /proc/bus/usb/devices.
Maybe I can add your GPS to a proper driver as I mentioned in comment #9.

Comment 13 Dmitry Burstein 2008-03-05 18:05:22 UTC
Created attachment 296903 [details]

Done. The GPS is the on with Vendor=03eb and ProdID=6126
Thanks again.

Comment 14 Pete Zaitcev 2008-03-05 21:49:17 UTC
David Brownell suggested that cdc-acm should be able to drive this
device. It's apparently commonplace for CDC devices to straddle two
interfaces (I thought that only CDC RNDIS did it, but I guess not).

Dmitry, please do this:
 rmmod usbserial   # rmmod dependencies first if this fails
 modprobe cdc_acm
 dmesg | tail -40

Comment 15 Dmitry Burstein 2008-03-05 22:05:13 UTC
Here is the (relevant) output:

usb 2-1: new full speed USB device using uhci_hcd and address 4
usb 2-1: configuration #1 chosen from 1 choice
usbcore: registered new interface driver usbserial
drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
usbserial_generic 2-1:1.0: generic converter detected
usbserial_generic 2-1:1.0: Generic device with no bulk out, not allowed.
usbserial_generic: probe of 2-1:1.0 failed with error -5
usbserial_generic 2-1:1.1: generic converter detected
usb 2-1: generic converter now attached to ttyUSB0
usbcore: registered new interface driver usbserial_generic
drivers/usb/serial/usb-serial.c: USB Serial Driver core
usbcore: deregistering interface driver usbserial_generic
generic ttyUSB0: generic converter now disconnected from ttyUSB0
usbserial_generic 2-1:1.1: device disconnected
drivers/usb/serial/usb-serial.c: USB Serial deregistering driver generic
usbcore: deregistering interface driver usbserial
usbcore: registered new interface driver cdc_acm
drivers/usb/class/cdc-acm.c: v0.25:USB Abstract Control Model driver for USB
modems and ISDN adapters

Comment 16 Dmitry Burstein 2008-03-05 22:29:49 UTC
Created attachment 296951 [details]
Pete's patch adapted to kernel version

Awesome! Pete, thank you very much: the problem is solved! I've just rebuild
the kernel with your patch applied (adapted to the earlier kernel
version), and it solved the problem. The computer didn't freeze, and I finally
was able to download the memory dump from my GPS gadget.
So, on my part, I can recommend including this patch to the upcoming kernel
release :-)

Comment 17 Hartmut Schimmel 2008-03-06 20:33:23 UTC
Thank you very much ! As the author of the GPS logger read-out perl script
(http://itu4l.schimmelnetz.de), with which the problem cames up I hope, you pack
away the stick with rusty nails now.

Comment 18 Dmitry Burstein 2008-03-08 15:06:15 UTC
I tried your patch (the original one from comment #10) with the newly released
kernel, and again it worked like a charm. One remark though: I'm
not sure it's somehow related to the current discussion, but with this kernel
any attempt to set the baud rate to anything bigger then the default 9600 failed
with "stty: /dev/ttyUSB0: unable to perform all requested operations". It didn't
bother me much: the GPS's memory wasn't that big. But if it is bug-related, may
be it'll help with your patch evaluation.

Comment 19 Chuck Ebbert 2008-03-10 22:28:00 UTC
Fixed in

Comment 20 Fedora Update System 2008-03-13 21:58:23 UTC
kernel- has been submitted as an update for Fedora 8

Comment 21 Fedora Update System 2008-03-16 19:27:49 UTC
kernel- has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Comment 22 Dmitry Burstein 2008-03-16 23:27:39 UTC
Can confirm: kernel- is working (still, the baud rate restricted
as mentioned in comment #18). The bug should stay closed. Thank you all for the

Note You need to log in before you can comment on or make changes to this bug.