Bug 4052

Summary: X can not startup on qemumips
Product: [Runtime] General Runtime Reporter: Yi Zhao <yi.zhao>
Component: General RuntimeAssignee: Bruce Ashfield <bruce.ashfield>
Status: RESOLVED FIXED QA Contact:
Severity: major    
Priority: Medium+ CC: alexandru.damian, corneliux.stoicescu, laurentiu.palcu, ning.zhang, Qi.Chen, raj.khem, richard.purdie, sgw
Version: 1.4   
Target Milestone: 1.4 M6   
Hardware: x86   
OS: Multiple   
Whiteboard:
OS type for building Yocto: --- Type of Regression: ---
Verified: Documentation change: ---
Attachments:
Description Flags
Xorg.0.log
none
message
none
message with kernel error none

Description Yi Zhao 2013-03-19 06:58:36 UTC
Created attachment 1118 [details]
Xorg.0.log

Image location: http://autobuilder.yoctoproject.org/pub/nightly/20130313-3

Branch: poky/master
Git rev: 4da406cd50cf02a63ed76810a670aba1eb561c79

The X can not startup on qemumips. Here are some error messages in Xorg.0.log
###########
[2170525.012] (EE) Failed to load module "glx" (module does not exist, 0)
[2170527.949] (EE) evdev: Generic Keyboard: Unable to open evdev device "/dev/input/by-path/platform-i8042-serio-0-event-kbd".
[2170527.950] (EE) PreInit returned 2 for "Generic Keyboard"
[2170527.951] (EE) evdev: Qemu Tablet: Unable to open evdev device "/dev/input/touchscreen0".
[2170527.951] (EE) PreInit returned 2 for "Qemu Tablet"
###########

I attached the full log of message and Xorg.0.log
Comment 1 Yi Zhao 2013-03-19 06:59:20 UTC
Created attachment 1119 [details]
message
Comment 2 Yi Zhao 2013-03-19 07:03:45 UTC
Created attachment 1120 [details]
message with kernel error

Sometimes the kernel printed some error messages:
############
Mar 19 06:48:05 qemumips user.warn kernel: Reserved instruction in kernel code[#1]:
Mar 19 06:48:05 qemumips user.warn kernel: Cpu 0
Mar 19 06:48:05 qemumips user.warn kernel: $ 0   : 00000000 c0029eb8 00000008 c0028000
Mar 19 06:48:05 qemumips user.warn kernel: $ 4   : 86cb54f0 a08bb480 ffffffff 00000000
Mar 19 06:48:05 qemumips user.warn kernel: $ 8   : 008ba270 804c8a70 00001000 00000001
Mar 19 06:48:05 qemumips user.warn kernel: $12   : 00000000 ffffffff 00000001 6e706172
Mar 19 06:48:05 qemumips user.warn kernel: $16   : 00000006 86d68780 3000a401 86cb5400
Mar 19 06:48:05 qemumips user.warn kernel: $20   : 8515bc00 00000001 a08bb480 00000003
Mar 19 06:48:05 qemumips user.warn kernel: $24   : 00000002 804805a8    
Mar 19 06:48:05 qemumips user.warn kernel: $28   : 86c14000 86c15bd8 86cb54f0 c002e08c
Mar 19 06:48:05 qemumips user.warn kernel: Hi    : 00000423
Mar 19 06:48:05 qemumips user.warn kernel: Lo    : 020c4d59
Mar 19 06:48:05 qemumips user.warn kernel: epc   : c0028000 uhci_check_bandwidth+0x0/0x160 [uhci_hcd]
Mar 19 06:48:05 qemumips user.warn kernel:     Not tainted
Mar 19 06:48:05 qemumips user.warn kernel: ra    : c002e08c uhci_urb_enqueue+0xba4/0xc48 [uhci_hcd]
Mar 19 06:48:05 qemumips user.warn kernel: Status: 3000a402    KERNEL EXL 
Mar 19 06:48:05 qemumips user.warn kernel: Cause : 90800028
Mar 19 06:48:05 qemumips user.warn kernel: PrId  : 00019300 (MIPS 24Kc)
Mar 19 06:48:05 qemumips user.warn kernel: Modules linked in: i2c_piix4 uhci_hcd i2c_core
Mar 19 06:48:05 qemumips user.warn kernel: Process Xorg (pid: 172, threadinfo=86c14000, task=87dd49b0, tls=77206490)
Mar 19 06:48:05 qemumips user.warn kernel: Stack : 000200da 00000000 00000000 802223a4 86cb54f0 00000041 00000001 00000002
Mar 19 06:48:05 qemumips user.warn kernel:         81081e60 81143798 87c04c00 80226204 1000a401 80224c18 808b7530 00000020
Mar 19 06:48:05 qemumips user.warn kernel:         86d68780 86cb5400 00000000 86d68788 000000d0 86d5ce3c 80233110 86c15e78
Mar 19 06:48:05 qemumips user.warn kernel:         00000000 8058092c 86c0f000 000000d0 00000000 81081e60 87fcdbc4 00000002
Mar 19 06:48:05 qemumips user.warn kernel:         00000000 00000002 00000000 87fcdbc4 00000000 86d5e400 86d5e4d8 86d5ce04
Mar 19 06:48:05 qemumips user.warn kernel:         ...
Mar 19 06:48:05 qemumips user.warn kernel: Call Trace:
Mar 19 06:48:05 qemumips user.warn kernel: [<c0028000>] uhci_check_bandwidth+0x0/0x160 [uhci_hcd]
Mar 19 06:48:05 qemumips user.warn kernel: [<c002e08c>] uhci_urb_enqueue+0xba4/0xc48 [uhci_hcd]
Mar 19 06:48:05 qemumips user.warn kernel: [<8058092c>] usb_hcd_submit_urb+0xdc/0x848
Mar 19 06:48:05 qemumips user.warn kernel: [<805b8fbc>] wacom_open+0x44/0x8c
Mar 19 06:48:05 qemumips user.warn kernel: [<805a1990>] input_open_device+0xac/0xec
Mar 19 06:48:05 qemumips user.warn kernel: [<805a8cec>] evdev_open+0x188/0x1bc
Mar 19 06:48:05 qemumips user.warn kernel: [<802331d8>] chrdev_open+0xc8/0x1c4
Mar 19 06:48:05 qemumips user.warn kernel: [<8022b338>] do_dentry_open+0x248/0x2e4
Mar 19 06:48:05 qemumips user.warn kernel: [<8022b418>] finish_open+0x44/0x68
Mar 19 06:48:05 qemumips user.warn kernel: [<8023e51c>] do_last.isra.29+0x2c0/0xcbc
Mar 19 06:48:05 qemumips user.warn kernel: [<8023efd8>] path_openat+0xc0/0x52c
Mar 19 06:48:05 qemumips user.warn kernel: [<8023f840>] do_filp_open+0x4c/0xbc
Mar 19 06:48:05 qemumips user.warn kernel: [<8022cc3c>] do_sys_open+0x128/0x20c
Mar 19 06:48:05 qemumips user.warn kernel: [<8010c07c>] stack_done+0x20/0x44
Mar 19 06:48:05 qemumips user.warn kernel: Code: (Bad address in epc)
Mar 19 06:48:05 qemumips user.warn kernel: ---[ end trace 8a48c6046870f8c2 ]---
Mar 19 06:48:05 qemumips user.info kernel: note: Xorg[172] exited with preempt_count 1
#############
Comment 3 Stoicescu Cornel 2013-04-04 11:35:58 UTC
This issue is present on qemux86-64 master:bdca49274173153b1b0a72887de6321b4756b684
Comment 4 Laurentiu Palcu 2013-04-04 12:08:34 UTC
(In reply to comment #3)
> This issue is present on qemux86-64
> master:bdca49274173153b1b0a72887de6321b4756b684

FYI, the issue you're referring to was already fixed on master [1] and is not related to this one.

[1] http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=9915f945c904fd7664d073421b803fd1c672c324
Comment 5 Alexandru Damian 2013-04-08 08:18:25 UTC
The root cause is ftrace inserting invalid instructions.

The workaround is disabling CONFIG_DYNAMIC_FTRACE, which is the easy one.

The proper fix would be fixing mips32 tracing, which seems difficult enough that experienced mips guys can't make it right. See arch/mips/kernel/ftrace.c

Bruce, can you please take a look and see what suits you ?
Comment 6 Bruce Ashfield 2013-04-08 12:39:43 UTC
I've just fixed (and queued) a similar issue for mips64.

------------------
commit eb6cb79808d7dc6535a71e5386f26c0abdaa1fb4
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Thu Apr 4 23:39:57 2013 -0400

    Revert "MIPS: Function tracer: Fix broken function tracing"
    
    This reverts commit 58b69401c797e470c8f638c598dddc44a4ce8a96.

:100644 100644 83fa146... 6a2d758... M  arch/mips/kernel/ftrace.c
:100644 100644 1658676... 4c968e7... M  arch/mips/kernel/mcount.S
------------------

Can you try reverting that same commit on your local kernel and see if it helps ?
I'm investigating two other bugs at the moment and it would really help if you can
try this on my behalf.

I'll take care of getting it into the linux-yocto tree if it fixes. the problem.
Comment 7 Alexandru Damian 2013-04-08 13:58:09 UTC
tested with 58b69401c797e470c8f638c598dddc44a4ce8a96 reverted, does not start at all.

I added the patch below to test, it works ok, I suggest using it.

diff --git a/arch/mips/kernel/ftrace.c b/arch/mips/kernel/ftrace.c
index 83fa146..2a988d9 100644
--- a/arch/mips/kernel/ftrace.c
+++ b/arch/mips/kernel/ftrace.c
@@ -100,6 +100,7 @@ static int ftrace_modify_code_2(unsigned long ip, unsigned int new_code1,
                                unsigned int new_code2)
 {
        int faulted;
+       return 0;
 
        safe_store_code(new_code1, ip, faulted);
        if (unlikely(faulted))
Comment 8 Bruce Ashfield 2013-04-08 14:00:54 UTC
Heh. No, we won't insert a return 0 into the code as a fix. 

I'll have to try my own boot tests today, since the revert really should fix the problem, as I've
been booting qemumips with X enabled for a while with my staged / pending kernel tree.

If the revert isn't working, then I'll simply disable the config.
Comment 9 Alexandru Damian 2013-04-08 14:04:18 UTC
I'm testing now just the config disable, I'll let you know how it goes.
Comment 10 Bruce Ashfield 2013-04-08 14:06:18 UTC
(In reply to comment #9)
> I'm testing now just the config disable, I'll let you know how it goes.

Sounds good. I'm doing a sato build, and will try the revert myself, and attempt to bisect the failure if
it doesn't fix the problem. But disabling the config is our fallback position, and your confirmation will
be very helpful.
Comment 11 Alexandru Damian 2013-04-08 15:30:00 UTC
Disabling CONFIG_DYNAMIC_FTRACE leads to building problems - ifdefs are not correctly defined.

I'd look into either fixing these, or the horrible return 0 hack.
Comment 12 Bruce Ashfield 2013-04-08 17:48:16 UTC
I'm seeing wildly different behaviour with qemu mips as I jump through revisions
since v3.4. Everything from silent boot death to graphics issues. In fact, 3.8 with
my pending config tweaks is better than anything since 3.4.

Has this really just started happening ? I tested the initial uprev, and it worked, and
3.8 has been the default for quit some time.

I'm trying to figure out what else may have changed that could trigger this.

And finally, if someone can try and fix the build failure with ftrace disabled, that
will be useful, since I'm busy bisecting the kernel build and need some help tasking
it in.
Comment 13 Bruce Ashfield 2013-04-08 20:29:45 UTC
The breakage for this seems to have happened some time ago, in fact, it looks
like the 3.5 timeframe. 

I've built and booted sato about 15 times with the following revert:

commit 0ec615c31233b8cce72242329a2e008e1101524e
Author: Bruce Ashfield <bruce.ashfield@windriver.com>
Date:   Mon Apr 8 12:57:18 2013 -0700

    Revert "ftrace/x86: Have x86 ftrace use the ftrace_modify_all_code()"
    
    This reverts commit e4f5d5440bb860a3e8942ca8f7277a7f31798965.

-----------------------

on standard/mti-malta32

It would be good to hear what it does for other people's boards.
Comment 14 Bruce Ashfield 2013-04-09 16:41:45 UTC
did anyone else try a boot with the last revert I posted ? It works for me here, but
we want more confirmation than just my single test.
Comment 15 Alexandru Damian 2013-04-10 11:07:25 UTC
I still verify the crash with patch e4f5d5440bb860a3e8942ca8f7277a7f31798965 reverted.

Can you please push your kernel head to a contrib branch ?
Comment 16 Bruce Ashfield 2013-04-10 12:45:21 UTC
Everything was pushed last night, see zedd/kernel-aufs off contrib. Take all the commits.

Bruce
Comment 17 Alexandru Damian 2013-04-10 14:44:48 UTC
I still reproduce the crash with the zedd/kernel-aufs branch.

I recommend the "return 0;"  patch, however ugly it is.
Comment 18 Bruce Ashfield 2013-04-10 14:48:17 UTC
We aren't going with return 0, we have to have some pride in our work.
Work on the compile failure with the config item turned off, we don't
stub out code.

This has booted 50 or 60 times here, so continuing to point the finger at
the kernel only .. isn't constructive. There is something else going on here,
we need the root cause of why my runs are different than yours.
Comment 19 Alexandru Damian 2013-04-10 14:52:41 UTC
Per Richard's suggestion, the right way to test this bug is to boot qemu with serial console, and watch the log/dmesg out for a Reserved instruction crash.


The image will boot to graphical display, but no interaction is possible due to the kernel crash. Please follow the dumps above.
Comment 20 Bruce Ashfield 2013-04-10 14:54:21 UTC
Do you really think that I haven't booted to the prompt as many times as the graphical shell ? :)
That works just as well, and is something that I do constantly.
Comment 21 Bruce Ashfield 2013-04-10 15:25:09 UTC
Just logging my build from this morning, sato image, nographic boot to prompt:

root@qemumips:~# uname -a
Linux qemumips 3.8.4-yocto-standard #1 PREEMPT Wed Apr 10 08:00:31 PDT 2013 mips GNU/Linux
root@qemumips:~# dmesg | grep Reserv
root@qemumips:~# 

The summary is that I'm not seeing the Reserved instructions during boot. I'll move to graphical boot now.
Comment 22 Bruce Ashfield 2013-04-10 19:38:26 UTC
Update: we've worked around the problem by building ECHI into the kernel for now. X is
up, mouse works, but no keyboard.

As my bisects were showing, and Alexandru's investigation, this does come back to ftrace
patching module code incorrectly. There's an interaction between the prologue, the module
loader and ftrace. We can completely disable FTRACE as another option, but that only
masks the problem, and has the same result as building the module in (X boots, no
keyboard). 

We do need to fix FTRACE, but that's going to be in a point release. 

The keyboard is a separate issue, and I'd suggest that it isn't related to the same symptom
and a new bug be opened to track it.
Comment 23 Richard Purdie 2013-04-11 11:40:09 UTC
Everything appears fixed by http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=4c02dd5f6432c6e683a57d47b610f56433e9ca0d (there were several issues, the ftrace issue breaking kernel modules, the superio being missing breaking the keyboard and likely configu issues breaking the graphics). All of these seem resolved as of the above commit.