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 happy.
-Kevin