FYI: msdu-desc must be multiple of 8.

FYI: msdu-desc must be multiple of 8.

[Ben Greear]

I just hit strange and wonderful crashes because I managed to use
an msdu-desc length that was not an even multiple of 8.  Firmware
has assumption (bug, really) about this.

Bug is only triggerable if you fill up tx-descs, so have to flood UDP
to hit easily.  I was trying 812 buffers, but 808 works just fine.
(non CT firmware will not let you do less that 1024, no matter what you
request, btw).

Easy to fix though once you know the problem.

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: FYI: msdu-desc must be multiple of 8.

[Avery Pennarun]

On Tue, May 13, 2014 at 6:34 PM, Ben Greear <greearb@candelatech.com> wrote:
> I just hit strange and wonderful crashes because I managed to use
> an msdu-desc length that was not an even multiple of 8.  Firmware
> has assumption (bug, really) about this.
>
> Bug is only triggerable if you fill up tx-descs, so have to flood UDP
> to hit easily.  I was trying 812 buffers, but 808 works just fine.
> (non CT firmware will not let you do less that 1024, no matter what you
> request, btw).

What chooses the msdu-desc length?  Is there a chance that this would
happen on an unmodified driver?

Avery

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: FYI: msdu-desc must be multiple of 8.

[Ben Greear]

On 05/13/2014 03:42 PM, Avery Pennarun wrote:
> On Tue, May 13, 2014 at 6:34 PM, Ben Greear <greearb@candelatech.com> wrote:
>> I just hit strange and wonderful crashes because I managed to use
>> an msdu-desc length that was not an even multiple of 8.  Firmware
>> has assumption (bug, really) about this.
>>
>> Bug is only triggerable if you fill up tx-descs, so have to flood UDP
>> to hit easily.  I was trying 812 buffers, but 808 works just fine.
>> (non CT firmware will not let you do less that 1024, no matter what you
>> request, btw).
> 
> What chooses the msdu-desc length?  Is there a chance that this would
> happen on an unmodified driver?

It would take someone mucking around in the driver like I was.

Mucking with the vow_config would likely have similar constraints,
but nothing is using that, and I'm not sure firmware even supports it.

See TARGET_10X_NUM_MSDU_DESC

As an aside, if you do manage to crash firmware in this manner, it also
takes down the host when it tries to clean up the stale tx buffers.  Possibly
that bug is just due to some of my own patches, but might be worth investigating
some day when I have more time and a cleaner tree...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com


_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: FYI: msdu-desc must be multiple of 8.

[Avery Pennarun]

On Tue, May 13, 2014 at 6:50 PM, Ben Greear <greearb@candelatech.com> wrote:
> As an aside, if you do manage to crash firmware in this manner, it also
> takes down the host when it tries to clean up the stale tx buffers.  Possibly
> that bug is just due to some of my own patches, but might be worth investigating
> some day when I have more time and a cleaner tree...

At least on my boxes, firmware crashes lead to kernel panics pretty
often, say 1/3 of the time.  There appear to be lots of ways the
cleanups are still not happening properly on a firmware crash.

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k

Re: FYI: msdu-desc must be multiple of 8.

[Kalle Valo]

Avery Pennarun <apenwarr@gmail.com> writes:

> On Tue, May 13, 2014 at 6:50 PM, Ben Greear <greearb@candelatech.com> wrote:
>> As an aside, if you do manage to crash firmware in this manner, it also
>> takes down the host when it tries to clean up the stale tx buffers.  Possibly
>> that bug is just due to some of my own patches, but might be worth investigating
>> some day when I have more time and a cleaner tree...
>
> At least on my boxes, firmware crashes lead to kernel panics pretty
> often, say 1/3 of the time.  There appear to be lots of ways the
> cleanups are still not happening properly on a firmware crash.

I just merged a patch from Michal which I think is related:

7147a13135ee ath10k: protect src_ring state with ce_lock in tx_sg()

Did that help? If not, any chance to get more info? I know these kind of
crashes don't usually provide much information, but even small hints
help.

-- 
Kalle Valo

_______________________________________________
ath10k mailing list
ath10k@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/ath10k