Recently I found a problem at LU-1442 where a page was wrongly marked as dirty but not in osc writing cache. That will definitely cause this kind of issue because osc_cache_writeback_range() won't clean up the whole lock region.
Based on the situation that there is no enough log I'd like to try that patch first. The patch is located at: http://review.whamcloud.com/3447
This patch is landed to master and so should be in the next tag
Hi Jinshan, What's the status of this? Is http://review.whamcloud.com/3447 all that is needed to fix the assertion?
Hi Prakash, yes, I think so.
ok so let's mark this as a duplicate of LU-1442 then and reopen if that proves incorrect
Correct me if I'm wrong, but I think LU-1442 is a separate issue. I thought Jinshan discovered the root cause of this issue when investigating LU-1442, not that they are the same bug?
LU-1442 can definitely cause this issue, let me explain here:
1. from the description of lu-1442, one page can be wrongly marked as Dirty but not be put into OSC's write cache;
2. when the lock is canceled, we only cleanup the region of osc write cache covered by the lock, however, the page is not in osc write cache as I stated in 1;
3. when the page is discarded, we verify that there is no dirty page in the lock region by checking vmpage dirty flag. This will hit assertion.
As a conclusion, I think these are different symptoms of the same issue.
Thanks for the detailed explanation!
Reopening. Somehow this ticket and ORI-726 were both marked "resolved" as duplicates of each other. One needs to stay open until the issue is resolved. 
Oh, I see, this should be resolved as duplicate of LU-1442. I'll do that.
Duplicate of LU-1442.
Sorry, my reading of the summary was too quick. I thought this was just a renamed ORI-726 so the patch could land to master, and that it was definitely related to PPC. I've removed the ppc label.