On Sat, 06 Sep, at 11:09:04PM, Mantas Mikulėnas wrote:
>
> Finally got around to testing the patches here. Sorry for no replies earlier.
>
> This seemed like it would work, but... it hangs at the memcpy?...
>
> (If I add a printk before memcpy and a printk after memcpy, I never
> see the second
On Sat, Sep 6, 2014 at 11:09 PM, Mantas Mikulėnas wrote:
> On Sat, Sep 6, 2014 at 1:16 AM, Matt Fleming wrote:
>> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>>
>>> I am fine with this patch, but at the same time I do want to note that
>>> there is an alternative to double-buffer the pa
On Sat, Sep 6, 2014 at 1:16 AM, Matt Fleming wrote:
> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>
>> I am fine with this patch, but at the same time I do want to note that
>> there is an alternative to double-buffer the patch and/or (if that
>> applies to the buggy BIOS) round up the s
* Matt Fleming [140906 00:16]:
> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
> > I am fine with this patch, but at the same time I do want to note that
> > there is an alternative to double-buffer the patch and/or (if that
> > applies to the buggy BIOS) round up the size of the target b
On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>
> I am fine with this patch, but at the same time I do want to note that
> there is an alternative to double-buffer the patch and/or (if that
> applies to the buggy BIOS) round up the size of the target buffer.
I took a whack at the double-bu
On 09/05/14 19:03, Yinghai Lu wrote:
> On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek wrote:
>> On 09/05/14 07:47, Anders Darander wrote:
>> In other words, the rounding up of the kernel will be undone in a
>> "somewhat higher level" driver in the firmware, and the request size
>> that reaches Disk
On Thu, Sep 4, 2014 at 11:38 PM, Laszlo Ersek wrote:
> On 09/05/14 07:47, Anders Darander wrote:
> In other words, the rounding up of the kernel will be undone in a
> "somewhat higher level" driver in the firmware, and the request size
> that reaches DiskIo (the "lowel level driver") remains the s
On 09/05/14 07:47, Anders Darander wrote:
> * Yinghai Lu [140905 03:19]:
>
>
>> On Thu, Sep 4, 2014 at 2:29 PM, Matt Fleming wrote:
>>> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>
I am fine with this patch, but at the same time I do want to note that
there is an alternativ
* Yinghai Lu [140905 03:19]:
> On Thu, Sep 4, 2014 at 2:29 PM, Matt Fleming wrote:
> > On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
> >> I am fine with this patch, but at the same time I do want to note that
> >> there is an alternative to double-buffer the patch and/or (if that
> >> a
On Thu, Sep 4, 2014 at 2:29 PM, Matt Fleming wrote:
> On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>>
>> I am fine with this patch, but at the same time I do want to note that
>> there is an alternative to double-buffer the patch and/or (if that
>> applies to the buggy BIOS) round up the s
On Thu, 04 Sep, at 01:59:05PM, H. Peter Anvin wrote:
>
> I am fine with this patch, but at the same time I do want to note that
> there is an alternative to double-buffer the patch and/or (if that
> applies to the buggy BIOS) round up the size of the target buffer.
I'm not sure that rounding up t
On 09/04/2014 03:01 AM, Matt Fleming wrote:
> On Wed, 03 Sep, at 09:50:07PM, Yinghai Lu wrote:
>> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
>> loaded above 4G"), the kernel freezes at the earliest possible moment
>> when trying to boot via UEFI on Asus laptop.
>>
>> Reve
On Wed, 03 Sep, at 09:50:07PM, Yinghai Lu wrote:
> Mantas found that after commit 4bf7111f5016 ("x86/efi: Support initrd
> loaded above 4G"), the kernel freezes at the earliest possible moment
> when trying to boot via UEFI on Asus laptop.
>
> Revert to old way to load initrd under 4G on first try
13 matches
Mail list logo
