| Message ID | 3162da18-462c-72b4-f8f0-eef896c6b162@xenosoft.de (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [Virtual,ppce500] virtio_gpu virtio0: swiotlb buffer is full | expand |
Hello I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the VirtIO-GPU (see below) still exists. Therefore we still need the patch (see below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. Could you please check the first bad commit? Thanks Christian On 12 August 2020 at 3:09 pm, Christian Zigotzky wrote: > Hello Daniel, > > The VirtIO-GPU doesn't work anymore with the latest Git kernel in a > virtual e5500 PPC64 QEMU machine [1,2] after the commit "drm/virtio: > Call the right shmem helpers". [3] > The kernel 5.8 works with the VirtIO-GPU in this virtual machine. > > I bisected today [4]. > > Result: drm/virtio: Call the right shmem helpers ( > d323bb44e4d23802eb25d13de1f93f2335bd60d0) [3] is the first bad commit. > > I was able to revert the first bad commit. [5] After that I compiled a > new kernel again. Then I was able to boot Linux with this kernel in a > virtual e5500 PPC64 QEMU machine with the VirtIO-GPU. > > I created a patch. [6] With this patch I can use the VirtIO-GPU again. > > Could you please check the first bad commit? > > Thanks, > Christian > > [1] QEMU command: qemu-system-ppc64 -M ppce500 -cpu e5500 -enable-kvm > -m 1024 -kernel uImage -drive > format=raw,file=fienix-soar_3.0-2020608-net.img,index=0,if=virtio -nic > user,model=e1000 -append "rw root=/dev/vda2" -device virtio-vga > -device virtio-mouse-pci -device virtio-keyboard-pci -device > pci-ohci,id=newusb -device usb-audio,bus=newusb.0 -smp 4 > > [2] Error messages: > > virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 > (slots), used 0 (slots) > BUG: Kernel NULL pointer dereference on read at 0x00000010 > Faulting instruction address: 0xc0000000000c7324 > Oops: Kernel access of bad area, sig: 11 [#1] > BE PAGE_SIZE=4K PREEMPT SMP NR_CPUS=4 QEMU e500 > Modules linked in: > CPU: 2 PID: 1678 Comm: kworker/2:2 Not tainted > 5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty #1 > Workqueue: events .virtio_gpu_dequeue_ctrl_func > NIP: c0000000000c7324 LR: c0000000000c72e4 CTR: c000000000462930 > REGS: c00000003dba75e0 TRAP: 0300 Not tainted > (5.9-a3_A-EON_X5000-11735-g06a81c1c7db9-dirty) > MSR: 0000000090029000 <CE,EE,ME> CR: 24002288 XER: 00000000 > DEAR: 0000000000000010 ESR: 0000000000000000 IRQMASK: 0 > GPR00: c0000000000c6188 c00000003dba7870 c0000000017f2300 > c00000003d893010 > GPR04: 0000000000000000 0000000000000001 0000000000000000 > 0000000000000000 > GPR08: 0000000000000000 0000000000000000 0000000000000000 > 7f7f7f7f7f7f7f7f > GPR12: 0000000024002284 c00000003fff9200 c00000000008c3a0 > c0000000061566c0 > GPR16: 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > GPR20: 0000000000000000 0000000000000000 0000000000000000 > 0000000000000000 > GPR24: 0000000000000001 0000000000110000 0000000000000000 > 0000000000000000 > GPR28: c00000003d893010 0000000000000000 0000000000000000 > c00000003d893010 > NIP [c0000000000c7324] .dma_direct_unmap_sg+0x4c/0xd8 > LR [c0000000000c72e4] .dma_direct_unmap_sg+0xc/0xd8 > Call Trace: > [c00000003dba7870] [c00000003dba7950] 0xc00000003dba7950 (unreliable) > [c00000003dba7920] [c0000000000c6188] .dma_unmap_sg_attrs+0x5c/0x98 > [c00000003dba79d0] [c0000000005cd438] > .drm_gem_shmem_free_object+0x98/0xcc > [c00000003dba7a50] [c0000000006af5b4] > .virtio_gpu_cleanup_object+0xc8/0xd4 > [c00000003dba7ad0] [c0000000006ad3bc] .virtio_gpu_cmd_unref_cb+0x1c/0x30 > [c00000003dba7b40] [c0000000006adab8] > .virtio_gpu_dequeue_ctrl_func+0x208/0x28c > [c00000003dba7c10] [c000000000086b70] .process_one_work+0x1a4/0x258 > [c00000003dba7cb0] [c0000000000870f4] .worker_thread+0x214/0x284 > [c00000003dba7d70] [c00000000008c4f0] .kthread+0x150/0x158 > [c00000003dba7e20] [c00000000000082c] .ret_from_kernel_thread+0x58/0x60 > Instruction dump: > f821ff51 7cb82b78 7cdb3378 4e000000 7cfa3b78 3bc00000 7f9ec000 41fc0014 > 382100b0 81810008 7d808120 48bc1ba8 <e93d0010> ebfc0248 833d0018 7fff4850 > ---[ end trace f28d194d9f0955a8 ]--- > > virtio_gpu virtio0: swiotlb buffer is full (sz: 4096 bytes), total 0 > (slots), used 0 (slots) > virtio_gpu virtio0: swiotlb buffer is full (sz: 16384 bytes), total 0 > (slots), used 0 (slots) > > --- > > [3] > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=d323bb44e4d23802eb25d13de1f93f2335bd60d0 > > [4] https://forum.hyperion-entertainment.com/viewtopic.php?p=51377#p51377 > > [5] git revert d323bb44e4d23802eb25d13de1f93f2335bd60d0 //Output: > [master 966950f724e4] Revert "drm/virtio: Call the right shmem > helpers" 1 file changed, 1 insertion(+), 1 deletion(-) > > [6] > diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c > b/drivers/gpu/drm/virtio/virtgpu_object.c > index 6ccbd01cd888..346cef5ce251 100644 > --- a/drivers/gpu/drm/virtio/virtgpu_object.c > +++ b/drivers/gpu/drm/virtio/virtgpu_object.c > @@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct > virtio_gpu_device *vgdev, > if (ret < 0) > return -EINVAL; > > - shmem->pages = drm_gem_shmem_get_pages_sgt(&bo->base.base); > + shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base); > if (!shmem->pages) { > drm_gem_shmem_unpin(&bo->base.base); > return -EINVAL; > ---
On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: > Hello > > I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the > VirtIO-GPU (see below) still exists. Therefore we still need the patch (see > below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which in turn should bring it to 5.9-rc2 or -rc3. take care, Gerd
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: > On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: >> Hello >> >> I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the >> VirtIO-GPU (see below) still exists. Therefore we still need the patch (see >> below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. > It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). > > Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which > in turn should bring it to 5.9-rc2 or -rc3. > > take care, > Gerd > Thank you!
On 18 August 2020 at 10:18 am, Gerd Hoffmann wrote: > On Mon, Aug 17, 2020 at 11:19:58AM +0200, Christian Zigotzky wrote: >> Hello >> >> I compiled the RC1 of kernel 5.9 today. Unfortunately the issue with the >> VirtIO-GPU (see below) still exists. Therefore we still need the patch (see >> below) for using the VirtIO-GPU in a virtual e5500 PPC64 QEMU machine. > It is fixed in drm-misc-next (commit 51c3b0cc32d2e17581fce5b487ee95bbe9e8270a). > > Will cherry-pick into drm-misc-fixes once the branch is 5.9-based, which > in turn should bring it to 5.9-rc2 or -rc3. > > take care, > Gerd > Hello Gerd, I compiled a new kernel with the latest DRM misc updates today. The patch is included in these updates. This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine on my X5000. Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with a resolution of 640x480. If I set a higher resolution then the guest disables the monitor. I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. Please check the latest DRM updates. Thanks, Christian
On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: > Hello Gerd, > > I compiled a new kernel with the latest DRM misc updates today. The patch is > included in these updates. > > This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine > on my X5000. > > Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with > a resolution of 640x480. If I set a higher resolution then the guest > disables the monitor. > I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. > > Please check the latest DRM updates. https://patchwork.freedesktop.org/patch/385980/ (tests & reviews & acks are welcome) HTH, Gerd
On 19 August 2020 at 06:35 am, Gerd Hoffmann wrote: > On Tue, Aug 18, 2020 at 04:41:38PM +0200, Christian Zigotzky wrote: >> Hello Gerd, >> >> I compiled a new kernel with the latest DRM misc updates today. The patch is >> included in these updates. >> >> This kernel works with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine >> on my X5000. >> >> Unfortunately I can only use the VirtIO-GPU (Monitor: Red Hat, Inc. 8") with >> a resolution of 640x480. If I set a higher resolution then the guest >> disables the monitor. >> I can use higher resolutions with the stable kernel 5.8 and the VirtIO-GPU. >> >> Please check the latest DRM updates. > https://patchwork.freedesktop.org/patch/385980/ > > (tests & reviews & acks are welcome) > > HTH, > Gerd > Hello Gerd, I compiled a new RC1 with our patches today. With these patches, the VirtIO-GPU works without any problems. I can use higher resolutions again. Screenshot of the RC1-3 with the VirtIO-GPU in a virtual e5500 QEMU/KVM HV machine on my X5000: https://i.pinimg.com/originals/4f/b0/14/4fb01476edd7abe6be1e1203a8e7e152.png Thanks a lot for your help! Cheers, Christian
diff --git a/drivers/gpu/drm/virtio/virtgpu_object.c b/drivers/gpu/drm/virtio/virtgpu_object.c index 6ccbd01cd888..346cef5ce251 100644 --- a/drivers/gpu/drm/virtio/virtgpu_object.c +++ b/drivers/gpu/drm/virtio/virtgpu_object.c @@ -150,7 +150,7 @@ static int virtio_gpu_object_shmem_init(struct virtio_gpu_device *vgdev, if (ret < 0) return -EINVAL; - shmem->pages = drm_gem_shmem_get_pages_sgt(&bo->base.base); + shmem->pages = drm_gem_shmem_get_sg_table(&bo->base.base); if (!shmem->pages) { drm_gem_shmem_unpin(&bo->base.base);