On Thu, Dec 19, 2002 at 03:24:28PM -0800, Nate Lawson wrote: > On Thu, 19 Dec 2002, Bernd Walter wrote: > > On Thu, Dec 19, 2002 at 09:06:19AM -0800, Matthew Dillon wrote: > > > The panic described in 46176 has happened to me on -current. On > > > -stable I have managed (very easily) to get the CAM layer vs UMASS > > > layer into a confused state where the CAM layer thinks it is still > > > attached but the UMASS layer thinks it has detached / cleaned everything > > > out. In both cases it appears that memory is being freed by one side > > > which is still being used by the other side but I haven't tracked down > > > the exact cause. > > > > The umass driver uses a single sim for all umass devices. > > There are a lot of workarounds and bugs introduced because of this. > > Also there is a small static limit (IIRC 3) in the number of instances > > supported. > > [...] > > My intention is to rewrite the parts of umass to use multiple sims > > so LUNs and many instances actually work and hopefully a lot of other > > problems like this can be solved too. > > A SIM is meant to represent a single bus which multiple periphs can attach > to. So on my laptop, which has multiple USB controllers, should call > cam_sim_alloc() 3 times:
No there is no direct relation to an usb bus and a sim. Each umass class device should have a sim on each own independend on which (usb)-bus it belongs. It is true that a SIM is meant to represent a bus, but the SCSI bus is with the umass entity. That is the same reason why two SCSI PCI cards have SIMs on each own even they could be on the same PCI bus. > uhci0: <Intel 82801CA/CAM (ICH3) USB controller USB-A> port 0x1800-0x181f > irq 11 at device 29.0 on pci0 > uhci1: <Intel 82801CA/CAM (ICH3) USB controller USB-B> port 0x1820-0x183f > irq 11 at device 29.1 on pci0 > uhci2: <Intel 82801CA/CAM (ICH3) USB controller USB-C> port 0x1840-0x185f > irq 11 at device 29.2 on pci0 > > Right now though, cam_sim_alloc() is called once when the first umass > device is detected and all devices are attached there. This is done so > that the target id can be a primary key to lookup the softc (via > devclass_get_softc). This is unnecessary since a pointer to the softc can > be stashed in the sim_priv area and since umass_cam_action gets called > with *sim, this is readily available. Right. > The static limit is 32 normally, 3 in the USB_DEBUG case. This is not a > CAM limitation. If umass used CAM properly, LUNs would not be a problem. And what if I want to connect 40 umass devices - possibly on the same usb bus? No it is not a CAM problem - it's a problem on the cam interface implementation in the umass driver. LUNs on umass currently don't work. E.g. there are many workarounds to handle disconection of devices. If you attach an USB device you effectively add new ID to a simulated bus and then we trigger cam to rescan the whole virtual bus. The same happens when a device gets disconnected. A special handling has to be done for the last device, because without it the virtual bus is removed and can't be rescanned. It would be much easier to just connect and disconnect a bus on each own for each umass device - even if a umass device can only have a single ID. That LUNs don't work has something to do that the code is stuffed with special handling for case introduced because of the single sim handling - in fact CAM knows the correct number of available LUNs and scans for all of them but the umass driver failed to handle them correctly. It has become difficult to maintain without good reasons. Well - it's possible to add another hack to get LUNs working, but I prefer a new basic design. I believe the cause for this design is that the cam interfacing was taken from the vpo driver which itself was designed for a single ZIP drive. > There are many ways USB interacts with CAM that are sub-optimal and > sometimes incorrect. I haven't had time to immerse myself in USB-land and > am pursuing updates to CAM to handle many different transport types > instead of hacking what is there in current implementations of > USB/1394/... (i.e. multiple duplicate cdb xlation routines) Exactly that's what SIMs should do - abstract the transport layer. And the transport layer for umass is SCSI/BBB and others. -- B.Walter COSMO-Project http://www.cosmo-project.de [EMAIL PROTECTED] Usergroup [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
