Re: [BISECTED] 4943ba16 ("include crypto- module prefix") breaks wifi

["George Spelvin" <linux@horizon.com>]

> And now my head-scratching: your bisect shows that v3.19-rc7 fails,
> but that prior to 4943ba16bbc2, things work correctly? As in, when
> _only_ 5d26a105b5a7 is in your tree things _work_?

Basically, yes.  v3.19-rc7 fails with basically the same symptoms:
wpa_supplicant keeps looping trying to associate.  I haven't compared
the log messages line-by-line.

It appears that it negotiates a crypto key and then fails to pass
it down to the kernel.

I haven't tested 5d26a105b5a7 specifically (when you say "_only_
5d26a105b5a7 is in your tree", do you mean that state, or that commit
cherry-picked?), but 4 commits later (476c7fe20f30) did get tested,
and it worked.  (In fact, that was the final test in my bisect
process; once I typed "git bisect good", things worked.)

Also, one more detail:
- When I changed CTR and CCM from =m to =y, things started working.

Perhaps it's the unexpected case of a module using a static algorithm?
Anyway, let me collect more information before you put more time into
it.

> Could you rename and instrument your /sbin/modprobe to do something like:
>
> #!/bin/sh
> echo "$@" >> /root/modprobe.log
> exec /sbin/modprobe.bin "$@"
> 
> Perhaps there's something being explicitly requested rather than
> having it be kernel auto-loaded?

Glad to.  Thanks for the pointer!

Unless you say otherwise, I'll probably test on 3.19 release, since that
seems the most useful baseline for future repair.