error in tag #1
Comments
johnjacques
pushed a commit
that referenced
this issue
Nov 6, 2015
Currently some uninitialized padding bytes are written to the output file, as can be confirmed with valgrind: $ valgrind tools/mksunxiboot spl/u-boot-spl.bin spl/sunxi-spl.bin ==5581== Syscall param write(buf) points to uninitialised byte(s) ==5581== at 0x4F0F940: __write_nocancel (in /lib64/libc-2.20.so) ==5581== by 0x400839: main (in /tmp/u-boot/tools/mksunxiboot) ==5581== Address 0xffeff5d3c is on thread 1's stack ==5581== in frame #1, created by main (???) This patch fixes the problem by clearing the whole structure instead of just a portion of it. Signed-off-by: Siarhei Siamashka <[email protected]> Acked-by: Hans de Goede <[email protected]> Signed-off-by: Hans de Goede <[email protected]>
johnjacques
pushed a commit
that referenced
this issue
Nov 6, 2015
>From source code comments:
"x0: 0 flush & invalidate, 1 invalidate only"
Current value 0xffff can make invalidate work, since we only judge whether
input value is 0 or not, see following code:
"
tbz w1, #0, 1f
dc isw, x9
b 2f
1: dc cisw, x9 /* clean & invalidate by set/way */
2: subs x6, x6, #1 /* decrement the way */
"
Later we may add "2 clean only" support. So following the comments,
correct value from 0xffff to 1.
Signed-off-by: Peng Fan <[email protected]>
Cc: York Sun <[email protected]>
Cc: Albert Aribaud <[email protected]>
johnjacques
pushed a commit
that referenced
this issue
Jun 17, 2016
After power-on, both LAPIC and I/O APIC appear with the same APIC ID zero, which creates an ID conflict. When generating MP table, U-Boot reports zero as the LAPIC ID in the processor entry, and zero as the I/O APIC ID in the I/O APIC as well as the I/O interrupt assignment entries. Such MP table confuses Linux kernel and finally a kernel panic is seen during boot: BUG: unable to handle kernel paging request at ffff9000 IP: [<c101d462>] native_io_apic_write+0x22/0x30 *pdpt = 00000000014fb001 *pde = 00000000014ff067 *pte = 0000000000000000 Oops: 0002 [#1] Modules linked in: Pid: 1, comm: swapper Tainted: G W 3.8.7 #3 intel galileo/galileo EIP: 0060:[<c101d462>] EFLAGS: 00010086 CPU: 0 EIP is at native_io_apic_write+0x22/0x30 ... Kernel panic - not syncing: Attempted to kill init! exitcode=0x00000009 Signed-off-by: Bin Meng <[email protected]> Reviewed-by: Simon Glass <[email protected]>
johnjacques
pushed a commit
that referenced
this issue
Sep 2, 2016
Booting a NXP kernel with mainline U-boot leads to the following kernel crash: caam: probe of 30900000.caam failed with error -11 Unable to handle kernel NULL pointer dereference at virtual address 00000004 pgd = 80004000 [00000004] *pgd=00000000 Internal error: Oops: 805 [#1] PREEMPT SMP ARM This happens because NXP kernel expects MX7 to boot in secure mode, so introduce mx7dsabresd_secure_defconfig that selects CONFIG_MX7_SEC and allows booting a NXP provided kernel successfully. Signed-off-by: Fabio Estevam <[email protected]>
johnjacques
pushed a commit
that referenced
this issue
Apr 30, 2018
If generating a script image and no datafile has been passed in, mkimage dies with SIGSEGV: #0 __strchr_sse2 () at ../sysdeps/x86_64/multiarch/../strchr.S:32 #1 0x0000000000403818 in main at tools/mkimage.c:503 Add explicit test for datafile to fix this. Signed-off-by: Alex Kiernan <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Since git 2.1, there have been a number of new fsck options added which produce issues when I clone the repository.
$ git fsck --full
Checking object directories: 100% (256/256), done.
error in tag eb394f56db3e05d00891d6dc36a00df0025cf255: unterminated header
error in tag 9bf86baaa3b35b25baa2d664e2f7f6cafad689ee: unterminated header
error in tag c7071e6d645a8e13adb0d4cea2caad27213fa62f: unterminated header
Checking objects: 100% (322303/322303), done.
Checking connectivity: 322303, done.
These new tests are enabled by default when using git fsck. I have been testing with git version 2.4.4.409.g5b1d901 and thought you might want to know so the error/warning messages can be corrected.
The text was updated successfully, but these errors were encountered: