Hide Forgot
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): 2.6.9-39.EL How reproducible: 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. 2. 3. Actual results: Kernel panics. Expected results: Kernel does not panic. Additional info: 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 come up?
*** Bug 196720 has been marked as a duplicate of this bug. ***
There are 4 ES7000/5xx models and the dmidecode values are ES7000-505-G3 ES7000-510-G3 ES7000-520-G3 ES7000-540-G3
Larry, 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. http://www.darnok.org/unisys/kernel-2.6.9-40.1.EL_BZ196723_brew.i686.rpm Thanks!
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.
Larry, Let me re-roll a patch a supply another kernel for testing.
Please try this kernel: http://www.darnok.org/unisys/kernel-2.6.9-42.EL_BZ196723_2.i686.rpm
Konrad, 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 from http://people.redhat.com/~jbaron/rhel4/
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 release.
The test kernel provided in Comment 25 (2.6.9-42.5.EL)ran successfully on the Dylan system.
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. http://rhn.redhat.com/errata/RHBA-2007-0304.html