Re: PATCH: new acpi embedded controller I/O model

From: Nate Lawson <nate_at_root.org>
Date: Tue, 27 Feb 2007 14:22:47 -0800
Ariff Abdullah wrote:
> On Mon, 26 Feb 2007 18:20:02 -0800
> Nate Lawson <nate_at_root.org> wrote:
>> If you notice slower performance or get EC "timed out" messages on
>> console, you try increasing these sysctls/tunables:
>>
>> debug.acpi.ec.timeout
>> debug.acpi.ec.poll_time

Before you go changing the logic, please...

Try adjusting these parameters, including other values besides these:
debug.acpi.ec.timeout=1000  # 1 sec total
debug.acpi.ec.poll_time=100 # 100 usec polling (or try larger like 800)

>> Or turn off this sysctl/tunable, disabling the new burst mode:
>> debug.acpi.ec.burst=0

Try the above values both with and without burst mode.

>> To find any performance problems, you'll need to rebuild the kernel
>> and modules with this added to your kernel config:
>>
>> options KTR
>> options KTR_ENTRIES=65536
>>
>> Then reboot, load this kernel/acpi.ko, use the system for a while to
>> trigger the problem behavior and generate output:
>> ktrdump -t | gzip -c > ktr.out.gz

Would you please submit the output requested above, along with sysctl
debug.acpi.ec so I can know what parameters you were using?


> --- sys/dev/acpica/acpi_ec.c	Tue Feb 27 19:21:12 2007
> +++ sys/dev/acpica/acpi_ec.c	Tue Feb 27 19:22:17 2007
> _at__at_ -936,6 +936,7 _at__at_
>      count = ec_poll_time / EC_POLL_DELAY;
>      if (count <= 0)
>  	count = 1;
> +    slp_ival = max(hz / 1000, 1);
>      for (i = 0; i < count; i++) {
>  	EcStatus = EC_GET_CSR(sc);
>  	if (sc->ec_burstactive && (EcStatus & EC_FLAG_BURST_MODE) == 0) {
> _at__at_ -947,7 +948,15 _at__at_
>  	    Status = AE_OK;
>  	    break;
>  	}
> -	AcpiOsStall(EC_POLL_DELAY);
> +	if (sc->ec_burstactive)
> +	    AcpiOsStall(EC_POLL_DELAY);
> +	else {
> +	    if (!cold)
> +	       	msleep(&sc->ec_csrvalue, &sc->ec_mtx, PZERO, "ecpoll",
> +	    	    slp_ival);
> +	    else
> +		AcpiOsStall(1000);
> +	}
>      }
>  
>      /*

Your patch just goes straight into msleep() instead of doing any
DELAY().  Does enabling the "#if 0" code right before your patch help?

Please revert your patch and try the above.  We need to reduce the
amount of variation to track it down.

-- 
Nate
Received on Tue Feb 27 2007 - 22:09:23 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:06 UTC