Patch to auto-load MSFT PV NIC driver
ksrinivasan at novell.com
Tue May 11 13:55:08 UTC 2010
>>> On 5/10/2010 at 1:21 PM, in message <20100510172125.GA1482 at kroah.com>, Greg KH
<greg at kroah.com> wrote:
> On Mon, May 10, 2010 at 05:05:02PM +0000, Hank Janssen wrote:
>> >Sent: Saturday, May 08, 2010 7:27 AM - Hank Janssen
>> >>On Sat, May 08, 2010 at 01:52:01PM +0000, Hank Janssen wrote:>
>> >> I am not sure if this is the right approach. hv_netvsc takes a dependency
> on hv_vmbus.
>> >> hv_vmbus does have the same DMI detection logic in it. But unless hv_vmbus
> has loaded
>> >> up competely, hv_netvsc will fail on loadup. And I do not think we can
> guarantee that
>> >> hv_vmbus has loaded yet.
>> >Yes you can, the dependancies in the module will take care of it. Try
>> >it, if you try to load the hv_netvsc module before hv_vmbus, modprobe
>> >will load hv_vmbus first.
>> In my testing I have seen issues with timing. It takes a little while for
> VMBus to start
>> getting the initialization taken care of with Hyper-V. And I have seen netvsc
> error with
>> unresolved symbols because vmbus had not completed the initialization yet.
> Odd, that shouldn't happen, unless you are loading modules in parallel.
This is indeed strange. Given the module dependency, modprobe is supposed to load all the dependencies first before loading the dependent module. I am wondering if there is some other race in the modules that may be causing this problem.
> If we switch to a proper discovery type bus, this should not be an
> greg k-h
More information about the devel