Subject: Re: uvisor and pilot-link
To: Dieter Baron <dillo@danbala.ifoer.tuwien.ac.at>
From: Lennart Augustsson <lennart@mail.augustsson.net>
List: current-users
Date: 01/22/2001 08:55:59
Thanks for the detailed description of your problems.  I'll investigate tonight.

    -- Lennart

Dieter Baron wrote:

> hi,
>
> after some more testing, I still can't talk to my Visor, but here is a
> more complete description of the situation:
>
>   Hot syncing under Windows works, so it's not the hardware.
>
>   I've now tried to talk to my Visor Prism on two different machines
> with different usb controllers:
>
>   1) the on-board USB controller on an Asus P5A-B:
>
> ohci0 at pci0 dev 2 function 0: Acer Labs M5237 USB Host Controller (rev. 0x03)
> ohci0: interrupting at irq 9
> ohci0: OHCI version 1.0, legacy support
> usb0 at ohci0: USB revision 1.0
> uhub0 at usb0
> uhub0: Acer Labs OHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
>
>   2) an IBM Thinkpad 570:
>
> uhci0 at pci0 dev 6 function 2: Intel 82371AB USB Host Controller (PIIX4) (rev.
> 0x01)
> uhci0: interrupting at irq 11
> usb0 at uhci0: USB revision 1.0
> uhub0 at usb0
> uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1
> uhub0: 2 ports with 2 removable, self powered
>
>   When connecting via cu (while the Visor is trying to hot-sync), cu
> receives no data (whereas it does receive data when connected to
> xcopilot's tty):
>
> uvisor0 at uhub0 port 1
> uvisor0: Handspring Inc Handspring Visor, rev 1.00/1.00, addr 2
> ucom0 at uvisor0
>   <cu -l /dev/ttyU0 dir>
> Connected.
>   <timeout>
> uhub0: port error, restarting port 1
> uvisor0: at uhub0 port 1 (addr 2) disconnected
>   <^C>
> cu: fcntl: Input/output error
> ucom0 detached
> uvisor0 detached
>
> Disconnected.
>
>   When running pilot-xfer, the kernel detaches ucom0 and uvisor0
> immediatly after the timeout, whereas with cu it waits for cu to close
> the tty.
>
>   Any ideas?  How can I proceed debugging?
>
>                                                 thanks,
>                                                 dillo
>
>   PS: I can consitently panic the kernel by doing the following:
>
>   -) start a hot sync on the visor
>   -) run cat /dev/ttyU0
>   -) wait for visor to timeout
>   -) press ^C
>
>   The first page of a backtrace (I have a dump and can provide further
> information):
>
> #0  0xc0322648 in db_last_command ()
> #1  0xc025d9d7 in cpu_reboot ()
> #2  0xc0128ef5 in db_sync_cmd ()
> #3  0xc0128b1c in db_command ()
> #4  0xc0128cbe in db_command_loop ()
> #5  0xc012ba52 in db_trap ()
> #6  0xc025b5c2 in kdb_trap ()
> #7  0xc0264e78 in trap ()
> #8  0xc0100d45 in calltrap ()
> #9  0xc0118d67 in uhci_device_bulk_close ()
> #10 0xc02ba5dc in usbd_close_pipe ()
> #11 0xc02c14f5 in ucom_cleanup ()
> #12 0xc02c0b31 in ucomclose ()
> #13 0xc0176436 in spec_close ()
> #14 0xc0248471 in ufsspec_close ()
> #15 0xc016dfe7 in vn_close ()
> #16 0xc016e89b in vn_closefile ()
> #17 0xc013ce8c in closef ()
> #18 0xc013cc66 in fdfree ()
> #19 0xc013e26a in exit1 ()
> #20 0xc014564b in sigexit ()
> #21 0xc0145413 in postsig ()