Red Hat Bugzilla – Bug 59926
Hampton on PERC3 in 2nd slot of Boxster hangs
Last modified: 2005-10-31 17:00:50 EST
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):
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
System wont boot
To be able to use PERC3 in any slot.
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
Created attachment 45780 [details]
mptable after megaraid load
/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...
Created attachment 45799 [details]
IRQ dump of RH7.2 using `dump_pirq`
This issue also happens on Discovery system with PERC3/QC. I will identify the
slots and update this.
"XT-PIC" sounds like the mptable is defective.....
Maybe I'm reading things very wrong, but the megaraid is on pci bus 3 and the
mptable has no info for bus 3....
IRQ11 isn't mapped in the 'IRQ to pin mapping' but megaraid is trying to use
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.
Created attachment 47780 [details]
mptable dump of Discovery with PERC3/DC on the top slot
Created attachment 47781 [details]
mptable dump of Discovery on 4th slot
Interesting how the mptable for the working case DOES have an entry for bus 3....
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.
Pumping these numbers up DOESN'T solve this Boxster with PERC3 in the middle slot.
Interesting question: does the same situation work with Windows NT4
(not W2K or XP) ?
if not... then it *really* looks like a bios bug
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. :-)
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.