On 10/8/20 1:54 PM, Mike Christie wrote:
> On 10/8/20 12:11 PM, Mike Christie wrote:
>> On 9/25/20 1:41 PM, ldun...@suse.com wrote:
>>> From: Lee Duncan
>>>
>>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>>> user-land iscsid daemon instead of handled in the kernel,
>>> as they should
>>> Mike Christie schrieb am 08.10.2020 um 22:54
>>> in
Nachricht <47eca384-b54e-63cc-0f84-7ed6501f4...@oracle.com>:
> On 10/8/20 12:11 PM, Mike Christie wrote:
>> On 9/25/20 1:41 PM, ldun...@suse.com wrote:
>>> From: Lee Duncan
>>>
>>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
On 10/8/20 12:11 PM, Mike Christie wrote:
> On 9/25/20 1:41 PM, ldun...@suse.com wrote:
>> From: Lee Duncan
>>
>> iSCSI NOPs are sometimes "lost", mistakenly sent to the
>> user-land iscsid daemon instead of handled in the kernel,
>> as they should be, resulting in a message from the daemon like:
On 9/25/20 1:41 PM, ldun...@suse.com wrote:
> From: Lee Duncan
>
> iSCSI NOPs are sometimes "lost", mistakenly sent to the
> user-land iscsid daemon instead of handled in the kernel,
> as they should be, resulting in a message from the daemon like:
>
>> iscsid: Got nop in, but kernel supports
On 9/25/20 11:41 AM, ldun...@suse.com wrote:
> From: Lee Duncan
>
> iSCSI NOPs are sometimes "lost", mistakenly sent to the
> user-land iscsid daemon instead of handled in the kernel,
> as they should be, resulting in a message from the daemon like:
>
>> iscsid: Got nop in, but kernel supports
From: Lee Duncan
iSCSI NOPs are sometimes "lost", mistakenly sent to the
user-land iscsid daemon instead of handled in the kernel,
as they should be, resulting in a message from the daemon like:
> iscsid: Got nop in, but kernel supports nop handling.
This can occur because of the forward- and
