Old Synopsis: Random acpi panic
New Synopsis: [acpi] Random acpi panic
Responsible-Changed-From-To: freebsd-bugs-freebsd-acpi
Responsible-Changed-By: linimon
Responsible-Changed-When: Fri Dec 28 10:15:10 UTC 2012
Responsible-Changed-Why:
Over to maintainer(s).
http://www.freebsd.org/cgi/query
On Sun, Dec 23, 2012 at 09:25:41PM +0200, Andriy Gapon wrote:
Stefan,
long time, no news...
So, I decided to attempt a different approach to the problem.
Could you please try the following patch if you are still experiencing the
problem? Could you please report how it goes?
My hope
Stefan,
long time, no news...
So, I decided to attempt a different approach to the problem.
Could you please try the following patch if you are still experiencing the
problem? Could you please report how it goes?
My hope is that, even if the problem persist, it will be easier to debug it
on 04/12/2012 10:50 Stefan Farfeleder said the following:
These checks have not triggered additional panics. I still get the cycle
one.
I am really out of ideas now on how that cycle could be created... :-(
Perhaps, try to add another copy of the loop detection code to the place after
an object
On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote:
Also, I've just realized that the check is racy...
Could you please move the whole check block (between and excluding
AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following
lines:
Status =
on 29/11/2012 10:46 Stefan Farfeleder said the following:
On Mon, Nov 26, 2012 at 01:13:46PM +0200, Andriy Gapon wrote:
Also, I've just realized that the check is racy...
Could you please move the whole check block (between and excluding
AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right
On Sun, Nov 25, 2012 at 06:17:37PM +0200, Andriy Gapon wrote:
@@ -238,6 +240,10 @@ AcpiOsReleaseObject (
if (Object == Curr) {
panic(freeing a free object %p, Object);
}
+Depth--;
+if (Depth 0) {
+panic(cycle in a cache list);
+
On Mon, Nov 26, 2012 at 11:29:55AM +0200, Andriy Gapon wrote:
Very interesting, thank you.
Are you able to get a crash dump?
Yes.
(kgdb) bt
#0 doadump (textdump=0) at pcpu.h:229
#1 0x802becae in db_dump (dummy=value optimized out, dummy2=0,
dummy3=0, dummy4=0x0) at
on 26/11/2012 11:37 Stefan Farfeleder said the following:
On Mon, Nov 26, 2012 at 11:29:55AM +0200, Andriy Gapon wrote:
Very interesting, thank you.
Are you able to get a crash dump?
Yes.
Great!
Could you please cast those cycled objects to 'union acpi_operand_object' and
print them?
On Mon, Nov 26, 2012 at 01:06:18PM +0200, Andriy Gapon wrote:
on 26/11/2012 12:47 Stefan Farfeleder said the following:
BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the
DescriptorType is at offset 8 from the object start and gets immediately
overwritten by the next
Also, I've just realized that the check is racy...
Could you please move the whole check block (between and excluding
AcpiUtAcquireMutex and AcpiUtReleaseMutex) down right below the following lines:
Status = AcpiUtAcquireMutex (ACPI_MTX_CACHES);
if (ACPI_FAILURE (Status))
on 26/11/2012 13:10 Stefan Farfeleder said the following:
On Mon, Nov 26, 2012 at 01:06:18PM +0200, Andriy Gapon wrote:
on 26/11/2012 12:47 Stefan Farfeleder said the following:
BTW, I noticed the ACPI_SET_DESCRIPTOR_TYPE code is pointless, because the
DescriptorType is at offset 8 from the
on 25/11/2012 16:00 Stefan Farfeleder said the following:
Hi Andriy,
with your patch my notebook has a ~50% chance of stalling during boot.
This always happens after the Entropy harvesting line and I can only
power it down then.
I guess somehow cycles are introduced into the acpi objects
On Wed, Nov 21, 2012 at 11:48:41AM +0100, Stefan Farfeleder wrote:
On Wed, Nov 21, 2012 at 12:55:36AM +0200, Andriy Gapon wrote:
on 20/11/2012 12:35 Stefan Farfeleder said the following:
Hi,
today I got the following panic on booting. The error seems to be some
kind of race
on 22/11/2012 10:18 Stefan Farfeleder said the following:
I'm afraid the AcpiOsAcquireObject panic is not directly related to
reference counting. I had the very same panic today with your patch.
OK, let's try to attack it from a different angle.
Please try this patch:
diff --git
on 22/11/2012 12:24 Andriy Gapon said the following:
on 22/11/2012 10:18 Stefan Farfeleder said the following:
I'm afraid the AcpiOsAcquireObject panic is not directly related to
reference counting. I had the very same panic today with your patch.
OK, let's try to attack it from a different
A patch that should actually compile, finally.
BTW, it's probably better to replace the NULL dereference trick with a simple
panic call in the first patch too.
diff --git a/sys/contrib/dev/acpica/components/utilities/utcache.c
b/sys/contrib/dev/acpica/components/utilities/utcache.c
index
On Wed, Nov 21, 2012 at 12:55:36AM +0200, Andriy Gapon wrote:
on 20/11/2012 12:35 Stefan Farfeleder said the following:
Hi,
today I got the following panic on booting. The error seems to be some
kind of race condition, as the same kernel booted fine before and
afterwards. This is
Hi,
today I got the following panic on booting. The error seems to be some
kind of race condition, as the same kernel booted fine before and
afterwards. This is current, r243234.
Any additional information required to debug/fix this?
Stefan
###
mole.fafoe.narf.at dumped core - see
on 20/11/2012 12:35 Stefan Farfeleder said the following:
Hi,
today I got the following panic on booting. The error seems to be some
kind of race condition, as the same kernel booted fine before and
afterwards. This is current, r243234.
Any additional information required to debug/fix
Synopsis: [acpi] [panic] kernel trap with acpi enabled
State-Changed-From-To: feedback-closed
State-Changed-By: jh
State-Changed-When: Sun Mar 4 16:04:31 UTC 2012
State-Changed-Why:
Feedback timeout.
http://www.freebsd.org/cgi/query-pr.cgi?pr=144045
Synopsis: [acpi] [panic] kernel trap with acpi enabled
State-Changed-From-To: open-feedback
State-Changed-By: jh
State-Changed-When: Sun Nov 27 11:48:05 UTC 2011
State-Changed-Why:
Note that submitter has been asked for feedback.
http://www.freebsd.org/cgi/query-pr.cgi?pr=144045
The following reply was made to PR kern/142009; it has been noted by GNATS.
From: Andriy Gapon a...@icyb.net.ua
To: bug-follo...@freebsd.org, swhet...@gmail.com
Cc:
Subject: Re: kern/142009: [acpi] [panic] Panic in AcpiNsGetAttachedObject
Date: Mon, 11 Oct 2010 19:59:32 +0300
Scot,
do you
23 matches
Mail list logo
