From owner-acpi-jp@jp.freebsd.org  Fri Jan  5 05:11:21 2001
Received: (from daemon@localhost)
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) id FAA85587;
	Fri, 5 Jan 2001 05:11:21 +0900 (JST)
	(envelope-from owner-acpi-jp@jp.FreeBSD.org)
Received: from opium.mbsi.ca (opium.mbsi.ca [198.168.101.1])
	by castle.jp.freebsd.org (8.9.3+3.2W/8.7.3) with ESMTP id FAA85576
	for <acpi-jp@jp.freebsd.org>; Fri, 5 Jan 2001 05:11:19 +0900 (JST)
	(envelope-from marc@mbsi.ca)
Received: from opium.mbsi.ca (marc@localhost [127.0.0.1])
	by opium.mbsi.ca (8.11.1/8.11.1) with ESMTP id f04K9fF05777;
	Thu, 4 Jan 2001 15:09:41 -0500 (EST)
Message-Id: <200101042009.f04K9fF05777@opium.mbsi.ca>
X-Mailer: exmh version 2.2 07/04/2000 with nmh-1.0.4+dev
To: Peter Wemm <peter@netplex.com.au>
cc: "Adam J. Richter" <adam@yggdrasil.com>,
        takawata@shidahara1.planet.sci.kobe-u.ac.jp, msmith@freebsd.org,
        acpi-jp@jp.freebsd.org, fudge_factor@hotmail.com,
        acme@conectiva.com.br, acpi@phobos.fachschaften.tu-muenchen.de,
        y-ogawa@dvpj.sony.co.jp
In-Reply-To: Your message of "Tue, 02 Jan 2001 17:28:09 PST."
             <200101030128.f031S9813385@mobile.wemm.org> 
References: <200101030128.f031S9813385@mobile.wemm.org> 
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Thu, 04 Jan 2001 15:09:41 -0500
From: Marc Boucher <marc@mbsi.ca>
Reply-To: acpi-jp@jp.freebsd.org
Precedence: list
X-Distribute: distribute version 2.1 (Alpha) patchlevel 24e+000315
X-Sequence: acpi-jp 1020
Subject: [acpi-jp 1020] Re: [Acpi] Patch(?): Peter Wemm's Sony Vaio ACPI fix simplified and adapted to linux-2.4.0-prerelease 
Errors-To: owner-acpi-jp@jp.freebsd.org
Sender: owner-acpi-jp@jp.freebsd.org
X-Originator: marc@mbsi.ca


Peter Wemm wrote:
>
> Marc Boucher wrote:
> > Hi Adam, folks,
> > 
> > Unfortunately this patch didn't fix the hang at initialization
> > (in EC0_BAT1's _STA method) on my Vaio PCG-Z505LS.
> 
> Which version of the patch?  Both?

ok, with Adam's new version under linux-2.4.0-prerelease-ac5 it is no
longer hanging, but entering or exiting sleep mode seems quite
unreliable..

> For what it is worth, I get hangs if I have 'CPU Speed: Auto' in the bios.
> If I set it to 'CPU Speed: Full' I get reliable boots.  The bios text suggests
> that this switch is non-functional with ACPI enabled, but it certainly
> seems to make an impact here.
> I usually get hangs in ECO_BAT1's _STA if I boot on 'Auto' speed, but not
> always.  If I power the thing up from cold I usually get a few more SMI calls
> further.  If I start really hot, it sometimes hangs sooner.

Trying OS Control: Yes, CPU Speed: Auto with the new patch I haven't yet
gotten any hangs yet, however my USB Keyboard (Logitech iTouch) no
longer works (it is detected on the USB Bus, and its leds briefly flash
when initialized by the hid driver but pressing keys has no effect). The
USB Mouse (Sony UMS1) still works fine though, even though it's
connected to the keyboard's USB hub.

With CPU Speed: Full the USB keyboard works properly..

BTW my bios version is R0203Z3 / RK203Z3 (Phoenix BIOS 4.0 Release 
6.0, Date: 08/25/00)

Cheers,
Marc

> > 
> > Regards,
> > Marc
> > 
> > On Tue, Jan 02, 2001 at 02:13:41AM -0800, Adam J. Richter wrote:
> > > 
> > > 	Many thanks to Peter Wemm for fixing the ACPI hangs that
> > > occurred on some Sony Vaio computers and to Takanori Watanabe for
> > > his help and forwarding Peter's patch to me.
> > > 
> > > 	I have simplified Peter Wemm's patch so that it does
> > > not need a new variable, a switch statement or a new goto target,
> > > and I have made the change to linux-2.4.0-prerelease and verified
> > > that it makes acpi work again on my Sony PictureBook PCG-1VN
> > > (the Transmeta version), at least to the extent that it does not
> > > hang at initialization and it shuts down the power when requested.
> > > 
> > > 	I think that Peter's debugging print message changes are
> > > not related to the Linux version, so the *BSD crowd should probably
> > > still apply those separately.  As for the changes that are reflected
> > > in this Linux patch, I recommend that *BSD people consider applying
> > > an adaptation of these changes to the *BSD sources, as they are
> > > substantially simpler.
> > > 
> > > -- 
> > > Adam J. Richter     __     ______________   4880 Stevens Creek Blvd, Suite 
>     104
> > > adam@yggdrasil.com     \ /                  San Jose, California 95129-1034
> > > +1 408 261-6630         | g g d r a s i l   United States of America
> > > fax +1 408 261-6631      "Free Software For The Rest Of Us."
> > 
> > > --- linux-2.4.0-prerelease/drivers/acpi/interpreter/amfldio.c	Fri Dec
>      29 14:07:21 2000
> > > +++ linux/drivers/acpi/interpreter/amfldio.c	Tue Jan  2 02:00:04 200
>     1
> > > @@ -391,9 +391,6 @@
> > >  
> > >  	merged_value = field_value;
> > >  
> > > -	/* Check if update rule needs to be applied (not if mask is all ones) *
>     /
> > > -
> > > -
> > >  	/* Decode the update rule */
> > >  
> > >  	switch (obj_desc->field.update_rule)
> > > @@ -402,12 +399,19 @@
> > >  	case UPDATE_PRESERVE:
> > >  
> > >  		/*
> > > -		 * Read the current contents of the byte/word/dword containing
> > > -		 * the field, and merge with the new field value.
> > > +	  	 * Check if update rule needs to be applied (not if mask
> > > +		 * is all ones).  If so, read the current contents of
> > > +		 * the byte/word/dword containing the field, and merge
> > > +		 * with the new field value.
> > >  		 */
> > > -		status = acpi_aml_read_field_data (obj_desc, this_field_byte_of
>     fset,
> > > +
> > > +
> > > +		if (((1UL << bit_granularity)-1) & ~mask) {
> > > +			status = acpi_aml_read_field_data (obj_desc,
> > > +				   this_field_byte_offset,
> > >  				   bit_granularity, &current_value);
> > > -		merged_value |= (current_value & ~mask);
> > > +			merged_value |= (current_value & ~mask);
> > > +		}
> > >  		break;
> > >  
> > >  
> > 
> > 
> 
> 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
> 


