From owner-freebsd-xen@FreeBSD.ORG Fri May 15 16:28:56 2015 Return-Path: Delivered-To: freebsd-xen@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [8.8.178.115]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id BB51C213 for ; Fri, 15 May 2015 16:28:56 +0000 (UTC) Received: from SMTP.CITRIX.COM (smtp.citrix.com [66.165.176.89]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (Client CN "mail.citrix.com", Issuer "Cybertrust Public SureServer SV CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 437B011AA for ; Fri, 15 May 2015 16:28:55 +0000 (UTC) X-IronPort-AV: E=Sophos;i="5.13,434,1427760000"; d="scan'208";a="263138072" Message-ID: <55561EBC.8080901@citrix.com> Date: Fri, 15 May 2015 18:28:44 +0200 From: =?UTF-8?B?Um9nZXIgUGF1IE1vbm7DqQ==?= User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:31.0) Gecko/20100101 Thunderbird/31.6.0 MIME-Version: 1.0 To: "Eggert, Lars" CC: "freebsd-xen@freebsd.org" Subject: Re: Xen dom0 "interrupt storm detected on "irq16:"; throttling interrupt source" References: <55531131.7040404@citrix.com> <65D7289A-9261-4F02-88E5-B2D137C268C1@netapp.com> <5553651D.3000400@citrix.com> <5555DFBC.9030306@citrix.com> <683335F9-E04E-4F8C-B1EF-0047E63E00AD@netapp.com> <5555FF4A.8010702@citrix.com> <126FDC37-2822-45DB-9AA6-3C9A03D89959@netapp.com> <55560414.1040002@citrix.com> <91758942-3683-42E5-9B39-66775E48D4DF@netapp.com> In-Reply-To: <91758942-3683-42E5-9B39-66775E48D4DF@netapp.com> Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 8bit X-DLP: MIA2 X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 15 May 2015 16:28:56 -0000 El 15/05/15 a les 16.42, Eggert, Lars ha escrit: > On 2015-5-15, at 16:35, Roger Pau Monné wrote: >> >> Yes, but I've realized that isci for example passes an uint32_t instead >> of an int, so it might be best to set it to 0. > > Here is what I see now: > > isci0: port 0x6000-0x60ff mem 0xde07c000-0xde07ffff,0xddc00000-0xddffffff irq 16 at device 0.0 on pci10 > isci0: attempting to allocate 2 MSI-X vectors (2 supported) > ISCI: isci->num_interrupts: 2 max_msix_messages: 2 > isci: 1:000089 ISCI bus_alloc_resource failed > > The storm is still there. Yes, after looking at the code, isci really needs to check for the return value of pci_alloc_msix, because num_interrupts is not updated if the allocation fails. Following patch should hopefully fix it, please give it a try. Roger. --- diff --git a/sys/dev/isci/isci_interrupt.c b/sys/dev/isci/isci_interrupt.c index 52c64f7..f331f3c 100644 --- a/sys/dev/isci/isci_interrupt.c +++ b/sys/dev/isci/isci_interrupt.c @@ -128,6 +128,7 @@ isci_interrupt_setup(struct isci_softc *isci) isci->controller_count; BOOL use_msix = FALSE; uint32_t force_legacy_interrupts = 0; + int rc; TUNABLE_INT_FETCH("hw.isci.force_legacy_interrupts", &force_legacy_interrupts); @@ -136,8 +137,8 @@ isci_interrupt_setup(struct isci_softc *isci) pci_msix_count(isci->device) >= max_msix_messages) { isci->num_interrupts = max_msix_messages; - pci_alloc_msix(isci->device, &isci->num_interrupts); - if (isci->num_interrupts == max_msix_messages) + rc = pci_alloc_msix(isci->device, &isci->num_interrupts); + if (rc == 0 && isci->num_interrupts == max_msix_messages) use_msix = TRUE; }