Bug 173872 - sym53c8xx hang during installer module load
Summary: sym53c8xx hang during installer module load
Alias: None
Product: Red Hat Enterprise Linux 4
Classification: Red Hat
Component: kernel   
(Show other bugs)
Version: 4.0
Hardware: All
OS: Linux
Target Milestone: ---
: ---
Assignee: Jim Paradis
QA Contact: Brian Brock
Keywords: Regression
Depends On:
TreeView+ depends on / blocked
Reported: 2005-11-22 00:57 UTC by Chris Adams
Modified: 2007-11-30 22:07 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2006-09-20 19:29:43 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Boot logs (28.41 KB, text/plain)
2005-11-28 19:04 UTC, Chris Adams
no flags Details

Description Chris Adams 2005-11-22 00:57:44 UTC
I'm trying to install RHEL 4 on a system (RHEL 4 ES update 2
specifically), and the installer hangs when loading the sym53c8xx kernel module.
 When it loads the sym53c8xx module; I get:

<6>PCI: Assigned IRQ 11 for device 0000:00:0b.0
<6>sym0: <895> rev 0x1 at pci 0000:00:0b.0 irq 11
<4>sym0: Tekram NVRAM, ID 7, Fast-40, LVD, parity checking
<5>sym0: SCSI BUS has been reset.
<6>scsi0 : sym-2.1.18j
<4>sym0:0:0: ABORT operation started.
<4>sym0:0:0: ABORT operation timed-out.
<4>sym0:0:0: DEVICE RESET operation started.
<4>sym0:0:0: DEVICE RESET operation timed-out.
<4>sym0:0:0: BUS RESET operation started.
<4>sym0:0:0: BUS RESET operation timed-out.
<4>sym0:0:0: HOST RESET operation started.
<5>sym0: SCSI BUS has been reset.

See bug 89593 for history.  This was a problem starting in RHL 9 and was finally
fixed in an RHEL 3 errata but it is there again in RHEL 4.

Comment 1 Chris Adams 2005-11-22 21:49:59 UTC
I can successfully boot and run the installer with "acpi=force".  The system
BIOS is from 2000 (newest available) so otherwise ACPI is disabled.

Once installed, I can run the SMP kernel without ACPI.  The interrupt mapping is
quite different; with ACPI, I get SCSI adapters on 169, 177, 185, and 193, while
without ACPI, I get 5, 10, and two on 11.

Is there a pro or con to running with "acpi=force"?  Does the interrupt
assignment really matter?

Comment 2 Jim Paradis 2005-11-28 18:20:30 UTC
It appears as though RHEL3 has entries in the DMI blacklist for certain problem
440GX bioses, and this code has not been ported to RHEL4.  Thing is, RHEL3 does
not use ACPI for PCI configuration for i386, whereas RHEL4 does.  Therefore, I'm
wondering why we're not using the ACPI configuration on RHEL4.

Could you get a serial dump of a failed boot and attach it to this BZ?  While I
could just add in the blacklist entries for RHEL4, I'd like to see exactly
what's going on...

Comment 3 Chris Adams 2005-11-28 19:04:11 UTC
Created attachment 121556 [details]
Boot logs

Here are three boot logs:

- boot of non-SMP kernel with no extra options (hangs)
- boot of non-SMP kernel with "acpi=force" (boots)
- boot of SMP kernel with no extra options (boots)

Comment 4 Chris Adams 2006-01-18 21:57:55 UTC
Any update on this?  I still have one of these systems out of production, so I
can still gather any additional needed data.

Comment 7 Jim Paradis 2006-09-20 19:29:43 UTC
The use of the "acpi=force" parameter is perfectly legitimate in this
circumstance.  Due to the large number of buggy early implementations of ACPI,
the kernel enforces a blanket blacklist of BIOSes built prior to 2001.  If a
pre-2001 BIOS has good ACPI tables, then it's perfectly legitimate (even
preferable) to use them, and acpi=force is the mechanism for doing so.

Closing as WONTFIX because there is an acceptable workaround.

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