Re: z22 F7 problem

Update: I upgraded to kernel kernel-2.6.22.9-91.fc7. I am able to use
pilot-xfer a little bit better, but it is still not quite right.  Maybe it
was working this way before and I just didn't notice it, but now, every
other time I invoke pilot-xfer, it will work, but other times it will hang.
/dev/ttyUSB0 and /dev/ttyUSB1 are still consistently being created for this
kernel (still, I wonder why two device files are being created as that seems
suspicious).

Something else that may or may not be significant: The first time I rebooted
into this new F7 kernel, I went into single user mode and tried the
pilot-xfer program from root.  Then, booted into level 3 (init 3) and tried
again. At one point right after pilot-xfer apparently succeeded, I saw these
messages on the root console (no X was running at this point of course):

hub 1-0:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 4. Maybe the USB cable is bad?
hub 1-0:1.0: Cannot enable port 4. Maybe the USB cable is bad?
USB 1-4: device descriptor read/64, error -62
USB 1-4: device descriptor read/64, error -62
USB 1-4: device descriptor read/64, error -62
USB 1-4: device descriptor read/64, error -62
USB 1-4: device not accepting address 28, error -62
USB 1-4: device not accepting address 28, error -62


Brent

On 9/30/07, Brent Goodrick <[email protected]> wrote:
>
> 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