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 KimReceived on Fri Sep 21 2007 - 20:27:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:18 UTC