linux-acpi.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hans de Goede <hdegoede@redhat.com>
To: linux-acpi <linux-acpi@vger.kernel.org>
Cc: martin@hundeboll.net, Matthew Garrett <mjg59@srcf.ucam.org>
Subject: Re: ACPI errors on Dell Latitude E5430
Date: Mon, 01 Oct 2012 20:38:42 +0200	[thread overview]
Message-ID: <5069E332.9060109@redhat.com> (raw)

Hi,

Matthew Garrett wrote:
 > We're getting timeouts when trying to access the embedded controller,
 > which would explain your problems.

I've been seeing the same problem on my Dell E6430. but only
with 3.6 not with 3.5. I've done quite a bit of debugging on
this enabling all the debug prints in drivers/acpi/ec.c + adding
some of my own, and I've failed to catch Linux on doing anything
"wrong" (unsurprisingly).

I've learned 2 interesting things though:
1) The timeout of the EC transactions is timing dependent, if
we feed the EC commands + data with the right timing all is ok,
this is why 3.5 worked and 3.6 did not work for me, the Fedora 3.6
kernels for F-18 are build with various kernel debugging options
enabled, changing the timing. If I take a 3.6 build from Fedora
without the debugging options 3.6 works just as well as 3.5 for me.

2) Even with a 3.6 which shows the problematic behavior, I can
make things work by adding acpi.ec_delay=2000 to the kernel cmdline,
the debug traces show that the EC takes it sweet time to respond
(sometime close to 2 seconds) but it does eventually respond in all
cases I've seen sofar.

This also seems to fix a sporadic occurence of:
"ACPI: EC: input buffer is not empty aborting transaction"
Which I'm seeing with 3.5 / 3.6 in a non debug build.

Martin, can you see if adding that helps you with the E5430 problems
too ?

###

I'll go and report this to Dell's Linux team, as I believe this is
an EC firmware bug. In the mean time, since even if Dell fixes this,
people are bad in applying BIOS updates, maybe we should add a DMI
quirk for machines which need a longer ec_delay, and add these 2?

Regards,

Hans



             reply	other threads:[~2012-10-01 18:37 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-10-01 18:38 Hans de Goede [this message]
2012-10-02  9:22 ` ACPI errors on Dell Latitude E5430 Martin Hundebøll
2012-10-02 11:14   ` Hans de Goede
2012-10-03  6:36     ` Martin Hundebøll
2012-10-03 10:43       ` Hans de Goede
2012-10-03 11:48         ` Martin Hundebøll
2012-10-03 12:52           ` Hans de Goede
2012-10-03 16:32             ` Martin Hundebøll
2012-10-08 11:22               ` Hans de Goede
2012-10-03 12:53           ` Hans de Goede
  -- strict thread matches above, loose matches on Subject: below --
2012-09-21 12:10 Martin Hundebøll
2012-09-21 19:34 ` Matthew Garrett

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=5069E332.9060109@redhat.com \
    --to=hdegoede@redhat.com \
    --cc=linux-acpi@vger.kernel.org \
    --cc=martin@hundeboll.net \
    --cc=mjg59@srcf.ucam.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).