|
 |
d07b889 |
From: Laura Abbott <labbott@fedoraproject.org>
|
|
|
d07b889 |
Date: Tue, 28 Apr 2015 15:37:44 -0700
|
|
|
d07b889 |
Subject: [PATCH] firmware: Drop WARN from usermodehelper_read_trylock error
|
|
|
d07b889 |
case
|
|
|
d07b889 |
|
|
|
d07b889 |
We've received a number of reports of warnings when coming
|
|
|
d07b889 |
out of suspend with certain bluetooth firmware configurations:
|
|
|
d07b889 |
|
|
|
d07b889 |
WARNING: CPU: 3 PID: 3280 at drivers/base/firmware_class.c:1126
|
|
|
d07b889 |
_request_firmware+0x558/0x810()
|
|
|
d07b889 |
Modules linked in: ccm ip6t_rpfilter ip6t_REJECT nf_reject_ipv6
|
|
|
d07b889 |
xt_conntrack ebtable_nat ebtable_broute bridge stp llc ebtable_filter
|
|
|
d07b889 |
ebtables ip6table_nat nf_conntrack_ipv6 nf_defrag_ipv6 nf_nat_ipv6
|
|
|
d07b889 |
ip6table_mangle ip6table_security ip6table_raw ip6table_filter
|
|
|
d07b889 |
ip6_tables iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4
|
|
|
d07b889 |
nf_nat nf_conntrack iptable_mangle iptable_security iptable_raw
|
|
|
d07b889 |
binfmt_misc bnep intel_rapl iosf_mbi arc4 x86_pkg_temp_thermal
|
|
|
d07b889 |
snd_hda_codec_hdmi coretemp kvm_intel joydev snd_hda_codec_realtek
|
|
|
d07b889 |
iwldvm snd_hda_codec_generic kvm iTCO_wdt mac80211 iTCO_vendor_support
|
|
|
d07b889 |
snd_hda_intel snd_hda_controller snd_hda_codec crct10dif_pclmul
|
|
|
d07b889 |
snd_hwdep crc32_pclmul snd_seq crc32c_intel ghash_clmulni_intel uvcvideo
|
|
|
d07b889 |
snd_seq_device iwlwifi btusb videobuf2_vmalloc snd_pcm videobuf2_core
|
|
|
d07b889 |
serio_raw bluetooth cfg80211 videobuf2_memops sdhci_pci v4l2_common
|
|
|
d07b889 |
videodev thinkpad_acpi sdhci i2c_i801 lpc_ich mfd_core wacom mmc_core
|
|
|
d07b889 |
media snd_timer tpm_tis hid_logitech_hidpp wmi tpm rfkill snd mei_me mei
|
|
|
d07b889 |
shpchp soundcore nfsd auth_rpcgss nfs_acl lockd grace sunrpc i915
|
|
|
d07b889 |
i2c_algo_bit drm_kms_helper e1000e drm hid_logitech_dj ptp pps_core
|
|
|
d07b889 |
video
|
|
|
d07b889 |
CPU: 3 PID: 3280 Comm: kworker/u17:0 Not tainted 3.19.3-200.fc21.x86_64
|
|
|
d07b889 |
Hardware name: LENOVO 343522U/343522U, BIOS GCET96WW (2.56 ) 10/22/2013
|
|
|
d07b889 |
Workqueue: hci0 hci_power_on [bluetooth]
|
|
|
d07b889 |
0000000000000000 0000000089944328 ffff88040acffb78 ffffffff8176e215
|
|
|
d07b889 |
0000000000000000 0000000000000000 ffff88040acffbb8 ffffffff8109bc1a
|
|
|
d07b889 |
0000000000000000 ffff88040acffcd0 00000000fffffff5 ffff8804076bac40
|
|
|
d07b889 |
Call Trace:
|
|
|
d07b889 |
[<ffffffff8176e215>] dump_stack+0x45/0x57
|
|
|
d07b889 |
[<ffffffff8109bc1a>] warn_slowpath_common+0x8a/0xc0
|
|
|
d07b889 |
[<ffffffff8109bd4a>] warn_slowpath_null+0x1a/0x20
|
|
|
d07b889 |
[<ffffffff814dbe78>] _request_firmware+0x558/0x810
|
|
|
d07b889 |
[<ffffffff814dc165>] request_firmware+0x35/0x50
|
|
|
d07b889 |
[<ffffffffa03a7886>] btusb_setup_bcm_patchram+0x86/0x590 [btusb]
|
|
|
d07b889 |
[<ffffffff814d40e6>] ? rpm_idle+0xd6/0x230
|
|
|
d07b889 |
[<ffffffffa04d4801>] hci_dev_do_open+0xe1/0xa90 [bluetooth]
|
|
|
d07b889 |
[<ffffffff810c51dd>] ? ttwu_do_activate.constprop.90+0x5d/0x70
|
|
|
d07b889 |
[<ffffffffa04d5980>] hci_power_on+0x40/0x200 [bluetooth]
|
|
|
d07b889 |
[<ffffffff810b487c>] process_one_work+0x14c/0x3f0
|
|
|
d07b889 |
[<ffffffff810b52f3>] worker_thread+0x53/0x470
|
|
|
d07b889 |
[<ffffffff810b52a0>] ? rescuer_thread+0x300/0x300
|
|
|
d07b889 |
[<ffffffff810ba548>] kthread+0xd8/0xf0
|
|
|
d07b889 |
[<ffffffff810ba470>] ? kthread_create_on_node+0x1b0/0x1b0
|
|
|
d07b889 |
[<ffffffff81774958>] ret_from_fork+0x58/0x90
|
|
|
d07b889 |
[<ffffffff810ba470>] ? kthread_create_on_node+0x1b0/0x1b0
|
|
|
d07b889 |
|
|
|
d07b889 |
This occurs after every resume.
|
|
|
d07b889 |
|
|
|
d07b889 |
When resuming, the bluetooth driver needs to re-request the
|
|
|
d07b889 |
firmware. This re-request is happening before usermodehelper
|
|
|
d07b889 |
is fully enabled. If the firmware load succeeded previously, the
|
|
|
d07b889 |
caching behavior of the firmware code typically negates the
|
|
|
d07b889 |
need to call the usermodehelper code again and the request
|
|
|
d07b889 |
succeeds. If the firmware was never loaded because it isn't
|
|
|
d07b889 |
actually present in the file system, this results in a call
|
|
|
d07b889 |
to usermodehelper and a failure warning every resume.
|
|
|
d07b889 |
|
|
|
d07b889 |
The proper fix is to add a reset_resume functionality to the
|
|
|
d07b889 |
btusb driver to be able to handle the resume case. The
|
|
|
d07b889 |
work for this is ongoing so in the mean time just silence
|
|
|
d07b889 |
the warning since we know it's a problem.
|
|
|
d07b889 |
|
|
|
d07b889 |
Bugzilla: 1133378
|
|
|
d07b889 |
Upstream-status: Working on it. It's a difficult problem :(
|
|
|
d07b889 |
Signed-off-by: Laura Abbott <labbott@fedoraproject.org>
|
|
|
d07b889 |
---
|
|
|
d07b889 |
drivers/base/firmware_class.c | 2 +-
|
|
|
d07b889 |
1 file changed, 1 insertion(+), 1 deletion(-)
|
|
|
d07b889 |
|
|
|
d07b889 |
diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c
|
|
 |
f70c487 |
index 894bda114224..f7a8d27b6459 100644
|
|
|
d07b889 |
--- a/drivers/base/firmware_class.c
|
|
|
d07b889 |
+++ b/drivers/base/firmware_class.c
|
|
|
f70c487 |
@@ -1144,7 +1144,7 @@ _request_firmware(const struct firmware **firmware_p, const char *name,
|
|
|
d07b889 |
}
|
|
|
d07b889 |
} else {
|
|
|
d07b889 |
ret = usermodehelper_read_trylock();
|
|
|
d07b889 |
- if (WARN_ON(ret)) {
|
|
|
d07b889 |
+ if (ret) {
|
|
|
d07b889 |
dev_err(device, "firmware: %s will not be loaded\n",
|
|
|
d07b889 |
name);
|
|
|
d07b889 |
goto out;
|