Messages in this thread | | | Date | Sun, 5 Oct 2008 10:51:45 +0200 (CEST) | From | Thomas Gleixner <> | Subject | Re: [RFC PATCH 02/12] On Tue, 23 Sep 2008, David Miller wrote: |
| |
On Sat, 4 Oct 2008, Jesse Brandeburg wrote: > > Exactly. The access to a ro region results in a fault. I have nowhere > > seen that trigger, but I can reproduce the trylock() WARN_ON, which > > confirms that there is concurrent access to the NVRAM registers. The > > backtrace pattern is similar to the one you have seen. > > are you still getting WARN_ON *with* all the mutex based fixes already applied?
The WARN_ON triggers with current mainline. Is there any fixlet in Linus tree missing ?
> with the mutex patches in place (without protection patch) we are > still reproducing the issue, until we apply the set_memory_ro patch.
That does not make sense to me. If the memory_ro patch is providing _real_ protection then you _must_ run into an access violation. If not, then the patch just papers over the real problem in some mysterious way.
The patch does:
+ set_memory_rw((unsigned long)hw->flash_address, + hw->flash_len >> PAGE_SHIFT); writew(val, hw->flash_address + reg); + set_memory_ro((unsigned long)hw->flash_address, + hw->flash_len >> PAGE_SHIFT);
This changes massively the timing of the flash access. Could this be the problem on the machine which needs the set_memory_ro patch to survive ?
> I had no luck on friday setting a hardware breakpoint on memory access > with kgdb to catch the writer with a breakpoint.
Well, why should you get a hardware breakpoint when the _ro protection does not trigger in the first place ?
Granted there could be a _rw alias mapping, but then the problem must be still visible with the _ro patch applied.
Thanks,
tglx
| |