Re: bluetooth related firmware loader spew on resume.

[Takashi Iwai <tiwai@suse.de>]

At Thu, 27 Nov 2014 10:46:05 +0100,
Arend van Spriel wrote:
> 
> On 11/27/14 10:29, Arend van Spriel wrote:
> > On 11/27/14 10:17, Takashi Iwai wrote:
> >> At Thu, 27 Nov 2014 09:59:12 +0100,
> >> Arend van Spriel wrote:
> >>>
> >>> On 11/26/14 19:13, Takashi Iwai wrote:
> >>>> At Wed, 26 Nov 2014 18:42:46 +0100,
> >>>> Arend van Spriel wrote:
> >>>>>
> >>>>> On 11/26/14 16:27, Takashi Iwai wrote:
> >>>>>> At Wed, 26 Nov 2014 17:26:15 +0200,
> >>>>>> Mihai Donțu wrote:
> >>>>>>>
> >>>>>>> On Wed, 26 Nov 2014 16:19:49 +0100
> >>>>>>> Takashi Iwai<tiwai@suse.de> wrote:
> >>>>>>>
> >>>>>>>> At Wed, 26 Nov 2014 16:56:09 +0200,
> >>>>>>>> Mihai Donțu wrote:
> >>>>>>>>>
> >>>>>>>>> On Tue, 11 Nov 2014 13:12:28 -0500 Dave Jones wrote:
> >>>>>>>>>> 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