> On 9. veebr 2017, at 17:05, Karl Denninger <k...@denninger.net> wrote:
>
>
> On 2/9/2017 08:58, Toomas Soome wrote:
>>> On 9. veebr 2017, at 16:36, Karl Denninger <k...@denninger.net>
>>> <mailto:k...@denninger.net> wrote:
>>>
>>>
>>> On 2/8/2017 16:18, Karl Denninger wrote:
>>>> r313441 blows up on the Pi3 in /boot/loader.efi with:
>>>>
>>>> FreeBSD/arm64 EFI loader, Revision 1.1
>>>> (Tue Feb 7 15:15:52 CST 2017 free...@newfs.denninger.net
>>>> <mailto:free...@newfs.denninger.net>)
>>>> Failed to start image provided by UFS (14)
>>>> "Synchronous Abort" handler, esr 0x96000004
>>>> ELR: 3af62cec
>>>> LR: 3af61d60
>>>> x0 : 0000000000000001 x1 : 0000000000000001
>>>> x2 : 000000003afeb000 x3 : 000000000000003f
>>>> x4 : 0000000000000020 x5 : 0000000000000010
>>>> x6 : 0000000000000000 x7 : 0000000039b260a4
>>>> x8 : 000000003af61d48 x9 : 000000000000000d
>>>> x10: 0000000000000030 x11: 0000000000000000
>>>> x12: 0000000000000000 x13: 0000000000000002
>>>> x14: 0000000000000000 x15: 0000000000000000
>>>> x16: 0000000000000000 x17: 0000000000000000
>>>> x18: 000000003ab30df8 x19: 0000000037a16008
>>>> x20: 0000000000000000 x21: 0000000000000000
>>>> x22: 0000000039b28000 x23: 0000000039b1d49c
>>>> x24: 0000000039b28850 x25: 000000003ab3d740
>>>> x26: 000000003af839a0 x27: 0000000039b2e3e8
>>>> x28: 0000000000000000 x29: 000000003ab2ef60
>>>>
>>>> Resetting CPU ...
>>>>
>>>> If you copy in a loader.efi from an earlier build (e.g. r313109) then the
>>>> system boots but complains about SMP problems, fails to start any of the
>>>> other CPUs (although it sees them) and panics before it reaches a login
>>>> prompt with what appears to be a problem reading the SD card (I also get a
>>>> couple of lor's in here too..... not sure if those are "real" or false
>>>> positives)
>>>>
>>>> B
>>> This has been isolated to r313333 in sys/boot/efi; reverting the EFI
>>> loader to a previous revision stops the crash.
>>>
>>> Filed here: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216940>
>>>
>> Does it still crash with r313442? I think it does and this is why:
>>
>> From your log above, the hint is "Failed to start image provided by UFS
>> (14)”, so what we can guess here is that for some reason the loader.efi
>> main() failed to detect the boot device, and did return back to boot1.
>>
>> Boot1 did print out this error message and did call panic(). So, the
>> question is, why it is failing to detect the root fs handle. I’ll try to
>> check if I can replicate the issue with x86 + ufs.
>>
>> BTW: sorry for trouble:)
>>
>> rgds,
>> toomas
>>
> Yes.
>
> It's isolated to that particular revision, which appears to have reworked the
> enumeration of the available devices to boot from. Reverting only
> sys/boot/efi to anything before 313333 (e.g. "svn update -r 313332 ." in
> src/sys/boot/efi) and rebuilding results in a loader.efi that successfully
> loads and starts the kernel.
>
Well, the x86 version does not appear to have problems with finding the ufs
devices. So this has to be some sort of corner case related to arm:(
unfortunately I do not have much variants to test arm, except qemu… so some
help would be needed there. Since the only crash is from boot1 call to panic, I
am pretty sure the disk detection and setup was ok, so we should get disk list
if we insert something like:
for (i = 0; devsw[i] != NULL; i++) {
if (devsw[i]->dv_print != NULL){
if (devsw[i]->dv_print(verbose))
break;
}
}
after dv_init() loop.
If thats true, then it should not take too much to find why we fail to get the
handle for root fs in case of arm…
rgds,
toomas
_______________________________________________
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
