https://bugzilla.kernel.org/show_bug.cgi?id=51221 --- Comment #13 from Paul Bolle <pebolle@xxxxxxxxxx> --- (In reply to Paul Bolle from comment #12) > With rpms (built for Fedora 15) downloaded from koji.fedoraproject.org I've > been able to narrow this down to 4.79 and 4.80. To be continued. I've bisected this down to bluez commit b8486f046aadbe0145519c86a087e880fd1d638f ("Move more hciops specific functionality into hciops"). I'm not sure why things change after this commit. But please note that this commit does move code around that is specific to this Broadcom controller. So this bisect isn't obviously bogus. See this annotation snippet: +static uint8_t get_inquiry_mode(int index) +{ [...] + if (VER(index).manufacturer == 15) { [...] + if (VER(index).hci_rev == 0x09 && + VER(index).lmp_subver == 0x6963) + return 1; [That is this controller!] [...] + } [...] + return 0; +} > (Note that the 4.80 error mode is slightly different. There the headset > seems to keep waiting for a pairing request (or whatever) forever.) Up to 4.81 the headset (apparently) stays in pairing mode. Perhaps it never receives a request. By 4.85 that behavior changes. The headset leaves pairing mode if one tries to pair from the laptop using this controller. I haven't yet bothered to further pinpoint the commit that causes that change in behavior. Anyhow, it is getting likely that this is not a kernel bug. Should I move this to a bluez specific bug tracker? -- You are receiving this mail because: You are the assignee for the bug. -- 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
