From owner-acpi-jp@jp.freebsd.org  Tue Jan  2 14:29:36 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id OAA83104;
	Tue, 2 Jan 2001 14:29:36 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (shidahara1.planet.sci.kobe-u.ac.jp [133.30.50.200])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id OAA83099
	for <acpi-jp@jp.freebsd.org>; Tue, 2 Jan 2001 14:29:36 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Received: from shidahara1.planet.sci.kobe-u.ac.jp (localhost [127.0.0.1])
	by shidahara1.planet.sci.kobe-u.ac.jp (8.9.3/8.9.3) with ESMTP id OAA30660
	for <acpi-jp@jp.freebsd.org>; Tue, 2 Jan 2001 14:30:15 +0900 (JST)
	(envelope-from takawata@shidahara1.planet.sci.kobe-u.ac.jp)
Message-Id: <200101020530.OAA30660@shidahara1.planet.sci.kobe-u.ac.jp>
To: acpi-jp@jp.freebsd.org
In-reply-to: Your message of "Mon, 01 Jan 2001 20:22:55 PST."
             <200101020423.f024Mt806471@mobile.wemm.org>
Date: Tue, 02 Jan 2001 14:30:15 +0900
From: Takanori Watanabe <takawata@shidahara1.planet.sci.kobe-u.ac.jp>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1014
Subject: [acpi-jp 1014] Re: [PATCH] How to get acpica to work on a Sony VAIO PCG-F690..
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: takawata@shidahara1.planet.sci.kobe-u.ac.jp

In message <200101020423.f024Mt806471@mobile.wemm.org>, Peter Wemm $B$5$s$$$o$/(B:
>Mike Smith suggested that I send this patch here for comment.  There is a
>bug in the acpica code in the write-with-rule code.  When executing
>the SMI call AML code, it was executing this incorrectly:
>Method(PHS0, 1) {
>	Store(Arg0, BCMD)
>	Store(Zero, SMIC)
>	While(LEqual(BCMD, Arg0)) {
>	}
>	Store(0x0, BCMD)
>}
>
>The "Store(Zero, SMIC)" was actually being executed as:
>Tempval = Read SMIC (8 bit quantity)
>Tempval = (Tempval & 0xffffff00) | (Zero & 0x000000ff)
>Store(Tempval, SMIC) (8 bit quantity)
>
>It seems that *any* access to SMIC (0x8040 on my vaio) causes an SMI event
>and the second call was breaking the while() loop causing it to spin forever
>and lock up.
>
>I added code to detect when the value written did not need need to preserve
>old contents.  With my attached patch, it correctly writes an 8-bit zero
>to the SMIC register once, instead of doing an 8-bit read followed by
>an 8-bit write.
>
>The diff also has code to fix some 32 bit vs 64 bit printfs for debugging
>this section of code.
>
>There is one outstanding problem.  If I use the BIOS setup and put the
>CPU speed in 'Auto' mode, the system hangs at some random SMI call in the
>same while() loop.  If I set the CPU speed to 'Full', it reliably boots.
>I do not know why, I have done some detailed debug traces and can see no real
>difference between the two cases.  The AML does not change either.  I am
>continuing to investigate this.
>
>Index: Interpreter/amfldio.c
>===================================================================
>RCS file: /home/ncvs/src/sys/contrib/dev/acpica/Subsystem/Interpreter/amfldio.
>c,v
>retrieving revision 1.1.1.4
>diff -u -r1.1.1.4 amfldio.c
>--- Interpreter/amfldio.c	2000/12/21 06:56:40	1.1.1.4
>+++ Interpreter/amfldio.c	2000/12/30 03:41:38
>@@ -541,6 +541,7 @@
>     ACPI_STATUS             Status = AE_OK;
>     UINT32                  MergedValue;
>     UINT32                  CurrentValue;
>+    UINT32                  BitMask;
> 
> 
>     /* Start with the new bits  */
>@@ -549,6 +550,30 @@
> 
>     /* Check if update rule needs to be applied (not if mask is all ones) */
> 
>+    switch (BitGranularity) {
>+    case 32:
>+	BitMask = 0xffffffff;
>+	break;
>+    case 16:
>+	BitMask = 0xffff;
>+	break;
>+    case 8:
>+	BitMask = 0xff;
>+	break;
>+    case 0:
>+	panic("BitGranularity = 0!");
>+	BitMask = 0;
>+	break;
>+    default:
>+	BitMask = (1UL << BitGranularity) - 1;
>+	break;
>+    }
>+    /*
>+     * If we are given the same or more bits than required, then write
>+     * the bits that we are given as-is
>+     */
>+    if ((Mask & BitMask) == BitMask)
>+	goto aligned;
> 
>     /* Decode the update rule */
> 
>@@ -590,6 +615,7 @@
>         Status = AE_AML_OPERAND_VALUE;
>     }
> 
>+aligned:
> 
>     /* Write the merged value */
> 
>Index: Interpreter/amregion.c
>===================================================================
>RCS file: /home/ncvs/src/sys/contrib/dev/acpica/Subsystem/Interpreter/amregion
>.c,v
>retrieving revision 1.1.1.4
>diff -u -r1.1.1.4 amregion.c
>--- Interpreter/amregion.c	2000/12/21 06:56:41	1.1.1.4
>+++ Interpreter/amregion.c	2000/12/29 19:42:17
>@@ -250,7 +250,7 @@
>     case ADDRESS_SPACE_READ:
> 
>         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
>-            ("Read (%d width) Address=%p\n", BitWidth, Address));
>+            ("Read (%d width) Address=%p\n", BitWidth, (u_int32_t)Address));
> 
>         switch (BitWidth)
>         {
>@@ -274,7 +274,7 @@
> 
>         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
>             ("Write (%d width) Address=%p Value %X\n",
>-            BitWidth, Address, *Value));
>+            BitWidth, (u_int32_t)Address, *Value));
> 
>         switch (BitWidth)
>         {
>@@ -344,8 +344,8 @@
>     case ADDRESS_SPACE_READ:
> 
>         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
>-            ("Read(%d width) Address=%p\n", BitWidth, Address));
>+            ("Read(%d width) Address=%p\n", BitWidth, (u_int32_t)Address));
> 
>         switch (BitWidth)
>         {
>         /* I/O Port width */
>@@ -376,7 +397,7 @@
> 
>         DEBUG_PRINT ((TRACE_OPREGION | VERBOSE_INFO),
>             ("Write(%d width) Address=%p Value %X\n",
>-            BitWidth, Address, *Value));
>+            BitWidth, (u_int32_t)Address, *Value));
> 
>         switch (BitWidth)
>         {
>
>A sample from dmesg(8):
>...
>FreeBSD 5.0-CURRENT #43: Sun Dec 31 20:11:07 PST 2000
>    peter@mobile.wemm.org:/home/src/sys/compile/MOBILE
>Timecounter "i8254"  frequency 1193148 Hz
>Timecounter "TSC"  frequency 843700763 Hz
>CPU: Pentium III/Pentium III Xeon/Celeron (843.70-MHz 686-class CPU)
>  Origin = "GenuineIntel"  Id = 0x686  Stepping = 6
>  Features=0x383f9ff<FPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,
>PAT,PSE36,MMX,FXSR,SSE>
>real memory  = 134152192 (131008K bytes)
>avail memory = 125992960 (123040K bytes)
>...
>acpi0: <SONY   K2      > on motherboard
>acpi_tz0: <thermal zone> on acpi0
>acpi_tz0: current temperature 65.9C
>acpi_button0: <Control Method Power Button Device> on acpi0
>acpi_pcib0: <Host-PCI bridge> on acpi0
>pci0: <PCI bus> on acpi_pcib0
>...
>intpm0: PM I/O mapped 8000 
>...
>pccbb0: <RF5C478 PCI-CardBus Bridge> at device 12.0 on pci0
>pccbb0: PCI Memory allocated: 18020000
>pci_cfgintr_unique: hard-routed to irq 9
>pci_cfgintr: 0:12 INTA routed to irq 9
>cardbus0: <Cardbus bus (newcard)> on pccbb0
>...
>acpi_ec0: <embedded controller> on acpi0
>acpi_cmbat0: <Control method Battery> on acpi0
>acpi_cmbat1: <Control method Battery> on acpi0
>acpi_acad0: <AC adapter> on acpi0
>acpi_acad0: On Line
>acpi_pr0: <processor device> on acpi0
>acpi_pr0: supported power states: C0 (0us) C1 (0us) C2 (10us)
>acpi_pr0: supported throttling states: 100% 87% 75% 62% 50% 37% 25% 12%
>acpi_timer0: <24-bit timer at 3.579545MHz> on acpi0
>...
>dc0: <Abocom FE2500 10/100BaseTX> port 0x3000-0x30ff mem 0x18040000-0x1805ffff
>,0x18022000-0x180223ff irq 9 at device 0.0 on cardbus0
>dc0: Ethernet address: 00:e0:98:8e:e5:d0
>miibus0: <MII bus> on dc0
>ukphy0: <Generic IEEE 802.3u media interface> on miibus0
>ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
>...
>
>All of the expected functionality works.. Power buttons cause a shutdown
>etc.
>
>How do we let Intel know about their bug?  There is an empty comment that
>talks about doing this change but it had obviously not been implemented.
>
>Cheers,
>-Peter
>--
>Peter Wemm - peter@FreeBSD.org; peter@yahoo-inc.com; peter@netplex.com.au
>"All of this is for nothing if we don't go to the stars" - JMS/B5
>
>
