public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Eric Dumazet <dada1@cosmosbay.com>
To: Andi Kleen <ak@suse.de>, linux-kernel@vger.kernel.org
Cc: Chris Bruner <cryst@golden.net>, Andrew Morton <akpm@osdl.org>,
	Linus Torvalds <torvalds@osdl.org>,
	Matt Domsch <Matt_Domsch@dell.com>
Subject: Something very strange on x86_64 2.6.X kernels
Date: Thu, 20 Jan 2005 21:53:36 +0100	[thread overview]
Message-ID: <41F01A50.1040109@cosmosbay.com> (raw)
In-Reply-To: <20050120164829.GG450@wotan.suse.de>

Hi Andi

I have very strange coredumps happening on a big 64bits program.

Some background :
- This program is multi-threaded
- Machine is a dual Opteron 248 machine, 12GB ram.
- Kernel 2.6.6  (tried 2.6.10 too but problems too)
- The program uses hugetlb pages.
- The program uses prefetchnta
- The program uses about 8GB of ram.

After numerous differents core dumps of this program, and gdb debugging 
I found :

Every time the crash occurs when one thread is using some ram located at 
virtual address 0xffffe6xx

When examining the core image, the data saved on this page seems correct 
(ie countains coherent user data). But one register (%rbx) is usually 
corrupted and contains a small value (like 0x3c)

The last instruction using this register is :
	prefetchnta 0x18(,%rbx,4)


Examining linux sources, I found that 0xffffe000 is 'special' (ia 32 
vsyscall) and 0xffffe600 is about sigreturn subsection of this special area.

Is it possible some vm trick just kicks in and corrupts my true 64bits 
program ?

Thank you
Eric Dumazet

  reply	other threads:[~2005-01-20 20:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-01-19 23:13 COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6 Janos Farkas
2005-01-20  4:21 ` Chris Bruner
2005-01-20 16:28 ` Adrian Bunk
2005-01-20 16:40   ` Linus Torvalds
2005-01-20 16:48   ` Andi Kleen
2005-01-20 20:53     ` Eric Dumazet [this message]
2005-01-20 21:08       ` Something very strange on x86_64 2.6.X kernels Andrew Morton
2005-01-20 21:19         ` Eric Dumazet
2005-01-21 16:26       ` Petr Vandrovec
2005-01-21 16:49         ` Eric Dumazet
2005-01-21 18:30           ` Petr Vandrovec
2005-01-22  1:54         ` Andi Kleen
2005-01-22  2:14           ` Linus Torvalds
2005-01-21  6:58     ` COMMAND_LINE_SIZE increasing in 2.6.11-rc1-bk6 Catalin(ux aka Dino) BOIE
2005-01-21  7:11       ` Andi Kleen
2005-01-21 17:46         ` Matt Domsch
2005-01-21 19:05           ` H. Peter Anvin
2005-02-07  6:57         ` Werner Almesberger
2005-02-12 13:54           ` Eric W. Biederman
2005-02-12 14:51             ` Werner Almesberger
2005-02-12 15:17               ` Eric W. Biederman
2005-02-14  5:49                 ` Werner Almesberger
2005-02-14  7:36                   ` Eric W. Biederman
2005-02-14  6:15       ` Adam Sulmicki

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=41F01A50.1040109@cosmosbay.com \
    --to=dada1@cosmosbay.com \
    --cc=Matt_Domsch@dell.com \
    --cc=ak@suse.de \
    --cc=akpm@osdl.org \
    --cc=cryst@golden.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@osdl.org \
    /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