Bug 862766

Summary: Hardcoded value for the initrd address overlaps the kernel address in qemu-system-arm.
Product: [Fedora] Fedora Reporter: Paul Whalen <pwhalen>
Component: qemuAssignee: Fedora Virtualization Maintainers <virt-maint>
Status: CLOSED CURRENTRELEASE QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: high Docs Contact:
Priority: high    
Version: 18CC: amit.shah, berrange, cfergeau, crobinso, dwmw2, itamar, knoel, pbonzini, pbrobinson, rjones, scottt.tw, virt-maint
Target Milestone: ---   
Target Release: ---   
Hardware: arm   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-11-02 20:07:33 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 245418    
Attachments:
Description Flags
qemu patch to change initrd load address when using qemu-system-arm none

Description Paul Whalen 2012-10-03 13:47:35 UTC 
Created attachment 620891 [details]
qemu patch to change initrd load address when using qemu-system-arm

Description of problem:

Because our kernels have grown in size, the hardcoded value for the initrd address overlaps the kernel address and an emulated ARM system will fail to boot. 

Version-Release number of selected component (if applicable):

All versions

How reproducible:

Everytime. 

Steps to Reproduce:
1. Create or use a precreated ARM vexpress image. 
2. Attempt to boot using (or provided bootscript with F17 GA image and 3.6 kernel):

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"

3. System will not boot, the following kernel message can be seen:

INITRD: 0x60d00000+0x00b3eb00 overlaps in-use memory region - disabling initrd. 

Full log - http://fpaste.org/AeZc/

Expected results:

System should boot to a log in prompt. 


Additional info:

I have been able to boot by changing the load address of the initrd manually and rebuilding. Below is the patch(also attached):

--- b/hw/arm_boot.c	2012-08-06 09:23:25.000000000 -0400
+++ a/qemu-kvm-1.2.0/hw/arm_boot.c	2012-09-26 15:12:19.860390812 -0400
@@ -18,7 +18,7 @@
 
 #define KERNEL_ARGS_ADDR 0x100
 #define KERNEL_LOAD_ADDR 0x00010000
-#define INITRD_LOAD_ADDR 0x00d00000
+#define INITRD_LOAD_ADDR 0x01d00000
 
 /* The worlds second smallest bootloader.  Set r0-r2, then jump to kernel.  */
 static uint32_t bootloader[] = {
Comment 1 Cole Robinson 2012-10-07 22:29:35 UTC 
Thanks Paul, I sent your patch upstream:

http://www.mail-archive.com/qemu-devel@nongnu.org/msg135069.html
Comment 2 Cole Robinson 2012-10-26 11:41:56 UTC 
Paul, where can I grab a kernel to test this? The patch as-is was rejected upstream because it will conflict with small memory arm machines:

https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01176.html

If i've got a reproducer maybe I can play with it and find something acceptable for upstream. Or feel free to chime in on that thread
Comment 3 Cole Robinson 2012-10-26 11:42:20 UTC 
(In reply to comment #2)
> Paul, where can I grab a kernel to test this? The patch as-is was rejected
> upstream because it will conflict with small memory arm machines:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg01176.html
> 
> If i've got a reproducer maybe I can play with it and find something
> acceptable for upstream. Or feel free to chime in on that thread

Setting NEEDINFO
Comment 4 Peter Robinson 2012-10-26 11:53:39 UTC 
Ultimately we set that value as it was larger and it worked. Maybe we need something in between. It might be better if the value could be set or overridden with a command line option or something like that. 

There's nightly builds here that allow you to recreate the problem. 

http://scotland.proximity.on.ca/arm-nightlies/vault/f18-prealpha/
Comment 5 Cole Robinson 2012-10-28 15:30:51 UTC 
(In reply to comment #4)
> Ultimately we set that value as it was larger and it worked. Maybe we need
> something in between. It might be better if the value could be set or
> overridden with a command line option or something like that. 
> 
> There's nightly builds here that allow you to recreate the problem. 
> 
> http://scotland.proximity.on.ca/arm-nightlies/vault/f18-prealpha/

Using:

http://scotland.proximity.on.ca/arm-nightlies/vault/f18-prealpha/F18-vexpress-test-20121010.tar.xz
./boot/boot-vexpress boot/vmlinuz-3.6.0-3.fc18.armv7hl boot/initramfs-3.6.0-3.fc18.armv7hl.img F18-vexpress-test-20121010.img

Booted fine using stock qemu-system-arm on current F18, what am I missing?

Also, the qemu arm maintainer has posted a patch that should fix things in a nicer way:

https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04732.html

But i'll verify and respond to him once I can reproduce the original issue.
Comment 6 Paul Whalen 2012-10-29 15:01:19 UTC 
(In reply to comment #5)
> (In reply to comment #4)
> > Ultimately we set that value as it was larger and it worked. Maybe we need
> > something in between. It might be better if the value could be set or
> > overridden with a command line option or something like that. 
> > 
> > There's nightly builds here that allow you to recreate the problem. 
> > 
> > http://scotland.proximity.on.ca/arm-nightlies/vault/f18-prealpha/
> 
> Using:
> 
> http://scotland.proximity.on.ca/arm-nightlies/vault/f18-prealpha/F18-
> vexpress-test-20121010.tar.xz
> ./boot/boot-vexpress boot/vmlinuz-3.6.0-3.fc18.armv7hl
> boot/initramfs-3.6.0-3.fc18.armv7hl.img F18-vexpress-test-20121010.img
> 
> Booted fine using stock qemu-system-arm on current F18, what am I missing?
> 
> Also, the qemu arm maintainer has posted a patch that should fix things in a
> nicer way:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04732.html
> 
> But i'll verify and respond to him once I can reproduce the original issue.

The issue seems to only appear in some kernels, most notably the RC kernels. I first noticed it using: kernel-3.6.0-0.rc3.git2.1.fc18
Comment 7 Peter Robinson 2012-10-29 15:09:01 UTC 
I wonder if it's when we have debug kernels which are larger.
Comment 8 Peter Robinson 2012-10-29 15:09:59 UTC 
> Also, the qemu arm maintainer has posted a patch that should fix things in a
> nicer way:
> 
> https://lists.gnu.org/archive/html/qemu-devel/2012-10/msg04732.html

I'm happy for a solution from upstream. It was just be useful not to have the issue :)
Comment 9 Cole Robinson 2012-10-29 15:46:02 UTC 
Can you guys link me to one of those debug kernels (sorry if it's buried somewhere in one of the links you pasted above, but it didn't jump out at me)
Comment 10 Paul Whalen 2012-10-29 16:51:58 UTC 
(In reply to comment #9)
> Can you guys link me to one of those debug kernels (sorry if it's buried
> somewhere in one of the links you pasted above, but it didn't jump out at me)

You can find one here - http://armpkgs.fedoraproject.org/packages/kernel/3.6.0/0.rc3.git2.1.fc18/armv7hl/kernel-3.6.0-0.rc3.git2.1.fc18.armv7hl.rpm
Comment 11 Fedora Update System 2012-10-31 12:53:11 UTC 
qemu-1.2.0-18.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qemu-1.2.0-18.fc18
Comment 12 Fedora Update System 2012-10-31 18:11:00 UTC 
Package qemu-1.2.0-18.fc18:
* should fix your issue,
* was pushed to the Fedora 18 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing qemu-1.2.0-18.fc18'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2012-17353/qemu-1.2.0-18.fc18
then log in and leave karma (feedback).
Comment 13 Fedora Update System 2012-11-01 13:05:49 UTC 
qemu-1.2.0-19.fc18 has been submitted as an update for Fedora 18.
https://admin.fedoraproject.org/updates/qemu-1.2.0-19.fc18
Comment 14 Paul Whalen 2012-11-02 20:07:33 UTC 
qemu-1.2.0-19.fc18 - confirmed working with latest debug enabled kernel.