[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.



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 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
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]