Created attachment 434025 [details] /var/log/messages Description of problem: Network drivers regression on 34.x Version-Release number of selected component (if applicable): Any 34.x release in koji. How reproducible: Always Steps to Reproduce: 1. Boot 2. Restart Network 3. Actual results: Fail Expected results: Network up and running. Additional info: Works fine on any 33.x kernels we have
Upstream maintainers are putting new firmware into firmware/ instead of submitting the firmware to the linux-firmware project.
If linux-firmware is the right place for firmware cant Linus be convinced of simply reject any submission to firmware/ with firm msg to submitters that linux-firmware is the place this should be submitted to? Hum perhaps upstream kernel has already dropped whatever was in firmware which is logical cause for this happening in the first place ( them missing ). Anyway dont we need to package what ever that has been misplaced in firmware/ in current supported kernels ( 32.x and 33.x ) with linux-firmware to prevent regression like this happening in newer kernels ( 34.x 35.x and future )? Anyway given that my time playing with this particular HW is soon coming to an end I retested this with latest 34.2-32.rc1.fc13 and 35-0.58.rc6.git6.fc14 latest from koji at the time of this writing which was expected given that linux firmware has not been rebuilt contaning the necessary firmware ( last build was on 2010-04-08 ). Firmware is present in kernel 32.x 33x. but missing in 34.x and 35.x Reassigning this to linux-firmware since it seem to be the appropriate place for this bug.
(In reply to comment #2) > If linux-firmware is the right place for firmware cant Linus be convinced of > simply reject any submission to firmware/ with firm msg to submitters that > linux-firmware is the place this should be submitted to? Proposed as a topic for this year's Kernel Summit. https://lists.linux-foundation.org/mailman/private/ksummit-2010-discuss/2010-July/000001.html (may need login; no idea why that would be, sorry) > Reassigning this to linux-firmware since it seem to be the appropriate place > for this bug. This firmware isn't *in* the upstream linux-firmware tree. The author of the driver in question has made his driver require a new firmware without putting that firmware *anywhere* sensible. I will attempt to chase it up.
Can we somehow manually ( for testers ) or automate ( autoqa ) check if we have drivers that require new firmware and that firmware is missing to try to prevent potential regression like this. We probably would need to load the driver without the necessary hw in place to catch the drive complaining about the missing firmware? I doubt that this is the only driver that has required (new) firmware and that firmware has not been put anywhere sensible.
Well, there are *lots* of drivers which don't have firmware anywhere sensible. Take the b43/b43legacy drivers, for example -- you have to use b43-fwcutter to extract the firmware from the Windows/MacOS/etc binary drivers, and we're not allowed to distribute it at all. It's easy enough to get a list of required firmware images from the kernel modules, and to notice when it changes and starts to require something new -- but it's not clear that you'd want to do anything with that information in an automated fashion. Perhaps if a given module *used* to depend on firmware which is shipped in a package in Fedora, but now depends on something which is *not* available in Fedora, that could trigger a warning/build failure?
(In reply to comment #5) > It's easy enough to get a list of required firmware images from the kernel > modules, and to notice when it changes and starts to require something new -- > but it's not clear that you'd want to do anything with that information in an > automated fashion. True probably best to do nothing other then trigger a warning/notification. > Perhaps if a given module *used* to depend on firmware which is shipped in a > package in Fedora, but now depends on something which is *not* available in > Fedora, that could trigger a warning/build failure? Sound reasonable. Build failure might be to harsh I would think a simple notification email to the party involved should suffice. Would this actually be needed to be run on every build or just when we introduce a new kernel?
So basically it would just trigger a warning then a script could parse the warning message from the log and act accordingly or not :)
Can we just temporarily add the missing firmware to the fedora package as patches? I don't want to release 2.6.34 without that.
Maybe we should start building kernel-firmware again? This is also going to hit Fedora 14 Alpha. Should this be an F14 Alpha blocker?
linux-firmware-20100806-2.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/linux-firmware-20100806-2.fc14
linux-firmware-20100806-2.fc13 has been submitted as an update for Fedora 13. http://admin.fedoraproject.org/updates/linux-firmware-20100806-2.fc13
Confirmed fixed +1 karma given. Did you just add the bnx2-mips-09-5.0.0.j9.fw firmware or did you check for and add other firmware if any that we were missing in 34,35 that we had in 32 and 33. If so then I think 34 kernel can be pushed to updates-testing.
linux-firmware-20100806-2.fc13 has been pushed to the Fedora 13 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update linux-firmware'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/linux-firmware-20100806-2.fc13
I've pushed kernel-2.6.34.2-34.fc13 to updates-testing, but without a dependency on the new firmware. Should that be added before releasing a 2.6.34 kernel?
I think you might as well, yes.
I've added a dependency on linux-firmware >= 20100806-2 to f13, f14 and rawhide.
linux-firmware-20100806-2.fc14 has been pushed to the Fedora 14 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update linux-firmware'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/linux-firmware-20100806-2.fc14
linux-firmware-20100806-2.fc13 has been pushed to the Fedora 13 stable repository. If problems still persist, please make note of it in this bug report.
linux-firmware-20100806-3.fc14 has been submitted as an update for Fedora 14. http://admin.fedoraproject.org/updates/linux-firmware-20100806-3.fc14