From patchwork Mon May 18 12:27:37 2015 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Chris Bainbridge X-Patchwork-Id: 6428621 Return-Path: X-Original-To: patchwork-linux-acpi@patchwork.kernel.org Delivered-To: patchwork-parsemail@patchwork2.web.kernel.org Received: from mail.kernel.org (mail.kernel.org [198.145.29.136]) by patchwork2.web.kernel.org (Postfix) with ESMTP id 99AFCC0432 for ; Mon, 18 May 2015 12:27:59 +0000 (UTC) Received: from mail.kernel.org (localhost [127.0.0.1]) by mail.kernel.org (Postfix) with ESMTP id A003220452 for ; Mon, 18 May 2015 12:27:58 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A7DD220451 for ; Mon, 18 May 2015 12:27:57 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754111AbbERM1t (ORCPT ); Mon, 18 May 2015 08:27:49 -0400 Received: from mail-wg0-f47.google.com ([74.125.82.47]:35259 "EHLO mail-wg0-f47.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753878AbbERM1n (ORCPT ); Mon, 18 May 2015 08:27:43 -0400 Received: by wgfl8 with SMTP id l8so34374969wgf.2 for ; Mon, 18 May 2015 05:27:41 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=mMppdBMZkVos26dbK3nvy8VRjzZj1A+yywV5FCk4q00=; b=G+YGpxlwDbbYqzeIhbK3gpbasR1DAWG9JEUSL6e8Ha5X3g8q49FoXp/DMef9sFUTAO Vfp146oWEEvUaNIO/OKcsGYMqoKusjqMcv3paKuSRrFzt4Qo8fDUJ7BFkljH/JCFHX5g SMbjhw4UnLeChaAszaDLvfHV5Re/Wpx2M1Y2hYjG4qSOw8YJy46yjKEtXO5tZI0yBWNu 8KT+240gsGQleQBN4mXQDrDSbFBm/an0tV47iuHyQAKGz4gOFlxrnniV/Co6OnDPh14n uocg8P8RmqJhjiIGdWE8n1HkVDzlsjMIjX9BVQcn+v+4+HOtZJTY+Xg5lyjB34asIudu Dg8g== X-Received: by 10.194.5.74 with SMTP id q10mr43625824wjq.27.1431952060846; Mon, 18 May 2015 05:27:40 -0700 (PDT) Received: from localhost (cpc2-sgyl32-2-0-cust142.sgyl.cable.virginm.net. [77.97.242.143]) by mx.google.com with ESMTPSA id o6sm12221298wiz.24.2015.05.18.05.27.39 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 18 May 2015 05:27:39 -0700 (PDT) Date: Mon, 18 May 2015 13:27:37 +0100 From: Chris Bainbridge To: Brad Campbell Cc: linux-acpi@vger.kernel.org Subject: Re: [PATCH] ACPI/sbshc: Add 5us delay to fix SBS hang on MacBook Message-ID: <20150518122737.GA5850@localhost> References: <20150424012530.GA16763@localhost> <4435249.leKkNHm9IZ@vostro.rjw.lan> <20150429202140.GB25904@localhost> <55594C71.9060402@fnarfbargle.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <55594C71.9060402@fnarfbargle.com> User-Agent: Mutt/1.5.23 (2014-03-12) Sender: linux-acpi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-acpi@vger.kernel.org X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, DKIM_ADSP_CUSTOM_MED, DKIM_SIGNED, FREEMAIL_FROM, RCVD_IN_DNSWL_HI, T_DKIM_INVALID, T_RP_MATCHES_RCVD, UNPARSEABLE_RELAY autolearn=unavailable version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on mail.kernel.org X-Virus-Scanned: ClamAV using ClamSMTP On Mon, May 18, 2015 at 10:20:33AM +0800, Brad Campbell wrote: > On 30/04/15 04:21, Chris Bainbridge wrote: > > > >Supporting _OSI("Darwin") caused the MacBook firmware to expose the SBS, > >resulting in intermittent hangs of several minutes on boot, and failure > >to detect or report the battery. Fix this by adding a 5us delay to the > >start of each SMBUS transaction. This timing is the result of > >experimentation - hangs were observed with 3us but never with 5us. > > G'day Chris, > > Using 4.1-rc3 (whatever git head was from a couple of days ago) I've still > been seeing ACPI lockups on my Macbook Pro (11,1). It appears to take a > couple of suspend/resume cycles but seems to happen within 24 hours of > booting whereas before this patch it was easy to hit. > > As a test (and I do wonder if it'll lock up after I press send on this > E-mail) I upped the delay to 10us and I've now been up for 1 day, 17:23 with > the battery still responding to polling. > > To make it easier to reproduce, I've been running a script that polls the > battery every 60 seconds. > > I figure I'll let it go for another couple of days, but I wanted to put this > out there in case anyone else is seeing lockups after a longer period of > uptime. The symptoms are the ACPI command just hangs as does 'cat > /sys/class/power_supply/BAT0/status'. From there I can't suspend as the > tasks can't be frozen and I just end up hard booting the machine. > > I've removed Len & Rafael from the cc. > > Regards, > Brad I used a patch similar to the following to test, it just runs the SBS read in a loop. acpi_battery_get_info is run when the sbs module is loaded. So start off with the 5us delay and a few runs through the loop and verify you hit the hang, then increase the delay to 10us or whatever and run the loop for a few thousand cycles until you're happy that increasing the delay fixes the problem. --- To unsubscribe from this list: send the line "unsubscribe linux-acpi" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html diff --git a/drivers/acpi/sbs.c b/drivers/acpi/sbs.c index 01504c8..74f8596 100644 --- a/drivers/acpi/sbs.c +++ b/drivers/acpi/sbs.c @@ -361,16 +361,21 @@ static int acpi_manager_get_info(struct acpi_sbs *sbs) static int acpi_battery_get_info(struct acpi_battery *battery) { int i, result = 0; - - for (i = 0; i < ARRAY_SIZE(info_readers); ++i) { - result = acpi_smbus_read(battery->sbs->hc, - info_readers[i].mode, - ACPI_SBS_BATTERY, - info_readers[i].command, - (u8 *) battery + - info_readers[i].offset); - if (result) - break; + int j; + + for (j = 0; j < 1000; j++) { + for (i = 0; i < ARRAY_SIZE(info_readers); ++i) { + result = acpi_smbus_read(battery->sbs->hc, + info_readers[i].mode, + ACPI_SBS_BATTERY, + info_readers[i].command, + (u8 *) battery + + info_readers[i].offset); + if (result) { + printk("FAIL\n"); + break; + } + } } return result; }