linux-kernel - Re: [Bug #14141] order 2 page allocation failures in iwlagn

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:	Fri, 2 Oct 2009 22:01:43 +0200
From:	Karol Lewandowski <karol.k.lewandowski@...il.com>
To:	Mel Gorman <mel@....ul.ie>
Cc:	Frans Pop <elendil@...net.nl>, "Rafael J. Wysocki" <rjw@...k.pl>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Kernel Testers List <kernel-testers@...r.kernel.org>,
	Pekka Enberg <penberg@...helsinki.fi>,
	Reinette Chatre <reinette.chatre@...el.com>,
	Bartlomiej Zolnierkiewicz <bzolnier@...il.com>,
	Karol Lewandowski <karol.k.lewandowski@...il.com>
Subject: Re: [Bug #14141] order 2 page allocation failures in iwlagn

On Fri, Oct 02, 2009 at 10:32:26AM +0100, Mel Gorman wrote:
> On Fri, Oct 02, 2009 at 11:11:52AM +0200, Frans Pop wrote:
> > My own feeling is that Bartlomiej is correct and that something has changed 
> > since .29 and that on average we do have less higher order areas available 
> > after the system has been in use for some time, but I can't substantiate 
> > that. I do know that before .30 I had never seen the SKB allocation 
> > errors.
> > 
> > Main problem is that it's hard to deliberately and reproducibly get the 
> > system in a state where the errors occur.
> > 
> 
> Apparently, Karol Lewandowski (cc added) has a reliable
> reproduction case for when the firmware loading problem occurs
> (http://lkml.org/lkml/2009/9/30/242). While it's not the same problem exactly,
> it's probable they're related. I'm hoping the problem commit can be identified
> by his bisection whenever he gets around to it.

Unfortunately, I've had little success with bisecting this problem.
I've spend fair amount of time today trying to reproduce this problem,
but I'm unable to do so even on kernels that failed "easily" before.

Nothing has changed in hardware/software.  I've changed methodology
somewhat from suspend-and-look-for-failure-on-resume to rmmod, fill
memory, modprobe-and-see-it-fail... but well, few days ago it failed
in either case.

Damn.
--
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/