Couple of kernel tracebacks

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi Bruce,

We are seeing a few teething issues which seem kernel related on the
autobuilder. The x86 lsb build saw this traceback in the logs:

Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c114998b>] do_wp_page+0x10b/0x670
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c104ee0c>] ? kmap_atomic_prot+0x3c/0xd0
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c114c2da>] handle_mm_fault+0x56a/0xb70
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c11526a2>] ? mprotect_fixup+0x122/0x230
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c10481d8>] __do_page_fault+0x238/0x4f0
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c115286e>] ? do_mprotect_pkey+0xbe/0x240
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c10484e4>] trace_do_page_fault+0x34/0x100
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c100196c>] ? do_int80_syscall_32+0x5c/0xc0
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c1044870>] ? kvm_pv_reboot_notify+0x30/0x30
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c10448c5>] do_async_page_fault+0x55/0x70
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c18bffc6>] error_code+0x5a/0x60
Aug 24 15:49:10 qemux86 kernel: [    8.965015]  [<c1044870>] ? kvm_pv_reboot_notify+0x30/0x30

https://autobuilder.yoctoproject.org/main/builders/nightly-x86-lsb/builds/1200/steps/Running%20Sanity%20Tests/logs/stdio

Sadly the logs were lost before I could get a full trace out of it.

I've also seen this locally on qemuppc:

         Starting Update UTMP about System Runlevel Changes...
[   25.580686] NFSD: Using /var/lib/nfs/v4recovery as the NFSv4 state recovery directory
[   25.602107] NFSD: starting 90-second grace period (net c0b04278)
[   26.388555] irq 36: nobody cared (try booting with the "irqpoll" option)
[   26.389018] CPU: 0 PID: 287 Comm: (agetty) Not tainted 4.12.7-yocto-standard #1
[   26.389339] Call Trace:
[   26.389845] [cff75f20] [c00873b0] __report_bad_irq.isra.0+0x40/0x14c (unreliable)
[   26.390319] [cff75f40] [c0087860] note_interrupt+0x320/0x374
[   26.390548] [cff75f70] [c0084650] handle_irq_event_percpu+0x60/0x7c
[   26.390783] [cff75f90] [c00846cc] handle_irq_event+0x60/0xac
[   26.391012] [cff75fa0] [c0088634] handle_fasteoi_irq+0xb8/0x274
[   26.391270] [cff75fc0] [c00831e8] generic_handle_irq+0x3c/0x58
[   26.391498] [cff75fd0] [c0007540] __do_irq+0x58/0x188
[   26.391698] [cff75ff0] [c0011298] call_do_irq+0x24/0x3c
[   26.391897] [c98c1b80] [c0007720] do_IRQ+0xb0/0x164
[   26.392135] [c98c1bb0] [c00142cc] ret_from_except+0x0/0x14
[   26.392407] --- interrupt: 501 at pmz_set_termios+0x140/0x6fc
[   26.392407]     LR = pmz_set_termios+0x100/0x6fc
[   26.392751] [c98c1ca0] [c053c95c] uart_change_speed.isra.2+0x58/0x19c
[   26.392991] [c98c1cc0] [c053d344] uart_startup.part.8+0xc0/0x1fc
[   26.393282] [c98c1ce0] [c0521ef8] tty_port_open+0xd8/0x174
[   26.393498] [c98c1d00] [c053b8e8] uart_open+0x44/0x60
[   26.393703] [c98c1d10] [c05199b0] tty_open+0x140/0x500
[   26.393910] [c98c1d60] [c01bd034] chrdev_open+0x104/0x244
[   26.394129] [c98c1d90] [c01b2548] do_dentry_open+0x26c/0x3bc
[   26.394365] [c98c1dc0] [c01ca03c] path_openat+0x588/0x11ec
[   26.394583] [c98c1e50] [c01cc134] do_filp_open+0x74/0xfc
[   26.394787] [c98c1f00] [c01b43f0] do_sys_open+0x1c0/0x270
[   26.395006] [c98c1f40] [c0013bb4] ret_from_syscall+0x0/0x38
[   26.395268] --- interrupt: c01 at 0xb77bf244
[   26.395268]     LR = 0xb77bf1f0
[   26.395524] handlers:
[   26.395671] [<c054075c>] pmz_interrupt
[   26.395865] Disabling IRQ #36

irq 36 is ttyS1. Not sure how to trigger this again :/.

We're also seeing qemuppc occasionally hang:

https://autobuilder.yoctoproject.org/main/builders/nightly-ppc/builds/1215/steps/Running%20Sanity%20Tests/logs/stdio
https://autobuilder.yocto.io/builders/nightly-ppc/builds/456
https://autobuilder.yocto.io/builders/nightly-ppc-lsb/builds/435/steps/Running%20Sanity%20Tests/logs/stdio

This has happened on multiple builders and on multiple images (sato,
sato-sdk and I think minimal). Could be the new kernel, could be qemu
:/. If has occurred on lsb and non-lsb ppc which makes it less kernel
version specific I guess. For some reason I keep wanting to blame the
IDE drivers but it is using virtio. We never get any backtrace for
this, the log just stop dead and then we hit timeouts, it never boots
fully in these cases. It stops after:

[    7.131438] udevd[105]: starting version 3.2.2
[    7.234086] udevd[106]: starting eudev-3.2.2

Mentioning this just in case you have any ideas...

Cheers,

Richard