Description of problem:
ark3116 driver crashes
Version-Release number of selected component (if applicable):
126.96.36.199-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
entire computer locks up tight with no kernel messages
communicate with cell phone modem: ATDT5551212, etc.
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
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.
Appears to be fixed in Fedora 9 kernel 188.8.131.52-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:
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! :)