PATCH: new acpi embedded controller I/O model
Nate Lawson
nate at root.org
Tue Feb 27 23:09:23 UTC 2007
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
> @@ -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
More information about the freebsd-stable
mailing list