On 12/17/2016 01:16 AM, Thierry Reding wrote: > * PGP Signed by an unknown key > > On Wed, Dec 14, 2016 at 11:08:20PM +0900, Alexandre Courbot wrote: >> Forgot to add the most relevant list for this issue (linux-next). >> >> Stephen, maybe you will want to temporarily revert this patch until this >> is cleared? This probably affects other users than DRM. >> >> On 12/13/2016 04:14 PM, Alexandre Courbot wrote: >>> Hi Matthew, >>> >>> Trying the latest -next on the Jetson TK1 board (with two different DRM >>> devices and display and render), I noticed that the GPU device probe >>> always failed with error -ENOSPC. After investigating I figured out that >>> this was due to the minor device allocation failing when a second DRM >>> device is added. >>> >>> More precisely, when drm_minor_alloc() is called with DRM_MINOR_PRIMARY >>> (0) as argument for a second time, the call to idr_alloc() (which has a >>> requested range of 0..64) fails instead of returning 1 as expected. Note >>> that the first call is successful. >>> >>> Reverting "reimplement IDR and IDA using the radix tree" on 20161213's >>> next fixes the issue for me, suggesting a bug may have slipped in there. >>> >>> Not sure how this could be fixed, so reporting the issue for now in case >>> it is not known yet. > > I can confirm Alex' findings, though the symptoms seem to be slightly > different, which may be related to me testing on next-20161216 rather > than next-20161213. > > What I'm seeing is that all drivers get probed correctly, but when an > application tries to open the DRM device files (/dev/dri/card0 in this > case), then all devices of a given minor type disappear. So in my case > upon boot I get this: > > # ls -l /dev/dri/ > total 0 > crw-rw---- 1 root video 226, 0 Dec 16 15:59 card0 > crw-rw---- 1 root video 226, 1 Dec 16 15:59 card1 > crw-rw---- 1 root video 226, 128 Dec 16 15:59 renderD128 > > The modetest program from libdrm is then unable to open any devices: > > # modetest > trying to open device 'i915'...failed > trying to open device 'amdgpu'...failed > trying to open device 'radeon'...failed > trying to open device 'nouveau'...failed > trying to open device 'vmwgfx'...failed > trying to open device 'omapdrm'...failed > trying to open device 'exynos'...failed > trying to open device 'tilcdc'...failed > trying to open device 'msm'...failed > trying to open device 'sti'...failed > trying to open device 'tegra'...failed > trying to open device 'imx-drm'...failed > trying to open device 'rockchip'...failed > trying to open device 'atmel-hlcdc'...failed > trying to open device 'fsl-dcu-drm'...failed > trying to open device 'vc4'...failed > trying to open device 'virtio_gpu'...failed > trying to open device 'mediatek'...failed > no device found > > And after that all of the primary minors are gone: > > # ls -l /dev/dri/ > total 0 > crw-rw---- 1 root video 226, 128 Dec 16 15:59 renderD128 That's exactly what I am also getting with 20161216. As it turns out the patch has changed slightly (my revert did not apply after a rebase), and the symptoms changed against 20161215, but the fix is the same: reverting gives me back a working system. This patch really should be reverted for now. Like Thierry I am available to test further iterations. -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
