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/23/2001 11:18:35
I've tried my Visor now and I can hot-sync and backup with no
problem. I did a number of hit-syncs and it worked every time.
I'm running -current, and my system has the DISGNOSTIC and
USBD_DEBUG options turned on. Perhaps you could try this too?
I was ably to reproduce your panic by yanking out the Visor while
doing a cat. I'll investigate that problem.
-- 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 ()