Jes Sorensen <jes.soren...@redhat.com> writes:
> Larry Finger <larry.fin...@lwfinger.net> writes:
>>> +static void rtl8xxxu_tx(struct ieee80211_hw *hw,
>>> +                   struct ieee80211_tx_control *control,
>>> +                   struct sk_buff *skb)
>>> +{
>>> +   struct ieee80211_hdr *hdr = (struct ieee80211_hdr *)skb->data;
>>> +   struct ieee80211_tx_info *tx_info = IEEE80211_SKB_CB(skb);
>>> +   struct ieee80211_rate *tx_rate = ieee80211_get_tx_rate(hw, tx_info);
>>> +   struct rtl8xxxu_priv *priv = hw->priv;
>>> +   struct rtl8xxxu_tx_desc *tx_desc;
>>> +   struct ieee80211_sta *sta = NULL;
>>> +   struct rtl8xxxu_sta_priv *sta_priv = NULL;
>>> +   struct device *dev = &priv->udev->dev;
>>> +   struct urb *urb;
>>> +   u32 queue, rate;
>>> +   u16 pktlen = skb->len;
>>> +   u16 seq_number;
>>> +   u16 rate_flag = tx_info->control.rates[0].flags;
>>> +   int ret;
>>> +
>>> +   if (skb_headroom(skb) < sizeof(struct rtl8xxxu_tx_desc)) {
>>> +           dev_warn(dev,
>>> +                    "%s: Not enough headroom (%i) for tx descriptor\n",
>>> +                    __func__, skb_headroom(skb));
>>> +           goto error;
>>> +   }
>>> +
>>> +   if (unlikely(skb->len > (65535 - sizeof(struct rtl8xxxu_tx_desc)))) {
>>> +           dev_warn(dev, "%s: Trying to send over-sized skb (%i)\n",
>>> +                    __func__, skb->len);
>>> +           goto error;
>>> +   }
>>> +
>>> +   urb = usb_alloc_urb(0, GFP_KERNEL);
>>
>> The above statement generated a "scheduling while atomic" splat. The
>> gfp_t argument needs to be GFP_KERNEL.
>
> You are seeing scheduling while atomic in the TX path? That just seems
> wrong to me - Johannes is the mac80211 TX path not meant to allow
> sleeping?

I went and checked include/net/mac80211.h and indeed you are right.
Updated patch fixing these issues, and hopefully mutex issue, coming you
way in a minute.

Cheers,
Jes
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Reply via email to