[PATCH] radeon: avoid boot hang in Xen Dom0

for further investigation, lspci for the offending device says: ATI Technologies Inc RS480 [Radeon Xpress 200G Series] [1002:5954] Fixes: 05082b8bbd "drm/radeon: fix asic initialization for virtualized environments" Signed-off-by: Jan Beulich --- drivers/gpu/drm/radeon/radeon_device.c |

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0

ualized > environments" I may have overlooked a different fix dealing with the problem; if so, I'd appreciate that fix being pointed out. Thanks, Jan > Signed-off-by: Jan Beulich > --- > drivers/gpu/drm/radeon/radeon_device.c |3 ++- > 1 file changed, 2 insertions(+), 1

Ping: [PATCH] radeon: avoid boot hang in Xen Dom0

>>> On 04.11.16 at 15:32, wrote: > On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich wrote: >>>>> On 13.09.16 at 17:54, wrote: >>> While a hard hang in atom_asic_init() likely points at a deeper problem >>> in the driver, restore the capability to bo

[PATCH] drm/mgag200: don't pass NULL file_priv to drm_gem_object_lookup()

bj" is actually needed, adjusting error paths suitably once again. Signed-off-by: Jan Beulich Cc: Daniel Vetter Cc: Thierry Reding --- drivers/gpu/drm/mgag200/mgag200_cursor.c | 18 ++ 1 file changed, 10 insertions(+), 8 deletions(-) --- 4.3-rc6/drivers/gpu/drm/mgag200/mgag

drm/mgag200: don't use uninitialized variables in mga_g200se_set_plls()

in warning that testm/testn are possibly uninitalized at this point, i.e. some change is needed no matter what. Signed-off-by: Jan Beulich Cc: Mathieu Larouche --- drivers/gpu/drm/mgag200/mgag200_mode.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- 4.3-rc6/drivers/gpu/drm/mgag200/mgag

drm/mgag200: don't use uninitialized variables in mga_g200se_set_plls()

>>> On 20.10.15 at 16:47, wrote: > On 19/10/2015 6:29 AM, Jan Beulich wrote: >> --- 4.3-rc6/drivers/gpu/drm/mgag200/mgag200_mode.c >> +++ 4.3-rc6-mgag200-uninit/drivers/gpu/drm/mgag200/mgag200_mode.c >> @@ -194,7 +194,7 @@ static int

[PATCH v2] drm/mgag200: don't use uninitialized variables in mga_g200se_set_plls()

in warning that testm/testn are possibly uninitalized at this point, i.e. some change is needed no matter what. Signed-off-by: Jan Beulich Cc: Mathieu Larouche --- v2: As pointed out by Mathieu, 1 needs to be added to both m and n when consuming them. --- drivers/gpu/drm/mgag200/mgag200_mode.c |

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

>>> On 28.11.17 at 10:12, wrote: > In theory the BIOS would search for address space and won't find > anything, so the hotplug operation should fail even before it reaches > the kernel in the first place. How would the BIOS know what the OS does or plans to do? I

Re: [Xen-devel] [PATCH v9 4/5] x86/PCI: Enable a 64bit BAR on AMD Family 15h (Models 30h-3fh) Processors v5

>>> On 28.11.17 at 11:17, <christian.koe...@amd.com> wrote: > Am 28.11.2017 um 10:46 schrieb Jan Beulich: >>>>> On 28.11.17 at 10:12, <christian.koe...@amd.com> wrote: >>> In theory the BIOS would search for address space and won't find >>

[PATCH] drm/xen: adjust Kconfig

ot;ing the dummy one. Signed-off-by: Jan Beulich --- a/drivers/gpu/drm/xen/Kconfig +++ b/drivers/gpu/drm/xen/Kconfig @@ -1,15 +1,11 @@ # SPDX-License-Identifier: GPL-2.0-only config DRM_XEN - bool "DRM Support for Xen guest OS" - depends on XEN - help -

Re: [PATCH 0/5] xen: cleanup detection of non-essential pv devices

On 22.10.2021 08:47, Juergen Gross wrote: > Today the non-essential pv devices are hard coded in the xenbus driver > and this list is lacking multiple entries. > > This series reworks the detection logic of non-essential devices by > adding a flag for that purpose to struct xenbus_driver. I'm

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"

On 18.10.2022 13:02, Christoph Hellwig wrote: > On Tue, Oct 18, 2022 at 10:57:37AM +0200, Jan Beulich wrote: >> Shouldn't this then be xen_pv_domain() that you use here, and - if you >> really want IS_ENABLED() in addition - CONFIG_XEN_PV? > > I'll need help from people that

Re: i915 "GPU HANG", bisected to a2daa27c0c61 "swiotlb: simplify swiotlb_max_segment"

On 18.10.2022 10:24, Christoph Hellwig wrote: > @@ -127,19 +128,22 @@ static inline unsigned int i915_sg_dma_sizes(struct > scatterlist *sg) > return page_sizes; > } > > -static inline unsigned int i915_sg_segment_size(void) > +static inline unsigned int i915_sg_segment_size(struct

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 16.03.2023 00:25, Stefano Stabellini wrote: > On Wed, 15 Mar 2023, Jan Beulich wrote: >> On 15.03.2023 01:52, Stefano Stabellini wrote: >>> On Mon, 13 Mar 2023, Jan Beulich wrote: >>>> On 12.03.2023 13:01, Huang Rui wrote: >>>>> Xen PVH is

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 12.03.2023 13:01, Huang Rui wrote: > Xen PVH is the paravirtualized mode and takes advantage of hardware > virtualization support when possible. It will using the hardware IOMMU > support instead of xen-swiotlb, so disable swiotlb if current domain is > Xen PVH. But the kernel has no way (yet)

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 15.03.2023 05:14, Huang Rui wrote: > On Wed, Mar 15, 2023 at 08:52:30AM +0800, Stefano Stabellini wrote: >> On Mon, 13 Mar 2023, Jan Beulich wrote: >>> On 12.03.2023 13:01, Huang Rui wrote: >>>> Xen PVH is the paravirtualized mode and takes advantage of hardware &g

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 15.03.2023 01:52, Stefano Stabellini wrote: > On Mon, 13 Mar 2023, Jan Beulich wrote: >> On 12.03.2023 13:01, Huang Rui wrote: >>> Xen PVH is the paravirtualized mode and takes advantage of hardware >>> virtualization support when possible. It will using the hardwar

Re: [RFC PATCH 1/5] x86/xen: disable swiotlb for xen pvh

On 16.03.2023 14:53, Alex Deucher wrote: > On Thu, Mar 16, 2023 at 9:48 AM Juergen Gross wrote: >> >> On 16.03.23 14:45, Alex Deucher wrote: >>> On Thu, Mar 16, 2023 at 3:50 AM Jan Beulich wrote: >>>> >>>> On 16.03.2023 00:25, Stefano Stabelli