View previous topic :: View next topic |
Author |
Message |
paradigm-X Apprentice
Joined: 19 Sep 2013 Posts: 168
|
Posted: Tue Jan 28, 2014 6:22 pm Post subject: Firmware missing error message during boot |
|
|
During a recent kernel upgrade, I must have screwed up, or failed to set, one of my settings for the kernel in menuconfig because I am now getting this error(?) message during boot:
"rtl8192se: firmware rtlwifi/rtl8192se fw.bin not available"
After it appears for a bit, the booting process continues regardless. This device is a Realtek (RTL8191SEvB Wireless LAN Controller), i.e., wireless network adapter in the motherboard.
I am not sure why firmware is being searched, at least that is how it appears to me at this point. If someone can point me to a ink for an explanation of why this would happen, I would appreciate it. |
|
Back to top |
|
|
Hu Moderator
Joined: 06 Mar 2007 Posts: 21490
|
Posted: Tue Jan 28, 2014 11:58 pm Post subject: |
|
|
Firmware is searched when the kernel initializes a driver for a device for which firmware should be loaded. Continuing without the firmware has consequences ranging from reduced functionality to complete unusability of the device. You can include the firmware in the kernel image to make it always available, or install the firmware on the filesystem and ensure that the driver initializes after the filesystem is mounted. |
|
Back to top |
|
|
noidgone n00b
Joined: 28 Jan 2014 Posts: 8
|
Posted: Wed Jan 29, 2014 12:18 am Post subject: compile in or load on boot |
|
|
I think the way it should work is that you need the firmware file that it mentions either compiled in or loaded on boot.
To compile the firmware into the kernel for example, you can include the path to your firmware file under
Device Drivers->Generic Driver Options->Include in-kernel firmware blobs in kernel binary
I think the firmware is included in the "linux-firmware" package so do an "emerge linux-firmware", it might even work after emerging that.
Does that help?.. |
|
Back to top |
|
|
paradigm-X Apprentice
Joined: 19 Sep 2013 Posts: 168
|
Posted: Fri Jan 31, 2014 4:12 am Post subject: |
|
|
> "Does that help?.."
Indeed it does and thanks for the input, noidgone.
> "I think the firmware is included in the "linux-firmware" package so do an "emerge linux-firmware", it might even work after emerging that. "
I am still a bit puzzled why this was not an issue until now, after the new kernel. I did not add a new device, and unless I am just mistaken, I believe that it was available before. I never had to do anything with firmware up to now. |
|
Back to top |
|
|
noidgone n00b
Joined: 28 Jan 2014 Posts: 8
|
Posted: Fri Jan 31, 2014 4:33 am Post subject: see Hu's comment |
|
|
I think Hu described it best... It might have been partially working and you may have seen it there in lspci or even in your interface list, but it may not have been fully functional by loading the firmware? Maybe it was unfunctional to not even get to load the firmware and complain with an error output and something has been updated in the mainline kernel to merge more code to make it more functional even?
Not sure, can you search your logs back that far to find out perhaps? Only if you are really interested I guess. |
|
Back to top |
|
|
paradigm-X Apprentice
Joined: 19 Sep 2013 Posts: 168
|
Posted: Sun Feb 02, 2014 9:08 pm Post subject: |
|
|
I can't figure out what it is that makes those drivers listed in the kernel menuconfig section called "Firmware Drivers" so special as to require them to have been put in this section uniquely by themselves. There are are only a few listed there, but I can see nothing typical in them. What am I missing? It would be good to understand this point, I should think. Hopefully, a developer can chime in on it. |
|
Back to top |
|
|
noidgone n00b
Joined: 28 Jan 2014 Posts: 8
|
Posted: Mon Feb 03, 2014 2:04 am Post subject: maybe this is the reason... |
|
|
*I think* it's the chipsets in whatever hardware being used that have not been fully reverse engineered by a developer to have a completely open-source and stable solution in the kernel itself. It needs a commercially produced binary blob to inject to the EEPROM controller of the chipset to make it run correctly.
Not sure if this is correct, but that's my best guess. |
|
Back to top |
|
|
|