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
-Original Message-
From: Andriy Gapon [mailto:a...@freebsd.org]
Sent: 14. november 2012 12:22
To: Tom Lislegaard
Cc: freebsd-acpi@FreeBSD.org
Subject: Re: AcpiOsAcquireObject crash [Was: 9-Stable panic:
resource_list_unreserve: can't find
resource]
on 13/11/2012 17:14 Andriy
I would like to propose the following patch which should kill two birds with one
stone:
- avoid race in acpi_cpu_cx_cst if more than one notifications occur in a rapid
succession for the same CPU and end up being concurrently handled by ACPI
taskqeue
threads
- avoid race acpi_cpu_cx_cst and
