On Sat, 30 Dec, 2023 18:41:13 +0100 Michael Büsch <m@xxxxxxx> wrote:
> [[PGP Signed Part:Undecided]]
> On Sat, 30 Dec 2023 17:15:18 +0000
> Rahul Rameshbabu <sergeantsagara@xxxxxxxxxxxxxx> wrote:
>
>> On Sat, 30 Dec, 2023 14:40:36 +0100 Michael Büsch <m@xxxxxxx> wrote:
>> > [[PGP Signed Part:Undecided]]
>> > On Sat, 30 Dec 2023 18:48:45 +1100
>> > Julian Calaby <julian.calaby@xxxxxxxxx> wrote:
>> >> > --- a/drivers/net/wireless/broadcom/b43/dma.c
>> >> > +++ b/drivers/net/wireless/broadcom/b43/dma.c
>> >> > @@ -1399,7 +1399,10 @@ int b43_dma_tx(struct b43_wldev *dev, struct sk_buff *skb)
>> >> > should_inject_overflow(ring)) {
>> >> > /* This TX ring is full. */
>> >> > unsigned int skb_mapping = skb_get_queue_mapping(skb);
>> >> > - ieee80211_stop_queue(dev->wl->hw, skb_mapping);
>> >> > + if (dev->qos_enabled)
>> >> > + ieee80211_stop_queue(dev->wl->hw, skb_mapping);
>> >> > + else
>> >> > + ieee80211_stop_queue(dev->wl->hw, 0);
>> >>
>> >> Would this be a little cleaner if we only look up the queue mapping if
>> >> QOS is enabled? I.e.
>> >
>> > No. It would break the other uses of skb_mapping.
>> >
>> > But I am wondering why skb_mapping is non-zero in the first place.
>> > I think the actual bug might be somewhere else.
>>
>> Right, skb_mapping is used to map to the correct software structures DMA
>> mapped to the device. The reason the mapping for the best effort queue
>> (the default/defacto when QoS is disabled) is not zero is due to the way
>> initialization of the queues/rings occurs in the driver. The best effort
>> queue is mapped as the third queue, which leads to this issue when QoS
>> is disabled. Would it make more sense to change the mappings in
>> initialization such that the best effort queue is by default mapped to
>> zero, so we would not need such conditionals?
>
> Maybe it is a good idea to find the patch that broke non-QoS.
> That possibly helps to understand the situation.
>
> Non-QoS used to work just fine.
I did some git analysis, and I actually believe that this issue has been
present since the commit e6f5b934fba8 ("b43: Add QOS support"). Before
then, non-QOS would not trigger this issue. There is a cosmetic change
after this commit, b27faf8ebf25 ("b43: Rename the DMA ring pointers"),
but this change does not introduce the issue (but makes it more
obvious). I think the reason nobody has ever reported this is that even
when the warnings are triggered, everything appears to work fine. I
think therefore the two options are the following.
1. Remap the BE queue to 0 instead of the BK queue.
2. Use this kind of conditional to handle the mapping when QoS is
disabled.
--
Thanks,
Rahul Rameshbabu
