"zfs send" freezes system (was: Re: pgdaemon high CPU consumption)

Hello, On 13.07.22 12:30, Matthias Petermann wrote: I can now confirm that reverting the patch also solved my problem. Of course I first fell into the trap, because I had not considered that the ZFS code is loaded as a module and had only changed the kernel. As a result, it looked at first as

Re: FYI: new X server in -current, among other X things

I have a minor (but strange) issue with the new X setup. My Radeon amdgpu does not fully work yet (strange colours, some drawing artifacts, otherwise mostly ok), so I am using vesfb and wsfb_drv (but the same effect happens with the amdgpu driver). I hadn't updated firefox before the X server upd

daily CVS update output

Updating src tree: P src/bin/rcp/rcp.c P src/sys/dev/wscons/wsdisplay_vcons.c P src/sys/external/bsd/drm2/amdgpu/amdgpu_pci.c P src/sys/external/bsd/drm2/amdgpu/amdgpu_task.h P src/sys/external/bsd/drm2/amdgpu/amdgpufb.c P src/sys/external/bsd/drm2/i915drm/i915_pci.h P src/sys/external/bsd/drm2/i

Re: FYI: new X server in -current, among other X things

On Mon, 2022-07-18 at 07:17 +1000, matthew green wrote: > > can you post the whole Xorg.0.log somewhere?  most of > > my i915 systems have become non-functional the last few > > years, but i have one system to test. > > unfortunately, my system (kaby lake, GT 630) seems to work > fine with xorg-se

re: FYI: new X server in -current, among other X things

Robert Swindells writes: > > I wrote: > > > >>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] > >>> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] > >>> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) > >>> [0x75b46379c930] >

Re: FYI: new X server in -current, among other X things

I wrote: > >>> [ 378.033] (EE) 0: /usr/X11R7/bin/X (xorg_backtrace+0x44) [0x1467d46d5] >>> [ 378.033] (EE) 1: /usr/X11R7/bin/X (os_move_fd+0x79) [0x1467d0465] >>> [ 378.033] (EE) 2: /usr/lib/libc.so.12 (__sigtramp_siginfo_2+0x0) >>> [0x75b46379c930] >>> [ 378.034] (EE) >>> [ 378.034]

re: panic in evo_wait

> > > [184218.xxx] fatal page fault in supervisor mode > > > [184218.xxx] trap type 6 code 0x2 ... > > > > this line's contents would have included the fault address, > > which is kinda useful for next time :-) > > I've got the rip -- it's 0x8095e177. oh - i was after the "cr2" value -- t

Re: readlink(1) realpath(1) and POSIX

In article <14374.1657965...@jacaranda.noi.kre.to>, Robert Elz wrote: >POSIX is planning to add readlink(1) in the next version. Nothing >special to say about that (makes no real difference to us, we have it >already, they will specify only the common options.) > >But while doing that, they loo

Re: panic in evo_wait

Hi Matt! On Mon, Jul 18, 2022 at 01:53:49PM +1000, Matthew Green wrote: > > [184218.xxx] warning: > > /usr/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_headgf119.c:83: > > 1 > > can you patch this code to print the value of "data" here? > it's probably a

Joyent package repo migrated to MNX

Hey all, If you are a user of the binary package repository I previously made available from https://pkgsrc.joyent.com/install-on-netbsd/ note that it has been updated and migrated over to MNX. New and upgrade bootstrap kits are now available from: https://pkgsrc.smartos.org/install-on-n

Re: Weird clock behaviour with current (amd64) kernel

Hi, On 2022/07/15 21:38, Robert Elz wrote: > Date:Fri, 15 Jul 2022 13:32:55 +0900 > From:Masanobu SAITOH > Message-ID: <87553319-950b-7dad-ac64-29d2c25d1...@execsw.org> > > | Could you show me the full dmesg with verbose output? > > I could, but it turns out to be