Cannot boot trusty kernel on qemu-system-arm

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

apport-collect 1303657

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.

Looks like the lp helper script got confused; logs were already attached from apport-bug. Overriding.

BTW, I removed u-boot from the situation and tried booting 3.13.0-23-generic directly from qemu-system-arm, same result. I have not yet been able to get 3.13.0-23-generic to boot.

Can you follow the "Boot options" instructions on the following wiki to enable additional output on boot:

https://wiki.ubuntu.com/DebuggingKernelBoot

As mentioned on the wiki, it would be great if you can attach a log file which may have captured any messages you see. If you are unable to capture a log file, a digital photo will work just as well. As a last resort you can even copy messages down by hand.

Also, will the machine boot if you select the 3.13.0-22 kernel from GRUB?

The only option on https://wiki.ubuntu.com/DebuggingKernelBoot of relevance to booting an ARM kernel in QEMU is the "debug" flag, which doesn't change anything. The u-boot output is in the original report; when booting through u-boot, it CPU spins after "Starting kernel ...". When booting the kernel directly from qemu-system-arm, there is literally no output.

I don't have access to 3.13.0-22, it was a d-r-u from saucy to trusty this weekend. I was referring to the difference between the saucy kernel line (3.11) and the trusty kernel line (3.13). I'm compiling an armhf kernel from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/ to test vanilla, but this is going to take a very long time.

FWIW, I was not able to compile the armhf package from http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.14-trusty/:

  CC [M] drivers/gpu/drm/msm/msm_drv.o
  CC [M] drivers/gpu/drm/msm/msm_fb.o
  CC [M] drivers/gpu/drm/msm/msm_gem.o
  CC [M] drivers/gpu/drm/msm/msm_gem_prime.o
  CC [M] drivers/gpu/drm/msm/msm_gem_submit.o
  CC [M] drivers/gpu/drm/msm/msm_gpu.o
  CC [M] drivers/gpu/drm/msm/msm_iommu.o
  CC [M] drivers/gpu/drm/msm/msm_ringbuffer.o
  CC [M] drivers/gpu/drm/msm/msm_fbdev.o
  LD [M] drivers/gpu/drm/msm/msm.o
drivers/gpu/drm/msm/hdmi/hdmi.o: In function `.LANCHOR2':
hdmi.c:(.rodata+0x10): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/msm/adreno/a3xx_gpu.o:a3xx_gpu.c:(.rodata+0x4e8): first defined here
drivers/gpu/drm/msm/msm_drv.o: In function `.LANCHOR0':
msm_drv.c:(.rodata+0x20c): multiple definition of `__mod_of_device_table'
drivers/gpu/drm/msm/adreno/a3xx_gpu.o:a3xx_gpu.c:(.rodata+0x4e8): first defined here
make[6]: *** [drivers/gpu/drm/msm/msm.o] Error 1
make[5]: *** [drivers/gpu/drm/msm] Error 2
make[4]: *** [drivers/gpu/drm] Error 2
make[3]: *** [drivers/gpu] Error 2
make[2]: *** [drivers] Error 2
make[1]: *** [sub-make] Error 2
make[1]: Leaving directory `/home/ryan/v3.14-trusty/linux-3.14'
make: *** [/home/ryan/v3.14-trusty/linux-3.14/debian/stamps/stamp-build-generic] Error 2
dpkg-buildpackage: error: debian/rules build gave error exit status 2
debuild: fatal error at line 1364:
dpkg-buildpackage -rfakeroot -D -us -uc failed

real 447m6.844s
user 385m56.960s
sys 36m20.700s

Recent distros can silently hang due to insufficient RAM while decompressing
kernel image. Did you give enough RAM?

can you try this kernel?

http://people.canonical.com/~ppisati/1303657/linux-image-3.13.0-24-generic_3.13.0-24.46~hvcdcc_armhf.deb

moreover, there's a dtb for this "board" at: /lib/firmware/3.13.0-24-generic/device-tree/vexpress-v2p-ca9.dtb

i added the dtb to the archive, and disable the "console via JTAG" that already gave us problem in the past - that should make it.

linux-image-3.13.0-24-generic_3.13.0-24.46~hvcdcc_armhf.deb verified as working, both directly and via u-boot, thank you.

And thanks for including the DTB in the package now. I was using vexpress-v2p-ca9.dtb, but IIRC I compiled it from vanilla sometime last year.

This bug was fixed in the package linux - 3.13.0-24.46

---------------
linux (3.13.0-24.46) trusty; urgency=low

  [ Andy Whitcroft ]

  * [Config] d-i -- add nvme devices to block-modules udeb
    - LP: #1303710

  [ Paolo Pisati ]

  * [Config] build vexpress a9 dtb
    - LP: #1303657
  * [Config] disable HVC_DCC
    - LP: #1303657

  [ Tim Gardner ]

  * Release Tracking Bug
    - LP: #1305158
  * rebase to v3.13.9
  * CONFIG_RTLBTCOEXIST=m
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * HID: Bluetooth: hidp: make sure input buffers are big enough
    - LP: #1252874
  * ACPI / video: Add systems that should favour native backlight interface
    - LP: #1303419
  * rds: prevent dereference of a NULL device in rds_iw_laddr_check
    - LP: #1302222
    - CVE-2014-2678
  * x86/efi: Fix 32-bit fallout
    - LP: #1301590
  * drm/nouveau/devinit: tidy up the subdev class definition
    - LP: #1158689
  * drm/nouveau/device: provide a way for devinit to mark engines as
    disabled
    - LP: #1158689
  * drm/nv50-/devinit: prevent use of engines marked as disabled by
    hw/vbios
    - LP: #1158689
  * rtlwifi: btcoexist: Add new mini driver
    - LP: #1296591
  * rtlwifi: Prepare existing drivers for new driver
    - LP: #1296591
  * rtlwifi: add MSI interrupts mode support
    - LP: #1296591
  * rtlwifi: rtl8188ee: enable MSI interrupts mode
    - LP: #1296591

  [ Upstream Kernel Changes ]

  * rebase to v3.13.9
 -- Tim Gardner <email address hidden> Fri, 04 Apr 2014 09:26:27 -0400