On 15/10/08 05:57 -0600, ext Paul Walmsley wrote: > Hi Nathan, > > On Thu, 9 Oct 2008, Nathan Monson wrote: > > > On Thu, Oct 9, 2008 at 5:43 AM, Tony Lindgren <tony@xxxxxxxxxxx> wrote: > > > Nathan, good to hear that the SO mode helps. But since you seem to > > > have it easily reproducable.. > > > > Reproducing is as easy as applying the DSP Bridge kernel patches and > > then running the 'ping.out' sample like this: while true; do > > ping.out; done > > > > > Could you try the following patch based on RMK's earlier patch > > > without the strongly ordered patch and see if that makes any > > > difference? > > > > Maybe it lasted a few seconds longer, or maybe it was luck, but in any > > case it eventually went into an IRQ -33 loop even with this patch. > > could you try Lauri's patch posted here: > > http://marc.info/?l=linux-omap&m=122407150608770&w=2 > > without the strongly-ordered memory patches? I would like TI or ARM to confirm if my assumption is correct that the IRQ will be re-raised if it gets corrupted in this way (resulting in a spurious irq -33, which seems to be the most common one ;). If not, then this patch will cause us to drop interrupts which is not good. Of course it is still better than ending in a permanent loop, but only marginally. I also tried the SO patch, result wasn't able to boot up at all (sorry, don't have the log to show where it died). /lauri -- To unsubscribe from this list: send the line "unsubscribe linux-omap" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
