Date: Tue, 21 Oct 2003 16:45:14 +1000 From: Johny Mattsson <lonewolf-freebsd@earthmagic.org> To: freebsd-current@freebsd.org Subject: usbd doesn't get DEVICE_DETACH? (plus patch for typo in usbd.c) Message-ID: <3F94D5FA.3090701@earthmagic.org>
next in thread | raw e-mail | index | archive | help
This is a multi-part message in MIME format. --------------020505040104060109020709 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Hi all, BACKGROUND: After a recent purchase of a Palm Tungsten W, I've been spending a few hours getting the synchronization working in FreeBSD (which hasn't been an easy task). I've almost got it all up and running, by using a PPP over Serial over USB setup, but I have a small problem remaining. THE PROBLEM: Basically, what's happening is this: When I initiate the sync on the Palm, it lights up the USB port and a /dev/ucom0 is created for me. My usbd then launches a ppp instance for that port, as well as the service daemon for the Palm device. This is all well and wonderful. However, when the sync is complete, the Palm closes down the USB port (to be expected), and /dev/ucom0 is removed. The problem is that the usbd only sees a DRIVER_DETACH, not a DEVICE_DETACH message, and because of that, it doesn't execute the "detach" statement for ucom0 (in my case, to shut down ppp and the service daemon). The net effect is that I get a ppp hanging around and getting in the way for the next sync. SPECIFIC QUESTION: What I'd like to know is whether usbd should pick up on the implicit device detach in the DRIVER_DETACH event (probably won't work if there's more than one device hanging off the driver detaching), or if there should indeed be a DEVICE_DETACH arriving before the DRIVER_DETACH? If I read usb.c correctly, it appears that when a detach event is posted, any events in the queue with the same cookie will be discarded. Is this intended behaviour, or should DEVICE_DETACH messages be left in the queue for normal processing? For me it would make more sense if they were kept, but I don't have any previous exposure to this code, so I'm not an authoritative voice exactly. As can be see in the trace below, the DRIVER_DETACH event does contain the device name, so it would be easy to modify usbd to handle this scenario as well. It doesn't feel like a very elegant way to do things, though, and as I mentioned above, it probably can't deal with the case where there's more than one device handing off the detaching driver. If someone points out what would be the preferred way of resolving this, I'm happy to get a patch happening. Trace showing that there's no device-detach picked up by usbd: ==== usbd: processing event queue on /dev/usb usbd: driver-attach event cookie=3217029324 devname=ucom0 USB_EVENT_DRIVER_ATTACH usbd: processing event queue on /dev/usb usbd: device-attach event at 1066715435.318666000, Palm Handheld, Palm, Inc.: vndr=0x0830 prdct=0x0031 rlse=0x0100 clss=0x0000 subclss=0x0000 prtcl=0x0000 device names: ucom0 usbd: ucom0 matches ucom0 usbd: Found action 'Palm Tungsten W' for Palm Handheld, Palm, Inc. at ucom0 usbd: action 0: Palm Tungsten W vndr=0x0830 prdct=0x0031 devname: ucom0 attach='/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 192.168.2.3 -n 255.255.255.0' detach='killall ppp; killall pi-csd' usbd: Setting DEVNAME='ucom0' usbd: Executing '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 192.168.2.3 -n 255.255.255.0' Working in auto mode Using interface: tun0 /usr/local/bin/pi-csd(50923): Connection Service Daemon for Palm Computing(tm) device active. /usr/local/bin/pi-csd(50923): Accepting connection requests for 'sarah' at 192.168.2.3 with mask 255.255.255.0. /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 'sarah', 192.168.2.3, 255.255.255.0 = accept. /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 'sarah', 192.168.2.3, 255.255.255.0 = accept. /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req 'sarah', 192.168.2.3, 255.255.255.0 = accept. Terminated usbd: '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a 192.168.2.3 -n 255.255.255.0' returned 143 usbd: driver-detach event cookie=3217029324 devname=ucom0 USB_EVENT_DRIVER_DETACH usbd: doing timeout discovery on /dev/usb0 usbd: doing timeout discovery on /dev/usb1 ==== Oh, and there's a typo in usbd.c too, it's printing DETACH when the event is ATTACH. One-line patch to fix this is ATTACHed (pun intended). Cheers, /Johny -- Johny Mattsson - System Designer ,-. ,-. ,-. There is no truth. http://www.earthmagic.org _.' `-' `-' There is only perception. --------------020505040104060109020709 Content-Type: text/plain; name="usbd.c.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="usbd.c.patch" --- usbd.c.org Tue Oct 21 15:49:52 2003 +++ usbd.c Tue Oct 21 15:50:10 2003 @@ -908,7 +908,7 @@ break; case USB_EVENT_DRIVER_ATTACH: if (verbose) - printf("USB_EVENT_DRIVER_DETACH\n"); + printf("USB_EVENT_DRIVER_ATTACH\n"); break; case USB_EVENT_DRIVER_DETACH: if (verbose) --------------020505040104060109020709--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3F94D5FA.3090701>