Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454615 - [Broadcom 5.4 bug] installation utility doesn't recognize HW, when bnx2x is installed from driver disk
Summary: [Broadcom 5.4 bug] installation utility doesn't recognize HW, when bnx2x is i...
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: driver-update-program
Version: 5.2
Hardware: All
OS: Linux
high
high
Target Milestone: rc
: 5.4
Assignee: Jon Masters
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-07-09 12:25 UTC by Vladislav Zolotarov
Modified: 2009-06-20 04:48 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-03-13 19:04:04 UTC


Attachments (Terms of Use)

Description Vladislav Zolotarov 2008-07-09 12:25:55 UTC
Description of problem:

Driver update utility can't recognize the appropriate HW after loading the bnx2x
driver from the driver disk during the installation while RH4 works perfectly
fine with the same driver disk (the mentioned disks are just the same except for
the modules.cgz, where the the top dir had the appropriate name and bnx2x.ko has
been compiled against the appropriate kernel).

Version-Release number of selected component (if applicable):


How reproducible:
Easily

Steps to Reproduce:
1. Disable all network devices except for NetXtreme II 10-Gigabit Ethernet
device (BIOS).
2. Create driver disk for the current bnx2x driver (ISO).
3. Start installation from the CD.
4. Choose linux dd askmethod 
5. When asked for a driver disk - use the one created at Step 1.
6. Press Alt-F3 to see that driver has been successfully loaded.
7. When asked for an installation method choose NFS of FTP.
8. At this stage RH4 recognizes that there is NetExtreme device and will
continue to NIC selection menu. RH5 doesn't do that and suggests to choose the
driver manually. Choose bnx2x driver.

At this stage installation utility will report that it can't find the
"appropriate device for this installation type"
  
Actual results:
NetXtreme II 10-Gigabit Ethernet device can not be used as a network device
during the installation.

Expected results:
NetXtreme II 10-Gigabit Ethernet device should be available as a network device
during the installation with driver disk.

Additional info:
Apparently, the problem is a size of bnx2x.ko.

Comment 1 Andrius Benokraitis 2008-07-10 15:24:37 UTC
Adding other Broadcom folks to CC.

Comment 3 Andrius Benokraitis 2008-07-10 15:27:24 UTC
Also I'm not the maintainer of this, I found the following on
www.driverupdateprogram.com:

Building a Driver Update Disk
Red Hat Driver Update Disks are built using ddiskit.

Driver Update Disks have been modified in RHEL5.1 and a new version of ddiskit 
(http://dup.et.redhat.com/ddiskit/) has been released that supports the use of
the RHEL Driver Update Program. Driver Update Disks are only ever used in the
specific case that either a SCSI or NETwork device must be used in order to
facilitate an install, but are not otherwise needed (drivers can be added to a
system after installation).

Creating a Driver Update Disk now works as before (see the documentation and
examples in the ddiskit sources - specifically the qla2xxx example that has been
included for this purpose), however you have the option of using your RPM
sources, rather than raw module source. During installation, if the installer
sees an RPM version of your driver on the disk (in the new disk format), then it
will copy the driver RPM onto the target and install it. The RHEL Driver Update
Program will retain this driver across future kernel updates.

Please note that it is still necessary to build the driver disk itself against a
specific kernel version, since the disk contains an unpacked version of your
module that is used by the installer itself - it is unable to use an RPM package
directly at the "stage 1" part of the system installation. This means that,
although your module will persist once installed, you still need a driver disk
for each release of RHEL5 that you want to support - i.e. one disk for RHEL5.0,
one for RHEL5.1, etc.

Comment 4 Matt Carlson 2008-07-10 18:51:12 UTC
Thanks Andrius.  The more information we can get on this, the better.

I'm not sure I see how a packaging change will affect the outcome though.  At
the lowest levels, a driver binary is present and loaded into the system.  The
rest is just "fluff".

Here are some more details about the problem :

* If I boot into rescue mode, unpack the driver and load it, the "1.5" device is
seen and works.
* If we replace the bnx2x device with an older "1.0" device, the driver works
from the installer.
* I tried reinserting the bnx2x "1.5" device, dropping to the console and
manually inserting the driver.  Unfortunately, the iscsi devices are not seen
later on in the install process, but the device can ping.  This is probably
because I don't completely understand the iSCSI process yet.

I think the problem is that "1.5" devices take considerably longer to
initialize.  I believe the installer is not waiting long enough for the device
to initialize before continuing.  To back this claim up, I would need to see the
"using /tmp/.../bnx2x.ko" message from VT 2, but I don't see it.  Perhaps this
is a technicality that can be dismissed?

Comment 5 Vladislav Zolotarov 2008-07-15 09:13:39 UTC
I tried to use the mentioned utility. It fails to build even the example it has
(I tried to build it on RH5 Gold distro).
Anyway, Andrew, we would appreciate if u could provide us with detailed
description of driver disk structure especially RPM option.


(In reply to comment #3)
> Also I'm not the maintainer of this, I found the following on
> www.driverupdateprogram.com:
> 
> Building a Driver Update Disk
> Red Hat Driver Update Disks are built using ddiskit.
> 
> Driver Update Disks have been modified in RHEL5.1 and a new version of ddiskit 
> (http://dup.et.redhat.com/ddiskit/) has been released that supports the use of
> the RHEL Driver Update Program. Driver Update Disks are only ever used in the
> specific case that either a SCSI or NETwork device must be used in order to
> facilitate an install, but are not otherwise needed (drivers can be added to a
> system after installation).
> 
> Creating a Driver Update Disk now works as before (see the documentation and
> examples in the ddiskit sources - specifically the qla2xxx example that has been
> included for this purpose), however you have the option of using your RPM
> sources, rather than raw module source. During installation, if the installer
> sees an RPM version of your driver on the disk (in the new disk format), then it
> will copy the driver RPM onto the target and install it. The RHEL Driver Update
> Program will retain this driver across future kernel updates.
> 
> Please note that it is still necessary to build the driver disk itself against a
> specific kernel version, since the disk contains an unpacked version of your
> module that is used by the installer itself - it is unable to use an RPM package
> directly at the "stage 1" part of the system installation. This means that,
> although your module will persist once installed, you still need a driver disk
> for each release of RHEL5 that you want to support - i.e. one disk for RHEL5.0,
> one for RHEL5.1, etc.



Comment 8 Andrius Benokraitis 2008-11-17 21:38:37 UTC
Jon - any updates?

Comment 9 Andrius Benokraitis 2008-11-17 21:39:20 UTC
Vladislav - I believe Jon created a bnx2x driver update disk recently. Would you like to test that?

Comment 10 Vladislav Zolotarov 2008-11-18 14:45:13 UTC
Andrius - i'd like to understand what was the problem and where. Then, of course I'd like to test it. Do u imply that the problem was in the driver disk? 
Pls., comment.

Comment 11 Andrius Benokraitis 2008-11-18 16:11:15 UTC
Vladislav - I don't think there was an issue, there was new hardware enablement and a DUD was required for an OEM. I'm attaching an ISO that has multiple DUDs on it, one of them should be an updated bnx2x instance.

http://people.redhat.com/andriusb/.bnx2x/dd.iso.gz

Comment 12 Vladislav Zolotarov 2008-11-18 16:48:29 UTC
Andrius - I'm afraid u completely misunderstood the problem: it's not that we needed u guys to create a driver disk for us. We are the ones who provide it to OEMs. If u'd read more carefully a BUG description (specifically step 2) then u would notice that we used a driver disk created specifically for the hardware we are trying to enable. There is an ISSUE with your release that needs to be fixed and it's quite described in the bug. 

From your responses I assume that there was done nothing (!!!) on the matter except for creating a driver disk (which we had before anyway). Am I correct?

Comment 13 Vladislav Zolotarov 2008-11-18 16:50:10 UTC
Just to be sure, I've tested the DUD u've provided and still didn't work (why would it?).

Comment 14 Andrius Benokraitis 2008-11-18 17:12:42 UTC
I'm deferring this to Jon (the bug assignee) since he is the maintainer of ddiskit. My attempt at helping isn't helping at all.

Comment 16 RHEL Product and Program Management 2008-12-09 21:12:46 UTC
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.


Note You need to log in before you can comment on or make changes to this bug.