[Cluster-devel] Kernel panic on mounting gfs2: kernel 2.6.19 and 2.6.20.
Zbyszek Żółkiewski
zbyszek at toliman.pl
Fri Feb 9 12:01:12 UTC 2007
ok then, let me know if you find something...
On 2/9/07, Steven Whitehouse <swhiteho at redhat.com> 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 <swhiteho at redhat.com> 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: <http://listman.redhat.com/archives/cluster-devel/attachments/20070209/79b7de07/attachment.htm>
More information about the Cluster-devel
mailing list