On Thu, 24 May 2007 11:07:56 -0500 "Mike Miller (OS Dev)" <[EMAIL PROTECTED]> wrote:
> So I guess I found the answer to my own question. msi_free_irqs was > apparently added > in 2.6.22-something. I don't find it in 2.6.21.2 or anywhere else. So > somebody broke a > couple of things. > The most noticable is cciss hangs after turning on interrupts. The reason for > that is > the kernel now looks at my array of MSI-X vectors in reverse order. We have 4 > ways of > generating an interrupt on Smart Array hw. They are: > > # define DOORBELL_INT 0 > # define PERF_MODE_INT 1 > # define SIMPLE_MODE_INT 2 > # define MEMQ_MODE_INT 3 > > For INTx these four lines are OR'ed together and run to one interrupt pin. > MSI-X > breaks this hardware OR'ing so we must register either all 4 or at the least > the > correct interrupt. When I first submitted the MSI/X support I was registering > all 4. > Someone changed that to only register a single MSI-X vector. That worked fine > until > 2.6.22-something. > Now it appears that the kernel is looking at the array in reverse order. IOW, > I must > register PERF_MODE_INT in order for cciss to work. That's messed up. Anybody > want to > `fess up to making these changes? :) > I'll keep working this, but I'm going to undo someones change when I figure > out where > it's broke. > I'd guess that you're referring to Michael's changes. If you can identify the offending code in a less vague fashion, more confident answers can be given ;) I canot find any sign of anyone altering the IRQ handling in cciss.c after your initial MSI-support merge. But that's perhaps isn't what you meant. it's all rather foggy. Please either quote file-n-line, or grab a copy of git-blame. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
