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
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]
PATCH: move cardbus container to pci devclass
Hello I have made a patch for -CURRENT and 5.1-RELEASE that hopefully improves the support for Cardbus devices by changing the cardbus driver to implement the pci devclass rather than the cardbus devclass, and to make their unit numbers correspond with the PCI secondary bus numbers that their bridges are assigned. This has a number of advantages: - User mode tools that interface with the /dev/pci interface such as pciconf and lspci (from ports) are now able to access Cardbus devices without modifications. - PCI drivers no longer need an additional driver declaration in order to support cardbus, e.g., in ./pci/if_xl.c:DRIVER_MODULE(xl, cardbus, xl_driver, xl_devclass, 0, 0); ./pci/if_xl.c:DRIVER_MODULE(xl, pci, xl_driver, xl_devclass, 0, 0); only the second line is required. (The first is harmless though.) - Because the unit numbers in the pci devclass now represent the PCI bus numbers in use in the system, we now have a good way of assigning bus numbers to the Cardbus bridges in lieu of the PCI BIOS doing so, which is not something we can expect all BIOSes to do. (The old code incremented a static counter starting from 2 by 3 every time this condition occurred, which wasn't correct because there could already be a pci2 in the system, and the counter would eventually recycle.) And a couple of potential drawbacks: - Drivers that need to behave differently for Cardbus devices can't do so by declaring another driver_t specifically for cardbus. (No driver that I'm aware of does this, however; they all use the same driver_t.) - Users that are accustomed to newbus nameunits containing descriptive information about devices may prefer to see, for example, cardbus0 rather than pci2. Note that using newbus in this way defeats a good deal of its potential for object-oriented design. The patches are at http://users.erols.com/eaja/cardbus51.diff http://users.erols.com/eaja/cardbuscurrent.diff Any comments? Thanks, Eric ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cardbus and xircom ethernet problem
On Sun, 22 Jun 2003 13:39:05 +0100 (BST) Matt [EMAIL PROTECTED] wrote: I have just tried this and this puts the machine in a hard lock with CISTPL_NONE 00 scrolling up the screen constantly until after 30 seconds or so it panics with page fault 12 in cbb0. I have a card which does this in NEWCARD. It works fine in OLDCARD. I would say try OLDCARD on your card, and if it works, maybe we can figure out what it is about the CIS in these cards that's throwing the parser. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LG 5350 cell phone
--- Josef Karthauser [EMAIL PROTECTED] wrote: An easy project for someone would be to write a general usb querying tool for displaying the classes, etc that a usb device supports. I've got code kicking around, mostly from Nick Hibma, but I never got around to finishing it off. There's usb_dump on Nick's site: http://www.etla.net/~n_hibma/usb/usb_dump.c The identifiers have been renamed, so it needs a patch http://users.erols.com/eaja/fbsd/usb_dump.diff usb_dump -D -f /dev/ugen0 will dump device, configuration, interface, and endpoint descriptors for ugen0. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
