Re: [SeaBIOS] usb ohci pipe free fix

[Kevin O'Connor]

On Sun, Mar 04, 2012 at 12:44:01AM +0100, Nils wrote:
> Op woensdag 22-02-2012 om 20:48 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > That's odd.  It looks like the controller was running for 236ms and
> > then freezes.  The only thing I can think of to track this down is to
> > sprinkle dprintf() statements through the code until we find what
> > caused the controller to stop.
>
> The controller freezes after the the lines 487 + 488 in usb-ohci.c:
> >    for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms)
> >        hcca->int_table[i] = (u32)ed;
>
> If i comment them out the controller doesn't freeze anymore and the
> timeout disappears.
> Do you have a another suggestion or patch i could test?

I don't see anything wrong with the above code.  (The barrier() should
be moved, but I don't see that causing the problems you're seeing.)

Getting more info may help.  Something like the below.

Another thing you could try is forcing the "if (frameexp == 0)" branch
(by, for example, changing it to "if (1 || frameexp == 0)".

-Kevin

--- a/src/usb-ohci.c
+++ b/src/usb-ohci.c
@@ -482,18 +496,22 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp)
     }

// Add to interrupt schedule.
-    barrier();
     struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
     if (frameexp == 0) {
         // Add to existing interrupt entry.
         struct ohci_ed *intr_ed = (void*)hcca->int_table[0];
         ed->hwNextED = intr_ed->hwNextED;
+        barrier();
         intr_ed->hwNextED = (u32)ed;
     } else {
         int startpos = 1<<(frameexp-1);
         ed->hwNextED = hcca->int_table[startpos];
-        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms)
+        dprintf(1, "update h=%p s=%d ms=%d ed=%p\n", hcca, startpos, ms, ed);
+        barrier();
+        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) {
+            dprintf(1, "u i=%d o=%x n=%p\n", i, hcca->int_table[i], ed);
             hcca->int_table[i] = (u32)ed;
+        }
     }

return &pipe->pipe;

usb ohci pipe free fix

[Nils]

Hi kevin,
Op zaterdag 03-03-2012 om 22:33 uur [tijdzone -0500], schreef Kevin
O'Connor:
> I don't see anything wrong with the above code.  (The barrier() should
> be moved, but I don't see that causing the problems you're seeing.)
>
> Getting more info may help.  Something like the below.

See ohci_test2.log
> Another thing you could try is forcing the "if (frameexp == 0)" branch
> (by, for example, changing it to "if (1 || frameexp == 0)".

With that branch forced i get the same timeout as before. 
See ohci_test3.log

Thanks, Nils.

usb ohci pipe free fix

[Kevin O'Connor]

On Sun, Mar 04, 2012 at 10:42:45PM +0100, Nils wrote:
> Hi kevin,
> Op zaterdag 03-03-2012 om 22:33 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > I don't see anything wrong with the above code.  (The barrier() should
> > be moved, but I don't see that causing the problems you're seeing.)
> >
> > Getting more info may help.  Something like the below.
>
> See ohci_test2.log
> > Another thing you could try is forcing the "if (frameexp == 0)" branch
> > (by, for example, changing it to "if (1 || frameexp == 0)".
>
> With that branch forced i get the same timeout as before. 
> See ohci_test3.log

Nothing looks wrong in the code.  I suppose one of the transfer
descriptors could have confused the controller.  You could try the
patch below (apply this on top of the "ohci pipe free fix" at the
start of this thread).  It would help if your logs had timing info
(via readserial.py).

I'm really just guessing at this point.  I'm pretty much at a loss for
why your controller just shuts down.

-Kevin

diff --git a/src/usb-ohci.c b/src/usb-ohci.c
index 7a437ad..4e020cb 100644
--- a/src/usb-ohci.c
+++ b/src/usb-ohci.c
@@ -123,6 +123,8 @@ ohci_waittick(struct usb_ohci_s *cntl)
 {
     barrier();
     struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "ohci wait: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     u32 startframe = hcca->frame_no;
     u64 end = calc_future_tsc(1000 * 5);
     for (;;) {
@@ -130,6 +132,8 @@ ohci_waittick(struct usb_ohci_s *cntl)
             break;
         if (check_tsc(end)) {
             warn_timeout();
+    dprintf(1, "ohci to: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
             return;
         }
         yield();
@@ -141,11 +145,16 @@ ohci_free_pipes(struct usb_ohci_s *cntl)
 {
     dprintf(7, "ohci_free_pipes %p\n", cntl);

+    struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "ohci fp: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     u32 creg = readl(&cntl->regs->control);
     if (creg & (OHCI_CTRL_CLE|OHCI_CTRL_BLE)) {
         writel(&cntl->regs->control, creg & ~(OHCI_CTRL_CLE|OHCI_CTRL_BLE));
         ohci_waittick(cntl);
     }
+    dprintf(1, "ohci fp2: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);

u32 *pos = &cntl->regs->ed_controlhead;
     for (;;) {
@@ -214,6 +223,9 @@ start_ohci(struct usb_ohci_s *cntl, struct ohci_hcca *hcca)
               | OHCI_USB_OPER | oldrwc));
     readl(&cntl->regs->control); // flush writes

+    dprintf(1, "ohci init: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
+
     return 0;
 }

@@ -322,6 +334,8 @@ wait_ed(struct ohci_ed *ed)
 void
 ohci_free_pipe(struct usb_pipe *pipe)
 {
+    if (! CONFIG_USB_OHCI)
+        return;
     // Add to controller's free list.
     struct usb_s *cntl = pipe->cntl;
     pipe->freenext = cntl->freelist;
@@ -463,6 +477,7 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp)
     if (!pipe || !tds || !data)
         goto err;
     memset(pipe, 0, sizeof(*pipe));
+    memset(tds, 0, sizeof(*tds) * count);
     memcpy(&pipe->pipe, dummy, sizeof(pipe->pipe));
     pipe->data = data;
     pipe->count = count;
@@ -482,20 +497,33 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp)
     }

// Add to interrupt schedule.
-    barrier();
     struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "add1: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     if (frameexp == 0) {
         // Add to existing interrupt entry.
         struct ohci_ed *intr_ed = (void*)hcca->int_table[0];
         ed->hwNextED = intr_ed->hwNextED;
+        barrier();
         intr_ed->hwNextED = (u32)ed;
     } else {
         int startpos = 1<<(frameexp-1);
         ed->hwNextED = hcca->int_table[startpos];
-        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms)
+        dprintf(1, "update h=%p s=%d ms=%d ed=%p\n", hcca, startpos, ms, ed);
+        barrier();
+        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) {
+            dprintf(1, "u i=%d o=%x n=%p\n", i, hcca->int_table[i], ed);
             hcca->int_table[i] = (u32)ed;
+        }
     }

+    msleep(100);
+    dprintf(1, "add2: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
+    for (i=0; i<count; i++)
+        dprintf(1, "td %d: %08x %08x %08x %08x\n"
+                , i, tds[i].hwINFO, tds[i].hwCBP, tds[i].hwNextTD, tds[i].hwBE);
+
     return &pipe->pipe;

err:
@@ -522,6 +550,9 @@ ohci_poll_intr(struct usb_pipe *p, void *data)
     if (head == next)
         // No intrs found.
         return -1;
+    dprintf(1, "Got ohci data %d: %08x %08x %08x %08x\n"
+            , pos, GET_FLATPTR(next->hwINFO), GET_FLATPTR(next->hwCBP)
+            , GET_FLATPTR(next->hwNextTD), GET_FLATPTR(next->hwBE));
     // XXX - check for errors.

// Copy data.

usb ohci pipe free fix

[Nils]

Op zondag 04-03-2012 om 19:04 uur [tijdzone -0500], schreef Kevin
O'Connor:
> Nothing looks wrong in the code.  I suppose one of the transfer
> descriptors could have confused the controller.  You could try the
> patch below (apply this on top of the "ohci pipe free fix" at the
> start of this thread).  It would help if your logs had timing info
> (via readserial.py).

See attached log.
> I'm really just guessing at this point.  I'm pretty much at a loss for
> why your controller just shuts down.

I appreciate your help, you know more about it than me.

My controller is the AMD CS5536.

Thanks, Nils.

usb ohci pipe free fix

[Kevin O'Connor]

On Mon, Mar 05, 2012 at 07:20:02PM +0100, Nils wrote:
> Op zondag 04-03-2012 om 19:04 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > Nothing looks wrong in the code.  I suppose one of the transfer
> > descriptors could have confused the controller.  You could try the
> > patch below (apply this on top of the "ohci pipe free fix" at the
> > start of this thread).  It would help if your logs had timing info
> > (via readserial.py).
>
> See attached log.

Nothing in the TD.  Can you try the patch below (again, on top of the
free pipe fix at the beginning of this thread).  This patch will also
dump the ED.

Another thing you could try is to post the log with the call to
set_idle() in usb-hid.c commented out.

-Kevin

diff --git a/src/usb-ohci.c b/src/usb-ohci.c
index 7a437ad..3670583 100644
--- a/src/usb-ohci.c
+++ b/src/usb-ohci.c
@@ -123,6 +123,8 @@ ohci_waittick(struct usb_ohci_s *cntl)
 {
     barrier();
     struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "ohci wait: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     u32 startframe = hcca->frame_no;
     u64 end = calc_future_tsc(1000 * 5);
     for (;;) {
@@ -130,6 +132,8 @@ ohci_waittick(struct usb_ohci_s *cntl)
             break;
         if (check_tsc(end)) {
             warn_timeout();
+    dprintf(1, "ohci to: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
             return;
         }
         yield();
@@ -141,11 +145,16 @@ ohci_free_pipes(struct usb_ohci_s *cntl)
 {
     dprintf(7, "ohci_free_pipes %p\n", cntl);

+    struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "ohci fp: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     u32 creg = readl(&cntl->regs->control);
     if (creg & (OHCI_CTRL_CLE|OHCI_CTRL_BLE)) {
         writel(&cntl->regs->control, creg & ~(OHCI_CTRL_CLE|OHCI_CTRL_BLE));
         ohci_waittick(cntl);
     }
+    dprintf(1, "ohci fp2: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);

u32 *pos = &cntl->regs->ed_controlhead;
     for (;;) {
@@ -214,6 +223,9 @@ start_ohci(struct usb_ohci_s *cntl, struct ohci_hcca *hcca)
               | OHCI_USB_OPER | oldrwc));
     readl(&cntl->regs->control); // flush writes

+    dprintf(1, "ohci init: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
+
     return 0;
 }

@@ -322,6 +334,8 @@ wait_ed(struct ohci_ed *ed)
 void
 ohci_free_pipe(struct usb_pipe *pipe)
 {
+    if (! CONFIG_USB_OHCI)
+        return;
     // Add to controller's free list.
     struct usb_s *cntl = pipe->cntl;
     pipe->freenext = cntl->freelist;
@@ -463,6 +477,7 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp)
     if (!pipe || !tds || !data)
         goto err;
     memset(pipe, 0, sizeof(*pipe));
+    memset(tds, 0, sizeof(*tds) * count);
     memcpy(&pipe->pipe, dummy, sizeof(pipe->pipe));
     pipe->data = data;
     pipe->count = count;
@@ -482,20 +497,37 @@ ohci_alloc_intr_pipe(struct usb_pipe *dummy, int frameexp)
     }

// Add to interrupt schedule.
-    barrier();
     struct ohci_hcca *hcca = (void*)cntl->regs->hcca;
+    dprintf(1, "add1: c=%x h=%p f=%d s=%x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus);
     if (frameexp == 0) {
         // Add to existing interrupt entry.
         struct ohci_ed *intr_ed = (void*)hcca->int_table[0];
         ed->hwNextED = intr_ed->hwNextED;
+        barrier();
         intr_ed->hwNextED = (u32)ed;
     } else {
         int startpos = 1<<(frameexp-1);
         ed->hwNextED = hcca->int_table[startpos];
-        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms)
+        dprintf(1, "update h=%p s=%d ms=%d ed=%p %08x %08x %08x %08x\n"
+                , hcca, startpos, ms, ed
+                , ed->hwINFO, ed->hwTailP, ed->hwHeadP, ed->hwNextED);
+        barrier();
+        for (i=startpos; i<ARRAY_SIZE(hcca->int_table); i+=ms) {
             hcca->int_table[i] = (u32)ed;
+            dprintf(1, "u i=%d o=%x n=%p f=%d\n"
+                    , i, hcca->int_table[i], ed, hcca->frame_no);
+        }
     }

+    msleep(100);
+    dprintf(1, "add2: c=%x h=%p f=%d s=%x  ed=%08x %08x %08x %08x\n"
+            , cntl->regs->control, hcca, hcca->frame_no, cntl->regs->intrstatus
+            , ed->hwINFO, ed->hwTailP, ed->hwHeadP, ed->hwNextED);
+    for (i=0; i<count; i++)
+        dprintf(1, "td %d: %08x %08x %08x %08x\n"
+                , i, tds[i].hwINFO, tds[i].hwCBP, tds[i].hwNextTD, tds[i].hwBE);
+
     return &pipe->pipe;

err:
@@ -522,6 +554,9 @@ ohci_poll_intr(struct usb_pipe *p, void *data)
     if (head == next)
         // No intrs found.
         return -1;
+    dprintf(1, "Got ohci data %d: %08x %08x %08x %08x\n"
+            , pos, GET_FLATPTR(next->hwINFO), GET_FLATPTR(next->hwCBP)
+            , GET_FLATPTR(next->hwNextTD), GET_FLATPTR(next->hwBE));
     // XXX - check for errors.

// Copy data.

usb ohci pipe free fix

[Nils]

Op maandag 05-03-2012 om 15:41 uur [tijdzone -0500], schreef Kevin
O'Connor:
> Nothing in the TD.  Can you try the patch below (again, on top of the
> free pipe fix at the beginning of this thread).  This patch will also
> dump the ED.

See seriallog-20120306_210506.log. (i don't see the ED dump?)
> Another thing you could try is to post the log with the call to
> set_idle() in usb-hid.c commented out.

See seriallog-20120306_214554.log.

Thanks, Nils.

usb ohci pipe free fix

[Nils]

Op dinsdag 06-03-2012 om 21:51 uur [tijdzone +0100], schreef Nils:
> Op maandag 05-03-2012 om 15:41 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > Nothing in the TD.  Can you try the patch below (again, on top of the
> > free pipe fix at the beginning of this thread).  This patch will also
> > dump the ED.
>
> See seriallog-20120306_210506.log. (i don't see the ED dump?)
> > Another thing you could try is to post the log with the call to
> > set_idle() in usb-hid.c commented out.
>
> See seriallog-20120306_214554.log.

I tested with some additional dprinf's and it returns in
usb-ohci.c/ohci_poll_intr() at line 556 (return -1;) before it gets to
the ED dump patch.

Thanks, Nils.

usb ohci pipe free fix

[Kevin O'Connor]

On Tue, Mar 06, 2012 at 09:51:09PM +0100, Nils wrote:
> Op maandag 05-03-2012 om 15:41 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > Nothing in the TD.  Can you try the patch below (again, on top of the
> > free pipe fix at the beginning of this thread).  This patch will also
> > dump the ED.
>
> See seriallog-20120306_210506.log. (i don't see the ED dump?)

It's the lines with "ed=...".  Anyway, nothing interesting there.
What I can see is that the frame counter halts right at the point when
it gets to the new "endpoint descriptor".  This is definitely odd, as
there is an endpoint descriptor already there that it doesn't seem to
have any issue with.  No status is put anywhere to indicate why the
controller stops updating the frame counter.

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.
> > Another thing you could try is to post the log with the call to
> > set_idle() in usb-hid.c commented out.
>
> See seriallog-20120306_214554.log.
>
> Thanks, Nils.

-Kevin

usb ohci pipe free fix

[Peter Stuge]

Kevin O'Connor wrote:
> No status is put anywhere to indicate why the
> controller stops updating the frame counter.

Your suggestions for what to try are excellent.

At this point it might be a good idea to look at CS5536 errata, if
there is anything concerning the OHCI.

//Peter

usb ohci pipe free fix

[Kevin O'Connor]

On Wed, Mar 07, 2012 at 04:57:09AM +0100, Peter Stuge wrote:
> Kevin O'Connor wrote:
> > No status is put anywhere to indicate why the
> > controller stops updating the frame counter.
>
> Your suggestions for what to try are excellent.
>
> At this point it might be a good idea to look at CS5536 errata, if
> there is anything concerning the OHCI.

I did look, but I didn't find anything enlightening.

-Kevin

usb ohci pipe free fix

[Nils]

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.

Thanks, Nils.

usb ohci pipe free fix

[Nils]

Op woensdag 07-03-2012 om 22:51 uur [tijdzone +0100], schreef Nils:
> 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.
>
> Thanks, Nils.

Also if repeat booting i get often the following lines in the log:
KBD: int09h_handler(): unknown scancode read: 0x5b!

KBD: int09h_handler(): unknown scancode read: 0x5c!

usb ohci pipe free fix

[Kevin O'Connor]

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

usb ohci pipe free fix

[Marc Jones]

On Wed, Mar 7, 2012 at 7:38 PM, Kevin O'Connor  wrote:
> 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.

I haven't looked at this stuff in years, but it sounds like geodelink
isn't setup to allow memory access into shadow ram. You may need to
setup additional geodelink routing.

http://www.amd.com/us/products/embedded/processors/other/Pages/geodelink-arc...

In coreboot, look at southbridge ChipsetGeodeLinkInit() and the
northbridge struct gliutable(s).

Marc

usb ohci pipe free fix

[Nils]

Op woensdag 07-03-2012 om 21:38 uur [tijdzone -0500], schreef Kevin
O'Connor:
> 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.

See seriallog-20120308_173529.log
> 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.

See seriallog-20120308_183255.log

On Wed, Mar 7, 2012 at 7:38 PM, Kevin O'Connor 
wrote:
> I haven't looked at this stuff in years, but it sounds like geodelink
> isn't setup to allow memory access into shadow ram. You may need to
> setup additional geodelink routing.

Thanks for the hint.
You could be right that the shadowram isn't setup right.
But if i'm not mistaken the original malloc_low range (the "9-segment")
is below shadow ram in conventional memory?

In the past years i looked several times at those geodelink msr range
setups, it's quite complicatedand and there were several problems.
Also there are lots of different memory regions (with different cache
setup?) in coreboot and SeaBIOS and i would have liked a table with
memory range prerequisites but i couldn't find one.
I'l look at it some more in the next days.

Thanks, Nils.

usb ohci pipe free fix

[Kevin O'Connor]

On Thu, Mar 08, 2012 at 11:36:05PM +0100, Nils wrote:
> Op woensdag 07-03-2012 om 21:38 uur [tijdzone -0500], schreef Kevin
> O'Connor:
> > 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.
>
> See seriallog-20120308_173529.log
> > 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.
>
> See seriallog-20120308_183255.log

It looks pretty clear that the controller doesn't like 9-segment nor
e-segment addresses.  You could try "malloc_low() - 0x50000" to see
how the controller likes 4-segment address, but basically the only
hope of getting this to work is to see if you can fix the controller.

-Kevin