ieee80211_tx_status: headroom too small

ieee80211_tx_status: headroom too small

[David Ellingsworth]

Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
kernel built from the wireless-testing repository I'm getting a number
of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
using the rt61pci driver in conjunction with hostap as a wpa2 secured
access point. The relevant information about my card from lspci is:

01:08.0 0280: 1814:0301
        Subsystem: 1458:e934
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
        Latency: 64, Cache Line Size: 128 bytes
        Interrupt: pin A routed to IRQ 18
        Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
        Capabilities: [40] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
        Kernel driver in use: rt61pci

If you need any other information, I'll be happy to provide it.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 1560 bytes --]

On 11/21/09 02:30, David Ellingsworth wrote:
> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
> kernel built from the wireless-testing repository I'm getting a number
> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
> using the rt61pci driver in conjunction with hostap as a wpa2 secured
> access point. The relevant information about my card from lspci is:
> 
> 01:08.0 0280: 1814:0301
>         Subsystem: 1458:e934
>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
> <TAbort- <MAbort- >SERR- <PERR- INTx-
>         Latency: 64, Cache Line Size: 128 bytes
>         Interrupt: pin A routed to IRQ 18
>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>         Capabilities: [40] Power Management version 2
>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>         Kernel driver in use: rt61pci
> 
> If you need any other information, I'll be happy to provide it.
> 

Hi David,

This seems to be caused by the rt2x00 driver not properly declaring its alignment
maneuvring space properly, and thus it doesn't leave enough headroom left for
copying to the monitor interface.

Can you check whether the attached patch fixes the issue for you?
Note: patch looks a bit bigger than it actually is due to indenting cleanups.

---
Gertjan.


[-- Attachment #2: align_fix.diff --]
[-- Type: text/plain, Size: 14419 bytes --]

diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 6e68bc7..f534d70 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1432,7 +1432,8 @@ static int rt2400pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SIGNAL_DBM |
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1623,20 +1624,21 @@ static const struct data_queue_desc rt2400pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2400pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2400pci_queue_rx,
-	.tx		= &rt2400pci_queue_tx,
-	.bcn		= &rt2400pci_queue_bcn,
-	.atim		= &rt2400pci_queue_atim,
-	.lib		= &rt2400pci_rt2x00_ops,
-	.hw		= &rt2400pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2400pci_queue_rx,
+	.tx			= &rt2400pci_queue_tx,
+	.bcn			= &rt2400pci_queue_bcn,
+	.atim			= &rt2400pci_queue_atim,
+	.lib			= &rt2400pci_rt2x00_ops,
+	.hw			= &rt2400pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2400pci_rt2x00debug,
+	.debugfs		= &rt2400pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 9a31e5e..ae40947 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1733,7 +1733,8 @@ static int rt2500pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1922,20 +1923,21 @@ static const struct data_queue_desc rt2500pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500pci_queue_rx,
-	.tx		= &rt2500pci_queue_tx,
-	.bcn		= &rt2500pci_queue_bcn,
-	.atim		= &rt2500pci_queue_atim,
-	.lib		= &rt2500pci_rt2x00_ops,
-	.hw		= &rt2500pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2500pci_queue_rx,
+	.tx			= &rt2500pci_queue_tx,
+	.bcn			= &rt2500pci_queue_bcn,
+	.atim			= &rt2500pci_queue_atim,
+	.lib			= &rt2500pci_rt2x00_ops,
+	.hw			= &rt2500pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500pci_rt2x00debug,
+	.debugfs		= &rt2500pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index b2de43e..02b2e1c 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1656,7 +1656,7 @@ static int rt2500usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1823,20 +1823,21 @@ static const struct data_queue_desc rt2500usb_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500usb_queue_rx,
-	.tx		= &rt2500usb_queue_tx,
-	.bcn		= &rt2500usb_queue_bcn,
-	.atim		= &rt2500usb_queue_atim,
-	.lib		= &rt2500usb_rt2x00_ops,
-	.hw		= &rt2500usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt2500usb_queue_rx,
+	.tx			= &rt2500usb_queue_tx,
+	.bcn			= &rt2500usb_queue_bcn,
+	.atim			= &rt2500usb_queue_atim,
+	.lib			= &rt2500usb_rt2x00_ops,
+	.hw			= &rt2500usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500usb_rt2x00debug,
+	.debugfs		= &rt2500usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index b809c49..de358b5 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -2030,11 +2030,8 @@ int rt2800_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	if (rt2x00_intf_is_usb(rt2x00dev))
-		rt2x00dev->hw->extra_tx_headroom =
-			TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
-	else if (rt2x00_intf_is_pci(rt2x00dev))
-		rt2x00dev->hw->extra_tx_headroom = TXWI_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_L2PAD_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
diff --git a/drivers/net/wireless/rt2x00/rt2800pci.c b/drivers/net/wireless/rt2x00/rt2800pci.c
index 87a5094..dfc886f 100644
--- a/drivers/net/wireless/rt2x00/rt2800pci.c
+++ b/drivers/net/wireless/rt2x00/rt2800pci.c
@@ -652,7 +652,7 @@ static void rt2800pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
 {
 	struct skb_frame_desc *skbdesc = get_skb_frame_desc(skb);
 	__le32 *txd = skbdesc->desc;
-	__le32 *txwi = (__le32 *)(skb->data - rt2x00dev->hw->extra_tx_headroom);
+	__le32 *txwi = (__le32 *)(skb->data - rt2x00dev->ops->extra_tx_headroom);
 	u32 word;
 
 	/*
@@ -725,14 +725,14 @@ static void rt2800pci_write_tx_desc(struct rt2x00_dev *rt2x00dev,
 	rt2x00_set_field32(&word, TXD_W1_BURST,
 			   test_bit(ENTRY_TXD_BURST, &txdesc->flags));
 	rt2x00_set_field32(&word, TXD_W1_SD_LEN0,
-			   rt2x00dev->hw->extra_tx_headroom);
+			   rt2x00dev->ops->extra_tx_headroom);
 	rt2x00_set_field32(&word, TXD_W1_LAST_SEC0, 0);
 	rt2x00_set_field32(&word, TXD_W1_DMA_DONE, 0);
 	rt2x00_desc_write(txd, 1, word);
 
 	rt2x00_desc_read(txd, 2, &word);
 	rt2x00_set_field32(&word, TXD_W2_SD_PTR1,
-			   skbdesc->skb_dma + rt2x00dev->hw->extra_tx_headroom);
+			   skbdesc->skb_dma + rt2x00dev->ops->extra_tx_headroom);
 	rt2x00_desc_write(txd, 2, word);
 
 	rt2x00_desc_read(txd, 3, &word);
@@ -1201,19 +1201,20 @@ static const struct data_queue_desc rt2800pci_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt2800pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 8,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2800pci_queue_rx,
-	.tx		= &rt2800pci_queue_tx,
-	.bcn		= &rt2800pci_queue_bcn,
-	.lib		= &rt2800pci_rt2x00_ops,
-	.hw		= &rt2800_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 8,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXWI_DESC_SIZE,
+	.rx			= &rt2800pci_queue_rx,
+	.tx			= &rt2800pci_queue_tx,
+	.bcn			= &rt2800pci_queue_bcn,
+	.lib			= &rt2800pci_rt2x00_ops,
+	.hw			= &rt2800_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2800_rt2x00debug,
+	.debugfs		= &rt2800_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 9ab15c4..af85d18 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -790,19 +790,20 @@ static const struct data_queue_desc rt2800usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt2800usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 8,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2800usb_queue_rx,
-	.tx		= &rt2800usb_queue_tx,
-	.bcn		= &rt2800usb_queue_bcn,
-	.lib		= &rt2800usb_rt2x00_ops,
-	.hw		= &rt2800_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 8,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
+	.rx			= &rt2800usb_queue_rx,
+	.tx			= &rt2800usb_queue_tx,
+	.bcn			= &rt2800usb_queue_bcn,
+	.lib			= &rt2800usb_rt2x00_ops,
+	.hw			= &rt2800_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2800_rt2x00debug,
+	.debugfs		= &rt2800_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 1cbb7ac..83008ab 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -113,6 +113,12 @@
 	(  ((unsigned long)((__skb)->data + (__header))) & 3 )
 
 /*
+ * Constants for extra TX headroom for alignment purposes.
+ */
+#define RT2X00_ALIGN_SIZE	4
+#define RT2X00_L2PAD_SIZE	8
+
+/*
  * Standard timing and size defines.
  * These values should follow the ieee80211 specifications.
  */
@@ -588,6 +594,7 @@ struct rt2x00_ops {
 	const unsigned int eeprom_size;
 	const unsigned int rf_size;
 	const unsigned int tx_queues;
+	const unsigned int extra_tx_headroom;
 	const struct data_queue_desc *rx;
 	const struct data_queue_desc *tx;
 	const struct data_queue_desc *bcn;
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 82d0b89..b743f34 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -104,7 +104,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	 * is also mapped to the DMA so it can be used for transfering
 	 * additional descriptor information to the hardware.
 	 */
-	skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_push(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->skb_dma =
 	    dma_map_single(rt2x00dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
@@ -112,7 +112,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	/*
 	 * Restore data pointer to original location again.
 	 */
-	skb_pull(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_pull(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->flags |= SKBDESC_DMA_MAPPED_TX;
 }
@@ -134,7 +134,7 @@ void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 		 * by the driver, but it was actually mapped to DMA.
 		 */
 		dma_unmap_single(rt2x00dev->dev, skbdesc->skb_dma,
-				 skb->len + rt2x00dev->hw->extra_tx_headroom,
+				 skb->len + rt2x00dev->ops->extra_tx_headroom,
 				 DMA_TO_DEVICE);
 		skbdesc->flags &= ~SKBDESC_DMA_MAPPED_TX;
 	}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index bf04605..956f6be 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2546,7 +2546,8 @@ static int rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2788,19 +2789,20 @@ static const struct data_queue_desc rt61pci_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt61pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt61pci_queue_rx,
-	.tx		= &rt61pci_queue_tx,
-	.bcn		= &rt61pci_queue_bcn,
-	.lib		= &rt61pci_rt2x00_ops,
-	.hw		= &rt61pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt61pci_queue_rx,
+	.tx			= &rt61pci_queue_tx,
+	.bcn			= &rt61pci_queue_bcn,
+	.lib			= &rt61pci_rt2x00_ops,
+	.hw			= &rt61pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt61pci_rt2x00debug,
+	.debugfs		= &rt61pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 5bbcf66..d4317dd 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2069,7 +2069,7 @@ static int rt73usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2306,19 +2306,20 @@ static const struct data_queue_desc rt73usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt73usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt73usb_queue_rx,
-	.tx		= &rt73usb_queue_tx,
-	.bcn		= &rt73usb_queue_bcn,
-	.lib		= &rt73usb_rt2x00_ops,
-	.hw		= &rt73usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt73usb_queue_rx,
+	.tx			= &rt73usb_queue_tx,
+	.bcn			= &rt73usb_queue_bcn,
+	.lib			= &rt73usb_rt2x00_ops,
+	.hw			= &rt73usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt73usb_rt2x00debug,
+	.debugfs		= &rt73usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 11/21/09 02:30, David Ellingsworth wrote:
>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>> kernel built from the wireless-testing repository I'm getting a number
>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>> access point. The relevant information about my card from lspci is:
>>
>> 01:08.0 0280: 1814:0301
>>         Subsystem: 1458:e934
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 64, Cache Line Size: 128 bytes
>>         Interrupt: pin A routed to IRQ 18
>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>         Capabilities: [40] Power Management version 2
>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>         Kernel driver in use: rt61pci
>>
>> If you need any other information, I'll be happy to provide it.
>>
>
> Hi David,
>
> This seems to be caused by the rt2x00 driver not properly declaring its alignment
> maneuvring space properly, and thus it doesn't leave enough headroom left for
> copying to the monitor interface.
>
> Can you check whether the attached patch fixes the issue for you?
> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>

Gertjan,

I haven't really been able to test this. The kernel version I was
using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
certain the patch will resolve the issue, but I've been unable to get
my wireless card to function properly with the latest 2.6.32-rc8-wl
master branch. I'm not entirely sure what changed since two days ago,
but I know the following:

1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
this issue. However, this patch will not apply on top of 2.6.32-rc8.

2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
above mentioned error. Unable to test patch since I pulled all the
recent modifications down.
3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.

I'm not entirely sure what the differences are between Linus' master
branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
changes have been made on the wireless-testing master branch in the
last couple of days that are preventing me from fully testing this
patch.

With the current wireless-testing master branch, 2.6.32-rc8-wl, with
and without the patch I can associate and authenticate with my AP but
am unable to do anything else. Any attempt to establish a wireless
connection thus dies while trying to obtain an ip address via DHCP.
Sadly, no errors are logged indicating what the cause of this problem
might be. Given that I've only seen these errors after establishing a
wireless connection, it's a little difficult for me to test without
being able to transmit any data.

I don't know if it's worth the effort or not, but if this patch were
re-based against Linus' master branch I might be able to test it since
my AP at least works with 2.6.32-rc8.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 11/21/09 02:30, David Ellingsworth wrote:
>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>> kernel built from the wireless-testing repository I'm getting a number
>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>> access point. The relevant information about my card from lspci is:
>>
>> 01:08.0 0280: 1814:0301
>>         Subsystem: 1458:e934
>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>         Latency: 64, Cache Line Size: 128 bytes
>>         Interrupt: pin A routed to IRQ 18
>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>         Capabilities: [40] Power Management version 2
>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>         Kernel driver in use: rt61pci
>>
>> If you need any other information, I'll be happy to provide it.
>>
>
> Hi David,
>
> This seems to be caused by the rt2x00 driver not properly declaring its alignment
> maneuvring space properly, and thus it doesn't leave enough headroom left for
> copying to the monitor interface.
>
> Can you check whether the attached patch fixes the issue for you?
> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>

Gertjan,

I haven't really been able to test this. The kernel version I was
using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
certain the patch will resolve the issue, but I've been unable to get
my wireless card to function properly with the latest 2.6.32-rc8-wl
master branch. I'm not entirely sure what changed since two days ago,
but I know the following:

1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
this issue. However, this patch will not apply on top of 2.6.32-rc8.

2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
above mentioned error. Unable to test patch since I pulled all the
recent modifications down.
3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.

I'm not entirely sure what the differences are between Linus' master
branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
changes have been made on the wireless-testing master branch in the
last couple of days that are preventing me from fully testing this
patch.

With the current wireless-testing master branch, 2.6.32-rc8-wl, with
and without the patch I can associate and authenticate with my AP but
am unable to do anything else. Any attempt to establish a wireless
connection thus dies while trying to obtain an ip address via DHCP.
Sadly, no errors are logged indicating what the cause of this problem
might be. Given that I've only seen these errors after establishing a
wireless connection, it's a little difficult for me to test without
being able to transmit any data.

I don't know if it's worth the effort or not, but if this patch were
re-based against Linus' master branch I might be able to test it since
my AP at least works with 2.6.32-rc8.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 3770 bytes --]

On 11/22/09 08:09, David Ellingsworth wrote:
> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/21/09 02:30, David Ellingsworth wrote:
>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>> kernel built from the wireless-testing repository I'm getting a number
>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>> access point. The relevant information about my card from lspci is:
>>>
>>> 01:08.0 0280: 1814:0301
>>>         Subsystem: 1458:e934
>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>         Latency: 64, Cache Line Size: 128 bytes
>>>         Interrupt: pin A routed to IRQ 18
>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>         Capabilities: [40] Power Management version 2
>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>         Kernel driver in use: rt61pci
>>>
>>> If you need any other information, I'll be happy to provide it.
>>>
>>
>> Hi David,
>>
>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>> copying to the monitor interface.
>>
>> Can you check whether the attached patch fixes the issue for you?
>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>
> 
> Gertjan,
> 
> I haven't really been able to test this. The kernel version I was
> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
> certain the patch will resolve the issue, but I've been unable to get
> my wireless card to function properly with the latest 2.6.32-rc8-wl
> master branch. I'm not entirely sure what changed since two days ago,
> but I know the following:
> 
> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
> this issue. However, this patch will not apply on top of 2.6.32-rc8.
> 
> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
> above mentioned error. Unable to test patch since I pulled all the
> recent modifications down.
> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
> 
> I'm not entirely sure what the differences are between Linus' master
> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
> changes have been made on the wireless-testing master branch in the
> last couple of days that are preventing me from fully testing this
> patch.
> 
> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
> and without the patch I can associate and authenticate with my AP but
> am unable to do anything else. Any attempt to establish a wireless
> connection thus dies while trying to obtain an ip address via DHCP.
> Sadly, no errors are logged indicating what the cause of this problem
> might be. Given that I've only seen these errors after establishing a
> wireless connection, it's a little difficult for me to test without
> being able to transmit any data.
> 
> I don't know if it's worth the effort or not, but if this patch were
> re-based against Linus' master branch I might be able to test it since
> my AP at least works with 2.6.32-rc8.

David,

OK. Find attached the patch ported to Linus' tree. It should apply to
any version of Linus' tree after 2.6.32-rc8.
I think it is good to get real confirmation that the patch behaves
as expected.

---
Gertjan.
 


[-- Attachment #2: align_fix_linus_tree.diff --]
[-- Type: text/plain, Size: 11875 bytes --]

diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 798f625..7a8b2c4 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1431,7 +1431,8 @@ static int rt2400pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SIGNAL_DBM |
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1622,20 +1623,21 @@ static const struct data_queue_desc rt2400pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2400pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2400pci_queue_rx,
-	.tx		= &rt2400pci_queue_tx,
-	.bcn		= &rt2400pci_queue_bcn,
-	.atim		= &rt2400pci_queue_atim,
-	.lib		= &rt2400pci_rt2x00_ops,
-	.hw		= &rt2400pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2400pci_queue_rx,
+	.tx			= &rt2400pci_queue_tx,
+	.bcn			= &rt2400pci_queue_bcn,
+	.atim			= &rt2400pci_queue_atim,
+	.lib			= &rt2400pci_rt2x00_ops,
+	.hw			= &rt2400pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2400pci_rt2x00debug,
+	.debugfs		= &rt2400pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 2e872ac..0baa5a7 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1732,7 +1732,8 @@ static int rt2500pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1921,20 +1922,21 @@ static const struct data_queue_desc rt2500pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500pci_queue_rx,
-	.tx		= &rt2500pci_queue_tx,
-	.bcn		= &rt2500pci_queue_bcn,
-	.atim		= &rt2500pci_queue_atim,
-	.lib		= &rt2500pci_rt2x00_ops,
-	.hw		= &rt2500pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2500pci_queue_rx,
+	.tx			= &rt2500pci_queue_tx,
+	.bcn			= &rt2500pci_queue_bcn,
+	.atim			= &rt2500pci_queue_atim,
+	.lib			= &rt2500pci_rt2x00_ops,
+	.hw			= &rt2500pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500pci_rt2x00debug,
+	.debugfs		= &rt2500pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 22dd6d9..1416f32 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1788,7 +1788,7 @@ static int rt2500usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1956,20 +1956,21 @@ static const struct data_queue_desc rt2500usb_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500usb_queue_rx,
-	.tx		= &rt2500usb_queue_tx,
-	.bcn		= &rt2500usb_queue_bcn,
-	.atim		= &rt2500usb_queue_atim,
-	.lib		= &rt2500usb_rt2x00_ops,
-	.hw		= &rt2500usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt2500usb_queue_rx,
+	.tx			= &rt2500usb_queue_tx,
+	.bcn			= &rt2500usb_queue_bcn,
+	.atim			= &rt2500usb_queue_atim,
+	.lib			= &rt2500usb_rt2x00_ops,
+	.hw			= &rt2500usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500usb_rt2x00debug,
+	.debugfs		= &rt2500usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 9fe770f..19298ef 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -2509,7 +2509,8 @@ static int rt2800usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+						RT2X00_L2PAD_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2852,19 +2853,20 @@ static const struct data_queue_desc rt2800usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt2800usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 8,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2800usb_queue_rx,
-	.tx		= &rt2800usb_queue_tx,
-	.bcn		= &rt2800usb_queue_bcn,
-	.lib		= &rt2800usb_rt2x00_ops,
-	.hw		= &rt2800usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 8,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
+	.rx			= &rt2800usb_queue_rx,
+	.tx			= &rt2800usb_queue_tx,
+	.bcn			= &rt2800usb_queue_bcn,
+	.lib			= &rt2800usb_rt2x00_ops,
+	.hw			= &rt2800usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2800usb_rt2x00debug,
+	.debugfs		= &rt2800usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 27bc6b7..a71962e 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -112,6 +112,12 @@
 	(  ((unsigned long)((__skb)->data + (__header))) & 3 )
 
 /*
+ * Constants for extra TX headroom for alignment purposes.
+ */
+#define RT2X00_ALIGN_SIZE	4
+#define RT2X00_L2PAD_SIZE	8
+
+/*
  * Standard timing and size defines.
  * These values should follow the ieee80211 specifications.
  */
@@ -579,6 +585,7 @@ struct rt2x00_ops {
 	const unsigned int eeprom_size;
 	const unsigned int rf_size;
 	const unsigned int tx_queues;
+	const unsigned int extra_tx_headroom;
 	const struct data_queue_desc *rx;
 	const struct data_queue_desc *tx;
 	const struct data_queue_desc *bcn;
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 577029e..2ec9c14 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -103,7 +103,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	 * is also mapped to the DMA so it can be used for transfering
 	 * additional descriptor information to the hardware.
 	 */
-	skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_push(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->skb_dma =
 	    dma_map_single(rt2x00dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
@@ -111,7 +111,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	/*
 	 * Restore data pointer to original location again.
 	 */
-	skb_pull(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_pull(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->flags |= SKBDESC_DMA_MAPPED_TX;
 }
@@ -133,7 +133,7 @@ void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 		 * by the driver, but it was actually mapped to DMA.
 		 */
 		dma_unmap_single(rt2x00dev->dev, skbdesc->skb_dma,
-				 skb->len + rt2x00dev->hw->extra_tx_headroom,
+				 skb->len + rt2x00dev->ops->extra_tx_headroom,
 				 DMA_TO_DEVICE);
 		skbdesc->flags &= ~SKBDESC_DMA_MAPPED_TX;
 	}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index b20e3ea..7b6f056 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2545,7 +2545,8 @@ static int rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2787,19 +2788,20 @@ static const struct data_queue_desc rt61pci_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt61pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt61pci_queue_rx,
-	.tx		= &rt61pci_queue_tx,
-	.bcn		= &rt61pci_queue_bcn,
-	.lib		= &rt61pci_rt2x00_ops,
-	.hw		= &rt61pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt61pci_queue_rx,
+	.tx			= &rt61pci_queue_tx,
+	.bcn			= &rt61pci_queue_bcn,
+	.lib			= &rt61pci_rt2x00_ops,
+	.hw			= &rt61pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt61pci_rt2x00debug,
+	.debugfs		= &rt61pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 14e7bb2..9f733e1 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2068,7 +2068,7 @@ static int rt73usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2305,19 +2305,20 @@ static const struct data_queue_desc rt73usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt73usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt73usb_queue_rx,
-	.tx		= &rt73usb_queue_tx,
-	.bcn		= &rt73usb_queue_bcn,
-	.lib		= &rt73usb_rt2x00_ops,
-	.hw		= &rt73usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt73usb_queue_rx,
+	.tx			= &rt73usb_queue_tx,
+	.bcn			= &rt73usb_queue_bcn,
+	.lib			= &rt73usb_rt2x00_ops,
+	.hw			= &rt73usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt73usb_rt2x00debug,
+	.debugfs		= &rt73usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 3770 bytes --]

On 11/22/09 08:09, David Ellingsworth wrote:
> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/21/09 02:30, David Ellingsworth wrote:
>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>> kernel built from the wireless-testing repository I'm getting a number
>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>> access point. The relevant information about my card from lspci is:
>>>
>>> 01:08.0 0280: 1814:0301
>>>         Subsystem: 1458:e934
>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>         Latency: 64, Cache Line Size: 128 bytes
>>>         Interrupt: pin A routed to IRQ 18
>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>         Capabilities: [40] Power Management version 2
>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>         Kernel driver in use: rt61pci
>>>
>>> If you need any other information, I'll be happy to provide it.
>>>
>>
>> Hi David,
>>
>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>> copying to the monitor interface.
>>
>> Can you check whether the attached patch fixes the issue for you?
>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>
> 
> Gertjan,
> 
> I haven't really been able to test this. The kernel version I was
> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
> certain the patch will resolve the issue, but I've been unable to get
> my wireless card to function properly with the latest 2.6.32-rc8-wl
> master branch. I'm not entirely sure what changed since two days ago,
> but I know the following:
> 
> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
> this issue. However, this patch will not apply on top of 2.6.32-rc8.
> 
> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
> above mentioned error. Unable to test patch since I pulled all the
> recent modifications down.
> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
> 
> I'm not entirely sure what the differences are between Linus' master
> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
> changes have been made on the wireless-testing master branch in the
> last couple of days that are preventing me from fully testing this
> patch.
> 
> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
> and without the patch I can associate and authenticate with my AP but
> am unable to do anything else. Any attempt to establish a wireless
> connection thus dies while trying to obtain an ip address via DHCP.
> Sadly, no errors are logged indicating what the cause of this problem
> might be. Given that I've only seen these errors after establishing a
> wireless connection, it's a little difficult for me to test without
> being able to transmit any data.
> 
> I don't know if it's worth the effort or not, but if this patch were
> re-based against Linus' master branch I might be able to test it since
> my AP at least works with 2.6.32-rc8.

David,

OK. Find attached the patch ported to Linus' tree. It should apply to
any version of Linus' tree after 2.6.32-rc8.
I think it is good to get real confirmation that the patch behaves
as expected.

---
Gertjan.
 


[-- Attachment #2: align_fix_linus_tree.diff --]
[-- Type: text/plain, Size: 11875 bytes --]

diff --git a/drivers/net/wireless/rt2x00/rt2400pci.c b/drivers/net/wireless/rt2x00/rt2400pci.c
index 798f625..7a8b2c4 100644
--- a/drivers/net/wireless/rt2x00/rt2400pci.c
+++ b/drivers/net/wireless/rt2x00/rt2400pci.c
@@ -1431,7 +1431,8 @@ static int rt2400pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SIGNAL_DBM |
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1622,20 +1623,21 @@ static const struct data_queue_desc rt2400pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2400pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2400pci_queue_rx,
-	.tx		= &rt2400pci_queue_tx,
-	.bcn		= &rt2400pci_queue_bcn,
-	.atim		= &rt2400pci_queue_atim,
-	.lib		= &rt2400pci_rt2x00_ops,
-	.hw		= &rt2400pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2400pci_queue_rx,
+	.tx			= &rt2400pci_queue_tx,
+	.bcn			= &rt2400pci_queue_bcn,
+	.atim			= &rt2400pci_queue_atim,
+	.lib			= &rt2400pci_rt2x00_ops,
+	.hw			= &rt2400pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2400pci_rt2x00debug,
+	.debugfs		= &rt2400pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500pci.c b/drivers/net/wireless/rt2x00/rt2500pci.c
index 2e872ac..0baa5a7 100644
--- a/drivers/net/wireless/rt2x00/rt2500pci.c
+++ b/drivers/net/wireless/rt2x00/rt2500pci.c
@@ -1732,7 +1732,8 @@ static int rt2500pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 			       IEEE80211_HW_SUPPORTS_PS |
 			       IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1921,20 +1922,21 @@ static const struct data_queue_desc rt2500pci_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500pci_queue_rx,
-	.tx		= &rt2500pci_queue_tx,
-	.bcn		= &rt2500pci_queue_bcn,
-	.atim		= &rt2500pci_queue_atim,
-	.lib		= &rt2500pci_rt2x00_ops,
-	.hw		= &rt2500pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt2500pci_queue_rx,
+	.tx			= &rt2500pci_queue_tx,
+	.bcn			= &rt2500pci_queue_bcn,
+	.atim			= &rt2500pci_queue_atim,
+	.lib			= &rt2500pci_rt2x00_ops,
+	.hw			= &rt2500pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500pci_rt2x00debug,
+	.debugfs		= &rt2500pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2500usb.c b/drivers/net/wireless/rt2x00/rt2500usb.c
index 22dd6d9..1416f32 100644
--- a/drivers/net/wireless/rt2x00/rt2500usb.c
+++ b/drivers/net/wireless/rt2x00/rt2500usb.c
@@ -1788,7 +1788,7 @@ static int rt2500usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
 
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -1956,20 +1956,21 @@ static const struct data_queue_desc rt2500usb_queue_atim = {
 };
 
 static const struct rt2x00_ops rt2500usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 1,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2500usb_queue_rx,
-	.tx		= &rt2500usb_queue_tx,
-	.bcn		= &rt2500usb_queue_bcn,
-	.atim		= &rt2500usb_queue_atim,
-	.lib		= &rt2500usb_rt2x00_ops,
-	.hw		= &rt2500usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 1,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt2500usb_queue_rx,
+	.tx			= &rt2500usb_queue_tx,
+	.bcn			= &rt2500usb_queue_bcn,
+	.atim			= &rt2500usb_queue_atim,
+	.lib			= &rt2500usb_rt2x00_ops,
+	.hw			= &rt2500usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2500usb_rt2x00debug,
+	.debugfs		= &rt2500usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2800usb.c b/drivers/net/wireless/rt2x00/rt2800usb.c
index 9fe770f..19298ef 100644
--- a/drivers/net/wireless/rt2x00/rt2800usb.c
+++ b/drivers/net/wireless/rt2x00/rt2800usb.c
@@ -2509,7 +2509,8 @@ static int rt2800usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = TXINFO_DESC_SIZE + TXWI_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+						RT2X00_L2PAD_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2852,19 +2853,20 @@ static const struct data_queue_desc rt2800usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt2800usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 8,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt2800usb_queue_rx,
-	.tx		= &rt2800usb_queue_tx,
-	.bcn		= &rt2800usb_queue_bcn,
-	.lib		= &rt2800usb_rt2x00_ops,
-	.hw		= &rt2800usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 8,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXINFO_DESC_SIZE + TXWI_DESC_SIZE,
+	.rx			= &rt2800usb_queue_rx,
+	.tx			= &rt2800usb_queue_tx,
+	.bcn			= &rt2800usb_queue_bcn,
+	.lib			= &rt2800usb_rt2x00_ops,
+	.hw			= &rt2800usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt2800usb_rt2x00debug,
+	.debugfs		= &rt2800usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt2x00.h b/drivers/net/wireless/rt2x00/rt2x00.h
index 27bc6b7..a71962e 100644
--- a/drivers/net/wireless/rt2x00/rt2x00.h
+++ b/drivers/net/wireless/rt2x00/rt2x00.h
@@ -112,6 +112,12 @@
 	(  ((unsigned long)((__skb)->data + (__header))) & 3 )
 
 /*
+ * Constants for extra TX headroom for alignment purposes.
+ */
+#define RT2X00_ALIGN_SIZE	4
+#define RT2X00_L2PAD_SIZE	8
+
+/*
  * Standard timing and size defines.
  * These values should follow the ieee80211 specifications.
  */
@@ -579,6 +585,7 @@ struct rt2x00_ops {
 	const unsigned int eeprom_size;
 	const unsigned int rf_size;
 	const unsigned int tx_queues;
+	const unsigned int extra_tx_headroom;
 	const struct data_queue_desc *rx;
 	const struct data_queue_desc *tx;
 	const struct data_queue_desc *bcn;
diff --git a/drivers/net/wireless/rt2x00/rt2x00queue.c b/drivers/net/wireless/rt2x00/rt2x00queue.c
index 577029e..2ec9c14 100644
--- a/drivers/net/wireless/rt2x00/rt2x00queue.c
+++ b/drivers/net/wireless/rt2x00/rt2x00queue.c
@@ -103,7 +103,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	 * is also mapped to the DMA so it can be used for transfering
 	 * additional descriptor information to the hardware.
 	 */
-	skb_push(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_push(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->skb_dma =
 	    dma_map_single(rt2x00dev->dev, skb->data, skb->len, DMA_TO_DEVICE);
@@ -111,7 +111,7 @@ void rt2x00queue_map_txskb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 	/*
 	 * Restore data pointer to original location again.
 	 */
-	skb_pull(skb, rt2x00dev->hw->extra_tx_headroom);
+	skb_pull(skb, rt2x00dev->ops->extra_tx_headroom);
 
 	skbdesc->flags |= SKBDESC_DMA_MAPPED_TX;
 }
@@ -133,7 +133,7 @@ void rt2x00queue_unmap_skb(struct rt2x00_dev *rt2x00dev, struct sk_buff *skb)
 		 * by the driver, but it was actually mapped to DMA.
 		 */
 		dma_unmap_single(rt2x00dev->dev, skbdesc->skb_dma,
-				 skb->len + rt2x00dev->hw->extra_tx_headroom,
+				 skb->len + rt2x00dev->ops->extra_tx_headroom,
 				 DMA_TO_DEVICE);
 		skbdesc->flags &= ~SKBDESC_DMA_MAPPED_TX;
 	}
diff --git a/drivers/net/wireless/rt2x00/rt61pci.c b/drivers/net/wireless/rt2x00/rt61pci.c
index b20e3ea..7b6f056 100644
--- a/drivers/net/wireless/rt2x00/rt61pci.c
+++ b/drivers/net/wireless/rt2x00/rt61pci.c
@@ -2545,7 +2545,8 @@ static int rt61pci_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = 0;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom +
+	    					RT2X00_ALIGN_SIZE;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2787,19 +2788,20 @@ static const struct data_queue_desc rt61pci_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt61pci_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt61pci_queue_rx,
-	.tx		= &rt61pci_queue_tx,
-	.bcn		= &rt61pci_queue_bcn,
-	.lib		= &rt61pci_rt2x00_ops,
-	.hw		= &rt61pci_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= 0,
+	.rx			= &rt61pci_queue_rx,
+	.tx			= &rt61pci_queue_tx,
+	.bcn			= &rt61pci_queue_bcn,
+	.lib			= &rt61pci_rt2x00_ops,
+	.hw			= &rt61pci_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt61pci_rt2x00debug,
+	.debugfs		= &rt61pci_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 
diff --git a/drivers/net/wireless/rt2x00/rt73usb.c b/drivers/net/wireless/rt2x00/rt73usb.c
index 14e7bb2..9f733e1 100644
--- a/drivers/net/wireless/rt2x00/rt73usb.c
+++ b/drivers/net/wireless/rt2x00/rt73usb.c
@@ -2068,7 +2068,7 @@ static int rt73usb_probe_hw_mode(struct rt2x00_dev *rt2x00dev)
 	    IEEE80211_HW_SIGNAL_DBM |
 	    IEEE80211_HW_SUPPORTS_PS |
 	    IEEE80211_HW_PS_NULLFUNC_STACK;
-	rt2x00dev->hw->extra_tx_headroom = TXD_DESC_SIZE;
+	rt2x00dev->hw->extra_tx_headroom = rt2x00dev->ops->extra_tx_headroom;
 
 	SET_IEEE80211_DEV(rt2x00dev->hw, rt2x00dev->dev);
 	SET_IEEE80211_PERM_ADDR(rt2x00dev->hw,
@@ -2305,19 +2305,20 @@ static const struct data_queue_desc rt73usb_queue_bcn = {
 };
 
 static const struct rt2x00_ops rt73usb_ops = {
-	.name		= KBUILD_MODNAME,
-	.max_sta_intf	= 1,
-	.max_ap_intf	= 4,
-	.eeprom_size	= EEPROM_SIZE,
-	.rf_size	= RF_SIZE,
-	.tx_queues	= NUM_TX_QUEUES,
-	.rx		= &rt73usb_queue_rx,
-	.tx		= &rt73usb_queue_tx,
-	.bcn		= &rt73usb_queue_bcn,
-	.lib		= &rt73usb_rt2x00_ops,
-	.hw		= &rt73usb_mac80211_ops,
+	.name			= KBUILD_MODNAME,
+	.max_sta_intf		= 1,
+	.max_ap_intf		= 4,
+	.eeprom_size		= EEPROM_SIZE,
+	.rf_size		= RF_SIZE,
+	.tx_queues		= NUM_TX_QUEUES,
+	.extra_tx_headroom	= TXD_DESC_SIZE,
+	.rx			= &rt73usb_queue_rx,
+	.tx			= &rt73usb_queue_tx,
+	.bcn			= &rt73usb_queue_bcn,
+	.lib			= &rt73usb_rt2x00_ops,
+	.hw			= &rt73usb_mac80211_ops,
 #ifdef CONFIG_RT2X00_LIB_DEBUGFS
-	.debugfs	= &rt73usb_rt2x00debug,
+	.debugfs		= &rt73usb_rt2x00debug,
 #endif /* CONFIG_RT2X00_LIB_DEBUGFS */
 };
 

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 11/22/09 08:09, David Ellingsworth wrote:
>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>> <gwingerde@gmail.com> wrote:
>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>> kernel built from the wireless-testing repository I'm getting a number
>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>> access point. The relevant information about my card from lspci is:
>>>>
>>>> 01:08.0 0280: 1814:0301
>>>>         Subsystem: 1458:e934
>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>         Interrupt: pin A routed to IRQ 18
>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>         Capabilities: [40] Power Management version 2
>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>         Kernel driver in use: rt61pci
>>>>
>>>> If you need any other information, I'll be happy to provide it.
>>>>
>>>
>>> Hi David,
>>>
>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>> copying to the monitor interface.
>>>
>>> Can you check whether the attached patch fixes the issue for you?
>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>
>>
>> Gertjan,
>>
>> I haven't really been able to test this. The kernel version I was
>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>> certain the patch will resolve the issue, but I've been unable to get
>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>> master branch. I'm not entirely sure what changed since two days ago,
>> but I know the following:
>>
>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>
>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>> above mentioned error. Unable to test patch since I pulled all the
>> recent modifications down.
>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>
>> I'm not entirely sure what the differences are between Linus' master
>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>> changes have been made on the wireless-testing master branch in the
>> last couple of days that are preventing me from fully testing this
>> patch.
>>
>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>> and without the patch I can associate and authenticate with my AP but
>> am unable to do anything else. Any attempt to establish a wireless
>> connection thus dies while trying to obtain an ip address via DHCP.
>> Sadly, no errors are logged indicating what the cause of this problem
>> might be. Given that I've only seen these errors after establishing a
>> wireless connection, it's a little difficult for me to test without
>> being able to transmit any data.
>>
>> I don't know if it's worth the effort or not, but if this patch were
>> re-based against Linus' master branch I might be able to test it since
>> my AP at least works with 2.6.32-rc8.
>
> David,
>
> OK. Find attached the patch ported to Linus' tree. It should apply to
> any version of Linus' tree after 2.6.32-rc8.
> I think it is good to get real confirmation that the patch behaves
> as expected.
>
> ---
> Gertjan.
>

Gertjan,

The patch applies but doesn't quite fix the issue with the rt61pci
driver. With the patch applied, I still occasionally receive the error
message. I added a printk after the error to see how much was missing.
It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
fails.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
<gwingerde@gmail.com> wrote:
> On 11/22/09 08:09, David Ellingsworth wrote:
>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>> <gwingerde@gmail.com> wrote:
>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>> kernel built from the wireless-testing repository I'm getting a number
>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>> access point. The relevant information about my card from lspci is:
>>>>
>>>> 01:08.0 0280: 1814:0301
>>>>         Subsystem: 1458:e934
>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>         Interrupt: pin A routed to IRQ 18
>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>         Capabilities: [40] Power Management version 2
>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>         Kernel driver in use: rt61pci
>>>>
>>>> If you need any other information, I'll be happy to provide it.
>>>>
>>>
>>> Hi David,
>>>
>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>> copying to the monitor interface.
>>>
>>> Can you check whether the attached patch fixes the issue for you?
>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>
>>
>> Gertjan,
>>
>> I haven't really been able to test this. The kernel version I was
>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>> certain the patch will resolve the issue, but I've been unable to get
>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>> master branch. I'm not entirely sure what changed since two days ago,
>> but I know the following:
>>
>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>
>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>> above mentioned error. Unable to test patch since I pulled all the
>> recent modifications down.
>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>
>> I'm not entirely sure what the differences are between Linus' master
>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>> changes have been made on the wireless-testing master branch in the
>> last couple of days that are preventing me from fully testing this
>> patch.
>>
>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>> and without the patch I can associate and authenticate with my AP but
>> am unable to do anything else. Any attempt to establish a wireless
>> connection thus dies while trying to obtain an ip address via DHCP.
>> Sadly, no errors are logged indicating what the cause of this problem
>> might be. Given that I've only seen these errors after establishing a
>> wireless connection, it's a little difficult for me to test without
>> being able to transmit any data.
>>
>> I don't know if it's worth the effort or not, but if this patch were
>> re-based against Linus' master branch I might be able to test it since
>> my AP at least works with 2.6.32-rc8.
>
> David,
>
> OK. Find attached the patch ported to Linus' tree. It should apply to
> any version of Linus' tree after 2.6.32-rc8.
> I think it is good to get real confirmation that the patch behaves
> as expected.
>
> ---
> Gertjan.
>

Gertjan,

The patch applies but doesn't quite fix the issue with the rt61pci
driver. With the patch applied, I still occasionally receive the error
message. I added a printk after the error to see how much was missing.
It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
fails.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

On 11/22/09 18:59, David Ellingsworth wrote:
> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/22/09 08:09, David Ellingsworth wrote:
>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>> <gwingerde@gmail.com> wrote:
>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>> access point. The relevant information about my card from lspci is:
>>>>>
>>>>> 01:08.0 0280: 1814:0301
>>>>>         Subsystem: 1458:e934
>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>         Capabilities: [40] Power Management version 2
>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>         Kernel driver in use: rt61pci
>>>>>
>>>>> If you need any other information, I'll be happy to provide it.
>>>>>
>>>>
>>>> Hi David,
>>>>
>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>> copying to the monitor interface.
>>>>
>>>> Can you check whether the attached patch fixes the issue for you?
>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>
>>>
>>> Gertjan,
>>>
>>> I haven't really been able to test this. The kernel version I was
>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>> certain the patch will resolve the issue, but I've been unable to get
>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>> master branch. I'm not entirely sure what changed since two days ago,
>>> but I know the following:
>>>
>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>
>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>> above mentioned error. Unable to test patch since I pulled all the
>>> recent modifications down.
>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>
>>> I'm not entirely sure what the differences are between Linus' master
>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>> changes have been made on the wireless-testing master branch in the
>>> last couple of days that are preventing me from fully testing this
>>> patch.
>>>
>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>> and without the patch I can associate and authenticate with my AP but
>>> am unable to do anything else. Any attempt to establish a wireless
>>> connection thus dies while trying to obtain an ip address via DHCP.
>>> Sadly, no errors are logged indicating what the cause of this problem
>>> might be. Given that I've only seen these errors after establishing a
>>> wireless connection, it's a little difficult for me to test without
>>> being able to transmit any data.
>>>
>>> I don't know if it's worth the effort or not, but if this patch were
>>> re-based against Linus' master branch I might be able to test it since
>>> my AP at least works with 2.6.32-rc8.
>>
>> David,
>>
>> OK. Find attached the patch ported to Linus' tree. It should apply to
>> any version of Linus' tree after 2.6.32-rc8.
>> I think it is good to get real confirmation that the patch behaves
>> as expected.
>>
>> ---
>> Gertjan.
>>
> 
> Gertjan,
> 
> The patch applies but doesn't quite fix the issue with the rt61pci
> driver. With the patch applied, I still occasionally receive the error
> message. I added a printk after the error to see how much was missing.
> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
> fails.
> 

David,

That is unexpected. This more starts to look like a problem that is
outside of rt2x00.

Would you be able to see what the available skb_headroom is when the TX
frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
entered?

---
Gertjan.

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

On 11/22/09 18:59, David Ellingsworth wrote:
> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
> <gwingerde@gmail.com> wrote:
>> On 11/22/09 08:09, David Ellingsworth wrote:
>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>> <gwingerde@gmail.com> wrote:
>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>> access point. The relevant information about my card from lspci is:
>>>>>
>>>>> 01:08.0 0280: 1814:0301
>>>>>         Subsystem: 1458:e934
>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>         Capabilities: [40] Power Management version 2
>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>         Kernel driver in use: rt61pci
>>>>>
>>>>> If you need any other information, I'll be happy to provide it.
>>>>>
>>>>
>>>> Hi David,
>>>>
>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>> copying to the monitor interface.
>>>>
>>>> Can you check whether the attached patch fixes the issue for you?
>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>
>>>
>>> Gertjan,
>>>
>>> I haven't really been able to test this. The kernel version I was
>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>> certain the patch will resolve the issue, but I've been unable to get
>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>> master branch. I'm not entirely sure what changed since two days ago,
>>> but I know the following:
>>>
>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>
>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>> above mentioned error. Unable to test patch since I pulled all the
>>> recent modifications down.
>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>
>>> I'm not entirely sure what the differences are between Linus' master
>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>> changes have been made on the wireless-testing master branch in the
>>> last couple of days that are preventing me from fully testing this
>>> patch.
>>>
>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>> and without the patch I can associate and authenticate with my AP but
>>> am unable to do anything else. Any attempt to establish a wireless
>>> connection thus dies while trying to obtain an ip address via DHCP.
>>> Sadly, no errors are logged indicating what the cause of this problem
>>> might be. Given that I've only seen these errors after establishing a
>>> wireless connection, it's a little difficult for me to test without
>>> being able to transmit any data.
>>>
>>> I don't know if it's worth the effort or not, but if this patch were
>>> re-based against Linus' master branch I might be able to test it since
>>> my AP at least works with 2.6.32-rc8.
>>
>> David,
>>
>> OK. Find attached the patch ported to Linus' tree. It should apply to
>> any version of Linus' tree after 2.6.32-rc8.
>> I think it is good to get real confirmation that the patch behaves
>> as expected.
>>
>> ---
>> Gertjan.
>>
> 
> Gertjan,
> 
> The patch applies but doesn't quite fix the issue with the rt61pci
> driver. With the patch applied, I still occasionally receive the error
> message. I added a printk after the error to see how much was missing.
> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
> fails.
> 

David,

That is unexpected. This more starts to look like a problem that is
outside of rt2x00.

Would you be able to see what the available skb_headroom is when the TX
frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
entered?

---
Gertjan.

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 5613 bytes --]

On 11/22/09 19:48, Gertjan van Wingerde wrote:
> On 11/22/09 18:59, David Ellingsworth wrote:
>> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
>> <gwingerde@gmail.com> wrote:
>>> On 11/22/09 08:09, David Ellingsworth wrote:
>>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>>> <gwingerde@gmail.com> wrote:
>>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>>> access point. The relevant information about my card from lspci is:
>>>>>>
>>>>>> 01:08.0 0280: 1814:0301
>>>>>>         Subsystem: 1458:e934
>>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>>         Capabilities: [40] Power Management version 2
>>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>         Kernel driver in use: rt61pci
>>>>>>
>>>>>> If you need any other information, I'll be happy to provide it.
>>>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>>> copying to the monitor interface.
>>>>>
>>>>> Can you check whether the attached patch fixes the issue for you?
>>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>>
>>>>
>>>> Gertjan,
>>>>
>>>> I haven't really been able to test this. The kernel version I was
>>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>>> certain the patch will resolve the issue, but I've been unable to get
>>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>>> master branch. I'm not entirely sure what changed since two days ago,
>>>> but I know the following:
>>>>
>>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>>
>>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>>> above mentioned error. Unable to test patch since I pulled all the
>>>> recent modifications down.
>>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>>
>>>> I'm not entirely sure what the differences are between Linus' master
>>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>>> changes have been made on the wireless-testing master branch in the
>>>> last couple of days that are preventing me from fully testing this
>>>> patch.
>>>>
>>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>>> and without the patch I can associate and authenticate with my AP but
>>>> am unable to do anything else. Any attempt to establish a wireless
>>>> connection thus dies while trying to obtain an ip address via DHCP.
>>>> Sadly, no errors are logged indicating what the cause of this problem
>>>> might be. Given that I've only seen these errors after establishing a
>>>> wireless connection, it's a little difficult for me to test without
>>>> being able to transmit any data.
>>>>
>>>> I don't know if it's worth the effort or not, but if this patch were
>>>> re-based against Linus' master branch I might be able to test it since
>>>> my AP at least works with 2.6.32-rc8.
>>>
>>> David,
>>>
>>> OK. Find attached the patch ported to Linus' tree. It should apply to
>>> any version of Linus' tree after 2.6.32-rc8.
>>> I think it is good to get real confirmation that the patch behaves
>>> as expected.
>>>
>>> ---
>>> Gertjan.
>>>
>>
>> Gertjan,
>>
>> The patch applies but doesn't quite fix the issue with the rt61pci
>> driver. With the patch applied, I still occasionally receive the error
>> message. I added a printk after the error to see how much was missing.
>> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
>> fails.
>>
> 
> David,
> 
> That is unexpected. This more starts to look like a problem that is
> outside of rt2x00.
> 
> Would you be able to see what the available skb_headroom is when the TX
> frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
> entered?
> 

(cc-ing Johannes, as this seems to be pointing towards mac80211 as well)

David,

I think I got figured out why the patch I sent didn't work. It seems mac80211
doesn't reserve headroom for both the driver requested space and the special
monitor interface header at the same time, but just for the maximum of the two.
This seems to be because it assumes that they are not needed at the same time.
However, this is not true for rt2x00, as it uses the headroom to align the frame
and never reclaims the used headroom (as the whole frame was moved forward in the
skb).

The easy fix here is to let mac80211 reserve headroom for both numbers, instead of
just the maximum.

Find the patch to achieve that attached.

I think that with both the rt2x00 patch and this patch applied the problem should
be gone.

---
Gertjan.

[-- Attachment #2: mac80211_headroom_fix.diff --]
[-- Type: text/plain, Size: 747 bytes --]

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 797f539..cba33ce 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -842,10 +842,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	/*
 	 * The hardware needs headroom for sending the frame,
 	 * and we need some headroom for passing the frame to monitor
-	 * interfaces, but never both at the same time.
+	 * interfaces. This may not be both at the same time, but
+	 * account for both to be safe.
 	 */
-	local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
-				   sizeof(struct ieee80211_tx_status_rtap_hdr));
+	local->tx_headroom = local->hw.extra_tx_headroom +
+				   sizeof(struct ieee80211_tx_status_rtap_hdr);
 
 	debugfs_hw_add(local);
 

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[Gertjan van Wingerde]

[-- Attachment #1: Type: text/plain, Size: 5613 bytes --]

On 11/22/09 19:48, Gertjan van Wingerde wrote:
> On 11/22/09 18:59, David Ellingsworth wrote:
>> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
>> <gwingerde@gmail.com> wrote:
>>> On 11/22/09 08:09, David Ellingsworth wrote:
>>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>>> <gwingerde@gmail.com> wrote:
>>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>>> access point. The relevant information about my card from lspci is:
>>>>>>
>>>>>> 01:08.0 0280: 1814:0301
>>>>>>         Subsystem: 1458:e934
>>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>>         Capabilities: [40] Power Management version 2
>>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>         Kernel driver in use: rt61pci
>>>>>>
>>>>>> If you need any other information, I'll be happy to provide it.
>>>>>>
>>>>>
>>>>> Hi David,
>>>>>
>>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>>> copying to the monitor interface.
>>>>>
>>>>> Can you check whether the attached patch fixes the issue for you?
>>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>>
>>>>
>>>> Gertjan,
>>>>
>>>> I haven't really been able to test this. The kernel version I was
>>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>>> certain the patch will resolve the issue, but I've been unable to get
>>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>>> master branch. I'm not entirely sure what changed since two days ago,
>>>> but I know the following:
>>>>
>>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>>
>>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>>> above mentioned error. Unable to test patch since I pulled all the
>>>> recent modifications down.
>>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>>
>>>> I'm not entirely sure what the differences are between Linus' master
>>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>>> changes have been made on the wireless-testing master branch in the
>>>> last couple of days that are preventing me from fully testing this
>>>> patch.
>>>>
>>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>>> and without the patch I can associate and authenticate with my AP but
>>>> am unable to do anything else. Any attempt to establish a wireless
>>>> connection thus dies while trying to obtain an ip address via DHCP.
>>>> Sadly, no errors are logged indicating what the cause of this problem
>>>> might be. Given that I've only seen these errors after establishing a
>>>> wireless connection, it's a little difficult for me to test without
>>>> being able to transmit any data.
>>>>
>>>> I don't know if it's worth the effort or not, but if this patch were
>>>> re-based against Linus' master branch I might be able to test it since
>>>> my AP at least works with 2.6.32-rc8.
>>>
>>> David,
>>>
>>> OK. Find attached the patch ported to Linus' tree. It should apply to
>>> any version of Linus' tree after 2.6.32-rc8.
>>> I think it is good to get real confirmation that the patch behaves
>>> as expected.
>>>
>>> ---
>>> Gertjan.
>>>
>>
>> Gertjan,
>>
>> The patch applies but doesn't quite fix the issue with the rt61pci
>> driver. With the patch applied, I still occasionally receive the error
>> message. I added a printk after the error to see how much was missing.
>> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
>> fails.
>>
> 
> David,
> 
> That is unexpected. This more starts to look like a problem that is
> outside of rt2x00.
> 
> Would you be able to see what the available skb_headroom is when the TX
> frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
> entered?
> 

(cc-ing Johannes, as this seems to be pointing towards mac80211 as well)

David,

I think I got figured out why the patch I sent didn't work. It seems mac80211
doesn't reserve headroom for both the driver requested space and the special
monitor interface header at the same time, but just for the maximum of the two.
This seems to be because it assumes that they are not needed at the same time.
However, this is not true for rt2x00, as it uses the headroom to align the frame
and never reclaims the used headroom (as the whole frame was moved forward in the
skb).

The easy fix here is to let mac80211 reserve headroom for both numbers, instead of
just the maximum.

Find the patch to achieve that attached.

I think that with both the rt2x00 patch and this patch applied the problem should
be gone.

---
Gertjan.

[-- Attachment #2: mac80211_headroom_fix.diff --]
[-- Type: text/plain, Size: 747 bytes --]

diff --git a/net/mac80211/main.c b/net/mac80211/main.c
index 797f539..cba33ce 100644
--- a/net/mac80211/main.c
+++ b/net/mac80211/main.c
@@ -842,10 +842,11 @@ int ieee80211_register_hw(struct ieee80211_hw *hw)
 	/*
 	 * The hardware needs headroom for sending the frame,
 	 * and we need some headroom for passing the frame to monitor
-	 * interfaces, but never both at the same time.
+	 * interfaces. This may not be both at the same time, but
+	 * account for both to be safe.
 	 */
-	local->tx_headroom = max_t(unsigned int , local->hw.extra_tx_headroom,
-				   sizeof(struct ieee80211_tx_status_rtap_hdr));
+	local->tx_headroom = local->hw.extra_tx_headroom +
+				   sizeof(struct ieee80211_tx_status_rtap_hdr);
 
 	debugfs_hw_add(local);
 

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sun, Nov 22, 2009 at 2:51 PM, Gertjan van Wingerde
<gertjan@vanwingerde.net> wrote:
> On 11/22/09 19:48, Gertjan van Wingerde wrote:
>> On 11/22/09 18:59, David Ellingsworth wrote:
>>> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
>>> <gwingerde@gmail.com> wrote:
>>>> On 11/22/09 08:09, David Ellingsworth wrote:
>>>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>>>> <gwingerde@gmail.com> wrote:
>>>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>>>> access point. The relevant information about my card from lspci is:
>>>>>>>
>>>>>>> 01:08.0 0280: 1814:0301
>>>>>>>         Subsystem: 1458:e934
>>>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>>>         Capabilities: [40] Power Management version 2
>>>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>         Kernel driver in use: rt61pci
>>>>>>>
>>>>>>> If you need any other information, I'll be happy to provide it.
>>>>>>>
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>>>> copying to the monitor interface.
>>>>>>
>>>>>> Can you check whether the attached patch fixes the issue for you?
>>>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>>>
>>>>>
>>>>> Gertjan,
>>>>>
>>>>> I haven't really been able to test this. The kernel version I was
>>>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>>>> certain the patch will resolve the issue, but I've been unable to get
>>>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>>>> master branch. I'm not entirely sure what changed since two days ago,
>>>>> but I know the following:
>>>>>
>>>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>>>
>>>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>>>> above mentioned error. Unable to test patch since I pulled all the
>>>>> recent modifications down.
>>>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>>>
>>>>> I'm not entirely sure what the differences are between Linus' master
>>>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>>>> changes have been made on the wireless-testing master branch in the
>>>>> last couple of days that are preventing me from fully testing this
>>>>> patch.
>>>>>
>>>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>>>> and without the patch I can associate and authenticate with my AP but
>>>>> am unable to do anything else. Any attempt to establish a wireless
>>>>> connection thus dies while trying to obtain an ip address via DHCP.
>>>>> Sadly, no errors are logged indicating what the cause of this problem
>>>>> might be. Given that I've only seen these errors after establishing a
>>>>> wireless connection, it's a little difficult for me to test without
>>>>> being able to transmit any data.
>>>>>
>>>>> I don't know if it's worth the effort or not, but if this patch were
>>>>> re-based against Linus' master branch I might be able to test it since
>>>>> my AP at least works with 2.6.32-rc8.
>>>>
>>>> David,
>>>>
>>>> OK. Find attached the patch ported to Linus' tree. It should apply to
>>>> any version of Linus' tree after 2.6.32-rc8.
>>>> I think it is good to get real confirmation that the patch behaves
>>>> as expected.
>>>>
>>>> ---
>>>> Gertjan.
>>>>
>>>
>>> Gertjan,
>>>
>>> The patch applies but doesn't quite fix the issue with the rt61pci
>>> driver. With the patch applied, I still occasionally receive the error
>>> message. I added a printk after the error to see how much was missing.
>>> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
>>> fails.
>>>
>>
>> David,
>>
>> That is unexpected. This more starts to look like a problem that is
>> outside of rt2x00.
>>
>> Would you be able to see what the available skb_headroom is when the TX
>> frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
>> entered?
>>
>
> (cc-ing Johannes, as this seems to be pointing towards mac80211 as well)
>
> David,
>
> I think I got figured out why the patch I sent didn't work. It seems mac80211
> doesn't reserve headroom for both the driver requested space and the special
> monitor interface header at the same time, but just for the maximum of the two.
> This seems to be because it assumes that they are not needed at the same time.
> However, this is not true for rt2x00, as it uses the headroom to align the frame
> and never reclaims the used headroom (as the whole frame was moved forward in the
> skb).
>
> The easy fix here is to let mac80211 reserve headroom for both numbers, instead of
> just the maximum.
>
> Find the patch to achieve that attached.
>
> I think that with both the rt2x00 patch and this patch applied the problem should
> be gone.
>
> ---
> Gertjan.
>

Gertjan,

>From what I can tell, the combination of both of these patches seems
to correct the issue. I have not experienced the error after applying
the patch to mac80211. Thanks for the help.

Regards,

David Ellingsworth

Re: [rt2x00-users] ieee80211_tx_status: headroom too small

[David Ellingsworth]

On Sun, Nov 22, 2009 at 2:51 PM, Gertjan van Wingerde
<gertjan@vanwingerde.net> wrote:
> On 11/22/09 19:48, Gertjan van Wingerde wrote:
>> On 11/22/09 18:59, David Ellingsworth wrote:
>>> On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde
>>> <gwingerde@gmail.com> wrote:
>>>> On 11/22/09 08:09, David Ellingsworth wrote:
>>>>> On Sat, Nov 21, 2009 at 10:27 AM, Gertjan van Wingerde
>>>>> <gwingerde@gmail.com> wrote:
>>>>>> On 11/21/09 02:30, David Ellingsworth wrote:
>>>>>>> Wasn't sure where to send this, but with the latest 2.6.32-rc8-wl
>>>>>>> kernel built from the wireless-testing repository I'm getting a number
>>>>>>> of "ieee80211_tx_status: headroom too small" errors in my syslog. I'm
>>>>>>> using the rt61pci driver in conjunction with hostap as a wpa2 secured
>>>>>>> access point. The relevant information about my card from lspci is:
>>>>>>>
>>>>>>> 01:08.0 0280: 1814:0301
>>>>>>>         Subsystem: 1458:e934
>>>>>>>         Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop-
>>>>>>> ParErr- Stepping- SERR+ FastB2B- DisINTx-
>>>>>>>         Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort-
>>>>>>> <TAbort- <MAbort- >SERR- <PERR- INTx-
>>>>>>>         Latency: 64, Cache Line Size: 128 bytes
>>>>>>>         Interrupt: pin A routed to IRQ 18
>>>>>>>         Region 0: Memory at fe6f0000 (32-bit, non-prefetchable) [size=32K]
>>>>>>>         Capabilities: [40] Power Management version 2
>>>>>>>                 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
>>>>>>> PME(D0-,D1-,D2-,D3hot-,D3cold-)
>>>>>>>                 Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
>>>>>>>         Kernel driver in use: rt61pci
>>>>>>>
>>>>>>> If you need any other information, I'll be happy to provide it.
>>>>>>>
>>>>>>
>>>>>> Hi David,
>>>>>>
>>>>>> This seems to be caused by the rt2x00 driver not properly declaring its alignment
>>>>>> maneuvring space properly, and thus it doesn't leave enough headroom left for
>>>>>> copying to the monitor interface.
>>>>>>
>>>>>> Can you check whether the attached patch fixes the issue for you?
>>>>>> Note: patch looks a bit bigger than it actually is due to indenting cleanups.
>>>>>>
>>>>>
>>>>> Gertjan,
>>>>>
>>>>> I haven't really been able to test this. The kernel version I was
>>>>> using at the time was 2.6.32-rc7-wl and not 2.6.32-rc8-wl. I'm rather
>>>>> certain the patch will resolve the issue, but I've been unable to get
>>>>> my wireless card to function properly with the latest 2.6.32-rc8-wl
>>>>> master branch. I'm not entirely sure what changed since two days ago,
>>>>> but I know the following:
>>>>>
>>>>> 1. 2.6.32-rc8 from Linus' master branch works fine but still exhibits
>>>>> this issue. However, this patch will not apply on top of 2.6.32-rc8.
>>>>>
>>>>> 2. 2.6.32-rc7-wl(11/19/2009) worked fine with the exception of the
>>>>> above mentioned error. Unable to test patch since I pulled all the
>>>>> recent modifications down.
>>>>> 3. 2.6.32-rc8-wl does not work at all for me, but patch does apply.
>>>>>
>>>>> I'm not entirely sure what the differences are between Linus' master
>>>>> branch of 2.6.32-rc8 and the current 2.6.32-rc8-wl tree are or what
>>>>> changes have been made on the wireless-testing master branch in the
>>>>> last couple of days that are preventing me from fully testing this
>>>>> patch.
>>>>>
>>>>> With the current wireless-testing master branch, 2.6.32-rc8-wl, with
>>>>> and without the patch I can associate and authenticate with my AP but
>>>>> am unable to do anything else. Any attempt to establish a wireless
>>>>> connection thus dies while trying to obtain an ip address via DHCP.
>>>>> Sadly, no errors are logged indicating what the cause of this problem
>>>>> might be. Given that I've only seen these errors after establishing a
>>>>> wireless connection, it's a little difficult for me to test without
>>>>> being able to transmit any data.
>>>>>
>>>>> I don't know if it's worth the effort or not, but if this patch were
>>>>> re-based against Linus' master branch I might be able to test it since
>>>>> my AP at least works with 2.6.32-rc8.
>>>>
>>>> David,
>>>>
>>>> OK. Find attached the patch ported to Linus' tree. It should apply to
>>>> any version of Linus' tree after 2.6.32-rc8.
>>>> I think it is good to get real confirmation that the patch behaves
>>>> as expected.
>>>>
>>>> ---
>>>> Gertjan.
>>>>
>>>
>>> Gertjan,
>>>
>>> The patch applies but doesn't quite fix the issue with the rt61pci
>>> driver. With the patch applied, I still occasionally receive the error
>>> message. I added a printk after the error to see how much was missing.
>>> It indicates that skb_headroom is 12 and sizeof(*rthdr) is 13 when it
>>> fails.
>>>
>>
>> David,
>>
>> That is unexpected. This more starts to look like a problem that is
>> outside of rt2x00.
>>
>> Would you be able to see what the available skb_headroom is when the TX
>> frame enters the rt61pci driver, i.e. when the rt2x00mac_tx function is
>> entered?
>>
>
> (cc-ing Johannes, as this seems to be pointing towards mac80211 as well)
>
> David,
>
> I think I got figured out why the patch I sent didn't work. It seems mac80211
> doesn't reserve headroom for both the driver requested space and the special
> monitor interface header at the same time, but just for the maximum of the two.
> This seems to be because it assumes that they are not needed at the same time.
> However, this is not true for rt2x00, as it uses the headroom to align the frame
> and never reclaims the used headroom (as the whole frame was moved forward in the
> skb).
>
> The easy fix here is to let mac80211 reserve headroom for both numbers, instead of
> just the maximum.
>
> Find the patch to achieve that attached.
>
> I think that with both the rt2x00 patch and this patch applied the problem should
> be gone.
>
> ---
> Gertjan.
>

Gertjan,

>From what I can tell, the combination of both of these patches seems
to correct the issue. I have not experienced the error after applying
the patch to mac80211. Thanks for the help.

Regards,

David Ellingsworth

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 11:17 +0100, Ivo van Doorn wrote:
> 
> > At the least the beacons, but I am not sure about if there are other frame types
> > which also have this requirement.
> 
> So you align them all right now? Just wondering since beacons shouldn't
> be status-reported.

Currently I do all, but that is because I am not sure which specific frames
require it. I might just fix this for beacons only and just see what happens
with the other frames.

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 288 bytes --]

On Sat, 2009-10-31 at 11:17 +0100, Ivo van Doorn wrote:

> At the least the beacons, but I am not sure about if there are other frame types
> which also have this requirement.

So you align them all right now? Just wondering since beacons shouldn't
be status-reported.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 10:44 +0100, Ivo van Doorn wrote:
> 
> > > Or maybe we should just not bother with having drivers do the alignment
> > > any more -- mac80211 does that now and it only does it if necessary
> > > (i.e. not on powerpc/x86)
> > 
> > I think you mean the RX alignment, while I am talking about the TX alignment.
> > Beacons and some othe frames must be 4-byte alignment because the wireleless
> > hardware requires it.
> 
> Oh, indeed, I got confused.
> 
> Hmm. TX alignment is weird ... no driver really needs that except rt2x00
> afaik. Which frames require this?

At the least the beacons, but I am not sure about if there are other frame types
which also have this requirement.

Users had reported that if they align beacon frames, rt2500pci finally starts
beaconing correctly in master mode.

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 584 bytes --]

On Sat, 2009-10-31 at 10:44 +0100, Ivo van Doorn wrote:

> > Or maybe we should just not bother with having drivers do the alignment
> > any more -- mac80211 does that now and it only does it if necessary
> > (i.e. not on powerpc/x86)
> 
> I think you mean the RX alignment, while I am talking about the TX alignment.
> Beacons and some othe frames must be 4-byte alignment because the wireleless
> hardware requires it.

Oh, indeed, I got confused.

Hmm. TX alignment is weird ... no driver really needs that except rt2x00
afaik. Which frames require this?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 10:30 +0100, Ivo van Doorn wrote:
> 
> > > > 4 actually, wasn't there some cases where the header could have an odd
> > > > number of bytes and would require 3 bytes for alignment?
> > > 
> > > Hm, is there? I thought they changed the 11s draft to no longer have
> > > that.
> > 
> > Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
> > a long time ago). :)
> 
> However, it really all depends on the hardware too ... Maybe we should
> put more of the logic into drivers, and have mac80211 only export its
> required headroom?
> 
> Or maybe we should just not bother with having drivers do the alignment
> any more -- mac80211 does that now and it only does it if necessary
> (i.e. not on powerpc/x86)

I think you mean the RX alignment, while I am talking about the TX alignment.
Beacons and some othe frames must be 4-byte alignment because the wireleless
hardware requires it.

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 763 bytes --]

On Sat, 2009-10-31 at 10:30 +0100, Ivo van Doorn wrote:

> > > 4 actually, wasn't there some cases where the header could have an odd
> > > number of bytes and would require 3 bytes for alignment?
> > 
> > Hm, is there? I thought they changed the 11s draft to no longer have
> > that.
> 
> Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
> a long time ago). :)

However, it really all depends on the hardware too ... Maybe we should
put more of the logic into drivers, and have mac80211 only export its
required headroom?

Or maybe we should just not bother with having drivers do the alignment
any more -- mac80211 does that now and it only does it if necessary
(i.e. not on powerpc/x86)

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 09:59 +0100, Ivo van Doorn wrote:
> > On Saturday 31 October 2009, Johannes Berg wrote:
> > > On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:
> > > 
> > > > > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > > > > should always reserve enough headroom in buffers it passes to the
> > > > > driver. Does rt61pci somehow realloc frames?
> > > > 
> > > > It does use skb_push. but will/should always stay within the limits
> > > > of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> > > > might be a situation where it needs to align the frame to a 4-byte boundary,
> > > > it could exceed that amount. :(
> > > 
> > > extra_tx_headroom is set to max_t(driver, mac80211) so that there's
> > > always some headroom. This doesn't take into account alignment though.
> > > Should we simply add 2 to that value?
> > 
> > 4 actually, wasn't there some cases where the header could have an odd
> > number of bytes and would require 3 bytes for alignment?
> 
> Hm, is there? I thought they changed the 11s draft to no longer have
> that.

Well 2 is fine in that case, (I was basing my comment on something said on this mailinglist
a long time ago). :)

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]

On Sat, 2009-10-31 at 09:59 +0100, Ivo van Doorn wrote:
> On Saturday 31 October 2009, Johannes Berg wrote:
> > On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:
> > 
> > > > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > > > should always reserve enough headroom in buffers it passes to the
> > > > driver. Does rt61pci somehow realloc frames?
> > > 
> > > It does use skb_push. but will/should always stay within the limits
> > > of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> > > might be a situation where it needs to align the frame to a 4-byte boundary,
> > > it could exceed that amount. :(
> > 
> > extra_tx_headroom is set to max_t(driver, mac80211) so that there's
> > always some headroom. This doesn't take into account alignment though.
> > Should we simply add 2 to that value?
> 
> 4 actually, wasn't there some cases where the header could have an odd
> number of bytes and would require 3 bytes for alignment?

Hm, is there? I thought they changed the 11s draft to no longer have
that.

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:
> 
> > > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > > should always reserve enough headroom in buffers it passes to the
> > > driver. Does rt61pci somehow realloc frames?
> > 
> > It does use skb_push. but will/should always stay within the limits
> > of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> > might be a situation where it needs to align the frame to a 4-byte boundary,
> > it could exceed that amount. :(
> 
> extra_tx_headroom is set to max_t(driver, mac80211) so that there's
> always some headroom. This doesn't take into account alignment though.
> Should we simply add 2 to that value?

4 actually, wasn't there some cases where the header could have an odd
number of bytes and would require 3 bytes for alignment?

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 707 bytes --]

On Sat, 2009-10-31 at 09:51 +0100, Ivo van Doorn wrote:

> > Ok. I looked at the problem and it's a very odd problem -- mac80211
> > should always reserve enough headroom in buffers it passes to the
> > driver. Does rt61pci somehow realloc frames?
> 
> It does use skb_push. but will/should always stay within the limits
> of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
> might be a situation where it needs to align the frame to a 4-byte boundary,
> it could exceed that amount. :(

extra_tx_headroom is set to max_t(driver, mac80211) so that there's
always some headroom. This doesn't take into account alignment though.
Should we simply add 2 to that value?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Ivo van Doorn]

On Saturday 31 October 2009, Johannes Berg wrote:
> On Sat, 2009-10-31 at 00:56 +0300, Nikolai ZHUBR wrote:
> > Friday, October 30, 2009, 11:59:01 PM, Johannes Berg wrote:
> > >>
> > >> ieee80211_tx_status: headroom too small
> > 
> > > What driver are you using?
> > 
> > Ah, sorry, forgot to mention. It is rt61pci (RaLink mini-PCI card)
> 
> Ok. I looked at the problem and it's a very odd problem -- mac80211
> should always reserve enough headroom in buffers it passes to the
> driver. Does rt61pci somehow realloc frames?

It does use skb_push. but will/should always stay within the limits
of rt2x00dev->hw->extra_tx_headroom. Although I just realize there
might be a situation where it needs to align the frame to a 4-byte boundary,
it could exceed that amount. :(

Ivo

Re: ieee80211_tx_status: headroom too small

[Johannes Berg]

[-- Attachment #1: Type: text/plain, Size: 278 bytes --]

On Fri, 2009-10-30 at 23:00 +0300, Nikolai ZHUBR wrote:
> Hello people,
> 
> I'm using compat-wireless-2009-09-14 with 2.6.25.20 and I have
> recently noticed lots of these in syslog:
> 
> ieee80211_tx_status: headroom too small

What driver are you using?

johannes

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 801 bytes --]

Re: ieee80211_tx_status: headroom too small

[Luis R. Rodriguez]

On Fri, Oct 30, 2009 at 1:00 PM, Nikolai ZHUBR <zhubr@mail.ru> wrote:
> Hello people,
>
> I'm using compat-wireless-2009-09-14 with 2.6.25.20 and I have
> recently noticed lots of these in syslog:
>
> ieee80211_tx_status: headroom too small
> ieee80211_tx_status: headroom too small
> ieee80211_tx_status: headroom too small
>
> The wireless (access point) works fine, though maybe not very
> fast. However, this warning somehow bothers me. Is it important?
> Does it mean something critical? Maybe I should just comment
> it out in the code? I don't like syslog being filled up this
> way...

You're lucky it even worked on 2.6.25.

  Luis

ieee80211_tx_status: headroom too small

[Nikolai ZHUBR]

Hello people,

I'm using compat-wireless-2009-09-14 with 2.6.25.20 and I have
recently noticed lots of these in syslog:

ieee80211_tx_status: headroom too small
ieee80211_tx_status: headroom too small
ieee80211_tx_status: headroom too small

The wireless (access point) works fine, though maybe not very
fast. However, this warning somehow bothers me. Is it important?
Does it mean something critical? Maybe I should just comment
it out in the code? I don't like syslog being filled up this
way...

Thank you.

Nikolai ZHUBR