From mboxrd@z Thu Jan 1 00:00:00 1970 From: Dheeraj CVR Subject: Re: [BUGREPORT] Intel X58 Boards don't boot after "iommu/vt-d: Make root entry visible for hardware right after allocation" Date: Thu, 16 Jun 2016 10:26:20 +0400 Message-ID: References: <20160425110151.GE17926@8bytes.org> <20160615161149.GJ13971@8bytes.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="===============1832928553645192621==" Return-path: In-Reply-To: <20160615161149.GJ13971-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org Errors-To: iommu-bounces-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org To: Joerg Roedel Cc: iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA@public.gmane.org List-Id: iommu@lists.linux-foundation.org --===============1832928553645192621== Content-Type: multipart/alternative; boundary=001a113f91e0096d1705355f518d --001a113f91e0096d1705355f518d Content-Type: text/plain; charset=UTF-8 I have added some debugging code to see where exactly the hang happens. The set_root_entry call works fine without any issues as you have expected. However, the hang happens when calling flush_context. flush_context -> qi_flush_context -> qi_submit_sync The loop "while (qi->desc_status[wait_index] != QI_DONE) {}" in "qi_submit_sync" executes indefinitely and the control doesn't break. Hence, "iommu->flush.flush_context()" never returns. Tested on 2 X58 Motherboards and both hang at the same place with intel_iommu=on. Hope this helps. On Wed, Jun 15, 2016 at 8:11 PM, Joerg Roedel wrote: > On Fri, Apr 29, 2016 at 04:41:23PM +0400, Dheeraj CVR wrote: > > Hi Joerg, > > > > Did you find time to have a look at the dmesg that I have sent to you in > the > > earlier email? Please let me know if you need any more debugging info to > > diagnose this issue. > > Yes, I had a look at the dmesg and went through the code again. I have > no clue yet why that commit causes the issue on your machine. Between > the two places in the code where the set_root_entry calls are/were, > there are no other things going on with the iommu hardware, so it > shouldn't matter when setting the root entry happens earlier. > > Can you try to track down (with some debug code) exactly where it is > hanging? That might bring some more light into the issue. > > > > Joerg > > -- Regards, Dheeraj CVR. --001a113f91e0096d1705355f518d Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
I have added some debuggi= ng code to see where exactly the hang happens. The=C2=A0set_root_entry call works fine without any issues as = you have expected. However, the hang happens when calling flush_context.

flush_context -> qi_flush_context -> qi_submit_= sync

= The loop &quo= t;while (qi->desc_status[wait_index] !=3D QI_DONE) {}" in "qi_= submit_sync" executes indefinitely and the control doesn't break. = Hence, "iommu->flush.flush_context()" never returns.
Tested on 2 X58 Motherboards and both hang at the same place with inte= l_iommu=3Don.

Hope this helps.

On Wed, Jun 15, 2016 at 8:1= 1 PM, Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org> wrote:
On Fri, Apr 29, 2016 at 04:41:23PM +0400, = Dheeraj CVR wrote:
> Hi=C2=A0Joerg,
>
> Did you find time to have a look at the dmesg that I have sent to you = in the
> earlier email? Please let me know if you need any more debugging info = to
> diagnose this issue.

Yes, I had a look at the dmesg and went through the code again. I ha= ve
no clue yet why that commit causes the issue on your machine. Between
the two places in the code where the set_root_entry calls are/were,
there are no other things going on with the iommu hardware, so it
shouldn't matter when setting the root entry happens earlier.

Can you try to track down (with some debug code) exactly where it is
hanging? That might bring some more light into the issue.



=C2=A0 =C2=A0 =C2=A0 =C2=A0 Joerg




--
Regards,
Dheeraj CVR.
--001a113f91e0096d1705355f518d-- --===============1832928553645192621== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============1832928553645192621==--