RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

> -Original Message-
> From: Hans Petter Selasky [mailto:h...@selasky.org]
> Sent: Tuesday, January 3, 2017 8:23 AM
> To: Moore, Robert <robert.mo...@intel.com>; Edward Tomasz Napierala
> <tr...@freebsd.org>; O. Hartmann <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 01/03/17 16:26, Moore, Robert wrote:
> > Not sure I understand. The fix has been committed, and is part of
> version 20161222.
> >
> >
> 
> Hi Robert,
> 
>  From what I can see that patches have been pushed to the following
> branch, vendor-sys/acpica/20161222/, see:
> 
> https://svnweb.freebsd.org/changeset/base/310451
> 
> But not yet to "master" (12-current) ?
[Moore, Robert] 


Everything goes to master.


> 
> Is that correct?
> 
> My console has been filling up with messages like this:
> 
> > ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for
> > [OpcodeName unavailable] (20161117/dswexec-498) ACPI Error: Method
> > parse/execution failed [\134_SB.PCI0.LPCB.H_EC._Q50] (Node
> > 0xf800047fce40), AE_AML_OPERAND_TYPE (20161117/psparse-560)
> > acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE
> 
> over the holidays, so I assume that means the previous version of ACPI,
> 20161117 which the 20161222 version is supposed to fix.
[Moore, Robert] 

Yes the messages above come from 20161117. Version is in the error messages.

> > 0xf800047fce40), AE_AML_OPERAND_TYPE (20161117/psparse-560)




> 
> --HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

Not sure I understand. The fix has been committed, and is part of version 
20161222.


> -Original Message-
> From: Hans Petter Selasky [mailto:h...@selasky.org]
> Sent: Monday, January 2, 2017 12:30 AM
> To: Moore, Robert <robert.mo...@intel.com>; Edward Tomasz Napierala
> <tr...@freebsd.org>; O. Hartmann <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 12/22/16 21:04, Moore, Robert wrote:
> > ACPICA version 20161222 happened today, with a fix for the problem
> below.
> >
> 
> +1
> 
> When will the fix be merged to -head ?
> 
> --HPS

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

ACPICA version 20161222 happened today, with a fix for the problem below.


> -Original Message-
> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> a...@freebsd.org] On Behalf Of Moore, Robert
> Sent: Wednesday, December 21, 2016 7:21 AM
> To: Edward Tomasz Napierala <tr...@freebsd.org>; O. Hartmann
> <ohartm...@walstatt.org>
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov <zakharov...@gmail.com>
> Subject: RE: ACPI Error on HP ProBook 430 G2
> 
> We have fixed this issue for the latest version of ACPICA that will
> happen this week, probably 22 december.
> 
> 
> > -Original Message-
> > From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> > a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> > Sent: Wednesday, December 21, 2016 3:15 AM
> > To: O. Hartmann <ohartm...@walstatt.org>
> > Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> > Zakharov <zakharov...@gmail.com>
> > Subject: Re: ACPI Error on HP ProBook 430 G2
> >
> > On 1220T1734, O. Hartmann wrote:
> > > Am Tue, 20 Dec 2016 18:09:20 +0300
> > > Vladimir Zakharov <zakharov...@gmail.com> schrieb:
> > >
> > > > Hello!
> > > >
> > > > Some time ago new ACPI messages appeared on console and in
> > > > /var/log/messages. Like
> > > > these:
> > > >
> > > > ACPI Error: Needed type [Reference], found [Processor]
> > > > 0xf800043b8980
> > > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > > resolving operands for [OpcodeName unavailable]
> > > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > > AE_AML_OPERAND_TYPE
> > > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> > failed:
> > > > AE_AML_OPERAND_TYPE
> > > >
> > > > I'm sure that there were no such messages earlier. Suspend/resume
> > > > works for me. But after disconnecting power line hw.acpi.acline
> > > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> > anymore.
> > > >
> > > > System info:
> > > > $ uname -a
> > > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > > Tue Dec 20 16:42:21 MSK 2016
> > > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > > >
> > > > dmesg: http://pastebin.com/cYD8cR0b
> > > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > > >
> > > >
> > > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > > >
> > >
> > > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI
> > > notebook running most recent CURRENT ...
> >
> > +1, I see the same on Thinkpad T420.
> >
> > ___
> > freebsd-a...@freebsd.org mailing list
> > https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> > To unsubscribe, send any mail to "freebsd-acpi-
> unsubscr...@freebsd.org"
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: ACPI Error on HP ProBook 430 G2

[Moore, Robert]

We have fixed this issue for the latest version of ACPICA that will happen this 
week, probably 22 december.


> -Original Message-
> From: owner-freebsd-a...@freebsd.org [mailto:owner-freebsd-
> a...@freebsd.org] On Behalf Of Edward Tomasz Napierala
> Sent: Wednesday, December 21, 2016 3:15 AM
> To: O. Hartmann 
> Cc: freebsd-a...@freebsd.org; freebsd-current@freebsd.org; Vladimir
> Zakharov 
> Subject: Re: ACPI Error on HP ProBook 430 G2
> 
> On 1220T1734, O. Hartmann wrote:
> > Am Tue, 20 Dec 2016 18:09:20 +0300
> > Vladimir Zakharov  schrieb:
> >
> > > Hello!
> > >
> > > Some time ago new ACPI messages appeared on console and in
> > > /var/log/messages. Like
> > > these:
> > >
> > > ACPI Error: Needed type [Reference], found [Processor]
> > > 0xf800043b8980
> > > (20161117/exresop-111) ACPI Exception: AE_AML_OPERAND_TYPE, While
> > > resolving operands for [OpcodeName unavailable]
> > > (20161117/dswexec-498) ACPI Error: Method parse/execution failed
> > > [\134_SB.PCI0.LPCB.EC0.PPNT] (Node 0xf80004396640),
> > > AE_AML_OPERAND_TYPE
> > > (20161117/psparse-560) ACPI Error: Method parse/execution failed
> > > [\134_SB.PCI0.LPCB.EC0._Q04] (Node 0xf80004396c40),
> > > AE_AML_OPERAND_TYPE
> > > (20161117/psparse-560) acpi_ec0: evaluation of query method _Q04
> failed:
> > > AE_AML_OPERAND_TYPE
> > >
> > > I'm sure that there were no such messages earlier. Suspend/resume
> > > works for me. But after disconnecting power line hw.acpi.acline
> > > still equals to 1. And powerd/powerdxx do not adjust CPU frequency
> anymore.
> > >
> > > System info:
> > > $ uname -a
> > > FreeBSD vzakharov 12.0-CURRENT FreeBSD 12.0-CURRENT #14 r310326M:
> > > Tue Dec 20 16:42:21 MSK 2016
> > > root@vzakharov:/home/obj/usr/src/sys/GENERIC-NODEBUG  amd64
> > >
> > > dmesg: http://pastebin.com/cYD8cR0b
> > > hw.acpi: http://pastebin.com/Tht9B0FZ
> > > acpidump: http://vzakharov.ru/z2v-HPProBook430G2.asl
> > >
> > >
> > > PS. I'm not subscribed to freebsd-acpi. So keep me in CC, please.
> > >
> >
> > I see lots of ACPI errors also shortly on a Lenovo E540 UEFI notebook
> > running most recent CURRENT ...
> 
> +1, I see the same on Thinkpad T420.
> 
> ___
> freebsd-a...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-acpi
> To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

RE: [acpi-jp 2274] Re: HEADSUP: acpi patches in the tree

[Moore, Robert]

TABLE_ID_DSDT was removed because the table ID should be dynamically
allocated.  There was a longstanding TBD to remove it.

It appears that there is some issue with this change, and of course we
would like to get to the root of this problem.

Bob

 -Original Message-
 From: Takayoshi Kochi [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 28, 2003 9:24 AM
 To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: [acpi-jp 2274] Re: HEADSUP: acpi patches in the tree
 
 Hi,
 
 From: Nate Lawson [EMAIL PROTECTED]
 Subject: [acpi-jp 2267] Re: HEADSUP: acpi patches in the tree
 Date: Tue, 27 May 2003 16:58:59 -0700
 
  On Wed, 28 May 2003, Shin-ichi YOSHIMOTO wrote:
   After this update, I found some error messages like this:
  
   acpi0: IntelR AWRDACPI on motherboard
   ACPI-0438: *** Error: Looking up [\\_OS_] in namespace,
 AE_NOT_FOUND
   ACPI-1287: *** Error: Method execution failed
[\\_SB_.PCI0._INI]
 (Node 0xc21b73e0), AE_NOT_FOUND
 
  Please try the attached patch and see if it changes things for you.
 
 I'm still studying the reason why the TABLE_ID_DSDT is removed
 in recent ACPI CA, but at least you should remove all TABLE_ID_DSDT's,
 I think.
 
 Also, ACPI_FIRST_METHOD_ID should be larger than 0,
 otherwise 0 may be allocated to running method and make a conflict.
 
 I've made a diff against NetBSD-current and just booted the kernel,
 but haven't tested much (and still trying to make out what the
 changes are intended).
 
 Attached is the patch and should apply to the FreeBSD tree with
 some appropriate option.
 
 ---
 Takayoshi Kochi
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: [acpi-jp 2279] Re: HEADSUP: acpi patches in the tree

[Moore, Robert]

Here's what we released:

#define ACPI_FIRST_METHOD_ID0x0001
#define ACPI_FIRST_TABLE_ID 0xF000



 -Original Message-
 From: Nate Lawson [mailto:[EMAIL PROTECTED]
 Sent: Wednesday, May 28, 2003 11:00 AM
 To: Takayoshi Kochi
 Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
 Subject: [acpi-jp 2279] Re: HEADSUP: acpi patches in the tree
 
 On Thu, 29 May 2003, Takayoshi Kochi wrote:
  I'm still studying the reason why the TABLE_ID_DSDT is removed
  in recent ACPI CA, but at least you should remove all
TABLE_ID_DSDT's,
  I think.
 
  Also, ACPI_FIRST_METHOD_ID should be larger than 0,
  otherwise 0 may be allocated to running method and make a conflict.
 
  I've made a diff against NetBSD-current and just booted the kernel,
  but haven't tested much (and still trying to make out what the
  changes are intended).
 
  Attached is the patch and should apply to the FreeBSD tree with
  some appropriate option.
 
 Thank you for the patch.  Since we are only days away from a release,
I
 would like to avoid using the new dynamic ID allocation code and
instead
 stick to hard-coding the defaults.  This is the safer way for 5.1R.
We
 will do a new import and more fixes after the release.
 
 -Nate
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]

RE: [acpi-jp 2009] Re: ACPI errors w/ latest ACPI code on GA BX2000 based system

[Moore, Robert]

I think this code is the problem:

Scope(\_TZ_) {
ThermalZone(THRM) {
Name(_AL0, Package(0x1) {
FAN_,
})


The name FAN_ is not defined elsewhere in the namespace.

Bob


-Original Message-
From: Thomas Seck [mailto:[EMAIL PROTECTED]] 
Sent: Saturday, November 30, 2002 4:34 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 2009] Re: ACPI errors w/ latest ACPI code on GA BX2000
based system

* Mitsuru IWASAKI ([EMAIL PROTECTED]):

Iwasaki-san,
list members,

   ACPI-0438: *** Error: Looking up [FAN_] in namespace, AE_NOT_FOUND
   ACPI-1287: *** Error: Method execution failed, AE_NOT_FOUND
 
 I think that this was caused by the following spec changes.
 From CHANGES.txt:
 
 22 October 2002.  Summary of changes for version 20021022.
 
 1) ACPI CA Core Subsystem:
 
 Implemented a restriction on the Scope operator that the
 target must already exist in the namespace at the time the
 operator is encountered (during table load or method
 execution).  In other words, forward references are not
 allowed and Scope() cannot create a new object. This changes
 the previous behavior where the interpreter would create the
 name if not found.  This new behavior correctly enables the
 search-to-root algorithm during namespace lookup of the target
 name.  Because of this upsearch, this fixes the known Compaq
 _SB_.OKEC problem and makes both the AML interpreter and iASL
 compiler compatible with other ACPI implementations.
 
 
 Could you send your acpidump output to this acpi-jp ML?

Of course. And thank you very much for working on this. Please see the
attached file.

 --Thomas

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!

[Moore, Robert]

The deleted object problem has been fixed in the 20021122 release which
should be available soon, if not already.  (I was able to reproduce the
problem with your dsdt on previous releases, and I verified it fixed with
the 11/22 release.)

I did not see any mutex issues -- as we found out on Linux, the OSL
implementation of wait_semaphore is often the culprit.

Bob


-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, November 27, 2002 12:37 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: [acpi-jp 1988] Re: ACPI errors and then panic - fixed!

Hi, Intel folks.
It seems that there is a bug in cached object utilization.
This causes strange behavior;
first evaluation of \_SB_.PCI0.LPC_.EC__.BAT0._BST is OK, but
second (or later) evaluation returns AE_TYPE.

 acpi_cmbat0: error fetching current battery status -- AE_TYPE

The raw DSDT is at:
http://www.root.org/~nate/acpi/ibm.dsdt

I guess that InternalObject was returned to cache in AcpiUtReleaseToCache()
but the same object is still in use somewhere (for ResultObj ?).

I could reproduce this problem with acpica debugger.  Trace output attached.
I'll track this down later.

Thanks


% acpicadb ibm.dsdt
Loading Acpi table from file ibm.dsdt
  utmisc-0802 [11] UtAcquireMutex: Mutex [ACPI_MTX_Namespace]
already acquired by this thread [C25]
  utmisc-0802 [11] UtAcquireMutex: Mutex [ACPI_MTX_Namespace]
already acquired by this thread [C25]
Parsing
Methods:



..
Table [DSDT] - 1208 Objects with 61 Devices 354 Methods 18 Regions
Acpi table [DSDT] successfully installed and loaded
- f _BST
  \_SB_.PCI0.LPC_.EC__.BAT0._BST (0x80ba0a8) - Method
  \_SB_.PCI0.LPC_.EC__.BAT1._BST (0x80ba6a8) - Method
- debug _SB_.PCI0.LPC_.EC__.BAT0._BST
Executing \_SB_.PCI0.LPC_.EC__.BAT0._BST
0 #007F XOr (DerefOf (Index (BT0I, 0x00)))

% 
ArgObj:0x80b9ea8 NodeName BT0I Package 0x80e1ba8
ArgObj:0x80f9fa8 Obj Integer 
ArgObj:0x80fe028 Obj Integer 
0 #0037 [EvalSubTree] (Package (0x0D)
{
0x00, 
0x, 
0x, 
0x01, 
0x2A30, 
0x00, 
0x00, 
0x01, 
0x01, 
, 
, 
, 

})


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1982] Re: Call for testers: acpica-unix-20021118.tar.gz

[Moore, Robert]

You'll need to enable the ACPI debug output and send this out so we can get
a better idea of what is going on.

Thanks,
Bob


-Original Message-
From: Matthew Emmerton [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, November 26, 2002 5:54 AM
To: [EMAIL PROTECTED]; Mitsuru IWASAKI
Cc: [EMAIL PROTECTED]
Subject: [acpi-jp 1982] Re: Call for testers: acpica-unix-20021118.tar.gz

ACPI stiil fails miserably on my Thinkpad T23 with these patches.

I've attached the ASL and DSDT data in tar.gz format.

Output from boot -v (transcribed by hand, so forgive any obvious typos)
Note -- the 'o' character in 'So' below is really o with an umlat.  I
suspect the space in 'T ' is a non-breaking space as well.

acpi0:  IBM TP-1A on motherboard
ACPI-0625:  *** Info: GPE Block0 defined as GPE0 to GPE15
ACPI-0625:  *** Info: GPE Block1 defined as GPE16 to GEP31
pci_open(1):   mode 1 addr port (0x0cf8) is 0x8058
pci_open(1a):   mode1res=0x8000 (0x8000)
pci_cfgcheck:  device 0 [class=06] [hdr=00] is there (id=35758086)
Using $PIR table, 14 entries at 0xc00fdeb0
 skipping PCI interrupt list 
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-1287: *** Error: Method execution failed, AE_NOT_EXIST
ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name:
f0009453
ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER
ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER
ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name:
f0009453
ACPI-0438: *** Error: Looking up [So] in namespace, AE_BAD_CHARACTER
ACPI-1287: *** Error: Method execution failed, AE_BAD_CHARACTER
ACPI-0383: *** Error: NsSearchAndEnter: Bad character in ACPI Name:
f000ff54
ACPI-0438: *** Error: Looking up [T ] in namespace, AE_BAD_CHARACTER
 repeat last 3 lines 8 times 

panic: kmem_malloc: entry not found or misaligned
Debugger(panic)
Stopped at   Debugger+0x54:  xchgl  %ebx,in_Debugger.0
db show registers
..
edx 0x40
ebx   0
...
db trace
panic(c03d0e4c,0,c05838c0,1,0) at panic+0xab
kmem_malloc(c0832078,1000,1,c058391c,c034c20b) at kmem_malloc+0x33c
page_alloc(c083ac80,1000,c058390f,1,780) at page_alloc_0x27
slab_zalloc(c083ac80,1,c4049f6c,c4049f40,63) at slab_zalloc+0xfb
uma_zone_slab(c083ac80,1,15f,c4046400,c083ad68) at uma_zone_slab+0x9e
uma_zalloc_bucket(c083ac80,1,c03d2929,57e,c151a380) at
uma_zalloc_bucekt+0x16d
uma_zalloc_arg(c083ac80,0,1,c151a380,c083ac80) at uma_zalloc_arg+0x2f5
malloc(1c,c0550da0,1,c0583940,c0538538) at malloc+0x76
AcpiOsAllocate(1c,c05839f0,c053a4fc,c054fe24,0) at AcpiOsAllocate+0x21
AcpiUtCallocate(1c,1,c054b483,ff,0) at AcpiUtCallocate+0x48
AcpiUtAcquireFromCache(3,0,100,0,c3fa4000) at
AcpiUtAcquireFromCache+0xac
AcpiPsAllocOp(0,c4046400,0,c0246966,c3fa41e4) at AcpiPsAllocOp+0x7c
AcpiPsParseLoop(c3fa4000,c403b040,c0583b0c,0,0) at AcpiPsParseLoop+0x37e
AcpiPsParseAml(c3fa4000,c4040340,c4044700,d7ae2332,2f) at
AcpiPsParseAml+0x7c
AcpiPsxExecute(c4044700,0,c0583b74,c4044700,c0583bfc) at
AcpiPsxExecute+0x12f
AcpiNsExecuteControlMethod(c4044700,0,c0583b74,c151a500,0) at
AcpiNsExecuteControlMethod+0x5f
AcpiNsEvaluateByHandle(c4044700,0,c0583bfc,e,0) at AcpiNsEvalueByHandle+0x92
AcpiNsEvaluateRelative(c4044760,c054b6d3,0,c0583bfc0) at
AcpiNsEvaluateRelative+0xde
AcpiUtExecute_STA(c4044760,c0583c20,0,0,c0583c30) at AcpiUtExecute_STA+0x31
AcpiNsInitOneDevice(c4044760,2,c0583c84,0,6) at AcpiNsInitOneDevice+0x77
AcpiNsInitializeDevices(0,c0583cdc,c053b42e,0,2) at
AcpiNsInitializeDevices+0x53
AcpiInitializeObjects(0,2,c052b930,0,0) at AcpiInitializeObjects+0x14
acpi_attach(c403c200,c4005098,c03e3954,c1503a70,c05500e3) at
acpi_attach+0x15e


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1961] Re: Call for testers: acpica-unix-20021118.tar.gz

[Moore, Robert]

ACPI-0483: *** Error: GPE0 block (GPE 0 to 15) overlaps the GPE1 block
(GPE 0 to 15)

It appears that in your machine's FADT:
 
1) There is a GPE1 block defined (GPE1_BLK, GPE1_BLK_LEN)
2) The GPE1_BASE is set to zero.

One of these is wrong.

Bob


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1964] Re: Call for testers: acpica-unix-20021118.tar.gz

[Moore, Robert]

DSDT=0x3ffbf77
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0xb1, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x1000-0x1003
PM1a_CNT_BLK=0x1004-0x1005
PM2_CNT_BLK=0x1030-0x1030
PM2_TMR_BLK=0x1008-0x100b
PM2_GPE0_BLK=0x1018-0x101b
P_LVL2_LAT=200ms, P_LVL3_LAT=2000ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=72, MON_ALRM=73, CENTURY=50
Flags={WBINVD,PROC_C1,SLP_BUTTON,TMR_VAL_EXT}

Juli, John,

This is interesting that no GPE1 information shows up.

It may be the case that GPE1_BLK is zero, but GPE1_BLK_LEN is not zero in
the FADT.

According to the ACPI spec, only (GPE1_BLK == 0) indicates that there is no
GPE1 block;  It may be that if GPE1_BLK_LEN is non-zero, but GPE1_BLK is
zero, the CA code is not handling this correctly.  I will investigate and
report back.

Bob


To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.tar .gz

[Moore, Robert]

Unfortunately, the ACPI specification also says this:

Each register block contains two registers of equal length: GPEx_STS and
GPEx_EN (where x is 0 or 1). The length of the GPE0_STS and GPE0_EN
registers is equal to half the GPE0_LEN. The length of the GPE1_STS and
GPE1_EN registers is equal to half the GPE1_LEN. If a generic register block
is not supported then its respective block pointer and block length values
in the FADT table contain zeros. The GPE0_LEN and GPE1_LEN do not need to be
the same size.


I guess that we will have to code it this way -- if EITHER the GPE1_BLK or
GPE1_BLK_LEN is zero, there is no GPE1.  Likewise with the GPE0 block.


Bob



-Original Message-
From: Moore, Robert [mailto:[EMAIL PROTECTED]] 
Sent: Thursday, November 21, 2002 3:00 PM
To: '[EMAIL PROTECTED]'; John Baldwin
Cc: [EMAIL PROTECTED]; Mitsuru IWASAKI
Subject: [acpi-jp 1965] RE: Call for testers: acpica-unix-20021118.tar .gz



DSDT=0x3ffbf77
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0xb1, ACPI_ENABLE=0xf0, ACPI_DISABLE=0xf1, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x1000-0x1003
PM1a_CNT_BLK=0x1004-0x1005
PM2_CNT_BLK=0x1030-0x1030
PM2_TMR_BLK=0x1008-0x100b
PM2_GPE0_BLK=0x1018-0x101b
P_LVL2_LAT=200ms, P_LVL3_LAT=2000ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=3
DAY_ALRM=72, MON_ALRM=73, CENTURY=50
Flags={WBINVD,PROC_C1,SLP_BUTTON,TMR_VAL_EXT}

Juli, John,

This is interesting that no GPE1 information shows up.

It may be the case that GPE1_BLK is zero, but GPE1_BLK_LEN is not zero in
the FADT.

According to the ACPI spec, only (GPE1_BLK == 0) indicates that there is no
GPE1 block;  It may be that if GPE1_BLK_LEN is non-zero, but GPE1_BLK is
zero, the CA code is not handling this correctly.  I will investigate and
report back.

Bob

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

Your patches seem to fix three things:

1) Implicit returns
2) Invalid escape sequences (missing double backslashes)
3) Uninitialized Locals

Which one was causing the original problem as reported?

Thanks,
Bob


-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]] 
Sent: Wednesday, August 28, 2002 3:36 AM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Subject: [acpi-jp 1759] Re: Call for testers: acpica-unix-20020815

 1) Fix the ASL so that it compiles without errors or warnings
 2) Override the BIOS version of the table with your new one.  (I don't
know
 how this is done on FreeBSD, someone else will have to help you.

Attached patches will fix the ASL.
For compiling and overriding, please refer to acpi(4).
 # iasl Tecra8200.asl
 # cp acpi_dsdt.aml /boot/
 # echo 'acpi_dsdt_load=YES'  /boot/loader.conf

Thanks

--- Tecra8200.asl-  Wed Aug 28 19:30:30 2002
+++ Tecra8200.asl   Wed Aug 28 19:26:57 2002
@@ -79,11 +79,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x1)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQA)
+Return(STAL(\_SB_.PCI0.FNC0.IRQA))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQA)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQA))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQA, Local0)
@@ -108,11 +108,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x2)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQB)
+Return(STAL(\_SB_.PCI0.FNC0.IRQB))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQB)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQB))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQB, Local0)
@@ -137,11 +137,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x3)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQC)
+Return(STAL(\_SB_.PCI0.FNC0.IRQC))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQC)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQC))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQC, Local0)
@@ -166,11 +166,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x4)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQD)
+Return(STAL(\_SB_.PCI0.FNC0.IRQD))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQD)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQD))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQD, Local0)
@@ -195,11 +195,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x5)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQE)
+Return(STAL(\_SB_.PCI0.FNC0.IRQE))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQE)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQE))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQE, Local0)
@@ -224,11 +224,11 @@
 Name(_HID, 0x0f0cd041)
 Name(_UID, 0x8)
 Method(_STA) {
-STAL(\_SB_.PCI0.FNC0.IRQH)
+Return(STAL(\_SB_.PCI0.FNC0.IRQH))
 }
 Name(_PRS, Buffer(0x6) {0x23, 0xf8, 0x1c, 0x18, 0x79, 0x0 })
 Method(_CRS) {
-CRSL(\_SB_.PCI0.FNC0.IRQH)
+Return(CRSL(\_SB_.PCI0.FNC0.IRQH))
 }
 Method(_DIS) {
 Store(\_SB_.PCI0.FNC0.IRQH, Local0)
@@ -253,7 +253,7 @@
 Name(_HID, 0x010cd041)
 Name(_STA, 0xf)
 Method(_CRS) {
-CRS_(0x1)
+Return(CRS_(0x1))
 }
 OperationRegion(SRAM, SystemMemory, 0x000ee800, 0x1800)
 Field(SRAM, AnyAcc, NoLock, Preserve) {
@@ -944,13 +944,13 @@
 Name(_HID, 0x000ed041)
 Name(_UID, 0x2)
 Method(_STA) {
-STA_(0x25)
+Return(STA_(0x25))
 }
 Method(_CRS) {
-CRS_(0x25)
+Return(CRS_(0x25))
 }
 Method(_PRS) {
-PRS_(0x25)
+Return(PRS_(0x25))
 }
 Method(_SRS, 1) {
 SRS_(0x25, Arg0)
@@ -965,7 +965,7 @@
 PS3_(0x25)
 }
 Method(_PSC) {
-PSC_(0x25)
+Return(PSC_(0x25))
 }
 Name(_PRW, Package(0x2) {
 0xb,
@@ -982,7 +982,7 @@
 Device(VDSC) {

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

This looks like the (in)famous implicit return problem that is in some
Toshiba ASL files.

Method(_CRS) {
CRS_(0x10)
}

This does NOT actually return a value and the ASL code is incorrect.  It has
to be:

Method(_CRS) {
Return (CRS_(0x10))
}

The iASL compiler generates warnings for all instances of this erroneous
code.

Bob

-Original Message-
From: Mitsuru IWASAKI [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 3:19 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

Hi,

Could you put the following lines into /boot/loader.conf and send
dmesg output again?

debug.acpi.layer=ACPI_ALL_COMPONENTS
debug.acpi.level=ACPI_LV_ERROR


[sent privately to not spam the lists with my dump files]
 
 On Mon, 26 Aug 2002, Mitsuru IWASAKI wrote:
 
  FYI, I have now a can't fetch resources for \\_SB_.PCI0.FNC0.PRT_
-
  AE_BAD_DATA with acpica-unix-20020815 during boot.
  
  I'd like to make sure if AE_BAD_DATA error occurred w/ previous
  versions (acpica-unix-20020725, 20020611, 20020404...) ?
  Or first time w/ acpica-unix-20020815 ?
 
This error did not happened with previous versions of acpi

Hmmm...  OK, I put your full ASL at:
http://www.jp.freebsd.org/cgi/cvsweb.cgi/ACPI/data/Tecra8200.asl?rev=1.1con
tent-type=text/x-cvsweb-markupcvsroot=freebsd-jp

It seems that the problem occurs by evaluating CRS_ method.
Method(CRS_, 1) {
Store(Arg0, \_SB_.MEM_.PAR1)
Store(0x0, \_SB_.MEM_.PAR2)
Store(0x0, \_SB_.MEM_.PAR3)
Store(0x0, \_SB_.MEM_.PAR4)
Store(0x0, \_SB_.MEM_.PAR5)
Store(0x0, \_SB_.MEM_.PAR6)
Store(0x1, \_SB_.PCI0.FNC0.SYSR.TRP4)
If(LEqual(\_SB_.MEM_.PAR3, 0x0)) {
Return(Buffer(0x2) {0x79, 0x0 })
}
Name(BUFF, Buffer(\_SB_.MEM_.PAR3) { })
Store(\_SB_.MEM_.PRES, BUFF)
Return(BUFF)
}

Intel folks, any ideas?

Thanks

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

Well, the *real* problem is that there is no Return AML opcode in the
control method and the interpreter therefore does not return a value.

However, to answer your question with a question:  

Would you ask a C compiler, or any other compiler for that matter, to
actually *GUESS* at what you had intended to be the return value of a
function?

Bob


-Original Message-
From: Terry Lambert [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 2:05 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

Moore, Robert wrote:
 This looks like the (in)famous implicit return problem that is in some
 Toshiba ASL files.
 
 Method(_CRS) {
 CRS_(0x10)
 }
 
 This does NOT actually return a value and the ASL code is incorrect.  It
has
 to be:
 
 Method(_CRS) {
 Return (CRS_(0x10))
 }
 
 The iASL compiler generates warnings for all instances of this erroneous
 code.


Is there any way to add a -s for strict option to the iASL compiler,
in which it generates warnings for this code... but in the absence
of the option, simply pretends it saw the Return, since it knows
that that's the problem anyway, and is just being bitchy by warning
about it instead of warning, but also taking the appropriate corrective
action for this case?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

I think you are missing something:

1) BIOS vendor writes ASL
2) BIOS vendor compiles ASL to AML byte-code
3) BIOS vendor puts AML into BIOS
4) OS gets AML from the BIOS
5) OS interprets AML

The error you are experiencing is in (5).  There is no return statement in
the original ASL, so there is no return opcode in the AML.  The AML
interpreter has nothing to return and things fall apart.

However, the error was written in (1) and should have been caught by the ASL
compiler in (2).   However, there are other ASL compilers out there that do
not perform such error-checking.  This is how these kinds of problems creep
into the BIOS AML code.

Bob


-Original Message-
From: Terry Lambert [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 2:54 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

Moore, Robert wrote:
 Well, the *real* problem is that there is no Return AML opcode in the
 control method and the interpreter therefore does not return a value.
 
 However, to answer your question with a question:
 
 Would you ask a C compiler, or any other compiler for that matter, to
 actually *GUESS* at what you had intended to be the return value of a
 function?

Is this a trick question?

If I had to write my source code to read-only media, with no
way to tell whose compiler was going to be used on it, and had
no way to fix it afterwards, I think the answer would have to
be yes.  8-) 8-).


FWIW, there's historical precedent for this: the DEC VAX/VMS
C compiler would imply semicolons for the programmer that
forgot them, and a couple of other similar fixups, issue a
warning, but the resulting code would run as the programmer
most likely intended, rather than not generating a running
program at all.

The issue here is one of syntactical vs. grammatical ambiguity;
if the only choices are between two possible outcomes, and one
of them is a failure to operate at all, while the other is to
operate, but potentially incorrectly.  The upshot is that ir
can't hurt, and it might help:

assumption?
no  yes
-
grammar error   |   FAILS   |   FAILS   |
|
syntax error|   FAILS   |   WORKS   |
-

So the worst possible outcome in the failure case is that it
fails -- which it already does, without the assumption -- and
the best possible outcome is that it succeeds when it wouldn't
have.

Anything that works is better than anything that doesn't

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

We have to look at each of these on a case-by-case basis.

It turns out that it is purely an accident that the code works on windows;
by some fluke of their AML interpreter, the value gets returned.  Because of
architectural differences, the CA interpreter deletes everything that isn't
needed before the method returns -- and therefore any implied return
object is long gone by the time the method exits.

Toshiba knows about this problem and has agreed to fix it in it's various
BIOSs

Bob


-Original Message-
From: Terry Lambert [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 3:40 PM
To: Moore, Robert
Cc: 'Mitsuru IWASAKI'; [EMAIL PROTECTED]; [EMAIL PROTECTED];
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

Moore, Robert wrote:
 I think you are missing something:
 
 1) BIOS vendor writes ASL
 2) BIOS vendor compiles ASL to AML byte-code
 3) BIOS vendor puts AML into BIOS
 4) OS gets AML from the BIOS
 5) OS interprets AML
 
 The error you are experiencing is in (5).  There is no return statement in
 the original ASL, so there is no return opcode in the AML.  The AML
 interpreter has nothing to return and things fall apart.
 
 However, the error was written in (1) and should have been caught by the
ASL
 compiler in (2).   However, there are other ASL compilers out there that
do
 not perform such error-checking.  This is how these kinds of problems
creep
 into the BIOS AML code.

As a consumer of 1-3, I have zero opportunity to fix the
problem before item #4.

Since use of a trademark or other legal baseball bat (8-))
won't get the code in the BIOS fixed, the only way to make
things work in the short term is to either intervene in step
#4 or in step #5.

In the long term, it'd probably be a good idea to release
the source code for the ASL-to-AML compiler under a strict
license, and displace all the ASL compilers that fail to do
error checking, so problems like this can't arise in the
first place.

I guess I would like to know if the AML can be recognized as
defective by the interpreter, and modify it at step #4 before
interning it for interpretation; Windows has to have *some* way
of dealing with this, short of supplying replacement AML for
every PC ever manufacturered, right?

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message

RE: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815

[Moore, Robert]

1) Fix the ASL so that it compiles without errors or warnings
2) Override the BIOS version of the table with your new one.  (I don't know
how this is done on FreeBSD, someone else will have to help you.

Bob


-Original Message-
From: Yann Berthier [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 3:19 PM
To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: [acpi-jp 1750] Re: Call for testers: acpica-unix-20020815

On Tue, 27 Aug 2002, Moore, Robert wrote:

 
 This looks like the (in)famous implicit return problem that is in some
 Toshiba ASL files.
 
 Method(_CRS) {
 CRS_(0x10)
 }
 
 This does NOT actually return a value and the ASL code is incorrect.  It
has
 to be:
 
 Method(_CRS) {
 Return (CRS_(0x10))
 }
 
 The iASL compiler generates warnings for all instances of this erroneous
 code.

   Thanks a lot for your input. What is the best way for me to verify
   this ?

   - yann

To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message