From: Ye Xiaolong <xiaolong.ye@intel.com>
To: Dou Liyang <douly.fnst@cn.fujitsu.com>
Cc: guzheng1@huawei.com, Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@kernel.org>,
"Li, Philip" <philip.li@intel.com>,
lkp@01.org, LKML <linux-kernel@vger.kernel.org>
Subject: Re: [lkp] [x86/acpi] dc6db24d24: BUG: unable to handle kernel paging request at 0000116007090008
Date: Mon, 13 Feb 2017 14:05:05 +0800 [thread overview]
Message-ID: <20170213060505.GH28502@yexl-desktop> (raw)
In-Reply-To: <0188ea2f-f2a1-bfb0-5733-8c84abc3acac@cn.fujitsu.com>
Hi, liyang
On 02/13, Dou Liyang wrote:
>Hi, Xiaolong
>
>At 02/13/2017 09:37 AM, Ye Xiaolong wrote:
>>On 11/21, Dou Liyang wrote:
>>>Hi, Xiaolong,
>>>
>>>At 11/21/2016 09:31 AM, Ye Xiaolong wrote:
>>>>On 11/18, Dou Liyang wrote:
>>>>>Hi xiaolong
>>>>>
>>>>>At 11/18/2016 02:16 PM, Ye Xiaolong wrote:
>>>>>>Hi, liyang
>>>>>>
>>>>>>Sorry for the late.
>>>>>>
>>>>>>On 10/31, Dou Liyang wrote:
>>>>>>>Hi, Xiaolong,
>>>>>>>
>>>>>>>I research the ACPI table for a long time, and I found that:
>>>>>>>The reason for this bug is the duplicate IDs "0xFF" in DSDT.
>>>>>>>it has already been fixed in the committed id
>>>>>>>8e089eaa1999def4bb954caa91941f29b0672b6a and
>>>>>>>fd74da217df7d4bd25e95411da64e0b92762842e which is after the
>>>>>>>dc6db24d2476cd09c0ecf2b8d80313539f737a89 .
>>>>>>>
>>>>>>>could you help me to Verify my thoughts in the LKP.
>>>>>>>
>>>>>>
>>>>>>I've queued the same test jobs for commit fd74da217d, I'll notify you
>>>>>>once I get the results.
>>>>>
>>>>
>>>>Hi, Liyang,
>>>>
>>>>Results show that the reported error is gone with commit fd74da217df7d4bd25e95411da64e0b92762842e
>>>>below is the comparison.
>>>>
>>>
>>>thanks a lot. that means it has been fixed.
>>
>>Sorry for my neglect, the result for fd74da217df7d4bd25e95411da showed no dmesg
>>because it's incomplete run and has no demsg stat at all.
>
>Is that means:
>
>you have already tested the Linux branch which contains the commit
>fd74da217df7d. and it doesn't work well.
>
>Btw, Why the test is incomplete run ?
Yes, We've got plenty test results for kernel that contains fd74da217df7d such as v4.9,
v4.10-rc1, v4.10-rc2...., they all have the same dmesg errors.
For the incomplete run, it may happen sometimes due to kernel panic during boot time and
0day failed to capture its dmesg stat.
>
>>The bug still persists in v4.9, v4.10-rcx, the lastest kernel head,
>
>If the dmesg and stat of the test is NULL, How do you prove that the
>bug still exists?
This "dmesg stat is empty" refer to test for kernel image which head commit is fd74da217df7d,
not for all test results.
>
>>could you help to check?
>>
>
>Yes, I think we first should make the test with commit fd74da217df7d
>work in the specific test machine.
>
>test machine: 72 threads Intel(R) Xeon(R) CPU E5-2699 v3 @ 2.30GHz
>with 128G memory
>
>Am I right? waiting your response.
Yes, currently we just found this issue on a specific machine, and I've queued the
same jobs to other machines to see whether they have the same issue.
Thanks,
Xiaolong
>
>Thanks,
>Liyang
>
>>Thanks,
>>Xiaolong
>>
>>>
>>>>
>>>>compare -at dc6db24d2476cd09c0ecf2b8d80313539f737a89 fd74da217df7d4bd25e95411da64e0b92762842e
>>>>tests: 1
>>>>testcase/path_params/tbox_group/run: vm-scalability/300-never-never-1-1-swap-w-rand-performance/lkp-hsw-ep2
>>>>
>>>>dc6db24d2476cd09 fd74da217df7d4bd25e95411da
>>>>---------------- --------------------------
>>>> fail:runs %reproduction fail:runs
>>>> | | |
>>>> 12:12 -100% :3 dmesg.BUG:unable_to_handle_kernel
>>>> 12:12 -100% :3 dmesg.Oops
>>>> 12:12 -100% :3 dmesg.RIP:get_partial_node
>>>> 9:12 -75% :3 dmesg.RIP:_raw_spin_lock_irqsave
>>>> 3:12 -25% :3 dmesg.general_protection_fault:#[##]SMP
>>>> 3:12 -25% :3 dmesg.RIP:native_queued_spin_lock_slowpath
>>>> 3:12 -25% :3 dmesg.Kernel_panic-not_syncing:Hard_LOCKUP
>>>> 2:12 -17% :3 dmesg.RIP:load_balance
>>>> 2:12 -17% :3 dmesg.Kernel_panic-not_syncing:Fatal_exception_in_interrupt
>>>> 1:12 -8% :3 dmesg.RIP:resched_curr
>>>> 1:12 -8% :3 dmesg.Kernel_panic-not_syncing:Fatal_exception
>>>> 5:12 -42% :3 dmesg.WARNING:at_include/linux/uaccess.h:#__probe_kernel_read
>>>> 1:12 -8% :3 dmesg.WARNING:at_lib/list_debug.c:#__list_add
>>>>
>>>>
>>>
>>>>>>>2. About the LKP-tests, I want run the tests in my own pc.
>>>>>>>I use the debain sid as an OS. the .yaml file can be installed and
>>>>>>>job splited, but it can't be run correctly.
>>>>>>>
>>>>>>>Is the linux source code must be in /tmp/?
>>>>>>>And if I need to modify the .yaml file to fit my pc.
>>>>>>>
>>>>>>
>>>>>>Could you paste the error log for me to analyze?
>>>>>
>>>>>Yes. let me tidy up it ah. :)
>>>>>
>>>
>>>And, I am very interesting in LKP-Test. when I built it, I met some
>>>problems.
>>>
>>>here is the error log:
>>>
>>>root@debian:/home/douly/lkp-tests# lkp run ./job-unlink2-performance-04c197c080f2ed7a022f79701455c6837f4b9573-debian-x86_64-2016-08-31.cgz.yaml
>>>
>>>IPMI BMC is not supported on this machine, skip bmc-watchdog setup!
>>>2016-11-21 15:21:01 ./runtest.py unlink2 32 both 1 54 72
>>>/home/douly/lkp-tests/bin/log_cmd: 7: exec: ./runtest.py: not found
>>>kill 18805 vmstat -n 10
>>>kill 18803 dmesg --follow --decode
>>>kill 18829 /lkp/benchmarks/perf-stat/perf stat -a -I 1000 -x -e cpu-clock,task-clock,page-faults,context-switches,cpu-migrations,minor-faults,major-faults
>>>--log-fd 1 --
>>>kill 18806 vmstat -n 1
>>>wait for background monitors: 18811 18813 18830 18833 18832 18819
>>>18821 18826 18818 18815 18810 18814 18825 18827 proc-stat meminfo
>>>oom-killer uptime nfs-hang softirqs diskstats sched_debug
>>>latency_stats interrupts proc-vmstat slabinfo turbostat perf-profile
>>>Error:
>>>The /tmp/lkp-root/perf.data file has no samples!
>>>
>>>Thanks,
>>>
>>>Dou.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>
>>
>>
>
>
next prev parent reply other threads:[~2017-02-13 6:05 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20161020011604.GC17837@yexl-desktop>
2016-10-20 11:40 ` Dou Liyang
2016-10-21 3:01 ` Ye Xiaolong
[not found] ` <20161021030210.GH24319@yexl-desktop>
[not found] ` <402c35ce-aca6-4b66-ecfd-2bcb7a4767b3@cn.fujitsu.com>
[not found] ` <20161118061622.GD2684@yexl-desktop>
[not found] ` <46cd9d61-229f-9452-80ae-b9b42f2672cb@cn.fujitsu.com>
[not found] ` <20161121013110.GA591@yexl-desktop>
[not found] ` <97e44a89-e527-5100-31b1-44cf1b0aea57@cn.fujitsu.com>
[not found] ` <20170213013708.GI16630@yexl-desktop>
2017-02-13 5:30 ` Dou Liyang
2017-02-13 6:05 ` Ye Xiaolong [this message]
2017-02-13 8:06 ` Dou Liyang
2017-02-13 1:33 ` [LKP] " Ye Xiaolong
2017-02-17 7:23 ` Dou Liyang
2017-02-17 7:40 ` Ye Xiaolong
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170213060505.GH28502@yexl-desktop \
--to=xiaolong.ye@intel.com \
--cc=douly.fnst@cn.fujitsu.com \
--cc=guzheng1@huawei.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=mingo@kernel.org \
--cc=philip.li@intel.com \
--cc=tglx@linutronix.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®