[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 5.10.40 dom0 kernel - nvme: Invalid SGL for payload:131072 nents:13

  • To: Andy Smith <andy@xxxxxxxxxxxxxx>
  • From: Jan Beulich <jbeulich@xxxxxxxx>
  • Date: Wed, 21 Jul 2021 16:49:26 +0200
  • Arc-authentication-results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=suse.com; dmarc=pass action=none header.from=suse.com; dkim=pass header.d=suse.com; arc=none
  • Arc-message-signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=oMwdR2HUqYEVibwbAEUWwZ4aC+hMXmOtWp0nAWRqgeE=; b=d7BEWwHKW4yM9LKFXAUbEfnF/GFV3rD/AW9LL20iaN4DPhRrV32QRqNCHUZnI1tuleBexTloeIgyAxOoooF51ot8uM3eKTQbeiUl6+v6wUG5tfpp7JhvGVZ/ChM3r3IVPUv7OmZqhOnkvIYW1usQE7+3kzr8cVxi9AES/gOWIHPdhG0m1vp0jAQekEGO7X5SF8Wn79nZ4m2bAoRKvFGzZoMgkH/gn6sftzL8smHTzBEubCtktWu7x0HSvlAxcRt/HD1sChu8YRpaZcU2E1S2oiUOz2Fr+pYKdmRH/0n/DM8owSIiWyrxUAFu0kN/ZpVhkaCixAZHjgipctS1uACENw==
  • Arc-seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=TaFY9whsouvz6hI1vXk12Cy0Q0L7B7Bldve8uTEHX/cVfD/k+BfpVgXJuKRlhT/hsXCwG0XtjEaMGD7Ci74VMIhGc0YDDHGvGDMPmj1D6KZg0Lr1d/x0wKG2za3h7uH2AmAC2FG/CbYOatyCd0KokIM4y8iR7Aqhf5ol88wNXH9VCCHDDvLqy7oMZOksQpQ88/52fLgwF5wyq1aUAKjdFfN/Z3fX8hQDa+EvkyA9kIgDquHeJiIb2bsr7KX9hSdRnLs9WpLToE12xARbrYNZ23z6E6gbOg8kNPyOaaJ9z3zzypBdZlypvosRa2qmpZoYRP6mVIHCEKMCpUosZh7WDw==
  • Authentication-results: lists.xenproject.org; dkim=none (message not signed) header.d=none;lists.xenproject.org; dmarc=none action=none header.from=suse.com;
  • Cc: xen-devel@xxxxxxxxxxxxxxxxxxxx
  • Delivery-date: Wed, 21 Jul 2021 14:49:35 +0000
  • List-id: Xen developer discussion <xen-devel.lists.xenproject.org>

On 21.07.2021 16:19, Andy Smith wrote:
> On Wed, Jul 21, 2021 at 10:10:13AM +0200, Jan Beulich wrote:
>> Since xen-blkback only talks in terms of bio-s, I don't think it is
>> the party responsible for honoring such driver restrictions. Instead
>> I'd expect the block layer's bio merging to be where this needs to be
>> observed. Perhaps it simply doesn't expect to be passed requests in
>> multiples of 11 sectors together with the capping at 64k (as said -
>> iirc) and driver restrictions on where splits may occur? And as to
>> earlier Linux versions working - perhaps the merging logic was less
>> aggressive back then?
> I later realised that there was another change in my setup besides
> the kernel version going from 4.19 to 5.10: I gave the dom0 8GiB of
> memory instead of the 3GiB it had before.
> I understand that below 4GiB memory use of swiotlb is disabled so
> all the time previously this was not used, and now is. Perhaps the
> bug is in there?
> I was told that the only simple way on a Xen dom0 to disable use of
> swiotlb would be to set the memory below 4GiB again, so I might try
> that.

I have no idea where you take this 4GiB aspect from. What the kernel
considers "below 4GiB" in its view of the world may be at a much
higher address in system address space. And the mere amount of
memory doesn't matter here at all.

> I was also pointed to this patch as a maybe fix for my issue:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit?id=5f89468e2f060031cd89fd4287298e0eaf246bf6

Yes, this looks possibly related.




Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.