[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [coldsync-hackers] Coldsync, IrDA and Mac OS X
Alo again,
--On Sunday, 18 November 2001 12:04 AM -0500 Andrew Arensburger
<arensb+CShackers@ooblick.com> wrote:
> On Sat, Nov 17, 2001 at 06:22:29PM -0500, William Uther wrote:
>> iv) compile coldsync. It configures and compiles fine. It does have
>> a lot of warnings while building though.
>
> Can you tell what the problem is? If you'll send me
> configuration and compilation logs, I can try to fix it. Of course,
> you have a Mac, so you're in a better position to fix it than I am.
Here is part of the log:
----- start log -----
cc -Wall -ansi -pedantic -g -O2 -DHAVE_CONFIG_H -I. -I./.. -I./../include
-I/usr/local/include -c PConnection_net.c
In file included from /usr/include/machine/types.h:30,
from /usr/include/sys/types.h:70,
from PConnection_net.c:5:
/usr/include/ppc/types.h:75: warning: ANSI C does not support `long long'
/usr/include/ppc/types.h:76: warning: ANSI C does not support `long long'
In file included from PConnection_net.c:12:
/usr/include/resolv.h:237: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:238: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:239: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:240: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:241: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:242: warning: ANSI C forbids const or volatile
functions
/usr/include/resolv.h:243: warning: ANSI C forbids const or volatile
functions
PConnection_net.c: In function `net_connect':
PConnection_net.c:256: warning: unused variable `namebuf'
PConnection_net.c:303: warning: unused variable `namebuf'
PConnection_net.c:425: warning: unused variable `namebuf'
----- end log -----
Is -ansi really neccesary?
>> The only problem I have is that it seems extremely slow (hours for the
>> initial sync). Any suggestions on fixing that?
>
> That depends on why it's taking so long. If it's not
> complaining, then I'd venture to guess that you have a lot of data and
> it's syncing at some unreasonably low speed.
> Try running it with "-dcmp:5 -dio:3". The "CMP: Got a message"
> and "CMP: Sending type" messages should tell you how fast the Palm is
> willing to go, and which speed ColdSync has picked, respectively. You
> should also see ColdSync going through a set of standard speeds to see
> whether the serial device can handle them.
well, that tells me:
===== Waiting for wakeup packet
CMP: Got a message: type 1, flags 0x00, v1.2, rate 115200
===== Got a wakeup packet
===== Sending INIT packet
CMP: Sending type 2, flags 0x80, v1.1, rate 115200
===== Finished sending INIT packet
Initialized CMP, returning speed 115200
it is deciding on 115200. I'm beginning to wonder if it is my Visor's
IrDA. I've never really used it much, and always thought it was slow. Is
there any way to get coldsync to dump the actual throughput?
In other news, it seems I sent that last email too soon. The initial sync
took ~4 hours (I told you it was slow). Right at the end it dies. The
palm and coldsync get out of sync about what they're backing up.
I just tried to sync again to get the real error messages, but it was
taking too long and I have stuff to do... From memory, the palm was saying
it was backing up one module. Coldsync was saying it was backing up
another, then coldsync gets some ACK errors (something about an extra ACK?).
I'll try to post proper error messages later...
later,
\x/ill :-}
This message was sent through the coldsync-hackers mailing list. To remove
yourself from this mailing list, send a message to majordomo@thedotin.net
with the words "unsubscribe coldsync-hackers" in the message body. For more
information on Coldsync, send mail to coldsync-hackers-owner@thedotin.net.