Bug#764263: linux-image-3.16-2-amd64: WARNING at drivers/base/firmware_class.c:1109 _request_firmware+0x521/0xaf0() [btusb?]

[Bjørn Mork <bjorn@mork.no>]

Ben Hutchings <ben@decadent.org.uk> writes:

> On Mon, 2014-10-06 at 20:15 +0200, Julien Cristau wrote:
>> Package: src:linux
>> Version: 3.16.3-2
>> Severity: normal
>> 
>> Hi,
>> 
>> I get the following trace in my kernel log, which I don't think I've
>> seen in pre-3.16 versions:
>> 
>> Sep 29 19:12:49 betterave kernel: [ 7696.920600] PM: resume of devices complete after 508.149 msecs
>> Sep 29 19:12:49 betterave kernel: [ 7696.921181] ------------[ cut here ]------------
>> Sep 29 19:12:49 betterave kernel: [ 7696.921188] WARNING: CPU: 2 PID: 3533 at /build/linux-P15SNz/linux-3.16.3/drivers/base/firmware_class.c:1109 _request_firmware+0x521/0xaf0()
> [...]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921405]  [<ffffffff813af8ac>] ? request_firmware+0x2c/0x40
>> Sep 29 19:12:49 betterave kernel: [ 7696.921412]  [<ffffffffa065f895>] ? btusb_setup_bcm_patchram+0x85/0x430 [btusb]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921419]  [<ffffffff813a663a>] ? rpm_check_suspend_allowed+0x6a/0xc0
> [...]
>> Sep 29 19:12:49 betterave kernel: [ 7696.921528] bluetooth hci0: firmware: brcm/BCM20702A0-0a5c-21e6.hcd will not be loaded
> [...]
>
> This means: btusb tries to load firmware during its resume operation,
> when userland is not yet available.  This doesn't work if firmware
> loading depends on the userland firmware agent.
>
> The warning won't appear if the firmware is installed in the usual
> place, as direct loading will work.  And the firmware agent is npw
> deprecated and not even enabled in Debian kernels.  We could remove this
> warning, but it would be papering over a driver bug.

Are you sure about this?  FWIW I've occasionally seen similar warnings
from another btusb device with firmware (using kernels I've built
myself, so not reported here of course). And I haven't really bothered to
look at the root cause before, so I haven't reported it upstream either.

But looking at _request_firmware() now it seems to me that this warning
is triggered _before_ we attempt any direct loading:


_request_firmware(const struct firmware **firmware_p, const char *name,
                  struct device *device, unsigned int opt_flags)
{

..
        if (opt_flags & FW_OPT_NOWAIT) {
                timeout = usermodehelper_read_lock_wait(timeout);
                if (!timeout) {
                        dev_dbg(device, "firmware: %s loading timed out\n",
                                name);
                        ret = -EBUSY;
                        goto out;
                }
        } else {
                ret = usermodehelper_read_trylock();
                if (WARN_ON(ret)) {
                        dev_err(device, "firmware: %s will not be loaded\n",
                                name);
                        goto out;
                }
        }

        ret = fw_get_filesystem_firmware(device, fw->priv);

 

That's the WARN_ON() we are hitting, as can be seen by the error message
following the warning.  So we fail to get the usermodehelper read lock
(why do we need that?) and bail out before even attempting the direct
loading.

I will not claim I understand any of this.  But the warning is
definitely triggered on some resumes, with firmware in the usual place
and without the firmware agent being enabled.


Bjørn