Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 24 Apr 2018 03:06:28 +0000
From:      bugzilla-noreply@freebsd.org
To:        virtualization@FreeBSD.org
Subject:   [Bug 226583] FreeBSD VM on Hyper-V/Azure can't properly detected SCSI disk da2
Message-ID:  <bug-226583-27103-mEPwL668uT@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-226583-27103@https.bugs.freebsd.org/bugzilla/>
References:  <bug-226583-27103@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226583

--- Comment #7 from commit-hook@freebsd.org ---
A commit references this bug:

Author: dexuan
Date: Tue Apr 24 03:06:05 UTC 2018
New revision: 332903
URL: https://svnweb.freebsd.org/changeset/base/332903

Log:
  MFC: 332385

  r332385:
      hyperv/storvsc: storvsc_io_done(): do not use CAM_SEL_TIMEOUT

      CAM_SEL_TIMEOUT was introduced in
      https://reviews.freebsd.org/D7521 (r304251), which claimed:

      "VM shall response to CAM layer with CAM_SEL_TIMEOUT to filter those
      invalid LUNs. Never use CAM_DEV_NOT_THERE which will block LUN scan
      for LUN number higher than 7."

      But it turns out this is not correct:

      I think what really filters the invalid LUNs in r304251 is that:
      before r304251, we could set the CAM_REQ_CMP without checking
      vm_srb->srb_status at all:
      ccb->ccb_h.status |=3D CAM_REQ_CMP.

      r304251 checks vm_srb->srb_status and sets ccb->ccb_h.status properly,
      so the invalid LUNs are filtered.

      I changed my code version to r304251 but replaced the CAM_SEL_TIMEOUT
      with CAM_DEV_NOT_THERE, and I confirmed the invalid LUNs can also be
      filtered, and I successfully hot-added and hot-removed 8 disks to/from
      the VM without any issue.

      CAM_SEL_TIMEOUT has an unwanted side effect -- see cam_periph_error():
      For a selection timeout, we consider all of the LUNs on
      the target to be gone. If the status is CAM_DEV_NOT_THERE,
      then we only get rid of the device(s) specified by the
      path in the original CCB.

      This means: for a VM with a valid LUN on 3:0:0:0, when the VM inquires
      3:0:0:1 and the host reports 3:0:0:1 doesn't exist and storvsc returns
      CAM_SEL_TIMEOUT to the CAM layer, CAM will detech 3:0:0:0 as well: th=
is
      is the bug I reported recently:
      https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D226583

      PR:     226583
      Reviewed by:    mav
      Sponsored by:   Microsoft
      Differential Revision:  https://reviews.freebsd.org/D14690

Changes:
_U  stable/11/
  stable/11/sys/dev/hyperv/storvsc/hv_storvsc_drv_freebsd.c

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-226583-27103-mEPwL668uT>