# Firmware in Kernel Problem

## NeddySeagoon

Team,

I have a fanless diskless ASUS E35M1-I Motherboard for a media player.

The diskless bit is important here as the system must load its kernel over the network then mount root over the network.

Now, the r8169 module wants to load firmware for its

```
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
```

and dmesg tells me its looking for 

```
rtl_nic/rtl8168e-2.fw
```

It stalls the bootup for 60 seconds trying to load the firmware, then the boot proceeds normally.

Keep in mind that the network card is not started at this time, so root is not mounted, so /lib/firmware/rtl_nic/rtl8168e-2.fw can't be read.

By the time root is mounted, its too late, as the driver is no longer interested in its firmware.

Building the firmware into the kernel seems to be the way forward but r8169 always looks in rtl_nic/rtl8168e-2.fw which I can't get to exist inside the kernel.

The dirty hack I've employed for kernel 3.0.7 is to edit drivers/net/r8169.c to change the firmware defines from 

```
#define FIRMWARE_8168D_1        "rtl_nic/rtl8168d-1.fw"

#define FIRMWARE_8168D_2        "rtl_nic/rtl8168d-2.fw"

#define FIRMWARE_8168E_1        "rtl_nic/rtl8168e-1.fw"

#define FIRMWARE_8168E_2        "rtl_nic/rtl8168e-2.fw"

#define FIRMWARE_8105E_1        "rtl_nic/rtl8105e-1.fw"
```

to

```
#define FIRMWARE_8168D_1        "rtl8168d-1.fw"

#define FIRMWARE_8168D_2        "rtl8168d-2.fw"

#define FIRMWARE_8168E_1        "rtl8168e-1.fw"

#define FIRMWARE_8168E_2        "rtl8168e-2.fw"

#define FIRMWARE_8105E_1        "rtl8105e-1.fw"
```

which works like a charm but its ugly as I need to patch the kernel for every new version.

I know I can make an initrd and have /lib/firmware/rtl_nic/rtl8168e-2.fw there, so normal userspace firmware loading works but that seems like overkill for one firmware blob.

How do I make this justwork with in kernel firmware?

----------

## Hu

I recently had to build radeon firmware directly into a kernel.  Like with your NIC firmware, it lives in a subdirectory below the main firmware area.  For me, I had to set KERNEL_FIRMWARE_DIR=/lib/firmware/, install the firmware on the build system (emerge sys-kernel/linux-firmware), and list radeon/FOO radeon/BAR in EXTRA_FIRMWARE.  It sounds like you tried something similar to this and did not get the results you wanted.  Could you post the output of find /lib/firmware ; grep FIRMWARE .config?

----------

## NeddySeagoon

Hu,

From my working patched kernel

```
roy@mediaplayer /usr/src/linux $ grep FIRMWARE .config

CONFIG_PREVENT_FIRMWARE_BUILD=y

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE="rtl8168e-2.fw"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/rtl_nic/"

CONFIG_FIRMWARE_EDID=y

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set
```

find /lib/firmware is huge, so its at http://paste.pocoo.org/show/496510/

Hmm...  I may not have tried

```
CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8168e-2.fw"
```

which is what I think you are suggesting.

----------

## Hu

Yes, that last block is what I intended.

----------

## NeddySeagoon

Hu,

That works!

Thank you very much.

----------

## codelad

Hello, 

I have a very similar (if not identical) issue. While my bootup does not visibly stall, dmesg still shows a message: 

```
r8169 0000:04:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)
```

My hardware is: 

```
04:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168B PCI Express Gigabit Ethernet controller (rev 06)
```

On my manually configured kernel (3.1.0), the relevant kernel parameters, read: 

```
/usr/src/linux $ grep 'FIRMWARE' .config

CONFIG_PREVENT_FIRMWARE_BUILD=y

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE="radeon/JUNIPER_me.bin radeon/JUNIPER_pfp.bin radeon/JUNIPER_rlc.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

CONFIG_FIRMWARE_EDID=y

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set
```

I was about to try the solution offered in the earlier post, but could not find the directory /lib/firmware/rtl_nic/. From looking around, I gather the rtl_nic firmware tree is part of the linux-firmware package. But I have trouble emerging it, since it appears to conflict with the radeon-ucode package. 

Any pointers much appreciated. Thank you!

----------

## chithanh

linux-firmware package contains most of the individual firmware packages already, hence the block.

----------

## codelad

 *chithanh wrote:*   

> linux-firmware package contains most of the individual firmware packages already, hence the block.

 

I'm actually trying to achieve the reverse - trying to emerge linux-firmware while radeon-ucode is already installed. Is radeon-ucode a subset of linux-firmware? If so, I could possibly unmerge radeon-ucode and replace it with linux-firmware. 

Thank you.

----------

## Gusar

 *codelad wrote:*   

> Is radeon-ucode a subset of linux-firmware?

 

Yep.

 *codelad wrote:*   

> If so, I could possibly unmerge radeon-ucode and replace it with linux-firmware.

 

Yep, that's exactly what you should do.

----------

## codelad

Gusar, thanks a ton for the help! It works now and the error message is gone. 

Strange though, that I've always used radeon-ucode and have never faced this problem before upgrading to the 3.1.0 kernel.

----------

## Gusar

A question: Did your network card not work without the firmware? I ask because I have a similar Realtek card and it works even without firmware. I get the error message, but network is working anyway.

----------

## codelad

 *Gusar wrote:*   

> A question: Did your network card not work without the firmware? I ask because I have a similar Realtek card and it works even without firmware. I get the error message, but network is working anyway.

 

My network card seemed to work fine. I found the error message annoying, though. 

FYI, I had previously faced issues with this same network hardware while on kernel 3.0.7,  and had to "downgrade" to the r8168 drivers from the manufacturer to make it work.

----------

## dewhite

Hello All,

I too am getting a message in dmesg regarding the firmware not loading for my NIC:

```
black linux # dmesg | grep firmware

[   63.737690] r8169 0000:02:00.0: eth0: unable to load firmware patch rtl_nic/rtl8168e-3.fw (-2)

```

My Kernel is configured as some have suggested above:

```
black linux # grep 'FIRMWARE' /usr/src/linux/.config

CONFIG_PREVENT_FIRMWARE_BUILD=y

CONFIG_FIRMWARE_IN_KERNEL=y

CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8168e-3.fw"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

CONFIG_FIRMWARE_EDID=y

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set

```

The firmware blob seems to exist in the correct location:

```
black linux # ls -l /lib/firmware/rtl_nic/rtl8168*

-rw-r--r-- 1 root root 1492 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168d-1.fw

-rw-r--r-- 1 root root 1324 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168d-2.fw

-rw-r--r-- 1 root root 5500 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-1.fw

-rw-r--r-- 1 root root 3920 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-2.fw

-rw-r--r-- 1 root root 3872 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-3.fw

-rw-r--r-- 1 root root 3424 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168f-1.fw

-rw-r--r-- 1 root root 1232 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168f-2.fw

-rw-r--r-- 1 root root 4272 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168g-1.fw
```

This is a bit annoying as the driver is built-in, and needed for a custom initramfs that supports an early environment dropbear ssh server, to provide access to decrypt my LUKS root remotely.  Waiting for the error message to come adds ~60 seconds to the boot-up that shouldn't need to be there...

Any thoughts, comments, questions, ideas, references, etc are always appreciated!

----------

## chithanh

.config may or may not be the config of your currently running kernel. Only for /proc/config.gz this is guaranteed (needs CONFIG_IKCONFIG_PROC enabled).

----------

## NeddySeagoon

dewhite,

What does

```
 uname -a
```

 show?

The #nnn is the number of times this kernel has been built and date/time is the build time of the running kernel.

Does that look right?

Also, compare the kernel version shown with the output of 

```
readlink /usr/src/linux
```

If they show different kernel versions there is a good change that you are not running the kernel you think you are and you are posting a .config, from a kernel you are not actually running.

----------

## dewhite

Thank You both for the quick replies!

This is a new build I installed last night, and I'm fairly certain that the config options I posted are compiled into my currently running kernel, but I certainly don't mind confirming:

```
dan@black ~ $ uname -a && readlink /usr/src/linux

Linux black 3.6.11-gentoo #8 SMP Sun Jan 20 10:13:02 CST 2013 x86_64 AMD Phenom(tm) II X6 1045T Processor AuthenticAMD GNU/Linux

linux-3.6.11-gentoo

```

Further:

```
dan@black ~ $ cat /proc/config.gz | gunzip | grep 'FIRMWARE'

CONFIG_PREVENT_FIRMWARE_BUILD=y

CONFIG_FIRMWARE_IN_KERNEL=y

CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8168e-3.fw"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

CONFIG_FIRMWARE_EDID=y

CONFIG_FIRMWARE_MEMMAP=y

# CONFIG_GOOGLE_FIRMWARE is not set

```

What else comes to mind?

----------

## Jaglover

dmesg

----------

## NeddySeagoon

dewhite,

Exactly when did the firmware get into /lib/firmware ?

Before or after Sun Jan 20 10:13:02 CST 2013 ?

To test that the firmware is found, build the NIC driver as a module.  When it loads, it will load the firmware too and tell you whats happening in dmesg.

NIC drivers need to be listed in /etc/conf.d/modules as they are not auto loaded.

If that works, revert the change and rebuild your kernel starting with make clean

----------

## Gusar

 *NeddySeagoon wrote:*   

> NIC drivers need to be listed in /etc/conf.d/modules as they are not auto loaded.

 

Err, of course they are. There are very, very few modules that aren't autoloaded. Virtualbox modules come to mind. But hardware drivers, they're all autoloaded.

----------

## dewhite

 *Jaglover wrote:*   

> dmesg

 

http://bpaste.net/show/71627/

----------

## dewhite

 *NeddySeagoon wrote:*   

> dewhite,
> 
> Exactly when did the firmware get into /lib/firmware ?
> 
> Before or after Sun Jan 20 10:13:02 CST 2013 ?
> ...

 

I emerged sys-kernel/linux-firmware and checked the contents of the rtl_nic directory just before configuring the location into the kernel and recompiling, at 9:37am:

```
dan@black ~ $ ls -l /lib/firmware/rtl_nic/rtl8*

-rw-r--r-- 1 root root 2076 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8105e-1.fw

-rw-r--r-- 1 root root 1856 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8106e-1.fw

-rw-r--r-- 1 root root 1492 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168d-1.fw

-rw-r--r-- 1 root root 1324 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168d-2.fw

-rw-r--r-- 1 root root 5500 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-1.fw

-rw-r--r-- 1 root root 3920 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-2.fw

-rw-r--r-- 1 root root 3872 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168e-3.fw

-rw-r--r-- 1 root root 3424 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168f-1.fw

-rw-r--r-- 1 root root 1232 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168f-2.fw

-rw-r--r-- 1 root root 4272 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8168g-1.fw

-rw-r--r-- 1 root root 1824 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8402-1.fw

-rw-r--r-- 1 root root 2112 Jan 20 09:37 /lib/firmware/rtl_nic/rtl8411-1.fw

```

I'm going to try loading the driver as a module and will report back in a couple of minutes.  Thanks!

----------

## dewhite

With the 8169 driver loaded as a module, dmesg declines to mention the firmware issue - I assume that means it was able to load it without issue:

```
dan@black ~ $ dmesg | grep 8169    

[   19.657751] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[   19.658007] r8169 0000:02:00.0: irq 44 for MSI/MSI-X

[   19.658198] r8169 0000:02:00.0: eth0: RTL8168evl/8111evl at 0xffffc9001338e000, 54:04:a6:d9:bd:36, XID 0c900800 IRQ 44

[   19.658200] r8169 0000:02:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[   22.433001] r8169 0000:02:00.0: eth0: link down

[   22.433021] r8169 0000:02:00.0: eth0: link down

[   25.044400] r8169 0000:02:00.0: eth0: link up

```

For the entire output, please see: http://bpaste.net/show/71631/

After recompiling the 8169 driver directly back into the kernel the errors (and delay) are gone from dmesg:

```
dan@black ~ $ dmesg | grep 8169

[    2.226640] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    2.227348] r8169 0000:02:00.0: irq 44 for MSI/MSI-X

[    2.227536] r8169 0000:02:00.0: eth0: RTL8168evl/8111evl at 0xffffc90000c7e000, 54:04:a6:d9:bd:36, XID 0c900800 IRQ 44

[    2.228062] r8169 0000:02:00.0: eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    3.311284] r8169 0000:02:00.0: eth0: link down

[    3.311297] r8169 0000:02:00.0: eth0: link down

[    5.866720] r8169 0000:02:00.0: eth0: link up

```

Full version: http://bpaste.net/show/71633/

I suppose it was the 'make clean' that was probably necessary to flush some loose?  In any case - I VERY MUCH appreciate all of your taking the time to lead this horse to some water!

The bright side, is that with an X6 cpu, make clean && make -j6 && make modules_install && make install goes by pretty quickly...   :Very Happy: 

BTW - should this thread be marked as 'solved', to encourage others with the same issue(s)?

----------

## NeddySeagoon

dewhite,

```
[    2.226640] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
```

is before 

```
[    3.165286]  sda: sda1 sda2
```

which is your real HDD and the container for /lib/firmare, so its unlikely firmware is loaded.

Its also unlikely that the ethernet driver comes from /lib/modules/... as your real_root is not yet mounted.

Its perfectly possible to put all this stuff into your initrd ... but did you?

As far as I know, neither dracut nor genkernel are that clever.

I suspect something went wrong with your kernel install.

----------

## dewhite

 *NeddySeagoon wrote:*   

> dewhite,
> 
> ```
> [    2.226640] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> ```
> ...

 

In fact, I prefer to avoid things like genkernel and dracut, because when things break, you have no idea what 'not broken' was supposed to look/feel like.  That, and maybe I'm a little OCD.  :Wink: 

I wrote an init script and rolled my own initramfs around it.

I must have misunderstood what was taking place here.  I was under the impression that, at compile time, make was looking for the firmware blob, in the specified location, to build into the kernel driver.  Is the kernel actually trying to dynamically pull the firmware in each time it boots?

If so - what you're saying makes perfect sense.  Why then, I wonder, after a recompile of the 8169 driver into the kernel, did the pause during boot and complaints about firmware disappear from dmesg?

Is there a tool that will probe the device or kernel driver and tell me if it has the enhanced functionality supported by loading the firmware?

I'm sure I could just create the /lib/firmware directory structure in my initramfs and drop in the firmware file, but I'd like to understand what's going on in the case that something like this comes up again...

----------

## Gusar

If the NIC driver is in the kernel (not a module), and so is the firmware, then /lib/firmware doesn't matter. The kernel does load the firmware at each boot, but this firmware is in the kernel image itself. Basically, your impression is correct.

----------

## NeddySeagoon

dewhite,

There are two options for kernel code and firmware that work and two that don't.

The easiest to make work is make the module needed the firmware as <M> and put the firmware into /lib/modules

Both the module and firmware are loaded after real_root is mounted as both parts of the driver are located on the the root filesystem.

dmesg tells you all about it.

The other approach, is to have both pieces of the code in the kernel binary.  The same mechanisim is used for firmware loading but this time bzImage provides all the parts.

The other combinations are doomed to fail.

I am not convinced you are running the kernel you think you are as the r8169 module appeared to load before your root filesystem was mounted.

As I said, thats unlikely but not impossible.

----------

## dewhite

 *NeddySeagoon wrote:*   

> dewhite,
> 
> There are two options for kernel code and firmware that work and two that don't.
> 
> The easiest to make work is make the module needed the firmware as <M> and put the firmware into /lib/modules
> ...

 

The wording in menuconfig suggests that the default behavior is to compile the firmware blob into the bzImage now:

```
          External firmware blobs to build into the kernel binary ────────┐

│  Please enter a string value. Use the <TAB> key to move from the input  │  

│  field to the buttons below it.
```

Which I obliged with the following options:

```
  (/sbin/hotplug) path to uevent helper

  [*] Maintain a devtmpfs filesystem to mount at /dev

  [ ]   Automount devtmpfs at /dev, after the kernel mounted the rootfs

  [*] Select only drivers that don't need compile-time external firmware

  [*] Prevent firmware from being built

  -*- Userspace firmware loading support

  [*]   Include in-kernel firmware blobs in kernel binary

  (rtl_nic/rtl8168e-3.fw) External firmware blobs to build into the kernel binary

  (/lib/firmware/) Firmware blobs root directory

  [ ] Driver Core verbose debug messages

  [*] Managed device resources verbose debug messages
```

Maybe this has not been the case in the past, but I believe that now the firmware blob specified in the configuration is being compiled directly into the bzImage, in order to facilitate exactly what I was trying to do (and likely, some much fancier and more important things being attempted by others).

----------

## Odward

Not wishing to interrupt, but wanting to give thanks for this thread being resurrected at an opportune time.

As well of course to the posters for solutions.

I literally just built a new PC and had a 60 second hang on boot resulting from the 'isci' driver for my Intel C600 SAS Controller.

```
[    0.583631] isci: Intel(R) C600 SAS Controller Driver - version 1.1.0

[    0.584157] isci 0000:05:00.0: driver configured for rev: 5 silicon

[   61.493396] isci 0000:05:00.0: Loading user firmware failed, using default values

```

I had already emerged the firmware, so I recompiled the kernel and now have:

```
CONFIG_PREVENT_FIRMWARE_BUILD=y

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE="isci/isci_firmware.bin"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"

CONFIG_FIRMWARE_EDID=y

CONFIG_FIRMWARE_MEMMAP=y

```

I don't use an initrd and thanks to this thread was quickly able to learn at least one method to build the firmware into the kernel.

Now she fires right up!

----------

## NeddySeagoon

dewhite,

Thats correct but incomplete.  The r8169 driver must also be selected as <*>.  

I guess it is, as it appears to initialise before real_root is mounted.  If so, all is well.

----------

## dewhite

 *NeddySeagoon wrote:*   

> dewhite,
> 
> Thats correct but incomplete.  The r8169 driver must also be selected as <*>.  
> 
> I guess it is, as it appears to initialise before real_root is mounted.  If so, all is well.

 

Indeed.  While I was trouble-shooting the problem I built the driver as a module (at your suggestion, I believe) to see if it would be able to load the firmware blob.  Then after successfully loading the module+firmware I reverted back to building the driver into the kernel (as I must have it available early on to support dropbear for my init script).

That was when I noticed that the in-built kernel driver seemed to be properly loading the firmware blob before having access to the root filesystem, and surmised that the blob must have been packed into the bzImage at compile time.  My best guess about why this hadn't happened the first time I re-compiled with the firmware location in menuconfig, is that I hadn't done:

```
make clean
```

Before doing:

```
make -j6 && make modules_install && make install
```

Since the kernel driver had already been built in a previous compile, make skipped rebuilding it, and therefore also skipped looking for the firmware blob associated to built into the image.  I imagine something like that  was going on, anyway...

Thanks again for helping me along the way!

----------

## SlashBeast

Hi all,

Allow me to resurrect this very thread, as I am facing the same issue with r8169 with pretty much the same usecase as dewhite.

A little background. I have remote box with dropbear sshd server into initramfs, to initialize LUKS before system starts etc. 

After system starts, it need about one minute to let me in (no ping works before). I can see in kernel log

```
Aug 04 13:15:13 [kernel] r8169 0000:03:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2)
```

So I included the firmware from linux-firmware package into initramfs, I see no more this error but I still need about minute after booting kernel to being able to ping and ssh there. Any ideas?

```
sugoi [SSH] grsec [master] # dmesg | grep -i r8169

[    0.502301] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded

[    0.502648] r8169 0000:03:00.0 eth0: RTL8168f/8111f at 0xffffc90001c5a000, 74:d0:2b:xx:xx:xx, XID 08000880 IRQ 16

[    0.502715] r8169 0000:03:00.0 eth0: jumbo features [frames: 9200 bytes, tx checksumming: ko]

[    1.004279] r8169 0000:03:00.0 eth0: link down

[    1.004330] r8169 0000:03:00.0 eth0: link down

[    2.662695] r8169 0000:03:00.0 eth0: link up
```

fwiw driver is bulit direcly into kernel.

edit:

After reading thru this thread I decided to drop /lib/firmware/rtl_nic from initramfs and include it in kernel. And hey, it worked.

```
# CONFIG_PREVENT_FIRMWARE_BUILD is not set

# CONFIG_FIRMWARE_IN_KERNEL is not set

CONFIG_EXTRA_FIRMWARE="rtl_nic/rtl8168f-1.fw"

CONFIG_EXTRA_FIRMWARE_DIR="/lib/firmware/"
```

Space magic, in-kernel driver can scan thru rootfs and find firmware but still add the timeout or something. Propably if I would include NIC driver as module and firmware in initramfs it would be instant, as with the EXTRA_FIRMWARE option.Last edited by SlashBeast on Sun Aug 04, 2013 8:48 pm; edited 1 time in total

----------

## NeddySeagoon

SlashBeast,

The salient points are  *Quote:*   

> fwiw driver is bulit direcly into kernel.

 and *Quote:*   

> I included the firmware from linux-firmware package into initramfs

 

I think you need to move the firmware into the kernel as the initrd is treated like a root filesystem.

Thus when the initrd is mounted, its already too late.

IF you have built the initramfs into the kernel, that may work - I've never tested built in initramfs.

----------

## SlashBeast

Pretty much yeah, I've ninja'ed your reply with my edit to last post.

the only funny part is that it does not print about missing firmware so eventualy it finds it in initramfs.

thanks anyway.  :Wink: 

----------

## archenroot

Hi,

I know it is old thread, but I was playing in this Christmas time with transforming Gentoo workstation install to support Gnome 3.8.* desktop. Well finally all the packages were merged and few changes I have done also within the kernel. What happened is that after boot, there is no network available. The r8169 driver was builtin kernel.

there is 'enp4s0' interface visible under /sys/class/net in moment, so I am going to just issue:

```
#ifconfig enp4s0 up
```

with result:

```
enp4s0: unable to load firmware patch rtl_nic/rtl8168f-1.fw (-2)
```

If I issue the command for second time, everything is just fine, the interface is going up. After I issue:

```
dhcpcd enp4s0
```

I can communicate.

I tried with following kernels both setup as module or builtin, the behavior is still the same.

linux-3.10.17-gentoo

linux-3.12.6-gentoo

I am stating that before I started playing with kernel because of systemd changes (NOT all changes were directly required by systemd), the interace was always up and running without such issue. I don't understand why for first time I receive error while loading firmware and after second run, it is running just fine.

Any hints?

Thanks.

----------

## Gusar

@arhcenroot: This is what you're hitting: https://forums.gentoo.org/viewtopic-p-7441414.html#7441414

----------

## archenroot

@gusar I didn't read it completely but from the first sight I see somehting what I was thinking that might cause troubles> userspace firmware helper. I checked now and I have follwoing settings:

```
helios linux # cat .config |grep FIRMWARE

CONFIG_PREVENT_FIRMWARE_BUILD=y

CONFIG_FIRMWARE_IN_KERNEL=y

CONFIG_EXTRA_FIRMWARE=""

# CONFIG_CYPRESS_FIRMWARE is not set

# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set

# CONFIG_FIRMWARE_EDID is not set

# CONFIG_FIRMWARE_MEMMAP is not set

# CONFIG_GOOGLE_FIRMWARE is not set

helios linux # cat .config |grep USERSPACE

# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set

CONFIG_CPU_FREQ_GOV_USERSPACE=y

# CONFIG_DM_LOG_USERSPACE is not set

helios linux # cat .config |grep HELPER

CONFIG_USE_GENERIC_SMP_HELPERS=y

CONFIG_IOMMU_HELPER=y

CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"

CONFIG_FW_LOADER_USER_HELPER=y

CONFIG_I2C_HELPER_AUTO=y

CONFIG_DRM_KMS_HELPER=y

CONFIG_FB_MODE_HELPERS=y

# CONFIG_TEST_STRING_HELPERS is not set

helios linux #

```

going to disable the helper and will retry  :Smile:  thanks for fast response.

----------

## Alpenjoe

There is a firmware package sys-kernel/linux-firmware that I used to fix my firmware problem

```
emerge -av sys-kernel/linux-firmware
```

----------

## depontius

My recently-purchased motherboard seems to need the network firmware, though as with others, it is working without it.  It also needs firmware for its embedded AMD/ATI graphics adapter.  Right now I'm using the radeon-ucode package, which cannot be installed at the same time as linux-firmware.  There are several files present in radeo-ucode which are newer than what is in linux-firmware, and thus not present there.  Manual hacks can always be done, but is there a "Gentoo way" to get the newer elements of radeon-ucode along with the rest of linux-firmware?

----------

## Ant P.

Looks like this thread gets resurrected frequently so I'll add my 2 bits...

I've been DDG'ing the filename trying to figure out what the firmware actually does in this case. I'm fixing it anyway just to keep dmesg tidy but was I missing out by not doing so? AFAIK the NIC already operates normally without firmware, gigabit with jumbo frames works here no problem. Me poking at random features it advertises support for in ethtool causes it to stop working until I revert them but I'm assuming that's due to it being a bottom-dollar onboard chipset.

I have the driver built in, but it doesn't cause any 60-second delay (they may have done something about that recently - this is 4.14/4.15). dmesg just tells me it can't find the firmware and carries on:

```
dmesg --reltime

[  +0.010997] udevd[1171]: starting eudev-3.2.5

[  +0.011979] r8169 0000:07:00.0: Direct firmware load for rtl_nic/rtl8168e-2.fw failed with error -2

[  +0.000011] r8169 0000:07:00.0 eth0: unable to load firmware patch rtl_nic/rtl8168e-2.fw (-2)

[  +0.070345] NFSD: starting 90-second grace period (net ffffffff9525d940)
```

----------

## skellr

 *Ant P. wrote:*   

> Looks like this thread gets resurrected frequently so I'll add my 2 bits...
> 
> I've been DDG'ing the filename trying to figure out what the firmware actually does in this case. I'm fixing it anyway just to keep dmesg tidy but was I missing out by not doing so? AFAIK the NIC already operates normally without firmware, gigabit with jumbo frames works here no problem. Me poking at random features it advertises support for in ethtool causes it to stop working until I revert them but I'm assuming that's due to it being a bottom-dollar onboard chipset.
> 
> I have the driver built in, but it doesn't cause any 60-second delay (they may have done something about that recently - this is 4.14/4.15). dmesg just tells me it can't find the firmware and carries on:
> ...

 

I'd guess firmware is for power management features. I have llaptops with intel, rtl, wireless, and  ethernet that all want firmware. They all work fine without the firmware except when it's time for them to "sleep".

----------

