Re: Problems with file conduit and Treo 680

> I have the same timing issues with a Treo 700p, but
worse, because if I
> don't pause the gpilotd daemon before plugging in to
charge (no
> hotsync), it infinite-loops.  With pilot-xfer, I need
to hit hotsync 1-5
> seconds before running pilot-xfer.  This is with libusb
instead of
> visor, I can't get visor to work at all with the 700p.

Adam,

Do you get into an infinite loop if you start pilot-xfer
before plugging
in the 700p?  If not, we should try to find out how gpilotd
gets
stuck.  Have you tried attaching with gdb and seeing what
bit of code
it is in via a stack trace?

I guess the pilot-link people should try to see how they can
distinguish
the charging connection from a sync attempt...

Matt
_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list

On Sun, 2007-09-23 at 21:56 +0100, Matt Davey wrote:
> > I have the same timing issues with a Treo 700p,
but worse, because if I
> > don't pause the gpilotd daemon before plugging in
to charge (no
> > hotsync), it infinite-loops.  With pilot-xfer, I
need to hit hotsync 1-5
> > seconds before running pilot-xfer.  This is with
libusb instead of
> > visor, I can't get visor to work at all with the
700p.
> 
> Adam,
> 
> Do you get into an infinite loop if you start
pilot-xfer before plugging
> in the 700p?  If not, we should try to find out how
gpilotd gets
> stuck.  Have you tried attaching with gdb and seeing
what bit of code
> it is in via a stack trace?
> 
> I guess the pilot-link people should try to see how
they can distinguish
> the charging connection from a sync attempt...

Okay, with gpilotd and the applet dead, I run
"pilot-xfer -p usb: -l",
and strace (attached) gets to the "futex(...
NULL".  Then I hit hotsync
on the 700p, and pilot-xfer goes up to max CPU but with no
further
strace output.

Then I do "gdb pilot-xfer" and "run -p usb:
-l", wait a bit, and again
the pilot-xfer process goes to max CPU.  Hmm, oh well, no
debugging
symbols, this is Debian. :-(

I can try rebuilding pilot-link with dh_strip removed, but
don't have
time now.  Does the strace output help?

-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8
564E E4B6

Engineering consulting using open source tools
http://www.opennovation.
com/

_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list

On Sun, 2007-09-23 at 18:44 -0400, Adam C Powell IV wrote:
> Then I do "gdb pilot-xfer" and "run -p
usb: -l", wait a bit, and again
> the pilot-xfer process goes to max CPU.  Hmm, oh well,
no debugging
> symbols, this is Debian. :-(

> I can try rebuilding pilot-link with dh_strip removed,
but don't have
> time now.  Does the strace output help?

You're dealing with the latest pilot-link version in CVS,
yes? Because
there are quite a few post-release fixes that have been
dropped in that
may alleviate some of the issues you're seeing. 

As for the timing issue, that's a bit more complicated than
I think we
can solve entirely in userland. Since the physical device
presents
itself as a different entity on the usb subsystem before any
kernel
driver can be loaded (or not loaded), pilot-link has to just
wait until
something it understands (i.e. the visor driver, or the
right usb
interface presented via libusb) exists before it can
communicate with
it. 

If the device is sitting on the cable with a mount-point
mapped to it
(i.e. "Drive Mode" through uhci_hcd, for example,
vs. the visor driver),
there is little pilot-link can do to kick it out of drive
mode and put
it back into "I'm a Palm now" mode. 

It may be some magical (publicly undocumented, of course)
DLP command,
or it may be something much uglier (start the communication,
kill the
socket, try again)... I'm not really sure how this process
works on
Windows, because the USBport.dll file that contains this
info, does not
have any source available for me to look at, nor is this
information
covered in the Palm/ACCESS SDK that is available to
developers. 

It would be interesting though, to build the libusb support
in Cygwin
(or native libusb support in Windows), and try to get it
working in the
same way, to see if the timing issue is still a factor there
or not. 

Anyone with a Windows box and some good usb sniffer software
care to
take a whack at this? 


-- 
David A. Desrosiers
desrodgnu-designs.com
setuidgmail.com
http://projects.plkr.org/
Skype...: 860-967-3820

_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list

On Sun, 2007-09-23 at 22:20 -0400, David A. Desrosiers
wrote:
> On Sun, 2007-09-23 at 18:44 -0400, Adam C Powell IV
wrote:
> > Then I do "gdb pilot-xfer" and "run
-p usb: -l", wait a bit, and again
> > the pilot-xfer process goes to max CPU.  Hmm, oh
well, no debugging
> > symbols, this is Debian. :-(
> 
> > I can try rebuilding pilot-link with dh_strip
removed, but don't have
> > time now.  Does the strace output help?
> 
> You're dealing with the latest pilot-link version in
CVS, yes? Because
> there are quite a few post-release fixes that have been
dropped in that
> may alleviate some of the issues you're seeing.

No, an older version.  Thanks, I'll try CVS when I get a
chance.

> As for the timing issue, that's a bit more complicated
than I think we
> can solve entirely in userland. Since the physical
device presents
> itself as a different entity on the usb subsystem
before any kernel
> driver can be loaded (or not loaded), pilot-link has to
just wait until
> something it understands (i.e. the visor driver, or the
right usb
> interface presented via libusb) exists before it can
communicate with
> it.

Makes sense, though it seems there should be a way to poll
the USB
subsystem looking for a new connection which might be the
device.

> If the device is sitting on the cable with a
mount-point mapped to it
> (i.e. "Drive Mode" through uhci_hcd, for
example, vs. the visor driver),
> there is little pilot-link can do to kick it out of
drive mode and put
> it back into "I'm a Palm now" mode. 
> 
> It may be some magical (publicly undocumented, of
course) DLP command,
> or it may be something much uglier (start the
communication, kill the
> socket, try again)... I'm not really sure how this
process works on
> Windows, because the USBport.dll file that contains
this info, does not
> have any source available for me to look at, nor is
this information
> covered in the Palm/ACCESS SDK that is available to
developers. 
> 
> It would be interesting though, to build the libusb
support in Cygwin
> (or native libusb support in Windows), and try to get
it working in the
> same way, to see if the timing issue is still a factor
there or not. 
> 
> Anyone with a Windows box and some good usb sniffer
software care to
> take a whack at this?

My wife's box has the Palm Desktop and usb sniffer (used to
reverse
engineer file upload to an old camera with gphoto2).  When I
have time,
I'll sync to my box, hard reset, and try to catch some
sniffs of syncs
there.

Thanks,
-Adam
-- 
GPG fingerprint: D54D 1AEE B11C CE9B A02B  C5DD 526F 01E8
564E E4B6

Engineering consulting using open source tools
http://www.opennovation.
com/

_______________________________________________
gnome-pilot-list mailing list
gnome-pilot-listgnome.org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list