Bug 25570

Summary:	System will reboot during Linux probing the PCI bus on HP's LH4 with NetRAID-2M controller
Product:	[Retired] Red Hat Linux	Reporter:	Venkatesh Ramamurthy <venkateshr>
Component:	kernel	Assignee:	Michael K. Johnson <johnsonm>
Status:	CLOSED WORKSFORME	QA Contact:	Brock Organ <borgan>
Severity:	high	Docs Contact:
Priority:	high
Version:	7.0	CC:	peterj, venkateshr
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
URL:	www.ami.com
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2003-06-05 23:29:28 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Venkatesh Ramamurthy 2001-02-01 23:54:44 UTC

Installing Linux Redhat7.0/6.2 to HP's LH4(Intel NX chipset) when NetRAID-
2M(AMI MegaRAID Controller) is in the primary bus(64bit).

System will reboot during Linux probing the PCI bus.

HP's NetRAID-2M contains a qlogic chip which is visible to the host bus.

According to the PCI trace:
***************************
Linux initiates I/O read one byte wide to the Qlogic SCSI Chip in the
NetRaid-2M.
Qlogic is not accesible to this type of cycle (I/O read one byte wide).
Linux retry the cycles three times, the last Qlogic initiate target
abort(stop asserted, devsel and trdy deasserted). This is valid!.

However, 180ns later Linux(not certain) resets the system.
My question: Does Linux susceptible to the target abort?

FYI, NetRAID-2M is 64bit adapter which is preferable to go to the 64bit PCI
slots.

Comment 1 Arjan van de Ven 2001-02-02 09:11:55 UTC

Does this also happen with the install-floppies (or cd) from the recently
released beta?

Comment 2 Venkatesh Ramamurthy 2001-02-02 18:12:48 UTC

The issue could not be reproduced in LH4 systems in AMI Labs. HP Labs have 
confirmed that it was behaving like my above mentioned report. I will pursue 
with HP with using floppy's for installation.

Comment 3 Michael K. Johnson 2001-02-08 21:14:06 UTC

peterj is actually the person responsible for this driver.
Peter, have you been involved in tracking this down?