ok then, let me know if you find something...<br><br><div><span class="gmail_quote">On 2/9/07, <b class="gmail_sendername">Steven Whitehouse</b> <<a href="mailto:swhiteho@redhat.com">swhiteho@redhat.com</a>> wrote:</span>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Hi,<br><br>Ok, that confuses me even more then, as thats not my expected location<br>of this problem. Looking back through the call chain it seems that there
<br>is no obvious way in which this spinlock could become unlocked.<br><br>I'll have to think about this some more and get back to you I'm afraid,<br><br>Steve.<br><br>On Fri, 2007-02-09 at 11:34 +0100, Zbyszek Żółkiewski wrote:
<br>> well yes the line is:<br>><br>> static void run_queue(struct gfs2_glock *gl)<br>> {<br>> struct gfs2_holder *gh;<br>> int blocked = 1;<br>><br>> BUG_ON(!spin_is_locked(&gl->gl_spin)); <
<br>> ------------------------------ line 632<br>> for (;;) {<br>> .......<br>><br>> and i don;t use preemption (No Forced....)... i was playing with<br>> various options but the bug still appears, no metter how i setup gfs,
<br>> on what distro (debian stable/eth)....<br>><br>><br>><br>><br>><br>> On 2/9/07, Steven Whitehouse <<a href="mailto:swhiteho@redhat.com">swhiteho@redhat.com</a>> wrote:<br>> Hi,<br>
><br>> On Thu, 2007-02-08 at 18:21 +0100, Zbyszek Żółkiewski wrote:<br>> > are you using the same glibc and distro?<br>> ><br>> I don't think glibc will make a difference here. I'm using
<br>> FC-6 but with<br>> the upstream kernel.<br>><br>> > well i have patched gfs2 and here is output:<br>> ><br>> Thanks for the report, I presume that line 632 is, in your
<br>> glock.c the<br>> BUG_ON which is directly after the call to rq_promote? If so<br>> then we've<br>> narrowed it down to that function. Having said that, even<br>> after looking
<br>> at every case of lock & unlock of gl_spin I still can't see<br>> any<br>> unbalanced pairs of locks.<br>><br>> rq_promote does, in one case drop that spin lock, but it does
<br>> also take<br>> it again before exiting the function. By adding some more<br>> BUG_ON()s into<br>> rq_promote, it might be possible to track it closer to the<br>> source.
<br>><br>> Are you using preempt btw? That ought to be fine if you are,<br>> but its<br>> always helpful to know when looking at locking problems,<br>><br>> Steve.<br>>
<br>><br>><br>><br>><br>> --<br>> pozdrawiam,<br>> Zbyszek Żółkiewski<br><br></blockquote></div><br><br clear="all"><br>-- <br>pozdrawiam,<br>Zbyszek Żółkiewski