From owner-acpi-jp@jp.freebsd.org  Wed Mar 21 13:23:35 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id NAA45553;
	Wed, 21 Mar 2001 13:23:35 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from tasogare.imasy.or.jp (root@tasogare.imasy.or.jp [202.227.24.5])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id NAA45547;
	Wed, 21 Mar 2001 13:23:32 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
Received: from localhost (iwasaki.imasy.or.jp [202.227.24.92])
	by tasogare.imasy.or.jp (8.11.3+3.4W/8.11.3/tasogare) with ESMTP/inet id f2L4NRb37452;
	Wed, 21 Mar 2001 13:23:28 +0900 (JST)
	(envelope-from iwasaki@jp.FreeBSD.org)
To: acpi-jp@jp.freebsd.org, jhb@FreeBSD.org
Cc: iwasaki@jp.freebsd.org
In-Reply-To: <XFMail.010320154820.jhb@FreeBSD.org>
References: <20010320223051F.iwasaki@jp.FreeBSD.org>
	<XFMail.010320154820.jhb@FreeBSD.org>
X-Mailer: Mew version 1.94.1 on Emacs 19.34 / Mule 2.3 (SUETSUMUHANA)
Mime-Version: 1.0
Content-Type: Text/Plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Message-Id: <20010321132325E.iwasaki@jp.FreeBSD.org>
Date: Wed, 21 Mar 2001 13:23:25 +0900
From: Mitsuru IWASAKI <iwasaki@jp.freebsd.org>
X-Dispatcher: imput version 20000228(IM140)
Lines: 56
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1109
Subject: [acpi-jp 1109] Re: acpica-unix-20010313.tar.gz
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: iwasaki@jp.freebsd.org

Hi, John.

> > +UINT32
> > +AcpiOsGetThreadId(void)
> > +{
> > +    FUNCTION_TRACE(__FUNCTION__);
> > +
> > +    if (curproc) {
> > +     return((curproc->p_pid) ? curproc->p_pid : 1);
> > +    }
> > +
> > +    return(1);
> > +}
> 
> curproc should never be NULL.  I would rather you use a KASSERT() to panic if
> it is.  We set curproc in the MD startup code before any MI code is called now.

OK.

> Even if it were NULL, then the proper value to return would be 0, not 1, as the
> pid of proc0 is 0.  This should probably look something like this:

No, we can't return 0 here otherwise acpi_pcib0 and some other devices
won't be probed.  In newer AcpiCmAcquireMutex(), you would see the
following.

    ThisThreadId = AcpiOsGetThreadId ();

    /*
     * Deadlock prevention.  Check if this thread owns any mutexes of value
     * greater than or equal to this one.  If so, the thread has violated
     * the mutex ordering rule.  This indicates a coding error somewhere in
     * the ACPI subsystem code.
     */
    for (i = MutexId; i < MAX_MTX; i++)
    {
        if (AcpiGbl_AcpiMutexInfo[i].OwnerId == ThisThreadId)
        {
            if (i == MutexId)
            {
                DEBUG_PRINT (ACPI_ERROR,
                        ("Mutex [%s] already acquired by this thread [%X]\n",
                        AcpiCmGetMutexName (MutexId), ThisThreadId));

                return (AE_ALREADY_ACQUIRED);
            }

Here if our AcpiOsGetThreadId() returns 0, AcpiCmAcquireMutex()
returns AE_ALREADY_ACQUIRED or AE_ACQUIRE_DEADLOCK because
AcpiGbl_AcpiMutexInfo[i].OwnerId has 0 as initial value.

AcpiCmAcquireMutex() is called from AcpiAmlEnterInterpreter(),
AcpiNsGetObjectValue(), AcpiNsEvaluateRelative(), AcpiCmExecute_HID(),
AcpiGetObjectInfo(), acpi_MatchHid() and probe routines in sys/dev/acpica/.

Thanks
