re: panic in evo_wait
> [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 bad request for userland, but the BUG_ON()
here does not give you any indication on _what_.
> [184218.xxx] uvm_fault(0x8191ba80, 0xb649e46a3000, 2) -> e
> [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 :-)
> [184218.xxx] curlpw 0xa8d4e6f36500 pid 27414.3207 lowest kstrack
> 0xb589296452c0
> kernel: page fault trap, code=0
> Stopped in pid 27414.3207 (mpv) at netbsd:evo_wait+0x7b: movl $0x2
> 000,0(%rdx,%rax,1)
> evo_wait() at netbsd:evo_wait+0x7b
> base507c_ntfy_set()
> nv50_wndw_flush_set()
> nv50_disp_atomic_commit_tail()
> nv50_disp_atomic_commit()
> drm_atomic_helper_set_config()
> drm_mode_setcrtc()
> drm_ioctl()
can you find out where evo_wait+0x7b is? in my kernel it's
at line 243, and the disasm seems to patch your "movl" above.
235 evo_wait(struct nv50_dmac *evoc, int nr)
236 {
237 struct nv50_dmac *dmac = evoc;
238 struct nvif_device *device = dmac->base.device;
239 u32 put = nvif_rd32(>base.user, 0x) / 4;
240
241 spin_lock(>lock);
242 if (put + nr >= (PAGE_SIZE / 4) - 8) {
243 dmac->ptr[put] = 0x2000;
244 evo_flush(dmac);
Dump of assembler code for function evo_wait:
0x8084dfe1 <+0>: push %rbp
[...]
0x8084e05c <+123>: movl $0x2000,(%rdx,%rax,1)
(0x7b = 123)
probably "dmac->ptr" is invalid here. a quick guess at the
code indicates it's only set once in nv50_dmac_create(),
the source from the caller(s). at least, i can't see it
set anywhere else right now.
.mrg.
daily CVS update output
Updating src tree: P src/distrib/sets/lists/xdebug/md.cats P src/share/mk/bsd.kmodule.mk P src/sys/arch/arm/fdt/arm_simplefb.c P src/sys/arch/arm/omap/omapfb.c P src/sys/arch/arm/ti/omap3_dss.c P src/sys/arch/macppc/conf/std.macppc P src/sys/arch/x86/x86/bus_space.c P src/sys/dev/pci/agp_i810.c P src/sys/dev/pci/wcfb.c P src/sys/dev/wscons/wsdisplay.c P src/sys/dev/wscons/wsdisplay_vcons.c P src/sys/dev/wscons/wsdisplay_vconsvar.h P src/sys/dev/wscons/wsmouse.c P src/sys/dev/wsfb/genfb.c P src/sys/dev/wsfb/genfbvar.h P src/sys/external/bsd/common/include/asm/barrier.h P src/sys/external/bsd/common/include/linux/compiler.h P src/sys/external/bsd/common/include/linux/tasklet.h P src/sys/external/bsd/drm2/amdgpu/amdgpu_module.c P src/sys/external/bsd/drm2/dist/drm/drm_drv.c P src/sys/external/bsd/drm2/drm/drm_module.c P src/sys/external/bsd/drm2/i915drm/files.i915drmkms P src/sys/external/bsd/drm2/i915drm/i915_module.c cvs update: `src/sys/external/bsd/drm2/i915drm/i915_perf.c' is no longer in the repository P src/sys/external/bsd/drm2/include/linux/device.h P src/sys/external/bsd/drm2/include/linux/sync_file.h P src/sys/external/bsd/drm2/include/linux/ww_mutex.h P src/sys/external/bsd/drm2/nouveau/nouveau_module.c P src/sys/external/bsd/drm2/radeon/radeon_module.c P src/sys/external/bsd/drm2/ttm/files.ttm U src/sys/external/bsd/drm2/ttm/ttm_module.c P src/sys/external/bsd/drm2/vmwgfx/vmwgfx_module.c P src/sys/modules/Makefile P src/sys/modules/drmkms/Makefile P src/sys/modules/drmkms/Makefile.inc P src/sys/modules/drmkms_linux/Makefile U src/sys/modules/drmkms_ttm/Makefile P src/sys/modules/i915drmkms/Makefile Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.3 P sys/kern/subr_pool.c P usr.bin/vmstat/vmstat.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 40134103 Jul 18 03:09 ls-lRA.gz
Re: iscsi target on a zfs zvol?
hello Brad. Yes, I've fooled with the block size, cache sizes, a bunch of other variables. If you search for slow read/write performance with zvols under FreeBSD or Linux, you'll find a number of references to this problem, both directly in the openzfs development bug reports and as bug reports for TrueNAS and other file server packages. I've ben struggling with this speed problem for over a year and a half with ZFS and FreeBSD and when I finally admitted defeat and began using flat files in zfs filesystems, I discovered the true magnetude of the problem. My read/write performance jumped by a factor of 5, which really astounded me. -thanks -Brian On Jul 16, 10:32pm, Brad Spencer wrote: } Subject: Re: iscsi target on a zfs zvol? } Brian Buhrow writes: } } > hello. Yes, I was vaguely aware of the lack of extended attributes for NetBSD-Zfs, but } > what I was suggesting was just using a flat file, exported via iscsi through istgt or your } > initiator of choice, on top of zfs, rather than a zvol, because you'll find the read/write speed } > to be so much faster. Unfortunately, it seems the upstream zfs maintainers have decided that } > zvols are not worth the time to optimize, so while they're functional, they're not performant } > under any openzfs-using implementation. This makes me sad because zvols are such a tidy way to } > manage so many different kinds of things. } > } > -thanks } > -Brian } } } I freely admit that I don't use zvols very much in NetBSD, but did you } mess with the volblocksize any on the volume?? }
panic in evo_wait
Hi! Yesterday I had a panic on 9.99.98/amd64 from June 22 while playing a couple of videos using mpv. Hand-transcribed from the console [184197.xxx] nouveau0: error: bus: MMIO read of FAULT at 409800 [TIMEOUT ] [184199.xxx] nouveau0: warn: timeout [184199.xxx] nouveau0: error: gr: init failed, -16 [184201.xxx] nouveau0: warn: timeout [184203.xxx] nouveau0: warn: timeout [184205.xxx] nouveau0: warn: timeout [184207.xxx] nouveau0: warn: timeout [184209.xxx] nouveau0: warn: timeout [184211.xxx] nouveau0: warn: timeout [184213.xxx] nouveau0: warn: timeout [184215.xxx] nouveau0: warn: timeout [184218.xxx] nouveau0: warn: timeout [184218.xxx] warning: /usr/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_headgf119.c:83: 1 [184218.xxx] warning: /usr/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_headgf119.c:83: 1 [184218.xxx] warning: /usr/src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/engine/disp/nouveau_nvkm_engine_disp_headgf119.c:83: 1 [184218.xxx] uvm_fault(0x8191ba80, 0xb649e46a3000, 2) -> e [184218.xxx] fatal page fault in supervisor mode [184218.xxx] trap type 6 code 0x2 ... [184218.xxx] curlpw 0xa8d4e6f36500 pid 27414.3207 lowest kstrack 0xb589296452c0 kernel: page fault trap, code=0 Stopped in pid 27414.3207 (mpv) at netbsd:evo_wait+0x7b: movl $0x2 000,0(%rdx,%rax,1) evo_wait() at netbsd:evo_wait+0x7b base507c_ntfy_set() nv50_wndw_flush_set() nv50_disp_atomic_commit_tail() nv50_disp_atomic_commit() drm_atomic_helper_set_config() drm_mode_setcrtc() drm_ioctl() drm_ioctl_shim() sys_ioctl() syscall() --- syscall (number 54) --- Does this ring a bell with anyone? Should I file a PR? Thomas
re: FYI: new X server in -current, among other X things
> 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-server 21.1.4 for me.
Re: i386/amd64 image generated trough mkimage stuck on primary bootsrap at boot
On Wednesday, July 13th, 2022 at 6:39 PM, br0nko wrote: > I confirm that the image is bootable with your patch, thank you !!! As you > said already, it lack the resize capability, which make the image somehow > useless since it run out of space at first boot. I did try "resize_root=YES" > in rc.conf without any luck. Actually the live-image didn't resize the CF card either, the missing piece in my case was the resize_disklabel script (https://github.com/NetBSD/src/blob/trunk/distrib/utils/embedded/files/resize_disklabel), which wasn't there by default (in rc.d). Once there, the following in rc.conf is doing the job: resize_disklabel=YES resize_root=YES resize_root_flags="-p" resize_root_postcmd="/sbin/reboot -n" br0nko
Re: FYI: new X server in -current, among other X things
>> [ 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] (EE) Segmentation fault at address 0x0 >> >> This happens with ctwm as part of the base installation, as well as with >> other pre-existing window managers and such from pkgsrc built against >> 9.99.97. > >can you configure X to generate a core dump or run it >under GDB and get the real stack trace? i thought we'd >fixed this problem in libexecinfo, but it's still not >tracing through the SEGV above, so finding what is >crashing where is what we need next. FWIW, I get the same on my Pinebook with a lima kernel, this may not be i915 specific. Doing a full debug build now.
