https://bugzilla.novell.com/show_bug.cgi?id=466431
User james.smart@emulex.com added comment
https://bugzilla.novell.com/show_bug.cgi?id=466431#c14
--- Comment #14 from James Smart 2009-01-27 11:53:21 MST ---
Thank You. So the problem is related to whether we come up with MSI enabled or
not. This is one of the differences between 8.2.7 and 8.2.8.x. The later
revisions attempt to come up MSI/MSI-X by default, rather than making it an
admin option.
There are a lot of broken MSI/MSIX chipsets/platforms that say they support
MSI/MSI-X. So, in driver rev 8.2.8.6, we always validate we can have an
interrupt delivered via MSI/MSIX before sticking with it. It appears that on
this system, that indeed works as we stay MSI-based.
What's interesting is - the place where this fails, the driver isn't depending
on interrupts - it's polling for X amount of time, and only if the time expires
does the failure path occur. I'm speculating, but I believe that there may be
some platform post-processing of MSI interrupt that is locking up the cpu and
disrupting the timer logic that the driver is depending on, thus it ends up
failing the attachment.
One thing we would like is for you to test our latest 8.2.8.x version. I will
upload it shortly.
If the latest revision is still not functional - the way I would recommend
resolving this is to release note the failure, symptoms, and the
"lpfc_use_msi=0" workaround.
--
Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.