Re: [btrfs] 70d28b0e4f: BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok

[David Sterba <dsterba@suse.cz>]

On Mon, Apr 01, 2019 at 11:02:37PM +0800,  Chen, Rong A  wrote:
> 
> On 4/1/2019 10:29 PM, Qu Wenruo wrote:
> >
> > On 2019/4/1 下午10:02,  Chen, Rong A  wrote:
> >> On 4/1/2019 9:28 PM, Nikolay Borisov wrote:
> >>> On 1.04.19 г. 16:24 ч., kernel test robot wrote:
> >>>> FYI, we noticed the following commit (built with gcc-7):
> >>>>
> >>>> commit: 70d28b0e4f8ed2d38571e7b1f9bec7f321a53102 ("btrfs:
> >>>> tree-checker: Verify dev item")
> >>>> https://git.kernel.org/cgit/linux/kernel/git/next/linux-next.git master
> >>>>
> >>>> in testcase: trinity
> >>>> with following parameters:
> >>>>
> >>>>      runtime: 300s
> >>>>
> >>>> test-description: Trinity is a linux system call fuzz tester.
> >>>> test-url: http://codemonkey.org.uk/projects/trinity/
> >>>>
> >>>>
> >>>> on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp
> >>>> 2 -m 2G
> >>>>
> >>>> caused below changes (please refer to attached dmesg/kmsg for entire
> >>>> log/backtrace):
> >>>>
> >>>>
> >>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
> >>>>
> >>>> |
> >>>> | 36b9d2bc69 | 70d28b0e4f |
> >>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
> >>>>
> >>>> |
> >>>> boot_successes
> >>>> | 14         | 0          |
> >>>> |
> >>>> boot_failures
> >>>> | 2          | 14         |
> >>>> |
> >>>> IP-Config:Auto-configuration_of_network_failed
> >>>> | 2          |            |
> >>>> |
> >>>> BUG:kernel_reboot-without-warning_in_early-boot_stage,last_printk:Probing_EDD(edd=off_to_disable)...ok
> >>>> | 0          | 14         |
> >>>> +--------------------------------------------------------------------------------------------------------+------------+------------+
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> early console in setup code
> >>>> Probing EDD (edd=off to disable)... ok
> >>>> BUG: kernel reboot-without-warning in early-boot stage, last printk:
> >>>> Probing EDD (edd=off to disable)... ok
> >>>> Linux version 5.0.0-rc8-00196-g70d28b0 #1
> >>>> Command line: ip=::::vm-snb-quantal-x86_64-1415::dhcp root=/dev/ram0
> >>>> user=lkp
> >>>> job=/lkp/jobs/scheduled/vm-snb-quantal-x86_64-1415/trinity-300s-quantal-core-x86_64-2018-11-09.cgz-70d28b0-20190330-29362-1y6g0qb-2.yaml
> >>>> ARCH=x86_64 kconfig=x86_64-randconfig-s5-03231928
> >>>> branch=linux-devel/devel-hourly-2019032317
> >>>> commit=70d28b0e4f8ed2d38571e7b1f9bec7f321a53102
> >>>> BOOT_IMAGE=/pkg/linux/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/vmlinuz-5.0.0-rc8-00196-g70d28b0
> >>>> max_uptime=1500
> >>>> RESULT_ROOT=/result/trinity/300s/vm-snb-quantal-x86_64/quantal-core-x86_64-2018-11-09.cgz/x86_64-randconfig-s5-03231928/gcc-7/70d28b0e4f8ed2d38571e7b1f9bec7f321a53102/8
> >>>> LKP_SERVER=inn debug apic=debug sysrq_always_enabled
> >>>> rcupdate.rcu_cpu_stall_timeout=100 net.ifnames=0 printk.devkmsg=on
> >>>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
> >>>> load_ramdisk=2 prompt_ramdisk=0 drbd.minor_count=8
> >>>> systemd.log_level=err ignore_loglevel console=tty0
> >>>> earlyprintk=ttyS0,115200 console=ttyS0,115200 vga=normal rw
> >>>> rcuperf.shutdown=0
> >>>>
> >>> Can this report be made useful by actually including output from serial
> >>> console? For example possible bug-ons or whatnot? dmesg.xz just contains
> >>> qemu's command line + some metadata about the test and :
> >>>
> >>> "BUG: kernel reboot-without-warning in early-boot stage, last printk:
> >>> Probing EDD (edd=off to disable)... ok"
> >>>
> >>> At least a stack trace would have been useful.
> >>>
> >>> <snip>
> >>
> >> Hi,
> >>
> >> We usually use the tool ("bin/lkp qemu -k <bzImage> job-script") to
> >> reproduce it.  It seems no stack trace in the result:
> > So there is no regression at that commit right?
> >
> > Just some false alert?
> 
> 
> Hi,
> 
> I think there's a regression, it stopped in the early-boot stage .

Can you please provide any logs that would point at btrfs? If the module
is loaded or built-in started, there's a line about that. Besides that
it's preceded by messages from other subsystems' initialization.