Hello,
I recently got the idea in my head to actually try to sync Evolution
with my Clie's addressbook. Previously I had been using pilot-xfer to
do data backup and transfer of PDBs without a hitch on 2.4.20.
Everything seems to work OK for a little while, and if I insmod the
visor module in debug mode I can see that the bulk messages are moving.
Then, after an indeterminate but short time, it appears to hang up.
Note the difference in timestamps. Now, I'm not sure if this is
gnome-pilot/evolution hanging up, or what. But that shouldn't cause the
oops that follows...
Sep 3 10:17:22 aluminum kernel: visor.c: visor_write_room - returns
18432
Sep 3 10:18:24 aluminum kernel: host/usb-uhci.c: interrupt, status 3,
frame# 1021
Sep 3 10:18:24 aluminum kernel: visor.c: visor_read_bulk_callback -
port 1
According to the urb status code received in visor_read_bulk_callback
(line 607), the error (-EILSEQ) is supposed to mean a CRC error (this is
according to the documentation in linux/Documentation/usb). I added
some debug messages to the visor module -- no actual logic changed (I
swear). Here is the output in syslog:
Sep 3 10:18:24 aluminum kernel: usb.c: USB disconnect on device
00:09.1-1 address 3
Sep 3 10:18:24 aluminum kernel: visor.c: visor_close - port 1
Sep 3 10:18:24 aluminum kernel: visor.c: visor_close - attempting to
unlink urbs. port is d528bc88
Sep 3 10:18:24 aluminum kernel: visor.c: visor_close - sending shutdown
messageSep 3 10:18:24 aluminum kernel: visor.c: Bytes In = 10775 Bytes
Out = 2272
Sep 3 10:18:24 aluminum kernel: Unable to handle kernel NULL pointer
dereference at virtual address 00000998
Sep 3 10:18:24 aluminum kernel: printing eip:
Sep 3 10:18:24 aluminum kernel: e1da326a
Oops follows:
Unable to handle kernel NULL pointer dereference at virtual address
00000998
printing eip:
e1da326a
*pde = 00000000
Oops: 0002
CPU: 0
EIP: 0010:[<e1da326a>] Tainted: P
EFLAGS: 00010246
eax: 00000000 ebx: d528bc6c ecx: dfd7402c edx: ddc3df7c
esi: d528bc88 edi: 00000001 ebp: d528bc00 esp: dfd75f18
ds: 0018 es: 0018 ss: 0018
Process khubd (pid: 7, stackpage=dfd75000)
Stack: d528bc88 00000000 00000010 e1da4640 e1da4620 00000000 d682ff00
c02512e4
d98f5e00 d528bc00 d98f5e04 00000003 00000000 d98f5e00 00000100
0000000a
dfdd7c00 00000000 c025414f dfdd7d0c 00000001 00000010 d682f7c0
c0253bac
Call Trace: [<e1da4640>] [<e1da4620>] [<c02512e4>] [<c025414f>]
[<c0253bac>]
[<c0254438>] [<c02544c6>] [<c0254490>] [<c0105000>] [<c010572e>]
[<c0254490>]
Code: c7 80 98 09 00 00 00 00 00 00 8d 4e 58 ff 43 74 0f 8e 6f 05
and ksymoops says:
>>EIP; e1da326a <[usbserial]usb_serial_disconnect+6a/250> <=====
>>ebx; d528bc6c <_end+14ec61e8/206f85fc>
>>ecx; dfd7402c <_end+1f9ae5a8/206f85fc>
>>edx; ddc3df7c <_end+1d8784f8/206f85fc>
>>esi; d528bc88 <_end+14ec6204/206f85fc>
>>ebp; d528bc00 <_end+14ec617c/206f85fc>
>>esp; dfd75f18 <_end+1f9b0494/206f85fc>
Trace; e1da4640 <[usbserial]usb_serial_driver+20/23>
Trace; e1da4620 <[usbserial]__module_description+0/0>
Trace; c02512e4 <usb_disconnect+94/160>
Trace; c025414f <usb_hub_port_connect_change+26f/280>
Trace; c0253bac <usb_hub_port_status+6c/a0>
Trace; c0254438 <usb_hub_events+2d8/330>
Trace; c02544c6 <usb_hub_thread+36/c0>
Trace; c0254490 <usb_hub_thread+0/c0>
Trace; c0105000 <_stext+0/0>
Trace; c010572e <arch_kernel_thread+2e/40>
Trace; c0254490 <usb_hub_thread+0/c0>
Code; e1da326a <[usbserial]usb_serial_disconnect+6a/250>
00000000 <_EIP>:
Code; e1da326a <[usbserial]usb_serial_disconnect+6a/250> <=====
0: c7 80 98 09 00 00 00 movl $0x0,0x998(%eax) <=====
Code; e1da3271 <[usbserial]usb_serial_disconnect+71/250>
7: 00 00 00
Code; e1da3274 <[usbserial]usb_serial_disconnect+74/250>
a: 8d 4e 58 lea 0x58(%esi),%ecx
Code; e1da3277 <[usbserial]usb_serial_disconnect+77/250>
d: ff 43 74 incl 0x74(%ebx)
Code; e1da327a <[usbserial]usb_serial_disconnect+7a/250>
10: 0f 8e 6f 05 00 00 jle 585 <_EIP+0x585>
1 warning issued. Results may not be reliable.
There are probably multiple issues here -- it should not be oopsing, but
why is it timing out in the first place?
This is the result with 2.4.22-ac1; I have _not_ tried with virgin
2.4.22 but the visor.c and usbserial.c code is identical between them.
It oopsed in a similar place with 2.4.20. pilot-xfer works fine with
all kernels I've tried. I've changed the data rate in the gnome-pilot
config to every possible value (and I note that 115200 isn't an option
in there).
Help? Please?
-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
_______________________________________________
[EMAIL PROTECTED]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-users
