Bug 113700

Summary: usb: unable to handle kernel paging request
Product: [Retired] Red Hat Raw Hide Reporter: Kaj J. Niemi <kajtzu>
Component: kernelAssignee: Pete Zaitcev <zaitcev>
Status: CLOSED RAWHIDE QA Contact: Brian Brock <bbrock>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0   
Target Milestone: ---   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2004-03-09 23:19:21 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
Test fix 1
none
Test fix 1a none

Description Kaj J. Niemi 2004-01-16 17:22:55 UTC
Description of problem:
kernel prints "Unable to handle kernel paging request at virtual
address" when disconnecting usb<->rs232 cable from laptop.

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

How reproducible:
Always

Steps to Reproduce:
1. plug the usb <-> rs232 cable in
2. minicom
3. remove the usb cable while minicom is still open
4. take a look at the logs
  
Actual results:
Jan 16 17:15:05 d100 kernel: hub 3-0:1.0: new USB device on port 2,
assigned address 4
Jan 16 17:15:06 d100 kernel: usbserial 3-2:1.0: Magic Control
Technology USB-RS232 converter detected
Jan 16 17:15:06 d100 kernel: usb 3-2: Magic Control Technology
USB-RS232 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Jan 16 17:16:42 d100 kernel: usb 3-2: USB disconnect, address 4
Jan 16 17:16:42 d100 kernel: mct_u232 ttyUSB0: Magic Control
Technology USB-RS232 converter now disconnected from ttyUSB0
Jan 16 17:16:42 d100 kernel: Unable to handle kernel paging request at
virtual address 6b6b6c4b
Jan 16 17:16:42 d100 kernel:  printing eip:
Jan 16 17:16:42 d100 kernel: fccaa5d2
Jan 16 17:16:42 d100 kernel: *pde = 00000000
Jan 16 17:16:42 d100 kernel: Oops: 0000 [#2]
Jan 16 17:16:42 d100 kernel: CPU:    0
Jan 16 17:16:42 d100 kernel: EIP:    0060:[<fccaa5d2>]    Not tainted
Jan 16 17:16:42 d100 kernel: EFLAGS: 00010202
Jan 16 17:16:42 d100 kernel: EIP is at usb_unlink_urb+0x12/0x40 [usbcore]
Jan 16 17:16:42 d100 kernel: eax: 6b6b6b6b   ebx: ee10c104   ecx:
00000002   edx: caa05a50
Jan 16 17:16:42 d100 kernel: esi: 00000001   edi: f5978104   ebp:
00000000   esp: f6dc9e58
Jan 16 17:16:42 d100 kernel: ds: 007b   es: 007b   ss: 0068
Jan 16 17:16:42 d100 kernel: Process khubd (pid: 104,
threadinfo=f6dc8000 task=f6db2940)
Jan 16 17:16:42 d100 kernel: Stack: 00000000 fce662a8 caa05a50
eebbe5b4 c019e1d1 f5978140 f5978140 fce6bce8
Jan 16 17:16:42 d100 kernel:        00000000 c02005d8 f5978140
f54945d4 f5978104 f54945c0 eebbe5b4 fce67208
Jan 16 17:16:42 d100 kernel:        f5978140 00000002 f54945c0
f54945c0 fce6bc40 f54945d4 fcca3117 f54945c0
Jan 16 17:16:42 d100 kernel: Call Trace:
Jan 16 17:16:42 d100 kernel:  [<fce662a8>] destroy_serial+0x108/0x190
[usbserial]
Jan 16 17:16:42 d100 kernel:  [<c019e1d1>] destroy_inode+0x61/0x70
Jan 16 17:16:42 d100 kernel:  [<c02005d8>] kobject_cleanup+0x98/0xa0
Jan 16 17:16:42 d100 kernel:  [<fce67208>]
usb_serial_disconnect+0x38/0x90 [usbserial]
Jan 16 17:16:42 d100 kernel:  [<fcca3117>]
usb_unbind_interface+0x77/0x80 [usbcore]
Jan 16 17:16:42 d100 kernel:  [<c0264d86>] device_release_driver+0x66/0x70
Jan 16 17:16:42 d100 kernel:  [<c0264f1a>] bus_remove_device+0x7a/0xc0
Jan 16 17:16:42 d100 kernel:  [<c0263c6d>] device_del+0x6d/0xb0
Jan 16 17:16:42 d100 kernel:  [<fccab930>]
usb_disable_device+0x70/0xb0 [usbcore]
Jan 16 17:16:42 d100 kernel:  [<fcca3ca4>] usb_disconnect+0xc4/0x120
[usbcore]
Jan 16 17:16:42 d100 kernel:  [<fcca6e81>]
hub_port_connect_change+0x331/0x340 [usbcore]
Jan 16 17:16:42 d100 kernel:  [<fcca6773>] hub_port_status+0x43/0xb0
[usbcore]
Jan 16 17:16:42 d100 kernel:  [<fcca71ea>] hub_events+0x35a/0x4d0
[usbcore]
Jan 16 17:16:42 d100 kernel:  [<fcca7395>] hub_thread+0x35/0x100 [usbcore]
Jan 16 17:16:42 d100 kernel:  [<c010c642>] ret_from_fork+0x6/0x14
Jan 16 17:16:42 d100 kernel:  [<c0124d40>] default_wake_function+0x0/0x20
Jan 16 17:16:42 d100 kernel:  [<fcca7360>] hub_thread+0x0/0x100 [usbcore]
Jan 16 17:16:42 d100 kernel:  [<c01092a5>] kernel_thread_helper+0x5/0x10
Jan 16 17:16:42 d100 kernel:
Jan 16 17:16:42 d100 kernel: Code: 8b 80 e0 00 00 00 85 c0 74 14 8b 40
20 85 c0 75 14 8d b6 00


Expected results:
Shouldn't happen.

Comment 1 Pete Zaitcev 2004-01-18 08:38:05 UTC
Created attachment 97080 [details]
Test fix 1

Comment 2 Kaj J. Niemi 2004-01-18 13:55:39 UTC
Thanks, I'll build 2.6.1-1.47 with the patch and will let you know the
end result.



Comment 3 Kaj J. Niemi 2004-01-19 09:22:07 UTC
Works for me. Now unplugging and replugging while in use results in
the creation of a device with a higher number (eg 1st is ttyUSB0,
after replug ttyUSB1). No oopses anymore.

Jan 19 11:04:24 d106 kernel: hub 3-0:1.0: new USB device on port 2,
assigned address 2
Jan 19 11:04:25 d106 kernel: drivers/usb/serial/usb-serial.c: USB
Serial support registered for Generic
Jan 19 11:04:25 d106 kernel: drivers/usb/core/usb.c: registered new
driver usbserial
Jan 19 11:04:25 d106 kernel: drivers/usb/serial/usb-serial.c: USB
Serial Driver core v2.0
Jan 19 11:04:25 d106 kernel: drivers/usb/serial/usb-serial.c: USB
Serial support registered for Magic Control Technology USB-RS232
Jan 19 11:04:25 d106 kernel: mct_u232 3-2:1.0: Magic Control
Technology USB-RS232 converter detected
Jan 19 11:04:25 d106 kernel: usb 3-2: Magic Control Technology
USB-RS232 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Jan 19 11:04:25 d106 kernel: drivers/usb/core/usb.c: registered new
driver mct_u232
Jan 19 11:04:25 d106 kernel: drivers/usb/serial/mct_u232.c: Magic
Control Technology USB-RS232 converter driver v1.2
Jan 19 11:04:46 d106 kernel: usb 3-2: USB disconnect, address 2
Jan 19 11:04:46 d106 kernel: mct_u232 3-2:1.0: device disconnected
Jan 19 11:04:47 d106 kernel: updfstab: numerical sysctl 1 23 is obsolete.
Jan 19 11:05:05 d106 kernel: hub 3-0:1.0: new USB device on port 2,
assigned address 3
Jan 19 11:05:05 d106 kernel: usbserial 3-2:1.0: Magic Control
Technology USB-RS232 converter detected
Jan 19 11:05:05 d106 kernel: usb 3-2: Magic Control Technology
USB-RS232 converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
Jan 19 11:05:45 d106 kernel: drivers/usb/serial/mct_u232.c: Set MODEM
CTRL 0xb failed (error = -19)
Jan 19 11:05:45 d106 kernel: drivers/usb/serial/mct_u232.c: Set MODEM
CTRL 0xb failed (error = -19)
Jan 19 11:05:45 d106 kernel: mct_u232 ttyUSB0: Magic Control
Technology USB-RS232 converter now disconnected from ttyUSB0
Jan 19 11:06:02 d106 kernel: usb 3-2: USB disconnect, address 3
Jan 19 11:06:02 d106 kernel: mct_u232 ttyUSB1: Magic Control
Technology USB-RS232 converter now disconnected from ttyUSB1
Jan 19 11:06:02 d106 kernel: usbserial 3-2:1.0: device disconnected
Jan 19 11:06:02 d106 kernel: updfstab: numerical sysctl 1 23 is obsolete.
Jan 19 11:06:08 d106 kernel: hub 3-0:1.0: new USB device on port 2,
assigned address 4
Jan 19 11:06:08 d106 kernel: usbserial 3-2:1.0: Magic Control
Technology USB-RS232 converter detected
Jan 19 11:06:08 d106 kernel: usb 3-2: Magic Control Technology
USB-RS232 converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Jan 19 11:06:11 d106 kernel: usb 3-2: USB disconnect, address 4
Jan 19 11:06:11 d106 kernel: mct_u232 ttyUSB0: Magic Control
Technology USB-RS232 converter now disconnected from ttyUSB0
Jan 19 11:06:11 d106 kernel: usbserial 3-2:1.0: device disconnected
Jan 19 11:06:11 d106 kernel: updfstab: numerical sysctl 1 23 is obsolete.


Comment 4 Pete Zaitcev 2004-01-20 01:51:58 UTC
Created attachment 97118 [details]
Test fix 1a

Comment 5 Pete Zaitcev 2004-01-20 01:53:56 UTC
Dunno what to do about ttyUSB1, it probably comes from the fake port
which the software latches. The only way is to make the application
not to scan ports, for now.


Comment 6 Kaj J. Niemi 2004-01-20 02:06:37 UTC
I'll rebuild and let you know what happens in the morning. I'm going
to include test fix 2 from bug #112889 as well in the build.

the ttyUSB1 issue probably doesn't matter as once the port is released
it reverts to ttyUSB0 I think?

Comment 7 Pete Zaitcev 2004-01-20 02:33:45 UTC
I don't think ttyUSB1 is actually functional, even though present.
It's a problem with applications which scan for a next port.
I do not have a solution.


Comment 8 Kaj J. Niemi 2004-01-20 10:36:07 UTC
Both patches seem to work although I should learn to pay attention to
what I type ;)



Comment 9 Pete Zaitcev 2004-03-09 23:19:21 UTC
Verified in 2.6.3-2.1.153