Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c >> > > Certainly looks like a plausible solution, will build kernel tonight to > confirm. Just to confirm; 4.2rc1 + above patch, and 4.2rc2 both function correctly and I no longer see the lock up/Oops. Thanks to all who helped out, Simon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c Certainly looks like a plausible solution, will build kernel tonight to confirm. Just to confirm; 4.2rc1 + above patch, and 4.2rc2 both function correctly and I no longer see the lock up/Oops. Thanks to all who helped out, Simon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
> On 07/17/2015 08:14 AM, si...@mungewell.org wrote: >> So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. >>> >>> The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware >>> data manually by accessing /sys/class/firmware//data. It runs in >>> case the firmware file is missing. >>> This user helper fallback will be enabled if one of LP55xx driver is >>> included in your dot config. Please see my patch below. >>> >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c >>> >>> However, I'm not sure why this affects your system lockup. Can I have >>> more details? >> >> Hi Milo, >> I'm not suggesting that your patch is the cause, just that it is an >> 'enabler' and and explains why the problem (system lockup when I plug >> USB >> Bluetooth dongle in) appears now. >> >> A full Oops log is further back in this thread: >> http://www.spinics.net/lists/linux-bluetooth/msg63090.html >> >> Will try building 4.1 with this option to see if it fails. >> >> A very quick test as I was leaving the house this morning shows that 4.1 >> with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. >> >> So at least we know the 'real' problem is a recent change to the code. >> Simon >> > > I think this was reported and fixed > > https://lkml.org/lkml/2015/7/8/858 > https://lkml.org/lkml/2015/7/8/1199 > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c > Certainly looks like a plausible solution, will build kernel tonight to confirm. If Shuah is still looking for the trigger, see above note regarding 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK'. Thanks, and have an awesome weekend. :-) Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing /sys/class/firmware//data. It runs in case the firmware file is missing. This user helper fallback will be enabled if one of LP55xx driver is included in your dot config. Please see my patch below. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c However, I'm not sure why this affects your system lockup. Can I have more details? Hi Milo, I'm not suggesting that your patch is the cause, just that it is an 'enabler' and and explains why the problem (system lockup when I plug USB Bluetooth dongle in) appears now. A full Oops log is further back in this thread: http://www.spinics.net/lists/linux-bluetooth/msg63090.html Will try building 4.1 with this option to see if it fails. A very quick test as I was leaving the house this morning shows that 4.1 with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. So at least we know the 'real' problem is a recent change to the code. Simon I think this was reported and fixed https://lkml.org/lkml/2015/7/8/858 https://lkml.org/lkml/2015/7/8/1199 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c Thanks, Laura -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
>> So in summary this problem is showing up now as the 'User Helper >> Fallback' >> is now forced on, obviously the underlying problem needs to be fixed - >> but >> I don't know when it crept in. >> > > The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware > data manually by accessing /sys/class/firmware//data. It runs in > case the firmware file is missing. > This user helper fallback will be enabled if one of LP55xx driver is > included in your dot config. Please see my patch below. > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c > > However, I'm not sure why this affects your system lockup. Can I have > more details? Hi Milo, I'm not suggesting that your patch is the cause, just that it is an 'enabler' and and explains why the problem (system lockup when I plug USB Bluetooth dongle in) appears now. A full Oops log is further back in this thread: http://www.spinics.net/lists/linux-bluetooth/msg63090.html >> Will try building 4.1 with this option to see if it fails. A very quick test as I was leaving the house this morning shows that 4.1 with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. So at least we know the 'real' problem is a recent change to the code. Simon -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
Hi Simon, On 7/17/2015 3:14 PM, si...@mungewell.org wrote: It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- /boot/config-4.2.0-rc1+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
> It looks like the firmware 'opt_flags' must be different, so this may be a > contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- /boot/config-4.2.0-rc1+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE="" CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing /sys/class/firmware/name/data. It runs in case the firmware file is missing. This user helper fallback will be enabled if one of LP55xx driver is included in your dot config. Please see my patch below. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c However, I'm not sure why this affects your system lockup. Can I have more details? Hi Milo, I'm not suggesting that your patch is the cause, just that it is an 'enabler' and and explains why the problem (system lockup when I plug USB Bluetooth dongle in) appears now. A full Oops log is further back in this thread: http://www.spinics.net/lists/linux-bluetooth/msg63090.html Will try building 4.1 with this option to see if it fails. A very quick test as I was leaving the house this morning shows that 4.1 with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. So at least we know the 'real' problem is a recent change to the code. Simon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE= CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- /boot/config-4.2.0-rc1+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE= CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y !!! CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- Has a kconfig forced a change? Grrr -- $ git blame ./drivers/leds/Kconfig -- c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 228) config LEDS_LP55XX_COMMON 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 229) tristate Common Driver for TI/National LP5521/5523/55231/5562/8501 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 230) depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501 10c06d178 (Milo(Woogyom) Kim 2013-02-05 19:17:20 +0900 231) select FW_LOADER b67893206 (Milo Kim 2015-06-28 17:39:14 -0700 232) select FW_LOADER_USER_HELPER_FALLBACK - c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 233) help 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 234) This option supports common operations for LP5521/5523/55231/5562/8501 c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 235) devices. -- So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. Will try building 4.1 with this option to see if it fails. Simon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
Hi Simon, On 7/17/2015 3:14 PM, si...@mungewell.org wrote: It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. Plot thickens kernel config has changed since I built 4.1.0rc7, but I don't recall doing it or starting a fresh. /boot/config-4.1.0-rc7+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE= CONFIG_FW_LOADER_USER_HELPER=y # CONFIG_FW_LOADER_USER_HELPER_FALLBACK is not set CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- /boot/config-4.2.0-rc1+ -- CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_FIRMWARE_IN_KERNEL=y CONFIG_EXTRA_FIRMWARE= CONFIG_FW_LOADER_USER_HELPER=y CONFIG_FW_LOADER_USER_HELPER_FALLBACK=y !!! CONFIG_WANT_DEV_COREDUMP=y CONFIG_ALLOW_DEV_COREDUMP=y CONFIG_DEV_COREDUMP=y -- Has a kconfig forced a change? Grrr -- $ git blame ./drivers/leds/Kconfig -- c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 228) config LEDS_LP55XX_COMMON 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 229) tristate Common Driver for TI/National LP5521/5523/55231/5562/8501 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 230) depends on LEDS_LP5521 || LEDS_LP5523 || LEDS_LP5562 || LEDS_LP8501 10c06d178 (Milo(Woogyom) Kim 2013-02-05 19:17:20 +0900 231) select FW_LOADER b67893206 (Milo Kim 2015-06-28 17:39:14 -0700 232) select FW_LOADER_USER_HELPER_FALLBACK - c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 233) help 33b3a561f (Kim, Milo 2013-07-09 02:11:37 -0700 234) This option supports common operations for LP5521/5523/55231/5562/8501 c93d08fa7 (Milo(Woogyom) Kim 2013-02-05 18:01:23 +0900 235) devices. -- So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing /sys/class/firmware/name/data. It runs in case the firmware file is missing. This user helper fallback will be enabled if one of LP55xx driver is included in your dot config. Please see my patch below. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c However, I'm not sure why this affects your system lockup. Can I have more details? Best regards, Milo -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing /sys/class/firmware/name/data. It runs in case the firmware file is missing. This user helper fallback will be enabled if one of LP55xx driver is included in your dot config. Please see my patch below. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c However, I'm not sure why this affects your system lockup. Can I have more details? Hi Milo, I'm not suggesting that your patch is the cause, just that it is an 'enabler' and and explains why the problem (system lockup when I plug USB Bluetooth dongle in) appears now. A full Oops log is further back in this thread: http://www.spinics.net/lists/linux-bluetooth/msg63090.html Will try building 4.1 with this option to see if it fails. A very quick test as I was leaving the house this morning shows that 4.1 with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. So at least we know the 'real' problem is a recent change to the code. Simon I think this was reported and fixed https://lkml.org/lkml/2015/7/8/858 https://lkml.org/lkml/2015/7/8/1199 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c Thanks, Laura -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
On 07/17/2015 08:14 AM, si...@mungewell.org wrote: So in summary this problem is showing up now as the 'User Helper Fallback' is now forced on, obviously the underlying problem needs to be fixed - but I don't know when it crept in. The 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' enables to load firmware data manually by accessing /sys/class/firmware/name/data. It runs in case the firmware file is missing. This user helper fallback will be enabled if one of LP55xx driver is included in your dot config. Please see my patch below. https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/leds?id=b67893206fc0a0e8af87130e67f3d8ae553fc87c However, I'm not sure why this affects your system lockup. Can I have more details? Hi Milo, I'm not suggesting that your patch is the cause, just that it is an 'enabler' and and explains why the problem (system lockup when I plug USB Bluetooth dongle in) appears now. A full Oops log is further back in this thread: http://www.spinics.net/lists/linux-bluetooth/msg63090.html Will try building 4.1 with this option to see if it fails. A very quick test as I was leaving the house this morning shows that 4.1 with 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK' does not show the problem. So at least we know the 'real' problem is a recent change to the code. Simon I think this was reported and fixed https://lkml.org/lkml/2015/7/8/858 https://lkml.org/lkml/2015/7/8/1199 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=6f957724b94cb19f5c1c97efd01dd4df8ced323c Certainly looks like a plausible solution, will build kernel tonight to confirm. If Shuah is still looking for the trigger, see above note regarding 'CONFIG_FW_LOADER_USER_HELPER_FALLBACK'. Thanks, and have an awesome weekend. :-) Simon -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
> [ 117.236007] [] device_del+0x18f/0x270 > [ 117.236007] [] ? wake_up_q+0x70/0x70 > [ 117.236007] [] _request_firmware+0x5aa/0xaf0 > [ 117.236007] [] request_firmware+0x35/0x50 > [ 117.236007] [] btbcm_setup_patchram+0x191/0x910 > [btbcm] > [ 117.236007] [] ? rpm_idle+0xc4/0x200 > [ 117.236007] [] hci_dev_do_open+0xd8/0x500 Looking between log from 3.19 -- Jul 7 21:42:57 retrobox kernel: [ 107.562441] bluetooth hci0: Direct firmware load for brcm/BCM20702A0-0a5c-21e8.hcd failed with error -2 Jul 7 21:42:57 retrobox kernel: [ 107.562452] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e8.hcd not found -- And the log of the lockup: https://www.flickr.com/photos/24244464@N03/19375918529/sizes/o/ It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. In fact I found a log from 4.1.0rc7, which shows they recently changed!! -- Jul 15 21:17:40 blind-fury kernel: [0.00] Linux version 4.1.0-rc7+ (root@blind-fury) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #2 SMP Wed Jun 10 21:25:17 MDT 2015 Jul 15 21:17:40 blind-fury kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc7+ root=UUID=56684438-bf61-422a-9c47-e0d7e405f4e7 ro quiet splash ... Jul 15 21:20:04 blind-fury kernel: [ 173.591327] usbcore: registered new interface driver btusb Jul 15 21:20:04 blind-fury kernel: [ 173.604148] Bluetooth: hci0: BCM: chip id 63 Jul 15 21:20:04 blind-fury kernel: [ 173.606079] Bluetooth: hci0: BCM20702A1 (001.002.014) build Jul 15 21:20:04 blind-fury kernel: [ 173.628434] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2 Jul 15 21:20:04 blind-fury kernel: [ 173.628439] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21e8.hcd not found -- These are checked here, but code hasn't changed recently: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/firmware_class.c?id=6593d9245bc66e6e3cf4ba6d365a7833110c1402#n1135 There has been changes to the btbcm.c code wrt to firmware loading: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btbcm.c?id=18aeb4445aa00f6f402ba3a92a2e9ff3d13882b4 Simon. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
[ 117.236007] [814d2ccf] device_del+0x18f/0x270 [ 117.236007] [8109b340] ? wake_up_q+0x70/0x70 [ 117.236007] [814e97da] _request_firmware+0x5aa/0xaf0 [ 117.236007] [814e9d55] request_firmware+0x35/0x50 [ 117.236007] [c00fb881] btbcm_setup_patchram+0x191/0x910 [btbcm] [ 117.236007] [814e0994] ? rpm_idle+0xc4/0x200 [ 117.236007] [c0e28488] hci_dev_do_open+0xd8/0x500 Looking between log from 3.19 -- Jul 7 21:42:57 retrobox kernel: [ 107.562441] bluetooth hci0: Direct firmware load for brcm/BCM20702A0-0a5c-21e8.hcd failed with error -2 Jul 7 21:42:57 retrobox kernel: [ 107.562452] Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e8.hcd not found -- And the log of the lockup: https://www.flickr.com/photos/24244464@N03/19375918529/sizes/o/ It looks like the firmware 'opt_flags' must be different, so this may be a contributing factor. In fact I found a log from 4.1.0rc7, which shows they recently changed!! -- Jul 15 21:17:40 blind-fury kernel: [0.00] Linux version 4.1.0-rc7+ (root@blind-fury) (gcc version 4.9.2 (Ubuntu 4.9.2-10ubuntu13) ) #2 SMP Wed Jun 10 21:25:17 MDT 2015 Jul 15 21:17:40 blind-fury kernel: [0.00] Command line: BOOT_IMAGE=/boot/vmlinuz-4.1.0-rc7+ root=UUID=56684438-bf61-422a-9c47-e0d7e405f4e7 ro quiet splash ... Jul 15 21:20:04 blind-fury kernel: [ 173.591327] usbcore: registered new interface driver btusb Jul 15 21:20:04 blind-fury kernel: [ 173.604148] Bluetooth: hci0: BCM: chip id 63 Jul 15 21:20:04 blind-fury kernel: [ 173.606079] Bluetooth: hci0: BCM20702A1 (001.002.014) build Jul 15 21:20:04 blind-fury kernel: [ 173.628434] bluetooth hci0: Direct firmware load for brcm/BCM20702A1-0a5c-21e8.hcd failed with error -2 Jul 15 21:20:04 blind-fury kernel: [ 173.628439] Bluetooth: hci0: BCM: Patch brcm/BCM20702A1-0a5c-21e8.hcd not found -- These are checked here, but code hasn't changed recently: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/base/firmware_class.c?id=6593d9245bc66e6e3cf4ba6d365a7833110c1402#n1135 There has been changes to the btbcm.c code wrt to firmware loading: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/drivers/bluetooth/btbcm.c?id=18aeb4445aa00f6f402ba3a92a2e9ff3d13882b4 Simon. -- To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/