Control: clone -1 -2 Control: reassign -2 network-manager Control: retitle -2 network-manager does not rate-limit attempts to bring interface up Control: tag -2 - patch On Mon, 2015-01-05 at 21:15 +0100, Alexander Greiner-Bär wrote: > Package: src:linux > Version: 3.16.7-ckt2-1 > Severity: important > Tags: patch > > Dear Maintainer, > > In linux 3.15 the return value of the firmware_class user helper has > changed to -ENOMEM when firmware loading fails (see commit > 2b1278cb651786648ba6dad285a6c0873c6788e1 "firmware: give a protection > when map page failed"). network-manager relies on -ENOENT to detect a > missing firmware, so network-manager tries to restart the interface in > a loop triggering new firmware requests: Well that's a stupid thing for network-manager to do! [...] > The missing firmware generates 10 MB logs per second on my system. That is absolutely *not* the kernel's fault. > I know that the firmware user helper is deprecated so its not worth > paying too much attention to it. But currently it renders a fresh Jessie > install quickly unusable when the firmware packages are not installed. > Kernel linux-image-3.18.0-trunk-amd64 from experimental works correctly > because it has the renamed CONFIG_FW_LOADER_USER_HELPER_FALLBACK disabled. That was supposed to be disabled in 3.12.6-1. However, we enable CONFIG_DELL_RBU which selects it. I think what I'll do is to disable that. > Kernel 3.14 also works as expected. > > Here is a quick fix based on commit 0542ad88fbdd81bbd53f48bff981a9867e0f0659 > "firmware loader: Fix _request_firmware_load() return val for fw load abort" > from 3.17 (which introduced -EAGAIN as return value, so not a solution here): > > --- a/drivers/base/firmware_class.c > +++ b/drivers/base/firmware_class.c > @@ -906,7 +906,9 @@ static int _request_firmware_load(struct firmware_priv *fw_priv, > wait_for_completion(&buf->completion); > > cancel_delayed_work_sync(&fw_priv->timeout_work); > - if (!buf->data) > + if (is_fw_load_aborted(buf)) > + retval = -ENOENT; > + else if (!buf->data) > retval = -ENOMEM; > > device_remove_file(f_dev, &dev_attr_loading); Why does the upstream change not do that? I don't want to apply a fix that isn't upstream. Ben. -- Ben Hutchings This sentence contradicts itself - no actually it doesn't.
Attachment:
signature.asc
Description: This is a digitally signed message part