From mboxrd@z Thu Jan 1 00:00:00 1970 From: Rafal Wojtczuk Subject: Re: PCI hotplug problem Date: Fri, 1 Oct 2010 16:24:12 +0200 Message-ID: <20101001142412.GD1201@email> References: <20100916114424.GE2621@email> <20100924142458.GB867@email> <20100927170705.GD4741@dumpdata.com> Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-2 Return-path: Content-Disposition: inline In-Reply-To: <20100927170705.GD4741@dumpdata.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Konrad Rzeszutek Wilk Cc: "xen-devel@lists.xensource.com" , Keir Fraser List-Id: xen-devel@lists.xenproject.org On Mon, Sep 27, 2010 at 01:07:05PM -0400, Konrad Rzeszutek Wilk wrote: > > The idea of using PCI hotplug is nice, however, PCI hotplug does not seem to > > work with the used setup (xen-3.4.3, all 64bit). Hot-unplug works, however the > > following hotplug makes the driver domain kernel spit out the following: [cut] > > Sep 24 09:46:15 localhost kernel: [ 126.846523] iwlagn 0000:00:01.0: device > > not available (can't reserve [mem 0xf8000000-0xf8001fff 64bit]) [cut] > > Others seem to experience similar problems (e.g. > > http://permalink.gmane.org/gmane.comp.emulators.xen.devel/80766). Does > > anyone know the solution ? > > I had an off-mailing list conversation with that fellow and I spun out > a bunch of patches to fix his issue. > > You need these patches: > Konrad Rzeszutek Wilk (3): > xen-pcifront: Enforce scanning of device functions on initial execution. > xen-pcifront: Claim PCI resources before going live. > xen-pcifront: Don't race with udev when discovering new devices. > > I think they are in Jeremy's upstream tree.. ah, right you guys aren't using > Jeremy's tree. > > Get them from: git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git > > pv/pcifront-2.6.34 Indeed these patches help, thank you. There is one more problem with the linux-2.6.18-xen.hg pcifront (that affect derived code, e.g. OpenSUSE kernel, too). unbind_from_irqhandler() is mistakenly passed evtchn, instead of irq. Compare line 68 of http://xenbits.xensource.com/linux-2.6.18-xen.hg?file/a66a7c64b1d0/drivers/xen/pcifront/xenbus.c with pvops equivalent http://git.kernel.org/?p=linux/kernel/git/jeremy/xen.git;a=blob;f=drivers/pci/xen-pcifront.c;h=10868aeae818d69980b8519f8a77b38d6ab58a4c;hb=HEAD#l758 The following patch helps. Regards, Rafal Wojtczuk unbind_from_irqhandler takes irq, not evtchn, as its first argument. Signed-off-by: Rafal Wojtczuk --- linux-2.6.34.1/drivers/xen/pcifront/xenbus.c.orig 2010-09-29 16:47:39.961674359 +0200 +++ linux-2.6.34.1/drivers/xen/pcifront/xenbus.c 2010-09-29 16:47:49.458675391 +0200 @@ -61,7 +61,7 @@ static void free_pdev(struct pcifront_de /*For PCIE_AER error handling job*/ flush_scheduled_work(); - unbind_from_irqhandler(pdev->evtchn, pdev); + unbind_from_irqhandler(irq_from_evtchn(pdev->evtchn), pdev); if (pdev->evtchn != INVALID_EVTCHN) xenbus_free_evtchn(pdev->xdev, pdev->evtchn);