Date: Fri, 24 Oct 2003 00:01:27 +0400 From: "Vladimir B. Grebenschikov" <vova@fbsd.ru> To: Johny Mattsson <lonewolf-freebsd@earthmagic.org> Cc: freebsd-current@freebsd.org Subject: Re: usbd doesn't get DEVICE_DETACH? (plus patch for typo in usbd.c) Message-ID: <1066939285.945.23.camel@localhost> In-Reply-To: <3F94D5FA.3090701@earthmagic.org> References: <3F94D5FA.3090701@earthmagic.org>
next in thread | previous in thread | raw e-mail | index | archive | help
=F7 =D7=D4, 21.10.2003, =D7 10:45, Johny Mattsson =D0=C9=DB=C5=D4: > Hi all, Me too ! kern/46488 =20 I will check your patch. > BACKGROUND: > After a recent purchase of a Palm Tungsten W, I've been spending a few=20 > hours getting the synchronization working in FreeBSD (which hasn't been=20 > an easy task). I've almost got it all up and running, by using a PPP=20 > over Serial over USB setup, but I have a small problem remaining. >=20 > THE PROBLEM: > Basically, what's happening is this: When I initiate the sync on the=20 > Palm, it lights up the USB port and a /dev/ucom0 is created for me. My=20 > usbd then launches a ppp instance for that port, as well as the service=20 > daemon for the Palm device. This is all well and wonderful. However,=20 > when the sync is complete, the Palm closes down the USB port (to be=20 > expected), and /dev/ucom0 is removed. The problem is that the usbd only=20 > sees a DRIVER_DETACH, not a DEVICE_DETACH message, and because of that,=20 > it doesn't execute the "detach" statement for ucom0 (in my case, to shut=20 > down ppp and the service daemon). The net effect is that I get a ppp=20 > hanging around and getting in the way for the next sync. >=20 >=20 > SPECIFIC QUESTION: > What I'd like to know is whether usbd should pick up on the implicit=20 > device detach in the DRIVER_DETACH event (probably won't work if there's=20 > more than one device hanging off the driver detaching), or if there=20 > should indeed be a DEVICE_DETACH arriving before the DRIVER_DETACH? >=20 > If I read usb.c correctly, it appears that when a detach event is=20 > posted, any events in the queue with the same cookie will be discarded.=20 > Is this intended behaviour, or should DEVICE_DETACH messages be left in=20 > the queue for normal processing? For me it would make more sense if they=20 > were kept, but I don't have any previous exposure to this code, so I'm=20 > not an authoritative voice exactly. >=20 > As can be see in the trace below, the DRIVER_DETACH event does contain=20 > the device name, so it would be easy to modify usbd to handle this=20 > scenario as well. It doesn't feel like a very elegant way to do things,=20 > though, and as I mentioned above, it probably can't deal with the case=20 > where there's more than one device handing off the detaching driver. >=20 > If someone points out what would be the preferred way of resolving this,=20 > I'm happy to get a patch happening. >=20 > Trace showing that there's no device-detach picked up by usbd: > =3D=3D=3D=3D > usbd: processing event queue on /dev/usb > usbd: driver-attach event cookie=3D3217029324 devname=3Ducom0 > USB_EVENT_DRIVER_ATTACH > usbd: processing event queue on /dev/usb > usbd: device-attach event at 1066715435.318666000, Palm Handheld, Palm,=20 > Inc.: > vndr=3D0x0830 prdct=3D0x0031 rlse=3D0x0100 clss=3D0x0000 subclss=3D0x0= 000=20 > prtcl=3D0x0000 > device names: ucom0 > usbd: ucom0 matches ucom0 > usbd: Found action 'Palm Tungsten W' for Palm Handheld, Palm, Inc. at uco= m0 > usbd: action 0: Palm Tungsten W > vndr=3D0x0830 prdct=3D0x0031 > devname: ucom0 > attach=3D'/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a=20 > 192.168.2.3 -n 255.255.255.0' > detach=3D'killall ppp; killall pi-csd' > usbd: Setting DEVNAME=3D'ucom0' > usbd: Executing '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H=20 > 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=20 > Computing(tm) device active. > /usr/local/bin/pi-csd(50923): Accepting connection requests for 'sarah'=20 > at 192.168.2.3 with mask 255.255.255.0. > /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req=20 > 'sarah', 192.168.2.3, 255.255.255.0 =3D accept. > /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req=20 > 'sarah', 192.168.2.3, 255.255.255.0 =3D accept. > /usr/local/bin/pi-csd(50923): Connection from [192.168.2.253], req=20 > 'sarah', 192.168.2.3, 255.255.255.0 =3D accept. > Terminated > usbd: '/usr/sbin/ppp -auto palm; /usr/local/bin/pi-csd -H sarah -a=20 > 192.168.2.3 -n 255.255.255.0' returned 143 > usbd: driver-detach event cookie=3D3217029324 devname=3Ducom0 > USB_EVENT_DRIVER_DETACH > usbd: doing timeout discovery on /dev/usb0 > usbd: doing timeout discovery on /dev/usb1 > =3D=3D=3D=3D >=20 > Oh, and there's a typo in usbd.c too, it's printing DETACH when the=20 > event is ATTACH. One-line patch to fix this is ATTACHed (pun intended). >=20 > Cheers, > /Johny --=20 Vladimir B. Grebenschikov <vova@fbsd.ru> SWsoft Inc.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1066939285.945.23.camel>