Red Hat Bugzilla – Full Text Bug Listing
|Summary:||qemu-system-arm vexpress-* want CONFIG_FB_ARMCLCD=y|
|Product:||[Fedora] Fedora||Reporter:||Paul Whalen <pwhalen>|
|Component:||kernel||Assignee:||Kernel Maintainer List <kernel-maint>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||20||CC:||amit.shah, berrange, cfergeau, crobinso, dracut-maint, dwmw2, gansalmon, itamar, jonathan, kernel-maint, kmcmartin, madhu.chinakonda, mr.marcelo.barbosa, pbonzini, pbrobinson, pwhalen, rjones, scottt.tw, virt-maint|
|Fixed In Version:||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2014-02-24 10:31:10 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
|Bug Depends On:|
Description Paul Whalen 2013-04-25 11:07:13 EDT
Description of problem: When lauching qemu-system-arm with graphics, the display window opens with a black screen. Version-Release number of selected component (if applicable): This is present in both qemu-system-arm-1.2.2-11.fc18.x86_64 and qemu-system-arm-1.4.0-9.fc19.x86_64 . How reproducible: All 3.8+ kernels, using a DTB. Steps to Reproduce: 1. Download the vexpress image from: http://dl.fedoraproject.org/pub/fedora-secondary/releases/18/Images/armhfp/Fedora-18-vexpress-xfce-armhfp.tar.xz 2. Boot using the provided boot script and upgrade to a 3.8+ kernel, copy kernel, initramfs and dtb folder from '/boot' to your host machine, shutdown qemu. 3. Launch the new kernel in qemu-system-arm with '--gui' option. Actual results: Window opens with a black screen, no further output. Expected results: Window opens with Fedora and XFCE. Additional info: Command used in the bootscript: No Graphic: qemu-system-arm -machine vexpress-a9 -m 1024 -nographic -net nic -net user \ -append "console=ttyAMA0,115200n8 rw root=/dev/mmcblk0p3 rootwait physmap.enabled=0" \ -kernel "$KERN" \ -initrd "$RAMFS" \ -sd "$IMAGE" -dtb $FDTARG Graphics: qemu-system-arm -machine vexpress-a9 -m 1024 -net nic -net user \ -append "rw root=/dev/mmcblk0p3 rootwait physmap.enabled=0" \ -kernel "$KERN" \ -initrd "$RAMFS" \ -sd "$IMAGE" \ -dtb $FDTARG
Comment 1 Cole Robinson 2013-08-18 15:33:02 EDT
Peter, Paul, do you guys know if this is an actual qemu issue or an upstream kernel issue? This page mentions something about kernel reorg breaking display, but only when a device tree is explicitly passed in: https://fedoraproject.org/wiki/Architectures/ARM/F19/Installation#For_Versatile_Express_Emulation_with_QEMU Unfortunately that's required to get virtio working. I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I can't get display to work regardless of passing in dtb. Any pointers? Maybe a thread to follow?
Comment 2 Peter Robinson 2013-08-19 07:16:00 EDT
> Peter, Paul, do you guys know if this is an actual qemu issue or an upstream > kernel issue? Unfortunately not. It works without a device tree, it doesn't work if you specify one. Who is at fault I'm not entirely certain. > This page mentions something about kernel reorg breaking display, but only > when a device tree is explicitly passed in: > > https://fedoraproject.org/wiki/Architectures/ARM/F19/ > Installation#For_Versatile_Express_Emulation_with_QEMU > > Unfortunately that's required to get virtio working. Is it possible to use a spice display with virtio instead of the other one (I don't remember off hand what we use to use) > I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I > can't get display to work regardless of passing in dtb. Any pointers? Maybe > a thread to follow? Paul will be able to spread more light on this.
Comment 3 Paul Whalen 2013-08-19 10:43:16 EDT
(In reply to Cole Robinson from comment #1) > Peter, Paul, do you guys know if this is an actual qemu issue or an upstream > kernel issue? I believe I read something about the display implementation in the dtb still being worked on. I've CC'd Kyle who may have a better idea of whats happening. > I've tried qemu git with the stock F19 arm kernel, but nothing newer, and I > can't get display to work regardless of passing in dtb. Any pointers? Maybe > a thread to follow? Nothing beyond whats documented on the wiki. The display should work with 3.9, 3.10 kernels without a dtb.
Comment 4 Fedora End Of Life 2013-09-16 09:39:18 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle. Changing version to '20'. More information and reason for this action is here: https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 5 Cole Robinson 2013-10-10 15:06:00 EDT
Okay I poked into this a bit. I think this is just a Fedora kernel config issue: when the explicit config-arm-versatile was dropped, CONFIG_FB_ARMCLCD=y became CONFIG_FB_ARMCLCD=m. I confirmed that taking the current F20 arm config, building kernel 3.11 from git with only changing CONFIG_FB_ARMCLCD=y, qemu graphical output works as expected
Comment 6 Kyle McMartin 2013-10-10 15:07:37 EDT
This is an explicit decision... it should be in the dracut initrd so it's not pointlessly loaded on actual hardware. --Kyle
Comment 7 Cole Robinson 2013-10-10 15:19:53 EDT
(In reply to Kyle McMartin from comment #6) > This is an explicit decision... it should be in the dracut initrd so it's > not pointlessly loaded on actual hardware. > I'm ignorant here, but does that mean 'reassign', 'notabug', 'decision was deliberate but we need a fix somewhere else', or ... ?
Comment 8 Cole Robinson 2013-10-10 17:12:50 EDT
Created attachment 810777 [details] kernel-modules/module-setup.sh: add amba-clcd.ko on arm Kyle, I think this is what you meant. If so I'll forward it to upstream dracut
Comment 9 Peter Robinson 2013-10-11 04:02:47 EDT
ultimately if it's in the device tree it should be automatically detected/loaded and then just needs to be in the initrd to do so as early as possible
Comment 10 Justin M. Forbes 2014-02-24 08:57:06 EST
*********** MASS BUG UPDATE ************** We apologize for the inconvenience. There is a large number of bugs to go through and several of them have gone stale. Due to this, we are doing a mass bug update across all of the Fedora 20 kernel bugs. Fedora 20 has now been rebased to 3.13.4-200.fc20. Please test this kernel update and let us know if you issue has been resolved or if it is still present with the newer kernel. If you experience different issues, please open a new bug report for those.