Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1186466 > unrolled thread

Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

Started bysimon@mungewell.org
First post2015-07-17 07:20 +0200
Last post2015-07-17 09:10 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.


Contents

  Re: Kernel Oops: btusb:  4.2rc1 System lockup with BT dongle insert  - log attached simon@mungewell.org - 2015-07-17 07:20 +0200
    Re: Kernel Oops: btusb:  4.2rc1 System lockup with BT dongle insert  - log attached simon@mungewell.org - 2015-07-17 08:20 +0200
      Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert -  log attached "Kim, Milo" <milo.kim@ti.com> - 2015-07-17 09:10 +0200

#1186466 — Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

Fromsimon@mungewell.org
Date2015-07-17 07:20 +0200
SubjectRe: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
Message-ID<pN6dZ-4dF-35@gated-at.bofh.it>
> [  117.236007]  [<ffffffff814d2ccf>] device_del+0x18f/0x270
> [  117.236007]  [<ffffffff8109b340>] ? wake_up_q+0x70/0x70
> [  117.236007]  [<ffffffff814e97da>] _request_firmware+0x5aa/0xaf0
> [  117.236007]  [<ffffffff814e9d55>] request_firmware+0x35/0x50
> [  117.236007]  [<ffffffffc00fb881>] btbcm_setup_patchram+0x191/0x910
> [btbcm]
> [  117.236007]  [<ffffffff814e0994>] ? rpm_idle+0xc4/0x200
> [  117.236007]  [<ffffffffc0e28488>] 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.000000] 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.000000] 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 0000
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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1186484

Fromsimon@mungewell.org
Date2015-07-17 08:20 +0200
Message-ID<pN7a2-5ys-7@gated-at.bofh.it>
In reply to#1186466
> 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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1186514 — Re: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached

From"Kim, Milo" <milo.kim@ti.com>
Date2015-07-17 09:10 +0200
SubjectRe: Kernel Oops: btusb: 4.2rc1 System lockup with BT dongle insert - log attached
Message-ID<pN7Wq-6HE-15@gated-at.bofh.it>
In reply to#1186484
Hi Simon,

On 7/17/2015 3:14 PM, simon@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 majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web