Bug 73556 - Keyspan firmware for USA-19Q and USA-19QW not included
Keyspan firmware for USA-19Q and USA-19QW not included
Status: CLOSED WORKSFORME
Product: Red Hat Linux
Classification: Retired
Component: kernel (Show other bugs)
8.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Pete Zaitcev
Brian Brock
http://www.keyspan.com/support/linux/
: FutureFeature
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-09-05 22:49 EDT by Kent Pirkle
Modified: 2007-04-18 12:46 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2003-02-21 19:55:00 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
ksymoops output of khubd module segfault after unplugging keyspan (4.78 KB, text/plain)
2002-09-17 14:13 EDT, Tom Wood
no flags Details

  None (edit)
Description Kent Pirkle 2002-09-05 22:49:23 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 Galeon/1.2.5 (X11; Linux i686; U;) Gecko/0

Description of problem:
Keyspan released the updated firmware for their USB-to-Serial adaptors several
months ago. They have been accepted in the development kernel but are not in the
2.4 series, thus users have to recompile the kernel to add these to the system.
It would be very nice if that wasn't necessary for the new Redhat release.

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


How reproducible:
Always

Steps to Reproduce:
1. Insert keyspan adaptor, dmesg says no driver found for this device.
2.
3.
	

Additional info:
Comment 1 Tom Wood 2002-09-17 14:11:39 EDT
Same problem here with a Keyspan USA49W.  As best I can tell, the switch block
in linux/drivers/usb/seriall/keyspan.c starting at line 985 isn't working as it
should.

Also, unplugging the device from the USB bus causes a oops in the khubd process.
 I'll attach the ksymoops, even though it complains about not finding ext3 and
jbd modules.  I've explicitly pathed ksymoops and it doesn't help.  Is this a
bug?  bugzilla shows nothing against ksymoops.
Comment 2 Tom Wood 2002-09-17 14:13:03 EDT
Created attachment 76424 [details]
ksymoops output of khubd module segfault after unplugging keyspan
Comment 3 Tom Wood 2002-09-17 14:16:15 EDT
One further note.  My problems are on RH 7.3, not null.

I'm not sure that the "new firmware" issue is the problem for a USA49W.  It's
just not seeing it compiled in.  And selecting it in the kernel config file
doesn't help.
Comment 4 Pete Zaitcev 2002-09-17 16:03:37 EDT
Requestors should file separate bugs for separate problems.
I do not see how the khubd oops has anything to do with
missing firmare for USA-19Q.
Comment 5 Tom Wood 2002-09-18 15:21:30 EDT
The khubd issue is related from the standpoint that when a 
Keyspan box is unplugged from the USB bus, it generates a oops.  
This only occurs when keyspan.o is loaded.  Since keyspan.o is 
the culprit here, I thought it useful to include this info here 
to make the general case that the keyspan.o is broken in 
several ways, not just missing firmware. 
 
I will file this as a separate bug.
Comment 6 Pete Zaitcev 2002-09-20 01:48:01 EDT
With the 49W out of the picture we start to make progress.

CVS:
milan  >2.4.18-14c
Comment 7 Kent Pirkle 2002-10-17 17:16:53 EDT
I see that the firmware update made it into the latest kernel. Unfortunately, it
doesn't work. I got the same results with a custom recompile of the stock RHL
8.0 kernel. I have opened a bug report with Keyspan. The following is the dmesg
output I get when I plug in my USA-19QA USB to serial adaptor:

usb.c: registered new driver serial
usbserial.c: USB Serial support registered for Generic
usbserial.c: USB Serial Driver core v1.4
usbserial.c: USB Serial support registered for Keyspan USA18X - (without firmwar
e)
usbserial.c: USB Serial support registered for Keyspan USA19 - (without firmware
)
usbserial.c: USB Serial support registered for Keyspan USA19QI - (without firmwa
re)
usbserial.c: USB Serial support registered for Keyspan USA19QW - (without firmwa
re)
usbserial.c: Keyspan USA19QW - (without firmware) converter detected
usbserial.c: USB Serial support registered for Keyspan USA19W - (without firmwar
e)
usbserial.c: USB Serial support registered for Keyspan USA28 - (without firmware
)
usbserial.c: USB Serial support registered for Keyspan USA28X - (without firmwar
e)
usbserial.c: USB Serial support registered for Keyspan USA28XA - (without firmwa
re)
usbserial.c: USB Serial support registered for Keyspan USA28XB - (without firmwa
re)
usbserial.c: USB Serial support registered for Keyspan USA49W - (without firmwar
e)
usbserial.c: USB Serial support registered for Keyspan USA18X
usbserial.c: USB Serial support registered for Keyspan USA19
usbserial.c: USB Serial support registered for Keyspan USA19QI
usbserial.c: USB Serial support registered for Keyspan USA19QW
usbserial.c: USB Serial support registered for Keyspan USA19W
usbserial.c: USB Serial support registered for Keyspan USA28
usbserial.c: USB Serial support registered for Keyspan USA28X/XB
usbserial.c: USB Serial support registered for Keyspan USA28XA
usbserial.c: USB Serial support registered for Keyspan USA49W
keyspan.c: v1.1.1:Keyspan USB to Serial Converter Driver
usb.c: USB disconnect on device 3
Unable to handle kernel NULL pointer dereference at virtual address 00000000
 printing eip:
c011909c
*pde = 00000000
Oops: 0002
keyspan usbserial CDCEther acm vmnet vmmon cisco_ipsec sr_mod cmpci soundcore
CPU:    0
EIP:    0010:[<c011909c>]    Tainted: PF
EFLAGS: 00010002

EIP is at add_wait_queue_exclusive [kernel] 0x1c (2.4.18-17.8.0)
eax: d9c10c80   ebx: 00000000   ecx: dfa0dee4   edx: dfa0dedc
esi: 00000202   edi: d9c10c80   ebp: dfa0dedc   esp: dfa0ded0
ds: 0018   es: 0018   ss: 0018
Process khubd (pid: 68, stackpage=dfa0d000)
Stack: d9c10c78 dfa0c000 c0107c51 00000001 dfa0c000 d9c10c80 00000000 e1c7151c
       00000000 d9c10c00 db894900 c0107dd4 d9c10c78 d9c10c00 d9c10c00 e1c6f51f
       00000004 00100002 00000100 e1c7151c e1c71500 00000000 e083016f d9a93000
Call Trace: [<c0107c51>] __down [kernel] 0x41 (0xdfa0ded8))
[<e1c7151c>] usb_serial_driver [usbserial] 0x1c (0xdfa0deec))
[<c0107dd4>] __down_failed [kernel] 0x8 (0xdfa0defc))
[<e1c6f51f>] .text.lock.usbserial [usbserial] 0x2d (0xdfa0df0c))
[<e1c7151c>] usb_serial_driver [usbserial] 0x1c (0xdfa0df1c))
[<e1c71500>] usb_serial_driver [usbserial] 0x0 (0xdfa0df20))
[<e083016f>] usb_disconnect_Re906e30a [usbcore] 0x8f (0xdfa0df28))
[<e08330f8>] usb_hub_port_connect_change [usbcore] 0x398 (0xdfa0df4c))
[<e08329fc>] usb_hub_port_status [usbcore] 0x6c (0xdfa0df6c))
[<e08333b2>] usb_hub_events [usbcore] 0x2b2 (0xdfa0df8c))
[<e0833445>] usb_hub_thread [usbcore] 0x45 (0xdfa0dfbc))
[<c01090c4>] ret_from_fork [kernel] 0x0 (0xdfa0dfc0))
[<e0840800>] khubd_wait [usbcore] 0x0 (0xdfa0dfd8))
[<e0840800>] khubd_wait [usbcore] 0x0 (0xdfa0dfdc))
[<c010745e>] kernel_thread [kernel] 0x2e (0xdfa0dff0))
[<e0833400>] usb_hub_thread [usbcore] 0x0 (0xdfa0dff8))


Code: 89 0b 89 59 04 56 9d 8b 1c 24 8b 74 24 04 83 c4 08 c3 89 f6
 <4>usb-uhci.c: interrupt, status 2, frame# 15
usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -84
usbdevfs: USBDEVFS_CONTROL failed dev 3 rqt 128 rq 6 len 18 ret -84
Comment 8 Kent Pirkle 2002-10-17 17:17:55 EDT
BTW - by custom recompile I mean recompiling the stock 8.0 kernel with the
addition of the Keyspan firmware.
Comment 9 Pete Zaitcev 2002-11-26 17:48:35 EST
OK. Now I realize that Tom's problem is different, but I already
allowed him to hijack the bug. Reinstating into assigned.
Comment 10 Pete Zaitcev 2002-11-26 18:02:37 EST
See also bz#76473: the oops bug.
Comment 11 Gregory Payne 2002-11-27 13:07:19 EST
Just to add some more info - I have a USA49W with RH8.0.  I recompiled the stock
source (with the firmware option selected).  After powering down and restarting,
I got similar error messages.  After rebooting from that point, it worked fine.
 This seems to be a pattern for me - first bootup after power-on doesn't work,
second (after reboot) works fine.  By not working, I mean only the serial
convertor - the rest of Linux is fine.
Comment 12 Pete Zaitcev 2002-11-29 18:11:28 EST
49W added
CVS milan >2.4.18-19

Also fixed-in-Rawhide (actually Marcelo 2.4.20 kernel has it right upstream).
Comment 13 Kent Pirkle 2002-12-28 13:03:43 EST
I've had a chance to test the new kernel 2.4.18-19.8.0. It appears that
everything loads correctly, there is no more kernel oops. The keyspan adaptor
appears to work, the led flashes. Except...when I use minicom to connect to
another Red Hat box as a serial console, I get some text and a lot of garbage. I
have the same results with an external modem. When I boot to the vanilla kernel
2.4.19 I compiled with the firmware, it works perfectly with the same com port
settings. 
Comment 14 Kent Pirkle 2003-02-21 19:55:00 EST
This bug appears to be fixed in the kernel that comes with Phoebe beta 3. 

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