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

[Steven Whitehouse <swhiteho@redhat.com>]

Hi,

I cannot reproduce what you are seeing, but try the attached patch to
see if we can narrow this down,

Steve.

On Thu, 2007-02-08 at 15:02 +0100, Zbyszek ???kiewski wrote:
> ok , i have build kernel from your git (
> git://git.kernel.org/pub/scm/linux/kernel/git/steve/gfs2-2.6-nmw.git)
> Linux version 2.6.20-xmpp2-ga2cf8222-dirty (root at xmpp-alt2) (gcc
> version 3.4.4 20050314 (prerelease) (Debian 3.4.3-13sarge1)) #1 Thu
> Feb 8 14:51:21 CET 2007
> 
> and there is the same problem;
> kernel BUG at fs/gfs2/glock.c:704!
> invalid opcode: 0000 [#2]
> Modules linked in: lock_nolock lock_dlm gfs2 dlm configfs
> CPU:    0 
> EIP:    0060:[<f8950173>]    Not tainted VLI
> EFLAGS: 00000282   (2.6.20-xmpp2-ga2cf8222-dirty #1)
> EIP is at gfs2_glmutex_unlock+0x18/0x1c [gfs2]
> 
> and so one....
> 
> ok so waiting patiently for solution.... 
> 
> 
> 
> 
> On 2/8/07, Steven Whitehouse <swhiteho@redhat.com> wrote:
>         Hi,
>         
>         On Thu, 2007-02-08 at 14:04 +0100, Zbyszek ???kiewski wrote:
>         > sorry - mail went only to Steven, now to group....
>         >
>         >
>         > On 2/8/07, Zbyszek ???kiewski <zbyszek@toliman.pl> wrote:
>         >         well, thanks for answer, i have tried with nolock,
>         and result
>         >         is as follow:
>         >         of course i made mkfs -t gfs2 -p lock_nolock -t
>         xmpp-alt2:test
>         >         -j 1 /dev/sdb1 and then:
>         >         mount -t gfs2 /dev/sdb1 /mnt -v
>         >
>         >         and yes - the device is mounted,
>         It looks like what is happening is that a glmutex_unlock() is
>         discovering that its spinlock has been dropped by
>         glock.c:run_queue()
>         which should be impossible, so something odd is happening here
>         I think.
>         
>         The daemons implicated in this are there to demote unused
>         locks on a
>         periodic basis, so its presumably one of the locks used during
>         mounting 
>         of the filesystem thats at fault.
>         
>         >         (the changes to kernel you was talking about: you
>         mean: git1
>         >         for 2.6.20?)
>         >
>         I'm not sure if its in git1 or not, I suspect it will be git2
>         since it 
>         was only yesterday that the patches went in. Linus' current
>         git tree
>         seems to be broken (both gitweb and direct via the git tools)
>         otherwise
>         I'd post a URL to the changes. In the mean time you can find
>         them in my 
>         -nmw tree which will get updated just as soon as git it
>         working again at
>         kernel.org,
>         
>         Steve.
>         
>         
> 
> 
> -- 
> pozdrawiam,
> Zbyszek ???kiewski
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.diff
Type: text/x-patch
Size: 1259 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/cluster-devel/attachments/20070208/ca40ccac/attachment.bin>