Kernel hangs on wandboard (freescale imx6)

Bug #1237733 reported by Stéphane Graber
12
This bug affects 2 people
Affects Status Importance Assigned to Milestone
linux (Ubuntu)
Fix Released
High
Unassigned
Saucy
Won't Fix
Undecided
Unassigned
Trusty
Fix Released
High
Unassigned

Bug Description

I've been trying to use the generic kernel with my wandboard (based on a freescale imx6) as it's supposed to be working properly.

Using the Ubuntu generic kernel, I usually get a successful boot very shortly followed by a hang.
The hang is: http://paste.ubuntu.com/6216221
That's when using: vmlinuz-3.11.0-12-generic
dmesg for that kernel: http://paste.ubuntu.com/6216265/

Then I noticed that fedora's 3.11 kernel appears to work fine for me and is reasonably stable (though it lacks aufs and overlayfs which I kind of need since I use the board as a buildd).
The fedora kernel I'm using is: vmlinuz-3.11.0-armv7-x13
dmesg for that kernel: http://paste.ubuntu.com/6216246/

A config diff between the two gives me: http://paste.ubuntu.com/6216233/

I believe the git branch for the fedora kernel is at: http://pkgs.fedoraproject.org/cgit/kernel.git

Revision history for this message
Brad Figg (brad-figg) wrote : Missing required logs.

This bug is missing log files that will aid in diagnosing the problem. From a terminal window please run:

apport-collect 1237733

and then change the status of the bug to 'Confirmed'.

If, due to the nature of the issue you have encountered, you are unable to run this command, please add a comment stating that fact and change the bug status to 'Confirmed'.

This change has been made by an automated script, maintained by the Ubuntu Kernel Team.

Changed in linux (Ubuntu):
status: New → Incomplete
Revision history for this message
Stéphane Graber (stgraber) wrote :

There's no chance I can run apport on that machine since it hangs after a few seconds, it's already a miracle I can get a shell to last long enough to run dmesg :)

Changed in linux (Ubuntu):
status: Incomplete → Confirmed
Changed in linux (Ubuntu):
importance: Undecided → Medium
tags: added: saucy
Revision history for this message
Joseph Salisbury (jsalisbury) wrote :

Do you happen to know if there was a previous Ubuntu kernel version that boot fine on this board?

tags: added: kernel-da-key
Revision history for this message
Stéphane Graber (stgraber) wrote :

That's a good question, I'll try a 3.8 generic kernel to see. AFAIK that's the only other generic armhf kernel that we have around.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Just tried the latest 3.8 from raring-proposed. It won't boot at all, not getting a single kernel entry on the serial console.
Now looking for a 3.10 kernel from earlier in the saucy cycle.

Revision history for this message
Stéphane Graber (stgraber) wrote :

3.10 seems a bit better, at least the kernel loads and the initrd too, though it appears unable to mount the sdcard and so ends up stuck in the initrd after a bunch of mmc related printk.

So it looks like there's no Ubuntu kernel that works properly on this board.

Changed in linux (Ubuntu):
importance: Medium → High
Revision history for this message
Paolo Pisati (p-pisati) wrote :

where does the dtb reside in this case? mmc or flash?

in any case, try updating it with the last one that you can find in /lib/firmware/$kernel-version/device-tree/imx6q-sabrelite.dtb

Revision history for this message
Stéphane Graber (stgraber) wrote :

The dtb comes from mmc, I'm currently using one coming from the Ubuntu image for the wandboard linked from their website but I also tried the one from the current upstream kernel without seeing any difference in behaviour.

I didn't try any of those shipped with the 3.11 kernel since the imx6q-wandboard one didn't exist back then (was added to the tree shortly after 3.11 released) but I'll give imx6q-sabrelite.dtb a shot later today.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Just did a quick test now, the board won't boot the kernel at all using imx6q-sabrelite.dtb so it must be different enough from the wandboard dtb to confuse the kernel very early on.

Revision history for this message
Paolo Pisati (p-pisati) wrote :

can you try this kernel:

http://people.canonical.com/~ppisati/linux-image-3.11.0-13-generic_3.11.0-13.20~imx6wands_armhf.deb

and the most appropriate of those dtbs:

ubuntu@arm:~$ ll /lib/firmware/3.11.0-13-generic/device-tree/*wandboard*
-rw-r--r-- 1 root root 31367 Oct 16 10:30 /lib/firmware/3.11.0-13-generic/device-tree/imx6dl-wandboard.dtb
-rw-r--r-- 1 root root 33006 Oct 16 10:30 /lib/firmware/3.11.0-13-generic/device-tree/imx6q-wandboard.dtb

Revision history for this message
Stéphane Graber (stgraber) wrote :

So just to sumarize our IRC discussion. The dtb looks good and works great with the fedora kernel.
The kernel itself boots and gets me past the initrd but hangs randomly a bit later on (around network initialization time).

Revision history for this message
Paolo Pisati (p-pisati) wrote :

here is another kernel to test:

http://people.canonical.com/~ppisati/linux-image-3.11.0-13-generic_3.11.0-13.20~imx6wandsfullbspplusfedyopts_armhf.deb

moreover, if it hangs just after initrd, would you mind trying to boot without it? could be a buggy module that is loaded afterwards.

Revision history for this message
Stéphane Graber (stgraber) wrote :

Just reporting what I said on IRC, this kernel gives me a pretty similar behaviour to the previous one, that's, it hangs at boot around the time apparmor/networking loads and 1/3 times I get a kernel panic: http://paste.ubuntu.com/6251449/

Revision history for this message
Paolo Pisati (p-pisati) wrote :

while it's technically possible to make wandboard work with a saucy kernel, that takes ~40 patches.
On the other hand, T already have enough bits to make that board boots and work fine as a server: for theese reasons, i'm marking this as "won't fix' in S, and propose it for T.

Revision history for this message
Paolo Pisati (p-pisati) wrote :
Revision history for this message
Paolo Pisati (p-pisati) wrote :
tags: added: patch
Revision history for this message
Stéphane Graber (stgraber) wrote :

Yep, I'm fine with that. I had little hope this would be fixed for S and I wasn't planning on running S for very long on that board anyway, so T is fine for me.

Changed in linux (Ubuntu Saucy):
status: New → Won't Fix
Changed in linux (Ubuntu Trusty):
status: Confirmed → Triaged
Changed in linux (Ubuntu Trusty):
status: Triaged → Fix Released
Changed in linux (Ubuntu):
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.