From: "Huang\, Ying" <ying.huang@linux.intel.com>
To: Daniel J Blueman <daniel@numascale.com>
Cc: <lkp@01.org>, LKML <linux-kernel@vger.kernel.org>,
Daniel Lezcano <daniel.lezcano@linaro.org>,
Steffen Persvold <sp@numascale.com>,
"Thomas Gleixner" <tglx@linutronix.de>
Subject: Re: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang
Date: Fri, 13 Nov 2015 16:06:19 +0800 [thread overview]
Message-ID: <87k2pm7284.fsf@yhuang-dev.intel.com> (raw)
In-Reply-To: <1447266511.14441.1@outlook-emeawest.office365.com> (Daniel J. Blueman's message of "Wed, 11 Nov 2015 19:28:31 +0100")
Daniel J Blueman <daniel@numascale.com> writes:
> Hi Ying Huang,
>
> On Tue, Nov 10, 2015 at 6:12 AM, kernel test robot
> <ying.huang@linux.intel.com> wrote:
>> FYI, we noticed the below changes on
>>
>> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>> master
>> commit db1003a719d75cebe5843a7906c02c29bec9922c ("x86/numachip:
>> Cleanup Numachip support")
>>
>>
>> Elapsed time: 210
>> BUG: kernel early-boot hang
>> Linux version 4.3.0-rc2-00001-gdb1003a #1
>> Command line: root=/dev/ram0 user=lkp
>> job=/lkp/scheduled/vm-intel12-yocto-x86_64-14/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-allyesdebian-db1003a719d75cebe5843a7906c02c29bec9922c-20151107-100037-1jb4qfh-1.yaml
>> ARCH=x86_64 kconfig=x86_64-allyesdebian
>> branch=sergeh-security/2015-11-05/cgroupns
>> commit=db1003a719d75cebe5843a7906c02c29bec9922c
>> BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-00001-gdb1003a
>> max_uptime=600
>> RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/0
>> LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug
>> apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>> load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0
>> vga=normal rw ip=::::vm-intel12-yocto-x86_64-14::dhcp
>> drbd.minor_count=8
>> qemu-system-x86_64 -enable-kvm -cpu Nehalem -kernel
>> /pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-00001-gdb1003a
>> -append 'root=/dev/ram0 user=lkp
>> job=/lkp/scheduled/vm-intel12-yocto-x86_64-14/bisect_boot-1-yocto-minimal-x86_64.cgz-x86_64-allyesdebian-db1003a719d75cebe5843a7906c02c29bec9922c-20151107-100037-1jb4qfh-1.yaml
>> ARCH=x86_64 kconfig=x86_64-allyesdebian
>> branch=sergeh-security/2015-11-05/cgroupns
>> commit=db1003a719d75cebe5843a7906c02c29bec9922c
>> BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/vmlinuz-4.3.0-rc2-00001-gdb1003a
>> max_uptime=600
>> RESULT_ROOT=/result/boot/1/vm-intel12-yocto-x86_64/yocto-minimal-x86_64.cgz/x86_64-allyesdebian/gcc-5/db1003a719d75cebe5843a7906c02c29bec9922c/0
>> LKP_SERVER=inn earlyprintk=ttyS0,115200 systemd.log_level=err debug
>> apic=debug sysrq_always_enabled rcupdate.rcu_cpu_stall_timeout=100
>> panic=-1 softlockup_panic=1 nmi_watchdog=panic oops=panic
>> load_ramdisk=2 prompt_ramdisk=0 console=ttyS0,115200 console=tty0
>> vga=normal rw ip=::::vm-intel12-yocto-x86_64-14::dhcp
>> drbd.minor_count=8' -initrd
>> /fs/KVM/initrd-vm-intel12-yocto-x86_64-14 -m 832 -smp 2 -device
>> e1000,netdev=net0 -netdev user,id=net0 -boot order=nc -no-reboot
>> -watchdog i6300esb -rtc base=localtime -drive
>> file=/fs/KVM/disk0-vm-intel12-yocto-x86_64-14,media=disk,if=virtio
>> -drive
>> file=/fs/KVM/disk1-vm-intel12-yocto-x86_64-14,media=disk,if=virtio
>> -pidfile /dev/shm/kboot/pid-vm-intel12-yocto-x86_64-14 -serial
>> file:/dev/shm/kboot/serial-vm-intel12-yocto-x86_64-14 -daemonize
>> -display none -monitor null
>
> Neat, however checking out the same kernel tree at "db1003a
> x86/numachip: Cleanup Numachip support", building with the same config
> (though with GCC 5.2.1), it boots just peachy with the same args.
>
> The patch itself is conservative, so I can't see how it could cause
> early boot hangs. Have you seen this kind of issue before, or is this
> the first time?
Sorry, the origin report is a false positive. The early boot hang
caused by testing system instead of your commit. Sorry again for that.
Will be more carefully in the future.
Best Regards,
Huang, Ying
prev parent reply other threads:[~2015-11-13 8:06 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-11-10 5:12 [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang kernel test robot
2015-11-11 18:28 ` Daniel J Blueman
2015-11-13 8:06 ` Huang, Ying [this message]
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=87k2pm7284.fsf@yhuang-dev.intel.com \
--to=ying.huang@linux.intel.com \
--cc=daniel.lezcano@linaro.org \
--cc=daniel@numascale.com \
--cc=linux-kernel@vger.kernel.org \
--cc=lkp@01.org \
--cc=sp@numascale.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