2015-11-10 05:12:57

by kernel test robot

[permalink] [raw]
Subject: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

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


Thanks,
Ying Huang


Attachments:
(No filename) (2.81 kB)
config-4.3.0-rc2-00001-gdb1003a (142.77 kB)
dmesg.xz (888.00 B)
Download all attachments

2015-11-11 18:28:51

by Daniel J Blueman

[permalink] [raw]
Subject: Re: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

Hi Ying Huang,

On Tue, Nov 10, 2015 at 6:12 AM, kernel test robot
<[email protected]> 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?

Thanks!
Daniel

2015-11-13 08:06:23

by kernel test robot

[permalink] [raw]
Subject: Re: [lkp] [x86/numachip] db1003a719: BUG: kernel early-boot hang

Daniel J Blueman <[email protected]> writes:

> Hi Ying Huang,
>
> On Tue, Nov 10, 2015 at 6:12 AM, kernel test robot
> <[email protected]> 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