Re: z22 F7 problem



Here are the summary of the results from my experiments so far with much assistance with a very helpful person on the IRC channel:

We tried to use the pilot-xfer program and was able to successfully sync using the pilot-xfer command directly one time only:

pilot-xfer -p /dev/pilot -b /tmp/$$

But upon subsequent tries, was unable to get even that command to sync.

We also tried changing the transfer rate inside gpilotd-control-applet to match the rate of the Treo 650, but that did not yield any success.

We tried increasing and decreasing the transfer rate, but that did not yield success either. 

The interesting thing is that we saw this sort of strange output with suspicious "Using net TRUE" lines from gpilotd:

$ : /usr/libexec/gpilotd
gpilotd-Message: gnome-pilot 2.0.15 starting...
gpilotd-Message: compiled for pilot-link version 0.12.1
gpilotd-Message: compiled with [VFS] [USB] [IrDA] [Network]
gpilotd-Message: Activating CORBA server
gpilotd-Message: bonobo_activation_active_server_register = 0
gpilotd-Message: Watching Cradle (/dev/pilot)
gpilotd-Message: Found 4766, 0001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0502, 0736
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 091e, 0004
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 115e, f100
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 082d, 0100
gpilotd-Message: Using net FALSE
gpilotd-Message: Found 082d, 0200
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 082d, 0300
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0061
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0c88, 0021
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0002
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0003
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0020
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0031
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0040
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0050
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0060
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0061
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0070
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 0830, 0080
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 04e8, 8001
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 04e8, 6601
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0038
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0066
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0095
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 009a
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00c9
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00da
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 00e9
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0144
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 054c, 0169
gpilotd-Message: Using net TRUE
gpilotd-Message: Found 12ef, 0100
gpilotd-Message: Using net TRUE

What is suspicious is that this is a USB connection, but the gpilotd is emitting these messages about "net". (Note to those trying to reproduce this: The gpilotd-config-applet program will start another instance of gpilotd, so that must be killed when running gpilotd manually in a terminal window).

I had the udev rule incorrect in my /etc/udev/rules.d/10-custom.rules file. I originally had this:

BUS=="usb", SYSFS{product}=="Palm Handheld*", KERNEL=="ttyUSB[13579]", SYMLINK+="pilot", MODE="0666"

But replaced it with this:

BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *", KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb", MODE="0666"

And restarted udev with

/etc/rc.d/udev restart

We also found that the Treo 650 info was missing from /usr/share/gnome-pilot/devices.xml and had to be added. The chunk of text to add to that file was:

 <!-- Handspring Treo 650 -->
 <device vendor_id="0830" product_id="0061" />

At one point we tried an experiment: We changed "Cradle type" in the gpilotd-control-applet device settings from USB to Serial, and kept hitting the sync button, and one time it did seem to trick out gpilotd into sensing the device and starting the sync process correctly.  But I could not reproduce that result subsequently.

For reference, here is the section of /proc/bus/usb/devices 3 seconds after hitting the sync button on the USB cable:

T:  Bus=01 Lev=01 Prnt=01 Port=03 Cnt=01 Dev#=  8 Spd=12  MxCh= 0
D:  Ver= 1.00 Cls=00(>ifc ) Sub=00 Prot=00 MxPS=16 #Cfgs=  1
P:  Vendor=0830 ProdID=0061 Rev= 1.00
S:  Manufacturer=PalmOne, Inc.
S:  Product=Palm Handheld
S:  SerialNumber=PalmSN12345678
C:* #Ifs= 1 Cfg#= 1 Atr=c0 MxPwr=  2mA
I:* If#= 0 Alt= 0 #EPs= 4 Cls=ff(vend.) Sub=00 Prot=00 Driver=visor
E:  Ad=81(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=02(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=86(I) Atr=02(Bulk) MxPS=  64 Ivl=0ms
E:  Ad=07(O) Atr=02(Bulk) MxPS=  64 Ivl=0ms

This is a Treo 650 bundled with Sprint, but I think it is a standard Treo 650 running Palm OS v5.4.8.

Versions of packages and their versions I'm using now (all installed via yum and none are compiled from source):
Problems that I saw after more experimentation that I will have to eliminate as possibilities:
  1. I noticed that earlier I had the udev rule specify a GROUP of uucp, but the corrected rule indicates usb.  My user is not a part of the usb group.  That may be a factor here, especially since I could not get the pilot-xfer program to work. 
  2. Even with that GROUP="usb", the file group permissions on the /dev/ttyUSB* files are still root.  Perhaps the usb group does not yet exist, and I have to figure out how to create it.The System --> Administration --> Users and Groups program under GNOME desktop does not show either "uucp" or "usb" groups.  Typing "groups" command at the shell prompt under my user shows "uucp", so why doesn't Users and Groups show the "uucp" group?  Unfortunately, I didn't write down how to add groups so I'll have to puzzle through how to do that.
  3. When I hit the sync button on the cradle, and do an ls -ld /dev/ttyUSB*, I see that the group bits are all zeroed out.  Perhaps the MODE setting in the udev rule is not doing what I expect it to, and I would expect that would be yet another reason for the user-mode execution of pilot-xfer to fail since the /dev/ttyUSB* files are not readable at all by any user within the UNIX groups. But if that is the case, then why doesn't pilot-xfer emit an error to standard out indicating failure to read the device file?
I'll report back when I make further progress, but I would appreciate a note if anyone else has any brighter ideas.

Brent

On 9/29/07, Brent Goodrick <bgoodr gmail com> wrote:
I'm having some success communicating with a person on that channel right now. I'll report a transcript when I'm got all of the juicy details.  Thanks again David!

Brent

On 9/29/07, David A. Desrosiers <desrod gnu-designs com> wrote:

> I wonder if there is a IRC channel that would give us more immediate
> help.

You could always try #pilot-link on irc.pilot-link.org. There's always
someone there 24x7..


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




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]