Re: USB kernel / udev issue with Palm Treo 700p

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