Re: panic after DRM & nouveau MSI changes
On Wed, 12 Feb 2020, Jarom??r Dole?~Mek wrote: > I've just committed a fix for the MSI interrupt allocation for > nouveau, can you try it on the system which had the trouble with blank > console? > > It needs rev. 1.7 of > sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/pci/nouveau_nvkm_subdev_pci_base.c I updated my sources as soon as I saw these commits. A release build is finishing as I write and I will update and test soon. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
daily CVS update output
Updating src tree: P src/external/cddl/osnet/dev/dtrace/aarch64/dtrace_subr.c P src/external/cddl/osnet/dev/fbt/aarch64/fbt_isa.c P src/sbin/mount_msdos/mount_msdos.8 P src/sys/arch/aarch64/aarch64/vectors.S P src/sys/arch/aarch64/include/cpu.h P src/sys/arch/arm/acpi/acpi_iort.c P src/sys/arch/arm/acpi/acpi_iort.h P src/sys/arch/arm/acpi/acpi_pci_machdep.c P src/sys/arch/arm/acpi/acpi_pci_n1sdp.c P src/sys/arch/arm/acpi/gicv3_acpi.c P src/sys/arch/arm/arm32/pmap.c P src/sys/arch/arm/cortex/gicv3.c P src/sys/arch/arm/cortex/gicv3.h P src/sys/arch/arm/cortex/gicv3_its.c P src/sys/arch/arm/include/pci_machdep.h P src/sys/arch/arm/pci/pci_msi_machdep.c P src/sys/arch/arm/xscale/ixp425reg.h U src/sys/arch/evbarm/stand/board/ixp425_mem.c U src/sys/arch/evbarm/stand/board/nslu2.c P src/sys/arch/evbarm/stand/gzboot/Makefile.gzboot P src/sys/arch/evbarm/stand/gzboot/gzboot.c U src/sys/arch/evbarm/stand/gzboot/NSLU2_dram_0x01d0/Makefile U src/sys/arch/evbarm/stand/gzboot/NSLU2_dram_0x01d0/ldscript P src/sys/arch/mips/adm5120/dev/ahci.c P src/sys/dev/pci/if_ixl.c P src/sys/dev/pci/if_ixlvar.h P src/sys/dev/usb/ehci.c P src/sys/dev/usb/motg.c P src/sys/dev/usb/ohci.c P src/sys/dev/usb/uhci.c P src/sys/dev/usb/usb.c P src/sys/dev/usb/usbdi.c P src/sys/dev/usb/usbdi.h P src/sys/dev/usb/usbdivar.h P src/sys/dev/usb/vhci.c P src/sys/dev/usb/xhci.c P src/sys/external/bsd/drm2/dist/drm/nouveau/nouveau_fbcon.c P src/sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/pci/nouveau_nvkm_subdev_pci_base.c P src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo.c P src/sys/external/bsd/drm2/linux/linux_pci.c P src/sys/external/bsd/dwc2/dwc2.c P src/sys/external/bsd/dwc2/dwc2var.h P src/sys/modules/cyclic/Makefile P src/tests/dev/audio/audiotest.c P src/tests/lib/libc/sys/t_ptrace_x86_wait.h P src/usr.bin/make/meta.c Updating xsrc tree: Killing core files: Updating file list: -rw-rw-r-- 1 srcmastr netbsd 35315867 Feb 13 03:03 ls-lRA.gz
Re: uvm/busy page deadlock in current (related to loading Raspberry Pi 3B+ Wi-Fi firmware, but more of a timing bug with the VM system)
Thanks very much, Chuck -- this patch fixed my problem. I noticed you removed a couple of KASSERTs -- shouldn't those be cases be EVEN MORE true now than they were before? Given what I debugged, I'm wondering if the asserts would help make sure future code doesn't end up trying to do something similar in the future... Rob > On Feb 7, 2020, at 4:31 PM, Chuck Silvers wrote: > > On Thu, Feb 06, 2020 at 04:31:47PM -0800, Rob Newberry wrote: >> Hi. >> >> I spent last weekend -- and a few days this week -- tracking down a problem >> that exists in current. >> I found a workaround, but I don't know what the "proper" fix is. >> Digging through the VM layer and debugging with printfs was slow -- >> and it's a boot-time issue, so I had to swap a lot of SD cards back and >> forth :-). >> Hopefully someone here is better at this than me. >> >> >> [analysis...] > > good job working your way through all that, this code is pretty complicated. > > >> 3) Start "aiodone_queue" earlier in the sequence. I don't have a rich >> enough understanding of >> this part of the kernel and user land startup process to know how hard this >> is, or how hacky it is. > > this is the right way to fix it. please try the attached patch. > > >> BTW, I'm ASSUMING that if uvm.aiodone_queue were present, the asynchronous >> completion would somehow >> handle marking the pages as "not busy". But I actually never debugged that >> code path, >> so I can't be sure that's helpful. > > right, the "aiodone_queue" workqueue will call uvm_aiodone_worker() on the > buffer, > and bp->b_iodone will have been set to uvm_aio_aiodone, which unbusies the > pages > among other things. > > -Chuck >
Re: panic after DRM & nouveau MSI changes
Le mer. 12 févr. 2020 à 03:38, John D. Baker a écrit : > I've checked this with plain GENERIC and one with the above file rolled > back. With plain generic, nouveau, intel, and radeon all work and have > MSI off. With the modified GENERIC, nouveau systems work (MSI off) and > intel and radeon systems work (MSI on). I've just committed a fix for the MSI interrupt allocation for nouveau, can you try it on the system which had the trouble with blank console? It needs rev. 1.7 of sys/external/bsd/drm2/dist/drm/nouveau/nvkm/subdev/pci/nouveau_nvkm_subdev_pci_base.c Jaromir
KASLR
Just tried for the first time a kern-GENERIC_KASLR.tar.xz from yesterday's source on a working GENERIC-9.99.17/amd64 box, with serial console. All I see is >> NetBSD/x86 BIOS Boot, Revision 5.11 (Thu Nov 29 11:11:25 UTC 2018) (from >> NetBSD 8.99.26) >> Memory: 639/4189184 k ... command(s): rndseed /var/db/entropy-file;boot default boot twice, skipping... [860323- and then it reboots. kern-GENERIC.tar.xz from the same build.sh release run is fine. Cheers, Patrick
