linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
To: nicolas prochazka <prochazka.nicolas@gmail.com>
Cc: Dave Jones <davej@redhat.com>,
	linux-kernel <linux-kernel@vger.kernel.org>
Subject: Re: oops in kernel ( 3.4.x -> 3.5rc )
Date: Mon, 23 Jul 2012 13:39:06 -0300	[thread overview]
Message-ID: <20120723163906.GA3662@oc1711230544.ibm.com> (raw)
In-Reply-To: <CADdae-iQAoA_n3_azKWOR7HAe9_tOWybN_bGVG-C_P3Pa8Y1WA@mail.gmail.com>

On Sat, Jul 21, 2012 at 12:59:12AM +0200, nicolas prochazka wrote:
> Well done
> 1fd36adcd98c14d2fd97f545293c488775cb2823  :  the bug occurs   ( cf dump )
> 1dce27c5aa6770e9d195f2bb7db1db3d4dde5591 :  the bug not occurs
> 
> Regards,
> Nicolas Prochazka.

Hi, Nicolas.

I was too hasty in sending you the commit id. There is a bug in 1fd36adc
that is fixed by commit f044db4cb4bf16893812d35b5fbeaaf3e30c9215. Can
you test running f044db4cb4? If you find the bug in there, then we know
that this fix isn't the only one needed for 1fd36adc.

Regards.
Cascardo.

> 
> dump  / 1fd36adcd98c14d2fd97f545293c488775cb2823
> lloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> VMtap: no IPv6 routers present
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 71 not NULL!
> alloc_fd: slot 121 not NULL!
> alloc_fd: slot 96 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 110 not NULL!
> alloc_fd: slot 121 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> brE: no IPv6 routers present
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 121 not NULL!
> alloc_fd: slot 142 not NULL!
> alloc_fd: slot 153 not NULL!
> alloc_fd: slot 153 not NULL!
> alloc_fd: slot 153 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 70 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 102 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 106 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 106 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 36 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 68 not NULL!
> alloc_fd: slot 100 not NULL!
> alloc_fd: slot 100 not NULL!
> ------------[ cut here ]------------
> kernel BUG at fs/open.c:873!
> invalid opcode: 0000 [#1] SMP
> CPU 0
> Modules linked in: kvm_intel kvm
> 
> then BUG paging request as usual
> 
> 
> 2012/7/20 Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>:
> > On Fri, Jul 20, 2012 at 10:52:40PM +0200, nicolas prochazka wrote:
> >> Hello
> >> the problem is occured with  :
> >> - linux kernel 3.4.5    i do not test with 3.4.0 / 1 / 2 / 3 / 4    ,
> >> but i can if you want
> >> - linux kernel 3.5rc6 rc7  / do not test with other rc.
> >>
> >> the problem is not occured with :
> >> linux kernel 3.3.4 / 3.3.8
> >>
> >> These servers are used for :
> >> - starting a lot of virtual machine with qemu-kvm ( ~ 40 )   ( lot of
> >> select i think)
> >> - do a lot of network tests with openvswitch
> >>
> >> I can test a kernel 3.4.x before and after a commit id (?) to find a regression.
> >>
> >> Regards,
> >> Nicolas.
> >>
> >
> > Can you try this commit 1fd36adcd98c14d2fd97f545293c488775cb2823? And
> > the commit before it?
> >
> >>
> >> 2012/7/20 Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>:
> >> > On Fri, Jul 20, 2012 at 09:21:53AM -0400, Dave Jones wrote:
> >> >> On Fri, Jul 20, 2012 at 11:56:06AM +0200, nicolas prochazka wrote:
> >> >>
> >> >>  > [ 2384.900061] BUG: unable to handle kernel paging request at 000000010000002f
> >> >>
> >> >> That '1' looks like a random bit flip. Try running memtest86.
> >> >>
> >> >
> >> > Looks more a 32-bit value of 1 followed by a 32-bit value of 0x2f. Most
> >> > likely a pointer to some other piece of a struct. However, taking a look
> >> > at fs/files.c code, nothing seems suspicious.
> >> >
> >> > Nicolas, it wasn't clear to me if you had problems with 3.4 too. There
> >> > has been some changes in fs/files.c on 3.4-rc1 in the piece of code
> >> > where you hit the problem.
> >> >
> >> > What does your system exercise? Any chance you are using a lot of
> >> > select, which has also been changed in those same patches to fs/files.c?
> >> >
> >> > Regards.
> >> > Cascardo.
> >> >
> >> >
> >> >>  > [ 2384.910010] Pid: 23838, comm: queue.sh Tainted: G      D W
> >> >>
> >> >> This wasn't the first problem either.
> >> >>
> >> >>  > [ 2397.885344] BUG: unable to handle kernel paging request at 000000010000003b
> >> >>
> >> >> Looks like the same flipped bit.
> >> >>
> >> >>       Dave
> >> >>
> >> >> --
> >> >> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> >> >> the body of a message to majordomo@vger.kernel.org
> >> >> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> >> >> Please read the FAQ at  http://www.tux.org/lkml/
> >> >>
> >> >
> >>
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
> 


  reply	other threads:[~2012-07-23 16:39 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-07-20  9:56 oops in kernel ( 3.4.x -> 3.5rc ) nicolas prochazka
2012-07-20 13:21 ` Dave Jones
2012-07-20 13:32   ` nicolas prochazka
2012-07-20 20:21   ` Thadeu Lima de Souza Cascardo
2012-07-20 20:52     ` nicolas prochazka
2012-07-20 21:06       ` Thadeu Lima de Souza Cascardo
2012-07-20 22:59         ` nicolas prochazka
2012-07-23 16:39           ` Thadeu Lima de Souza Cascardo [this message]
2012-07-23 21:15             ` nicolas prochazka
2012-07-24 16:52               ` Thadeu Lima de Souza Cascardo
2012-07-28  7:52                 ` nicolas prochazka
2012-08-08 10:44                   ` nicolas prochazka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120723163906.GA3662@oc1711230544.ibm.com \
    --to=cascardo@linux.vnet.ibm.com \
    --cc=davej@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=prochazka.nicolas@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body. 
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).