linux-kernel - looking for explanation of spontaneous reset/reboot on Opteron

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 for Android: free password hash cracker in your pocket

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

Message-ID: <6CCEAEDF4D06984A83F427424F47D6E4013D1446@CORPUSMX40A.corp.emc.com>
Date:	Thu, 12 Oct 2006 13:43:15 -0400
From:	Edward Goggin <egoggin@....com>
To:	<linux-kernel@...r.kernel.org>
Subject: looking for explanation of spontaneous reset/reboot on Opteron

I'm looking for information about potential causes for a
spontaneous reboot of a dual core Opteron running RHEL 4
linux (2.6.9 derivative).  I'm thinking the cause is
due to the box taking a triple fault and resetting the
BIOS.

I'm also thinking that the triple fault is caused by a
kernel stack overflow into an unmapped virtual page
frame.  Is this a reasonable explanation?  Are there
others?

What are reasonable debugging strategies for handling
this?  Following the kernel stack overflow hunch, I'm
going to try increasing the Opteron stack size from
8K to 16K.  Can this be done by simply changing
THREAD_ORDER in include/asm-x86_64/page.h from 1 to 2?

Also, is there any kernel stack overflow detection
debugging code anywhere for x86_64 as there is for
i386?

Thanks,

Ed Goggin
-
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/