Red Hat Bugzilla – Bug 196723
RHEL4 U4 i386 partner beta will not install on Dylan systems
Last modified: 2009-06-18 11:27:15 EDT
Description of problem:
When attempting to install the RHEL4 U4 partner beta (i386) on a Unisys Dylan
system, the uniprocessor installation kernel panics. We found that the system
will install when using the "noapic" parameter.
This is a regression from RHEL4 U3. There were no kernel parameters rquired
to install RHEL4 U3
Version-Release number of selected component (if applicable):
Can be reproduced anytime install is attempted without the nopic parameter.
Steps to Reproduce:
1. Boot from the RHEL4 U4 i386 partner beta CD1 and attempt to install.
Kernel does not panic.
This problem appears to be similar to the problem reported in Bugzilla Bug
195002. The patch that corrected that problem will not corrct this one
because the dmidecode values are different for the Dylan systems. If you want
to make a similar patch for the Dylan systems we can provide the dmidecode
product names for the Dylan systems.
"Dylan" systems are the ES7000/5xx series of systems. (They are i386 only.)
Pls provide the dmidecode. Are there any other OEM-ed Unisys machines that might
*** Bug 196720 has been marked as a duplicate of this bug. ***
There are 4 ES7000/5xx models and the dmidecode values are
What is "dmidecode values"? Is that the product name? What is the Vendor? Still
"UNISYS" or is it "Dylan" ?
Those are product names. The vendor is still UNISYS.
Pls try this kernel without the noapic on one of those 5xx models.
Created attachment 132403 [details]
dmidecode command output from a Dylan system
The test kernel did not work, we got the same error. I think the problem is
that we gave you incorrect information. For the Dylan systems the vendor name
is Unisys Corporation not UNISYS as we indicated. UNISYS is used for
the newer ES7000-ONE and ES7000-600 systems.
I have attached the dmidecode output for clarity.
If this is the problem I apologize for the misinformation. If this is not the
problem then please tell me what addtional information you require.
Let me re-roll a patch a supply another kernel for testing.
Please try this kernel:
The new kernel worked. Thanks for making the change. You can go ahead and
submit the patch.
Patch posted for internal kernel reflector for review and inclusion.
The patch is pretty straightforward and doesn't really impact anything else
(just adds additional calls to disable apic for specific hardware.) If we're
willing to take the hit (2 days I would suspect) to respin and move the
resulting kernel through the advisory process then QE ack.
We also need to think about what other pieces of hardware might be impacted by
us enabling apic in the UP kernel. Probably should think about a kbase entry
asking users to try "noapic" as I'm sure there's other hardware which exhibits
the same issue.
We found very little hardware impacted by enabling the apic in the up kernel. we
actually already put in an auto detect for a unisys box already in U4 see bz
195002, no idea why we didn't know the extent of the unisys systems at that point.
I don't think this should block GA, it wouldn't affect existing upgrades, only
fresh installs, which can be worked around with the 'noapic' on the command
line. I only marked this an exception since its a regression introduced in U4
which meets the respin criteria.
committed in stream U5 build 42.2. A test kernel with this patch is available
This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release. Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products. This request is not yet committed for inclusion in an Update
The test kernel provided in Comment 25 (2.6.9-42.5.EL)ran successfully on the
This bugzilla has Keywords: Regression.
Since no regressions are allowed between releases,
it is also being marked as a blocker for this release.
Please resolve ASAP.
Shouldn't this BZ be in VERIFIED state?
Comment #29 says: "The test kernel provided in Comment 25 (2.6.9-42.5.EL)ran
successfully on the Dylan system."
ah.. the bug will stay in MODIFIED state until the whole kernel gets
handed off to QE. Then the state will change from MODIDIED to ON_QA,
then to VERIFIED.
Patch is in the -52 kernel, already verified by the partner.
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.