linux-kernel - Re: almost daily Kernel oops with 2.6.23.9

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:	Thu, 20 Dec 2007 23:48:29 +0200
From:	"Pekka Enberg" <penberg@...helsinki.fi>
To:	"David Newall" <david@...idnewall.com>
Cc:	"Hemmann, Volker Armin" <volker.armin.hemmann@...clausthal.de>,
	Scott <linux-kernel@...ecamel.eml.cc>,
	linux-kernel@...r.kernel.org, mingo@...e.hu, hugh@...itas.com,
	stefanr@...6.in-berlin.de
Subject: Re: almost daily Kernel oops with 2.6.23.9 - and now 2.6.23.11 as well

Hi,

On Dec 20, 2007 4:38 PM, David Newall <david@...idnewall.com> wrote:
> >>> and another one, this time tainted with the nvidia module:
> >>> 5194.130985] Unable to handle kernel paging request at 0000030000000000
> >>> RIP:
>
> Numbers like that don't suggest hardware faults.  All those zeros: It's
> far too round.  Sounds very like software.  In fact, it sounds like the
> start of significant hardware region.

Nah, it's just that vma->anon_vma is probably supposed to be NULL here. And if
you look at all the oopses, they do suggest one particular byte lane
is dodgy (the
corruption is in bits 41-43 and 45).

The whole thing reminds me of another bug where memtest86 didn't find anything
because it's doing cached memory accesses: http://lkml.org/lkml/2007/10/3/259

                                Pekka
--
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/