Re: Sync Evolution and Visor

[Greg Copeland <gtcopeland earthlink net>]

On Fri, 2003-09-19 at 08:45, Frederic Crozat wrote: 
> Le ven 19/09/2003 à 14:58, Greg Copeland a écrit :
> > On Fri, 2003-09-19 at 07:44, Frederic Crozat wrote:
> > > Le ven 19/09/2003 à 14:29, Greg Copeland a écrit :
> > > > The gpilotd configuration file yields:
> > > > [General]
> > > > sync_PC_Id=542352833
> > > > progress_stepping=1
> > > > num_devices=1
> > > > num_pilots=1
> > > >  
> > > > [Device0]
> > > > type=1
> > > > name=Cradle
> > > > device=/dev/palm
> > > > speed=115200
> > > > timeout=4
> > > 
> > > Try replacing with
> > > device=/dev/usb/tts/1
> > > speed=57600
> > > 
> > 
> > Done.  Still a no go.
> 
> 
> > > But before all of this, you should make sure something below gnome-pilot
> > > is not broken. Try this : 
> > > -press hotsync
> > > -run pilot-xfer -l  to check if your visor is correctly detected and
> > > read by pilot-link..
> > 
> > This has always worked.  Just did it again to be anal.  It still works. 
> > Furthermore, it seems to work well off the /dev/pilot link too.
> > 
> > []$ pilot-xfer -l
> >    No $PILOTPORT specified and no -p <port> given.
> >    Defaulting to '/dev/pilot'
> >  
> >    Listening to port: /dev/pilot
> >  
> >    Please press the HotSync button now... Connected
> >  
> > Reading list of databases in RAM...
> > .
> > .
> > .
> > List complete. 59 files found.
> > Time elapsed: 0:00:03
> 
> Ok.. I prefer to get things tested on step at a time..
> 

Agreed.  I understand you need to know what square peg I'm standing on.

> > My system is almost back to it's old settings.  I do know that 
> > "2.4.21-0.25mdksmp" appears to have a minor reference count bug in the
> > modules.  I can remove all usb modules and there is still a reference
> > count of 1 for usbcore.  No matter what, the count can't be reduced. 
> > I'm wondering if part of the problem is kernel related.
> 
> This is because /proc/bus/usb is mounted.. Unmount it and you'll be able
> to unload usb module..

Doh!  Confirmed!

> Back on gpilotd, try this :
> 
> -killall gpilotd (just to be sure no other instance is runnning)
> -run it yourself in an xterm
> -press hotsync and check what it ouputs..

Negative.
We're back to the can't bind message, several times in a row...
*recovery from three crashes*...and time spent doing other things...
Shortly after messing with the USB stuff, my system locked immediately
following a successful sync.  Seems like those pesky kernel USB bugs are
still lurking.  At any rate, rebooting several times resulting in my
machine locking tight every time the USB modules were loaded.  After
doing a cold boot, the system came up and I can now do the
one-off-gpilotd syncs.  Seems the USB stuff didn't get properly reset
between warm boots.  Ack!  A cold boot seems to of kicked squarely. 
Which, does place me back to where I started from.  Cool!  

Want to thank everyone that helped for their time and effort.  Just fyi,
my gpilotd device section looks like this:  It's now back to where it
was before I upgraded and had problems.

[Device0]
type=1
name=Cradle
device=/dev/pilot
speed=230400
timeout=4
 

Also, Just FYI, I had been changing rate on my visor too.  I noticed
long ago that syncing is much harder, if not impossible, if the data
rates between gpilotd and the device are not the same.  Oddly enough,
I'm not sure I understand the reason why and never bothered to look at
the code to figure out if there is actual code to support such a
correlation.

Cheers!


-- 

Greg Copeland <gtcopeland earthlink net>