[LU-3843] osc_completion()) ASSERTION( (!!(page->cp_state == CPS_PAGEOUT) == !!(cmd == 0x02)) Created: 27/Aug/13  Updated: 19/Mar/14  Resolved: 19/Mar/14

Status: Closed
Project: Lustre
Component/s: None
Affects Version/s: None
Fix Version/s: Lustre 2.6.0

Type: Bug Priority: Major
Reporter: Christopher Morrone Assignee: Niu Yawei (Inactive)
Resolution: Cannot Reproduce Votes: 0
Labels: None
Environment:

Sequoia login node. PPC64. 48 core Power 7. Lustre version 2.4.0-RC2_11chaos


Severity: 3
Rank (Obsolete): 9945

 Description   

Using Lustre version 2.4.0-RC2_11chaos, we hit the following assertion on a login node (lustre client):

osc_cache.c:1267:osc_completion()) ASSERTION( (!!(page->cp_state == CPS_PAGEOUT) == !!(cmd == 0x02) ) failed:

The backtrace looks roughly like this:

osc_ap_compltion
osc_extent_finish
brw_interpret
ptlrpc_check_set
ptlrpcd_check
ptlrpcd

There was not much going on in the client's log. About one minute earlier an OSC lost connection to one of the OSTs and then reconnected. But that is a fairly common occurance. It is not immediately obvious to me that there is a connection to this assertion.

This client is a Power7 login node with 48 cores and 64GB of RAM.



 Comments   
Comment by Peter Jones [ 27/Aug/13 ]

Niu

Could you please comment on this one?

Thanks

Peter

Comment by Niu Yawei (Inactive) [ 29/Aug/13 ]

I have no idea how this can be triggered now, maybe printing more information on the LASSERT could be helpful for debug: http://review.whamcloud.com/7494

Chris, could you apply this debug patch? so we can see the value of cp_state & cmd next time when it's triggered. Thanks.

Comment by Christopher Morrone [ 30/Aug/13 ]

I had the same thought. Yes, I will add that to our local tree.

Comment by Peter Jones [ 02/Nov/13 ]

Landed for 2.6

Comment by Niu Yawei (Inactive) [ 04/Nov/13 ]

The landed patch is just a debug patch.

Comment by Jodi Levi (Inactive) [ 19/Mar/14 ]

Debug patch has landed. If this occurs again, please reopen the bug.

Generated at Sat Feb 10 01:37:23 UTC 2024 using Jira 9.4.14#940014-sha1:734e6822bbf0d45eff9af51f82432957f73aa32c.