Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Firmware in Kernel Problem
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Mon Jan 21, 2013 7:03 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dewhite
Tux's lil' helper
Tux's lil' helper


Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA

PostPosted: Mon Jan 21, 2013 10:04 pm    Post subject: Reply with quote

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
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.


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

Code:
          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:

Code:
  (/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).
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1


Last edited by dewhite on Mon Jan 21, 2013 11:18 pm; edited 2 times in total
Back to top
View user's profile Send private message
Odward
n00b
n00b


Joined: 21 Mar 2012
Posts: 65

PostPosted: Mon Jan 21, 2013 10:27 pm    Post subject: Reply with quote

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.
Code:
[    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:
Code:
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!
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Tue Jan 22, 2013 9:36 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
dewhite
Tux's lil' helper
Tux's lil' helper


Joined: 16 Mar 2003
Posts: 106
Location: Houston, Texas, USA

PostPosted: Tue Jan 22, 2013 9:56 pm    Post subject: Reply with quote

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:

Code:
make clean


Before doing:

Code:
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!
_________________
Work FS: R7-5700g | 2x16Gb DDR4 | 500Gb NVMe LUKS root | 2x 8TB RAID1
Home FS: R7-1700x | 2x8Gb DDR4 | 275Gb M.2 SATA LUKS root | 2x 14TB RAID1
Back to top
View user's profile Send private message
SlashBeast
Retired Dev
Retired Dev


Joined: 23 May 2006
Posts: 2922

PostPosted: Sun Aug 04, 2013 8:10 pm    Post subject: Reply with quote

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
Code:
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?
Code:
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.

Code:
# 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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 54096
Location: 56N 3W

PostPosted: Sun Aug 04, 2013 8:37 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
SlashBeast
Retired Dev
Retired Dev


Joined: 23 May 2006
Posts: 2922

PostPosted: Sun Aug 04, 2013 8:48 pm    Post subject: Reply with quote

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. ;-)
Back to top
View user's profile Send private message
archenroot
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 218
Location: Lake Macha, Czech republic

PostPosted: Thu Dec 26, 2013 11:28 pm    Post subject: Still strange behavior with r8169 :-) Reply with quote

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:
Code:
#ifconfig enp4s0 up


with result:
Code:
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:
Code:
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.
_________________
Emperor wants to control outer space Yoda wants to explore inner space that's the fundamental difference between good and bad sides of the Force
Back to top
View user's profile Send private message
Gusar
Advocate
Advocate


Joined: 09 Apr 2005
Posts: 2665
Location: Slovenia

PostPosted: Thu Dec 26, 2013 11:48 pm    Post subject: Reply with quote

@arhcenroot: This is what you're hitting: https://forums.gentoo.org/viewtopic-p-7441414.html#7441414
Back to top
View user's profile Send private message
archenroot
Apprentice
Apprentice


Joined: 13 Dec 2011
Posts: 218
Location: Lake Macha, Czech republic

PostPosted: Fri Dec 27, 2013 12:32 am    Post subject: Reply with quote

@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:
Code:
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 :-) thanks for fast response.
_________________
Emperor wants to control outer space Yoda wants to explore inner space that's the fundamental difference between good and bad sides of the Force
Back to top
View user's profile Send private message
Alpenjoe
n00b
n00b


Joined: 08 Oct 2014
Posts: 1

PostPosted: Sat Oct 11, 2014 8:01 am    Post subject: Reply with quote

There is a firmware package sys-kernel/linux-firmware that I used to fix my firmware problem
Code:
emerge -av sys-kernel/linux-firmware
Back to top
View user's profile Send private message
depontius
Advocate
Advocate


Joined: 05 May 2004
Posts: 3509

PostPosted: Sat Oct 11, 2014 6:01 pm    Post subject: Reply with quote

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?
_________________
.sigs waste space and bandwidth
Back to top
View user's profile Send private message
Ant P.
Watchman
Watchman


Joined: 18 Apr 2009
Posts: 6920

PostPosted: Thu Mar 22, 2018 10:25 pm    Post subject: Reply with quote

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:
Code:
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)
Back to top
View user's profile Send private message
skellr
l33t
l33t


Joined: 18 Jun 2005
Posts: 975
Location: The Village, Portmeirion

PostPosted: Fri Mar 23, 2018 12:19 am    Post subject: Reply with quote

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:
Code:
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)

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".
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2
Page 2 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum