From mboxrd@z Thu Jan 1 00:00:00 1970 From: Andrew Cooper Subject: Re: megasas stops I/O when running kernel as dom0 under xen4.1/4.2 Date: Fri, 19 Aug 2011 17:49:39 +0100 Message-ID: <4E4E9423.8010904@citrix.com> References: <4E43E04B.8010401@leuphana.de> <20110811225119.GA3557@dumpdata.com> <4E44EE51.70802@leuphana.de> <201108151149.44053.simon.rowe@eu.citrix.com> <4E4916A3.9070106@leuphana.de> <4E4E56EE.2070801@citrix.com> <4E4E705E.3040505@leuphana.de> <4E4E79E8.3020808@citrix.com> <4E4E913C.40809@leuphana.de> Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-15" Content-Transfer-Encoding: 7bit Return-path: In-Reply-To: <4E4E913C.40809@leuphana.de> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Andreas Olsowski Cc: "xen-devel@lists.xensource.com" List-Id: xen-devel@lists.xenproject.org On 19/08/11 17:37, Andreas Olsowski wrote: > Am 19.08.2011 16:57, Andrew Cooper: > >> >> This further confirms my findings. >> >> Do you mind intserting a call to pci_enable_msi() in the probe function >> and see if that sorts out your two problem cases? >> > > /* Try to enable MSI-X */ > if ((instance->pdev->device != PCI_DEVICE_ID_LSI_SAS1078R) && > (instance->pdev->device != PCI_DEVICE_ID_LSI_SAS1078DE) && > (instance->pdev->device != PCI_DEVICE_ID_LSI_VERDE_ZCR) && > !msix_disable && !pci_enable_msix(instance->pdev, > &instance->msixentry, 1)) > instance->msi_flag = 1; > > /* > > My device is a: > 01:00.0 RAID bus controller: LSI Logic / Symbios Logic MegaRAID SAS > 1078 (rev 04) > > and this excluded for some reason. > There are more references to this particular type of raid controller. > > Can you think of a reason why msi would not work on some specific > harware? > > Anyway since i dont have much C-experience and wouldnt know where to > put " pci_enable_msi() " exactly, i modified the above mentioned code > to just do: > instance->msi_flag = 1; > > I also removed "options megaraid_sas poll_mode_io=1" from the module > options. > > The kernel did not boot properly at that point. > Something about /dev not beeing mounted due to missing device. > Followed by udev not doing much and the system generally doing nothing > that would further the bootup process. > > So i went back to put that module option in again. > > It still did not boot properly, here is some output: > Loading, please wait... > mount: mounting none on /dev failed: No such device > ... > megasas: 00.00.05.30 Tue. Jan. 4 17:00:00 PDT 2011 > megasas: 0x1000:0x0060:0x1028:0x1f0c: bus 1:slot 0:func 0 > megaraid_sas 0000:01:00.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 > megaraid_sas 0000:01:00.0: setting latency timer to 64 > megasas: FW now in Ready state > megasas: cpx is not supported. > megasas: INIT adapter done > ... > and then came the udev failing to load something and basically nothing > happened after that point. > > I guess there really is a good reason not to enable msi for that type > of controller. > > The fact that corresponding problems from not having the module option > do not happen on bare-metal isnt very helpful either. > Especially when you cant test the kernel bare-metal due to the fact > that it wont boot bare-metal anymore ... but i digress. > > I guess an acceptable fix would be to make the module option a default > for those raid controllers in the next version of the megasas modules. > > glad to be of service > > with best regards: > The only change you need to make is in megasas_probe_one() in megaraid_sas_base.c Add a call to pci_enable_msi(pdev) immediately after the current call to pci_set_master(pdev); ~Andrew -- Andrew Cooper - Dom0 Kernel Engineer, Citrix XenServer T: +44 (0)1223 225 900, http://www.citrix.com