В пт, 24.10.2003, в 00:01, Vladimir B. Grebenschikov пишет: > В вт, 21.10.2003, в 10:45, Johny Mattsson пишет: > > Hi all, > > Me too ! > > kern/46488 > > I will check your patch.
Yes, patch works, Thanx, please commit and close PR. Now I can get rid of hack in usbd.conf: --- # hack to workaround no keyboard detach event device "HUB" devname "uhub[0-9]+" detach "/usr/sbin/kbdcontrol -k /dev/kbd0 < /dev/console" --- > > 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 <[EMAIL PROTECTED]> SWsoft Inc. _______________________________________________ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "[EMAIL PROTECTED]"