that's because some customer modified QEMU and trap each VF's memory access, which cost too much time if using CPU access FB, emmm, I guess we have no better choice by far, do as you suggested, to kill risk the negative effect that we may have no console if ib test failed, I suggest we don't block driver proceeding after ib test failure detected , doable ? ________________________________ å??件人: Christian König <deathsimple at vodafone.de> å??é??æ?¶é?´: 2017å¹´2æ??8æ?¥ 23:59:10 æ?¶ä»¶äºº: Liu, Monk; Michel Dänzer æ??é??: amd-gfx at lists.freedesktop.org 主é¢?: Re: ç?å¤?: ç?å¤?: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error Am 08.02.2017 um 16:53 schrieb Liu, Monk: agreed, why not just use cpu to clear it ? is it because performance ? Pixel Ding removed the CPU clear because "There's a failure caused by this is that handshaking gets timeout of SRIOV virtual function." I can only assume that this is really adding to much delay at bootup. ________________________________ å??件人: Michel Dänzer <michel at daenzer.net><mailto:michel at daenzer.net> å??é??æ?¶é?´: 2017å¹´2æ??8æ?¥ 23:52:02 æ?¶ä»¶äºº: Christian König; Liu, Monk æ??é??: amd-gfx at lists.freedesktop.org<mailto:amd-gfx at lists.freedesktop.org> 主é¢?: Re: ç?å¤?: [PATCH] drm/amdgpu:fix amdgpu_sa_bo_new error On 09/02/17 12:30 AM, Christian König wrote: > The IB test make the decision if the hardware is working or not. > > So they should be the first commands (except for the ring tests) we send > to the hardware. > > When we allocate the fb before the test we send the clear command to the > hardware without knowing if the hardware really works or not. > > Not a big issue, but I think the order makes more sense that way. I just wonder if it's worth all the trouble, just to clear the fbcon buffer[0], if the result is that the console output is delayed, possibly indefinitely. Actually that change is quite beneficial because the IB tests where usually revealing any problem. Not 100% sure, but when we initialize the fb later that might actually allow us to better track such problems down. Going to check that, Christian. [0] We don't have any other hardware acceleration for fbcon, so its BO is only accessed by the CPU and display hardware after this, and has to be pinned in the CPU visible area of VRAM at all times anyway. -- Earthling Michel Dänzer | http://www.amd.com Libre software enthusiast | Mesa and X developer -------------- next part -------------- An HTML attachment was scrubbed... URL: <https://lists.freedesktop.org/archives/amd-gfx/attachments/20170208/f46d7e6f/attachment-0001.html>
