kernel fails to load iwlwifi firmware - disable CONFIG_FW_LOADER_USER_HELPER

Bug #1398458 reported by Sebastien Bacher
10
This bug affects 1 person
Affects Status Importance Assigned to Milestone
openSUSE
Fix Released
High
linux (Ubuntu)
Low
Seth Forshee
systemd (Ubuntu)
High
Martin Pitt

Bug Description

Using current vivid, when using udev 217 wlan0 is missing, it's there and working fine when downgrading to 215

Right after boot, kernel shows

[ 6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2
[ 6.586598] iwlwifi 0000:02:00.0: Falling back to user helper

After manually enabling the card, kernel shows

Dec 2 11:37:08 localhost kernel: [ 127.133185] iwlwifi 0000:02:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm

ProblemType: Bug
DistroRelease: Ubuntu 15.04
Package: udev 217-2ubuntu1
ProcVersionSignature: Ubuntu 3.16.0-26.34-generic 3.16.7-ckt1
Uname: Linux 3.16.0-26-generic i686
ApportVersion: 2.14.7-0ubuntu10
Architecture: i386
CurrentDesktop: Unity
CustomUdevRuleFiles: 80-net-name-slot.rules 81-canonij_prn.rules
Date: Tue Dec 2 17:39:08 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2010-10-09 (1515 days ago)
InstallationMedia: Ubuntu 10.10 "Maverick Meerkat" - Release i386 (20101007)
MachineType: Dell Inc. Latitude E6410
PccardctlIdent:
 Socket 0:
   no product info available
PccardctlStatus:
 Socket 0:
   no card
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.16.0-26-generic root=UUID=555ebc11-d747-44d3-af56-5e7d17851ce3 ro quiet splash init=/bin/systemd vt.handoff=7
SourcePackage: systemd
SystemImageInfo:
 current build number: 0
 device name:
 channel: daily
 last update: Unknown
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 04/21/2013
dmi.bios.vendor: Dell Inc.
dmi.bios.version: A14
dmi.board.name: 0HNGW4
dmi.board.vendor: Dell Inc.
dmi.chassis.type: 9
dmi.chassis.vendor: Dell Inc.
dmi.modalias: dmi:bvnDellInc.:bvrA14:bd04/21/2013:svnDellInc.:pnLatitudeE6410:pvr0001:rvnDellInc.:rn0HNGW4:rvr:cvnDellInc.:ct9:cvr:
dmi.product.name: Latitude E6410
dmi.product.version: 0001
dmi.sys.vendor: Dell Inc.

CVE References

Revision history for this message
In , Mich (michalng) wrote :

User-Agent: Mozilla/5.0 (X11; Linux i686; rv:31.0) Gecko/20100101 Firefox/31.0

Installed openSUSE Factory using the openSUSE-Factory-NET-i586-Current.iso.
During installation, wireless is detected but unable to connect so the installation was performed with Ethernet (RJ45) cable instead of wireless.

After installation,
noticed that when using Ethernet (RJ45) cable, do not need to wait much for the internet connection to be established during boot up.
However, if I were to remove the Ethernet cable and try to connect using wireless during boot up, will need to wait approximately 2 minutes before openSUSE activates the wireless connection.

Did try switching to Wicked and Disbling Network Service.
It allows the configuring of the Wireless and Ethernet connection but the 2 minutes wait is still there, even after configuring wireless and reboot.

Installed Fluxbox and nm-applet and booted into them.
Confirmed that the 2 minutes wait is still there.

Reproducible: Always

Steps to Reproduce:
1. Boot into openSUSE Factory
2. Wait for wireless connection.
3.
Actual Results:
Need to wait approximately 2 minutes before wireless connects

Expected Results:
Wireless connection within a very short period

Revision history for this message
In , Bwiedemann (bwiedemann) wrote :

As it happens both with wicked and NetworkManager,
it seems to not be related to any of them.

My best guess on how to get closer to the problem
would be to get timings out of systemd via
http://freedesktop.org/wiki/Software/systemd/Debugging/

Do you have NFS/Samba shares that could block things?

Revision history for this message
In , Mich (michalng) wrote :

Correction, the problem happens with NetworkManager.
I switched to Wicked (to disable NetworkManager) for a short moment so that I can configure the wireless interface (which will be locked if managed by NetworkManager).

If you still want me to play with http://freedesktop.org/wiki/Software/systemd/Debugging/ , will need you help to be more specific. Just a normal user here :D

No, I do not have NFS/Samba shares. Just a Ext4 partition with / and /home altogether. Do have an encrypted Ext4 mounted at boot at /mnt/extra.

Revision history for this message
In , Bwiedemann (bwiedemann) wrote :

OK. In that case, it goes to the Gnome people who care for NetworkManager

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

(In reply to comment #3)
> OK. In that case, it goes to the Gnome people who care for NetworkManager

I have my fair share of doubt on that one... I actually see it on my machine too (yes, with NM.. but)

- my driver used is iwlwifi
During boot, the driver fails to load the firmware (error -2), retries after 60s, fails, retries after 60s success, trying to pass on to 'user space'

It does not matter if I start a session or not in the meantime.

The issue with 'user space': this is meant to be udev - but udev no longer does that.

http://lists.freedesktop.org/archives/systemd-devel/2013-August/012536.html

I'm CCing udev/systemtd maintainers for their valuable input on the topic as well.

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :
Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

from systemd.spec:

%if 0%{?suse_version} <= 1310
  --with-firmware-path="%{_prefix}/lib/firmware:/lib/firmware" \
%endif

Introduced with https://build.opensuse.org/request/show/238853

Revision history for this message
In , 1-w1rner-0 (1-w1rner-0) wrote :

Are you aware that this is a WONTFIX!

From systemd-210/README:

        Userspace firmware loading is deprecated, will go away, and
        sometimes causes problems:
          CONFIG_FW_LOADER_USER_HELPER=n

and as long as this is deprecated the firmware part will not go into.

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

(In reply to comment #7)
> Are you aware that this is a WONTFIX!
>
> From systemd-210/README:
>
> Userspace firmware loading is deprecated, will go away, and
> sometimes causes problems:
> CONFIG_FW_LOADER_USER_HELPER=n
>
> and as long as this is deprecated the firmware part will not go into.

Hold it right there - before there are misunderstandings:

I never said it was a bug that needed fixing in systemd. I merely pointed out that which change caused it to happen to surface.

The bug though is that the systemd maintainer introduced this without talking to the kernel maintainer...

As a current openSUSE Kernel still has:
> zgrep FW_LOADER /proc/config.gz
CONFIG_FW_LOADER=y
CONFIG_FW_LOADER_USER_HELPER=y

Pleae, look beyond your garden - if you are already aware that a change in your package requires a fix in something else - why not coordinate those two changes?

As such: should you really decide to 'wontfix' that, there is likely not much I can do, but it will not make the issue go away.

Revision history for this message
In , 1-w1rner-0 (1-w1rner-0) wrote :

Bernhard? Please choose the correct maintainer which could be NetworkManager and/or wicked

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

(In reply to comment #9)
> Bernhard? Please choose the correct maintainer which could be NetworkManager
> and/or wicked

???

you claim
> Userspace firmware loading is deprecated, will go away, and
> sometimes causes problems:
> CONFIG_FW_LOADER_USER_HELPER=n

Our kernel has this different (=y).

Yet, it shall be a wicked/NM bug?

/me is confused

Revision history for this message
In , 1-w1rner-0 (1-w1rner-0) wrote :

Suppose there will be an update of systemd and there is no firmware anymore ... now what will happen then? Upstream of systemd has decided not to go this way.

config FW_LOADER_USER_HELPER
        bool "Fallback user-helper invocation for firmware loading"
        depends on FW_LOADER
        default y
        help
          This option enables / disables the invocation of user-helper
          (e.g. udev) for loading firmware files as a fallback after the
          direct file loading in kernel fails. The user-mode helper is
          no longer required unless you have a special firmware file that
          resides in a non-standard path.

Maybe Robert has aa idea why this is depricated. AFAIK such helpers are not required anymore

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

Hmm, that is interesting. The config option is there for backward compatibility. To make the kernel work with older userspace (those predating 13.1 in this case).

The bug seems to be that the kernel fails to load the firmware and falls back to udev loading.

Can you provide the dmesg output from a machine booted with the delay?

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Jiri,

on my system i see:

dle1gis@linux:~> dmesg | grep iwl
[ 7.050451] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 7.050520] iwlwifi 0000:03:00.0: irq 47 for MSI/MSI-X
[ 7.055182] iwlwifi 0000:03:00.0: Direct firmware load failed with error -2
[ 7.055187] iwlwifi 0000:03:00.0: Falling back to user helper
[ 67.119868] iwlwifi 0000:03:00.0: Direct firmware load failed with error -2
[ 67.119876] iwlwifi 0000:03:00.0: Falling back to user helper
[ 127.257650] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm
[ 127.278256] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 127.278261] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[ 127.278265] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 127.278269] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Advanced-N 6200 AGN, REV=0x74
[ 127.278343] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 127.298454] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 127.305733] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 127.312159] iwlwifi 0000:03:00.0: Radio type=0x1-0x3-0x1
[ 127.523766] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 127.530183] iwlwifi 0000:03:00.0: Radio type=0x1-0x3-0x1

(not changing NEEDINFO - but I guess Michal has something alike)

Revision history for this message
In , Mich (michalng) wrote :

output from my system

dmesg | grep iwl
[ 15.686273] iwlwifi 0000:03:00.0: can't disable ASPM; OS doesn't have ASPM control
[ 15.686335] iwlwifi 0000:03:00.0: irq 45 for MSI/MSI-X
[ 15.727254] iwlwifi 0000:03:00.0: Direct firmware load failed with error -2
[ 15.727262] iwlwifi 0000:03:00.0: Falling back to user helper
[ 75.896537] iwlwifi 0000:03:00.0: Direct firmware load failed with error -2
[ 75.896545] iwlwifi 0000:03:00.0: Falling back to user helper
[ 136.094305] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build 25532 op_mode iwldvm
[ 136.158913] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUG enabled
[ 136.158920] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEBUGFS enabled
[ 136.158924] iwlwifi 0000:03:00.0: CONFIG_IWLWIFI_DEVICE_TRACING disabled
[ 136.158929] iwlwifi 0000:03:00.0: Detected Intel(R) Centrino(R) Ultimate-N 6300 AGN, REV=0x74
[ 136.158987] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 136.180935] ieee80211 phy0: Selected rate control algorithm 'iwl-agn-rs'
[ 136.204473] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 136.204685] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1
[ 136.419495] iwlwifi 0000:03:00.0: L1 Enabled; Disabling L0S
[ 136.419728] iwlwifi 0000:03:00.0: Radio type=0x0-0x3-0x1

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

Cool guys, so do you have the firmware in-place? Show me your:
* rpm -ql kernel-firmware
* lspci -nn

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Considering it magically finds firmware after two minutes, I would cast a guess and say yes:

[ 127.257650] iwlwifi 0000:03:00.0: loaded firmware version 9.221.4.1 build
25532 op_mode iwldvm

(but I will confirm in the evening on my machine - Michal might be faster to that)

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

Yes, and could you also attach lsinitrd /boot/initrd?

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Created attachment 603345
rpm -ql kernel-firmware

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Created attachment 603346
lspci -nn

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Created attachment 603347
lsinitrd /boot/initrd

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

Created attachment 603348
Full dmesg log

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :
Download full text (3.9 KiB)

NOTE: unloading and reloading iwlwifi brings back the 2 minute window - so it is definitively NOT related to a race on bootup: even if the system was up for 30 minutes already, simply do:

rmmod iwlwifi
modprobe iwlwifi
=> it will take again 2 minutes to load the firmware

some udevadm monitoring:

after 'modprobe iwlwifi'

KERNEL[3055.484684] add /module/iwlwifi (module)
UDEV [3055.485613] add /module/iwlwifi (module)
KERNEL[3055.485656] add /bus/pci/drivers/iwlwifi (drivers)
KERNEL[3055.485810] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-6.ucode (firmware)
UDEV [3055.486038] add /bus/pci/drivers/iwlwifi (drivers)
UDEV [3055.486638] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-6.ucode (firmware)
KERNEL[3055.487174] add /module/iwldvm (module)
UDEV [3055.487377] add /module/iwldvm (module)

one minute later (note: remove *-6.ucode, add *-5.ucode)

1KERNEL[3115.612278] remove /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-6.ucode (firmware)
KERNEL[3115.612320] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-5.ucode (firmware)
UDEV [3115.613263] remove /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-6.ucode (firmware)
UDEV [3115.613708] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-5.ucode (firmware)

one minute later (note: remove *-5.ucode; I assume it would add *-4*.ucode, BUT this is loaded in kernel, as this is the file that exists!)

KERNEL[3175.644300] remove /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-5.ucode (firmware)
UDEV [3175.645274] remove /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/firmware/iwlwifi-6000-5.ucode (firmware)
KERNEL[3175.660107] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/phy3-led (leds)
KERNEL[3175.660145] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy3 (ieee80211)
KERNEL[3175.660220] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy3/rfkill6 (rfkill)
KERNEL[3175.660480] change /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/phy3-led (leds)
KERNEL[3175.660507] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0 (net)
UDEV [3175.660525] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/phy3-led (leds)
KERNEL[3175.660541] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/queues/rx-0 (queues)
KERNEL[3175.660557] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/queues/tx-0 (queues)
KERNEL[3175.660572] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/queues/tx-1 (queues)
KERNEL[3175.660587] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/queues/tx-2 (queues)
KERNEL[3175.660602] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/net/wlan0/queues/tx-3 (queues)
UDEV [3175.661026] change /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/leds/phy3-led (leds)
UDEV [3175.661060] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/phy3 (ieee80211)
UDEV [3175.661768] add /devices/pci0000:00/0000:00:1c.1/0000:03:00.0/ieee80211/p...

Read more...

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

(In reply to comment #25)
> So the main issue is indeed that we pass off to udev for loading - and there is
> a 60s timeout (per try)

Yes, indeed. That's the root cause. Your symptoms result from the fact, that the driver tries two firmwares, which were never released by intel.

I will disable to helper as we used to have the firmwares in the preset locations, so it should not cause problems to anybody even if the kernel is installed on older distros.

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

Pushed:
   8f730c579d8f..2873b40b1bc3 master -> master

Revision history for this message
In , Bwiedemann (bwiedemann) wrote :

*** Bug 898858 has been marked as a duplicate of this bug. ***

Revision history for this message
In , Dominique Leuenberger aka DimStar (dimstar) wrote :

(In reply to Jiri Slaby from comment #27)
> Pushed:
> 8f730c579d8f..2873b40b1bc3 master -> master

Can you make an assessment in which kernel in Factory this fix will appear? I now have kernel 3.16.2 (latest changelog entry Sep 7 2014), but this fix is not yet included (so also the kernel in upcoming openSUSE 13.2 seems to be missing this fix)

Revision history for this message
In , Jslaby-h (jslaby-h) wrote :

We cannot disable userspace fw loader in the stable branch which is pulled into factory. Dell RBU driver depends on that. So the fix gets to factory as soon as 3.17 is released and merged to the stable branch.

Revision history for this message
Sebastien Bacher (seb128) wrote :
Revision history for this message
Martin Pitt (pitti) wrote : Re: [udev] wlan interface missing on boot with v217

First stab: It seems with 217, the card is waiting for getting its firmware loaded:

+E: FIRMWARE=iwlwifi-6000-5.ucode
+E: SUBSYSTEM=firmware
+E: TIMEOUT=60

and dmesg shows:

[ 6.586593] iwlwifi 0000:02:00.0: Direct firmware load failed with error -2
[ 6.586598] iwlwifi 0000:02:00.0: Falling back to user helper

which seems to correlate with this in the 217 changelog:

        * Userspace firmware loading support has been removed and
          the minimum supported kernel version is thus bumped to 3.7.

so it seems we found a case where the in-kernel firmware loading does not work.

I have iwlwifi as well:

03:00.0 Network controller: Intel Corporation Centrino Advanced-N 6205 [Taylor Peak] (rev 34)

and my dmesg says

[ 2.898239] iwlwifi 0000:03:00.0: loaded firmware version 18.168.6.1 op_mode iwldvm

summary: - wlan interface missing on boot with v217
+ [udev] wlan interface missing on boot with v217
summary: - [udev] wlan interface missing on boot with v217
+ kernel fails to load iwlwifi firmware
Martin Pitt (pitti)
affects: systemd (openSUSE) → opensuse
Revision history for this message
Martin Pitt (pitti) wrote : Re: kernel fails to load iwlwifi firmware

We ship /lib/firmware/iwlwifi-6000-4.ucode in linux-firmware, which is also what the module advertises:

$ modinfo iwlwifi|grep 6000
firmware: iwlwifi-6000g2b-6.ucode
firmware: iwlwifi-6000g2a-5.ucode
firmware: iwlwifi-6000-4.ucode

This is what udev's userspace helper is looking at, so that finds the file just fine.

The interesting question here is why the kernel wants to load requests iwlwifi-6000-5.ucode. I. e. where does the -5 come from? It seems the in-kernel loader and the "firmware:" module field are doing something different?

Revision history for this message
Martin Pitt (pitti) wrote :

Adding a linux task. It seems quite clear that in the short term we need to re-enable the udev userspace helper, but this eventually needs to be fixed in the kernel properly.

description: updated
description: updated
Revision history for this message
Martin Pitt (pitti) wrote :

So here's what happens:
- The intel driver has a list of valid versions, -6, -5, -4, -3; the kernel tries all of them in descending order
- It starts with loading -6, which is ENOENT
- As we enable CONFIG_FW_LOADER_USER_HELPER, it now tries to call that (with a timeout of 60 seconds); the timeout hits as we don't ship the user helper any more
- Kernel falls back to trying -5, same timeout
- Kernel falls back to trying -4 which succeeds

That's why it takes 2 minutes.

Short-term solution: Provide a userspace loader stub which immediately fails
Long-term solution: Disable CONFIG_FW_LOADER_USER_HELPER to avoid running into the timeout

summary: - kernel fails to load iwlwifi firmware
+ kernel fails to load iwlwifi firmware - disable
+ CONFIG_FW_LOADER_USER_HELPER
Changed in systemd (Ubuntu):
assignee: nobody → Martin Pitt (pitti)
importance: Undecided → Medium
status: New → In Progress
Revision history for this message
Brad Figg (brad-figg) wrote : Status changed to Confirmed

This change was made by a bot.

Changed in linux (Ubuntu):
status: New → Confirmed
Revision history for this message
Martin Pitt (pitti) wrote :

Please create /etc/udev/rules.d/50-firmware.rules with

  SUBSYSTEM=="firmware", ACTION=="add", RUN="/bin/false"

and see whether that improves things? To be honest I don't know exactly what the kernel expects from the userspace helper, but it's worth a try.

Revision history for this message
Martin Pitt (pitti) wrote :

Sebastien tested this, and it works:

  SUBSYSTEM=="firmware", ACTION=="add", ATTR{loading}="-1"

Changed in opensuse:
importance: Unknown → High
status: Unknown → Fix Released
Revision history for this message
Sebastien Bacher (seb128) wrote :

confirmed, the rules from comment #7 didn't work but the one copied in comment #8 does

Martin Pitt (pitti)
Changed in systemd (Ubuntu):
importance: Medium → High
Changed in linux (Ubuntu):
status: Confirmed → Triaged
importance: Undecided → Low
Revision history for this message
Martin Pitt (pitti) wrote :
Changed in systemd (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :
Download full text (4.1 KiB)

This bug was fixed in the package systemd - 217-3ubuntu1

---------------
systemd (217-3ubuntu1) vivid; urgency=medium

  * Merge with Debian unstable. Remaining Ubuntu changes:
    - Create disk/by-partlabel links for mmcblk partitions.
    - Hack to support system-image read-only /etc, and modify files in
      /etc/writable/ instead.
    - debian/rules: Drop doc dir symlinking. It creates havoc with dpkg
      upgrades, and we already have the automatic per-file symlinking.
    - debian/rules: Add an epoch to libgudev.
    - Don't install 80-networking.rules and the Debian *.agent scripts, we
      never supported them in Ubuntu. Instead, extend systemd's "net" device
      udev rule to trigger ifup@.service on network devices.
    - Keep our much simpler udev maintainer scripts (all platforms must
      support udev, no debconf).
    - Add udev Apport package hook.
    - debian/extra/initramfs.top: Drop $ROOTDELAY, we do that in a more
      sensible way with wait-for-root. Will get applicable to Debian once
      Debian gets wait-for-root in initramfs-tools.
    - debian/extra/initramfs.bottom: If LVM is installed, settle udev,
      otherwise we get missing LV symlinks. Workaround for LP #1185394.
    - Add 40-hyperv-hotadd.rules: Workaround for LP #1233466.
    - Mark graphics devices as PRIMARY_DEVICE_FOR_DISPLAY so that we can wait
      for those in plymouth.
    - Add debian/udev.lvm2.init: Dummy SysV init script to satisfy insserv
      dependencies to "lvm2" which is handled with udev rules in Ubuntu.
    - Lower Breaks: to lvm2 again. Our lvm2 package has always used udev for
      device setup, and thus is be compatible with systemd, too.
    - Lower Breaks: to plymouth version which has the udev inotify fix in
      Ubuntu.
    - Add HP ProLiant Server Cartridge power control support.
    - Provide shutdown fallback for upstart. (LP: #1370329)
    - debian/ifup@.service: Additionally run for "auto" class. We don't really
      support "allow-hotplug" in Ubuntu at the moment, so we need to deal with
      "auto" devices appearing after "/etc/init.d/networking start" already
      ran. (LP: #1374521)
    - Add Get-RTC-is-in-local-time-setting-from-etc-default-rc.patch: In
      Ubuntu we currently keep the setting whether the RTC is in local or UTC
      time in /etc/default/rcS "UTC=yes|no", instead of /etc/adjtime.
      (LP: #1377258)
    - Add systemd Apport hook for adding systemd-delta and information about
      failed units.
    - Put session scopes into all cgroup controllers. This makes unprivileged
      user LXC containers work under systemd. (LP: #1346734)
    - Do not realize and migrate cgroups multiple times, in particular
      "-.slice". This fixes PIDs in non-systemd cgroup controllers to be
      randomly migrated back to /.
    - Build-depend on libapparmor-dev to enable AppArmor support
      (LP: #1396270)

    Upgrade fixes, keep until 16.04 LTS release:
    - systemd Conflicts/Replaces/Provides systemd-services.
    - Remove obsolete systemd-logind upstart job.
    - Clean up obsolete /etc/udev/rules.d/README on upgrades. (LP: #1381655)

systemd (217-4) UNRELEASED; urgency=medium

  * Reinstate a debian...

Read more...

Changed in systemd (Ubuntu):
status: Fix Committed → Fix Released
Revision history for this message
Seth Forshee (sforshee) wrote :

I don't think it makes sense to change this in the 3.16 kernel, which is currently what's being used in vivid. On the surface it makes sense to disable CONFIG_FW_LOADER_USER_HELPER in the 3.18 branch, except that ultimately the vivid kernel will also be released for trusty. In theory things should still just work, but potentially there are some corner cases which still rely on the fallback.

In the end I guess we probably ought to change it though.

Changed in linux (Ubuntu):
assignee: nobody → Seth Forshee (sforshee)
status: Triaged → In Progress
Revision history for this message
Seth Forshee (sforshee) wrote :

It looks like I don't have any of the affected hardware. I put up a test build at the link below; Sebastien, could you give it a try (with the workaround removed obviously) and confirm that it fixes the problem?

http://people.canonical.com/~sforshee/lp1398458/linux-3.18.0-5.6+lp1398458v201412031026/

Changed in linux (Ubuntu):
status: In Progress → Incomplete
Seth Forshee (sforshee)
Changed in linux (Ubuntu):
status: Incomplete → In Progress
Revision history for this message
Seth Forshee (sforshee) wrote :

I used https://github.com/mcgrof/fake-firmware-test to confirm that disabling CONFIG_FW_LOADER_USER_HELPER eliminates use of the user helper and the associated delay when the firmware is missing. Patch has been sent to the kernel team mailing list.

Andy Whitcroft (apw)
Changed in linux (Ubuntu):
status: In Progress → Fix Committed
Revision history for this message
Launchpad Janitor (janitor) wrote :

This bug was fixed in the package linux - 3.18.0-8.9

---------------
linux (3.18.0-8.9) vivid; urgency=low

  [ Leann Ogasawara ]

  * Release Tracking Bug
    - LP: #1407692
  * rebase to v3.18.1
  * ubuntu: AUFS -- Resolve build failure union has no member named
    'd_child'

  [ Upstream Kernel Changes ]

  * arm64: optimized copy_to_user and copy_from_user assembly code
    - LP: #1400349
  * x86, kvm: Clear paravirt_enabled on KVM guests for espfix32's benefit
    - LP: #1400314
    - CVE-2014-8134
  * rebase to v3.18.1
 -- Leann Ogasawara <email address hidden> Mon, 05 Jan 2015 09:12:32 -0800

Changed in linux (Ubuntu):
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.