[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <DM2PR0301MB123277EB59B145A3769D04EAAB380@DM2PR0301MB1232.namprd03.prod.outlook.com>
Date: Fri, 6 Feb 2015 16:57:05 +0000
From: Jake Oshins <jakeo@...rosoft.com>
To: Vitaly Kuznetsov <vkuznets@...hat.com>
CC: "gregkh@...uxfoundation.org" <gregkh@...uxfoundation.org>,
KY Srinivasan <kys@...rosoft.com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"devel@...uxdriverproject.org" <devel@...uxdriverproject.org>,
"olaf@...fle.de" <olaf@...fle.de>,
"apw@...onical.com" <apw@...onical.com>
Subject: RE: [PATCH v2 1/1] drivers:hv:vmbus drivers:hv:vmbus Allow for more
than one MMIO range for children
> -----Original Message-----
> From: Vitaly Kuznetsov [mailto:vkuznets@...hat.com]
> Sent: Friday, February 6, 2015 7:04 AM
> To: Jake Oshins
> Cc: gregkh@...uxfoundation.org; KY Srinivasan; linux-kernel@...r.kernel.org;
> devel@...uxdriverproject.org; olaf@...fle.de; apw@...onical.com
> Subject: Re: [PATCH v2 1/1] drivers:hv:vmbus drivers:hv:vmbus Allow for more
> than one MMIO range for children
>
> Jake Oshins <jakeo@...rosoft.com> writes:
>
> > This set of changes finds the _CRS object in the ACPI namespace
> > that contains memory address space descriptors, intended to convey
> > to VMBus which ranges of memory-mapped I/O space are available for
> > child devices, and then builds a resource list that contains all
> > those ranges. Without this change, only some of the memory-mapped
> > I/O space will be available for child devices, and only in some
> > virtual BIOS configurations (Generation 2 VMs).
> >
> > This patch has been updated with feedback from Vitaly Kuznetsov.
> > Cleanup is now driven by the acpi remove callback function.
>
> Sorry for beeing late with this message but I'm seeing issues with this
> commit. I added some debug to figure out what's going on and here is
> what I see:
>
> With Gen1 VM we end up doing request_resource for two ranges:
> f8000000 - fffbffff
> fe0000000 - fffefffff
>
> request_resource() fails (as we already have PCI device at f8000000 I
> suppose?) but we don't check the return value. release_resource on
> module unload crashes the kernel:
> [ 78.314344] BUG: unable to handle kernel NULL pointer dereference at
> 0000000000000030
> [ 78.315021] IP: [<ffffffff8107fac5>] release_resource+0x25/0x90
> [ 78.315021] PGD 78c67067 PUD 78c5a067 PMD 0
> [ 78.315021] Oops: 0000 [#1] SMP DEBUG_PAGEALLOC
> [ 78.315021] Modules linked in: hv_vmbus(-)
> ...
> If I'm not mistaken, before the change we didn't do any
> request_resource() for Gen1 VMs at all.
>
> With Gen2 VM we do request_resource for fe0000000 - fffffffff range
> only, that means this commit doesn't change anything.
>
> Can you please take a look? I'd like to help but I don't completely
> understand the essense of the change wrt Gen1 VMs with PCI devices.
>
I'll take a look immediately.
Thanks,
Jake
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists