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

[Zbyszek Żółkiewski]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20070209/438bfa28/attachment.htm>