Re: usbd does not use detach
On Thu, 2003-08-14 at 16:30, Olivier Cortes wrote: Le Mer 06/08/2003 à 17:55, Jan Stocker a écrit : Does nobody has this problem or does noone use this feature? the problem i see with detach is the utility of the command. but when detaching, the umount part should be done BEFORE detaching, not after. i can't find any good use for the detach hook. most of things should have been done before detaching, and i can't see how to do it without user interactivity, thus avoiding use of the detach hook. Thats another one thats a wrong specification or idea behind it... but here nothing is been called i once included a umount -f in the detach hook. after unplugin' the device, it resulted in a panic. i don't remember if the umount was causing it or if it was right after, when accessing the mount point or repluging the digital recorder. anyway, i learned that umount -f is not meant to be used often... perhaps not on top of usb. for now. But none of this should cause a panic. here this works fine if i doing it by hand... Jan -- Jan Stocker [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Friday 15 August 2003 14:13, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : It should also have a hint to indicate that this device could potentially : go away at any time, so it shouldn't cache anything if at all possible. : (Although it would be good if the user could elect to override this in : the interests of performance) : : I suspect that would require more significant changes though :) I suspect that this would be as hard to implement as dealing with things going away, and produce a system that is less desirable to use. I think ideally both would be possible.. It IS nice when you plug something in and it is mounted, and you do what you want with it, then a few seconds after you finish you unplug it. I LIKE this feature of Windows etc :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
M. Warner Losh wrote: These two are redundant. Devices can already ask the bridge driver if the device is still present on the bus. Smart drivers already do this, but most of the drivers in the tree are dumb. You also have to deal with device disappearance in ISRs since it is possible for the device to go away while the device is in the middle of the ISR. Some bus technologies also allow interrupt entry when a card/device is ejected. Another common case is to hibernate/sleep/suspend/whatever the machine, and then disconnect the device out from under it, and it not being there when the machine wakes back up. Almost all MP3 players and Palm devices have that issues (since the order of human operation is to shut off the machine, get the wallet and keys, grab the iPod (or whatever), and head out the door). -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Thu, 14 Aug 2003 22:37:35 -0600 (MDT) M. Warner Losh [EMAIL PROTECTED] wrote: In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : #DETACH_FORCE: Clients using the device must be disconnected, : #typically by revoking open file descriptors. May not : #return EBUSY due to client activitiy, but may return : #that or other errors due to hardware problems or : #limitations. : # : #DETACH_EJECTED: This call is made from a lower-level bus : #driver when the device has been physically removed from : #the system. Like DETACH_FORCE, except that drivers can : #avoid attemping (and failing) to reset the hardware : #state. This request must succeed. These two are redundant. Devices can already ask the bridge driver if the device is still present on the bus. Smart drivers already do this, but most of the drivers in the tree are dumb. How does one do this check? It is not obvious, which may explain why there are so many dumb drivers in this regard. Another factor that aggravates this is that in some cases, the driver itself may not care about this check, but its clients will. For example, umass may well not need to do anything different depending on whether it was unloaded or its device was unplugged. But the layers below it, CAM, GEOM, and VFS, may still need that information. And they aren't going to know what the USB device is, much less how to query for its existence. It seems to me that the solution for dumb drivers is to make it as easy for them to be smart, by doing as much as possible in the bus driver. You also have to deal with device disappearance in ISRs since it is possible for the device to go away while the device is in the middle of the ISR. Some bus technologies also allow interrupt entry when a card/device is ejected. : In addition, the DETACH_FORCE and DETACH_EJECTED flags could : be mapped to appropriate flag values for the other subsystems, such : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS. The problem is that when you are detaching a device, it is gone when you return from the detach routine. Right. I haven't looked at the code extensively, but I believe the GEOM orphanage concept handles this well. When the disk_destroy is called during the device detach, it means that GEOM will take over returning errors to clients who still may be trying to use the device, so that those requests won't get sent to the device, and the device would be safe to delete. It can be hard to know what buffers (disk, network, etc) in the system refer a given newbus device because there's not a one to one mapping for the device_t to dev_t that the rest of the system uses. Devices may or may not know about buffers that are outstanding. Work would be needed in the buf/bio system to reference cound the dev_t so that when the driver destroys it, it doesn't go completely away until the reference count goes to zero. However, doing that may have unfavorable performance impacts. This exists in GEOM, see struct g_bioq and the nstart and nend fields of struct g_consumer. I don't know if it actually handles the hot-unplug scenario, though. The design should be able to handle it. : i manually umount the device before unpluging it. : : That is the only safe way to do it for now. Agreed. Warner Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Thu, 14 Aug 2003 10:38:07 -0700 John-Mark Gurney [EMAIL PROTECTED] wrote: This is a bit more complex than this. There are many more layers between usb and VFS. For USB umass devices, they proxy to cam, which then is an interface to da which is a provider for geom which then provides the final device for ufs to mount. So, each and every one of those steps need to be taught about this. Right now, very few things use newbus even though they should. This is a problem of them existing before newbus was nailed down. CAM doesn't use newbus for any of it's device management (scsi device, not HBA attachment). Yes, I'm aware that there are more layers. Propogating the flag value down is trivial. The major deficiency of CAM and GEOM is that errors can't be sent back up. For example, we have this scenario: # mount /dev/da0s1a /mnt # mounting a USB hard drive # cd /mnt # in use # kldunload umass # oops! it succeeds # Ideally, I'd love to see an enhanced newbus provide the One True Framework for attaching and detaching both devices and device clients. Unfortunately, it seems like it would take a substantial redesign to get there from this point. Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED]
Eric Jacobs [EMAIL PROTECTED] writes:
: In message: [EMAIL PROTECTED]
: Eric Jacobs [EMAIL PROTECTED] writes:
: : #DETACH_FORCE: Clients using the device must be disconnected,
: : #typically by revoking open file descriptors. May not
: : #return EBUSY due to client activitiy, but may return
: : #that or other errors due to hardware problems or
: : #limitations.
: : #
: : #DETACH_EJECTED: This call is made from a lower-level bus
: : #driver when the device has been physically removed from
: : #the system. Like DETACH_FORCE, except that drivers can
: : #avoid attemping (and failing) to reset the hardware
: : #state. This request must succeed.
:
: These two are redundant. Devices can already ask the bridge driver if
: the device is still present on the bus. Smart drivers already do
: this, but most of the drivers in the tree are dumb.
:
: How does one do this check? It is not obvious, which may explain why
: there are so many dumb drivers in this regard.
#
# Is the hardware described by _child still attached to the system?
#
# This method should return 0 if the device is not present. It should
# return -1 if it is present. Any errors in determining should be
# returned as a normal errno value. Client drivers are to assume that
# the device is present, even if there is an error determining if it is
# there. Busses are to try to avoid returning errors, but newcard will return
# an error if the device fails to implement this method.
#
METHOD int child_present {
device_t_dev;
device_t_child;
} DEFAULT bus_generic_child_present;
It is recently added.
: Another factor that aggravates this is that in some cases, the driver
: itself may not care about this check, but its clients will. For example,
: umass may well not need to do anything different depending on whether
: it was unloaded or its device was unplugged. But the layers below it,
: CAM, GEOM, and VFS, may still need that information. And they aren't
: going to know what the USB device is, much less how to query for its
: existence.
Well, somebody has to talk to hardware, and that somebody has to
cope. And the problem is we can
: It seems to me that the solution for dumb drivers is to make it as
: easy for them to be smart, by doing as much as possible in the bus
: driver.
You aren't making things easier. You have:
switch (foo) {
case DETACH_FORCE:
flush();
/* fall through */
case DETACH_EJECT:
...
}
vs
if (bus_child_present(dev))
flush();
...
: : In addition, the DETACH_FORCE and DETACH_EJECTED flags could
: : be mapped to appropriate flag values for the other subsystems, such
: : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS.
:
: The problem is that when you are detaching a device, it is gone when
: you return from the detach routine.
:
: Right. I haven't looked at the code extensively, but I believe the GEOM
: orphanage concept handles this well. When the disk_destroy is called
: during the device detach, it means that GEOM will take over returning
: errors to clients who still may be trying to use the device, so that
: those requests won't get sent to the device, and the device would be
: safe to delete.
If this is true, then no driver work should be necessary at all for
disk devices. However, the upper layers don't deal too well with
errors flushing. And it does nothing for network drives that have
similar problems.
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : On Thu, 14 Aug 2003 10:38:07 -0700 : John-Mark Gurney [EMAIL PROTECTED] wrote: : : : This is a bit more complex than this. There are many more layers between : usb and VFS. For USB umass devices, they proxy to cam, which then is an : interface to da which is a provider for geom which then provides the : final device for ufs to mount. So, each and every one of those steps : need to be taught about this. Right now, very few things use newbus : even though they should. This is a problem of them existing before : newbus was nailed down. CAM doesn't use newbus for any of it's device : management (scsi device, not HBA attachment). : : Yes, I'm aware that there are more layers. Propogating the flag value : down is trivial. The major deficiency of CAM and GEOM is that errors : can't be sent back up. For example, we have this scenario: : : # mount /dev/da0s1a /mnt # mounting a USB hard drive : # cd /mnt # in use : # kldunload umass # oops! it succeeds : # : : Ideally, I'd love to see an enhanced newbus provide the One True : Framework for attaching and detaching both devices and device : clients. Unfortunately, it seems like it would take a substantial : redesign to get there from this point. Nah, just to make cam use it. cam and newbus were contemporary developments, so cam used the old ad-hoc way of dealing. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Friday 15 August 2003 00:31, Eric Jacobs wrote: example: my digital photo recorder. i have an attach script to mount automatically the partition on the cooresponding umass/da device. works great, and this helps. but when detaching, the umount part should be done BEFORE detaching, not after. i can't find any good use for the detach hook. most of things should have been done before detaching, and i can't see how to do it without user interactivity, thus avoiding use of the detach hook. The problem with this is that the system will be asking the FS to e.g. flush buffers to a disk which it knows doesn't exist anymore, which is an error (and will cause errors). It should also have a hint to indicate that this device could potentially go away at any time, so it shouldn't cache anything if at all possible. (Although it would be good if the user could elect to override this in the interests of performance) I suspect that would require more significant changes though :) -- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 9A8C 569F 685A D928 5140 AE4B 319B 41F4 5D17 FDD5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED] Eric Jacobs [EMAIL PROTECTED] writes: : #DETACH_FORCE: Clients using the device must be disconnected, : #typically by revoking open file descriptors. May not : #return EBUSY due to client activitiy, but may return : #that or other errors due to hardware problems or : #limitations. : # : #DETACH_EJECTED: This call is made from a lower-level bus : #driver when the device has been physically removed from : #the system. Like DETACH_FORCE, except that drivers can : #avoid attemping (and failing) to reset the hardware : #state. This request must succeed. These two are redundant. Devices can already ask the bridge driver if the device is still present on the bus. Smart drivers already do this, but most of the drivers in the tree are dumb. You also have to deal with device disappearance in ISRs since it is possible for the device to go away while the device is in the middle of the ISR. Some bus technologies also allow interrupt entry when a card/device is ejected. : In addition, the DETACH_FORCE and DETACH_EJECTED flags could : be mapped to appropriate flag values for the other subsystems, such : as MNT_FORCE and (a new) MNT_EJECTED flag for VFS. The problem is that when you are detaching a device, it is gone when you return from the detach routine. It can be hard to know what buffers (disk, network, etc) in the system refer a given newbus device because there's not a one to one mapping for the device_t to dev_t that the rest of the system uses. Devices may or may not know about buffers that are outstanding. Work would be needed in the buf/bio system to reference cound the dev_t so that when the driver destroys it, it doesn't go completely away until the reference count goes to zero. However, doing that may have unfavorable performance impacts. : i manually umount the device before unpluging it. : : That is the only safe way to do it for now. Agreed. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : It should also have a hint to indicate that this device could potentially go : away at any time, so it shouldn't cache anything if at all possible. : (Although it would be good if the user could elect to override this in the : interests of performance) : : I suspect that would require more significant changes though :) I suspect that this would be as hard to implement as dealing with things going away, and produce a system that is less desirable to use. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Thursday 07 August 2003 11:19 am, you wrote: On Wed, 2003-08-06 at 16:42, Anish Mistry wrote: Do you know if the usbd actually recieves the detach signal? If it does then it should be fairly simple to add the detach to the code. usbd: driver-detach event cookie=3217029340 devname=ucom0 USB_EVENT_DRIVER_DETACH This looks like usbd receices the event, doesn't it? Jan Apply the attached patch and send me the debug output again. - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/MzO2xqA5ziudZT0RAtVLAJ9cHlAHhsvhu7SzW2hTprr5aEIZlQCgyhth 5pboSNz/5nND/+OeK4jP7nA= =F22L -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Friday 08 August 2003 02:19 am, you wrote: Helps to actually attach the patch. Almost positive I had attached it. It's attached and pasted below, just fixes a typo in the debugging. Warner - --- usbd.c.orig Thu Aug 7 18:46:47 2003 +++ usbd.c Thu Aug 7 18:52:33 2003 @@ -911,7 +911,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) - -- Anish Mistry -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/M8suxqA5ziudZT0RAs70AJ9QJmkUQL0G+Cyd11aKqQwtyY3h2gCdH9ES 7cvH2y+SzT6M7RC+EsuWqR4= =ryqG -END PGP SIGNATURE- ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
Eric Jacobs wrote this message on Thu, Aug 14, 2003 at 11:01 -0400: In addition, the DETACH_FORCE and DETACH_EJECTED flags could be mapped to appropriate flag values for the other subsystems, such as MNT_FORCE and (a new) MNT_EJECTED flag for VFS. This is a bit more complex than this. There are many more layers between usb and VFS. For USB umass devices, they proxy to cam, which then is an interface to da which is a provider for geom which then provides the final device for ufs to mount. So, each and every one of those steps need to be taught about this. Right now, very few things use newbus even though they should. This is a problem of them existing before newbus was nailed down. CAM doesn't use newbus for any of it's device management (scsi device, not HBA attachment). -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
On Thu, 14 Aug 2003 14:30:06 +
Olivier Cortes [EMAIL PROTECTED] wrote:
Le Mer 06/08/2003 à 17:55, Jan Stocker a écrit :
Does nobody has this problem or does noone use this feature?
the problem i see with detach is the utility of the command.
example: my digital photo recorder.
i have an attach script to mount automatically the partition on the
cooresponding umass/da device. works great, and this helps.
but when detaching, the umount part should be done BEFORE detaching, not
after. i can't find any good use for the detach hook. most of things
should have been done before detaching, and i can't see how to do it
without user interactivity, thus avoiding use of the detach hook.
The problem with this is that the system will be asking the FS to
e.g. flush buffers to a disk which it knows doesn't exist anymore, which
is an error (and will cause errors).
My proposal is that we need to amend newbus somewhat like this:
#
# Detach a device. This can be called if the user is replacing the
# driver software or if a device is about to be physically removed
# from the system (e.g. for pccard devices). Returns 0 on success.
#
# The flags argument provides more information about the cause of
# the detach and the expected behavior of this function. Possible
# values:
#
#DETACH_NORMAL: Detach succeeds only if no clients would be
#affected by removing this device from the system. May
#return EBUSY otherwise.
#
#DETACH_FORCE: Clients using the device must be disconnected,
#typically by revoking open file descriptors. May not
#return EBUSY due to client activitiy, but may return
#that or other errors due to hardware problems or
#limitations.
#
#DETACH_EJECTED: This call is made from a lower-level bus
#driver when the device has been physically removed from
#the system. Like DETACH_FORCE, except that drivers can
#avoid attemping (and failing) to reset the hardware
#state. This request must succeed.
#
METHOD int detach {
device_t dev;
int flags;
};
where each detach method call will now have a flags parameter
that provides enough information to handle the hot plug
scenarios you're describing.
In addition, the DETACH_FORCE and DETACH_EJECTED flags could
be mapped to appropriate flag values for the other subsystems, such
as MNT_FORCE and (a new) MNT_EJECTED flag for VFS.
i once included a umount -f in the detach hook. after unplugin' the
device, it resulted in a panic. i don't remember if the umount was
causing it or if it was right after, when accessing the mount point or
repluging the digital recorder.
Right, VFS needs to be clued in that the underlying device simply
isn't there anymore.
anyway, i learned that umount -f is not
meant to be used often... perhaps not on top of usb. for now.
umount -f is fine; however, it is not the same as the new
DETACH_EJECTED condition that I'm proposing, which would handle this.
i manually umount the device before unpluging it.
That is the only safe way to do it for now.
Eric
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
Le Mer 06/08/2003 17:55, Jan Stocker a crit : Does nobody has this problem or does noone use this feature? the problem i see with detach is the utility of the command. example: my digital photo recorder. i have an attach script to mount automatically the partition on the cooresponding umass/da device. works great, and this helps. but when detaching, the umount part should be done BEFORE detaching, not after. i can't find any good use for the detach hook. most of things should have been done before detaching, and i can't see how to do it without user interactivity, thus avoiding use of the detach hook. i once included a umount -f in the detach hook. after unplugin' the device, it resulted in a panic. i don't remember if the umount was causing it or if it was right after, when accessing the mount point or repluging the digital recorder. anyway, i learned that umount -f is not meant to be used often... perhaps not on top of usb. for now. i manually umount the device before unpluging it. my 2 cents... olivier ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
usbd does not use detach
Does nobody has this problem or does noone use this feature? Jan On Sat, 2003-08-02 at 14:47, Jan Stocker wrote: Hi, my usbd on -current does not call my script (or any command) given in the detach-value in usbd.conf. This is the output usbd: ucom0 matches ucom0 usbd: Found action 'Palm Handheld Device' for Palm Handheld, Palm, Inc. at ucom0usbd: action 0: Palm Handheld Device vndr=0x0830 prdct=0x0060 devname: ucom0 attach='/usr/sbin/ppp -auto palm' detach='/test.sh' usbd: Setting DEVNAME='ucom0' usbd: Executing '/usr/sbin/ppp -auto palm' Working in auto mode Using interface: tun0 usbd: '/usr/sbin/ppp -auto palm' is ok usbd: processing event queue on /dev/usb usbd: driver-detach event cookie=3217029340 devname=ucom0 USB_EVENT_DRIVER_DETACH P.S. i am tring to get my usb palm working with FreeBSD. The most prefered solution is doing this with a ppp connection and a network sync (all solutions i found in web are not correct but a good advice). Does anyone has a USB palm directly syncing over USB? -- Jan Stocker [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: usbd does not use detach
- --- usbd.c.orig Thu Aug 7 18:46:47 2003
+++ usbd.c Thu Aug 7 18:52:33 2003
@@ -911,7 +911,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)
It's here not a second attach output looks like the same:
[EMAIL PROTECTED]:/usr/src/usr.sbin/usbd $ /usr/sbin/usbd -c /etc/usbd.conf
-vvv -d usbd: opened /dev/usb0
usbd: reading configuration file /etc/usbd.conf
usbd: action 1: ActiveWire board, firmware download
vndr=0x0854 prdct=0x0100 rlse=0x
attach='/usr/local/bin/ezdownload -f
/usr/local/share/usb/firmware/0854.0100.0_01.hex ${DEVNAME}'
usbd: action 2: Entrega Serial with UART
vndr=0x1645 prdct=0x8001 rlse=0x0101
attach='/usr/sbin/ezdownload -v -f
/usr/share/usb/firmware/1645.8001.0101 /dev/${DEVNAME}'
usbd: action 3: USB ethernet
devname: [ackr]ue[0-9]+
attach='/etc/pccard_ether ${DEVNAME} start'
detach='/etc/pccard_ether ${DEVNAME} stop'
usbd: action 4: Handspring Visor
vndr=0x082d prdct=0x0100 rlse=0x0100
devname: ugen[0-9]+
attach='/usr/local/bin/coldsync -md -p /dev/${DEVNAME} -t usb'
usbd: action 5: Mouse
devname: ums[0-9]+
attach='/usr/sbin/moused -p /dev/${DEVNAME} -I
/var/run/moused.${DEVNAME}.pid ; /usr/sbin/vidcontrol -m on'
usbd: action 6: Palm Handheld Device
vndr=0x0830 prdct=0x0060
devname: ucom0
attach='/usr/sbin/ppp -auto palm'
detach='/test.sh'
usbd: action 7: USB device
usbd: 7 actions
usbd: opened /dev/usb
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 1060502709.481417000, Palm Handheld, Palm,
Inc.:
vndr=0x0830 prdct=0x0060 rlse=0x0100 clss=0x subclss=0x
prtcl=0x
device names: ucom0
usbd: ucom0 matches ucom0
usbd: Found action 'Palm Handheld Device' for Palm Handheld, Palm, Inc.
at ucom0
usbd: action 0: Palm Handheld Device
vndr=0x0830 prdct=0x0060
devname: ucom0
attach='/usr/sbin/ppp -auto palm'
detach='/test.sh'
usbd: Setting DEVNAME='ucom0'
usbd: Executing '/usr/sbin/ppp -auto palm'
Working in auto mode
Using interface: tun0
Warning: No default entry found in config file.
usbd: '/usr/sbin/ppp -auto palm' is ok
usbd: processing event queue on /dev/usb
usbd: driver-detach event cookie=3217029324 devname=ucom0
USB_EVENT_DRIVER_DETACH
usbd: doing timeout discovery on /dev/usb0
usbd: processing event queue due to timeout on /dev/usb
usbd: doing timeout discovery on /dev/usb0
usbd: processing event queue due to timeout on /dev/usb
usbd: doing timeout discovery on /dev/usb0
usbd: processing event queue due to timeout on /dev/usb
--
Jan Stocker [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
usbd does not use detach
Hi, my usbd on -current does not call my script (or any command) given in the detach-value in usbd.conf. This is the output usbd: ucom0 matches ucom0 usbd: Found action 'Palm Handheld Device' for Palm Handheld, Palm, Inc. at ucom0usbd: action 0: Palm Handheld Device vndr=0x0830 prdct=0x0060 devname: ucom0 attach='/usr/sbin/ppp -auto palm' detach='/test.sh' usbd: Setting DEVNAME='ucom0' usbd: Executing '/usr/sbin/ppp -auto palm' Working in auto mode Using interface: tun0 usbd: '/usr/sbin/ppp -auto palm' is ok usbd: processing event queue on /dev/usb usbd: driver-detach event cookie=3217029340 devname=ucom0 USB_EVENT_DRIVER_DETACH P.S. i am tring to get my usb palm working with FreeBSD. The most prefered solution is doing this with a ppp connection and a network sync (all solutions i found in web are not correct but a good advice). Does anyone has a USB palm directly syncing over USB? -- Jan Stocker [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
