RE: [PATCH] OsdSynch.c modernization

I can look around a bit, but I don't think we'd make any system calls
while holding a spinlock. 

Bob


>-----Original Message-----
>From: owner-freebsd-acpi_at_freebsd.org [mailto:owner-freebsd-
>acpi_at_freebsd.org] On Behalf Of Jung-uk Kim
>Sent: Friday, September 21, 2007 3:27 PM
>To: John Baldwin
>Cc: freebsd-acpi_at_FreeBSD.org; freebsd-current_at_FreeBSD.org
>Subject: Re: [PATCH] OsdSynch.c modernization
>
>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 _at_
>/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
>_______________________________________________
>freebsd-acpi_at_freebsd.org mailing list
>http://lists.freebsd.org/mailman/listinfo/freebsd-acpi
>To unsubscribe, send any mail to "freebsd-acpi-unsubscribe_at_freebsd.org"