GNOME.org
 

Re: Initial sync pickup

Hi Nigel, hi all,

On Tue, 2004-05-25 at 16:28, Nigel Metheringham wrote:
> Hi,
> 
> I'm running pilot-link 0.11.8 & gnome-pilot 2.0.10 (both of these are
> stock Fedora FC2 packages) with a Tungsten C in a USB cradle.
> 
> When I hit the palm cradle sync button gnome-pilot often fails to notice
> the sync (although the normal kernel hotplug magic is happening).  It
> can take as many as a dozen attempts to make gnome-pilot notice the palm
> (cancelling and retrying each time).
> 
Had (have?) exactly the same prob with a Sony Clie SJ30 on 
	debian woody/stable, 
	woody/stable w. backports, 
	sarge/testing 
with 	2.4.20 thru .23 
	and 2.6.0 and .1. 
Tried 	pilot-link 0.11.5 thru 0.11.8 
	and gnome-pilot up to 2.0.10. 
Hardware is Omnibook XE3 /i440zx Chipset, using usb-uhci drivers. 

Stopped trying after more than a year. You'd find those ancient threads
in the archives. I know of at least one other guy who recently contacted
me on this; see below.

Though I stopped working on it (now using jpilot - less pretty but much
faster and working every time), I wanted to say : You are not alone. If
you find anything more helpful, pls let me know. 

Below is what I recently told that other guy, including most of the
details I ever wrote down in one message. Take your time, some lines to
read.

Regards,
Lars

-----8<------
Original message asking me for that old thread:

On Wed, 2004-05-12 at 20:47, Philip Cheney wrote:
> Hello,
>  This is in response to an old thread, I hope you remember the
> solution!  I've been having issues with using my Clie (T415) with
> gpilotd for quite some time.  It centers entirely around the need to
> time the starting of gpilotd just right before pressing the hotsync
> button, as you described in the thread mentioned below.
> 
>  In that thread, however, this subject was dropped and never referred
to
> again.  Did you manage to resolve it?  Did it take any special actions
> to do so?  I'm using unstable with kernel 2.6.5 and udev, so I'll
admit
> that my setup is different than yours, but it has been an issue since
> well into the 2.4 days.  Let me know what you know...
> 
> Cheers,
> Phil
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
> From: Lars Weissflog <L rs-w de>
> To: gnome-pilot-list gnome org
> Subject: Re: SNAFU: Incomplete installs, no conduits available,
> precompiledpackages not working
> Date: Wed, 01 Oct 2003 22:55:00 +0200
> 
>
________________________________________________________________________
> Hi Jamie,
> details were just sent by PM off-list to you.
> 
> If anyone should stumble over this thread and is interested in my
> details, just drop me a note.
> 
> Regards.
> Lars

-----8<--------
My reply to Philip, giving all my details:

Hi Philip, 
the solution is simple: Stop using gpilotd or get a different type of
Palm OS device. 

Okay, here is the long, non kidding answer:
Thread was dropped because I never found a solution. Sometimes it works,
sometimes not. I got so tired of this that I stopped syncing Evo via
gpilotd with the Palm. Evo is great, don't get me wrong. But the problem
with gpilotd, USB and Clie is so random and seldom (i.e. limited to some
Sony models only) that nobody seemed to know an answer. 

Finally, I figured out that it seemed to be limited to a special
hardware-software combo: I have an Omnibook XE3 with intel 440ZX
Chipset. There were two drivers available for the 2.4.20 for usb:
usb-uhci.o which is the "standard" one and uhci.o aka "Alternative JE
Driver". The strange thing was: with the uhci.o, I got connected far
more often than with the usb-uhci.o. Next, there is a module called
usb-ohci.o for different types of chipsets. As I also have a normal PC
which at that time hat a SIS 735 Chipset (Athlon), I also tried that
module, and it worked _every_ single time. So, I figured it must have
been something with those usb-uhci.o modules. 

I contacted Greg Kroah (core USB developer) on this (warning, long
message, but that are all my final details in this matter):

---8<----
My question to Greg:

Hi Greg,

sorry for directly contacting you, but it seems you are the one who
might on a first glimpse point me into the right direction or the right
mailing list. My problem deals with an Intel 440ZX Chipset, the visor.o,
usbserial.o, usb-ohci.o, usb-uhci.o and uhci.o modules in stock 2.4.20
and a Sony Clie SJ30 (OS 4.x)

The problem is this: On that machine (Laptop with 440ZX-Chipset, see
lspci below), whenever I use usb-uhci, I get the Clie to connect to
pilot-link once in a hundert tries. It seems to me as if it were sort of
a timing issue, depending on my body-internal millisecond timer to
execute the pilot-link command at the right millisecond just after the
usb-subsystem has created /dev/ttyUSB1.

As soon as I switch to the JE Alternate Driver (uhci.o), I get connected
every time. I tried the same Kernel, pilot-link and all that on another
machine with a SIS 735 Chipset (Athlon) with the usb-ohci.o module and
there, too, I get connected every time.

I had this issue with 2.4.18, pilot-link from 0.11.5 up to current
0.11.8, but as it disappears when using uhci.o, I believe it is
something in usb-uhci or the combination of usb-uhci with the 440zx,
visor.o and usbserial.o.

As your name appears in nearly every post to similar issues in all those
archives google found something in, I thought you might have an idea
a) what the problem is 
or 
b) where to address this to (mailing list, newsgroup, person etc.).

I have discussed that issue several times on the gnome-pilot mailing
list where the developers of pilot-link are, but there we never found a
solution. 

Well, and using alternate uhci.o won't do me any good since I need USB
within a VMware and that tool won't run USB with the uhci.o ;-((
Only (very-much-)work-around would be to shut down any VMware instances,
unload usb-uhci, load uhci, do pilot-stuff from linux, unload uhci, load
usb-uhci and reboot any VMware instances. Much work, and kinda
dangerous, since as far as I noted VMware doesn't report the usb-uhci
module as used when it runs, so if I forget to close a VMware, the
system gets into serious trouble.

Okay, some details:

1) lspci -v
[2328] moi carryme:~ $ lspci -v
00:00.0 Host bridge: Intel Corp. 440BX/ZX - 82443BX/ZX Host bridge (rev
03)
        Flags: bus master, medium devsel, latency 64
        Memory at ec000000 (32-bit, prefetchable) [size=64M]
        Capabilities: <available only to root>

00:01.0 PCI bridge: Intel Corp. 440BX/ZX - 82443BX/ZX AGP bridge (rev
03) (prog-if 00 [Normal decode])
        Flags: bus master, 66Mhz, medium devsel, latency 128
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=64
        Memory behind bridge: f0000000-f7ffffff

00:04.0 CardBus bridge: Texas Instruments PCI1420
        Subsystem: Hewlett-Packard Company: Unknown device 0014
        Flags: bus master, medium devsel, latency 168, IRQ 11
        Memory at 20000000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 20400000-207ff000 (prefetchable)
        Memory window 1: 20800000-20bff000
        I/O window 0: 00004000-000040ff
        I/O window 1: 00004400-000044ff
        16-bit legacy interface ports at 0001

00:04.1 CardBus bridge: Texas Instruments PCI1420
        Subsystem: Hewlett-Packard Company: Unknown device 0014
        Flags: bus master, medium devsel, latency 168, IRQ 11
        Memory at 20001000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=06, subordinate=09, sec-latency=176
        Memory window 0: 20c00000-20fff000 (prefetchable)
        Memory window 1: 21000000-213ff000
        I/O window 0: 00004800-000048ff
        I/O window 1: 00004c00-00004cff
        16-bit legacy interface ports at 0001

00:07.0 ISA bridge: Intel Corp. 82371AB PIIX4 ISA (rev 02)
        Flags: bus master, medium devsel, latency 0

00:07.1 IDE interface: Intel Corp. 82371AB PIIX4 IDE (rev 01) (prog-if
80 [Master])
        Flags: bus master, medium devsel, latency 64
        I/O ports at 1080 [size=16]

00:07.2 USB Controller: Intel Corp. 82371AB PIIX4 USB (rev 01) (prog-if
00 [UHCI])
        Flags: bus master, medium devsel, latency 64, IRQ 5
        I/O ports at 1060 [size=32]

00:07.3 Bridge: Intel Corp. 82371AB PIIX4 ACPI (rev 03)
        Flags: medium devsel, IRQ 9

00:08.0 Multimedia audio controller: ESS Technology ES1988 Allegro-1
(rev 12)
        Subsystem: Hewlett-Packard Company: Unknown device 0012
        Flags: bus master, medium devsel, latency 64, IRQ 5
        I/O ports at 1400 [size=256]
        Capabilities: <available only to root>

00:08.1 Communication controller: ESS Technology ESS Modem (rev 12)
        Subsystem: Hewlett-Packard Company: Unknown device 0012
        Flags: medium devsel, IRQ 5
        I/O ports at 1800 [size=256]
        Capabilities: <available only to root>

00:10.0 Ethernet controller: Accton Technology Corporation EN-1216
Ethernet Adapter (rev 11)
        Subsystem: Accton Technology Corporation: Unknown device 2242
        Flags: bus master, medium devsel, latency 64, IRQ 11
        I/O ports at 1c00 [size=256]
        Memory at e8000000 (32-bit, non-prefetchable) [size=1K]
        Expansion ROM at <unassigned> [disabled] [size=128K]
        Capabilities: <available only to root>

01:01.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev
11) (prog-if 00 [VGA])
        Subsystem: Hewlett-Packard Company: Unknown device 0014
        Flags: bus master, 66Mhz, medium devsel, latency 64, IRQ 11
        Memory at f0000000 (32-bit, non-prefetchable) [size=128M]
        Expansion ROM at <unassigned> [disabled] [size=64K]
        Capabilities: <available only to root>


2) /var/log/messages when running on usb-uhci and hitting sync on the
clie:
---- MARK ----

[here I tap hotsync on the clie]

Nov 26 23:33:44 carryme kernel: hub.c: new USB device 00:07.2-2,
assigned address 5
Nov 26 23:33:44 carryme kernel: Manufacturer: Palm, Inc.
Nov 26 23:33:44 carryme kernel: Product: Palm Handheld
Nov 26 23:33:44 carryme kernel: usbserial.c: Handspring Visor / Palm 4.0
/ Clié 4.x converter detected
Nov 26 23:33:44 carryme kernel: visor.c: Handspring Visor / Palm 4.0 /
Clié 4.x: Number of ports: 2
Nov 26 23:33:44 carryme kernel: visor.c: Handspring Visor / Palm 4.0 /
Clié 4.x: port 1, is for Generic use and is bound to ttyUSB0
Nov 26 23:33:44 carryme kernel: visor.c: Handspring Visor / Palm 4.0 /
Clié 4.x: port 2, is for HotSync use and is bound to ttyUSB1
Nov 26 23:33:44 carryme kernel: usb-uhci.c: interrupt, status 2, frame#
159
Nov 26 23:33:47 carryme kernel: usb_control/bulk_msg: timeout

[observe the time difference: 3 seconds!]

Nov 26 23:33:50 carryme kernel: usb_control/bulk_msg: timeout
Nov 26 23:33:50 carryme kernel: usbserial.c: Handspring Visor / Palm 4.0
/ Clié 4.x converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Nov 26 23:33:50 carryme kernel: usbserial.c: Handspring Visor / Palm 4.0
/ Clié 4.x converter now attached to ttyUSB1 (or usb/tts/1 for devfs)

[here I tap cancel on the clie]

Nov 26 23:33:57 carryme kernel: usb.c: USB disconnect on device
00:07.2-2 address 5
Nov 26 23:33:57 carryme kernel: usbserial.c: Handspring Visor / Palm 4.0
/ Clié 4.x converter now disconnected from ttyUSB0
Nov 26 23:33:57 carryme kernel: usbserial.c: Handspring Visor / Palm 4.0
/ Clié 4.x converter now disconnected from ttyUSB1



What makes me suspicious are those  three lines:
Nov 26 23:33:44 carryme kernel: usb-uhci.c: interrupt, status 2, frame#
159
Nov 26 23:33:47 carryme kernel: usb_control/bulk_msg: timeout
Nov 26 23:33:50 carryme kernel: usb_control/bulk_msg: timeout

The noticeable break between the last two messages is sometimes shorter.


2) /var/log/messages is exactly the same with uhci.o loaded, only the
three strange lines are missing then. 

3) dmesg gives for that usb-uhci connection attempt:

[here I tap hotsync on the clie]

hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: port 2, portstatus 101, change 1, 12 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 101, change 1, 12 Mb/s
hub.c: port 2, portstatus 101, change 0, 12 Mb/s
hub.c: port 2, portstatus 101, change 0, 12 Mb/s
hub.c: port 2, portstatus 101, change 0, 12 Mb/s
hub.c: port 2, portstatus 101, change 0, 12 Mb/s
hub.c: port 2, portstatus 103, change 0, 12 Mb/s
hub.c: new USB device 00:07.2-2, assigned address 6
usb.c: kmalloc IF c7072244, numif 1
usb.c: new device strings: Mfr=1, Product=2, SerialNumber=0
usb.c: USB device number 6 default language ID 0x409
Manufacturer: Palm, Inc.
Product: Palm Handheld
usbserial.c: Handspring Visor / Palm 4.0 / Clié 4.x converter detected
visor.c: Handspring Visor / Palm 4.0 / Clié 4.x: Number of ports: 2
visor.c: Handspring Visor / Palm 4.0 / Clié 4.x: port 1, is for Generic
use and is bound to ttyUSB0
visor.c: Handspring Visor / Palm 4.0 / Clié 4.x: port 2, is for HotSync
use and is bound to ttyUSB1
usb-uhci.c: interrupt, status 2, frame# 396
usb_control/bulk_msg: timeout
visor.c: visor_startup - error getting first unknown palm command
usb_control/bulk_msg: timeout
visor.c: visor_startup - error getting second unknown palm command
usbserial.c: Handspring Visor / Palm 4.0 / Clié 4.x converter now
attached to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: Handspring Visor / Palm 4.0 / Clié 4.x converter now
attached to ttyUSB1 (or usb/tts/1 for devfs)
usb.c: serial driver claimed interface c7072244
usb.c: kusbd: /sbin/hotplug add 6
usb.c: kusbd policy returned 0xfffffffe
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: port 2, portstatus 103, change 0, 12 Mb/s

[here I tap cancel on the clie]

hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
hub.c: port 2 connection change
hub.c: port 2, portstatus 100, change 3, 12 Mb/s
usb.c: USB disconnect on device 00:07.2-2 address 6
usbserial.c: Handspring Visor / Palm 4.0 / Clié 4.x converter now
disconnected from ttyUSB0
usbserial.c: Handspring Visor / Palm 4.0 / Clié 4.x converter now
disconnected from ttyUSB1
usb.c: kusbd: /sbin/hotplug remove 6
usb.c: kusbd policy returned 0xfffffffe
hub.c: port 1, portstatus 303, change 0, 1.5 Mb/s
hub.c: port 2, portstatus 100, change 2, 12 Mb/s
hub.c: port 2 enable change, status 100


Uh, that's it. What else can I tell you? Would be great if you had any
idea for me where to continue.

End of message to Greg
--->8----


I got more or less no reply from him, he only asked "what about 2.6?". I
recently tried that, running 2.6.3 for a while now. But no obvious
change. 

So, finally I gave up connecting the Clie via gpilotd to evo. I now use
ugly but fast and stable jpilot which has the nice side effect of having
a plugin for the GPL tool "keyring". As I'm an Admin, I have millions of
passwords to remember, and this is really nice. All for free. So I more
or less use jpilot only as Backup tool, syncs much faster than Evo with
gpilot. Mails are still in Evo and that's it. 

Sorry for having no better news for you, but anyhow: Welcome to the Club
:-(

Best regards
Lars
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]