|
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [Xen-devel] [linux-linus bisection] complete test-amd64-amd64-xl-pvh-amd
branch xen-unstable xenbranch xen-unstable job test-amd64-amd64-xl-pvh-amd testid xen-boot Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: bba072dfd7bf87f0712e569a78ae9c0e91e0a8df Bug not present: 511601bdbcacd3ab615564941409bf012435b23d Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/64875/ commit bba072dfd7bf87f0712e569a78ae9c0e91e0a8df Merge: 511601b 04633df Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Sun Nov 15 09:32:59 2015 -0800 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A couple of fixes and updates related to x86: - Fix the W+X check regression on XEN - The real fix for the low identity map trainwreck - Probe legacy PIC early instead of unconditionally allocating legacy irqs - Add cpu verification to long mode entry - Adjust the cache topology to AMD Fam17H systems - Let Merrifield use the TSC across S3" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu: Call verify_cpu() after having entered long mode too x86/setup: Fix low identity map for >= 2GB kernel range x86/mm: Skip the hypervisor range when walking PGD x86/AMD: Fix last level cache topology for AMD Fam17h systems x86/irq: Probe for PIC presence before allocating descs for legacy IRQs x86/cpu/intel: Enable X86_FEATURE_NONSTOP_TSC_S3 for Merrifield commit 04633df0c43d710e5f696b06539c100898678235 Author: Borislav Petkov <bp@xxxxxxx> Date: Thu Nov 5 16:57:56 2015 +0100 x86/cpu: Call verify_cpu() after having entered long mode too When we get loaded by a 64-bit bootloader, kernel entry point is startup_64 in head_64.S. We don't trust any and all bootloaders because some will fiddle with CPU configuration so we go ahead and massage each CPU into sanity again. For example, some dell BIOSes have this XD disable feature which set IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround for other OSes but Linux sure doesn't need it. A similar thing is present in the Surface 3 firmware - see https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit only on the BSP: # rdmsr -a 0x1a0 400850089 850089 850089 850089 I know, right?! There's not even an off switch in there. So fix all those cases by sanitizing the 64-bit entry point too. For that, make verify_cpu() callable in 64-bit mode also. Requested-and-debugged-by: "H. Peter Anvin" <hpa@xxxxxxxxx> Reported-and-tested-by: Bastien Nocera <bugzilla@xxxxxxxxxx> Signed-off-by: Borislav Petkov <bp@xxxxxxx> Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@xxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 68accac392d859d24adcf1be3a90e41f978bd54c Author: Krzysztof Mazur <krzysiek@xxxxxxxxxxxx> Date: Fri Nov 6 14:18:36 2015 +0100 x86/setup: Fix low identity map for >= 2GB kernel range The commit f5f3497cad8c extended the low identity mapping. However, if the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory split), the normal memory mapping is overwritten by the low identity mapping causing a crash. To avoid overwritting, limit the low identity map to cover only memory before kernel range (PAGE_OFFSET). Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel range Signed-off-by: Krzysztof Mazur <krzysiek@xxxxxxxxxxxx> Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx> Cc: Borislav Petkov <bp@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Cc: Matt Fleming <matt.fleming@xxxxxxxxx> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@xxxxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit f4e342c87776884f0309942a3880ca7e835239f9 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Thu Nov 5 13:56:35 2015 -0500 x86/mm: Skip the hypervisor range when walking PGD The range between 0xffff800000000000 and 0xffff87ffffffffff is reserved for hypervisor and therefore we should not try to follow PGD's indexes corresponding to those addresses. While this has always been a problem, with the new W+X warning mechanism ptdump_walk_pgd_level_core() can now be called during boot, causing a PV Xen guest to crash. [ tglx: Replaced the macro with a readable inline ] Fixes: e1a58320a38d "x86/mm: Warn on W^X mappings" Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Cc: xen-devel@xxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446749795-27764-1-git-send-email-boris.ostrovsky@xxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 3849e91f571dcb48cf2c8143480c59137d44d6bc Author: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx> Date: Wed Nov 4 12:49:42 2015 +0100 x86/AMD: Fix last level cache topology for AMD Fam17h systems On AMD Fam17h systems, the last level cache is not resident in the northbridge. Therefore, we cannot assign cpu_llc_id to the same value as Node ID as we have been doing until now. We should rather look at the ApicID bits of the core to provide us the last level cache ID info. Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Cc: Andy Lutomirski <luto@xxxxxxxxxx> Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> Cc: Huang Rui <ray.huang@xxxxxxx> Cc: Ingo Molnar <mingo@xxxxxxxxxx> Cc: Jacob Shin <jacob.w.shin@xxxxxxxxx> Link: http://lkml.kernel.org/r/1446582899-9378-1-git-send-email-Aravind.Gopalakrishnan@xxxxxxx Signed-off-by: Borislav Petkov <bp@xxxxxxx> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 8c058b0b9c34d8c8d7912880956543769323e2d8 Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Date: Tue Nov 3 10:40:14 2015 +0100 x86/irq: Probe for PIC presence before allocating descs for legacy IRQs Commit d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces") brought a regression for Hyper-V Gen2 instances. These instances don't have i8259 legacy PIC but they use legacy IRQs for serial port, rtc, and acpi. With this commit included we end up with these IRQs not initialized. Earlier, there was a special workaround for legacy IRQs in mp_map_pin_to_irq() doing mp_irqdomain_map() without looking at nr_legacy_irqs() and now we fail in __irq_domain_alloc_irqs() when irq_domain_alloc_descs() returns -EEXIST. The essence of the issue seems to be that early_irq_init() calls arch_probe_nr_irqs() to figure out the number of legacy IRQs before we probe for i8259 and gets 16. Later when init_8259A() is called we switch to NULL legacy PIC and nr_legacy_irqs() starts to return 0 but we already have 16 descs allocated. Solve the issue by separating i8259 probe from init and calling it in arch_probe_nr_irqs() before we actually use nr_legacy_irqs() information. Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces") Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Cc: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx> Cc: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446543614-3621-1-git-send-email-vkuznets@xxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 354dbaa7ff5b53a0ed1c0f7a9773d5953b3a1bb9 Author: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Date: Thu Oct 8 18:56:26 2015 +0300 x86/cpu/intel: Enable X86_FEATURE_NONSTOP_TSC_S3 for Merrifield The Intel Merrifield SoC is a successor of the Intel MID line of SoCs. Let's set the neccessary capability for that chip. See commit c54fdbb2823d (x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3) for the details. Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Link: http://lkml.kernel.org/r/1444319786-36125-1-git-send-email-andriy.shevchenko@xxxxxxxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> For bisection revision-tuple graph see: http://logs.test-lab.xenproject.org/osstest/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-amd.xen-boot.html Revision IDs in each graph node refer, respectively, to the Trees above. ---------------------------------------- Running cs-bisection-step --graph-out=/home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-amd.xen-boot --summary-out=tmp/64875.bisection-summary --basis-template=59254 --blessings=real,real-bisect linux-linus test-amd64-amd64-xl-pvh-amd xen-boot Searching for failure / basis pass: 64484 fail [host=pinot1] / 64197 ok. Failure / basis pass flights: 64484 / 64197 (tree with no url: ovmf) (tree with no url: seabios) Tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Tree: linuxfirmware git://xenbits.xen.org/osstest/linux-firmware.git Tree: qemu git://xenbits.xen.org/qemu-xen-traditional.git Tree: qemuu git://xenbits.xen.org/qemu-xen.git Tree: xen git://xenbits.xen.org/xen.git Latest 8005c49d9aea74d382f474ce11afbbc7d7130bec c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Basis pass f6d07dfcb15aad199d7351d3122eabd506968daf c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Generating revisions with ./adhoc-revtuple-generator git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git#f6d07dfcb15aad199d7351d3122eabd506968daf-8005c49d9aea74d382f474ce11afbbc7d7130bec git://xenbits.xen.org/osstest/linux-firmware.git#c530a75c1e6a472b0eb9558310b518f0dfcd8860-c530a75c1e6a472b0eb9558310b518f0dfcd8860 git://xenbits.xen.org/qemu-xen-traditional.git#bc00cad75d8bcc3ba696992bec219c21db8406aa-bc00cad75d8bcc3ba696992bec219c21db8406aa git://xenbits.xen.org/qemu-xen.git#816609b2841297925a223ec377c336360e044ee5-816609b2841297925a223ec377c336360e044ee5 git://xenbits.xen.org/xen.git#22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c-22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Loaded 1119 nodes in revision graph Searching for test results: 64197 pass f6d07dfcb15aad199d7351d3122eabd506968daf c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64484 fail 8005c49d9aea74d382f474ce11afbbc7d7130bec c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64813 fail 8005c49d9aea74d382f474ce11afbbc7d7130bec c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64739 pass f6d07dfcb15aad199d7351d3122eabd506968daf c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64818 pass a30b7ca2894994e4e2f2e06811ee67fa637bca2e c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64824 pass b84da9fa47cf6e8dfd71d673a2f744ec1cac452c c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64854 fail bba072dfd7bf87f0712e569a78ae9c0e91e0a8df c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64862 pass 511601bdbcacd3ab615564941409bf012435b23d c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64837 fail 8f98e292eb612956e1add401f28dc76ffea20323 c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64875 fail bba072dfd7bf87f0712e569a78ae9c0e91e0a8df c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64845 pass 511601bdbcacd3ab615564941409bf012435b23d c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64864 fail bba072dfd7bf87f0712e569a78ae9c0e91e0a8df c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c 64872 pass 511601bdbcacd3ab615564941409bf012435b23d c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c Searching for interesting versions Result found: flight 64197 (pass), for basis pass Result found: flight 64484 (fail), for basis failure Repro found: flight 64739 (pass), for basis pass Repro found: flight 64813 (fail), for basis failure 0 revisions at 511601bdbcacd3ab615564941409bf012435b23d c530a75c1e6a472b0eb9558310b518f0dfcd8860 bc00cad75d8bcc3ba696992bec219c21db8406aa 816609b2841297925a223ec377c336360e044ee5 22a1fbb575df3a3a7726cdeb5ddf19cc8f60827c No revisions left to test, checking graph state. Result found: flight 64845 (pass), for last pass Result found: flight 64854 (fail), for first failure Repro found: flight 64862 (pass), for last pass Repro found: flight 64864 (fail), for first failure Repro found: flight 64872 (pass), for last pass Repro found: flight 64875 (fail), for first failure *** Found and reproduced problem changeset *** Bug is in tree: linux git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git Bug introduced: bba072dfd7bf87f0712e569a78ae9c0e91e0a8df Bug not present: 511601bdbcacd3ab615564941409bf012435b23d Last fail repro: http://logs.test-lab.xenproject.org/osstest/logs/64875/ commit bba072dfd7bf87f0712e569a78ae9c0e91e0a8df Merge: 511601b 04633df Author: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> Date: Sun Nov 15 09:32:59 2015 -0800 Merge branch 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip Pull x86 fixes from Thomas Gleixner: "A couple of fixes and updates related to x86: - Fix the W+X check regression on XEN - The real fix for the low identity map trainwreck - Probe legacy PIC early instead of unconditionally allocating legacy irqs - Add cpu verification to long mode entry - Adjust the cache topology to AMD Fam17H systems - Let Merrifield use the TSC across S3" * 'x86-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/cpu: Call verify_cpu() after having entered long mode too x86/setup: Fix low identity map for >= 2GB kernel range x86/mm: Skip the hypervisor range when walking PGD x86/AMD: Fix last level cache topology for AMD Fam17h systems x86/irq: Probe for PIC presence before allocating descs for legacy IRQs x86/cpu/intel: Enable X86_FEATURE_NONSTOP_TSC_S3 for Merrifield commit 04633df0c43d710e5f696b06539c100898678235 Author: Borislav Petkov <bp@xxxxxxx> Date: Thu Nov 5 16:57:56 2015 +0100 x86/cpu: Call verify_cpu() after having entered long mode too When we get loaded by a 64-bit bootloader, kernel entry point is startup_64 in head_64.S. We don't trust any and all bootloaders because some will fiddle with CPU configuration so we go ahead and massage each CPU into sanity again. For example, some dell BIOSes have this XD disable feature which set IA32_MISC_ENABLE[34] and disable NX. This might be some dumb workaround for other OSes but Linux sure doesn't need it. A similar thing is present in the Surface 3 firmware - see https://bugzilla.kernel.org/show_bug.cgi?id=106051 - which sets this bit only on the BSP: # rdmsr -a 0x1a0 400850089 850089 850089 850089 I know, right?! There's not even an off switch in there. So fix all those cases by sanitizing the 64-bit entry point too. For that, make verify_cpu() callable in 64-bit mode also. Requested-and-debugged-by: "H. Peter Anvin" <hpa@xxxxxxxxx> Reported-and-tested-by: Bastien Nocera <bugzilla@xxxxxxxxxx> Signed-off-by: Borislav Petkov <bp@xxxxxxx> Cc: Matt Fleming <matt@xxxxxxxxxxxxxxxxxxx> Cc: Peter Zijlstra <peterz@xxxxxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446739076-21303-1-git-send-email-bp@xxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 68accac392d859d24adcf1be3a90e41f978bd54c Author: Krzysztof Mazur <krzysiek@xxxxxxxxxxxx> Date: Fri Nov 6 14:18:36 2015 +0100 x86/setup: Fix low identity map for >= 2GB kernel range The commit f5f3497cad8c extended the low identity mapping. However, if the kernel uses more than 2 GB (VMSPLIT_2G_OPT or VMSPLIT_1G memory split), the normal memory mapping is overwritten by the low identity mapping causing a crash. To avoid overwritting, limit the low identity map to cover only memory before kernel range (PAGE_OFFSET). Fixes: f5f3497cad8c "x86/setup: Extend low identity map to cover whole kernel range Signed-off-by: Krzysztof Mazur <krzysiek@xxxxxxxxxxxx> Cc: Andy Lutomirski <luto@xxxxxxxxxxxxxx> Cc: Borislav Petkov <bp@xxxxxxxxx> Cc: Laszlo Ersek <lersek@xxxxxxxxxx> Cc: Matt Fleming <matt.fleming@xxxxxxxxx> Cc: Paolo Bonzini <pbonzini@xxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446815916-22105-1-git-send-email-krzysiek@xxxxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit f4e342c87776884f0309942a3880ca7e835239f9 Author: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Date: Thu Nov 5 13:56:35 2015 -0500 x86/mm: Skip the hypervisor range when walking PGD The range between 0xffff800000000000 and 0xffff87ffffffffff is reserved for hypervisor and therefore we should not try to follow PGD's indexes corresponding to those addresses. While this has always been a problem, with the new W+X warning mechanism ptdump_walk_pgd_level_core() can now be called during boot, causing a PV Xen guest to crash. [ tglx: Replaced the macro with a readable inline ] Fixes: e1a58320a38d "x86/mm: Warn on W^X mappings" Reported-by: Sander Eikelenboom <linux@xxxxxxxxxxxxxx> Signed-off-by: Boris Ostrovsky <boris.ostrovsky@xxxxxxxxxx> Cc: xen-devel@xxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446749795-27764-1-git-send-email-boris.ostrovsky@xxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 3849e91f571dcb48cf2c8143480c59137d44d6bc Author: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx> Date: Wed Nov 4 12:49:42 2015 +0100 x86/AMD: Fix last level cache topology for AMD Fam17h systems On AMD Fam17h systems, the last level cache is not resident in the northbridge. Therefore, we cannot assign cpu_llc_id to the same value as Node ID as we have been doing until now. We should rather look at the ApicID bits of the core to provide us the last level cache ID info. Signed-off-by: Aravind Gopalakrishnan <Aravind.Gopalakrishnan@xxxxxxx> Cc: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> Cc: Andy Lutomirski <luto@xxxxxxxxxx> Cc: Frederic Weisbecker <fweisbec@xxxxxxxxx> Cc: "H. Peter Anvin" <hpa@xxxxxxxxx> Cc: Huang Rui <ray.huang@xxxxxxx> Cc: Ingo Molnar <mingo@xxxxxxxxxx> Cc: Jacob Shin <jacob.w.shin@xxxxxxxxx> Link: http://lkml.kernel.org/r/1446582899-9378-1-git-send-email-Aravind.Gopalakrishnan@xxxxxxx Signed-off-by: Borislav Petkov <bp@xxxxxxx> Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 8c058b0b9c34d8c8d7912880956543769323e2d8 Author: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Date: Tue Nov 3 10:40:14 2015 +0100 x86/irq: Probe for PIC presence before allocating descs for legacy IRQs Commit d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces") brought a regression for Hyper-V Gen2 instances. These instances don't have i8259 legacy PIC but they use legacy IRQs for serial port, rtc, and acpi. With this commit included we end up with these IRQs not initialized. Earlier, there was a special workaround for legacy IRQs in mp_map_pin_to_irq() doing mp_irqdomain_map() without looking at nr_legacy_irqs() and now we fail in __irq_domain_alloc_irqs() when irq_domain_alloc_descs() returns -EEXIST. The essence of the issue seems to be that early_irq_init() calls arch_probe_nr_irqs() to figure out the number of legacy IRQs before we probe for i8259 and gets 16. Later when init_8259A() is called we switch to NULL legacy PIC and nr_legacy_irqs() starts to return 0 but we already have 16 descs allocated. Solve the issue by separating i8259 probe from init and calling it in arch_probe_nr_irqs() before we actually use nr_legacy_irqs() information. Fixes: d32932d02e18 ("x86/irq: Convert IOAPIC to use hierarchical irqdomain interfaces") Signed-off-by: Vitaly Kuznetsov <vkuznets@xxxxxxxxxx> Cc: Jiang Liu <jiang.liu@xxxxxxxxxxxxxxx> Cc: K. Y. Srinivasan <kys@xxxxxxxxxxxxx> Cc: stable@xxxxxxxxxxxxxxx Link: http://lkml.kernel.org/r/1446543614-3621-1-git-send-email-vkuznets@xxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> commit 354dbaa7ff5b53a0ed1c0f7a9773d5953b3a1bb9 Author: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Date: Thu Oct 8 18:56:26 2015 +0300 x86/cpu/intel: Enable X86_FEATURE_NONSTOP_TSC_S3 for Merrifield The Intel Merrifield SoC is a successor of the Intel MID line of SoCs. Let's set the neccessary capability for that chip. See commit c54fdbb2823d (x86: Add cpu capability flag X86_FEATURE_NONSTOP_TSC_S3) for the details. Signed-off-by: Andy Shevchenko <andriy.shevchenko@xxxxxxxxxxxxxxx> Link: http://lkml.kernel.org/r/1444319786-36125-1-git-send-email-andriy.shevchenko@xxxxxxxxxxxxxxx Signed-off-by: Thomas Gleixner <tglx@xxxxxxxxxxxxx> Revision graph left in /home/logs/results/bisect/linux-linus/test-amd64-amd64-xl-pvh-amd.xen-boot.{dot,ps,png,html,svg}. ---------------------------------------- 64875: tolerable ALL FAIL flight 64875 linux-linus real-bisect [real] http://logs.test-lab.xenproject.org/osstest/logs/64875/ Failures :-/ but no regressions. Tests which did not succeed, including tests which could not be run: test-amd64-amd64-xl-pvh-amd 6 xen-boot fail baseline untested jobs: test-amd64-amd64-xl-pvh-amd fail ------------------------------------------------------------ sg-report-flight on osstest.test-lab.xenproject.org logs: /home/logs/logs images: /home/logs/images Logs, config files, etc. are available at http://logs.test-lab.xenproject.org/osstest/logs Explanation of these reports, and of osstest in general, is at http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master Test harness code can be found at http://xenbits.xen.org/gitweb?p=osstest.git;a=summary _______________________________________________ Xen-devel mailing list Xen-devel@xxxxxxxxxxxxx http://lists.xen.org/xen-devel
|
 |
Lists.xenproject.org is hosted with RackSpace, monitoring our |