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

[Steven Whitehouse <swhiteho@redhat.com>]

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