> 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. -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
