[Cluster-devel] Kernel panic on mounting gfs2: kernel 2.6.19 and 2.6.20.

[Zbyszek Żółkiewski <zbyszek@toliman.pl>]

ok then, let me know if you find something...

On 2/9/07, Steven Whitehouse <swhiteho@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@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>