From mboxrd@z Thu Jan 1 00:00:00 1970 From: Zbyszek Żółkiewski Date: Fri, 9 Feb 2007 13:01:12 +0100 Subject: [Cluster-devel] Kernel panic on mounting gfs2: kernel 2.6.19 and 2.6.20. In-Reply-To: <1171021275.11001.575.camel@quoit.chygwyn.com> References: <1170941171.11001.496.camel@quoit.chygwyn.com> <1170951992.11001.509.camel@quoit.chygwyn.com> <1171017159.11001.559.camel@quoit.chygwyn.com> <1171021275.11001.575.camel@quoit.chygwyn.com> Message-ID: List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit ok then, let me know if you find something... On 2/9/07, Steven Whitehouse wrote: > > Hi, > > Ok, that confuses me even more then, as thats not my expected location > of this problem. Looking back through the call chain it seems that there > is no obvious way in which this spinlock could become unlocked. > > I'll have to think about this some more and get back to you I'm afraid, > > Steve. > > On Fri, 2007-02-09 at 11:34 +0100, Zbyszek ???kiewski wrote: > > well yes the line is: > > > > static void run_queue(struct gfs2_glock *gl) > > { > > struct gfs2_holder *gh; > > int blocked = 1; > > > > BUG_ON(!spin_is_locked(&gl->gl_spin)); < > > ------------------------------ line 632 > > for (;;) { > > ....... > > > > and i don;t use preemption (No Forced....)... i was playing with > > various options but the bug still appears, no metter how i setup gfs, > > on what distro (debian stable/eth).... > > > > > > > > > > > > On 2/9/07, Steven Whitehouse wrote: > > Hi, > > > > On Thu, 2007-02-08 at 18:21 +0100, Zbyszek ???kiewski wrote: > > > are you using the same glibc and distro? > > > > > I don't think glibc will make a difference here. I'm using > > FC-6 but with > > the upstream kernel. > > > > > well i have patched gfs2 and here is output: > > > > > Thanks for the report, I presume that line 632 is, in your > > glock.c the > > BUG_ON which is directly after the call to rq_promote? If so > > then we've > > narrowed it down to that function. Having said that, even > > after looking > > at every case of lock & unlock of gl_spin I still can't see > > any > > unbalanced pairs of locks. > > > > rq_promote does, in one case drop that spin lock, but it does > > also take > > it again before exiting the function. By adding some more > > BUG_ON()s into > > rq_promote, it might be possible to track it closer to the > > source. > > > > Are you using preempt btw? That ought to be fine if you are, > > but its > > always helpful to know when looking at locking problems, > > > > Steve. > > > > > > > > > > > > -- > > pozdrawiam, > > Zbyszek ???kiewski > > -- pozdrawiam, Zbyszek ???kiewski -------------- next part -------------- An HTML attachment was scrubbed... URL: