Re: [10-STABLE, 11-CURRENT] something wrong between cam and eventtimer or geom and eventtimer

From: Oliver Pinter <oliver.pntr_at_gmail.com>
Date: Tue, 5 Nov 2013 20:27:49 +0100
dmesg corrected

On 11/5/13, Oliver Pinter <oliver.pntr_at_gmail.com> wrote:
> On 11/5/13, Adrian Chadd <adrian_at_freebsd.org> wrote:
>> Ok, so it's only hitting C1. It's not going into C2.
>>
>> Is this a dual core CPU with hyperthreading enabled, or a quad core CPU?
>
> quad core, i5-4670
>
>>
>> How about changing the idle loop from acpi to hlt, see if that fixes
>> things? (Without tweaking the event timer logic.)
>
> Now, after reboot, the problem has gone. The other symptom are: on vt
> switching is laggish, and switching the num lock state delayed
> ~0.5sec.
>
> This are reproducible ~ every 10-15th boot.
>
>>
>> I'm worried that what you're seeing here are missed interrupts or
>> interrupts that aren't immediately causing the driver thread to be
>> scheduled (and thus things enter HLT until the next interrupt.) I had
>> to deal with this crap on MIPS for quite some time.
>>
>> sysctl machdep.idle=hlt
>>
>>
>>
>> -adrian
>>
>>
>> On 5 November 2013 09:25, Oliver Pinter <oliver.pntr_at_gmail.com> wrote:
>>> op_at_perpetua ~> sysctl dev.cpu
>>> dev.cpu.0.%desc: ACPI CPU
>>> dev.cpu.0.%driver: cpu
>>> dev.cpu.0.%location: handle=\_PR_.CPU0
>>> dev.cpu.0.%pnpinfo: _HID=none _UID=0
>>> dev.cpu.0.%parent: acpi0
>>> dev.cpu.0.coretemp.delta: 59
>>> dev.cpu.0.coretemp.resolution: 1
>>> dev.cpu.0.coretemp.tjmax: 100.0C
>>> dev.cpu.0.coretemp.throttle_log: 0
>>> dev.cpu.0.temperature: 41.0C
>>> dev.cpu.0.freq_levels: 3401/84000 3400/84000 3200/77169 3000/70587
>>> 2800/64262 2700/61182 2500/55201 2300/49464 2100/43946 1900/38654
>>> 1700/34277 1500/29407 1400/27053 1225/23671 1200/22509 1050/19695
>>> 1000/18167 875/15896 800/14031 700/12277 600/10523 500/8769 400/7015
>>> 300/5261 200/3507 100/1753
>>> dev.cpu.0.cx_supported: C1/1/1 C2/2/67
>>> dev.cpu.0.cx_lowest: C1
>>> dev.cpu.0.cx_usage: 100.00% 0.00% last 812us
>>> dev.cpu.1.%desc: ACPI CPU
>>> dev.cpu.1.%driver: cpu
>>> dev.cpu.1.%location: handle=\_PR_.CPU1
>>> dev.cpu.1.%pnpinfo: _HID=none _UID=0
>>> dev.cpu.1.%parent: acpi0
>>> dev.cpu.1.coretemp.delta: 56
>>> dev.cpu.1.coretemp.resolution: 1
>>> dev.cpu.1.coretemp.tjmax: 100.0C
>>> dev.cpu.1.coretemp.throttle_log: 0
>>> dev.cpu.1.temperature: 44.0C
>>> dev.cpu.1.cx_supported: C1/1/1 C2/2/67
>>> dev.cpu.1.cx_lowest: C1
>>> dev.cpu.1.cx_usage: 100.00% 0.00% last 1348us
>>> dev.cpu.2.%desc: ACPI CPU
>>> dev.cpu.2.%driver: cpu
>>> dev.cpu.2.%location: handle=\_PR_.CPU2
>>> dev.cpu.2.%pnpinfo: _HID=none _UID=0
>>> dev.cpu.2.%parent: acpi0
>>> dev.cpu.2.coretemp.delta: 61
>>> dev.cpu.2.coretemp.resolution: 1
>>> dev.cpu.2.coretemp.tjmax: 100.0C
>>> dev.cpu.2.coretemp.throttle_log: 0
>>> dev.cpu.2.temperature: 39.0C
>>> dev.cpu.2.cx_supported: C1/1/1 C2/2/67
>>> dev.cpu.2.cx_lowest: C1
>>> dev.cpu.2.cx_usage: 100.00% 0.00% last 845us
>>> dev.cpu.3.%desc: ACPI CPU
>>> dev.cpu.3.%driver: cpu
>>> dev.cpu.3.%location: handle=\_PR_.CPU3
>>> dev.cpu.3.%pnpinfo: _HID=none _UID=0
>>> dev.cpu.3.%parent: acpi0
>>> dev.cpu.3.coretemp.delta: 62
>>> dev.cpu.3.coretemp.resolution: 1
>>> dev.cpu.3.coretemp.tjmax: 100.0C
>>> dev.cpu.3.coretemp.throttle_log: 0
>>> dev.cpu.3.temperature: 38.0C
>>> dev.cpu.3.cx_supported: C1/1/1 C2/2/67
>>> dev.cpu.3.cx_lowest: C1
>>> dev.cpu.3.cx_usage: 100.00% 0.00% last 1609us
>>>
>>> On 11/5/13, Adrian Chadd <adrian_at_freebsd.org> wrote:
>>>> Hi!
>>>>
>>>> Can you do 'sysctl dev.cpu' please? I'd like to see what sleep
>>>> state(s) your CPU is entering.
>>>>
>>>> Thanks!
>>>>
>>>>
>>>> -adrian
>>>>
>>>>
>>>> On 5 November 2013 06:07, Oliver Pinter <oliver.pntr_at_gmail.com> wrote:
>>>>> Hi all!
>>>>>
>>>>> The machine is a Haswell machine, the disc performance was very poor
>>>>> (20-30MByte/sec).
>>>>> When I change the kern.eventtimer.idletick from 0 to 1, the normal
>>>>> performance restored back to normal (70-90MByte/sec).
>>>>>
>>>>> The default eventtimer was LAPIC.
>>>>>
>>>>> On other machine Q9300, this was fully reproducible.
>>>>> _______________________________________________
>>>>> freebsd-current_at_freebsd.org mailing list
>>>>> http://lists.freebsd.org/mailman/listinfo/freebsd-current
>>>>> To unsubscribe, send any mail to
>>>>> "freebsd-current-unsubscribe_at_freebsd.org"
>>>>
>>
>

Received on Tue Nov 05 2013 - 18:27:52 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:44 UTC