kernel panic trying to utilize a da(4)/umass(4) device with
ohci(4)
Brian F. Feldman
green at freebsd.org
Sat Nov 22 05:08:31 PST 2003
Bernd Walter <ticso at cicely12.cicely.de> wrote:
> On Fri, Nov 21, 2003 at 12:35:50PM -0500, Brian F. Feldman wrote:
> > Doug White <dwhite at gumbysoft.com> 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.
>
> NetBSD is different in that point.
>
> > > 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...
>
> We never did any page crossing on ohci/ehci bevor the newbus change
> took place.
Found it!!! Definitely a problem created then...
--- ohci.c 12 Nov 2003 01:40:11 -0000 1.138
+++ ohci.c 22 Nov 2003 03:28:42 -0000
@@ -569,7 +569,7 @@
cur->td.td_cbp = htole32(dataphys);
cur->nexttd = next;
cur->td.td_nexttd = htole32(next->physaddr);
- cur->td.td_be = htole32(DMAADDR(dma, curlen - 1));
+ cur->td.td_be = htole32(DMAADDR(dma, offset + curlen - 1));
cur->len = curlen;
cur->flags = OHCI_ADD_LEN;
cur->xfer = xfer;
I'm a lot happier now :-) Let's start trying to get this stuff merged in!
--
Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\
<> green at FreeBSD.org \ The Power to Serve! \
Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\
More information about the freebsd-current
mailing list