Re: z22 F7 problem

["Brent Goodrick" <bgoodr gmail com>]

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 < bgoodr gmail com> 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 <mouse256 ulyssis org> 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
gnome-pilot-list gnome org
http://mail.gnome.org/mailman/listinfo/gnome-pilot-list