Re: z22 F7 problem

Matt and Tom: Thanks for your input. That confirms my suspicions that it is
somewhere at a level beneath pilot-xfer (kernel? visor module or other
modules? or even my hardware?)   pilot-xfer continues to only function the
first time as Tom indicated.

It is very notable that Tom is seeing this on a different Linux (he is using
archlinux and I'm using Fedora 7). My current kernel is
kernel-2.6.22.5-76.fc7, and just this morning the updater is wanting to
install a new kernel: kernel-2.6.22.9-91.fc7. I'll want to update to that
kernel and retest.

Do you guys think it is suspicious that two /dev/ttyUSB* files are created?
Or is that normal?  Which software component creates those files: the visor
module running in the kernel, or the kernel itself?

Do you guys know if anyone has tried to work with anyone at the kernel level
(or with the visor module maintainers) to isolate this inconsistent behavior
further? If not, I'm willing to give it a shot.

Thanks,
Brent

P.S. See my verbiage below describing additional changes I had to make to
just get pilot-xfer to be able to read the /dev/ttyUSB* files that first
time (this did not fix the pilot-xfer-works-only-once problem, but is just
here for others to reference and for future searches once the GNOME web
maintainers get around to fixing the broken search engine):

Permissions were wrong and my new udev rule was not quite
> complete. This did not fix my problem with pilot-xfer not working the
> second time.
>
> But here is what I ended up doing to my udev and user and groups setup
> on my Fedora 7 system for others to use just in case:
>
> 1. Added a usb group with my non-root user since it did not exist before
> (needed by the new udev rule):
>
>     [root@hungover ~]# groupadd usb
>     [root@hungover ~]# grep usb /etc/group
>     usb:x:502:
>
> 2. Added my non-root user (brentg) to the group:
>
>      gpasswd -a brentg usb
>
> 3. Modify the udev rule for the device to skip the other rules that
>    would change the permissions and modes and group of the device
>    files differently than we need (see
>    http://www.reactivated.net/writing_udev_rules.html#env).  The new
>    thing I added was OPTIONS+="last_rule".  Contents of my udev rule
>    file at /etc/udev/rules.d/10- custom.rules is now:
>
>     BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *",
> KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb",
> MODE="0666", OPTIONS+="last_rule"
>
>    Note this line could be used instead for debugging, since it
>    contains also contains RUN directive to run a shell script:
>
>     BUS=="usb", SYSFS{product}=="Palm Handheld*|Handspring *",
> KERNEL=="ttyUSB*", NAME="ttyUSB%n", SYMLINK="pilot", GROUP="usb",
> MODE="0666", RUN+="/tmp/udevtest.sh 10-custom.rules k==%k p==%p S==%S
> n==%n", OPTIONS+="last_rule"
>
>    With the /tmp/udevtest.sh script set up simply to log its output:
>
>     #!/bin/sh
>
>     echo "$*" >>/tmp/udevtest.out
>
>    I could not determine exactly which of the other udev rules were
>    executing that would cause the permissions to get reset, but I
>    suspect this one I found in /etc/udev/rules.d/50-udev.rules:
>
>     KERNEL=="*", OWNER="root", GROUP="root", MODE="0600"
>
>    And restarted udev with "/sbin/start_udev" each time instead of
>    rebooting each time (saved lots of time).
>
>
Brent

On 9/30/07, Tom Billiet <[email protected]> wrote:
>
>
>
> ----- Original Message -----
> From: Matt Davey
> Time: 30-09-07 12:47
> > Hi,
> >
> >> 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/$$
> >
>
> This is also the only thing I can do.
>
> > Odd.  If it works one time only, this suggests to me there might
> > be a problem at the kernel/udev layer.  It doesn't seem credible
> > that there's a difference at the palm end, nor pilot-xfer.  That
> > leaves the usb hardware and udev.
> >
> > If you browse the archives to this list over the last month
> > or two you will see several long threads discussing recent
> > regressions with Palm connectivity.  My current hunch is that
> > a relatively recent kernel change has messed up the timing
> > of device detection and creation.  This has happened before
> > (pretty badly about 18 months ago, IIRC).  There have been
> > reports of syncing only working if you start a sync about
> > a second before starting pilot-xfer or gnome-pilot (pause/unpause).
>
> Yeah, I was one of these users. I will summarize what I've found out
> about this.
>
> With the previous kernel:
> -) At the moment I connect my palm, ttyUSB0 and ttyUSB1 are created
> -) gpilotd starts printing the "using net TRUE" lines
> -) after 2 seconds, gpilotd gives a timeout message (I have to wait for
> this, otherwise sync did not work)
> -) I hit the hotsync button, ttyUSB0 and ttyUSB1 are destroyed, ttyUSB2
> and ttyUSB3 are created
> -) gpilotd is starting
>
> With the current kernel:
> -) At the moment I connect my palm, ttyUSB0 and ttyUSB1 are created
> -) gpilotd starts printing the "using net TRUE" lines
> -) no more timeout message arrives
> -) I hit the hotsync button, ttyUSB0 and ttyUSB1 are destroyed, but
> again *ttyUSB0* and *ttyUSB1* are created
> -) gpilotd does nothing, palm times out
>
> I think the problem lies there that gpilotd keeps listening on an old
> usb connection that doesn't exist anymore, but I don't know who is
> responsible for this fault: kernel, udev, pilot-link or gpilotd?
>
> >[...]
> >>    - gnome-pilot-2.0.15-5.fc7
> >>    - pilot-link-0.12.2-4.fc7
> >>    - uname -a --> Linux 2.6.22.5-76.fc7 #1 SMP Thu Aug 30 13:08:59 EDT
> >>    2007 x86_64 x86_64 x86_64 GNU/Linux
> >
> > Of those three, I think the kernel is the most likely source of trouble,
> > unfortunately.
> >
> > I don't have many suggestions, unfortunately.  I think the solution
> > will lie either with the resourceful pilot-link folks figuring out
> > more ways to deal with the problematic timing issues, or a fix
> > in the udev/kernel layers in a future kernel update.
>
> Same kernel, same palm, same problems
> >
> > You could try installing an additional kernel package and downgrading.
> > You can usually have multiple kernel packages installed and choose
> > between them at boot time.
>
> Downgrading the kernel is not that easy on my linux version (archlinux),
> so I can't test that...
>
> Tom
> _______________________________________________
> gnome-pilot-list mailing list
> [email protected]
> http://mail.gnome.org/mailman/listinfo/gnome-pilot-list
>

_______________________________________________
gnome-pilot-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list