From mboxrd@z Thu Jan 1 00:00:00 1970 From: Steven Whitehouse Date: Thu, 08 Feb 2007 16:26:32 +0000 Subject: [Cluster-devel] Kernel panic on mounting gfs2: kernel 2.6.19 and 2.6.20. In-Reply-To: References: <1170939465.11001.491.camel@quoit.chygwyn.com> <1170941171.11001.496.camel@quoit.chygwyn.com> Message-ID: <1170951992.11001.509.camel@quoit.chygwyn.com> List-Id: To: cluster-devel.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit 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:[] 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 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 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: