Hi,
I've encountered an oops while using the generic usbserial driver to talk
to a USB device[1] I'm building. I need some help to determine if it's
my fault (I'm just beginning to learn about USB) or a bug on the driver side.
I'm using a 2.4.18 kernel with the preempt_kernel patch, usb-uhci and usbserial
loaded as modules. Apart from the single device, there's nothing on the USB.
The device (EzUSB/AN2131SC based) at the moment just outputs a "hello, world"
message on one of its bulk endpoints.
After loading the usbserial module, giving it my device's vendor and product
IDs, I run 'cat /dev/ttyUSB0'; this correctly displays the message stream.
When I hit CTRL-C, I get an oops. The machine locks up solid, so I had to
copy the message by hand; here's what I have:
> ksymoops 2.3.4 on i686 2.4.18. Options used
> -V (default)
> -k /proc/ksyms (default)
> -l /proc/modules (default)
> -o /lib/modules/2.4.18/ (default)
> -m /boot/System.map-2.4.18 (default)
>
> Warning: You did not tell me where to find symbol information. I will
> assume that the log matches the kernel and modules that are running
> right now and I'll use the default options above for symbol resolution.
> If the current kernel and/or modules do not match the log, you can get
> more accurate output by telling me the kernel version and where to find
> map, modules, ksyms etc. ksymoops -h explains the options.
>
> EIP: <e087636d>
> Using defaults from ksymoops -t elf32-i386 -a i386
> Trace: <e0876a24> <e0876d4a> <c1018a74> <c0108cb5> <c01051e0>
> <c010b0e3> <c01051e0> <c01051e0> <c010520c> <c0105272> <c0119aa6>
> <c0119964>
> Code: 8b 2c 90 8b 44 24 28 c1 e9 08 83 e1 0f d3 ed 83 e5 01 c7 44
>
> >>EIP; e087636d <[usb-uhci]process_transfer+51/2e0> <=====
> Trace; e0876a24 <[usb-uhci]process_urb+58/294>
> Trace; e0876d4a <[usb-uhci]uhci_interrupt+ea/168>
> Trace; c1018a74 <_end+ce4a28/20530014>
> Trace; c0108cb5 <do_IRQ+bd/128>
> Trace; c01051e0 <default_idle+0/34>
> Trace; c010b0e3 <call_do_IRQ+5/a>
> Trace; c01051e0 <default_idle+0/34>
> Trace; c01051e0 <default_idle+0/34>
> Trace; c010520c <default_idle+2c/34>
> Trace; c0105272 <cpu_idle+3e/54>
> Trace; c0119aa6 <release_console_sem+da/e0>
> Trace; c0119964 <printk+144/170>
> Code; e087636d <[usb-uhci]process_transfer+51/2e0>
> 00000000 <_EIP>:
> Code; e087636d <[usb-uhci]process_transfer+51/2e0> <=====
> 0: 8b 2c 90 mov (%eax,%edx,4),%ebp <=====
> Code; e0876370 <[usb-uhci]process_transfer+54/2e0>
> 3: 8b 44 24 28 mov 0x28(%esp,1),%eax
> Code; e0876374 <[usb-uhci]process_transfer+58/2e0>
> 7: c1 e9 08 shr $0x8,%ecx
> Code; e0876377 <[usb-uhci]process_transfer+5b/2e0>
> a: 83 e1 0f and $0xf,%ecx
> Code; e087637a <[usb-uhci]process_transfer+5e/2e0>
> d: d3 ed shr %cl,%ebp
> Code; e087637c <[usb-uhci]process_transfer+60/2e0>
> f: 83 e5 01 and $0x1,%ebp
> Code; e087637f <[usb-uhci]process_transfer+63/2e0>
> 12: c7 44 00 00 00 00 00 movl $0x0,0x0(%eax,%eax,1)
> Code; e0876386 <[usb-uhci]process_transfer+6a/2e0>
> 19: 00
>
>
> 1 warning issued. Results may not be reliable.
This seems to be very reproducible; the error is always a null pointer
dereference at 0x0000002c, but in varying processes (it occurs during an
interrupt, as far as I can tell).
I haven't yet tried to use the other UHCI driver to see if the problem
persists.
Greetings,
Jens.
[1] Just an EzUSB module with some blinkenlights, buttons, and dials;
I'm using it to revive a piece of obsolete hardware, and it probably
won't ever be of interest to somebody else.
--
mailto:[EMAIL PROTECTED] phone:+49-7031-464-7698 (TELNET 778-7698)
http://www.bawue.de/~jjk/ fax:+49-7031-464-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
