Hi Linus, >> Yes 81f95076281f is to blame.. After reverting it all is fine again. >> >> 15 resume cycles on the one laptop , 10 on the other without to hit the >> trace. > > Yeah, I think that disable/enable_firmware in the suspend/resume path > is basically just completely random code. There is nothing that > serializes with anything else, and it has no actual basis for saying > "I am now disabled/enabled" except for some entirely random time of > whenever the suspend/resume callbacks happen. > > I'm going to revert it. > > I wonder why 4.13 seemed to work for me. Or maybe it didn't, and I > just didn't notice, because I didn't use bluetooth and I wasn't > traveling. I test my laptop every release, but I don't necessarily > always _use_ it. we have a bug report that might go into the similar direction. So the problem is that modern Bluetooth controller require full firmware loading (not just ROM patching) and if the controller has the firmware somehow already loaded, but then looses power and needs a reload, then it is not cached (since it was never requested in the first place). Of course if the reload triggers during resume when not file system is available, it can not request the firmware. That will just fail and thus you might see this issue. We have a few RFC patches on the mailing list that I have to review. It is however not that easy all the time to find the right firmware file (at least not for Intel hardware) since the boot loader provides different information than the fully operational firmware. So I need to make sure that request the right firmware (if we do not need it initially) so that it gets cached. Regards Marcel -- To unsubscribe from this list: send the line "unsubscribe linux-bluetooth" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
