Bug 196723 - RHEL4 U4 i386 partner beta will not install on Dylan systems
RHEL4 U4 i386 partner beta will not install on Dylan systems
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
4.0
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Konrad Rzeszutek
Brian Brock
: Regression
: 196720 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-06-26 14:05 EDT by Larry Newitt
Modified: 2009-06-18 11:27 EDT (History)
9 users (show)

See Also:
Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-05-07 22:00:55 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
dmidecode command output from a Dylan system (34.92 KB, text/plain)
2006-07-13 18:12 EDT, Larry Newitt
no flags Details

  None (edit)
Description Larry Newitt 2006-06-26 14:05:20 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):
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.
Comment 1 Bruce Vessey 2006-06-26 14:39:18 EDT
"Dylan" systems are the ES7000/5xx series of systems.  (They are i386 only.)
Comment 2 Konrad Rzeszutek 2006-06-26 14:59:10 EDT
Pls provide the dmidecode. Are there any other OEM-ed Unisys machines that might
come up?
Comment 3 Konrad Rzeszutek 2006-06-26 15:15:26 EDT
*** Bug 196720 has been marked as a duplicate of this bug. ***
Comment 4 Larry Newitt 2006-07-07 12:09:43 EDT
There are 4 ES7000/5xx models and the dmidecode values are

ES7000-505-G3
ES7000-510-G3
ES7000-520-G3
ES7000-540-G3
Comment 5 Konrad Rzeszutek 2006-07-12 11:17:04 EDT
Larry,

What is "dmidecode values"? Is that the product name? What is the Vendor? Still
"UNISYS" or is it "Dylan" ? 
Comment 6 Daniel W. Ottey 2006-07-12 11:22:22 EDT
Those are product names.  The vendor is still UNISYS.
Comment 7 Konrad Rzeszutek 2006-07-12 16:19:14 EDT
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!
Comment 8 Larry Newitt 2006-07-13 18:12:44 EDT
Created attachment 132403 [details]
dmidecode command output from a Dylan system
Comment 9 Larry Newitt 2006-07-13 18:14:30 EDT
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.
Comment 10 Konrad Rzeszutek 2006-07-14 14:38:05 EDT
Larry,

Let me re-roll a patch a supply another kernel for testing.
Comment 12 Konrad Rzeszutek 2006-07-14 19:13:49 EDT
Please try this kernel:

http://www.darnok.org/unisys/kernel-2.6.9-42.EL_BZ196723_2.i686.rpm
Comment 13 Larry Newitt 2006-07-18 17:56:07 EDT
Konrad,

The new kernel worked.  Thanks for making the change. You can go ahead and 
submit the patch.
Comment 14 Konrad Rzeszutek 2006-07-18 19:31:33 EDT
Patch posted for internal kernel reflector for review and inclusion.
Comment 17 Jay Turner 2006-07-19 12:36:32 EDT
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.
Comment 19 Jason Baron 2006-07-19 14:49:47 EDT
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.
Comment 25 Jason Baron 2006-08-21 16:55:02 EDT
committed in stream U5 build 42.2. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 26 RHEL Product and Program Management 2006-09-07 15:12:50 EDT
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.
Comment 27 RHEL Product and Program Management 2006-09-07 15:12:56 EDT
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.
Comment 28 Larry Newitt 2006-09-07 16:33:47 EDT
The test kernel provided in Comment 25 (2.6.9-42.5.EL)ran successfully on the 
Dylan system.
Comment 29 RHEL Product and Program Management 2006-12-12 12:14:40 EST
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.
Comment 30 RHEL Product and Program Management 2006-12-12 12:14:58 EST
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.
Comment 31 Konrad Rzeszutek 2006-12-12 14:22:35 EST
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."
Comment 32 Linda Wang 2006-12-12 17:51:59 EST
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.
Comment 34 Mike Gahagan 2007-04-03 15:45:52 EDT
Patch is in the -52 kernel, already verified by the partner.
Comment 36 Red Hat Bugzilla 2007-05-07 22:00:55 EDT
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

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