Re: kernel panic trying to utilize a da(4)/umass(4) device with ohci(4)

"Brian F. Feldman" <green_at_FreeBSD.org> 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!
> 
> Please check out my debugging messages and tell me if you see any hints as 
> to why the transfers are getting stalled.  I should have looked at the 
> debugging messages long ago, I guess.   Thanks!
> 
> http://green.homeunix.org/~green/ohci-debugging.txt.gz

BTW, replying to myself -- it seems to be something missing from the 
multi-allocation transfers (>8KB), because I can do up to 8KB transfers 
perfectly fine now, but 10KB ones, for example, like mdir(8) does are the 
ones that give me BBB stalls.

-- 
Brian Fundakowski Feldman                           \'[ FreeBSD ]''''''''''\
  <> green_at_FreeBSD.org                               \  The Power to Serve! \
 Opinions expressed are my own.                       \,,,,,,,,,,,,,,,,,,,,,,\