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 <james.smart@emulex.com> 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.