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: Always. 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
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 IRQ11.
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. :-) -Matt
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. -Matt