Bug 196723 - RHEL4 U4 i386 partner beta will not install on Dylan systems
Summary: RHEL4 U4 i386 partner beta will not install on Dylan systems
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel
Version: 4.0
Hardware: i386
OS: Linux
medium
high
Target Milestone: ---
: ---
Assignee: Konrad Rzeszutek
QA Contact: Brian Brock
URL:
Whiteboard:
: 196720 (view as bug list)
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2006-06-26 18:05 UTC by Larry Newitt
Modified: 2009-06-18 15:27 UTC (History)
9 users (show)

Fixed In Version: RHBA-2007-0304
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2007-05-08 02:00:55 UTC
Target Upstream Version:
Embargoed:


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


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2007:0304 0 normal SHIPPED_LIVE Updated kernel packages available for Red Hat Enterprise Linux 4 Update 5 2007-04-28 18:58:50 UTC

Description Larry Newitt 2006-06-26 18:05:20 UTC
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 18:39:18 UTC
"Dylan" systems are the ES7000/5xx series of systems.  (They are i386 only.)

Comment 2 Konrad Rzeszutek 2006-06-26 18:59:10 UTC
Pls provide the dmidecode. Are there any other OEM-ed Unisys machines that might
come up?

Comment 3 Konrad Rzeszutek 2006-06-26 19:15:26 UTC
*** Bug 196720 has been marked as a duplicate of this bug. ***

Comment 4 Larry Newitt 2006-07-07 16:09:43 UTC
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 15:17:04 UTC
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 15:22:22 UTC
Those are product names.  The vendor is still UNISYS.

Comment 7 Konrad Rzeszutek 2006-07-12 20:19:14 UTC
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 22:12:44 UTC
Created attachment 132403 [details]
dmidecode command output from a Dylan system

Comment 9 Larry Newitt 2006-07-13 22:14:30 UTC
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 18:38:05 UTC
Larry,

Let me re-roll a patch a supply another kernel for testing.

Comment 12 Konrad Rzeszutek 2006-07-14 23:13:49 UTC
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 21:56:07 UTC
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 23:31:33 UTC
Patch posted for internal kernel reflector for review and inclusion.

Comment 17 Jay Turner 2006-07-19 16:36:32 UTC
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 18:49:47 UTC
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 20:55:02 UTC
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 Program Management 2006-09-07 19:12:50 UTC
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 Program Management 2006-09-07 19:12:56 UTC
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 20:33:47 UTC
The test kernel provided in Comment 25 (2.6.9-42.5.EL)ran successfully on the 
Dylan system.

Comment 29 RHEL Program Management 2006-12-12 17:14:40 UTC
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 Program Management 2006-12-12 17:14:58 UTC
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 19:22:35 UTC
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 22:51:59 UTC
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 19:45:52 UTC
Patch is in the -52 kernel, already verified by the partner.


Comment 36 Red Hat Bugzilla 2007-05-08 02:00:55 UTC
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.