[SeaBIOS] usb ohci pipe free fix

Kevin O'Connor kevin at koconnor.net
Thu Mar 8 03:38:21 CET 2012

On Wed, Mar 07, 2012 at 10:51:34PM +0100, Nils wrote:
> Op dinsdag 06-03-2012 om 22:25 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > You could try, dumping the value of cntl->regs->periodicstart and
> > cntl->regs->fminterval at the end of start_ohci() to see if there's
> > something odd there.
> > 
> > You could also try setting the Skip bit in ohci_alloc_intr_pipe
> > (ed->hwINFO |= ED_SKIP) to see if the issue is with the TDs or EDs.
> > You could also try replacing malloc_low calls with malloc_high calls
> > in ohci_alloc_intr_pipe to see if maybe the controller doesn't like
> > the memory addresses.
> Ok now i have some results!
> With the original ohci pipe free fix and the 3 malloc's changed to
> malloc_high the controller seems to keep running. :)
> There is probably also another problem.(see attached log)
> While booting i did not touch the keyboard, but it received (partly
> unknown) keycodes.
> At the end of the log SeaBIOS crashed.
> This sequence is reproducible at every boot.
> When i unplug the keyboard then boot and then plug in again after
> SeaBIOS finished, then linux runs fine. 

Oh - it definitely wont work with it changed to malloc_high.  The test
is just to see if the controller continues to freeze with it that way.
It looks like the timeouts went away, which would indicate that your
USB chip has some problems DMAing to low memory.  Definitely sounds
like a chip bug.  Best way to confirm that would be to repost the log
with the malloc_high change on top of the debugging patch I last sent.

Another test you could do would be to change the allocations back to
"malloc_low()" but as "malloc_low() + 0x50000" to see if moving the
allocations from the 9-segment to the e-segment makes the controller


More information about the SeaBIOS mailing list