[lkml]   [2009]   [Feb]   [23]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [TIP] BUG kmalloc-4096: Poison overwritten (ath5k_rx_skb_alloc)
    2009/2/23  <>:
    > On Mon, 23 Feb 2009 18:03:16 +0200, Nick Kossifidis <>
    > wrote:
    >> 2009/2/23 Bob Copeland <>:
    >>> On Mon, 23 Feb 2009 00:20:50 +0100, Jiri Slaby wrote
    >>>> On 22.2.2009 22:56, Jiri Slaby wrote:
    >>>> > Well, maybe we should try to reproduce with jumbo packets sent to the
    >>>> > ath5k receiver, since I think it (1) is not very much test-covered
    >>>> > code
    >>>> > (2) appears to be related.
    >>>> According to the spec I have for older chip, there is not `done' flag
    >>>> set for descriptors which have `more' flag set. We handle this wrongly.
    >>>> Am I looking correctly, Nick, Luis, Bob?
    >>>> I still don't see what could have caused this though.
    >>> As I understand it, yes, we don't do the right thing when the more flag
    >>> is set. We're supposed to keep processing packets until we get one with
    >>> the done flag, and then all of that is supposed to be merged into a
    >>> single
    >>> packet. Other flags such as the rx rate are only valid on the final
    >>> packet.
    >>> However, I did some debugging of this a while ago and concluded that the
    >>> 'jumbo' frames were largely garbage data. The dma buffer size is
    >>> certainly
    >>> large enough for a standard 802.11 frame and the 'more' flag is only
    >>> supposed to be set if the dma buffer size is too small for a packet. In
    >>> all cases the dma buffer size was 2500+ bytes and the actual contents of
    >>> the packets looked like random values (I did have encryption turned on,
    >>> but there were no 802.11 headers I could see.)
    >>> So I am not sure if the jumbo packets are causing bad things to happen,
    >>> or if they are an indication that something bad has already happened.
    >> Hmm can someone test ath5k against an Atheros AP using fast frames ?
    >> Maybe they are jumbo frames but they don't have any header etc so that
    >> they look like one frame after un-fragmentation, documentation says
    >> that the current frame is continued in the next descriptor if more is
    >> set to 1 so i guess next buffer might not have the header. If more = 0
    >> then it's our last descriptor and only then other fields such as done,
    >> frame receive ok, rssi etc are valid.
    > If an ath9k device in AP mode using hostapd counts as an Atheros AP, then I
    > can test tonight. If you can send me the steps to test this, I'll do it in
    > about 8 hours.
    > Pat Erley

    As far as i know ath9k doesn't support fast frames ;-(

    GPG ID: 0xD21DB2DB
    As you read this post global entropy rises. Have Fun ;-)

     \ /
      Last update: 2009-02-23 17:23    [W:0.025 / U:10.412 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site