On 1 February 2007 at 10:20, Alan Stern wrote:
| On Wed, 31 Jan 2007, Dirk Eddelbuettel wrote:
|
| > Alan Stern <stern <at> rowland.harvard.edu> writes:
| > > In fact, it's possible that these problems are caused by bad USB cable
| > > connections. They certainly could result in intermittent disconnects.
| >
| > We tried two factory new cables that came with the two Palm 700p devices.
| > Also, once I modified the kernel (as suggested by Oliver) the issues went
| > away. So I'd be hesitant to blame the cable.
| >
| > > Is it possible that the changes in behavior you see are caused by changes
| > > in visor.c or pilot-xfer rather than by anything in the USB stack? The
| > > log does give the impression that the Treo has difficulty with some of the
| > > commands it receives. For instance, it died when it received this
| > > vendor-specific control-IN command: c2 02 0000 0000 0012. But it died at
| > > other times too.
| >
| > Well that's why I was hoping that the usb kernel hacker crowd would be in a
| > position to help. What would be the next step?
|
| >From your earlier comments, it's not entirely clear that turning off
| CONFIG_USB_SUSPEND really does solve the problem. You said that even then
| the device didn't work all the time.
|
| Try doing this: Use a kernel with CONFIG_USB_SUSPEND and CONFIG_USB_DEBUG
| turned on. Before plugging in the Treo, do "rmmod ohci-hcd". Then clear
| the kernel log buffer by doing "dmesg -c >/dev/null", plug in the device,
| and do "modprobe ohci-hcd". Post the resulting dmesg log so we can see
| what happens.
|
| Just for kicks, try doing exactly the same experiment over again, this
| time with a kernel that doesn't have CONFIG_USB_SUSPEND but is otherwise
| identical. The two dmesg logs shouldn't show any significant differences.
I think you may be right. The behaviour was not that different between the
twp variants of 2.6.18 I tried, one with and one without CONFIG_USB_SUSPEND
and CONFIG_USB_DEBUG.
In either case, it works if you do the following exactly as described:
1) Prepare the statement to be executed, in my case
pilot-xter -p /dev/ttyUSB1 -l
but do not yet press Enter
2) On the Palm Treo 700p, launch the HotSync and press the hotsync icon.
Wait until the 'Connecting with the desktop using Cradle/Cable' appears
3) Maybe a half-second or second after the text appears, hit Enter in the
shell prepared in 1). You will greeted with 'Connected' from pilot-xfer.
The last step also works if you hit enter a little too soon leading to 'no
device found' type error. Quick command-recall in bash and re-running the
command helped.
Each log hence shows the first failed attempt, the successful attempt as well
as a last (failed) attempt when pilot-xfer tries to access the PDA that is
not expecting a connection.
I hope all this helps. I purged ohci-hcd as suggested, flushed dmesg,
and reloaded the module and sent you the logs in a separate email.
Thanks for all the help.
Best regards, Dirk
--
Hell, there are no rules here - we're trying to accomplish something.
-- Thomas A. Edison
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier.
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel
