From owner-acpi-jp@jp.freebsd.org  Wed Mar 21 13:27:47 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id NAA45839;
	Wed, 21 Mar 2001 13:27:47 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from mass.dis.org ([206.112.120.82])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id NAA45830;
	Wed, 21 Mar 2001 13:27:42 +0900 (JST)
	(envelope-from msmith@mass.dis.org)
Received: from mass.dis.org (localhost [127.0.0.1])
	by mass.dis.org (8.11.2/8.11.2) with ESMTP id f2L4QRO01663;
	Tue, 20 Mar 2001 20:26:28 -0800 (PST)
	(envelope-from msmith@mass.dis.org)
Message-Id: <200103210426.f2L4QRO01663@mass.dis.org>
X-Mailer: exmh version 2.1.1 10/15/1999
To: acpi-jp@jp.freebsd.org
cc: jhb@FreeBSD.org, iwasaki@jp.freebsd.org
In-reply-to: Your message of "Wed, 21 Mar 2001 13:23:25 +0900."
             <20010321132325E.iwasaki@jp.FreeBSD.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Tue, 20 Mar 2001 20:26:26 -0800
From: Mike Smith <msmith@freebsd.org>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1110
Subject: [acpi-jp 1110] Re: acpica-unix-20010313.tar.gz 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: msmith@freebsd.org


JFYI, I have the latest Intel drop building and once I've had time to 
absorb this thread, will be bringing it in.  Intel did us something of a 
big disfavour by moving everything around, as it's going to make a mess 
in the repo, but fortunately we haven't tagged anything yet. 8)

> 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

-- 
... every activity meets with opposition, everyone who acts has his
rivals and unfortunately opponents also.  But not because people want
to be opponents, rather because the tasks and relationships force
people to take different points of view.  [Dr. Fritz Todt]
           V I C T O R Y   N O T   V E N G E A N C E


