Thanks to Feng pointing me in the right direction, I've got this starting to
work but I have encountered some strangeness.
I wrote the PEIM below to configure the xHCI controller and install the
PEI_USB_CONTROLLER_PPI.
I was seeing some problems reading device and config descriptors and found
th
Hi Feng,
I am OK with step #1, it shall solve our problem. For step #2, it is good but a
little complex, if sending the abort command after timeout, there are following
possible results:
1. The last command's completion comes first.
2. The abort command's completion comes first.
3. No completio
Hi, Wenbo
Here "queue handling" what I meant is s/w SQ/CQ handling in EDKII NvmExpressDxe
driver, we don't check command ID. We just check PT to know if there is a new
completion queue entry. So with current logic, if there is a timeout happen and
the upper layer send another command again, the
Because each command has an unique command ID, queue handling shall not miss up
even if the completion is returned after timeout.
-Original Message-
From: Wenbo Wang [mailto:wenbo.w...@memblaze.com]
Sent: Tuesday, September 8, 2015 10:23 AM
To: 'Tian, Feng'; 'edk2-devel@lists.01.org'
Sub
Thanks Feng.
In our test, when the command timeout, the completion queue is empty (head ==
tail), in this case if the driver moves head (head++), it corrupts the
completion queue, the NVMe controller generates error. I think the HW behavior
is correct because the driver shall not move head if t
Hi, Wenbo
Why we advanced one CQ entry in line 592 whatever the execution result of SQ is
because there are two cases:
1. If timeout happens and no new completion queue entry is added, the CQH get
updated to point to next entry. Nvme controller would know a new entry of
completion queue is avai
Reviewed-by: Fu Siyuan
-Original Message-
From: Wu, Jiaxin
Sent: Tuesday, September 8, 2015 9:41 AM
To: edk2-devel@lists.01.org
Cc: Ye, Ting ; Fu, Siyuan
Subject: [Patch] NetworkPkg: Fix suspicious dereference of pointer 'FieldCount'
This patch is used to fix suspicious dereference of
This patch is used to fix suspicious dereference of pointer 'FieldCount'
before NULL check.
Cc: Ye Ting
Cc: Fu Siyuan
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiaxin Wu
---
NetworkPkg/HttpUtilitiesDxe/HttpUtilitiesProtocol.c | 2 +-
1 file changed, 1 insertion(+),
Hi Sudeep,
I'm not involved in ACPI development, so am not able to review this.
Regards,
Ryan.
On 7 September 2015 at 17:07, Sudeep Holla wrote:
> Currently the MADT signature and revision is mapped to v1.0 macros
> which results in MADT with incorrect entries in the header for Juno.
> This pa
Currently the MADT signature and revision is mapped to v1.0 macros
which results in MADT with incorrect entries in the header for Juno.
This patch fixes these EFI_ACPI_*_0_MULTIPLE_APIC_DESCRIPTION_TABLE
macros by using appropriate v5.0 versions.
Contributed-under: TianoCore Contribution Agreement
On 7 September 2015 at 10:41, Heyi Guo wrote:
>
>
> On 09/06/2015 07:43 PM, Ard Biesheuvel wrote:
>>
>> On 6 September 2015 at 10:15, Heyi Guo wrote:
>>>
>>> The code has a simple bug on calculating aligned page table address.
>>> We need to add alignment - 1 to allocated address first and then m
On 09/07/15 09:34, Ard Biesheuvel wrote:
> On 6 September 2015 at 14:22, Leif Lindholm wrote:
>> On 6 September 2015 at 13:05, Ard Biesheuvel
>> wrote:
>>> On 6 September 2015 at 14:04, Leif Lindholm
>>> wrote:
On 6 September 2015 at 12:52, Ard Biesheuvel
wrote:
> On 6 Septembe
On 6 September 2015 at 10:15, Heyi Guo wrote:
> Below code has bug since *BlockEntrySize and *TableLevel are not
> updated accordingly:
>
> if (IndexLevel == PageLevel) {
> // And get the appropriate BlockEntry at the next level
> BlockEntry = (UINT64*)TT_GET_ENTRY_FOR_ADDRESS (TranslationTabl
On 09/07/15 01:55, Jordan Justen wrote:
> On 2015-07-24 16:00:12, Laszlo Ersek wrote:
>> If OVMF was built with -D SMM_REQUIRE, that implies that the runtime OS is
>> not trusted and we should defend against it tampering with the firmware's
>> data.
>>
>> One such datum is the PEI firmware volume (
On 09/06/15 21:56, Jordan Justen wrote:
> On 2015-07-24 16:00:11, Laszlo Ersek wrote:
>> The DecompressMemFvs() function in "OvmfPkg/Sec/SecMain.c" uses more
>> memory, temporarily, than what PEIFV and DXEFV will ultimately need.
>> First, it uses an output buffer for decompression, second, the
>>
Jordan:
I don't know the real usage of the multiple image support. I just want to
focus on the issue and avoid the behavior change in this library instance.
For the alternative solutions, I prefer option 2 to let platform make sure the
memory range is clear before usage.
Thanks
Liming
-
On 09/06/15 20:31, Jordan Justen wrote:
> On 2015-09-05 23:43:27, Gao, Liming wrote:
>> Laszlo:
>> Yes. Current design supports to share GuidedTable pointed by
>> PcdGuidedExtractHandlerTableAddress between the different drivers.
>
> This multiple image support was actually designed into the
>
On 09/06/15 08:09, Tian, Feng wrote:
> Hi, Laszlo
>
> Thanks for root cause this issue.
>
> We ever met the same issue when installing windows 8 32bit through
> cdrom and we found:
>
> 1) Why 32bit UEFI win8 OS installation fails with some DVD-Only
> devices is because OS would invoke a single read
Hi,
The following code is from NvmExpressPassthru.c, at line 592, the cq head is
updated even if the command timeout. Is there any reason for this?
If completion queue is empty, this operation may corrupt the queue.
Thanks,
-Wenbo
Code Copied from the latest NvmExpressPassthru.c ==
On 7 September 2015 at 11:16, Heyi Guo wrote:
>
>
> On 09/06/2015 09:42 PM, Ard Biesheuvel wrote:
>>
>> On 6 September 2015 at 10:15, Heyi Guo wrote:
>>>
>>> Below code has bug since *BlockEntrySize and *TableLevel are not
>>> updated accordingly:
>>>
>>> if (IndexLevel == PageLevel) {
>>>//
On 09/06/2015 09:42 PM, Ard Biesheuvel wrote:
On 6 September 2015 at 10:15, Heyi Guo wrote:
Below code has bug since *BlockEntrySize and *TableLevel are not
updated accordingly:
if (IndexLevel == PageLevel) {
// And get the appropriate BlockEntry at the next level
BlockEntry = (UINT64*
On 09/06/2015 07:43 PM, Ard Biesheuvel wrote:
On 6 September 2015 at 10:15, Heyi Guo wrote:
The code has a simple bug on calculating aligned page table address.
We need to add alignment - 1 to allocated address first and then mask
the unaligned bits.
Nice find!
Contributed-under: TianoCor
On 6 September 2015 at 14:22, Leif Lindholm wrote:
> On 6 September 2015 at 13:05, Ard Biesheuvel
> wrote:
>> On 6 September 2015 at 14:04, Leif Lindholm wrote:
>>> On 6 September 2015 at 12:52, Ard Biesheuvel
>>> wrote:
On 6 September 2015 at 10:15, Heyi Guo wrote:
> There is a hid
23 matches
Mail list logo
