Hide Forgot
Description of problem: ark3116 driver crashes Version-Release number of selected component (if applicable): 2.6.23.1-21.fc7 (other kernels tested also, same problem every time) How reproducible: every time Steps to Reproduce: 1. plug in KQ-U8A USB cable 2. make sure ark3116 driver gets loaded 3. open /dev/ttyUSB0 with a terminal program like minicom Actual results: entire computer locks up tight with no kernel messages Expected results: communicate with cell phone modem: ATDT5551212, etc. Additional info: I have attempted without success to contact the author of the driver as listed in the source code and its web site. The author states on his web site that the driver will fail with SMP kernels. Since all the Fedora kernels are SMP now, the driver doesn't work at all on any platform. I have tested on a single processor i386 machine (Fedora 8) and a two-processor AMD Opteron machine (Fedora 7), same result both times. If you need a USB cable to duplicate the problem, please let me know, we can work something out. They are also available on eBay for very cheap.
I don't see why the priority and severity of this bug are set to low -- but I don't have access to change them. Severity should be set to urgent, and priority should be high. The crash happens for me too, every time, with a SIM card reader having ark3116. A simple command like "cat /dev/ttyUSB0" is enough to lock up the whole computer immediately. Nothing is printed to the console. I am using an AMD Sempron 2500+, which clearly does not have SMP capabilities, yet the standard F8 kernel might have. I booted my computer with Knoppix 5 Live DVD (kernel 2.6.19), and there was no crash. Also, I have successfully used ark3116 under FC5, and possibly also on F7. I suspect the problem is not in the ark3116 driver alone; I tried compiling and loading a separately distributed old version of ark3116, which I've successfully used many times before, and even with that the computer crashed immediately.
I am setting the Severity to urgent because of the previous post, it's nor urgent for me but apparently it is for others. I don't have access to the Priority field either. Hopefully someone will pay attention, I don't know what it takes to get something like this fixed. Normally I try to fix things myself and submit a patch, but I have no experience with kernel drivers. I also have a Fedora 8 PPC machine available for testing if necessary, but I haven't tried the USB cable with it yet.
Some more observations: I was not able to reproduce the bug under VMware, that is, F8 running under VMware on F8. I was also experimenting with the separately distributed, old driver (which may not be exactly like the one in Fedora), and was able to get some output on the console. The lock-up seems to happen within ark3116_open, somewhere after the call to usb_serial_generic_open() and before ark3116_set_termios(). However, there still were no error messages.
The priority field isn't really used in Fedora. However, I've set it :). Do you have a smolt profile of the hardware in question? I'm guessing that since the author of the driver states explicitly that it does not work with SMP kernels, there's little that we can do about this. You may want to try this with the kernel-debug kernel in order to get some more information about the lockup, though.
Wait. Are you saying that the driver has made it to the official kernel even if it is known to be broken enough to lock up the whole computer with all SMP kernels, even on a non-SMP computer? I refuse to believe that is the case... The only reference to SMP trouble I could find is http://avr.auctionant.de/ark3116_linux_driver/ , which has been written probably at least 2 years ago. The FAQ says: "I received reports that the driver causes a kernel ooops if running on x86 multiprocessor kernels (SMP) [...]". Occasional kernel oopses are quite different from the driver crashing the whole computer instantaneously every time. In my opinion, nobody has provided any proof so far that this problem is SMP-related at all. It might be, who knows, but let us not rule out other possiblities either.
I'm not saying that at all. I'm just a triager, not a developer - it's my job to ensure that developers get complete, useful bug reports that are actually bugs - i.e. something that is actionable. I figured that you had found some authoritative reference that the driver is busted under SMP upstream. If that were indeed the case, then there's little that we could do about it. I agree that a complete crash is not acceptable. Is the system locked up hard when this happens (press the caps lock key on the keyboard and see if the light changes color). Try to reproduce this under a kernel-debug kernel - there's not a whole heck of a lot to go on here. Also, try hooking up a serial console to catch any kernel messages prior to the crash. Thanks! -Jon
Appears to be fixed in Fedora 9 kernel 2.6.25.3-18, but I have not tested very much. Lauri Nurmi, does it work for you?
This message is a reminder that Fedora 8 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 8. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '8'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 8's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 8 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora please change the 'version' of this bug to the applicable version. If you are unable to change the version, please add a comment here and someone will do it for you. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Indeed no crash in Fedora 9. (Sorry for the very late reply, I did not have F9 installed when Fran asked.)
in that case, closing! :)