From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1757553AbcGZUE1 (ORCPT ); Tue, 26 Jul 2016 16:04:27 -0400 Received: from out02.mta.xmission.com ([166.70.13.232]:54931 "EHLO out02.mta.xmission.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1757012AbcGZUEY (ORCPT ); Tue, 26 Jul 2016 16:04:24 -0400 From: ebiederm@xmission.com (Eric W. Biederman) To: Fengguang Wu Cc: containers@lists.linux-foundation.org, lkp@01.org, LKML References: <5793dfa5.mvXPj4LJOS0dlz3i%xiaolong.ye@intel.com> <877fc9a6mb.fsf@x220.int.ebiederm.org> <20160726143545.GA23656@wfg-t540p.sh.intel.com> <87vazsv4cn.fsf@x220.int.ebiederm.org> <20160726151344.GB8811@wfg-t540p.sh.intel.com> Date: Tue, 26 Jul 2016 14:50:58 -0500 In-Reply-To: <20160726151344.GB8811@wfg-t540p.sh.intel.com> (Fengguang Wu's message of "Tue, 26 Jul 2016 23:13:44 +0800") Message-ID: <87wpk8p49p.fsf@x220.int.ebiederm.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-XM-SPF: eid=1bS8a6-00080e-DG;;;mid=<87wpk8p49p.fsf@x220.int.ebiederm.org>;;;hst=in02.mta.xmission.com;;;ip=67.3.204.119;;;frm=ebiederm@xmission.com;;;spf=neutral X-XM-AID: U2FsdGVkX1+kH6G7+B3pDqby+zL/oVVRMKtOPa5nLEY= X-SA-Exim-Connect-IP: 67.3.204.119 X-SA-Exim-Mail-From: ebiederm@xmission.com X-Spam-Report: * -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP * 0.0 TVD_RCVD_IP Message was received from an IP address * 0.7 XMSubLong Long Subject * 0.0 T_TM2_M_HEADER_IN_MSG BODY: No description available. * 0.8 BAYES_50 BODY: Bayes spam probability is 40 to 60% * [score: 0.5000] * -0.0 DCC_CHECK_NEGATIVE Not listed in DCC * [sa02 1397; Body=1 Fuz1=1 Fuz2=1] X-Spam-DCC: XMission; sa02 1397; Body=1 Fuz1=1 Fuz2=1 X-Spam-Combo: ;Fengguang Wu X-Spam-Relay-Country: X-Spam-Timing: total 1233 ms - load_scoreonly_sql: 0.09 (0.0%), signal_user_changed: 24 (2.0%), b_tie_ro: 22 (1.8%), parse: 1.29 (0.1%), extract_message_metadata: 58 (4.7%), get_uri_detail_list: 3.6 (0.3%), tests_pri_-1000: 5 (0.4%), tests_pri_-950: 14 (1.2%), tests_pri_-900: 1.81 (0.1%), tests_pri_-400: 53 (4.3%), check_bayes: 51 (4.1%), b_tokenize: 17 (1.4%), b_tok_get_all: 12 (1.0%), b_comp_prob: 5 (0.4%), b_tok_touch_all: 12 (1.0%), b_finish: 1.05 (0.1%), tests_pri_0: 1052 (85.3%), check_dkim_signature: 1.06 (0.1%), check_dkim_adsp: 92 (7.5%), tests_pri_500: 17 (1.4%), rewrite_mail: 0.00 (0.0%) Subject: Re: [LKP] More information please. Re: [fs] 54cc07a761: BUG: kernel test crashed X-Spam-Flag: No X-SA-Exim-Version: 4.2.1 (built Thu, 05 May 2016 13:38:54 -0600) X-SA-Exim-Scanned: Yes (on in02.mta.xmission.com) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Fengguang Wu writes: > On Tue, Jul 26, 2016 at 09:52:40AM -0500, Eric W. Biederman wrote: >>Fengguang Wu writes: >>> On Mon, Jul 25, 2016 at 01:57:00PM -0500, Eric W. Biederman wrote: >>>>kernel test robot writes: >>[snip] >>>>> >>>>> [ 19.206454] VFS: Warning: trinity-c0 using old stat() call. Recompile your binary. >>>>> >>>>> Elapsed time: 70 >>>>> BUG: kernel test crashed >>>> >>>>What application generated the line "BUG: kernel test crashed." >>>>What flavor of crash was this? >>> >>> It's a simple boot test with a quick trinity run. So there will be >>> some randomness in this test. >>> >>> The "BUG: kernel test crashed" means the VM reboots by itself while >>> the trinity test is running. If the error message is "BUG: kernel boot >>> crashed" it'd mean VM abnormally reboots before any test is launched. >> >>Is it possible to include a url pointing to a page of documentation >>holding this information in your emails or alternatively a url pointing >>to some source code. Just so other people don't have to ask you this >>question. > > Yes that's the right directions to follow. We'll make the reports more > understandable and the test/bisects more reliable. Thanks. Does trinity have a random seed it can export/import to rerun the same tests? I ask because there was a failure these tests caught that if the right kernel options was enabled was 100% reliable and it blamed a commit 10 patches down from the indicated commit. The problem being 100% reproducible it wasn't an issue that the indicated commit was wrong. But a 100% reliable failure being misattributed suggest a way attribution could become more reliable. > In particular, I suspect this false report might be related to QEMU > watchdog. The wild guess is, if trinity touches the watchdog device by > accident, it may result in the VM reset w/o any symptom. Interesting. I hope it is the watchdog. I know some qemu versions + some kernel versions have race conditions that are observable during boot. I don't know if those happen in your test harness but it may be worth a look. I tend to get grumpy when I see those and work on stabalizing a magic kernel config that likes qemu, but I keep finding issues when I try other peoples configurations for reproducing problems like this one. Eric