Add Variable Page Size and IA64 Support in Intel IOMMU
cover Add Variable Page Size and IA64 Support in Intel IOMMU
The following two patches (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.
If applying only the generic patch on x86-64 kernel, x86-64 IOMMU is working fine, i.e. the generic patch doesn't have compilation and functionality impact on x86-64 IOMMU. If applying only the ia64 specific patch on ia64 kernel, ia64 is working as non-IOMMU/swiotlb case. If applying both of the patches and set CONFIG_DMAR=y, ia64 IOMMU is working.
Thanks.
-Fenghua
Quoted 1 line · Fenghua Yu
The following two patches (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.
General comment (not ia64-related): it looks like you detect the IOMMU using the static DMAR table. Does the IOMMU also appear in PCI config space or the ACPI namespace? I expect it would, because the fact that the DMAR table is static precludes any sort of hot-plug to add or remove IOMMUs.
If it *is* in config space or the namespace, it would be good to exercise that discovery path to help shake out firmware bugs. For example, arch/ia64/hp/common/sba_iommu.c uses acpi_bus_register_driver() to discover HP IOMMUs. I wouldn't hold the sba_iommu.c discovery code (most of which I take the blame for) up as a shining example of how to do things, but it shows the point.
Bjorn
Quoted 4 lines
Quoted 1 line
The following two patches (Intel IOMMU generic patch and ia64 specific
the fact that the DMAR table is static precludes any sort of hot-plug to add or remove IOMMUs.
The latest VT-d spec v1.1 does not support hot plug. If the feature is available in newer spec, we will support it.
Thanks.
-Fenghua
v2 cover Add Variable Page Size and IA64 Support in Intel IOMMU
In reply to Fenghua YuThe patche set (Intel IOMMU generic patch and ia64 specific patch) together enable Intel IOMMU on IA64 platform. They are applied cleanly on the latest linux-next tree which contains Intel IOMMU interrupt remapping and VT-d driver KVM support code.
If applying only the generic patch on x86-64 kernel, x86-64 IOMMU is working fine, i.e. the generic patch doesn't have compilation and functionality impact on x86-64 IOMMU. If applying only the ia64 specific patch on ia64 kernel, ia64 is working as non-IOMMU/swiotlb case. If applying both of the patches and set CONFIG_DMAR=y, ia64 IOMMU is working.
Thanks.
-Fenghua
PATCH 1/1 iwlan dma mapping read and write changes
In reply to Fenghua YuWhen iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE write bit is not set on some of PTE's. This is because iwlan driver calls DMA mapping with PCI_DMA_TODEVICE which is read only in mapping PTE. But iwlan device actually writes to the mapped page to update its contents. This issue is not exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault transaction.
The following patch fixes the issue.
---
iwl-tx.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)
drivers/net/wireless/iwlwifi/iwl-tx.c renamed from drivers/net/wireless/iwlwifi/iwl-tx.c.orig +4 -4
@@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct ipci_unmap_single (dev,pci_unmap_addr (&txq->cmd[index]->meta, mapping),pci_unmap_len (&txq->cmd[index]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );/* Unmap chunks, if any. */ for (i =1 ; i < num_tbs; i++) {
@@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st* within command buffer array. */ txcmd_phys =pci_map_single (priv->pci_dev, out_cmd,sizeof (struct iwl_cmd ), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, txcmd_phys);pci_unmap_len_set (&out_cmd->meta, len,sizeof (struct iwl_cmd ));/* Add buffer containing Tx command and MAC(!) header to TFD's
@@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr IWL_MAX_SCAN_SIZE :sizeof (struct iwl_cmd ); phys_addr =pci_map_single (priv->pci_dev, out_cmd, - len,PCI_DMA_TODEVICE ); + len,PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, phys_addr);pci_unmap_len_set (&out_cmd->meta, len, len); phys_addr += offsetof(struct iwl_cmd , hdr);
@@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(strucpci_unmap_single (priv->pci_dev,pci_unmap_addr (&txq->cmd[cmd_idx]->meta, mapping),pci_unmap_len (&txq->cmd[cmd_idx]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );for (idx =iwl_queue_inc_wrap (idx, q->n_bd); q->read_ptr != idx; q->read_ptr =iwl_queue_inc_wrap (q->read_ptr, q->n_bd)) {
RE: [PATCH]iwlan dma mapping read and write changes
Looks good to me. Ship it!
- Bhavesh
Bhavesh P. Davda
Quoted 75 lines
-----Original Message-----
From: [email protected] [mailto:iommu- [email protected]] On Behalf Of Fenghua Yu
Sent: Wednesday, February 11, 2009 10:27 AM
To: David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew Morton; Johannes Berg; Emmanuel Grumbach; Tomas Winkler; Zhu Yi; Chris Wright
Cc: [email protected]; LKML
Subject: [PATCH]iwlan dma mapping read and write changesWhen iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE
write bit is not set on some of PTE's. This is because iwlan driver calls DMA
mapping withPCI_DMA_TODEVICEwhich is read only in mapping PTE. But iwlan device
actually writes to the mapped page to update its contents. This issue is not
exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault
transaction.The following patch fixes the issue.
Signed-off-by Fenghua Yu <[email protected]>---
iwl-tx.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-)--- a/drivers/net/wireless/iwlwifi/iwl-tx.c.orig 2009-02-10
21:28:45.000000000 -0800
+++b/drivers/net/wireless/iwlwifi/iwl-tx.c2009-02-10
21:41:02.000000000 -0800drivers/net/wireless/iwlwifi/iwl-tx.c renamed from drivers/net/wireless/iwlwifi/iwl-tx.c.orig +1
-1@@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct ipci_unmap_single (dev,pci_unmap_addr (&txq->cmd[index]->meta, mapping),pci_unmap_len (&txq->cmd[index]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );/* Unmap chunks, if any. */ drivers/net/wireless/iwlwifi/iwl-tx.c renamed from drivers/net/wireless/iwlwifi/iwl-tx.c.orig +3
-3for (i =1 ; i < num_tbs; i++) {@@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st* within command buffer array. */ txcmd_phys =pci_map_single (priv->pci_dev, out_cmd,sizeof (struct iwl_cmd ), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, txcmd_phys);pci_unmap_len_set (&out_cmd->meta, len,sizeof (struct iwl_cmd ));/* Add buffer containing Tx command and MAC(!) header to TFD's @@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr IWL_MAX_SCAN_SIZE :sizeof (struct iwl_cmd ); phys_addr =pci_map_single (priv->pci_dev, out_cmd, - len,PCI_DMA_TODEVICE ); + len,PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, phys_addr);pci_unmap_len_set (&out_cmd->meta, len, len); phys_addr += offsetof(struct iwl_cmd , hdr);@@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(strucpci_unmap_single (priv->pci_dev,pci_unmap_addr (&txq->cmd[cmd_idx]->meta, mapping),pci_unmap_len (&txq->cmd[cmd_idx]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );for (idx =iwl_queue_inc_wrap (idx, q->n_bd); q->read_ptr != idx; q->read_ptr =iwl_queue_inc_wrap (q->read_ptr, q->n_bd)) {_______________________________________________
iommu mailing list
[email protected]
https://lists.linux-foundation.org/mailman/listinfo/iommu
Yu, Fenghua
Reviewed-by Bhavesh DavdaRE: [PATCH]iwlan dma mapping read and write changes
Quoted 7 lines
Looks good to me. Ship it!
- Bhavesh
Bhavesh P. Davda
Thanks.
-Fenghua
Re: [PATCH]iwlan dma mapping read and write changes
In reply to Fenghua YuQuoted 8 lines · * Fenghua Yu ([email protected]) wrote:
When iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE write bit is not set on some of PTE's. This is because iwlan driver calls DMA mapping with
PCI_DMA_TODEVICEwhich is read only in mapping PTE. But iwlan device actually writes to the mapped page to update its contents. This issue is not exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault transaction.The following patch fixes the issue.
Yes, plain old driver bug! This fixes the iwlagn vt-d issue.
Quoted 1 line
Signed-off-by Fenghua Yu <[email protected]>
thanks,
chris
RE: [PATCH]iwlan dma mapping read and write changes
In reply to Fenghua YuQuoted 22 lines
-----Original Message-----
From: Yu, Fenghua
Sent: Wednesday, February 11, 2009 8:27 PM
To: David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew Morton; Johannes Berg; Grumbach, Emmanuel; Winkler, Tomas; Zhu, Yi; Chris Wright
Cc: LKML; [email protected]
Subject: [PATCH]iwlan dma mapping read and write changesWhen iwlan runs on IOMMU, IOMMU generates a lot of PTE write faults because PTE
write bit is not set on some of PTE's. This is because iwlan driver calls DMA
mapping withPCI_DMA_TODEVICEwhich is read only in mapping PTE. But iwlan device
actually writes to the mapped page to update its contents. This issue is not
exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault
transaction.
Quoted 3 lines
The following patch fixes the issue.
Signed-off-by Fenghua Yu <[email protected]>
Indeed the firmware/ucode write back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.
Quoted 37 lines
---
iwl-tx.c| 8 ++++----1 files changed, 4 insertions(+), 4 deletions(-)--- a/drivers/net/wireless/iwlwifi/iwl-tx.c.orig 2009-02-10
21:28:45.000000000 -0800
+++b/drivers/net/wireless/iwlwifi/iwl-tx.c2009-02-10
21:41:02.000000000 -0800drivers/net/wireless/iwlwifi/iwl-tx.c renamed from drivers/net/wireless/iwlwifi/iwl-tx.c.orig +3
-3@@ -148,7 +148,7 @@ static void iwl_hw_txq_free_tfd(struct ipci_unmap_single (dev,pci_unmap_addr (&txq->cmd[index]->meta, mapping),pci_unmap_len (&txq->cmd[index]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );/* Unmap chunks, if any. */ for (i =1 ; i < num_tbs; i++) {@@ -964,7 +964,7 @@ int iwl_tx_skb(struct iwl_priv *priv, st* within command buffer array. */ txcmd_phys =pci_map_single (priv->pci_dev, out_cmd,sizeof (struct iwl_cmd ), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, txcmd_phys);pci_unmap_len_set (&out_cmd->meta, len,sizeof (struct iwl_cmd ));/* Add buffer containing Tx command and MAC(!) header to TFD's @@ -1115,7 +1115,7 @@ int iwl_enqueue_hcmd(struct iwl_priv *pr IWL_MAX_SCAN_SIZE :sizeof (struct iwl_cmd ); phys_addr =pci_map_single (priv->pci_dev, out_cmd, - len,PCI_DMA_TODEVICE ); + len,PCI_DMA_BIDIRECTIONAL );pci_unmap_addr_set (&out_cmd->meta, mapping, phys_addr);pci_unmap_len_set (&out_cmd->meta, len, len); phys_addr += offsetof(struct iwl_cmd , hdr);
drivers/net/wireless/iwlwifi/iwl-tx.c static void iwl_hcmd_queue_reclaim(struc · line 1218
Quoted 8 lines
drivers/net/wireless/iwlwifi/iwl-tx.c renamed from drivers/net/wireless/iwlwifi/iwl-tx.c.orig +1
-1@@ -1212,7 +1212,7 @@ static void iwl_hcmd_queue_reclaim(strucpci_unmap_single (priv->pci_dev,pci_unmap_addr (&txq->cmd[cmd_idx]->meta, mapping),pci_unmap_len (&txq->cmd[cmd_idx]->meta, len), -PCI_DMA_TODEVICE ); +PCI_DMA_BIDIRECTIONAL );for (idx =iwl_queue_inc_wrap (idx, q->n_bd); q->read_ptr != idx; q->read_ptr =iwl_queue_inc_wrap (q->read_ptr, q->n_bd)) {
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Johannes Berg
maintainerRE: [PATCH]iwlan dma mapping read and write changes
Quoted 8 lines · Tomas
Quoted 8 lines
mapping with
PCI_DMA_TODEVICEwhich is read only in mapping PTE. But iwlan device
actually writes to the mapped page to update its contents. This issue is not
exposed in swiotlb. But VT-d hardware can capture this fault and stop the fault
transaction.
Quoted 8 lines
Quoted 3 lines
The following patch fixes the issue.
Signed-off-by Fenghua Yu <[email protected]>Acked-by Tomas Winkler <[email protected]>Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.
I don't think they can be seeing AMPDU packets since that is, well, broken?
johannes
RE: [PATCH]iwlan dma mapping read and write changes
Quoted 26 lines
-----Original Message-----
From: Johannes Berg [mailto:[email protected]]
Sent: Wednesday, February 11, 2009 11:34 PM
To: Winkler, Tomas
Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Andrew Morton; Grumbach, Emmanuel; Zhu, Yi; Chris Wright; LKML; [email protected] foundation.org
Subject: RE: [PATCH]iwlan dma mapping read and write changesQuoted 1 line · Tomas
Quoted 1 line
mapping with
PCI_DMA_TODEVICEwhich is read only in mapping PTE. Butiwlan
Quoted 4 lines
Quoted 4 lines
device
actually writes to the mapped page to update its contents. This issue is not
exposed in swiotlb. But VT-d hardware can capture this fault and stopthe
Quoted 6 lines
Quoted 6 lines
fault
transaction.The following patch fixes the issue.
Signed-off-by Fenghua Yu <[email protected]>
Quoted 8 lines
Quoted 5 lines
Acked-by Tomas Winkler <[email protected]>Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow. Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Johannes Berg
maintainerRE: [PATCH]iwlan dma mapping read and write changes
Quoted 11 lines
Quoted 7 lines
Quoted 4 lines
Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
I don't think it really matters, since AMPDU packets will be fixed soon, and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
johannes
Johannes Berg
maintainerRE: [PATCH]iwlan dma mapping read and write changes
Quoted 11 lines · Johannes Berg
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
Quoted 5 lines
I don't think it really matters, since AMPDU packets will be fixed soon, and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
Or if there's a firmware bug.
johannes
RE: [PATCH]iwlan dma mapping read and write changes
Quoted 22 lines
-----Original Message-----
From: Johannes Berg [mailto:[email protected]]
Sent: Wednesday, February 11, 2009 11:50 PM
To: Winkler, Tomas
Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Grumbach, Emmanuel; Zhu, Yi; Chris Wright; LKML; [email protected]
Subject: RE: [PATCH]iwlan dma mapping read and write changesQuoted 11 lines · Johannes Berg
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
Quoted 7 lines
Quoted 5 lines
I don't think it really matters, since AMPDU packets will be fixed soon, and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
Or if there's a firmware bug.
That's why it's better to clear the picture.
Fenghua
What exact HW do you get this error?
Thanks
Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
RE: [PATCH]iwlan dma mapping read and write changes
Quoted 17 lines
Quoted 11 lines
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Quoted 3 lines
Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
Quoted 5 lines
I don't think it really matters, since AMPDU packets will be fixed soon, and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
Quoted 5 lines
Or if there's a firmware bug.
That's why it's better to clear the picture.
Fenghua
What exact HW do you get this error?
This is Lenovo T400 wireless lan. Firmware version is 5.4.1.16. I think this issue happens on other platform/hw as well.
Thanks.
-Fenghua
RE: [PATCH]iwlan dma mapping read and write changes
In reply to Winkler, TomasQuoted 27 lines · Tomas
Quoted 27 lines
-----Original Message-----
From: Johannes Berg [mailto:[email protected]]
Sent: Wednesday, February 11, 2009 11:50 PM
To: Winkler, Tomas
Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell; Grumbach, Emmanuel; Zhu, Yi; Chris Wright; LKML; [email protected]
Subject: RE: [PATCH]iwlan dma mapping read and write changesQuoted 16 lines · Johannes Berg
Quoted 10 lines
Quoted 6 lines
Quoted 3 lines
Indeed the
firmware/ucodewrite back to host memory to update retry counter for APMDU packets. I'm not sure if this is needed for legacy traffic, though.I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
I don't think it really matters, since AMPDU packets will be fixed soon, and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
Quoted 5 lines
Quoted 1 line
Or if there's a firmware bug.
That's why it's better to clear the picture.
Fenghua
What exact HW do you get this error?
Lenovo T400.
00:00.0 0600: 8086:2a40 (rev 07) 00:02.0 0300: 8086:2a42 (rev 07) 00:02.1 0380: 8086:2a43 (rev 07) 00:03.0 0780: 8086:2a44 (rev 07) 00:03.2 0101: 8086:2a46 (rev 07) 00:03.3 0700: 8086:2a47 (rev 07) 00:19.0 0200: 8086:10f5 (rev 03) 00:1a.0 0c03: 8086:2937 (rev 03) 00:1a.1 0c03: 8086:2938 (rev 03) 00:1a.2 0c03: 8086:2939 (rev 03) 00:1a.7 0c03: 8086:293c (rev 03) 00:1b.0 0403: 8086:293e (rev 03) 00:1c.0 0604: 8086:2940 (rev 03) 00:1c.1 0604: 8086:2942 (rev 03) 00:1c.2 0604: 8086:2944 (rev 03) 00:1c.3 0604: 8086:2946 (rev 03) 00:1c.4 0604: 8086:2948 (rev 03) 00:1d.0 0c03: 8086:2934 (rev 03) 00:1d.1 0c03: 8086:2935 (rev 03) 00:1d.2 0c03: 8086:2936 (rev 03) 00:1d.7 0c03: 8086:293a (rev 03) 00:1e.0 0604: 8086:2448 (rev 93) 00:1f.0 0601: 8086:2917 (rev 03) 00:1f.2 0106: 8086:2929 (rev 03) 00:1f.3 0c05: 8086:2930 (rev 03) 03:00.0 0280: 8086:4236 04:00.0 0580: 8086:444e (rev 11) 15:00.0 0607: 1180:0476 (rev ba) 15:00.1 0c00: 1180:0832 (rev 04)
Signature · 1 line
dwmw2
RE: [PATCH]iwlan dma mapping read and write changes
Quoted 48 lines
-----Original Message-----
From: David Woodhouse [mailto:[email protected]]
Sent: Thursday, February 12, 2009 12:14 AM
To: Winkler, Tomas
Cc: Johannes Berg; Yu, Fenghua; Ingo Molnar; Stephen Rothwell; Grumbach, Emmanuel; Zhu, Yi; Chris Wright; LKML; [email protected]
Subject: RE: [PATCH]iwlan dma mapping read and write changesQuoted 6 lines · Tomas
Quoted 6 lines
-----Original Message-----
From: Johannes Berg [mailto:[email protected]]
Sent: Wednesday, February 11, 2009 11:50 PM
To: Winkler, Tomas
Cc: Yu, Fenghua; David Woodhouse; Ingo Molnar; Stephen Rothwell;Grumbach,
Quoted 5 lines
Quoted 5 lines
Emmanuel; Zhu, Yi; Chris Wright; LKML; [email protected]
Subject: RE: [PATCH]iwlan dma mapping read and write changesQuoted 1 line · Johannes Berg
Quoted 1 line
Quoted 1 line
Quoted 1 line
Indeed the
firmware/ucodewrite back to host memory to updateretry
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
counter for APMDU packets. I'm not sure if this is needed for
legacy
Quoted 10 lines
Quoted 10 lines
Quoted 10 lines
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
traffic, though.
I don't think they can be seeing AMPDU packets since that is, well, broken?
Currently I'm not aware of any other cases where memory is accessed back but I may have not complete info. Will be back with the answer tomorrow.
I don't think it really matters, since AMPDU packets will be fixed
soon,
Quoted 10 lines
Quoted 6 lines
Quoted 4 lines
and for those you know it's necessary (and the report says that under some other circumstances it's also necessary). Unless there'd be some benefit from using BIDI only when we know it'll be needed, and using TODEV in the other cases?
Or if there's a firmware bug.
That's why it's better to clear the picture.
Fenghua
What exact HW do you get this error?
Quoted 6 lines
Lenovo T400.
03:00.0 0280: 8086:4236
I can confirm that for 5000 series the patch is required also for regular frames. In this particular machine the NIC is 5300. For 4965 only for AMPDU frames are affected also the implementation is not the same but I'm not sure if it makes any sense to differentiate.
Does anybody know what performance implications of this change are?
Thanks Tomas
---------------------------------------------------------------------
Intel Israel (74) Limited
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.