linux-kernel - Re: Which patch fix the 8G memory problem on x64 platform?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 27 Nov 2006 21:33:55 -0800
From:	"Zhao Forrest" <forrest.zhao@...il.com>
To:	"Andi Kleen" <ak@...e.de>
Cc:	discuss@...-64.org, linux-kernel@...r.kernel.org
Subject: Re: Which patch fix the 8G memory problem on x64 platform?

On 11/27/06, Andi Kleen <ak@...e.de> wrote:
> On Monday 27 November 2006 11:02, Zhao Forrest wrote:
> > Hi Andi,
> >
> > The kernel 2.6.18.3 runs very well on my x64 server with 2 CPU's and
> > 8G memory; however kernel 2.6.16.32 kernel panic(Kernel panic - not
> > syncing: Attempted to kill init) under the stress test. After I use
> > mem=4000M for kernel 2.6.16.32, the kernel panic doesn't happen under
> > stress test.
>
> I'm not aware of a "8G memory problem"
>
> Best you write a full bug report and possibly git bisect it.
>

Hi Andy,

My bad. After the further testing, we found this bug is not related to
the volumn of physical memory. During the stress test, when the system
halt, there's only "Kernel panic - not
 syncing: Attempted to kill init" on the screen, no stack call trace
is printed out. Also we found the content in the address pointed by
rSP is all 0xff, so don't know how to debug it.
This bug is reproduced with kernel 2.6.16.32 on both IBM and SUN MP servers.

I first need to contact the author of test case if we could send the
test case to open source. The test case is called "crashme", and the
main idea of test case is:
A signal handler is set up so that in most cases the machine exception
generated by the illegal instructions, bad operands, etc in the procedure
made up of random data are caught; and another round of randomness may
be tried. Eventually a random instruction may corrupt the program or
the machine state in such a way that the program must halt. This is
a test of the robustness of the hardware/software for instruction
fault handling.

Now we are doing git-bisect, which will take some time......

Thanks,
Forrest
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/