From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S932901AbcFLMdf (ORCPT <rfc822;w@1wt.eu>);
	Sun, 12 Jun 2016 08:33:35 -0400
Received: from mailout3.hostsharing.net ([176.9.242.54]:33426 "EHLO
	mailout3.hostsharing.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
	with ESMTP id S1753286AbcFLMde (ORCPT
	<rfc822;linux-kernel@vger.kernel.org>);
	Sun, 12 Jun 2016 08:33:34 -0400
Date: Sun, 12 Jun 2016 14:37:26 +0200
From: Lukas Wunner <lukas@wunner.de>
To: Ingo Molnar <mingo@kernel.org>
Cc: x86@kernel.org, linux-kernel@vger.kernel.org,
        Bjorn Helgaas <bhelgaas@google.com>, Yinghai Lu <yinghai@kernel.org>,
        Matt Fleming <matt@codeblueprint.co.uk>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        Andrew Morton <akpm@linux-foundation.org>,
        Thomas Gleixner <tglx@linutronix.de>, "H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH v2 3/3] x86/quirks: Add early quirk to reset Apple
 AirPort card
Message-ID: <20160612123726.GA20653@wunner.de>
References: <cover.1465690253.git.lukas@wunner.de>
 <48d0972ac82a53d460e5fce77a07b2560db95203.1465690253.git.lukas@wunner.de>
 <20160612114902.GA15940@gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20160612114902.GA15940@gmail.com>
User-Agent: Mutt/1.6.1 (2016-04-27)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

On Sun, Jun 12, 2016 at 01:49:02PM +0200, Ingo Molnar wrote:
> * Lukas Wunner <lukas@wunner.de> wrote:
> > The solution is to reset the card on boot by writing to a reset bit in
> > its mmio space. This must be done as an early quirk and not as a plain
> > vanilla PCI quirk to successfully combat memory corruption by DMAed
> > packets: Matthew Garrett found out in 2012 that the packets are written
> > to EfiBootServicesData memory (http://mjg59.dreamwidth.org/11235.html).
> > This type of memory is made available to the page allocator by
> > efi_free_boot_services(). [...]
> 
> Btw., would it also make sense to *not* free those pages by default,
> if firmware can occasionally corrupt them? What memory size are we
> talking about?

The memory area where packets are written is relatively small,
Matthew Garret writes: "I'd traced it down to a single 31MB region
of boot service data" (https://mjg59.dreamwidth.org/11235.html)

However memory corruption by DMAed packets is only one of two issues
here. The other is the interrupt storm unleashed by the wireless card.
The IRQ is frequently shared on these models. On my machine it's
shared with the Thunderbolt controller, SDXC controller and a sound
card. I can't even authenticate with cryptsetup on boot before getting
a spurious interrupt splat.

Resetting the card solves the problem at the root and fixes both,
the spurious interrupts and the memory corruption. 

Best regards,

Lukas