From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dave Hansen Subject: i915 hang and large allocation (~3.7-rc4) Date: Mon, 12 Nov 2012 14:44:46 -0800 Message-ID: <50A17BDE.7050404@linux.vnet.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from e34.co.us.ibm.com (e34.co.us.ibm.com [32.97.110.152]) by gabe.freedesktop.org (Postfix) with ESMTP id DBE0C9E79E for ; Mon, 12 Nov 2012 14:45:16 -0800 (PST) Received: from /spool/local by e34.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Mon, 12 Nov 2012 15:45:16 -0700 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org Errors-To: dri-devel-bounces+sf-dri-devel=m.gmane.org@lists.freedesktop.org To: intel-gfx@lists.freedesktop.org, dri-devel@lists.freedesktop.org, Chris Wilson , Daniel Vetter List-Id: dri-devel@lists.freedesktop.org I've been seeing a little goofiness with i915 video under the 3.7-rc's. It looks like I'm seeing two separate issues. One, that the video hardware hangs, spits some errors in dmesg, and then video acceleration seems to stop working. Two, when it does this, apport goes digging in debugfs for information about the hang. When it does this, something does an order-9 (2MB) kmalloc() which fails. While debugfs is expected to be a _bit_ rickety, I do think order-9 is a bit excessive for an in-kernel allocation, even a temporary one. I'm not quite sure if it has done this for a long time, and I'm only hitting it now since I'm seeing a _separate_ i915 hang. Relevant parts of dmesg, lspci, and kernel config are here: http://sr71.net/~dave/linux/i915-wonky/