[rt2x00-users] [bugzilla-daemon at bugzilla.kernel.org: [Bug 42828] rt2800pci unstable - chokes after too much I/O]

Francisco Pina Martins f.pinamartins at gmail.com
Fri Oct 19 09:04:06 AEDT 2012


Here is the output of lspci -vvv for my card:

01:00.0 Network controller: Ralink corp. RT2790 Wireless 802.11n 1T/2R PCIe
    Subsystem: Ralink corp. Device 2790
    Physical Slot: eeepc-wifi
    Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr-
Stepping- SERR- FastB2B- DisINTx-
    Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort-
<MAbort- >SERR- <PERR- INTx-
    Latency: 0, Cache Line Size: 32 bytes
    Interrupt: pin A routed to IRQ 19
    Region 0: Memory at fbef0000 (32-bit, non-prefetchable) [size=64K]
    Capabilities: [40] Power Management version 3
        Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
        Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME+
    Capabilities: [50] MSI: Enable- Count=1/32 Maskable- 64bit+
        Address: 0000000000000000  Data: 0000
    Capabilities: [70] Express (v1) Endpoint, MSI 00
        DevCap:    MaxPayload 128 bytes, PhantFunc 0, Latency L0s <128ns,
L1 <2us
            ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
        DevCtl:    Report errors: Correctable- Non-Fatal- Fatal-
Unsupported-
            RlxdOrd+ ExtTag- PhantFunc- AuxPwr- NoSnoop-
            MaxPayload 128 bytes, MaxReadReq 512 bytes
        DevSta:    CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr-
TransPend-
        LnkCap:    Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Latency
L0 <512ns, L1 <64us
            ClockPM+ Surprise- LLActRep- BwNot-
        LnkCtl:    ASPM Disabled; RCB 128 bytes Disabled- Retrain- CommClk+
            ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
        LnkSta:    Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
    Capabilities: [100 v1] Advanced Error Reporting
        UESta:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq+ ACSViol-
        UEMsk:    DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt- RxOF-
MalfTLP- ECRC- UnsupReq- ACSViol-
        UESvrt:    DLP+ SDES- TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt- RxOF+
MalfTLP+ ECRC- UnsupReq- ACSViol-
        CESta:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        CEMsk:    RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
        AERCap:    First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
    Kernel driver in use: rt2800pci

I am not sure how to find the "rf" and "rev" values.
My network is 2.4Ghz, and the AP is using both 20/40Mhz bandwidth. Changing
this value to 20Mhz does not fix the problem.
The AP is a  Belkin F5D8233-4-v1(01A) using the latest available
firmware (1.01.15
(Dec 27 2007 18:39:03) yes, it is old). It is working in AP mode only and
the routing is done via my miniITX box running ubuntu server 10.04. If you
need to know more about this just let me know what info you require.

Francisco

PS - sorry it took so long for me to reply - for some reason gmail sent
this thread to spam...

On 18 October 2012 22:08, Helmut Schaa <helmut.schaa at googlemail.com> wrote:

> Hi,
>
> On Thu, Oct 18, 2012 at 8:48 PM, Andreas Hartmann
> <andihartmann at 01019freenet.de> wrote:
> > Anyway, I retested with compat-wireless-3.5 rc5 and I can see a complete
> > hanging connection after 3s of running netperf with
> > 0011-Revert-rt2x00-Don-t-let-mac80211-send-a-BAR-when-an-.patch (2.4
> > GHz, 40MHz) - the original problem and the reason for the patch.
> >
> > Maybe we should distinguish between AP and STA? Or is it a device
> > specific problem? I'm not sure. Helmut mentioned here that it could be a
> > hardware issue, too:
> >
> http://news.gmane.org/find-root.php?group=gmane.linux.kernel.wireless.general&article=83767
>
> If I remember correctly the hardware will always report BAR frames as
> un-acked even if a BlockAck is received as response to the BAR. This
> leads to mac80211 resending the BAR.
>
> Maybe just reporting BAR TX status as "acked" works around this issue ...
>
> Helmut
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rt2x00.serialmonkey.com/pipermail/users_rt2x00.serialmonkey.com/attachments/20121018/281facb0/attachment-0002.html>


More information about the users mailing list