Hi, > -----Original Message----- > From: Felipe Contreras [mailto:felipe.contreras@xxxxxxxxx] > Sent: Wednesday, May 12, 2010 2:39 PM > To: Guzman Lugo, Fernando > Cc: Chitriki Rudramuni, Deepak; linux-omap; Ameya Palande; Felipe > Contreras; Hiroshi Doyu; Ramirez Luna, Omar; Menon, Nishanth > Subject: Re: [PATCH] DSPBRIDGE:Fix Kernel memory poison overwritten after > DSP_MMUFAULT > > Hi, > > I didn't touch this issue in the hopes that it would be fixed, but > seems it hasn't. > > On Mon, Apr 19, 2010 at 9:25 PM, Guzman Lugo, Fernando <x0095840@xxxxxx> > wrote: > > To sum up: > > > > - "DSPBRIDGE:Fix Kernel memory poison overwritten after DSP_MMUFAULT" is > only hidden the problem, we don't need aligned memory in this point, that > patch should be removed if it is already apply. > > > > - There is no need to create a patch for the issue because it is already > indirectly fix with "DSPBRIDGE: MMU-Fault debugging enhancements". > > If you are referring to this patch: > http://git.kernel.org/?p=linux/kernel/git/tmlind/linux-omap- > 2.6.git;a=commit;h=26ad62f03578a12e942d8bb86d0e52ef1afdee22 Yes, that's the patch. Could you make sure that the GPT8 interrupt is generated before acking MMU fault interrupt? > > I tried to backport it to minimize the changes to a reproducible > test-case. I guess in the l-o branch the commit would be dd1fd0b. > Unfortunately that didn't fix the corruption. So I don't by that GPT8 > theory. > > > - we don't need allocate memory for dummy_va_addr, if some patch should > be created should be the patch to remove dummy_va_addr allocation and > deletion. > > I tried that, and that actually fixes the corruption for me (passing 0 > to hw_mmu_tlb_add). I think first page DSP side memory is never mapped to MPU side, so even if the DSP corrupts that page it does not affect MPU side. However the right solution is the one explained before: avoid DSP continues executing after MMUfault. Regards, Fernando. > > -- > Felipe Contreras -- 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
