>>> Could you also please send the me the FW version (output of "ethtool -i
>> eth0")
>>
>> Hi Sathya, thanks for your help. FW version is 4.6.247.5 driver version is
>> 4.4.161.0s
>
> Hi Wang, this issue (a FW bug) was fixed in the 4.9 FW series.
> The HP qualified FW (ver 4.9.416.0) is availa
> -Original Message-
> From: Yijing Wang [mailto:wangyij...@huawei.com]
>
> [Adding the Emulex driver developers to Cc for some input on the
> device,
> and why it might use wrong request ids]
>
> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
> >
On 8/25/2014 9:51 PM, Yijing Wang wrote:
> On 2014/8/25 23:04, David Woodhouse wrote:
>> On Mon, 2014-08-25 at 12:11 +, Sathya Perla wrote:
>>>
>>> Hi Wang, from the kernel log I can see that the faulting address
>>> 0xbdf7 falls in the
>>> RMRR range the BIOS requested:
>>> [0.111343]
On 2014/8/25 17:15, Joerg Roedel wrote:
> [Adding the Emulex driver developers to Cc for some input on the device,
> and why it might use wrong request ids]
Thanks!
>
> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
>> We found some strange devices in HP C7000 and Huawei Storage S
On 2014/8/25 23:04, David Woodhouse wrote:
> On Mon, 2014-08-25 at 12:11 +, Sathya Perla wrote:
>>
>> Hi Wang, from the kernel log I can see that the faulting address
>> 0xbdf7 falls in the
>> RMRR range the BIOS requested:
>> [0.111343] DMAR: RMRR base: 0x00bdf6f000 end: 0x00bd
> -Original Message-
> From: Joerg Roedel [mailto:j...@8bytes.org]
>
> [Adding the Emulex driver developers to Cc for some input on the device,
> and why it might use wrong request ids]
>
> On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
> > We found some strange devices in
> -Original Message-
> From: Yijing Wang [mailto:wangyij...@huawei.com]
>
> On 2014/8/25 17:32, Sathya Perla wrote:
> >> -Original Message-
> >> From: Joerg Roedel [mailto:j...@8bytes.org]
> >>
> >> [Adding the Emulex driver developers to Cc for some input on the device,
> >> and
On Mon, 2014-08-25 at 12:11 +, Sathya Perla wrote:
>
> Hi Wang, from the kernel log I can see that the faulting address
> 0xbdf7 falls in the
> RMRR range the BIOS requested:
> [0.111343] DMAR: RMRR base: 0x00bdf6f000 end: 0x00bdf7efff
We can't see which *devices* that RMRR wa
On 2014/8/25 20:11, Sathya Perla wrote:
>> -Original Message-
>> From: Yijing Wang [mailto:wangyij...@huawei.com]
>>
>> On 2014/8/25 17:32, Sathya Perla wrote:
-Original Message-
From: Joerg Roedel [mailto:j...@8bytes.org]
[Adding the Emulex driver developers to
[Adding the Emulex driver developers to Cc for some input on the device,
and why it might use wrong request ids]
On Mon, Aug 25, 2014 at 02:44:59PM +0800, Yijing Wang wrote:
> We found some strange devices in HP C7000 and Huawei Storage Server. These
> devices can not be enumerated by OS, but the
>> +/* We found some strange devices in HP c7000 and other platforms, they
>> + * can not be enumerated by OS, and they did DMA read/write without
>> + * driver management. if we open iommu in these platforms, the DMA
>> read/write
>> + * will be blocked by IOMMU hardware. Currently
iang Liu
> Subject: [PATCH v2] iommu/vt-d: Fix broken device issue when using iommu=pt
>
> We found some strange devices in HP C7000 and Huawei Storage Server. These
> devices can not be enumerated by OS, but they still did DMA read/write
> without OS management. Because iommu will not c
We found some strange devices in HP C7000 and Huawei Storage Server. These
devices can not be enumerated by OS, but they still did DMA read/write
without OS management. Because iommu will not create the DMA mapping for
these devices, the DMA read/write will be blocked by iommu hardware.
Eg.
in HP
13 matches
Mail list logo
