Bug 191847 - REGRESSION: kernel- does not boot on ALTIX systems
REGRESSION: kernel- does not boot on ALTIX systems
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel (Show other bugs)
ia64 Linux
urgent Severity high
: ---
: ---
Assigned To: Prarit Bhargava
Brian Brock
: Regression
Depends On:
Blocks: 181409
  Show dependency treegraph
Reported: 2006-05-15 21:58 EDT by Prarit Bhargava
Modified: 2009-06-18 11:15 EDT (History)
2 users (show)

See Also:
Fixed In Version: RHSA-2006-0575
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-08-10 19:18:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch to replace panic with printk (1.23 KB, patch)
2006-05-16 13:18 EDT, Prarit Bhargava
no flags Details | Diff

  None (edit)
Description Prarit Bhargava 2006-05-15 21:58:02 EDT
Description of problem:

kernel- fails due to panic in MADT ACPI table code.

Version-Release number of selected component (if applicable):

How reproducible: 100%

Steps to Reproduce:
1. Boot kernel 2.6.9-36
Actual results:

Loading initrd initrd-2.6.9-36.EL.img...done
Linux version 2.6.9-36.EL (bhcompile@bullwinkle.build.redhat.com) (gcc version
3.4.5 20051201 (Red Hat 3.4.5-2)) #1 SMP Tue May 9 09:06:25 EDT 2006
EFI v1.10 by INTEL: SALsystab=0x3002814b60 ACPI 2.0=0x300281b8e0
booting generic kernel on platform sn2
Number of logical nodes in system = 32
Number of memory chunks in system = 32
Initial ramdisk at: 0xe0000fb07a0ba000 (3331564 bytes)
SAL 2.9: SGI SN2 version 4.43
SAL Platform features: ITC_Drift
SAL: AP wakeup using external interrupt vector 0x12
No logical to physical processor mapping available
ACPI: Local APIC address c0000000fee00000
ACPI: Error parsing MADT - no IOSAPIC entries
register_intr: No IOSAPIC for GSI 52
Kernel panic - not syncing: acpi_register_gsi: out of interrupt vectors!

Expected results:

Boot should succeed.
Additional info: Binary search through patches indicates Anil's
acpi_register_gsi patch is the culprit.  Anil modified the code such that
acpi_register_gsi panic's if iosapic_register_intr returns < 0.  However, the
MADT code that registers the SCI interrupt can (and does handle) a return < 0.

Anil's patch should not panic if < 0 -- just output a warning?
Comment 2 Prarit Bhargava 2006-05-16 09:33:17 EDT

This statement in your patch is wrong:

+       /* Caller of acpi_register_gsi() assumes this function always succeeds,
+        * hence calling panic() for backward compatibility

IMO, calling panic() to maintain backward compatibility is incorrect here as this
will break all systems with bad ACPI tables (of which there are many).
Comment 4 Anil S Keshavamurthy 2006-05-16 13:16:59 EDT
Ha..good that I had a panic() call which caught the buggy ACPI table bug:) 
I am okay with you replacing panic() call with printk.
Comment 5 Prarit Bhargava 2006-05-16 13:18:02 EDT
Created attachment 129237 [details]
Patch to replace panic with printk

Patch to replace panic with printk
Comment 6 Jay Turner 2006-05-16 15:15:02 EDT
Regression in behavior introduced in U4 code development.  Not a beta blocker
and would agree to taking during beta since it's just a behavior change.
Comment 7 Daniel Riek 2006-05-17 17:05:16 EDT
PM ACK for U4
Comment 9 Jason Baron 2006-05-22 15:21:54 EDT
committed in stream U4 build 36.1. A test kernel with this patch is available
from http://people.redhat.com/~jbaron/rhel4/
Comment 13 Red Hat Bugzilla 2006-08-10 19:18:50 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.


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