From owner-freebsd-sparc64@FreeBSD.ORG Mon Sep 13 12:12:28 2010 Return-Path: Delivered-To: freebsd-sparc64@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id E5175106566B for ; Mon, 13 Sep 2010 12:12:28 +0000 (UTC) (envelope-from hselasky@c2i.net) Received: from swip.net (mailfe04.swip.net [212.247.154.97]) by mx1.freebsd.org (Postfix) with ESMTP id 602CD8FC14 for ; Mon, 13 Sep 2010 12:12:28 +0000 (UTC) X-Cloudmark-Score: 0.000000 [] X-Cloudmark-Analysis: v=1.1 cv=69M7SDRZ/3ZqjvOQolLkvw049hoMKehWXnTrnU8tixs= c=1 sm=1 a=8nJEP1OIZ-IA:10 a=M8b_wTzEtboA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:17 a=zD0lzIT9esXgrWn00U8A:9 a=kArs88BzmppyMRhEtRkA:7 a=Ve0h1KrDDjke8kjpi64QhR0w1jgA:4 a=wPNLvfGTeEIA:10 a=MnI1ikcADjEx7bvsp0jZvQ==:117 Received: from [188.126.201.140] (account mc467741@c2i.net HELO laptop002.hselasky.homeunix.org) by mailfe04.swip.net (CommuniGate Pro SMTP 5.2.19) with ESMTPA id 20648501; Mon, 13 Sep 2010 14:02:00 +0200 From: Hans Petter Selasky To: Marius Strobl Date: Mon, 13 Sep 2010 13:58:23 +0200 User-Agent: KMail/1.13.5 (FreeBSD/8.1-STABLE; KDE/4.4.5; amd64; ; ) References: <20100725143252.GV21929@gradx.cs.jhu.edu> <201007260859.20501.hselasky@c2i.net> <20100912182214.GA90233@alchemy.franken.de> In-Reply-To: <20100912182214.GA90233@alchemy.franken.de> X-Face: +~\`s("[*|O,="7?X@L.elg*F"OA\I/3%^p8g?ab%RN'(; _IjlA: hGE..Ew, XAQ*o#\/M~SC=S1-f9{EzRfT'|Hhll5Q]ha5Bt-s|oTlKMusi:1e[wJl}kd}GR Z0adGx-x_0zGbZj'e(Y[(UNle~)8CQWXW@:DX+9)_YlB[tIccCPN$7/L' MIME-Version: 1.0 Content-Type: Text/Plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <201009131358.24323.hselasky@c2i.net> Cc: Nathaniel W Filardo , freebsd-sparc64@freebsd.org Subject: Re: VIMAGE hang, USB panic X-BeenThere: freebsd-sparc64@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting FreeBSD to the Sparc List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 13 Sep 2010 12:12:29 -0000 On Sunday 12 September 2010 20:22:14 Marius Strobl wrote: > On Mon, Jul 26, 2010 at 08:59:20AM +0200, Hans Petter Selasky wrote: > > On Sunday 25 July 2010 16:32:52 Nathaniel W Filardo wrote: > > > Speaking of USB hotplug, attaching a micro 4-port hub, I get this (both > > > with and without VIMAGE): > > > > > > ugen0.2: at usbus0 > > > uhub1: on > > > usbus0 > > > panic: iommu_dvmamap_create: bogus preallocation size , nsegments = 2, > > > maxpre = 2, maxsize = 1 > > > cpuid = 0 > > > > > KDB: stack backtrace: > > Hi, > > > > Looks like the following check fails. The allocation size USB requests is > > 1- byte. For the check to not fail, we need to request more bytes then > > the max- segments parameter specified. > > Or decrease the nsegments parameter. I think that the sanity check is > right and the parameters supplied are bogus as 1 byte cannot be split > across 2 segments. > > > maxpre = imin(dt->dt_nsegments, IOMMU_MAX_PRE_SEG); > > presz = dt->dt_maxsize / maxpre; > > KASSERT(presz != 0, ("%s: bogus preallocation size , nsegments = > > %d, " > > > > "maxpre = %d, maxsize = %lu", __func__, dt->dt_nsegments, > > maxpre, dt->dt_maxsize)); > > > > Does not look like a problem in the USB stack. > > I think it is as the maxsize and nsegments parameters supplied in this > case make no sense. Moreover, maxsegsz should be <= maxsize, thus I'd > like to commit the following change: Hi, Yes, the values supplied are not too tight. The patch you've made to usb_busdma.c seems OK to me. > > Index: usb_busdma.c > =================================================================== > --- usb_busdma.c (revision 212478) > +++ usb_busdma.c (working copy) > @@ -366,9 +366,9 @@ usb_dma_tag_create(struct usb_dma_tag *udt, > /* filter */ NULL, > /* filterarg */ NULL, > /* maxsize */ size, > - /* nsegments */ (align == 1) ? > + /* nsegments */ (align == 1 && size > 1) ? > (2 + (size / USB_PAGE_SIZE)) : 1, > - /* maxsegsz */ (align == 1) ? > + /* maxsegsz */ (align == 1 && size > USB_PAGE_SIZE) ? > USB_PAGE_SIZE : size, > /* flags */ BUS_DMA_KEEP_PG_OFFSET, > /* lockfn */ &usb_dma_lock_cb, > > Why is this using one more segment than splitting size in USB_PAGE_SIZE > sized segments btw? > If this isn't actually needed then replacing the 2 > with a 1 would be the more preferable fix IMO. We are using 2 because a virtual memory load operation of less than USB_PAGE_SIZE, can be split accross two pages at maximum. > > However, specifying such small allocation sizes together with > BUS_SPACE_UNRESTRICTED as nsegments, which unlike what usb(4) > currently does the I'd would consider as valid combinations, > will also trigger this assertion, so I'll remove it. It is usually not allocation that are of this size, but rather DMA load mappings. --HPS