Skip to content
This repository has been archived by the owner on Apr 13, 2024. It is now read-only.

Drop ext4 images and use initramfs for all targets #221

Merged
merged 2 commits into from
Dec 16, 2019
Merged

Drop ext4 images and use initramfs for all targets #221

merged 2 commits into from
Dec 16, 2019

Conversation

tpimh
Copy link
Contributor

@tpimh tpimh commented Dec 4, 2019

As discussed in #184 (comment), ext4 images can be dropped and slimmer initramfs images should be used instead.

Most ext4 images were unused. Only arm32_v7, arm64, mipsel and some x86_64 configs used them. They were modified to use initramfs instead.

Travis for basic set of configurations shows no regressions, but I suggest testing the full set that's normally run by cron.

@tpimh tpimh self-assigned this Dec 4, 2019
@nathanchance
Copy link
Member

I pulled this down locally and started a set of builds before I had to rush off to work. I’ll post the results and formally review it tonight.

Copy link
Member

@nickdesaulniers nickdesaulniers left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I was hesitant to remove these, as locally I was using these images to run QEMU tests quickly locally, but I should just update my workflow to use these. Thanks for the cleanup and simplification. 🐇 🏇

@nathanchance
Copy link
Member

Full results:

Running 'ARCH=arm32_v5 LD=ld.lld ./driver.sh'... Successful in 2m 14s
Running 'ARCH=arm32_v6 ./driver.sh'... Successful in 1m 26s
Running 'ARCH=arm32_v7 LD=ld.lld ./driver.sh'... Successful in 1m 57s
Running 'ARCH=arm64 LD=ld.lld ./driver.sh'... Successful in 2m 44s
Running 'ARCH=mipsel ./driver.sh'... Successful in 1m 23s
Running 'ARCH=ppc32 ./driver.sh'... Successful in 1m 1s
Running 'ARCH=ppc64 ./driver.sh'... Successful in 1m 54s
Running 'ARCH=ppc64le LD=ld.lld ./driver.sh'... Failed in 3m 20s
Running 'ARCH=x86_64 LD=ld.lld ./driver.sh'... Successful in 1m 53s
Running 'ARCH=arm32_v5 LD=ld.lld REPO=linux-next ./driver.sh'... Successful in 2m 16s
Running 'ARCH=arm32_v6 REPO=linux-next ./driver.sh'... Successful in 1m 25s
Running 'ARCH=arm32_v7 LD=ld.lld REPO=linux-next ./driver.sh'... Successful in 1m 58s
Running 'ARCH=arm64 LD=ld.lld REPO=linux-next ./driver.sh'... Successful in 2m 45s
Running 'ARCH=mipsel REPO=linux-next ./driver.sh'... Successful in 1m 21s
Running 'ARCH=ppc32 REPO=linux-next ./driver.sh'... Successful in 0m 59s
Running 'ARCH=ppc64 REPO=linux-next ./driver.sh'... Successful in 1m 52s
Running 'ARCH=ppc64le LD=ld.lld REPO=linux-next ./driver.sh'... Failed in 3m 18s
Running 'ARCH=x86_64 LD=ld.lld REPO=linux-next ./driver.sh'... Successful in 1m 56s
Running 'ARCH=arm32_v7 REPO=4.19 ./driver.sh'... Successful in 2m 26s
Running 'ARCH=arm64 LD=ld.lld REPO=4.19 ./driver.sh'... Successful in 2m 20s
Running 'ARCH=ppc64le REPO=4.19 ./driver.sh'... Failed in 3m 14s
Running 'ARCH=x86_64 LD=ld.lld REPO=4.19 ./driver.sh'... Successful in 1m 39s
Running 'ARCH=arm32_v7 REPO=4.14 ./driver.sh'... Successful in 2m 11s
Running 'ARCH=arm64 LD=ld.lld REPO=4.14 ./driver.sh'... Successful in 2m 2s
Running 'ARCH=ppc64le REPO=4.14 ./driver.sh'... Failed in 3m 17s
Running 'ARCH=x86_64 LD=ld.lld REPO=4.14 ./driver.sh'... Successful in 1m 38s
Running 'ARCH=arm32_v7 REPO=4.9 ./driver.sh'... Successful in 1m 50s
Running 'ARCH=arm64 REPO=4.9 ./driver.sh'... Successful in 1m 38s
Running 'ARCH=x86_64 LD=ld.lld REPO=4.9 ./driver.sh'... Successful in 1m 15s
Running 'ARCH=arm64 REPO=4.4 ./driver.sh'... Successful in 1m 38s
Running 'ARCH=x86_64 LD=ld.lld REPO=4.4 ./driver.sh'... Successful in 1m 12s
Running 'ARCH=arm64 REPO=android-4.9-q ./driver.sh'... Successful in 2m 47s
Running 'ARCH=arm64 REPO=android-4.14 ./driver.sh'... Successful in 2m 58s
Running 'ARCH=arm64 REPO=android-4.19 ./driver.sh'... Successful in 3m 8s
Running 'ARCH=x86_64 LD=ld.lld REPO=android-4.9-q ./driver.sh'... Successful in 1m 51s
Running 'ARCH=x86_64 LD=ld.lld REPO=android-4.14 ./driver.sh'... Successful in 2m 53s
Running 'ARCH=x86_64 LD=ld.lld REPO=android-4.19 ./driver.sh'... Successful in 2m 37s

Looks like powerpc64le is the only regression but it appears to be a QEMU one because I am using v4.2.0-rc4 and v4.1.1 appears fine:

$ ARCH=ppc64le LD=ld.lld ./driver.sh
...
+ timeout 2m unbuffer qemu-system-ppc64 -m 2G -machine powernv -device ipmi-bmc-sim,id=bmc0 -device isa-ipmi-bt,bmc=bmc0,irq=10 -L images/ppc64le/ -bios skiboot.lid -initrd images/ppc64le/rootfs.cpio -display none -serial mon:stdio -kernel linux/arch/powerpc/boot/zImage.epapr
[    0.014104195,5] OPAL skiboot-v6.2-176-g261ca8e779e5 starting...
[    0.014592522,7] initial console log level: memory 7, driver 5
[    0.014630639,6] CPU: P9 generation processor (max 4 threads/core)
[    0.014647800,7] CPU: Boot CPU PIR is 0x0000 PVR is 0x004e1200
[    0.014742086,7] OPAL table: 0x30100f30 .. 0x30101510, branch table: 0x30002000
[    0.014900926,7] Assigning physical memory map table for nimbus
[    0.015538051,7] FDT: Parsing fdt @0x1000000
[    0.017377792,6] CHIP: Initialised chip 0 from xscom@603fc00000000
[    0.017680180,6] P9 DD2.00 detected
[    0.017696491,5] CHIP: Chip ID 0000 type: P9N DD2.00
[    0.017704748,7] XSCOM: Base address: 0x603fc00000000
[    0.017721911,7] XSTOP: ibm,sw-checkstop-fir prop not found
[    0.017778401,6] MFSI 0:0: Initialized
[    0.017788696,6] MFSI 0:2: Initialized
[    0.017797746,6] MFSI 0:1: Initialized
[    0.018184044,6] LPC: LPC[000]: Initialized
[    0.018191946,7] LPC: access via MMIO @0x6030000000000
[    0.018214891,7] LPC: Default bus on chip 0x0
[    0.018283335,7] CPU: New max PIR set to 0x3
[    0.018681309,7] MEM: parsing reserved memory from reserved-names/-ranges properties
[    0.018740943,7] HOMER: Init chip 0
[    0.018767631,7]   PBA BAR0 : 0x0000203ffd800000
[    0.018775342,7]   PBA MASK0: 0x0000000000300000
[    0.018797931,7]   HOMER Image at 0x203ffd800000 size 4MB
[    0.018839048,4] HOMER image is not reserved! Reserving
[    0.018878353,7]   PBA BAR2 : 0x0000203fff800000
[    0.018883037,7]   PBA MASK2: 0x0000000000700000
[    0.018892651,7]   OCC Common Area at 0x203fff800000 size 8MB
[    0.018919342,4] OCC common area is not reserved! Reserving
[    0.018957641,7] CPU: decrementer bits 56
[    0.019006608,6] CPU: CPU from DT PIR=0x0000 Server#=0x0 State=3
[    0.019087732,6] CPU:  1 secondary threads
[    0.019585672,3] GENERIC BMC PLATFORM: **GUESSING** that there's *maybe* a BMC we can talk to.
[    0.019596073,3] THIS IS ****UNSUPPORTED****, BRINGUP USE ONLY.
[    0.020109340,5] PLAT: Using SuperIO UART
[    0.020346917,7] UART: Using LPC IRQ 4
[    0.024642533,5] PLAT: Detected generic platform
[    0.024761307,5] PLAT: Detected BMC platform generic
[    0.049745843,5] CPU: All 1 processors called in...
[    0.050039462,3] CHIPTOD: Unknown TOD type !
[    0.050140437,3] CHIPTOD: Failed ChipTOD detection !
[    0.050261767,0] Aborting!
CPU 0000 Backtrace:
 S: 0000000031c03cd0 R: 000000003001b2c4   ._abort+0x4c
 S: 0000000031c03d50 R: 0000000030037f40   .chiptod_init+0xf0
 S: 0000000031c03e30 R: 0000000030014ef4   .main_cpu_entry+0x404
 S: 0000000031c03f00 R: 0000000030002718   boot_entry+0x1c0
 --- OPAL boot ---

I'll bisect the breaking commit and report it upstream. I assume that our version of QEMU in the Docker image should be fine but I do not have the time to verify right now.

nathanchance added a commit to nathanchance/continuous-integration that referenced this pull request Dec 6, 2019
There is currently an issue with booting a ppc64le kernel with QEMU
4.2.0-rc4. A bisect points to the QEMU commit linked below. Updating to
the latest stable skiboot 6.5.1 fixes the issue and does not break QEMU
3.1.0 that we currently use for our Docker image.

Link: ClangBuiltLinux#221 (comment)
Link: https://git.qemu.org/?p=qemu.git;a=commit;h=f30c843ced5055fde71d28d10beb15af97fdfe39
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
nathanchance added a commit to nathanchance/continuous-integration that referenced this pull request Dec 6, 2019
There is currently an issue with booting a ppc64le kernel with QEMU
4.2.0-rc4 with the skiboot we package in this repo (done in ClangBuiltLinux#138), see
the link in ClangBuiltLinux#221 below.

A bisect points to the QEMU commit linked below. Updating to the latest
stable skiboot 6.5.1 fixes the issue and does not break QEMU 3.1.0 that
we currently use for our Docker image.

[skip ci]

Link: ClangBuiltLinux#221 (comment)
Link: https://git.qemu.org/?p=qemu.git;a=commit;h=f30c843ced5055fde71d28d10beb15af97fdfe39
Presubmit: https://travis-ci.com/nathanchance/continuous-integration/builds/139635572
Signed-off-by: Nathan Chancellor <natechancellor@gmail.com>
@nickdesaulniers
Copy link
Member

I think this is good to land, now? Or are we still blocked on something?

Copy link
Member

@nathanchance nathanchance left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sorry, forgot to update it here. That regression was not in this pull request, it has been handled in #224. This should be good now.

@nickdesaulniers nickdesaulniers merged commit 52ca57f into ClangBuiltLinux:master Dec 16, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants