grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH 1/2] disk: Add support for device-specific malloc function


From: Andrei Borzenkov
Subject: Re: [PATCH 1/2] disk: Add support for device-specific malloc function
Date: Fri, 26 Feb 2016 16:48:32 +0300

On Fri, Feb 26, 2016 at 4:27 PM, Vladimir 'phcoder' Serbinenko
<address@hidden> wrote:
> Andrei, your patch is pretty complicated and would be a subject to putting
> into next branch because of its breakage potential. Issue at hand affects
> x86 as well. Can we split the solution from radical rework of disk.c with
> optimisations?
>

Then we need to add additional small read to for unaligned beginning
of user supplied buffer in main agglomeration loop. It is doable I
think.

> Le mer. 24 févr. 2016 20:04, Andrei Borzenkov <address@hidden> a écrit
> :
>>
>> 24.02.2016 20:40, Andrei Borzenkov пишет:
>> > 24.02.2016 16:57, Leif Lindholm пишет:
>> >> On Wed, Feb 24, 2016 at 03:09:13PM +0300, Andrei Borzenkov wrote:
>> >>>>> Could you test attached patch with your alignment fixes on top. This
>> >>>>> implements my idea of using shared buffers. Seems to work in naive
>> >>>>> testing.
>> >>>>
>> >>>> Testing this with a grub-mkstandalone image, I get:
>> >>>>
>> >>>> kern/dl.c:556: flushing 0x10f1 bytes at 0x9ffb5ac20
>> >>>> kern/dl.c:649: module name: tar
>> >>>> kern/dl.c:650: init function: 0x9ffb5b220
>> >>>> kern/disk.c:217: Opening `memdisk'...
>> >>>> kern/fs.c:56: Detecting tarfs...
>> >>>>
>> >>>> And then spectacular crash in UEFI due to an EL2 translation fault.
>> >>>
>> >>> To be sure - is it with my patch alone or with your patches? If some
>> >>> more patches are used - could you send exact diff to trunk to avoid
>> >>> misunderstanding?
>> >>
>> >> Double checked with only your patch on top of
>> >> 1b782e902e69516f82158203674d4951a40c82d4 (previously running with
>> >> _only_ my alignment fixup in efidisk.c). Same behaviour.
>> >
>> > I cannot reproduce it on x86_64 (also with mm-debug enabled) and I do
>> > not know how to load standalone image on ppc; is it possible to use QEMU
>> > to run ARM64 (I assume you have it)? If not what are options to test it?
>> >
>> > Anyway, there was one problem I fixed later (although I did not get any
>> > issue before as well), I attach updated version. Thank you for testing!
>> >
>>
>> I still cannot reproduce it with either patch version using current GIT
>> QEMU + binary QEMU_EFI.fd from
>>
>> http://snapshots.linaro.org/components/kernel/leg-virt-tianocore-edk2-upstream/554/QEMU-AARCH64/RELEASE_GCC49/QEMU_EFI.fd;
>> I run it as
>>
>> aarch64-softmmu/qemu-system-aarch64  -m 1024 -cpu cortex-a57 -M virt
>> -bios ~/vm/QEMU_EFI.fd -cdrom /tmp/grub.iso -serial stdio
>>
>> Where grub.iso is built
>>
>> pkgdatadir=$PWD ./grub-mkstandalone -d grub-core -O arm64-efi -o
>> /tmp/grub.efi
>> pkgdatadir=$PWD ./grub-mkrescue -d grub-core -o /tmp/grub.iso
>> /grub.efi=/tmp/grub.efi
>>
>> and I do
>>
>> chainloader /grub.efi
>> boot
>>
>> after that.
>>
>> _______________________________________________
>> Grub-devel mailing list
>> address@hidden
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> https://lists.gnu.org/mailman/listinfo/grub-devel
>



reply via email to

[Prev in Thread] Current Thread [Next in Thread]