>>> On 04.11.16 at 15:32, <alexdeucher@xxxxxxxxx> wrote: > On Fri, Nov 4, 2016 at 6:44 AM, Jan Beulich <JBeulich@xxxxxxxx> 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 boot a Xen Dom0 by simply >>> avoiding the call there: Other than for Xen DomU, Dom0 owning a device >>> does not really mean is has got passed through to it. >>> >>> In case it is of interest 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" >> >> I may have overlooked a different fix dealing with the problem; if >> so, I'd appreciate that fix being pointed out. > > Already fixed: > http://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=88 > 4031f0aacf57dad1575f96714efc80de9b19cc Hmm, that indeed should make the immediate problem go away. Nevertheless I do think that Xen Dom0 should be treated just like native here. Only DomU should be forced through that extra path. I did also notice that the equivalent function under amdgpu/ has gone away again during the 4.9 merge window... Jan _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
