From owner-freebsd-current Thu Dec 19 15:24:33 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id AC7A337B7BF for ; Thu, 19 Dec 2002 15:24:31 -0800 (PST) Received: from rootlabs.com (root.org [67.118.192.226]) by mx1.FreeBSD.org (Postfix) with SMTP id C48F643EDE for ; Thu, 19 Dec 2002 15:24:27 -0800 (PST) (envelope-from nate@rootlabs.com) Received: (qmail 60491 invoked by uid 1000); 19 Dec 2002 23:24:28 -0000 Date: Thu, 19 Dec 2002 15:24:28 -0800 (PST) From: Nate Lawson To: ticso@cicely.de Cc: freebsd-current@FreeBSD.ORG Subject: Re: UMASS USB bug? (getting the Sony disk-on-key device working). In-Reply-To: <20021219172612.GI29286@cicely8.cicely.de> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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: port 0x1800-0x181f irq 11 at device 29.0 on pci0 uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 uhci2: 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