Description of problem: kernel 4.5.0-0.rc1.git1.1.fc24 does not boot in qemu (using software TCG emulation). Basically similar to bug 1302071, but now affecting armv7hl as well. Version-Release number of selected component (if applicable): kernel 4.5.0-0.rc1.git1.1.fc24 qemu 2:2.5.0-4.fc24 How reproducible: 100% Steps to Reproduce: 1. Run libguestfs-test-tool on armv7hl. Additional info: https://kojipkgs.fedoraproject.org//work/tasks/6380/12726380/root.log https://kojipkgs.fedoraproject.org//work/tasks/6380/12726380/build.log I'm going to try and get my Cubietruck working again to see if I can reproduce this on baremetal and/or in a KVM VM.
This kernel fails to boot on baremetal also. Enter choice: 1: Fedora (4.5.0-0.rc1.git1.1.fc24.armv7hl) 23 (Twenty Three) Retrieving file: /initramfs-4.5.0-0.rc1.git1.1.fc24.armv7hl.img 14830723 bytes read in 487 ms (29 MiB/s) Retrieving file: /vmlinuz-4.5.0-0.rc1.git1.1.fc24.armv7hl 6593544 bytes read in 220 ms (28.6 MiB/s) no console= append: ro root=UUID=e098e36f-f409-44cb-9d8e-9d5c0e2ed9c9 LANG=en_US.UTF-8 console=ttyS0,115200 Retrieving file: /dtb-4.5.0-0.rc1.git1.1.fc24.armv7hl/sun7i-a20-cubietruck.dtb 30801 bytes read in 534 ms (55.7 KiB/s) Kernel image @ 0x42000000 [ 0x000000 - 0x649c08 ] ## Flattened Device Tree blob at 43000000 Booting using the fdt blob at 0x43000000 Loading Ramdisk to 4f1db000, end 4ffffc83 ... OK Loading Device Tree to 4f1d0000, end 4f1da850 ... OK Starting kernel ... [and here it hangs, apparently forever] The hardware is a CubieTruck.
FWIW 4.5.0-0.rc1.git1.1.fc24.armv7hl+lpae does not boot either. 4.5.0-0.rc1.git0.2.fc24.armv7hl DOES boot OK.
Same here, tested on Banana Pi, I'm unable to boot since rawhide 20160130, (affected kernels: kernel-4.5.0-0.rc1.git2.1.fc24.armv7hl.rpm, kernel-4.5.0-0.rc2.git1.1.fc24.armv7hl.rpm) As pwhalen mentioned, it seems to be specific for vexpress and allwinner: https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/thread/MT4CL4LRARX555QRUFZ6AHXSXFEPDFEJ/
(In reply to Lukas Brabec from comment #3) > Same here, tested on Banana Pi, I'm unable to boot since rawhide 20160130, > (affected kernels: kernel-4.5.0-0.rc1.git2.1.fc24.armv7hl.rpm, > kernel-4.5.0-0.rc2.git1.1.fc24.armv7hl.rpm) > > > As pwhalen mentioned, it seems to be specific for vexpress and allwinner: > https://lists.fedoraproject.org/archives/list/arm@lists.fedoraproject.org/ > thread/MT4CL4LRARX555QRUFZ6AHXSXFEPDFEJ/ It affects qemu -M virt too. See comment #0.
OK this looks to be an issue with the new binutils, when the kernel is built with the f23 userspace it works as expected and the version that has issues was the first build with the new binutils
*** Bug 1306568 has been marked as a duplicate of this bug. ***
This bug appears to have been reported against 'rawhide' during the Fedora 24 development cycle. Changing version to '24'. More information and reason for this action is here: https://fedoraproject.org/wiki/Fedora_Program_Management/HouseKeeping/Fedora24#Rawhide_Rebase
OK, I've spend some time over the weekend digging into this further to try and get to the bottom of it. To summarise the last kernel to boot correctly was 4.5.0-0.rc1.git0.2.fc24 and from then on 4.5.0-0.rc1.git1.1.fc24 doesn't on some ARMv7 SoCs. AllWinner, VExpress, some tegra (at least tk1/124) appear to be affected. i.MX6, am33xx, omap, mvebu aren't affected and work fine. There's possibly others that are/aren't affected that I've not yet tested. Two koji build tasks: 4.5.0-0.rc1.git0.2.fc24: http://koji.fedoraproject.org/koji/buildinfo?buildID=714169 4.5.0-0.rc1.git1.1.fc24: http://koji.fedoraproject.org/koji/buildinfo?buildID=714524 I was wrong on the binutils, the major change here in the toolchain was the landing of gcc6. binutils was already at 2.26-3.fc24 for the last working kernel. The diff of the buildroot package differences on the above working/not working kernels is: -00kernel/4.5.0/0.rc1.git0.2.fc24 +00kernel/4.5.0/0.rc1.git1.1.fc24 - binutils armv7hl 2.26-3.fc24 build 5.5 M - binutils-devel armv7hl 2.26-3.fc24 build 712 k + binutils armv7hl 2.26-4.fc24 build 5.5 M + binutils-devel armv7hl 2.26-4.fc24 build 710 k - cpp armv7hl 5.3.1-3.fc24 build 6.8 M + cpp armv7hl 6.0.0-0.5.fc24 build 7.1 M - dnf-plugins-core noarch 0.1.16-1.fc24 build 36 k + dnf-plugins-core noarch 0.1.16-2.fc24 build 36 k - elfutils armv7hl 0.165-2.fc24 build 290 k - elfutils-default-yama-scope noarch 0.165-2.fc24 build 36 k - elfutils-devel armv7hl 0.165-2.fc24 build 92 k - elfutils-libelf armv7hl 0.165-2.fc24 build 209 k - elfutils-libelf-devel armv7hl 0.165-2.fc24 build 43 k - elfutils-libs armv7hl 0.165-2.fc24 build 257 k + elfutils armv7hl 0.165-3.fc24 build 289 k + elfutils-default-yama-scope noarch 0.165-3.fc24 build 37 k + elfutils-devel armv7hl 0.165-3.fc24 build 92 k + elfutils-libelf armv7hl 0.165-3.fc24 build 210 k + elfutils-libelf-devel armv7hl 0.165-3.fc24 build 43 k + elfutils-libs armv7hl 0.165-3.fc24 build 257 k - file armv7hl 5.25-4.fc24 build 66 k - file-libs armv7hl 5.25-4.fc24 build 433 k + file armv7hl 5.25-5.fc24 build 66 k + file-libs armv7hl 5.25-5.fc24 build 433 k - gcc armv7hl 5.3.1-3.fc24 build 15 M - gcc-c++ armv7hl 5.3.1-3.fc24 build 8.0 M - gcc-gdb-plugin armv7hl 5.3.1-3.fc24 build 72 k + gcc armv7hl 6.0.0-0.5.fc24 build 15 M + gcc-c++ armv7hl 6.0.0-0.5.fc24 build 8.4 M + gcc-gdb-plugin armv7hl 6.0.0-0.5.fc24 build 55 k - glibc armv7hl 2.22.90-29.fc24 build 3.3 M - glibc-common armv7hl 2.22.90-29.fc24 build 12 M - glibc-devel armv7hl 2.22.90-29.fc24 build 915 k - glibc-headers armv7hl 2.22.90-29.fc24 build 478 k + glibc armv7hl 2.22.90-31.fc24 build 3.4 M + glibc-common armv7hl 2.22.90-31.fc24 build 12 M + glibc-devel armv7hl 2.22.90-31.fc24 build 928 k + glibc-headers armv7hl 2.22.90-31.fc24 build 478 k - go-srpm-macros noarch 2-4.fc24 build 7.3 k + go-srpm-macros noarch 2-5.fc24 build 7.1 k - kernel-headers armv7hl 4.5.0-0.rc1.git0.1.fc24 build 1.0 M + kernel-headers armv7hl 4.5.0-0.rc1.git0.2.fc24 build 1.0 M - krb5-libs armv7hl 1.14-17.fc24 build 755 k + krb5-libs armv7hl 1.14-18.fc24 build 756 k - libasan armv7hl 5.3.1-3.fc24 build 262 k + libasan armv7hl 6.0.0-0.5.fc24 build 288 k - libatomic armv7hl 5.3.1-3.fc24 build 32 k + libatomic armv7hl 6.0.0-0.5.fc24 build 13 k - libgcc armv7hl 5.3.1-3.fc24 build 84 k + libgcc armv7hl 6.0.0-0.5.fc24 build 65 k - libgomp armv7hl 5.3.1-3.fc24 build 146 k + libgomp armv7hl 6.0.0-0.5.fc24 build 161 k - libstdc++ armv7hl 5.3.1-3.fc24 build 370 k - libstdc++-devel armv7hl 5.3.1-3.fc24 build 1.7 M + libstdc++ armv7hl 6.0.0-0.5.fc24 build 355 k + libstdc++-devel armv7hl 6.0.0-0.5.fc24 build 1.8 M - libtool-ltdl armv7hl 2.4.6-8.fc24 build 51 k - libubsan armv7hl 5.3.1-3.fc24 build 115 k + libtool-ltdl armv7hl 2.4.6-9.fc24 build 51 k + libubsan armv7hl 6.0.0-0.5.fc24 build 103 k - openssl-libs armv7hl 1:1.0.2e-5.fc24 build 831 k + openssl-libs armv7hl 1:1.0.2f-1.fc24 build 831 k - python3-dnf-plugins-core noarch 0.1.16-1.fc24 build 80 k + python3-dnf-plugins-core noarch 0.1.16-2.fc24 build 80 k Of the above the only possible components that look like they might cause issues is gcc 6, binutils bump, elfutils, and glibc. The obvious one was gcc 6, and with a local compile using: binutils-2.26-13.fc24.armv7hl gcc-5.3.1-3.fc24.armv7hl elfutils-0.165-5.fc24.armv7hl glibc-2.22.90-36.fc24.armv7hl So with just gcc downgraded to the last 5.3 rev shipped in F-24 we have a working boot on an AllWinner based Cubietruck indicating the problem is in fact gcc6.
So the CubieTruck and Jetson TK1 which previously ceased to boot with a 4.5.0-0.rc1.git1.1.fc24 or later kernel now boot with one compiled with binutils 2.26+ and gcc 5.3.1. For those that wish to test you can grab the kernel from: https://pbrobinson.fedorapeople.org/arm-kernel/
So, can somebody bisect this to a particular kernel source file? Start with building two same kernels, build one with gcc 6.0 prerelease, another one with gcc 5.3.1, and then copy that to another tree and always mix them some portion of gcc 6.0 built object files and 5.3.1 built object files, touch them and relink, test. Perhaps with knowing roughly what is going on or at least where the bisection might be speeded up by only trying a couple of suspicious object files.
> So, can somebody bisect this to a particular kernel source file? I'm not sure what you mean by this. If I build the identical kernel src.rpm with gcc 6 it doesn't boot, if I build the same src.rpm with gcc 5.3.1 it doesn't boot. > Start with building two same kernels, build one with gcc 6.0 prerelease, > another one with gcc 5.3.1, and then copy that to another tree and always > mix them some portion of gcc 6.0 built object files and 5.3.1 built object > files, touch them and relink, test. That process doesn't make sense when a kernel that's built on gcc 5.3.1 and the same kernel doesn't work on gcc6
What doesn't make sense? If gcc 5.3.1 builds a working kernel and gcc 6 non-working, but both are ABI compatible (they should be), then you can try linking say first half of *.o files created with gcc 5.3.1 with rest of *.o files created with gcc 6, if that boots, copy over a quarter of further gcc 6 created files, if it doesn't boot, copy over a quarter of further gcc 5.3.1 generated files, etc., until you have either a single gcc 6 compiled file and all others 5.3.1 which still fails to boot, or all gcc 6 compiled except one, compiled with 5.3.1 that does boot. This of course assumes the problem is just in a single file, which is the most common case. At that point, attach the preprocessed source and gcc command line options used to compile it.
When I copy arch/arm/kernel/setup.o from gcc 5.3.1 build to my gcc 6.0.0 build then resulting kernel boots.
Created attachment 1132725 [details] gcc 5.3.1 preprocessed source of arch/arm/kernel/setup.c make arch/arm/kernel/setup.o V=1 [...] gcc -Wp,-MD,arch/arm/kernel/.setup.o.d -nostdinc -isystem /usr/lib/gcc/armv7hl-redhat-linux-gnueabi/5.3.1/include -I./arch/arm/include -Iarch/arm/include/generated/uapi -Iarch/arm/include/generated -Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fvar-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)" -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/arm/kernel/setup.o arch/arm/kernel/setup.c
Created attachment 1132726 [details] gcc 6.0.0 preprocessed source of arch/arm/kernel/setup.c <mock-chroot>[mockbuild@localhost linux-4.5.0-0.rc6.git0.1.fc25.armv7hl]$ gcc -Wp,-MD,arch/arm/kernel/.setup.o.d -nostdinc -isystem /usr/lib/gcc/armv7hl-gnueabi/6.0.0/include -I./arch/arm/include -Iarch/arm/include/generated/uapi -Iarch/arm/include/generated -Iinclude -I./arch/arm/include/uapi -Iarch/arm/include/generated/uapi -I./include/uapi -Iinclude/generated/uapi -include ./include/linux/kconfig.h -D__KERNEL__ -mlittle-endian -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Wno-format-security -std=gnu89 -fno-dwarf2-cfi-asm -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -funwind-tables -marm -D__LINUX_ARM_ARCH__=7 -march=armv7-a -msoft-float -Uarm -fno-delete-null-pointer-checks -Os -Wno-maybe-uninitialized --param=allow-store-data-races=0 -Wframe-larger-than=1024 -fno-stack-protector -Wno-unused-but-set-variable -fvar-tracking-assignments -g -pg -Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow -fconserve-stack -Werror=implicit-int -Werror=strict-prototypes -Werror=date-time -DCC_HAVE_ASM_GOTO -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(setup)" -D"KBUILD_MODNAME=KBUILD_STR(setup)" -c -o arch/arm/kernel/setup.o arch/arm/kernel/setup.c
One extra datapoint / something to keep in mind, I've just found out the hardway that it is not just an issue with kernels build with gcc-6 but also with u-boot build with gcc-6 (at least on allwinner A23 SoCs). The u-boot issue is more subtle / nasty, u-boot seems to work as it should but the kernel hangs during boot when u-boot is build with gcc-6. Not 100% sure this is the case but downgrading gcc and then rebuilding u-boot fixed the boot issue I was having. Note lets first fix the kernel thing, hopefully the u-boot fix will be similar, or if this is a gcc issue, the gcc fix will also fix u-boot.
Does building that file with -O0 help? Or -O2 instead of -Os? If yes, can you try adding __attribute__((optimize (0))) to some functions and see which function in that file matters? Does -Os -fno-inline still crash? If yes, the above would be somewhat easier with -fno-inline on the command line. Otherwise, I could try to provide you assembly files built with different revisions of gcc, but that would need to be interactive process, as I have no way to reproduce this myself.
(In reply to Jakub Jelinek from comment #17) > Does building that file with -O0 help? Or -O2 instead of -Os? > If yes, can you try adding __attribute__((optimize (0))) to some functions > and see which function in that file matters? > Does -Os -fno-inline still crash? If yes, the above would be somewhat > easier with -fno-inline on the command line. Will check those hints on Monday. > Otherwise, I could try to provide you assembly files built with different > revisions of gcc, but that would need to be interactive process, as I have > no way to reproduce this myself. I used qemu for tests: qemu-system-arm -serial stdio -append "console=ttyAMA0 earlyprintk" -M virt -kernel zImage
setup.c built with -O0 boots. -O1 does not. Will check which optimization breaks.
Well, -O1 enables lots of changes that aren't controllable by other optimization flags. Does -O1 -fno-inline boot or not? If it doesn't, then I'd go with -O1 -fno-inline, and selectively adding __attribute__((optimize (0))) to various functions.
According to gcc docs at https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html this should be equal to -O1: -O0 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments -fcompare-elim -fcprop-registers -fdce -fdefer-pop -fdelayed-branch -fdse -fforward-propagate -fguess-branch-probability -fif-conversion2 -fif-conversion -finline-functions-called-once -fipa-pure-const -fipa-profile -fipa-reference -fmerge-constants -fmove-loop-invariants -freorder-blocks -fshrink-wrap -fsplit-wide-types -fssa-backprop -fssa-phiopt -ftree-bit-ccp -ftree-ccp -ftree-ch -ftree-coalesce-vars -ftree-copy-prop -ftree-dce -ftree-dominator-opts -ftree-dse -ftree-forwprop -ftree-fre -ftree-phiprop -ftree-sink -ftree-slsr -ftree-sra -ftree-pta -ftree-ter -funit-at-a-time But resulting kernel boots. Will go for __attribute__ check now. -O1 -fno-inline does not boot.
__attribute__((optimize (0))) static void __init patch_aeabi_idiv(void) and kernel boots!
(In reply to Marcin Juszkiewicz from comment #22) > __attribute__((optimize (0))) static void __init patch_aeabi_idiv(void) > > and kernel boots! That's with default -Os optimisations.
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/arm/kernel/setup.c?id=42f25bddd0a226d2431e057b9e01c5cc61067e12 is faulty commit. Disabling CONFIG_ARM_PATCH_IDIV in config makes kernel bootable again. Will mail Nicolas Pitre.
(In reply to Marcin Juszkiewicz from comment #24) > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/arch/ > arm/kernel/setup.c?id=42f25bddd0a226d2431e057b9e01c5cc61067e12 is faulty > commit. The question is why that works on gcc 5.3.1 and breaks on gcc 6
Created attachment 1133886 [details] setup.c ASM source when built with gcc 5.3.1 (-save-temps used) I built setup.o with "-save-temps" option.
Created attachment 1133887 [details] setup.c ASM source when built with gcc 6.0.0 (-save-temps used)
If the kernel still boots if you add -fno-inline when you compile setup.c with gcc 5.3 and breaks if you add -fno-inline when you compile setup.c with gcc 6, can you please attach the assembly you get with the additional -fno-inline -dA options in addition to what you used (have just cross-compiler here and want to verify I'm looking at the same code). patch_eabi_idiv is pretty short function, so hope something can be discovered just from eyeballing the assembly.
Actually, I can see it already. DSE1 does: Deleted dead store '*fn_addr.35_20 = 3876647184; Deleted dead store '*fn_addr.35_9 = 3878744336; so removes the stores of the first instructions (and keeps the second instructions). It would be certainly safer if the kernel used some optimization barrier, like: fn_addr = (uintptr_t)&__aeabi_uidiv; asm volatile ("" : "+g" (fn_addr)); fn_addr &= ~1; (and similarly for __aeabi_idiv). But I'll have a look why DSE removes it and when it started. Reduced testcase: extern void v7_coherent_kern_range(unsigned long, unsigned long); void patch_aeabi_idiv(void) { extern void __aeabi_uidiv(void); extern void __aeabi_idiv(void); unsigned long fn_addr; fn_addr = ((unsigned long)&__aeabi_uidiv) & ~1; ((unsigned int *)fn_addr)[0] = 0xe730f110; ((unsigned int *)fn_addr)[1] = 0xe12fff1e; v7_coherent_kern_range(fn_addr,fn_addr + 8); fn_addr = ((unsigned long)&__aeabi_idiv) & ~1; ((unsigned int *)fn_addr)[0] = 0xe710f110; ((unsigned int *)fn_addr)[1] = 0xe12fff1e; v7_coherent_kern_range(fn_addr,fn_addr + 8); }
Strangely, the above with -fno-strict-aliasing -fno-common -std=gnu89 -fno-ipa-sra -mabi=aapcs-linux -mno-thumb-interwork -mfpu=vfp -marm -march=armv7-a -msoft-float -fno-delete-null-pointer-checks -Os the ((unsigned int *)fn_addr)[0] stores are removed already by gcc 5 too and even older compilers.
Great work Jakub!
I saw the changelog entry: Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147 in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However, kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed? I'm testing on a PCDuino3 Nano Lite (Allwinner A20).
> Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147 > > in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However, > kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed? Boots fine on my CubieTruck which is also a AllWinner A20, but there does appear to be an issue with the NIC, which while a regression I'll look into, is completely unrelated to this.
This issue is solved upstream and touched A7/A15/A17 cores only. Workaround in kernel config was done. We will close it when all pieces land in Fedora. For other kernel issues please open new bugs.
Hi Peter, (In reply to Peter Robinson from comment #33) > > Disble ARM_PATCH_IDIV as a work around to fix rhbz 1303147 > > > > in kernel-4.5.0-0.rc7.git0.2.fc24, and that kernel booted. However, > > kernel-4.5.0-300.fc24 hangs in boot again. Was the workaround fix removed? > > Boots fine on my CubieTruck which is also a AllWinner A20, but there does > appear to be an issue with the NIC, which while a regression I'll look into, > is completely unrelated to this. The NIC not working in u-boot is a known issue. I've a pretty good idea how to fix this, it should work in the kernel but if you're tftp booting that is not of any help. Unfortunately I did not realize that u-boot has moved from a 3 month release schedule to a 2 month schedule, otherwise I would have prioritized fixing this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches (this one and another one) to add to Fedora's u-boot v2016.03 release (which I thought would be v2016.04 giving me more time). Regards, Hans
> The NIC not working in u-boot is a known issue. I've a pretty good idea how > to fix this, it should work in the kernel but if you're tftp booting that is > not of any help. No, this is not working in the kernel. Nothing to do with u-boot, I'm aware of those issues, I'm on the u-boot mailing list. > Unfortunately I did not realize that u-boot has moved from a 3 month release > schedule to a 2 month schedule, otherwise I would have prioritized fixing It was well documented on the u-boot mailing list. > this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches > (this one and another one) to add to Fedora's u-boot v2016.03 release (which > I thought would be v2016.04 giving me more time). Sure, or I'm happy to grab them from the u-boot list/patworks too. That said, this is not the location to discuss any of the above, it's off topic.
(In reply to Marcin Juszkiewicz from comment #21) > According to gcc docs at > https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html this should be > equal to -O1: > > -O0 -fauto-inc-dec -fbranch-count-reg -fcombine-stack-adjustments ... No, you missed the part that says: "Most optimizations are only enabled if an -O level is set on the command line. Otherwise they are disabled, even if individual optimization flags are specified." i.e. -O0 disables all optimizations, you can't turn individual ones on. https://gcc.gnu.org/wiki/FAQ#optimization-options
I built 4.5 kernel with IDIV enabled using gcc 6.0.0-16 (which has solution merged). Kernel booted fine. (In reply to Jonathan Wakely from comment #37) > No, you missed the part that says: Thanks. Will remember for future.
(In reply to Peter Robinson from comment #36) > > The NIC not working in u-boot is a known issue. I've a pretty good idea how > > to fix this, it should work in the kernel but if you're tftp booting that is > > not of any help. > > No, this is not working in the kernel. Nothing to do with u-boot, I'm aware > of those issues, I'm on the u-boot mailing list. > > > Unfortunately I did not realize that u-boot has moved from a 3 month release > > schedule to a 2 month schedule, otherwise I would have prioritized fixing > > It was well documented on the u-boot mailing list. > > > this. Once I've this fixed I'll send you a mail with 2 sunxi bug-fix patches > > (this one and another one) to add to Fedora's u-boot v2016.03 release (which > > I thought would be v2016.04 giving me more time). > > Sure, or I'm happy to grab them from the u-boot list/patworks too. > > That said, this is not the location to discuss any of the above, it's off > topic.
Proposed as a Blocker for 24-alpha by Fedora user lbrabec using the blocker tracking app because: This bug clearly violates alpha criterion: Initialization requirements "Release-blocking images must boot" (All release-blocking images must boot in their supported configurations.) and "Release-blocking ARM disk images must boot to the initial-setup utility". I got stuck again on "Starting kernel ...", tested on Banana Pi with Fedora-Minimal-armhfp-24_Alpha-5-sda.raw.xz (kernel 4.5.0-0.rc7.git0.2.fc24). I propose this because Banana Pi is a common board as well as are AllWinner SoCs (even though it boots on CubieTruck, as said in comment #37).
> I got stuck again on "Starting kernel ...", tested on Banana Pi with > Fedora-Minimal-armhfp-24_Alpha-5-sda.raw.xz (kernel 4.5.0-0.rc7.git0.2.fc24). That kernel already has this fix, this is not the same problem. Please provide details on how you flashed the image in a new BZ. > I propose this because Banana Pi is a common board as well as are AllWinner > SoCs (even though it boots on CubieTruck, as said in comment #37). We don't block a release on individual devices. The issue you're seeing is not this one. Please open another bug.