> > -----Original Message----- > > From: Vitaly Kuznetsov [mailto:vkuznets@xxxxxxxxxx] > > Sent: Friday, February 6, 2015 7:04 AM > > To: Jake Oshins > > Cc: gregkh@xxxxxxxxxxxxxxxxxxx; KY Srinivasan; linux-kernel@xxxxxxxxxxxxxxx; > > devel@xxxxxxxxxxxxxxxxxxxxxx; olaf@xxxxxxxxx; apw@xxxxxxxxxxxxx > > Subject: Re: [PATCH v2 1/1] drivers:hv:vmbus drivers:hv:vmbus Allow for more > > than one MMIO range for children <snip> > > > > 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 I looked at this and I realize that I need to fix this problem structurally. The intent is that VMBus-enumerated paravirtual "devices" suballocate from everything granted to the ACPI node above VMBus, in its _CRS object. But since PCI devices also have to suballocate from those ranges, I need a different approach. I'll work up a fix for this and send it around for review. -- Jake Oshins _______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
