Re: [PATCH 1/1] New driver: rtl8xxxu (mac80211)

[Larry Finger <Larry.Finger@lwfinger.net>]

On 08/30/2015 09:39 PM, Jes Sorensen wrote:
> Larry Finger <Larry.Finger@lwfinger.net> writes:
>> On 08/30/2015 01:41 PM, Jes Sorensen wrote:
>>>> 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 have never seen this on x86 and I have been running the driver for a
>>> long time. It is puzzling this causes a problem on PowerPC. It there
>>> something special in the config for it? I am inclined to say there is
>>> something wrong with the PPC32 setup rather than with my usage of
>>> GFP_KERNEL in the TX path.
>>
>> The scheduling while atomic problem is on x86_64, not on PPC. I have
>> lots of debugging/testing turned on in my configuration, but I cannot
>> really identify which one might turn on the message. My config uses
>> SLUB memory allocation, but that shouldn't matter either.
>
> I had some problems with mail delivery, so you may receive another
> answer later - I checked up on it, and it was indeed a bug. You can
> check my git branch for a version that won't suffer from this.
>
>>>>> +{USB_DEVICE_AND_INTERFACE_INFO(USB_VENDOR_ID_REALTEK, 0x817e, 0xff,
>>>> 0xff, 0xff),
>>>>> +	.driver_info = (unsigned long)&rtl8192cu_fops},
>>>>
>>>> I have tested a device with USB ID 0x0bda (USB_VENDOR_ID_REALTEK):0x817e.
>>>
>>> Were you happy with the results, or did it cause problems? Ie. did you
>>> try on x86 or on PPC32?
>>
>> As covered in the other mail, it works very well at G rates.
>
> I see - I am a little confused, it works well on G rates but not on N
> rates, or was this due to the AP used?

The AP is AC1200. It supports full N rates on other devices.
>
>>> I don't think any of this is showstopper material for inclusion right
>>> now, albeit I do want to address them.
>>
>> The scheduling while atomic problems do need to be fixed, and I am
>> still working on the failure to get a wifi device on PPC.
>
> It's already fixed :)

A full debug=0x3fff showed me one problem on the PPC. I will be testing a patch 
later today.

Larry