WARNING - OLD ARCHIVES

This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
   
 
 
Xen 
 
Home Products Support Community News
 
   
 

xen-devel

Re: [Xen-devel] PCI hotplug problem

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 <rafal@xxxxxxxxxxxxxxxxxxxxxx>
--- 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);


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

<Prev in Thread] Current Thread [Next in Thread>