Bug 59926 - Hampton on PERC3 in 2nd slot of Boxster hangs
Summary: Hampton on PERC3 in 2nd slot of Boxster hangs
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.3
Hardware: i386
OS: Linux
Target Milestone: ---
Assignee: Arjan van de Ven
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2002-02-15 01:14 UTC by Tesfamariam Michael
Modified: 2005-10-31 22:00 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-09 00:37:17 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
mptable after megaraid load (25.98 KB, patch)
2002-02-15 01:16 UTC, Tesfamariam Michael
no flags Details | Diff
IRQ dump of RH7.2 using `dump_pirq` (2.36 KB, text/plain)
2002-02-15 16:16 UTC, Tesfamariam Michael
no flags Details
mptable dump of Discovery with PERC3/DC on the top slot (17.89 KB, text/plain)
2002-03-07 18:54 UTC, Tesfamariam Michael
no flags Details
mptable dump of Discovery on 4th slot (25.92 KB, text/plain)
2002-03-07 19:34 UTC, Tesfamariam Michael
no flags Details

Description Tesfamariam Michael 2002-02-15 01:14:26 UTC
Description of Problem:
Installing Hampton onto PERC3(megaraid driver) in slot2 of Boxster generates 
scsi-time out and system hangs.

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

How Reproducible:

Steps to Reproduce:
1. Install Hampton onto any PERC3 card in slot2 (middle slot)
2. reboot system with SMP or Enterprise kernel
3. System hangs due to scsi timeout

Actual Results:
System wont boot

Expected Results:
To be able to use PERC3 in any slot.

Additional Information:
This issue also happens on RH7.2.
Installing onto onborad scsi controller with PERC3 in the 2nd slot, booting 
with SMP or Enterprise kernel, and loading megaraid manually hangs. `lsmod` 
shows megaraid as "(initializing)" and `more /proc/interrupts` shows 
        11:          0          0          XT-PIC  megaraid

Comment 1 Tesfamariam Michael 2002-02-15 01:16:16 UTC
Created attachment 45780 [details]
mptable after megaraid load

Comment 2 Matt Domsch 2002-02-15 04:25:24 UTC
/proc/pci and megaraid driver both think (per dmesg) that the card is assigned 
IRQ11 (not sure why though).  But earlier in dmesg, there's no IRQ->pin mapping 
for 11 (why not if the others think there should be?).  Hence no interrupts...

Comment 3 Tesfamariam Michael 2002-02-15 16:16:44 UTC
Created attachment 45799 [details]
IRQ dump of RH7.2 using `dump_pirq`

Comment 4 Tesfamariam Michael 2002-03-04 17:36:06 UTC
This issue also happens on Discovery system with PERC3/QC. I will identify the 
slots and update this.

Comment 5 Arjan van de Ven 2002-03-05 09:35:27 UTC
"XT-PIC" sounds like the mptable is defective.....

Comment 6 Arjan van de Ven 2002-03-05 09:52:34 UTC
Maybe I'm reading things very wrong, but the megaraid is on pci bus 3 and the
mptable has no info for bus 3....

Comment 7 Tesfamariam Michael 2002-03-05 17:47:40 UTC
IRQ11 isn't mapped in the 'IRQ to pin mapping' but megaraid is trying to use 

Comment 8 Tesfamariam Michael 2002-03-07 18:52:41 UTC
On Discovery system, only slots 1 and 4 work (counting from bottom up), all the 
other slots have this problem. Attached is the mptable dump with PERC3/DC in 
the top slot. I will see if the patch Matt created for 60754 solves this issue.

Comment 9 Tesfamariam Michael 2002-03-07 18:54:41 UTC
Created attachment 47780 [details]
mptable dump of Discovery with PERC3/DC on the top slot

Comment 10 Tesfamariam Michael 2002-03-07 19:34:00 UTC
Created attachment 47781 [details]
mptable dump of Discovery on 4th slot

Comment 11 Arjan van de Ven 2002-03-08 13:32:51 UTC
Interesting how the mptable for the working case DOES have an entry for bus 3....

Comment 12 Matt Domsch 2002-03-08 18:41:00 UTC
FWIW, simply bumping up the values of MAX_MP_BUSSES, MAX_IRQ_SOURCE, and 
MAX_APICS from 32, 128, 16  to 128, 256, 64 respectively appears to solve the 
problems on Discovery.  Tesfamariam will test on Boxter.

I find this strange, because the MP tables on Discovery don't ever reach the 
lower limits on these arrays.  I'm hoping the patch in #60754 will solve this 
on Discovery and Boxter too, but unclear why.

If this does indeed solve the problem, we may like to see an errata kernel for 
7.2 released (perhaps concurrent/identical to the 7.3 release) which we can 
recommend customers with 7.2 upgrade to.

Comment 13 Tesfamariam Michael 2002-03-08 20:15:27 UTC
Pumping these numbers up DOESN'T solve this Boxster with PERC3 in the middle slot.

Comment 14 Arjan van de Ven 2002-03-08 20:20:49 UTC
Interesting question: does the same situation work with Windows NT4
(not W2K or XP) ?
if not... then it *really* looks like a bios bug

Comment 15 Matt Domsch 2002-03-09 00:37:10 UTC
Discovery is solved with the "count the MP table entries properly" patch, so 
it's stuff is unrelated to this issue.  Boxter issue remains.  Still looks like 
an MP table bug in BIOS, so changing back to NEEDINFO until we resolve 
definitively with BIOS.  Other systems list PERC3 cards in MP table.  Boxter 
doesn't (and the BIOS guy thinks that's correct).  Apparently not. :-)

Comment 16 Matt Domsch 2002-03-12 21:33:52 UTC
BIOS team investigated, created a test bios (that looks behind transparent 
bridges for devices on cards in slot 2) and puts an entry in the MP table now.  
This will be incorproated into BIOS X10.  Closing.

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