Red Hat Bugzilla – Bug 186307
RHEL3U7 fails installation using RSA(2).
Last modified: 2007-11-30 17:07:09 EST
Description of problem:
When installaing RHEL3U7 remotly using the RSA(2) adapter the installation fails
- during the check media and also when installing packages.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1). From a remote host bring up a Java enabled browser to the RSA(2) device.
Select the Remote Control. In the new window click on the "Select file" to
select the RHEL3 U7 ISO image. Hit "Mount Drive"
2). Boot up the machine
3). Go through the steps of installing RHEL3 U7 and see it fail during media
check or during installation (packages are not read correctly)
With further discovery using an USB analyzer tool it became evident that
the RSA(2) emulates the USB CDROM. And since network latency is an issue here,
the RSA(2) adapter returns an error when it cannot fulfill the request for 63
sectors. It has no problems when the request is for 60 sectors.
There are two ways of fixing this: Make the RSA firmware return a different
error that would signal "timeout" and not "error" condition (in discussion) and
blacklist the RSA(2) adapter to set the request to the max of 60 sectors.
For the second purpose I am attaching an output from /proc/bus/usb/devices.
I am getting confirmation from the RSA folks about there being only
one type of VendorID and ProductID.
Created attachment 126501 [details]
Output from /proc/bus/usb/devices
The ID will be either:
depending on which version of RSA(2) hardware is used.
Created attachment 127905 [details]
Candidate #1 - Per-adapter max_sectors
Patch posted for review.
Created attachment 127969 [details]
Patch which was posted for review. Re-worked from Pete's. Added extra ProductIDs
Reverting last reassignment. Looks like patch was Pete's after all.
Konrad, when you get a chance, please ack Pete's patch on rhkernel-list
(and I guess you should explain that you posted it on Pete's behalf after
verifying the fix -- maybe you'll be the first person to ack a patch that
he/she has posted). :)
I am not allowed to post ACKs (as I am a "contractor" and not an employee). I
will solicit other people for ACKs and also post an explanation.
Hi, Konrad. I give you permission to "ack" any patch on rhkernel-list
that you feel competent enough to review (on technical grounds). If
anyone says you can't say "ack", then you can say that you have reviewed
the code changes and support them on their technical merits.
In any case, I'm considering the patch to be yours, so I'll count PeteZ's
ack (as the 2nd one), and I'm queuing the patch for tonight's build.
A fix for this problem has just been committed to the RHEL3 U8
patch pool this evening (in kernel version 2.4.21-41.EL).
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on the solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.