ft.com>; Alex Ng (LIS) <ale...@microsoft.com>;
> Radim Krcmar <rkrc...@redhat.com>; Cathy Avery <cav...@redhat.com>
> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>
> KY Srinivasan <k...@microsoft.com> writes:
>
> >>
o: KY Srinivasan
> >> Cc: de...@linuxdriverproject.org; linux-kernel@vger.kernel.org; Haiyang
> >> Zhang ; Alex Ng (LIS)
> ;
> >> Radim Krcmar ; Cathy Avery
>
> >> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> >>
> &
x-kernel@vger.kernel.org; Haiyang
>> Zhang <haiya...@microsoft.com>; Alex Ng (LIS) <ale...@microsoft.com>;
>> Radim Krcmar <rkrc...@redhat.com>; Cathy Avery <cav...@redhat.com>
>> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenari
x Ng (LIS) ;
>> Radim Krcmar ; Cathy Avery
>> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>>
>> KY Srinivasan writes:
>>
>> >> -Original Message-
>> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
x-kernel@vger.kernel.org; Haiyang
>> Zhang <haiya...@microsoft.com>; Alex Ng (LIS) <ale...@microsoft.com>;
>> Radim Krcmar <rkrc...@redhat.com>; Cathy Avery <cav...@redhat.com>
>> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenari
x Ng (LIS) ;
>> Radim Krcmar ; Cathy Avery
>> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>>
>> KY Srinivasan writes:
>>
>> >> -Original Message-
>> >> From: Vitaly Kuznetsov [mailto:vkuzn...@redhat.com]
ft.com>; Alex Ng (LIS) <ale...@microsoft.com>;
> Radim Krcmar <rkrc...@redhat.com>; Cathy Avery <cav...@redhat.com>
> Subject: Re: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>
> KY Srinivasan <k...@microsoft.com> writes:
>
> >>
e...@linuxdriverproject.org
> >> Cc: linux-kernel@vger.kernel.org; KY Srinivasan ;
> >> Haiyang Zhang ; Alex Ng (LIS)
> >> ; Radim Krcmar ; Cathy
> >> Avery
> >> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
> >>
> >&
t;k...@microsoft.com>;
>> Haiyang Zhang <haiya...@microsoft.com>; Alex Ng (LIS)
>> <ale...@microsoft.com>; Radim Krcmar <rkrc...@redhat.com>; Cathy
>> Avery <cav...@redhat.com>
>> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>
x Ng (LIS)
>> ; Radim Krcmar ; Cathy
>> Avery
>> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>>
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending
>> C
Radim Krcmar writes:
> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
>> from. vmbus_wait_for_unload() doesn't account for the fact that
Radim Krcmar writes:
> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
>> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
>> from. vmbus_wait_for_unload() doesn't account for the fact that in case
>> we're
.com>; Alex Ng (LIS)
> <ale...@microsoft.com>; Radim Krcmar <rkrc...@redhat.com>; Cathy
> Avery <cav...@redhat.com>
> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is
Avery
> Subject: [PATCH] Drivers: hv: vmbus: handle various crash scenarios
>
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
> delivered to CPU0 regardless of what CPU we're sending
> CHANNELMSG_UNLOAD
> from. vmbus_wait_for_unload() doesn't account for the
2016-03-18 16:53+0100, Vitaly Kuznetsov:
> Radim Krcmar writes:
>> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>>
>> (I'm not a huge fan of the unloaded variable; what about remembering the
>> header/msgtype here
2016-03-18 16:53+0100, Vitaly Kuznetsov:
> Radim Krcmar writes:
>> 2016-03-18 13:33+0100, Vitaly Kuznetsov:
>>> @@ -530,9 +542,17 @@ static void vmbus_wait_for_unload(void)
>>
>> (I'm not a huge fan of the unloaded variable; what about remembering the
>> header/msgtype here ...
>>
>>>
Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
from. vmbus_wait_for_unload() doesn't account for the fact that in case
we're crashing on some other CPU and CPU0 is still alive and operational
Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
from. vmbus_wait_for_unload() doesn't account for the fact that in case
we're crashing on some other CPU and CPU0 is still alive and operational
2016-03-18 13:33+0100, Vitaly Kuznetsov:
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
> from. vmbus_wait_for_unload() doesn't account for the fact that in case
> we're crashing on some other CPU and
2016-03-18 13:33+0100, Vitaly Kuznetsov:
> Kdump keeps biting. Turns out CHANNELMSG_UNLOAD_RESPONSE is always
> delivered to CPU0 regardless of what CPU we're sending CHANNELMSG_UNLOAD
> from. vmbus_wait_for_unload() doesn't account for the fact that in case
> we're crashing on some other CPU and
20 matches
Mail list logo