On Fri, Sep 13, 2019 at 09:35:56PM +, Mikolaj Kucharski wrote:
> I've tested monitor mode and it seems to work:
>
> $ ifconfig iwm0
> iwm0: flags=8847 mtu 1500
> lladdr 38:37:8b:XX:XX:XX
> index 1 priority 4 llprio 3
> groups: wlan egress
> media: IEEE802.11 aut
Hi Stefan,
On Fri, Sep 13, 2019 at 02:10:12PM +0200, Stefan Sperling wrote:
> Updated diff, rebased on top of -current
>
> If you were seeing throughput problems when testing this diff in the
> previous round, please try again.
>
> I suspect such problems were due to the ifq drop issue which has
On Fri, Aug 30, 2019 at 03:59:08PM +0200, Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
>
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamo
On Fri, 30 Aug 2019, Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
>
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamous errors in other c
On 30.08., Stefan Sperling wrote:
> I would like to try this again: In iwm(4), process more than one frame
> per Rx interrupt, and enable monitor mode.
>
> Monitor mode triggers "unhandled fimware response" errors without multi-Rx
> support. We have seen these infamous errors in other contexts as w
I would like to try this again: In iwm(4), process more than one frame
per Rx interrupt, and enable monitor mode.
Monitor mode triggers "unhandled fimware response" errors without multi-Rx
support. We have seen these infamous errors in other contexts as well.
It is possible that the firmware decid
