Re: Using bintime() in acpi_cpu_idle()?
On 30.07.2012 07:33, Bruce Evans wrote: On Sun, 29 Jul 2012, Alexander Motin wrote: On 29.07.2012 15:26, Bruce Evans wrote: On Sun, 29 Jul 2012, Alexander Motin wrote: On 29.07.2012 11:37, Bruce Evans wrote: ... binuptime() is more accurate than uncalibrated scaling. Is accuracy required? Accuracy is not required at all. +-20% is not a problem. If not, the CPU ticker might work, and is faster than HPET, and and is not under user control for perverse settings. It normally reduces to readtsc() with no serializing instruction even in proposed changes. This is good enough for process times (not very good) and depends on the CPU not changing. Its calibration is very accurate (similar to timecounters) modulo bugs, but not always up to date. Problem with ticker that it may stop during idle periods, and idle is exactly what happens here. Unlike timecounter usage here we don't need CPU synchronicity, but we need it working during deep sleeps. The ticker is the same as the timecounter in many cases of interest. If the TSC stops then it cannot be used for timecounting unless timecounting is reinitialized. Timecounting should be reinitialized after deep sleeps, but you say you need it to work during deep sleeps. Timecounter already has detection logic to disable TSC in cases where it is unreliable. I don't want to replicate it here. I need not precise and not synchronized by reliable and fast time source. Yes, this logic gives exactly what you don't want (an inefficient timecounter), by preventing use of the TSC for the timecounter, although the TSC is perfectly usable for the ticker and here. Can you teach me how to use ticker that is not ticking? If TSC was considered unusable for timecounter for reasons unrelated to SMP, how can I use it as ticker. I wouldn't trust timecounters for some time after waking up after a deep sleep. If their clock stopped then the times read might only be very out of date. If their clock didn't stop, then they might have wrapped or otherwise overflowed and the times read would be garbage. Is there any locking or ordering to prevent them being used before they are reinitialized? I am not sure what reinitialization are you talking about. IIRC, there is no any waking up code for TSC. None other time counters have problems with C-states. It is the timecounter code that needs reinitializing. If the TSC stops, or wraps mod 2**32, then its counts become garbage for the purpose of timecounting. Maybe it is not used for timecounting in either of these cases. But these cases shouldn't prevent its use for timecounting. The 2**32 number is because timecounters only use 32 bits of hardware counters (for efficiency). So even if the hardware has some magic to not stop the TSC while sleeping (maybe it fakes not stopping it be reloading on wakeup), it is still unusable by timecounters after sleeping for a second or 2 so that it wraps. The software needs similar faking to reload the timecounter on wakeup. This makes use of timecounters in sleep/wakeup code fragile. At this moment I am not talking about S-states sleeping for hours. I am talking about C-states for milliseconds. It means that TSC may stop and start 10K times each second or even more. Attempt to save and restore its state will consume so much resources, that probably make it useless. What's about wrap after 2 seconds, I would be happy to make CPU sleep for so long, but now 100ms is all I can hope even on idle system. At boot time there is a dummy timecounter that returns bogo-times. Apparently sleeping doesn't occur before the timecounter is switched to a real one. The dummy timecounter isn't switched back to after boot time. But it probably should be, since the hardware timecounter may have stopped or wrapped. Sleeping could just set a flag to indicate this state, but then you would have to provide a fake time anyway on finding the flag set. Boot time just points to the dummy timecounter so as not to check this flag in all early timecounter hardware calls. And how dummy timecounter that counts something, but not time, can help me to measure sleep time? -- Alexander Motin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Using bintime() in acpi_cpu_idle()?
On Mon, 30 Jul 2012, Alexander Motin wrote: [...] ... Nevermind, let it be compromise solution -- ticker for C1 state where performance is the most important and where TSC works and ACPI timer for others. I like that. Something similar should work for making the TSC usable in timecounters even if it stops during deep sleeps. The timecounter hardware would have to be switched or reinitalized if it might have stopped. Bruce ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Current problem reports assigned to freebsd-acpi@FreeBSD.org
Note: to view an individual PR, use: http://www.freebsd.org/cgi/query-pr.cgi?pr=(number). The following is a listing of current problems submitted by FreeBSD users. These represent problem reports covering all versions including experimental development code and obsolete releases. S Tracker Resp. Description o kern/164329 acpi [acpi] hw.acpi.thermal.tz0.temperature shows strange v o kern/163268 acpi [acpi_hp] fix driver detach in absence of CMI o kern/162859 acpi [acpi] ACPI battery/acline monitoring partialy working o kern/161715 acpi [acpi] Dell E6520 doesn't resume after ACPI suspend o kern/161713 acpi [acpi] Suspend on Dell E6520 o kern/160838 acpi [acpi] ACPI Battery Monitor Non-Functional o kern/160419 acpi [acpi_thermal] acpi_thermal kernel thread high CPU usa o kern/158689 acpi [acpi] value of sysctl hw.acpi.thermal.polling_rate ne o kern/154955 acpi [acpi] Keyboard or ACPI doesn't work on Lenovo S10-3 o kern/152438 acpi [acpi]: patch to acpi_asus(4) to add extra sysctls for o kern/152098 acpi [acpi] Lenovo T61p does not resume o i386/146715 acpi [acpi] Suspend works, resume not on a HP Probook 4510s o kern/145306 acpi [acpi]: Can't change brightness on HP ProBook 4510s o i386/143798 acpi [acpi] shutdown problem with SiS K7S5A o kern/143420 acpi [acpi] ACPI issues with Toshiba o kern/142009 acpi [acpi] [panic] Panic in AcpiNsGetAttachedObject o kern/139088 acpi [acpi] ACPI Exception: AE_AML_INFINITE_LOOP error o amd64/138210 acpi [acpi] acer aspire 5536 ACPI problems (S3, brightness, o kern/137042 acpi [acpi] hp laptop's lcd not wakes up after suspend to r o i386/136008 acpi [acpi] Dell Vostro 1310 will not shutdown (Requires us o bin/135349 acpi [patch] teach acpidump(8) to disassemble arbitrary mem o kern/132602 acpi [acpi] ACPI Problem with Intel SS4200: System does not p kern/128634 acpi [patch] fix acpi_asus(4) in asus a6f laptop o bin/126162 acpi [acpi] ACPI autoload failed : loading required module o kern/123039 acpi [acpi] ACPI AML_BUFFER_LIMIT errors during boot a i386/122887 acpi [panic] [atkbdc] 7.0-RELEASE on IBM HS20 panics immed s kern/112544 acpi [acpi] [patch] Add High Precision Event Timer Driver f o kern/105537 acpi [acpi] problems in acpi on HP Compaq nc6320 o kern/91594 acpi [acpi] FreeBSD 5.4 w/ACPI fails to detect Intel Pro/ o kern/73823 acpi [request] acpi / power-on by timer support o kern/56024 acpi ACPI suspend drains battery while in S3 31 problems total. ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
Re: Time to increase MAX_TASKS?
On Thursday, July 19, 2012 4:49:23 pm Sean Bruno wrote: The new Dell machines are doing a lot more of outstanding ACPI things currently. So much in fact, that they are exceeding ACPI_MAX_TASKS and are throwing errors indicating thing: snip vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable est0: Enhanced SpeedStep Frequency Control on cpu0 .imecounters tick every 1.000 msec smbios: System Management BIOS version 2.7 Profiling kernel, textsize=6861200 [8029b190..80926320] usbus0: 480Mbps High Speed USB v2.0 usbus1: 480Mbps High Speed USB v2.0 ugen0.1: Intel at usbus0 uhub0: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus0 ugen1.1: Intel at usbus1 uhub1: Intel EHCI root HUB, class 9/0, rev 2.00/1.00, addr 1 on usbus1 ipmi0: IPMI device rev. 1, firmware rev. 1.10, version 2.0 ipmi0: Number of channels 6 ipmi0: Attached watchdog AcpiOsExecute: failed to enqueue task, consider increasing the debug.acpi.max_tasks tunable mfid0 on mfi0 /snip the current value in sys/dev/acpica/acpivar.h of 32 is no longer sufficient on the r420/r320 Sandybridge class of box. I am currently running with a value of 128 and doing a bit of testing. I think it should be something like MAX(32, MAXCPU). -- John Baldwin ___ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to freebsd-acpi-unsubscr...@freebsd.org
