All of lore.kernel.org
 help / color / mirror / Atom feed
From: Zdenek Kabelac <zkabelac@redhat.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Len Brown <lenb@kernel.org>, "Rafael J. Wysocki" <rjw@sisk.pl>,
	Linux ACPI <linux-acpi@vger.kernel.org>,
	LKML <linux-kernel@vger.kernel.org>
Subject: Re: Acpi deadlocks with 3.7.0-rc4
Date: Wed, 28 Nov 2012 17:21:24 +0100	[thread overview]
Message-ID: <50B63A04.9010901@redhat.com> (raw)
In-Reply-To: <CA+55aFyLMmKuEvY6T2=vSHp_R4=ndqFEFNJsc3Axze2vYknKhg@mail.gmail.com>

Dne 28.11.2012 17:01, Linus Torvalds napsal(a):
> Adding more people (and the acpi list) to this report.
>
> I'm seeing *very* few changes to the core suspend/resume path in 3.7,
> and while there are some acpia updates, they seem to be pretty mild
> too.
>
> I think the acpi_os_wait_semaphore thing is a red herring - that's
> just stale on the stack.
>
> Do you have the register state from the oops? Or at least the "Code:"
> line? It would be nice to see exactly where the oops happens, and I
> cannot line up your "acpi_ns_lookup  + 0xa1/0x5b9" with any code due
> to different compilers (and configurations etc).
>
>                 Linus
>


I've opened  https://bugzilla.kernel.org/show_bug.cgi?id=51071
and attached picture there which is all I have.

I'll try to decode exact code line.


In all cases - I've played even with 3.4 kernel - which also does not survive 
multiple resumes in docking station - though it just leaves black screen - so 
this oops is rather 'progress' and it also could be false path.

It's probably not a regression from 3.6 - since this problem was there for 
much longer - but now it has just become much more visible.

As I usually do not have reason to make multiple suspend/resumes in dock I've 
not noticed it until now when I've tried to capture this ACPI trace.

Zdenek


  reply	other threads:[~2012-11-28 16:21 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-15 16:09 Acpi deadlocks with 3.7.0-rc4 Zdenek Kabelac
2012-11-28 16:01 ` Linus Torvalds
2012-11-28 16:21   ` Zdenek Kabelac [this message]
2012-11-28 17:02     ` Linus Torvalds
2012-11-28 17:27       ` Zdenek Kabelac
2012-11-28 19:07         ` Linus Torvalds
2012-11-28 20:05           ` Rafael J. Wysocki
2012-11-29 10:13           ` Zdenek Kabelac
2012-11-29 10:59             ` Rafael J. Wysocki
2012-11-29 12:26               ` Zdenek Kabelac
2012-11-29 16:59                 ` Rafael J. Wysocki
2012-11-28 20:31         ` Rafael J. Wysocki
2012-11-29  9:03           ` Zdenek Kabelac
2012-11-29 10:09             ` Rafael J. Wysocki
2012-11-28 18:35     ` Rafael J. Wysocki

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=50B63A04.9010901@redhat.com \
    --to=zkabelac@redhat.com \
    --cc=lenb@kernel.org \
    --cc=linux-acpi@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=rjw@sisk.pl \
    --cc=torvalds@linux-foundation.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.