The kernel messages pointed out here aren't come from anything in the precise kernel but rather from modules included via compat-drivers. I found that compat-wireless-3.10-dkms 3.10~rc1~2.20130618.sutton3 is installed, and if that's really coming from an rc1 kernel then there may well be some bug fixes. Releasing anything based off of rc1 code seems like a bad idea.
Since I'm not sure where the source lives for this compat-wireless package I looked at something more recent. Based on that I don't think this is a race between bluez and the kernel (though the fact that adding a delay helps implies that there's likely a race somewhere). There's a setup callback that gets called when userspace opens the device that prints these messages, and that callback tries to issue these commands which are failing and then load the firmware. So it's not a matter of doing stuff before the firmware is loaded, it's that some commands to the device are failing.
There _are_ several commits since 3.10-rc1 dealing with either races (one specifically related to rfkill and device setup) or handling of power on failures. I think we need some testing against the trusty kernel to see if the problem still exists, and if not we can try to find what fixed it. And I'd also like to reiterate the request for logs in comment #6.
A few observations.
The kernel messages pointed out here aren't come from anything in the precise kernel but rather from modules included via compat-drivers. I found that compat- wireless- 3.10-dkms 3.10~rc1~ 2.20130618. sutton3 is installed, and if that's really coming from an rc1 kernel then there may well be some bug fixes. Releasing anything based off of rc1 code seems like a bad idea.
Since I'm not sure where the source lives for this compat-wireless package I looked at something more recent. Based on that I don't think this is a race between bluez and the kernel (though the fact that adding a delay helps implies that there's likely a race somewhere). There's a setup callback that gets called when userspace opens the device that prints these messages, and that callback tries to issue these commands which are failing and then load the firmware. So it's not a matter of doing stuff before the firmware is loaded, it's that some commands to the device are failing.
There _are_ several commits since 3.10-rc1 dealing with either races (one specifically related to rfkill and device setup) or handling of power on failures. I think we need some testing against the trusty kernel to see if the problem still exists, and if not we can try to find what fixed it. And I'd also like to reiterate the request for logs in comment #6.