Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-22 Thread Fengguang Wu 

On Thu, Nov 23, 2017 at 07:36:23AM +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 04:39:14PM +0200, Andy Shevchenko wrote:

On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> It shows up since v4.13 .

Sorry it actually also shows up in 4.10:


This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:


It's basically a KVM machine. This is adapted from the reproduce
script attached in the first email:

kvm=(
   qemu-system-x86_64
   -enable-kvm
   -cpu IvyBridge
   -kernel $kernel
   -initrd initrd.img
   -m 1536
   -smp 2
   -device e1000,netdev=net0
   -netdev user,id=net0,hostfwd=tcp::23406-:22
   -boot order=nc
   -no-reboot
   -watchdog i6300esb
   -watchdog-action debug
   -rtc base=localtime
   -drive file=disk-vm-ivb41-1G-7-0,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-1,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-2,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-3,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-4,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-5,media=disk,if=virtio



   -serial stdio


Sorry that has been replaced to stdio for convenience of use.
Since this error is related to serial console, it's good to
use the original options used in testing: 


-serial file:$dmesg
   -serial file:$kmsg

So wrt. your question in the other email, ttyS1 is for writing
kmsg by this script

https://github.com/intel/lkp-tests/blob/master/monitors/kmsg

Thanks,
Fengguang


   -display none
   -monitor null
)

append=(
   ip=vm-ivb41-1G-7::dhcp
   root=/dev/ram0
   user=lkp
   job=/job-script
   ARCH=x86_64
   kconfig=x86_64-allyesdebian
   branch=linus/master
   commit=abc36be236358162202e86ad88616ff95a755101
   
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/vmlinuz-4.14.0-02748-gabc36be
   max_uptime=600
   
RESULT_ROOT=/result/boot/1/vm-ivb41-1G/debian-x86_64-2016-08-31.cgz/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/0
   result_service=tmpfs
   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
)

Thanks,
Fengguang

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-22 Thread Fengguang Wu 

On Thu, Nov 23, 2017 at 07:36:23AM +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 04:39:14PM +0200, Andy Shevchenko wrote:

On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> It shows up since v4.13 .

Sorry it actually also shows up in 4.10:


This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:


It's basically a KVM machine. This is adapted from the reproduce
script attached in the first email:

kvm=(
   qemu-system-x86_64
   -enable-kvm
   -cpu IvyBridge
   -kernel $kernel
   -initrd initrd.img
   -m 1536
   -smp 2
   -device e1000,netdev=net0
   -netdev user,id=net0,hostfwd=tcp::23406-:22
   -boot order=nc
   -no-reboot
   -watchdog i6300esb
   -watchdog-action debug
   -rtc base=localtime
   -drive file=disk-vm-ivb41-1G-7-0,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-1,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-2,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-3,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-4,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-5,media=disk,if=virtio



   -serial stdio


Sorry that has been replaced to stdio for convenience of use.
Since this error is related to serial console, it's good to
use the original options used in testing: 


-serial file:$dmesg
   -serial file:$kmsg

So wrt. your question in the other email, ttyS1 is for writing
kmsg by this script

https://github.com/intel/lkp-tests/blob/master/monitors/kmsg

Thanks,
Fengguang


   -display none
   -monitor null
)

append=(
   ip=vm-ivb41-1G-7::dhcp
   root=/dev/ram0
   user=lkp
   job=/job-script
   ARCH=x86_64
   kconfig=x86_64-allyesdebian
   branch=linus/master
   commit=abc36be236358162202e86ad88616ff95a755101
   
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/vmlinuz-4.14.0-02748-gabc36be
   max_uptime=600
   
RESULT_ROOT=/result/boot/1/vm-ivb41-1G/debian-x86_64-2016-08-31.cgz/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/0
   result_service=tmpfs
   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
)

Thanks,
Fengguang

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-22 Thread Fengguang Wu 

On Tue, Nov 21, 2017 at 04:39:14PM +0200, Andy Shevchenko wrote:

On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> It shows up since v4.13 .

Sorry it actually also shows up in 4.10:


This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:


It's basically a KVM machine. This is adapted from the reproduce
script attached in the first email: 


kvm=(
   qemu-system-x86_64
   -enable-kvm
   -cpu IvyBridge
   -kernel $kernel
   -initrd initrd.img
   -m 1536
   -smp 2
   -device e1000,netdev=net0
   -netdev user,id=net0,hostfwd=tcp::23406-:22
   -boot order=nc
   -no-reboot
   -watchdog i6300esb
   -watchdog-action debug
   -rtc base=localtime
   -drive file=disk-vm-ivb41-1G-7-0,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-1,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-2,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-3,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-4,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-5,media=disk,if=virtio
   -serial stdio
   -display none
   -monitor null
)

append=(
   ip=vm-ivb41-1G-7::dhcp
   root=/dev/ram0
   user=lkp
   job=/job-script
   ARCH=x86_64
   kconfig=x86_64-allyesdebian
   branch=linus/master
   commit=abc36be236358162202e86ad88616ff95a755101
   
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/vmlinuz-4.14.0-02748-gabc36be
   max_uptime=600
   
RESULT_ROOT=/result/boot/1/vm-ivb41-1G/debian-x86_64-2016-08-31.cgz/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/0
   result_service=tmpfs
   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
)

Thanks,
Fengguang

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-22 Thread Fengguang Wu 

On Tue, Nov 21, 2017 at 04:39:14PM +0200, Andy Shevchenko wrote:

On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> Hello,
>
> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> It shows up since v4.13 .

Sorry it actually also shows up in 4.10:


This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:


It's basically a KVM machine. This is adapted from the reproduce
script attached in the first email: 


kvm=(
   qemu-system-x86_64
   -enable-kvm
   -cpu IvyBridge
   -kernel $kernel
   -initrd initrd.img
   -m 1536
   -smp 2
   -device e1000,netdev=net0
   -netdev user,id=net0,hostfwd=tcp::23406-:22
   -boot order=nc
   -no-reboot
   -watchdog i6300esb
   -watchdog-action debug
   -rtc base=localtime
   -drive file=disk-vm-ivb41-1G-7-0,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-1,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-2,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-3,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-4,media=disk,if=virtio
   -drive file=disk-vm-ivb41-1G-7-5,media=disk,if=virtio
   -serial stdio
   -display none
   -monitor null
)

append=(
   ip=vm-ivb41-1G-7::dhcp
   root=/dev/ram0
   user=lkp
   job=/job-script
   ARCH=x86_64
   kconfig=x86_64-allyesdebian
   branch=linus/master
   commit=abc36be236358162202e86ad88616ff95a755101
   
BOOT_IMAGE=/pkg/linux/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/vmlinuz-4.14.0-02748-gabc36be
   max_uptime=600
   
RESULT_ROOT=/result/boot/1/vm-ivb41-1G/debian-x86_64-2016-08-31.cgz/x86_64-allyesdebian/gcc-6/abc36be236358162202e86ad88616ff95a755101/0
   result_service=tmpfs
   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
)

Thanks,
Fengguang

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Andy Shevchenko 
On Tue, 2017-11-21 at 16:39 +0200, Andy Shevchenko wrote:
> On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:
> > On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:

>>> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> > > It shows up since v4.13 .
> > 
> > Sorry it actually also shows up in 4.10:

>> [   21.020567] irq 3: nobody cared (try booting with the "irqpoll"
> > option)

> > [   21.039171]  uart_start+0x73/0xe0

> > [   21.044977]  vfs_write+0xc8/0x1e0

> > [   21.054662] Disabling IRQ #3

Another question who and why initiates a write to ttyS1 (console seems
on ttyS0).

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Andy Shevchenko 
On Tue, 2017-11-21 at 16:39 +0200, Andy Shevchenko wrote:
> On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:
> > On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:

>>> FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> > > It shows up since v4.13 .
> > 
> > Sorry it actually also shows up in 4.10:

>> [   21.020567] irq 3: nobody cared (try booting with the "irqpoll"
> > option)

> > [   21.039171]  uart_start+0x73/0xe0

> > [   21.044977]  vfs_write+0xc8/0x1e0

> > [   21.054662] Disabling IRQ #3

Another question who and why initiates a write to ttyS1 (console seems
on ttyS0).

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Andy Shevchenko 
On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:
> On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> > Hello,
> > 
> > FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> > It shows up since v4.13 .
> 
> Sorry it actually also shows up in 4.10:

This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:

1. % acpidump -o tables.dat # tables.dat is point of interest
2. % lspci -vv -nk # output of the command
3. % dmidecode # output of the command
4. % grep -H 15 /sys/bus/acpi/devices/*/status # output of the command
5. % dmesg # when kernel command line has the 'ignore_loglevel
initcall_debug' added

Also 
% cat /proc/interrupts # if possible in both working / non-working cases


> /pkg/linux/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-
> 6/c470abd4fde40ea6a0846a2beab642a578c0b8cd/dmesg-vm-lkp-hsw01-4G-
> 1:20171110043200:x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED:4.10.0:1
> 
> [   19.902933]
> [   19.904514]
> [   19.904515]
> [   21.020567] irq 3: nobody cared (try booting with the "irqpoll"
> option)
> [   21.021466] CPU: 0 PID: 4094 Comm: dmesg Not tainted 4.10.0 #1
> [   21.022276] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1 04/01/2014
> [   21.023584] Call Trace:
> [   21.024126]  
> [   21.025622]  dump_stack+0x63/0x8a
> [   21.026238]  __report_bad_irq+0x35/0xc0
> [   21.026890]  note_interrupt+0x234/0x270
> [   21.027548]  handle_irq_event_percpu+0x45/0x60
> [   21.028249]  handle_irq_event+0x42/0x70
> [   21.028901]  handle_edge_irq+0x74/0x140
> [   21.029560]  handle_irq+0x73/0x120
> [   21.030177]  ? irq_exit+0x6a/0xf0
> [   21.030794]  do_IRQ+0x46/0xd0
> [   21.031380]  common_interrupt+0x8e/0x8e
> [   21.032042] RIP: 0010:_raw_spin_unlock_irqrestore+0x15/0x30
> [   21.032831] RSP: 0018:c90002d9fd28 EFLAGS: 0286 ORIG_RAX:
> ffcc
> [   21.034081] RAX: 0001 RBX: 82362ee8 RCX:
> 
> [   21.034999] RDX: 02f9 RSI: 0286 RDI:
> 0286
> [   21.035914] RBP: c90002d9fd28 R08: 0004 R09:
> 88012e6dfc38
> [   21.036826] R10: 7ffc8f5bb708 R11: 88007f542580 R12:
> 88007fd51c00
> [   21.037742] R13: 0286 R14: c900031672a0 R15:
> 0001
> [   21.038654]  
> [   21.039171]  uart_start+0x73/0xe0
> [   21.039783]  uart_flush_chars+0xe/0x10
> [   21.040430]  n_tty_write+0x231/0x450
> [   21.041068]  ? __wake_up_sync+0x20/0x20
> [   21.041721]  tty_write+0x1ab/0x330
> [   21.042346]  ? n_tty_open+0xd0/0xd0
> [   21.042972]  __vfs_write+0x28/0x140
> [   21.043602]  ? security_file_permission+0x3b/0xc0
> [   21.044326]  ? rw_verify_area+0x4e/0xb0
> [   21.044977]  vfs_write+0xc8/0x1e0
> [   21.045596]  SyS_write+0x46/0xa0
> [   21.046207]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> [   21.046926] RIP: 0033:0x7f7a0064a720
> [   21.047560] RSP: 002b:7ffc8f5bb688 EFLAGS: 0246 ORIG_RAX:
> 0001
> [   21.048811] RAX: ffda RBX: 0001 RCX:
> 7f7a0064a720
> [   21.049723] RDX: 0001 RSI: 0060c400 RDI:
> 0001
> [   21.050636] RBP: 7f7a00907683 R08: 7f7a00908760 R09:
> 7f7a00907600
> [   21.051554] R10: 7ffc8f5bb708 R11: 0246 R12:
> 0001
> [   21.052471] R13: 0001 R14: 7f7a00907600 R15:
> 0001
> [   21.053383] handlers:
> [   21.053913] [] serial8250_interrupt
> [   21.054662] Disabling IRQ #3
> 
> Fengguang

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Andy Shevchenko 
On Tue, 2017-11-21 at 21:31 +0800, Fengguang Wu wrote:
> On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:
> > Hello,
> > 
> > FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
> > It shows up since v4.13 .
> 
> Sorry it actually also shows up in 4.10:

This one means that interrupt storm is occurred. Last time I saw that
was by the fact of some specific IOAPIC configuration when DMA for UART
was enabled.

I'm pretty sure that is not the case here. Though, it would be nice to
see link to the following files:

1. % acpidump -o tables.dat # tables.dat is point of interest
2. % lspci -vv -nk # output of the command
3. % dmidecode # output of the command
4. % grep -H 15 /sys/bus/acpi/devices/*/status # output of the command
5. % dmesg # when kernel command line has the 'ignore_loglevel
initcall_debug' added

Also 
% cat /proc/interrupts # if possible in both working / non-working cases


> /pkg/linux/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-
> 6/c470abd4fde40ea6a0846a2beab642a578c0b8cd/dmesg-vm-lkp-hsw01-4G-
> 1:20171110043200:x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED:4.10.0:1
> 
> [   19.902933]
> [   19.904514]
> [   19.904515]
> [   21.020567] irq 3: nobody cared (try booting with the "irqpoll"
> option)
> [   21.021466] CPU: 0 PID: 4094 Comm: dmesg Not tainted 4.10.0 #1
> [   21.022276] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996),
> BIOS 1.10.2-1 04/01/2014
> [   21.023584] Call Trace:
> [   21.024126]  
> [   21.025622]  dump_stack+0x63/0x8a
> [   21.026238]  __report_bad_irq+0x35/0xc0
> [   21.026890]  note_interrupt+0x234/0x270
> [   21.027548]  handle_irq_event_percpu+0x45/0x60
> [   21.028249]  handle_irq_event+0x42/0x70
> [   21.028901]  handle_edge_irq+0x74/0x140
> [   21.029560]  handle_irq+0x73/0x120
> [   21.030177]  ? irq_exit+0x6a/0xf0
> [   21.030794]  do_IRQ+0x46/0xd0
> [   21.031380]  common_interrupt+0x8e/0x8e
> [   21.032042] RIP: 0010:_raw_spin_unlock_irqrestore+0x15/0x30
> [   21.032831] RSP: 0018:c90002d9fd28 EFLAGS: 0286 ORIG_RAX:
> ffcc
> [   21.034081] RAX: 0001 RBX: 82362ee8 RCX:
> 
> [   21.034999] RDX: 02f9 RSI: 0286 RDI:
> 0286
> [   21.035914] RBP: c90002d9fd28 R08: 0004 R09:
> 88012e6dfc38
> [   21.036826] R10: 7ffc8f5bb708 R11: 88007f542580 R12:
> 88007fd51c00
> [   21.037742] R13: 0286 R14: c900031672a0 R15:
> 0001
> [   21.038654]  
> [   21.039171]  uart_start+0x73/0xe0
> [   21.039783]  uart_flush_chars+0xe/0x10
> [   21.040430]  n_tty_write+0x231/0x450
> [   21.041068]  ? __wake_up_sync+0x20/0x20
> [   21.041721]  tty_write+0x1ab/0x330
> [   21.042346]  ? n_tty_open+0xd0/0xd0
> [   21.042972]  __vfs_write+0x28/0x140
> [   21.043602]  ? security_file_permission+0x3b/0xc0
> [   21.044326]  ? rw_verify_area+0x4e/0xb0
> [   21.044977]  vfs_write+0xc8/0x1e0
> [   21.045596]  SyS_write+0x46/0xa0
> [   21.046207]  entry_SYSCALL_64_fastpath+0x1a/0xa9
> [   21.046926] RIP: 0033:0x7f7a0064a720
> [   21.047560] RSP: 002b:7ffc8f5bb688 EFLAGS: 0246 ORIG_RAX:
> 0001
> [   21.048811] RAX: ffda RBX: 0001 RCX:
> 7f7a0064a720
> [   21.049723] RDX: 0001 RSI: 0060c400 RDI:
> 0001
> [   21.050636] RBP: 7f7a00907683 R08: 7f7a00908760 R09:
> 7f7a00907600
> [   21.051554] R10: 7ffc8f5bb708 R11: 0246 R12:
> 0001
> [   21.052471] R13: 0001 R14: 7f7a00907600 R15:
> 0001
> [   21.053383] handlers:
> [   21.053913] [] serial8250_interrupt
> [   21.054662] Disabling IRQ #3
> 
> Fengguang

-- 
Andy Shevchenko 
Intel Finland Oy

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Fengguang Wu 

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:

Hello,

FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
It shows up since v4.13 .


Sorry it actually also shows up in 4.10:

/pkg/linux/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-6/c470abd4fde40ea6a0846a2beab642a578c0b8cd/dmesg-vm-lkp-hsw01-4G-1:20171110043200:x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED:4.10.0:1

[   19.902933]
[   19.904514]
[   19.904515]
[   21.020567] irq 3: nobody cared (try booting with the "irqpoll" option)
[   21.021466] CPU: 0 PID: 4094 Comm: dmesg Not tainted 4.10.0 #1
[   21.022276] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   21.023584] Call Trace:
[   21.024126]  
[   21.025622]  dump_stack+0x63/0x8a
[   21.026238]  __report_bad_irq+0x35/0xc0
[   21.026890]  note_interrupt+0x234/0x270
[   21.027548]  handle_irq_event_percpu+0x45/0x60
[   21.028249]  handle_irq_event+0x42/0x70
[   21.028901]  handle_edge_irq+0x74/0x140
[   21.029560]  handle_irq+0x73/0x120
[   21.030177]  ? irq_exit+0x6a/0xf0
[   21.030794]  do_IRQ+0x46/0xd0
[   21.031380]  common_interrupt+0x8e/0x8e
[   21.032042] RIP: 0010:_raw_spin_unlock_irqrestore+0x15/0x30
[   21.032831] RSP: 0018:c90002d9fd28 EFLAGS: 0286 ORIG_RAX: 
ffcc
[   21.034081] RAX: 0001 RBX: 82362ee8 RCX: 
[   21.034999] RDX: 02f9 RSI: 0286 RDI: 0286
[   21.035914] RBP: c90002d9fd28 R08: 0004 R09: 88012e6dfc38
[   21.036826] R10: 7ffc8f5bb708 R11: 88007f542580 R12: 88007fd51c00
[   21.037742] R13: 0286 R14: c900031672a0 R15: 0001
[   21.038654]  
[   21.039171]  uart_start+0x73/0xe0
[   21.039783]  uart_flush_chars+0xe/0x10
[   21.040430]  n_tty_write+0x231/0x450
[   21.041068]  ? __wake_up_sync+0x20/0x20
[   21.041721]  tty_write+0x1ab/0x330
[   21.042346]  ? n_tty_open+0xd0/0xd0
[   21.042972]  __vfs_write+0x28/0x140
[   21.043602]  ? security_file_permission+0x3b/0xc0
[   21.044326]  ? rw_verify_area+0x4e/0xb0
[   21.044977]  vfs_write+0xc8/0x1e0
[   21.045596]  SyS_write+0x46/0xa0
[   21.046207]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   21.046926] RIP: 0033:0x7f7a0064a720
[   21.047560] RSP: 002b:7ffc8f5bb688 EFLAGS: 0246 ORIG_RAX: 
0001
[   21.048811] RAX: ffda RBX: 0001 RCX: 7f7a0064a720
[   21.049723] RDX: 0001 RSI: 0060c400 RDI: 0001
[   21.050636] RBP: 7f7a00907683 R08: 7f7a00908760 R09: 7f7a00907600
[   21.051554] R10: 7ffc8f5bb708 R11: 0246 R12: 0001
[   21.052471] R13: 0001 R14: 7f7a00907600 R15: 0001
[   21.053383] handlers:
[   21.053913] [] serial8250_interrupt
[   21.054662] Disabling IRQ #3

Fengguang

Re: [serial8250_interrupt] RIP: 0010:arch_local_irq_restore+0x2/0x8

2017-11-21 Thread Fengguang Wu 

On Tue, Nov 21, 2017 at 08:33:57PM +0800, Fengguang Wu wrote:

Hello,

FYI this happens in mainline kernel 4.14.0-02748-gabc36be.
It shows up since v4.13 .


Sorry it actually also shows up in 4.10:

/pkg/linux/x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED/gcc-6/c470abd4fde40ea6a0846a2beab642a578c0b8cd/dmesg-vm-lkp-hsw01-4G-1:20171110043200:x86_64-rhel-7.2+CONFIG_DEBUG_INFO_REDUCED:4.10.0:1

[   19.902933]
[   19.904514]
[   19.904515]
[   21.020567] irq 3: nobody cared (try booting with the "irqpoll" option)
[   21.021466] CPU: 0 PID: 4094 Comm: dmesg Not tainted 4.10.0 #1
[   21.022276] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.10.2-1 04/01/2014
[   21.023584] Call Trace:
[   21.024126]  
[   21.025622]  dump_stack+0x63/0x8a
[   21.026238]  __report_bad_irq+0x35/0xc0
[   21.026890]  note_interrupt+0x234/0x270
[   21.027548]  handle_irq_event_percpu+0x45/0x60
[   21.028249]  handle_irq_event+0x42/0x70
[   21.028901]  handle_edge_irq+0x74/0x140
[   21.029560]  handle_irq+0x73/0x120
[   21.030177]  ? irq_exit+0x6a/0xf0
[   21.030794]  do_IRQ+0x46/0xd0
[   21.031380]  common_interrupt+0x8e/0x8e
[   21.032042] RIP: 0010:_raw_spin_unlock_irqrestore+0x15/0x30
[   21.032831] RSP: 0018:c90002d9fd28 EFLAGS: 0286 ORIG_RAX: 
ffcc
[   21.034081] RAX: 0001 RBX: 82362ee8 RCX: 
[   21.034999] RDX: 02f9 RSI: 0286 RDI: 0286
[   21.035914] RBP: c90002d9fd28 R08: 0004 R09: 88012e6dfc38
[   21.036826] R10: 7ffc8f5bb708 R11: 88007f542580 R12: 88007fd51c00
[   21.037742] R13: 0286 R14: c900031672a0 R15: 0001
[   21.038654]  
[   21.039171]  uart_start+0x73/0xe0
[   21.039783]  uart_flush_chars+0xe/0x10
[   21.040430]  n_tty_write+0x231/0x450
[   21.041068]  ? __wake_up_sync+0x20/0x20
[   21.041721]  tty_write+0x1ab/0x330
[   21.042346]  ? n_tty_open+0xd0/0xd0
[   21.042972]  __vfs_write+0x28/0x140
[   21.043602]  ? security_file_permission+0x3b/0xc0
[   21.044326]  ? rw_verify_area+0x4e/0xb0
[   21.044977]  vfs_write+0xc8/0x1e0
[   21.045596]  SyS_write+0x46/0xa0
[   21.046207]  entry_SYSCALL_64_fastpath+0x1a/0xa9
[   21.046926] RIP: 0033:0x7f7a0064a720
[   21.047560] RSP: 002b:7ffc8f5bb688 EFLAGS: 0246 ORIG_RAX: 
0001
[   21.048811] RAX: ffda RBX: 0001 RCX: 7f7a0064a720
[   21.049723] RDX: 0001 RSI: 0060c400 RDI: 0001
[   21.050636] RBP: 7f7a00907683 R08: 7f7a00908760 R09: 7f7a00907600
[   21.051554] R10: 7ffc8f5bb708 R11: 0246 R12: 0001
[   21.052471] R13: 0001 R14: 7f7a00907600 R15: 0001
[   21.053383] handlers:
[   21.053913] [] serial8250_interrupt
[   21.054662] Disabling IRQ #3

Fengguang