ieee80211_tx_status: headroom too small
in [Kernel]
|
Prev: [PATCH] r8192U_core: test for negative error in rtl8192_rx_isr()?
Next: [RFC PATCH 1/9] Serial: Enable build of sc26xx driver for embedded platforms
From: Gertjan van Wingerde on 22 Nov 2009 13:50 On 11/22/09 18:59, David Ellingsworth wrote: > On Sun, Nov 22, 2009 at 7:47 AM, Gertjan van Wingerde > <gwingerde(a)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(a)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. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Gertjan van Wingerde on 22 Nov 2009 15:00 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(a)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(a)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.
From: David Ellingsworth on 22 Nov 2009 16:20
On Sun, Nov 22, 2009 at 2:51 PM, Gertjan van Wingerde <gertjan(a)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(a)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(a)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 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |