> [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
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
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
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
> 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.
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
>> [ 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)
