Re: bluetooth related firmware loader spew on resume.

At Thu, 27 Nov 2014 10:46:05 +0100,
Arend van Spriel wrote:

On 11/27/14 10:29, Arend van Spriel wrote:

quoted

On 11/27/14 10:17, Takashi Iwai wrote:

quoted

At Thu, 27 Nov 2014 09:59:12 +0100,
Arend van Spriel wrote:

quoted

On 11/26/14 19:13, Takashi Iwai wrote:

quoted

At Wed, 26 Nov 2014 18:42:46 +0100,
Arend van Spriel wrote:

quoted

On 11/26/14 16:27, Takashi Iwai wrote:

quoted

At Wed, 26 Nov 2014 17:26:15 +0200,
Mihai Donțu wrote:

quoted

On Wed, 26 Nov 2014 16:19:49 +0100
Takashi Iwai[off-list ref] wrote:

quoted

At Wed, 26 Nov 2014 16:56:09 +0200,
Mihai Donțu wrote:

quoted

On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote:

quoted

Since the addition of 10d4c6736ea "Bluetooth: btusb: Add
Broadcom patch
RAM support", I (and a number of other people[*]) have been
seeing
this trace on resume from suspend.

WARNING: CPU: 1 PID: 8565 at
drivers/base/firmware_class.c:1127
_request_firmware+0x4c1/0x7c0()
CPU: 1 PID: 8565 Comm: kworker/u17:0 Not tainted
3.17.2-200.fc20.x86_64 #1
Hardware name: LENOVO 2356JK8/2356JK8, BIOS G7ET94WW (2.54 )
04/30/2013
Workqueue: hci0 hci_power_on [bluetooth]
0000000000000000 00000000f52a564b ffff8800a8c63be8
ffffffff817271cc
0000000000000000 ffff8800a8c63c20 ffffffff81094ced
ffff8800a8c63d10
ffff8801365ddf00 ffff8801387b4b00 ffff8800a8c63d08
00000000fffffff5
Call Trace:
[<ffffffff817271cc>] dump_stack+0x45/0x56
[<ffffffff81094ced>] warn_slowpath_common+0x7d/0xa0
[<ffffffff81094e1a>] warn_slowpath_null+0x1a/0x20
[<ffffffff814965c1>] _request_firmware+0x4c1/0x7c0
[<ffffffff8137b9b9>] ? snprintf+0x49/0x70
[<ffffffff814968f1>] request_firmware+0x31/0x50
[<ffffffffa0943bf3>] btusb_setup_bcm_patchram+0x83/0x550 [btusb]
[<ffffffff8148ecf6>] ? rpm_idle+0xd6/0x2b0
[<ffffffffa0649051>] hci_dev_do_open+0xe1/0xa60 [bluetooth]
ACPI: \_SB_.PCI0.LPC_.EC__.BAT1: docking
Restarting tasks ...
[<ffffffff810bcb3d>] ? ttwu_do_activate.constprop.90+0x5d/0x70
[<ffffffffa064a1c0>] hci_power_on+0x40/0x1e0 [bluetooth]
[<ffffffff810f53fb>] ? lock_timer_base.isra.34+0x2b/0x50
[<ffffffff810acc39>] process_one_work+0x149/0x3d0
[<ffffffff810ad2bb>] worker_thread+0x11b/0x490
[<ffffffff810ad1a0>] ? rescuer_thread+0x2e0/0x2e0
[<ffffffff810b2318>] kthread+0xd8/0xf0
[<ffffffff810b2240>] ? kthread_create_on_node+0x190/0x190
[<ffffffff8172e7bc>] ret_from_fork+0x7c/0xb0
[<ffffffff810b2240>] ? kthread_create_on_node+0x190/0x190
---[ end trace 75a0e9c7f33ebb4c ]---
bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will
not be loaded
Bluetooth: hci0: BCM: patch brcm/BCM20702A0-0a5c-21e6.hcd not
found


At first I thought it was just over-reaction to the file being
missing, but
looking at the WARN_ON, it appears that we're trying to invoke
the firmware
loader before userspace is back up ?

In this (and probably other related) kernel,
CONFIG_FW_LOADER_USER_HELPER is unset,
in case that matters at all.

Dave

[*] https://bugzilla.kernel.org/show_bug.cgi?id=81821
https://bugzilla.redhat.com/show_bug.cgi?id=1133378

I have the following during normal boot:

[ 5.620796] Bluetooth: hci0: read Intel version:
370710018002030d00
[ 5.620822] bluetooth hci0: Direct firmware load for
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq failed with error -2
[ 5.620827] Bluetooth: hci0 failed to open Intel firmware file:
intel/ibt-hw-37.7.10-fw-1.80.2.3.d.bseq(-2)
[ 5.620920] bluetooth hci0: Direct firmware load for
intel/ibt-hw-37.7.bseq failed with error -2
[ 5.620922] Bluetooth: hci0 failed to open default Intel fw
file: intel/ibt-hw-37.7.bseq
[ 5.629910] EXT4-fs (sda2): mounted filesystem with ordered
data mode. Opts: (null)
[ 5.629916] VFS: Mounted root (ext4 filesystem) readonly on
device 8:2.

The driver is trying to load the firmware before root is
mounted. Do I
really need an initramfs?

If btusb driver is loaded in initrd, you'd need the corresponding
firmware in initrd, too.

The driver is built into the kernel and I don't use an initrd. I
could
probably create one, but it's a bit tricky with UEFI and a tad
harder
to maintain.

Then you can build the firmware file into kernel, too.

huh? The whole idea of the firmware API was to keep (often
proprietary)
firmware out of the kernel. Has that strategy been abandoned recently?

See CONFIG_EXTRA_FIRMARE. It doesn't mean to include the binary blob
into the kernel source tree. It just allows to *build* into your
kernel.

So I looked at this Kconfig option and reading the help I came across 
this warning:

"""
WARNING: If you include additional firmware files into your binary 
kernel image that are not available under the terms of the GPL, 
then it may be a violation of the GPL to distribute the resulting 
image since it combines both GPL and non-GPL work. You should 
consult a lawyer of your own before distributing such an image.
"""

This is exactly what I meant, by "(often proprietary) firmware". So we 
should conclude that if a device needs proprietary firmware it can not 
be built-in the kernel if intended for distribution.

Well, that's why I've repeatedly written it's for *building* the
kernel.  Building a kernel in such a way and using it is no problem.
The problem happens only when you distribute it.  So, this doesn't
apply to the distro kernels, of course.  Think separately between
build and distribution.

In Michai's case, he's certainly building the kernel manually (that's
why btusb is built-in, which usually isn't so on distro kernels).


Takashi