Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 21 Sep 2007 18:27:28 -0400
From:      Jung-uk Kim <jkim@FreeBSD.org>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        freebsd-acpi@FreeBSD.org, freebsd-current@FreeBSD.org
Subject:   Re: [PATCH] OsdSynch.c modernization
Message-ID:  <200709211827.29763.jkim@FreeBSD.org>
In-Reply-To: <200709211715.17940.jhb@freebsd.org>
References:  <200709181516.11207.jkim@FreeBSD.org> <200709211715.17940.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help
On Friday 21 September 2007 05:15 pm, John Baldwin wrote:
> On Tuesday 18 September 2007 03:16:07 pm Jung-uk Kim wrote:
> > I have rewritten sys/dev/acpica/Osd/OsdSynch.c to match the
> > modern ACPI-CA and -CURRENT:
> >
> > http://people.freebsd.org/~jkim/acpica/OsdSynch.diff
>
> Why do you use a loop around tsleep() rather than just use
> sx_xlock() (which will block) for the WAIT_FOREVER case when
> waiting on a semaphore?

You mean for AcpiOsAcquireMutex()?  sx_xlock() cannot be waken up by 
the wait channel.

> Why don't you just use a spin mutex for the spin lock?
> That is a far better fit than the sx lock stuff you are doing.
> Manually doing spinlock_enter() (wrongly btw, you should use
> critical_enter(), not sched_pin() otherwise you can be preempted)
> just to avoid the assertion failure is just going to result in
> obscure hangs.  Does ACPI-CA want to malloc() while holding an ACPI
> spin lock or something?

I thought exactly the same when I started rewriting it (almost half 
year ago!).  I have tried all of the above, spent numerous sleepless 
nights, and miserably failed. :-(

Spin mutex is too restrictive (e.g., it cannot be used with other 
locks gracefully).  critical_enter() causes:

panic: blockable sleep lock (sleep mutex) 32 @
/usr/src/sys/vm/uma_core.c:1830 cpuid = 0
KDB: enter: panic
[thread pid 21 tid 100013 ]
Stopped at      kdb_enter+0x32: leave

http://docs.freebsd.org/cgi/mid.cgi?200709121927.46465.jkim

I guess it wants to malloc() while holding spin lock although I 
haven't traced it down.

I intend to investigate and fix further after RELENG_7 is branched and 
I really like to hear more ideas from you.

Thanks,

Jung-uk Kim



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200709211827.29763.jkim>