Bug 431379

Created attachment 293841 [details]
Perl script for reading raw data from AT91xx based GPS-Loggers

I've just checked it with the last 2.6.23.14-115 kernel version. Unfortunately,
with the same results: complete system freeze.

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?

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.

I've tried it on 2.6.23.15-137 - with the same results :-(

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.

Can you capture that with the console in 50-line mode (vga=1) or framebuffer
mode (vga=791)?

Created attachment 296683 [details]
NMI watchdog screenshot in fb mode

Here it is: the screen captured in fb mode.

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.

Created attachment 296859 [details]
Fix for recursive lock-taking

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

Thanks a lot, I hope your patch will fix it. How can I test it? Can you attach
compiled module for 2.6.23.15-137 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 :-(

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.

Created attachment 296903 [details]
/proc/bus/usb/devices

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

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

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

Created attachment 296951 [details]
Pete's patch adapted to 2.6.23.15 kernel version

Awesome! Pete, thank you very much: the problem is solved! I've just rebuild
the 2.6.23.15-137 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 :-)

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.

I tried your patch (the original one from comment #10) with the newly released
kernel 2.6.24.3-12.fc8, 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.

Fixed in 2.6.24.3-26.

kernel-2.6.24.3-34.fc8 has been submitted as an update for Fedora 8

kernel-2.6.24.3-34.fc8 has been pushed to the Fedora 8 stable repository.  If problems still persist, please make note of it in this bug report.

Can confirm: kernel-2.6.24.3-34.fc8 is working (still, the baud rate restricted
as mentioned in comment #18). The bug should stay closed. Thank you all for the
help!