karmic/lucid installation slow on "detecting network hardware" with bnx2x
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
initramfs-tools (Ubuntu) |
Fix Released
|
Undecided
|
Unassigned | ||
Lucid |
Won't Fix
|
Medium
|
Stefan Bader | ||
linux (Ubuntu) |
Fix Released
|
Medium
|
Unassigned | ||
Lucid |
Fix Released
|
Medium
|
Unassigned |
Bug Description
Binary package hint: linux-image-
When installing some of my new bl460c g6 blades with bnx2x 10GE interfaces, the step "detecting network hardware" takes a really long time. This is probably due to the installer scanning all interfaces several times, and these blades have 8 of them (each physical interface is split into 4 virtual one, each exposed as a nic by the kernel), together with a 50-second timeout in the driver.
50 seconds times 8 interfaces times 3-4 probing rounds makes for a total delay of 20-30 minutes, which is a bit painful.
The delay seems to be in "[bnx2x_
I am booting a slightly modified (bnx2x dependencies added to the initrd) karmic netboot installer as of last week, will try the latest version as soon as #360966 gets fixed.
-------
SRU Justification (iniramfs-tools):
[Impact]
The libcrc32c module depends in a non-detectable way on the crypto/crc32c module. If any driver (like the bnx2x) depends on libcrc32c there will be problems while loading the driver without the rootfs already attached. In the bnx2x case at least this delays the boot process by 3-4 minutes while the driver waits and retries the modprobe of libcrc32c.
[Fix]
This is a backport from Debian which is contained in newer releases. It adds a checking function which looks for libcrc32c being in the initramfs and if it is there manually adds crc32c.
[Testcase]
Before this change or if there is no driver required that pulls in libcrc32c
#> gunzip -c <initrd> | cpio -t | grep crc32
would show either nothing or libcrc32c alone. After the change it shows either none or both crc32 modules.
[Regression Potential]
Low. Even if the crc32c module would be added incorrectly, it would not be used. The package could fail to build (though test build was done in a current Lucid environment) or the generation of initramfs could fail to unrelated reasons.
Changed in linux (Ubuntu Lucid): | |
status: | Confirmed → Triaged |
Changed in linux (Ubuntu Lucid): | |
assignee: | nobody → Stefan Bader (stefan-bader-canonical) |
Changed in linux (Ubuntu Lucid): | |
status: | Triaged → Incomplete |
tags: | added: kernel-da-key |
description: | updated |
description: | updated |
tags: | added: removal-candidate |
Of interest could be that the current Squeeze installer kernel is significantly faster, by not having this 50 second timeout, but then that is a fairly ancient 2.6.26-2 with other issues.