Re: unable to bind to pilot?

[Patrick Ball <lookout_20005 yahoo com>]

Ok, new info, and WEIRD outcomes. David: you asked if
other tools talk to the visor. The answer, after
today's efforts, is "sort of."  Having
a longer look at insmod, I found the following:


[root localhost pball]# /sbin/insmod visor debug=1
Using
/lib/modules/2.4.9-21/kernel/drivers/usb/serial/visor.o
/lib/modules/2.4.9-21/kernel/drivers/usb/serial/visor.o:
unresolved symbol usb_s
erial_register_R47432c1e
/lib/modules/2.4.9-21/kernel/drivers/usb/serial/visor.o:
unresolved symbol usb_s
erial_deregister_Rf3baa7aa


apparently there are broken pieces of usb_serial, but
I have no idea how to fix them.  This is an out-of-the
-box RH7.2 kernel (after a fling with up2date). I'd be
happy to roll my own, but experience suggests that
I'll just make the problem much worse. (and I'll admit
there are several kernels floating around on my box
and I'm promiscuous in the extreme with adding new
ones.  this won't make my tasks easier, but hey, this
is NOT my work production machine.)

However, we've managed to change the errors.  Now when
I hit the sync button on the cradle, the visor gives
it's "I'm connected" chirp followed nearly instantly
by the "I"m disconnected" chirp. I SIGKILL'd gpilotd
and restarted from the cmd line, and it said that
I'd sync'd everything just fine!

gpilotd-Message: gnome-pilot 0.1.64 starting...
gpilotd-Message: compiled for pilot-link version 0.9.5
gpilotd-Message: compiled with [VFS] [GOAD] [USB]
[IrDA] [Network] 
[pball localhost pball]$ gpilotd-Message: Activating
CORBA server
gpilotd-Message: Watching Cradle (/dev/pilot)
gpilotd-Message: setting PILOTRATE=57600
gpilotd-Message: Cradle Cradle has 0 events
gpilotd-Message: Instantiating 0 conduits...
gpilotd-Message: Instantiated 0 backup conduits, 0
file conduits, 0 other conduits
gpilotd-Message: HotSync button pressed, synchronizing
pilot
gpilotd-Message: Pilot ID is 500, name is visor, owner
is pball
gpilotd-Message: Pilot has 0 entries in restore queue
gpilotd-Message: Pilot has 0 entries in conduit queue
gpilotd-Message: Using conduit settings for sync...
gpilotd-Message: Synchronization ended

ok, how weird is that?  it did lose the conduits to
evo, so I went
back into gnomecc to reset them. I hit sync again, and
THE ADDRESSES
sync'd!  But we're not home yet.

First, when I told gnomecc to enable the MemoFile
conduit,
gpilotd-control-applet segfaulted.  This is a
consistent, repeatable
error and I submitted a bug report.

But perhaps more interestingly for our purposes, the
calendar app
refused to sync to evo.  Here's gpilotd's log from the
cmd line after
I hit sync.  

ecalconduit-WARNING **: Could not read pilot's
Calendar application block

ecalconduit-WARNING **: dlp_ReadAppBlock(...) = -1

gpilotd-WARNING **: Synchronization failed!

gpilotd-WARNING **: Unable to open conduit!
gpilotd-Message: Synchronization ended
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd:
monitor_on(pilot_name="OldPilot",client_id =
IOR:010000001b000000...)
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd:
monitor_on(pilot_name="visor",client_id =
IOR:010000001b000000...)
gpilotd-Message: gpilotd: corba:
notify_on(event_type=CONNECT,callback=IOR:010000001b000000...)
gpilotd-Message: gpilotd: corba:
notify_on(event_type=DISCONNECT,callback=IOR:010000001b000000...)

gpilotd-WARNING **: orbit_daemon_glue.c:208 Exception:
IDL:CORBA/COMM_FAILURE:1.0

gpilotd-Message: corba: monitor (null) dead

gpilotd-WARNING **: orbit_daemon_glue.c:208 Exception:
IDL:CORBA/COMM_FAILURE:1.0

gpilotd-Message: corba: monitor (null) dead

gpilotd-WARNING **: orbit_daemon_glue.c:208 Exception:
IDL:CORBA/COMM_FAILURE:1.0

gpilotd-Message: corba: monitor (null) dead

gpilotd-WARNING **: orbit_daemon_glue.c:208 Exception:
IDL:CORBA/COMM_FAILURE:1.0

gpilotd-Message: corba: monitor (null) dead
gpilotd-Message: Shutting down devices
gpilotd-Message: Rereading configuration...
gpilotd-Message: Watching Cradle (/dev/pilot)
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd:
monitor_on(pilot_name="OldPilot",client_id =
IOR:010000001b000000...)
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd: Client seems ok
gpilotd-Message: gpilotd:
monitor_on(pilot_name="visor",client_id =
IOR:010000001b000000...)
gpilotd-Message: gpilotd: corba:
notify_on(event_type=CONNECT,callback=IOR:010000001b000000...)
gpilotd-Message: gpilotd: corba:
notify_on(event_type=DISCONNECT,callback=IOR:010000001b000000...)

I noticed that gpilotd is seeing the my old pilot, and
perhaps
becoming confused.  I deleted the old pilot from
gnomecc and tried
again. 


[pball localhost pball]$ gpilotd-Message: setting
PILOTRATE=57600

gpilotd-WARNING **: pi_accept_to: Connection timed out

gpilotd-WARNING **: pi_accept_to: timeout was 2 secs


No connection at all.  Hey, I'm a trained engineer.  I
pushed the sync
button again.  


[pball localhost pball]$ gpilotd-Message: setting
PILOTRATE=57600
Weird packet

gpilotd-WARNING **: pi_accept_to: Input/output error

gpilotd-WARNING **: pi_accept_to: timeout was 2 secs


"Weird packet"?  Ok, now I'm starting to take that
usb_serial_register
driver problem more seriously.  The visor reports
"connection lost,
some data may not be backed up."  Back to dmesg, we
see block after
block of the following:


hub.c: USB new device connect on bus1/2, assigned
device number 8
usbserial.c: Handspring Visor converter detected
visor.c: Handspring Visor: Number of ports: 2
visor.c: Handspring Visor: port 1, is for Generic use
and is bound to ttyUSB0
visor.c: Handspring Visor: port 2, is for HotSync use
and is bound to ttyUSB1
usbserial.c: Handspring Visor converter now attached
to ttyUSB0 (or usb/tts/0 for devfs)
usbserial.c: Handspring Visor converter now attached
to ttyUSB1 (or usb/tts/1 for devfs)
usb-uhci.c: interrupt, status 3, frame# 1619
usb.c: USB disconnect on device 8
usb-uhci.c: interrupt, status 2, frame# 1636
usbserial.c: Handspring Visor converter now
disconnected from ttyUSB0
usbserial.c: Handspring Visor converter now
disconnected from ttyUSB1


and at this point, I've run out of ideas. 
Suggestions?  TIA - PB.



--- "David A. Desrosiers" <hacker gnu-designs com> 
> 
> 	Actually, your Handspring PDA is attached to the
> cradle at this
> point, making the electrical connection to the
> desktop. The Visor doesn't
> exist as far as the desktop is concerned, until you
> make this electrical
> connection. Do other tools talk to the Visor without
> problems?
> 
> > What do people recommend? I've googled on "unable
> to bind to pilot" and
> > not much turns up.
> 
> 	Debugging is in order. Insert your visor driver
> with the following
> syntax:
> 
> 	insmod visor debug=1
> 
> 	Then tail your logs, and see if you actually are
> getting anything
> more than the initial connection from
> Visor->cradle->usbcore. If you get
> that far, it's a matter of making the tools aware
> that this device now
> exists (/dev/ttyUSB1 is an invalid device until you
> make the physical
> connection, that's how USB works).
> 
> 
> 
> /d
> 


__________________________________________________
Do You Yahoo!?
Great stuff seeking new owners in Yahoo! Auctions! 
http://auctions.yahoo.com