I suggested a patch for loading modules from interruptible mode, but
this patch remained unclaimed (
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124851.html
).
For some reason I thought that this patch had been removed and did not
track the fate of this code (
http://driverdev.linuxdriverproject.org/pipermail/driverdev-devel/2018-August/124573.html
).
On 1/1/19 5:17 AM, Larry Finger wrote:
On 12/30/18 12:39 PM, Michael Straube wrote:
Commit 6bd082af7e36 ("staging:r8188eu: use lib80211 CCMP decrypt")
is causing hardfreeze whenever the driver tries to connect to my wifi
network. That makes the driver unusable on my system. Reverting the
commit fixes the issue and the driver works properly.
Dec 29 19:21:17 gentoo kernel: BUG: scheduling while atomic:
swapper/6/0/0x00000100
Michael,
I have verified the freezes that you see. Although I have not been able
to capture the console dump, I think we are likely seeing the same problem.
I do have a work-around in that I have not gotten any freezes when I
force module lib80211_crypt_ccmp to be loaded before I load module
r8188eu. This clue was used in finding what seems to be a good fix.
I do not know anything about demand loading of modules using
try_then_request_module(); however, I noticed that the macro actually
calls __request_module(), which has the following comment:
* Load a module using the user mode module loader. The function returns
* zero on success or a negative errno code or positive exit code from
* "modprobe" on failure. Note that a successful module load does not mean
* the module did not then unload and exit on an error of its own. Callers
* must check that the service they requested is now available not blindly
* invoke it.
I note that it says "user mode module loader". Routine rtw_aes_decrypt()
is likely inside some sort of locking, which leads to the "scheduling
while atomic" bug that you see. As a result, I suspect that the module
is not loaded, and that leads to the NULL dereference when the module is
accessed. Please try the one-line patch attached, which forces lib80211
to load when r8188eu is loaded. With this patch, I have been connected
to an AES-encrypted AP for nearly 3 hours with no problems.
Larry
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
