Re: DRM/KMS: vmwgfx driver is now available

On 7/23/23 06:06, Taylor R Campbell wrote: Date: Sun, 23 Jul 2023 00:47:39 +0900 From: PHO On 7/22/23 22:23, Taylor R Campbell wrote: For that matter, do we even need a new allocator here? Can we just do a new bus_dmamem_alloc/load for each one? Sure, but I fear that would degrade the

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 23 Jul 2023 00:47:39 +0900 > From: PHO > > On 7/22/23 22:23, Taylor R Campbell wrote: > > For that matter, do we even need a new allocator here? Can we just do > > a new bus_dmamem_alloc/load for each one? > > Sure, but I fear that would degrade the performance. Any idea how

Re: ALTQ cannot be stopped Was: Fwd: 10-BETA : some network issues

> Date: Sat, 22 Jul 2023 17:14:11 +0200 > From: BERTRAND Joël > > I have rebuilt my tree, started and stopped altqd. Excellent, thanks! Can you either: (a) send me a tarball of your altqd binary together with all the shared libraries and .debug files that gdb mentioned, and together

Re: ALTQ cannot be stopped Was: Fwd: 10-BETA : some network issues

I have rebuilt my tree, started and stopped altqd. legendre# gdb /usr/sbin/altqd 22610 GNU gdb (GDB) 11.0.50.20200914-git Copyright (C) 2020 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later This is free software: you are free to

Re: DRM/KMS: vmwgfx driver is now available

On Sun, Jul 23, 2023 at 01:20:31AM +0900, PHO wrote: > That still means we have to allocate the real framebuffer in VRAM doesn't > it? Unfortunately we just can't do it in the case of vmwgfx. I'm not sure (not very fammiliar with this code) - there is a WSFB_VRAM_IS_RAM flag (used e.g. in

Re: DRM/KMS: vmwgfx driver is now available

On 7/23/23 00:09, Martin Husemann wrote: On Sat, Jul 22, 2023 at 01:23:39PM +, Taylor R Campbell wrote: Is there a way we could just use or add a simple hook in genfb or rasops for when there's dirty areas to update, so we don't have to copy & paste all of that cruft from genfb and drmfb?

Re: DRM/KMS: vmwgfx driver is now available

On 7/22/23 22:23, Taylor R Campbell wrote: Date: Sun, 16 Jul 2023 04:50:35 +0900 From: PHO On 7/16/23 04:19, Taylor R Campbell wrote: 1. Did you reimplement an allocator for the dma_pool_* API? Should it use vmem(9) instead or can that not handle the requests that it needs? Yes

Re: DRM/KMS: vmwgfx driver is now available

On Sat, Jul 22, 2023 at 01:23:39PM +, Taylor R Campbell wrote: > Is there a way we could just use or add a simple hook in genfb or > rasops for when there's dirty areas to update, so we don't have to > copy & paste all of that cruft from genfb and drmfb? > > It looks like a painful

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

n 7/22/23 22:31, Taylor R Campbell wrote: What exactly is the panic you see and the evidence when you see it? Stack trace, gdb print cb in crash dump? Wait, can we use gdb for examining the kernel dump? I thought gdb couldn't read it. Here's the stacktrace found in /var/log/message: Yep,

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

On 7/22/23 22:41, Taylor R Campbell wrote: Date: Sat, 22 Jul 2023 21:52:40 +0900 From: PHO Jul 17 00:52:34 netbsd-current /netbsd: [ 64017.6151161] vmw_fence_wait() at netbsd:vmw_fence_wait+0xdc Just to confirm, what does `info line *(vmw_fence_wait+0xdc)' say in gdb? And, if you can get to

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Sat, 22 Jul 2023 21:52:40 +0900 > From: PHO > > Jul 17 00:52:34 netbsd-current /netbsd: [ 64017.6151161] > vmw_fence_wait() at netbsd:vmw_fence_wait+0xdc Just to confirm, what does `info line *(vmw_fence_wait+0xdc)' say in gdb? And, if you can get to the frame in gdb, what does gdb

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Sat, 22 Jul 2023 21:52:40 +0900 > From: PHO > > >> cv_destroy(); // <-- Panics! > >> > >> It seldom panics on KASSERT(!cv_has_waiters(cv)) in cv_destroy() but not > >> always. The panic seems to happen when cv_timedwait_sig() exits due to > >> the timeout expiring before it gets

Re: DRM/KMS: vmwgfx driver is now available

> Date: Sun, 16 Jul 2023 04:50:35 +0900 > From: PHO > > On 7/16/23 04:19, Taylor R Campbell wrote: > > > 1. Did you reimplement an allocator for the dma_pool_* API? Should it > > use vmem(9) instead or can that not handle the requests that it > > needs? > > Yes I reimplemented it but

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

On 7/22/23 20:48, Taylor R Campbell wrote: A note about one of the problems there: spin_unlock(f->lock); ret = dma_fence_add_callback(f, , vmwgfx_wait_cb); spin_lock(f->lock); #if defined(__NetBSD__) /* This is probably an upstream bug: there is a time window

Re: Strange crash of DIAGNOSTIC kernel on cv_destroy(9)

> Date: Mon, 17 Jul 2023 12:57:42 +0900 > From: PHO > > While further testing my DRM/KMS vmwgfx driver patches by playing > games/minetest from pkgsrc, I experienced inexplicable kernel panics on > this code: > >

Re: [10.0-BETA] Reproductible panic (filesystem)

BERTRAND Joël a écrit : > BERTRAND Joël a écrit : >> Taylor R Campbell a écrit : Date: Fri, 19 May 2023 11:55:09 +0200 From: BERTRAND Joël This morning, ccd0 (and of course dk5) are "locked". All tasks stall in uninterruptible state when they try to access to dk5: