Bug 25570 - System will reboot during Linux probing the PCI bus on HP's LH4 with NetRAID-2M controller
Summary: System will reboot during Linux probing the PCI bus on HP's LH4 with NetRAID-...
Keywords:
Status: CLOSED WORKSFORME
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel
Version: 7.0
Hardware: i386
OS: Linux
high
high
Target Milestone: ---
Assignee: Michael K. Johnson
QA Contact: Brock Organ
URL: www.ami.com
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2001-02-01 23:54 UTC by Venkatesh Ramamurthy
Modified: 2005-10-31 22:00 UTC (History)
2 users (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2003-06-05 23:29:28 UTC
Embargoed:


Attachments (Terms of Use)

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?


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