From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 09:11:35 2003 Return-Path: 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 0969516A4CE; Fri, 21 Nov 2003 09:11:35 -0800 (PST) Received: from carver.gumbysoft.com (carver.gumbysoft.com [66.220.23.50]) by mx1.FreeBSD.org (Postfix) with ESMTP id 07E0543FB1; Fri, 21 Nov 2003 09:11:34 -0800 (PST) (envelope-from dwhite@gumbysoft.com) Received: by carver.gumbysoft.com (Postfix, from userid 1000) id ED84D72DB8; Fri, 21 Nov 2003 09:11:33 -0800 (PST) Received: from localhost (localhost [127.0.0.1]) by carver.gumbysoft.com (Postfix) with ESMTP id EB4A072DAD; Fri, 21 Nov 2003 09:11:33 -0800 (PST) Date: Fri, 21 Nov 2003 09:11:33 -0800 (PST) From: Doug White To: "Brian F. Feldman" In-Reply-To: <200311210309.hAL39X6Y001205@green.bikeshed.org> Message-ID: <20031121090802.Y57910@carver.gumbysoft.com> References: <200311210309.hAL39X6Y001205@green.bikeshed.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII cc: Josef Karthauser cc: Ian Dowse cc: current@FreeBSD.org Subject: Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 21 Nov 2003 17:11:35 -0000 The OHCI driver is largely synced with NetBSD so you might see if they have the same bug. This might be the underlying wierdness we were seeing in gtetlow's microdrive with transfers over 8k. The one-page-crossing ohci limitation is really annoying. On Thu, 20 Nov 2003, Brian F. Feldman wrote: > Thanks for the patches to try! They unfortunately didn't fix the crash I > have, but I found out why it's occurring. > > See ohci.c:1389: > if (std->td.td_cbp != 0) > len -= le32toh(std->td.td_be) - > le32toh(std->td.td_cbp) + 1; > > In one of my transfers (look in my log for the 2560 byte one) that statement > actually adds 8192 to len, which is utterly bogus because you can see it > only allocates 2560 -- hence when it tries to finish the transfer it > memcpy()'s way too much memory and my kernel segfaults. If I #if 0 this out, > I'm left only with "umass0: BBB reset failed, STALLED" messages... which is > a lot better than before! I don't know under what situations that bit of > code makes sense, but it definitely needs more reviewing! Stalls usually come from the device receiving bad data. Rather than return errors, usb generally just hangs the endpoint. -- Doug White | FreeBSD: The Power to Serve dwhite@gumbysoft.com | www.FreeBSD.org