Re: usbd doesn't get DEVICE_DETACH? (plus patch for typo in usbd.c)

В вт, 21.10.2003, в 10:45, Johny Mattsson пишет:
> Hi all,

Me too !

kern/46488  

I will check your patch.

> 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
-- 
Vladimir B. Grebenschikov <vova_at_fbsd.ru>
SWsoft Inc.