Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 27 Feb 2007 14:22:47 -0800
From:      Nate Lawson <nate@root.org>
To:        Ariff Abdullah <ariff@FreeBSD.org>
Cc:        stable@freebsd.org, current@FreeBSD.org
Subject:   Re: PATCH: new acpi embedded controller I/O model
Message-ID:  <45E4AF37.9000207@root.org>
In-Reply-To: <20070227193508.49076f8b.ariff@FreeBSD.org>
References:  <45E39552.2020607@root.org> <20070227193508.49076f8b.ariff@FreeBSD.org>

next in thread | previous in thread | raw e-mail | index | archive | help
Ariff Abdullah wrote:
> On Mon, 26 Feb 2007 18:20:02 -0800
> Nate Lawson <nate@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
> @@ -936,6 +936,7 @@
>      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) {
> @@ -947,7 +948,15 @@
>  	    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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?45E4AF37.9000207>