On Fri, Jul 23, 2004 at 09:38:19PM -0500, Lonnie Mendez wrote:
Try enabling USB Serial Converter verbose debug under USB Serial Converter support, along with USB verbose debug. Make note that the USB Serial Converter driver needs to be compiled into the kernel in order for the debugging option to show up in the kernel config menu.
That's because if you are building the drivers as a module, all you need to do is enable the debug option on the modprobe line like: modprobe usbserial debug=1 modprobe pl2303 debug=1
And now with the debugging. I'm *really* new to this code, but I got debugs in one window and code in another, and I *think* I kinda understand it... =)
I have a lot of:
Jul 23 22:14:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_write_room - port 0
Jul 23 22:14:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_write_room - returns 64
Jul 23 22:14:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_chars_in_buffer = port 0
Jul 23 22:14:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_chars_in_buffer - port 0
Jul 23 22:14:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_chars_in_buffer - returns 0
Which, while I'm unclear what "rooms" are, the usb_serial_generic_write_room actually appears to *read* a "room" from the port.
This returns 64 (the room?)...
But the troubling part is the usb_serial_generic_chars_in_buffer which ALWAYS returns 0. Unless I'm mistaken, usb_serial_generic_chars_in_buffer() simply checks the buffer for bytes transfered from the phone (which I guess would be waiting in some USB buffer somewhere).
So that always being 0 would mean the phone is not sending/receiving info.
The connection usually finally ends with:
in_buffer - returns 0
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_break - port 0
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_break - port 0
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5402
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_set_termios - port 0
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_ioctl - port 0, cmd 0x5401
Jul 23 22:17:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_close - port 0
The serial_break function appears to send a break, so I'm guessing that the application has given up and requested to close the connection.
Now the interesting thing is that an initial connection is definitely made (the phone wakes up and says it's syncing) as you can see here:
Jul 23 22:10:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_open
Jul 23 22:10:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_ioctl - port 0,
cmd 0x5401
......SNIP OTHER CMDS......
Jul 23 22:10:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_write - port 0,
4 byte(s)
Jul 23 22:10:16 rider kernel: drivers/usb/serial/usb-serial.c: serial_chars_in_buffer
= port 0
Jul 23 22:10:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_chars_
in_buffer - port 0
Jul 23 22:10:16 rider kernel: drivers/usb/serial/generic.c: usb_serial_generic_chars_
in_buffer - returns 4
So it successfully reads and writes -- and then boom, can't do it anymore. Now it is also note worthy it can often take 2 or 3 tries to get the connection started... but 1 in 3 is a lot different from the hundreds of reads tried when the connection dies in the middle (otherwise I'd suspect the cable -- and I somewhat do, but since its new, I'm trying to keep my mind open).
Thoughts, comments, etc., appreciated.
-- Phil Dibowitz [EMAIL PROTECTED] Freeware and Technical Pages Insanity Palace of Metallica http://www.phildev.net/ http://www.ipom.com/
"They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." - Benjamin Franklin, 1759
signature.asc
Description: OpenPGP digital signature
