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 _______________________________________________ linux-usb-devel@lists.sourceforge.net To unsubscribe, use the last form field at: https://lists.sourceforge.net/lists/listinfo/linux-usb-devel