[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

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

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:

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,


Zbyszek Żółkiewski
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]