Date: Thu, 19 Dec 2002 15:24:28 -0800 (PST) From: Nate Lawson <nate@root.org> To: ticso@cicely.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working). Message-ID: <Pine.BSF.4.21.0212191452040.60085-100000@root.org> In-Reply-To: <20021219172612.GI29286@cicely8.cicely.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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:
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.
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.
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)
-Nate
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0212191452040.60085-100000>