Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1282330 > unrolled thread

Skylake (XPS 13 9350) TSC is way off

Started byAndy Lutomirski <luto@kernel.org>
First post2015-12-02 21:10 +0100
Last post2015-12-03 04:30 +0100
Articles 9 — 3 participants

Back to article view | Back to linux.kernel

Contents

  Skylake (XPS 13 9350) TSC is way off Andy Lutomirski <luto@kernel.org> - 2015-12-02 21:10 +0100
    RE: Skylake (XPS 13 9350) TSC is way off "Brown, Len" <len.brown@intel.com> - 2015-12-03 00:00 +0100
      Re: Skylake (XPS 13 9350) TSC is way off Andy Lutomirski <luto@kernel.org> - 2015-12-03 00:30 +0100
        Re: Skylake (XPS 13 9350) TSC is way off John Stultz <john.stultz@linaro.org> - 2015-12-03 00:40 +0100
          Re: Skylake (XPS 13 9350) TSC is way off Andy Lutomirski <luto@kernel.org> - 2015-12-03 00:50 +0100
            Re: Skylake (XPS 13 9350) TSC is way off John Stultz <john.stultz@linaro.org> - 2015-12-03 01:00 +0100
          Re: Skylake (XPS 13 9350) TSC is way off John Stultz <john.stultz@linaro.org> - 2015-12-03 00:50 +0100
            Re: Skylake (XPS 13 9350) TSC is way off Andy Lutomirski <luto@kernel.org> - 2015-12-03 01:10 +0100
        RE: Skylake (XPS 13 9350) TSC is way off "Brown, Len" <len.brown@intel.com> - 2015-12-03 04:30 +0100

#1282330 — Skylake (XPS 13 9350) TSC is way off

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-02 21:10 +0100
SubjectSkylake (XPS 13 9350) TSC is way off
Message-ID<qBlSX-3wb-37@gated-at.bofh.it>
[    0.000000] tsc: PIT calibration matches HPET. 2 loops
[    0.000000] tsc: Detected 2399.975 MHz processor
[    0.090897] TSC deadline timer enabled
[    1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz
[    1.960039] clocksource: tsc: mask: 0xffffffffffffffff max_cycles:
0x22983e30402, max_idle_ns: 440795260848 ns
[    2.959936] clocksource: Switched to clocksource tsc
[   87.168211] Adjusting tsc more than 11% (5941981 vs 7759439)

This is more or less Linus' latest tree (v4.4-rc3 plus some unrelated
platform driver patches).

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]

#1282498

From"Brown, Len" <len.brown@intel.com>
Date2015-12-03 00:00 +0100
Message-ID<qBoxu-50H-55@gated-at.bofh.it>
In reply to#1282330
K2Fkcmlhbg0KDQo+IFsgICAgMC4wMDAwMDBdIHRzYzogUElUIGNhbGlicmF0aW9uIG1hdGNoZXMg
SFBFVC4gMiBsb29wcw0KPiBbICAgIDAuMDAwMDAwXSB0c2M6IERldGVjdGVkIDIzOTkuOTc1IE1I
eiBwcm9jZXNzb3INCj4gWyAgICAwLjA5MDg5N10gVFNDIGRlYWRsaW5lIHRpbWVyIGVuYWJsZWQN
Cj4gWyAgICAxLjk2MDAzNF0gdHNjOiBSZWZpbmVkIFRTQyBjbG9ja3NvdXJjZSBjYWxpYnJhdGlv
bjogMjQwMC4wMDcgTUh6DQo+IFsgICAgMS45NjAwMzldIGNsb2Nrc291cmNlOiB0c2M6IG1hc2s6
IDB4ZmZmZmZmZmZmZmZmZmZmZiBtYXhfY3ljbGVzOg0KPiAweDIyOTgzZTMwNDAyLCBtYXhfaWRs
ZV9uczogNDQwNzk1MjYwODQ4IG5zDQo+IFsgICAgMi45NTk5MzZdIGNsb2Nrc291cmNlOiBTd2l0
Y2hlZCB0byBjbG9ja3NvdXJjZSB0c2MNCj4gWyAgIDg3LjE2ODIxMV0gQWRqdXN0aW5nIHRzYyBt
b3JlIHRoYW4gMTElICg1OTQxOTgxIHZzIDc3NTk0MzkpDQo+IA0KPiBUaGlzIGlzIG1vcmUgb3Ig
bGVzcyBMaW51cycgbGF0ZXN0IHRyZWUgKHY0LjQtcmMzIHBsdXMgc29tZSB1bnJlbGF0ZWQNCj4g
cGxhdGZvcm0gZHJpdmVyIHBhdGNoZXMpLg0KDQpIaSBBbmR5LA0KVGhhbmtzIGZvciB0aGUgbm90
ZS4NCkknbGwgc2VuZCB5b3UgYSBkZWJ1ZyB2ZXJzaW9uIG9mIHR1cmJvc3RhdCwgb2ZmIGxpc3Qs
DQpzaW5jZSB0aGUgbGlzdCB3aWxsIGp1c3QgYmxvY2sgbWFpbCB3aXRoIHRoYXQgYXR0YWNobWVu
dC4NCg0KdGhhbmtzLA0KLUxlbg0KDQo=
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282563

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-03 00:30 +0100
Message-ID<qBp0t-5qO-1@gated-at.bofh.it>
In reply to#1282498
[cc: John Stultz]

On Wed, Dec 2, 2015 at 2:52 PM, Brown, Len <len.brown@intel.com> wrote:
> +adrian
>
>> [    0.000000] tsc: PIT calibration matches HPET. 2 loops
>> [    0.000000] tsc: Detected 2399.975 MHz processor
>> [    0.090897] TSC deadline timer enabled
>> [    1.960034] tsc: Refined TSC clocksource calibration: 2400.007 MHz
>> [    1.960039] clocksource: tsc: mask: 0xffffffffffffffff max_cycles:
>> 0x22983e30402, max_idle_ns: 440795260848 ns
>> [    2.959936] clocksource: Switched to clocksource tsc
>> [   87.168211] Adjusting tsc more than 11% (5941981 vs 7759439)
>>
>> This is more or less Linus' latest tree (v4.4-rc3 plus some unrelated
>> platform driver patches).
>
> Hi Andy,
> Thanks for the note.
> I'll send you a debug version of turbostat, off list,
> since the list will just block mail with that attachment.

turbostat version 4.10 10 Dec, 2015 - Len Brown <lenb@kernel.org>
CPUID(0): GenuineIntel 22 CPUID levels; family:model:stepping 0x6:4e:3 (6:78:3)
CPUID(1): SSE3 MONITOR EIST TM2 TSC MSR ACPI-TM TM
CPUID(6): APERF, DTS, PTM, HWP, HWPnotify, HWPwindow, HWPepp, No-HWPpkg, EPB
cpu1: MSR_IA32_MISC_ENABLE: 0x00850089 (TCC EIST MONITOR)
CPUID(0x15): eax_crystal: 2 ebx_tsc: 200 ecx_crystal_hz: 0
TSC: 2400 MHz (24000000 Hz * 200 / 2 / 1000000)
CPUID(0x16): base_mhz: 2400 max_mhz: 2800 bus_mhz: 100
RAPL: 17476 sec. Joule Counter Range, at 15 Watts
cpu1: MSR_PLATFORM_INFO: 0x4043df1011800
4 * 100 = 400 MHz max efficiency frequency
24 * 100 = 2400 MHz base frequency
cpu1: MSR_IA32_POWER_CTL: 0x0024005d (C1E auto-promotion: DISabled)
cpu1: MSR_TURBO_RATIO_LIMIT: 0x1b1b1b1c
27 * 100 = 2700 MHz max turbo 4 active cores
27 * 100 = 2700 MHz max turbo 3 active cores
27 * 100 = 2700 MHz max turbo 2 active cores
28 * 100 = 2800 MHz max turbo 1 active cores
cpu1: MSR_CONFIG_TDP_NOMINAL: 0x00000017 (base_ratio=7)
cpu1: MSR_CONFIG_TDP_LEVEL_1: 0x0008003c (PKG_MIN_PWR_LVL1=0
PKG_MAX_PWR_LVL1=0 LVL1_RATIO=8 PKG_TDP_LVL1=60)
cpu1: MSR_CONFIG_TDP_LEVEL_2: 0x001800c8 (PKG_MIN_PWR_LVL2=0
PKG_MAX_PWR_LVL2=0 LVL2_RATIO=8 PKG_TDP_LVL2=200)
cpu1: MSR_CONFIG_TDP_CONTROL: 0x00000000 ( lock=0)
cpu1: MSR_TURBO_ACTIVATION_RATIO: 0x00000000 (MAX_NON_TURBO_RATIO=0 lock=0)
cpu1: MSR_NHM_SNB_PKG_CST_CFG_CTL: 0x1e008006 (UNdemote-C3,
UNdemote-C1, demote-C3, demote-C1, locked: pkg-cstate-limit=6: pc8)
cpu0: MSR_PM_ENABLE: 0x00000001 (HWP)
cpu0: MSR_HWP_CAPABILITIES: 0x0105171c (high 0x1c guar 0x17 eff 0x5 low 0x1)
cpu0: MSR_HWP_REQUEST: 0x80001c04 (min 0x4 max 0x1c des 0x0 epp 0x80
window 0x0 pkg 0x0)
cpu0: MSR_HWP_INTERRUPT: 0x00000001 (EN_Guaranteed_Perf_Change,
Dis_Excursion_Min)
cpu0: MSR_HWP_STATUS: 0x00000000 (No-Guaranteed_Perf_Change, No-Excursion_Min)
cpu0: MSR_IA32_ENERGY_PERF_BIAS: 0x00000006 (balanced)
cpu0: MSR_RAPL_POWER_UNIT: 0x000a0e03 (0.125000 Watts, 0.000061
Joules, 0.000977 sec.)
cpu0: MSR_PKG_POWER_INFO: 0x00000078 (15 W TDP, RAPL 0 - 0 W, 0.000000 sec.)
cpu0: MSR_PKG_POWER_LIMIT: 0x4280c800dd8078 (UNlocked)
cpu0: PKG Limit #1: ENabled (15.000000 Watts, 28.000000 sec, clamp ENabled)
cpu0: PKG Limit #2: ENabled (25.000000 Watts, 0.002441* sec, clamp DISabled)
cpu0: MSR_DRAM_POWER_LIMIT: 0x5400de00000000 (UNlocked)
cpu0: DRAM Limit: DISabled (0.000000 Watts, 0.000977 sec, clamp DISabled)
cpu0: MSR_IA32_TEMPERATURE_TARGET: 0x00640000 (100 C)
cpu0: MSR_IA32_PACKAGE_THERM_STATUS: 0x88340800 (48 C)
cpu0: MSR_IA32_THERM_STATUS: 0x88350800 (47 C +/- 1)
cpu1: MSR_IA32_THERM_STATUS: 0x88340800 (48 C +/- 1)
    Core     CPU Avg_MHz   %Busy Bzy_MHz TSC_MHz     SMI  CPU%c1
CPU%c3  CPU%c6  CPU%c7 CoreTmp  PkgTmp Totl%C0  Any%C0  GFX%C0 CPUGFX%
Pkg%pc2 Pkg%pc3 Pkg%pc6 Pkg%pc7 Pkg%pc8 Pkg%pc9 Pk%pc10 PkgWatt
RAMWatt   PKG_%   RAM_%
       -       -      16    2.84     549    2399       0    4.13
0.02    0.63   92.39      46      46   12.21   10.77    2.48    0.80
14.33   71.53    0.00    0.00    0.00    0.00    0.00    1.95    0.54
  0.00    0.00
       0       0      11    1.92     563    2399       0    2.48
0.02    0.80   94.78      46      46   12.21   10.78    2.48    0.80
14.34   71.55    0.00    0.00    0.00    0.00    0.00    1.95    0.54
  0.00    0.00
       0       2       8    1.39     550    2399       0    3.04
       1       1      13    2.04     622    2400       0    7.48
0.02    0.45   90.01      45
       1       3      31    6.01     520    2400       0    3.51
1.002561 sec

In case it's at all useful, adjtimex -p says:

         mode: 0
       offset: 0
    frequency: 135641
     maxerror: 37498
     esterror: 1532
       status: 8192
time_constant: 2
    precision: 1
    tolerance: 32768000
         tick: 10000
     raw time:  1449098317s 671243180us = 1449098317.671243180

this suggests a rather small correction, so I really have no idea what
"Adjusting tsc more than 11% (8039115 vs 7759462)" means.

John, you wrote this code.  What does the error message mean?

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282592

FromJohn Stultz <john.stultz@linaro.org>
Date2015-12-03 00:40 +0100
Message-ID<qBpa9-5uf-1@gated-at.bofh.it>
In reply to#1282563
On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
> In case it's at all useful, adjtimex -p says:
>
>          mode: 0
>        offset: 0
>     frequency: 135641
>      maxerror: 37498
>      esterror: 1532
>        status: 8192
> time_constant: 2
>     precision: 1
>     tolerance: 32768000
>          tick: 10000
>      raw time:  1449098317s 671243180us = 1449098317.671243180
>
> this suggests a rather small correction, so I really have no idea what
> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>
> John, you wrote this code.  What does the error message mean?

Basally the internal correction adjustments are getting pulled further
then it is supposed to (its concerning since in some cases we push the
clocksource mult value to be quite large, and so making a large
adjustment could possibly cause an overflow).

Awhile back I had intended to cap the max adjustment, but out of
caution I put in a warning instead to see how often this might occur.

I've seen it reported sometimes while folks were running trinity or
under a VM (suggesting that due to system delays timekeeping
management may have been delayed and the internal time error had grown
quite far, so the internal correction was being somewhat aggressive).
Though more recently (3.17 era) we've changed the internal adjustment
code to try to be more conservative to avoid over-steering w/ NOHZ, so
I'd expect fewer of these.

On a hunch, are you running chrony instead of ntpd?

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282599

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-03 00:50 +0100
Message-ID<qBpjP-5xC-5@gated-at.bofh.it>
In reply to#1282592
On Wed, Dec 2, 2015 at 3:38 PM, John Stultz <john.stultz@linaro.org> wrote:
> On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> In case it's at all useful, adjtimex -p says:
>>
>>          mode: 0
>>        offset: 0
>>     frequency: 135641
>>      maxerror: 37498
>>      esterror: 1532
>>        status: 8192
>> time_constant: 2
>>     precision: 1
>>     tolerance: 32768000
>>          tick: 10000
>>      raw time:  1449098317s 671243180us = 1449098317.671243180
>>
>> this suggests a rather small correction, so I really have no idea what
>> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>>
>> John, you wrote this code.  What does the error message mean?
>
> Basally the internal correction adjustments are getting pulled further
> then it is supposed to (its concerning since in some cases we push the
> clocksource mult value to be quite large, and so making a large
> adjustment could possibly cause an overflow).
>
> Awhile back I had intended to cap the max adjustment, but out of
> caution I put in a warning instead to see how often this might occur.
>
> I've seen it reported sometimes while folks were running trinity or
> under a VM (suggesting that due to system delays timekeeping
> management may have been delayed and the internal time error had grown
> quite far, so the internal correction was being somewhat aggressive).
> Though more recently (3.17 era) we've changed the internal adjustment
> code to try to be more conservative to avoid over-steering w/ NOHZ, so
> I'd expect fewer of these.
>

The trouble for me is that it's not clear from the message what rate
doesn't agree with what rate (kernel's unadjusted rate vs adjtimex's
request?), and the units are incomprehensible.  If the issue is that
adjtimex(2) has asked for X PPM of adjustment and X is greater than Y,
could we display that directly?

> On a hunch, are you running chrony instead of ntpd?

Yes, this is indeed chrony.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282606

FromJohn Stultz <john.stultz@linaro.org>
Date2015-12-03 01:00 +0100
Message-ID<qBptw-5Bi-21@gated-at.bofh.it>
In reply to#1282599
On Wed, Dec 2, 2015 at 3:42 PM, Andy Lutomirski <luto@kernel.org> wrote:
> On Wed, Dec 2, 2015 at 3:38 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> In case it's at all useful, adjtimex -p says:
>>>
>>>          mode: 0
>>>        offset: 0
>>>     frequency: 135641
>>>      maxerror: 37498
>>>      esterror: 1532
>>>        status: 8192
>>> time_constant: 2
>>>     precision: 1
>>>     tolerance: 32768000
>>>          tick: 10000
>>>      raw time:  1449098317s 671243180us = 1449098317.671243180
>>>
>>> this suggests a rather small correction, so I really have no idea what
>>> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>>>
>>> John, you wrote this code.  What does the error message mean?
>>
>> Basally the internal correction adjustments are getting pulled further
>> then it is supposed to (its concerning since in some cases we push the
>> clocksource mult value to be quite large, and so making a large
>> adjustment could possibly cause an overflow).
>>
>> Awhile back I had intended to cap the max adjustment, but out of
>> caution I put in a warning instead to see how often this might occur.
>>
>> I've seen it reported sometimes while folks were running trinity or
>> under a VM (suggesting that due to system delays timekeeping
>> management may have been delayed and the internal time error had grown
>> quite far, so the internal correction was being somewhat aggressive).
>> Though more recently (3.17 era) we've changed the internal adjustment
>> code to try to be more conservative to avoid over-steering w/ NOHZ, so
>> I'd expect fewer of these.
>>
>
> The trouble for me is that it's not clear from the message what rate
> doesn't agree with what rate (kernel's unadjusted rate vs adjtimex's
> request?), and the units are incomprehensible.  If the issue is that
> adjtimex(2) has asked for X PPM of adjustment and X is greater than Y,
> could we display that directly?

Sorry, yes, its the clocksource adjusted mult vs original mult values.

And its having to do with the internal correction (ie, what we've
actually done) logic, not the adjtimex requested adjustment (what we
were asked to do).

>> On a hunch, are you running chrony instead of ntpd?
>
> Yes, this is indeed chrony.

Ok. I'll have to look closer. The last time that message came up it
was in a report of a bug that chrony uncovered with the internal
correction being too slow. I know chrony is much more aggressive
compared to ntpd in tweaking the freq value for the initial converging
correction at startup, so maybe that along with something else is
causing us to get out of spec.

From the values I see in the message, it looks like you're not
overflowing mult, and the smallish freq value from adjtimex you're
seeing now look fine, so I suspect you're not actually hitting a
problem, but we're momentarily outside what the code is designed for.

Still need to figure out why and fix that, of course. :)

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282601

FromJohn Stultz <john.stultz@linaro.org>
Date2015-12-03 00:50 +0100
Message-ID<qBpjQ-5xC-17@gated-at.bofh.it>
In reply to#1282592
On Wed, Dec 2, 2015 at 3:38 PM, John Stultz <john.stultz@linaro.org> wrote:
> On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
>> In case it's at all useful, adjtimex -p says:
>>
>>          mode: 0
>>        offset: 0
>>     frequency: 135641
>>      maxerror: 37498
>>      esterror: 1532
>>        status: 8192
>> time_constant: 2
>>     precision: 1
>>     tolerance: 32768000
>>          tick: 10000
>>      raw time:  1449098317s 671243180us = 1449098317.671243180
>>
>> this suggests a rather small correction, so I really have no idea what
>> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>>
>> John, you wrote this code.  What does the error message mean?

Also, is there a behavior issue you're seeing or is this just a
concern about the warning? I assumed it was the first, but digging up
the thread here I'm not sure I see any specific problems listed.

thanks
-john
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282615

FromAndy Lutomirski <luto@kernel.org>
Date2015-12-03 01:10 +0100
Message-ID<qBpDc-5UD-29@gated-at.bofh.it>
In reply to#1282601
On Wed, Dec 2, 2015 at 3:42 PM, John Stultz <john.stultz@linaro.org> wrote:
> On Wed, Dec 2, 2015 at 3:38 PM, John Stultz <john.stultz@linaro.org> wrote:
>> On Wed, Dec 2, 2015 at 3:25 PM, Andy Lutomirski <luto@kernel.org> wrote:
>>> In case it's at all useful, adjtimex -p says:
>>>
>>>          mode: 0
>>>        offset: 0
>>>     frequency: 135641
>>>      maxerror: 37498
>>>      esterror: 1532
>>>        status: 8192
>>> time_constant: 2
>>>     precision: 1
>>>     tolerance: 32768000
>>>          tick: 10000
>>>      raw time:  1449098317s 671243180us = 1449098317.671243180
>>>
>>> this suggests a rather small correction, so I really have no idea what
>>> "Adjusting tsc more than 11% (8039115 vs 7759462)" means.
>>>
>>> John, you wrote this code.  What does the error message mean?
>
> Also, is there a behavior issue you're seeing or is this just a
> concern about the warning? I assumed it was the first, but digging up
> the thread here I'm not sure I see any specific problems listed.

No, there's no actual problem I'm aware of other than the error
message.  Skylake's TSC is different from other chips, and this is
Skylake, and I was worried that something was wrong with the initial
calibration.  It seems like the initial calibration may be fine,
though.

--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]

#1282680

From"Brown, Len" <len.brown@intel.com>
Date2015-12-03 04:30 +0100
Message-ID<qBsKK-7Sh-11@gated-at.bofh.it>
In reply to#1282563
PiA+PiBbICAgIDAuMDAwMDAwXSB0c2M6IFBJVCBjYWxpYnJhdGlvbiBtYXRjaGVzIEhQRVQuIDIg
bG9vcHMNCj4gPj4gWyAgICAwLjAwMDAwMF0gdHNjOiBEZXRlY3RlZCAyMzk5Ljk3NSBNSHogcHJv
Y2Vzc29yDQo+ID4+IFsgICAgMC4wOTA4OTddIFRTQyBkZWFkbGluZSB0aW1lciBlbmFibGVkDQo+
ID4+IFsgICAgMS45NjAwMzRdIHRzYzogUmVmaW5lZCBUU0MgY2xvY2tzb3VyY2UgY2FsaWJyYXRp
b246IDI0MDAuMDA3IE1Ieg0KDQo+IHR1cmJvc3RhdCB2ZXJzaW9uIDQuMTAgMTAgRGVjLCAyMDE1
IC0gTGVuIEJyb3duIDxsZW5iQGtlcm5lbC5vcmc+DQo+IENQVUlEKDApOiBHZW51aW5lSW50ZWwg
MjIgQ1BVSUQgbGV2ZWxzOyBmYW1pbHk6bW9kZWw6c3RlcHBpbmcgMHg2OjRlOjMgKDY6Nzg6MykN
Cj4gQ1BVSUQoMSk6IFNTRTMgTU9OSVRPUiBFSVNUIFRNMiBUU0MgTVNSIEFDUEktVE0gVE0NCj4g
Q1BVSUQoNik6IEFQRVJGLCBEVFMsIFBUTSwgSFdQLCBIV1Bub3RpZnksIEhXUHdpbmRvdywgSFdQ
ZXBwLCBOby1IV1Bwa2csIEVQQg0KPiBjcHUxOiBNU1JfSUEzMl9NSVNDX0VOQUJMRTogMHgwMDg1
MDA4OSAoVENDIEVJU1QgTU9OSVRPUikNCj4gQ1BVSUQoMHgxNSk6IGVheF9jcnlzdGFsOiAyIGVi
eF90c2M6IDIwMCBlY3hfY3J5c3RhbF9oejogMA0KPiBUU0M6IDI0MDAgTUh6ICgyNDAwMDAwMCBI
eiAqIDIwMCAvIDIgLyAxMDAwMDAwKQ0KPiBDUFVJRCgweDE2KTogYmFzZV9taHo6IDI0MDAgbWF4
X21oejogMjgwMCBidXNfbWh6OiAxMDANCg0KDQpCb3RoIHRoZSBpbml0aWFsIGFuZCByZWZpbmVk
IFRTQyBjYWxpYnJhdGlvbiBhcmUgcmlnaHQgb24gdGhlIG1vbmV5IC0tIDI0MDAgTUh6Lg0KRnVy
dGhlciwgdGhpcyBzeXN0ZW0gaGFwcGVucyB0byBhbHNvIGhhdmUgYSBiYXNlIGZyZXF1ZW5jeSBv
ZiAyNDAwIE1IeiwNCnNvIHRzY19raHogPSBjcHVfa2h6ID0gMiw0MDAsMDAwLCBleGFjdGx5LiAg
SXQgd291bGQgc3RyYXkgZnJvbSB0aGF0IHZhbHVlDQpvbmx5IGJhc2VkIG9uIHRoZSBwcG0gZXJy
b3Igb2YgdGhlIGJhc2UgMjQgTUh6IGNyeXN0YWwuDQoNCkFueXRoaW5nIG90aGVyIHRoYW4gdGhh
dCB2YWx1ZSBpcyBlcnJvci4NCg0KLUxlbg0KDQo+IFJBUEw6IDE3NDc2IHNlYy4gSm91bGUgQ291
bnRlciBSYW5nZSwgYXQgMTUgV2F0dHMNCj4gY3B1MTogTVNSX1BMQVRGT1JNX0lORk86IDB4NDA0
M2RmMTAxMTgwMA0KPiA0ICogMTAwID0gNDAwIE1IeiBtYXggZWZmaWNpZW5jeSBmcmVxdWVuY3kN
Cj4gMjQgKiAxMDAgPSAyNDAwIE1IeiBiYXNlIGZyZXF1ZW5jeQ0KPiBjcHUxOiBNU1JfSUEzMl9Q
T1dFUl9DVEw6IDB4MDAyNDAwNWQgKEMxRSBhdXRvLXByb21vdGlvbjogRElTYWJsZWQpDQo+IGNw
dTE6IE1TUl9UVVJCT19SQVRJT19MSU1JVDogMHgxYjFiMWIxYw0KPiAyNyAqIDEwMCA9IDI3MDAg
TUh6IG1heCB0dXJibyA0IGFjdGl2ZSBjb3Jlcw0KPiAyNyAqIDEwMCA9IDI3MDAgTUh6IG1heCB0
dXJibyAzIGFjdGl2ZSBjb3Jlcw0KPiAyNyAqIDEwMCA9IDI3MDAgTUh6IG1heCB0dXJibyAyIGFj
dGl2ZSBjb3Jlcw0KPiAyOCAqIDEwMCA9IDI4MDAgTUh6IG1heCB0dXJibyAxIGFjdGl2ZSBjb3Jl
cw0KPiBjcHUxOiBNU1JfQ09ORklHX1REUF9OT01JTkFMOiAweDAwMDAwMDE3IChiYXNlX3JhdGlv
PTcpDQo+IGNwdTE6IE1TUl9DT05GSUdfVERQX0xFVkVMXzE6IDB4MDAwODAwM2MgKFBLR19NSU5f
UFdSX0xWTDE9MA0KPiBQS0dfTUFYX1BXUl9MVkwxPTAgTFZMMV9SQVRJTz04IFBLR19URFBfTFZM
MT02MCkNCj4gY3B1MTogTVNSX0NPTkZJR19URFBfTEVWRUxfMjogMHgwMDE4MDBjOCAoUEtHX01J
Tl9QV1JfTFZMMj0wDQo+IFBLR19NQVhfUFdSX0xWTDI9MCBMVkwyX1JBVElPPTggUEtHX1REUF9M
VkwyPTIwMCkNCj4gY3B1MTogTVNSX0NPTkZJR19URFBfQ09OVFJPTDogMHgwMDAwMDAwMCAoIGxv
Y2s9MCkNCj4gY3B1MTogTVNSX1RVUkJPX0FDVElWQVRJT05fUkFUSU86IDB4MDAwMDAwMDAgKE1B
WF9OT05fVFVSQk9fUkFUSU89MA0KPiBsb2NrPTApDQo+IGNwdTE6IE1TUl9OSE1fU05CX1BLR19D
U1RfQ0ZHX0NUTDogMHgxZTAwODAwNiAoVU5kZW1vdGUtQzMsDQo+IFVOZGVtb3RlLUMxLCBkZW1v
dGUtQzMsIGRlbW90ZS1DMSwgbG9ja2VkOiBwa2ctY3N0YXRlLWxpbWl0PTY6IHBjOCkNCj4gY3B1
MDogTVNSX1BNX0VOQUJMRTogMHgwMDAwMDAwMSAoSFdQKQ0KPiBjcHUwOiBNU1JfSFdQX0NBUEFC
SUxJVElFUzogMHgwMTA1MTcxYyAoaGlnaCAweDFjIGd1YXIgMHgxNyBlZmYgMHg1IGxvdw0KPiAw
eDEpDQo+IGNwdTA6IE1TUl9IV1BfUkVRVUVTVDogMHg4MDAwMWMwNCAobWluIDB4NCBtYXggMHgx
YyBkZXMgMHgwIGVwcCAweDgwDQo+IHdpbmRvdyAweDAgcGtnIDB4MCkNCj4gY3B1MDogTVNSX0hX
UF9JTlRFUlJVUFQ6IDB4MDAwMDAwMDEgKEVOX0d1YXJhbnRlZWRfUGVyZl9DaGFuZ2UsDQo+IERp
c19FeGN1cnNpb25fTWluKQ0KPiBjcHUwOiBNU1JfSFdQX1NUQVRVUzogMHgwMDAwMDAwMCAoTm8t
R3VhcmFudGVlZF9QZXJmX0NoYW5nZSwgTm8tDQo+IEV4Y3Vyc2lvbl9NaW4pDQo+IGNwdTA6IE1T
Ul9JQTMyX0VORVJHWV9QRVJGX0JJQVM6IDB4MDAwMDAwMDYgKGJhbGFuY2VkKQ0KPiBjcHUwOiBN
U1JfUkFQTF9QT1dFUl9VTklUOiAweDAwMGEwZTAzICgwLjEyNTAwMCBXYXR0cywgMC4wMDAwNjEN
Cj4gSm91bGVzLCAwLjAwMDk3NyBzZWMuKQ0KPiBjcHUwOiBNU1JfUEtHX1BPV0VSX0lORk86IDB4
MDAwMDAwNzggKDE1IFcgVERQLCBSQVBMIDAgLSAwIFcsIDAuMDAwMDAwDQo+IHNlYy4pDQo+IGNw
dTA6IE1TUl9QS0dfUE9XRVJfTElNSVQ6IDB4NDI4MGM4MDBkZDgwNzggKFVObG9ja2VkKQ0KPiBj
cHUwOiBQS0cgTGltaXQgIzE6IEVOYWJsZWQgKDE1LjAwMDAwMCBXYXR0cywgMjguMDAwMDAwIHNl
YywgY2xhbXANCj4gRU5hYmxlZCkNCj4gY3B1MDogUEtHIExpbWl0ICMyOiBFTmFibGVkICgyNS4w
MDAwMDAgV2F0dHMsIDAuMDAyNDQxKiBzZWMsIGNsYW1wDQo+IERJU2FibGVkKQ0KPiBjcHUwOiBN
U1JfRFJBTV9QT1dFUl9MSU1JVDogMHg1NDAwZGUwMDAwMDAwMCAoVU5sb2NrZWQpDQo+IGNwdTA6
IERSQU0gTGltaXQ6IERJU2FibGVkICgwLjAwMDAwMCBXYXR0cywgMC4wMDA5Nzcgc2VjLCBjbGFt
cCBESVNhYmxlZCkNCj4gY3B1MDogTVNSX0lBMzJfVEVNUEVSQVRVUkVfVEFSR0VUOiAweDAwNjQw
MDAwICgxMDAgQykNCj4gY3B1MDogTVNSX0lBMzJfUEFDS0FHRV9USEVSTV9TVEFUVVM6IDB4ODgz
NDA4MDAgKDQ4IEMpDQo+IGNwdTA6IE1TUl9JQTMyX1RIRVJNX1NUQVRVUzogMHg4ODM1MDgwMCAo
NDcgQyArLy0gMSkNCj4gY3B1MTogTVNSX0lBMzJfVEhFUk1fU1RBVFVTOiAweDg4MzQwODAwICg0
OCBDICsvLSAxKQ0KPiAgICAgQ29yZSAgICAgQ1BVIEF2Z19NSHogICAlQnVzeSBCenlfTUh6IFRT
Q19NSHogICAgIFNNSSAgQ1BVJWMxDQo+IENQVSVjMyAgQ1BVJWM2ICBDUFUlYzcgQ29yZVRtcCAg
UGtnVG1wIFRvdGwlQzAgIEFueSVDMCAgR0ZYJUMwIENQVUdGWCUNCj4gUGtnJXBjMiBQa2clcGMz
IFBrZyVwYzYgUGtnJXBjNyBQa2clcGM4IFBrZyVwYzkgUGslcGMxMCBQa2dXYXR0DQo+IFJBTVdh
dHQgICBQS0dfJSAgIFJBTV8lDQo+ICAgICAgICAtICAgICAgIC0gICAgICAxNiAgICAyLjg0ICAg
ICA1NDkgICAgMjM5OSAgICAgICAwICAgIDQuMTMNCj4gMC4wMiAgICAwLjYzICAgOTIuMzkgICAg
ICA0NiAgICAgIDQ2ICAgMTIuMjEgICAxMC43NyAgICAyLjQ4ICAgIDAuODANCj4gMTQuMzMgICA3
MS41MyAgICAwLjAwICAgIDAuMDAgICAgMC4wMCAgICAwLjAwICAgIDAuMDAgICAgMS45NSAgICAw
LjU0DQo+ICAgMC4wMCAgICAwLjAwDQo+ICAgICAgICAwICAgICAgIDAgICAgICAxMSAgICAxLjky
ICAgICA1NjMgICAgMjM5OSAgICAgICAwICAgIDIuNDgNCj4gMC4wMiAgICAwLjgwICAgOTQuNzgg
ICAgICA0NiAgICAgIDQ2ICAgMTIuMjEgICAxMC43OCAgICAyLjQ4ICAgIDAuODANCj4gMTQuMzQg
ICA3MS41NSAgICAwLjAwICAgIDAuMDAgICAgMC4wMCAgICAwLjAwICAgIDAuMDAgICAgMS45NSAg
ICAwLjU0DQo+ICAgMC4wMCAgICAwLjAwDQo+ICAgICAgICAwICAgICAgIDIgICAgICAgOCAgICAx
LjM5ICAgICA1NTAgICAgMjM5OSAgICAgICAwICAgIDMuMDQNCj4gICAgICAgIDEgICAgICAgMSAg
ICAgIDEzICAgIDIuMDQgICAgIDYyMiAgICAyNDAwICAgICAgIDAgICAgNy40OA0KPiAwLjAyICAg
IDAuNDUgICA5MC4wMSAgICAgIDQ1DQo+ICAgICAgICAxICAgICAgIDMgICAgICAzMSAgICA2LjAx
ICAgICA1MjAgICAgMjQwMCAgICAgICAwICAgIDMuNTENCj4gMS4wMDI1NjEgc2VjDQo+IA0KPiBJ
biBjYXNlIGl0J3MgYXQgYWxsIHVzZWZ1bCwgYWRqdGltZXggLXAgc2F5czoNCj4gDQo+ICAgICAg
ICAgIG1vZGU6IDANCj4gICAgICAgIG9mZnNldDogMA0KPiAgICAgZnJlcXVlbmN5OiAxMzU2NDEN
Cj4gICAgICBtYXhlcnJvcjogMzc0OTgNCj4gICAgICBlc3RlcnJvcjogMTUzMg0KPiAgICAgICAg
c3RhdHVzOiA4MTkyDQo+IHRpbWVfY29uc3RhbnQ6IDINCj4gICAgIHByZWNpc2lvbjogMQ0KPiAg
ICAgdG9sZXJhbmNlOiAzMjc2ODAwMA0KPiAgICAgICAgICB0aWNrOiAxMDAwMA0KPiAgICAgIHJh
dyB0aW1lOiAgMTQ0OTA5ODMxN3MgNjcxMjQzMTgwdXMgPSAxNDQ5MDk4MzE3LjY3MTI0MzE4MA0K
PiANCj4gdGhpcyBzdWdnZXN0cyBhIHJhdGhlciBzbWFsbCBjb3JyZWN0aW9uLCBzbyBJIHJlYWxs
eSBoYXZlIG5vIGlkZWEgd2hhdA0KPiAiQWRqdXN0aW5nIHRzYyBtb3JlIHRoYW4gMTElICg4MDM5
MTE1IHZzIDc3NTk0NjIpIiBtZWFucy4NCj4gDQo+IEpvaG4sIHlvdSB3cm90ZSB0aGlzIGNvZGUu
ICBXaGF0IGRvZXMgdGhlIGVycm9yIG1lc3NhZ2UgbWVhbj8NCj4gDQo+IC0tQW5keQ0K
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web