From owner-freebsd-current@FreeBSD.ORG Fri Nov 21 09:35:52 2003 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from green.bikeshed.org (freefall.freebsd.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id E35C116A4CE; Fri, 21 Nov 2003 09:35:51 -0800 (PST) Received: from green.bikeshed.org (green@pcp04368313pcs.nrockv01.md.comcast.net [69.140.209.127]) by green.bikeshed.org (8.12.10/8.12.9) with ESMTP id hALHZp6p009642; Fri, 21 Nov 2003 12:35:51 -0500 (EST) (envelope-from green@green.bikeshed.org) Received: from localhost (green@localhost)hALHZos7009639; Fri, 21 Nov 2003 12:35:51 -0500 (EST) Message-Id: <200311211735.hALHZos7009639@green.bikeshed.org> X-Mailer: exmh version 2.6.3 04/04/2003 with nmh-1.0.4 To: Doug White In-Reply-To: Message from Doug White <20031121090802.Y57910@carver.gumbysoft.com> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 21 Nov 2003 12:35:50 -0500 Sender: green@green.bikeshed.org 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:35:52 -0000 Doug White wrote: > The OHCI driver is largely synced with NetBSD so you might see if they > have the same bug. I'll look around for a bootable NetBSD CD. > 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. Is there a way to add a quirk for max 8k transfers or anything? Even though that would be patently lame, I'd like to get some sort of workaround here. I don't even know what is supposed to be the problem here -- the fact that it's an ohci controller, an ohci+ehci controller, or that it's some specific controller issue... > 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. Hmm :-/ I wonder if anyone could interpret the debugging info enough to have an idea what it's disliking for certain. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\