Re: git: 871b33ad65ba - main - pci: Consistently use pci_vf_* for suballocated VF memory resources
Date: Wed, 05 Jun 2024 05:16:38 UTC
In message <20240605034733.42321112@slippy.cwsent.com>, Cy Schubert writes: > In message <202406042352.454NqFVj061328@gitrepo.freebsd.org>, John Baldwin wr > it > es: > > The branch main has been updated by jhb: > > > > URL: https://cgit.FreeBSD.org/src/commit/?id=871b33ad65baf07c92cce120a4fc19 > 78 > > c2ed7b3b > > > > commit 871b33ad65baf07c92cce120a4fc1978c2ed7b3b > > Author: John Baldwin <jhb@FreeBSD.org> > > AuthorDate: 2024-06-04 23:51:37 +0000 > > Commit: John Baldwin <jhb@FreeBSD.org> > > CommitDate: 2024-06-04 23:51:37 +0000 > > > > pci: Consistently use pci_vf_* for suballocated VF memory resources > > > > Some of the bus resource methods were passing these up to the parent > > which triggered rman mismatch assertions in INVARIANTS kernels. > > > > Reported by: kp > > Reviewed by: imp > > Tested by: kp (earlier version) > > Differential Revision: https://reviews.freebsd.org/D45406 > > --- > > sys/dev/pci/pci.c | 118 ++++++++++++++++++++++++++++++++++-- > > sys/dev/pci/pci_iov.c | 151 ++++++++++++++++++++++++++++++++++++++++++ > ++ > > ++ [...] > atapci0: <nVidia nForce MCP55 UDMA133 controller> port 0x1f0-0x1f7,0x3f6,0x17 > 0-0x177,0x376,0xfc00-0xfc0f at device 4.0 on pci0 > ata0: <ATA channel> at channel 0 on atapci0 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 2; apic id = 02 > fault virtual address = 0x54 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0xffffffff804a76e2 > stack pointer = 0x28:0xffffffff81f0b6d0 > frame pointer = 0x28:0xffffffff81f0b700 > code segment = base 0x0, limit 0xfffff, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 0 (swapper) > rdi: fffff80004bf9000 rsi: fffff80004bf9000 rdx: fffff80004c2de00 > rcx: fffff80004a99000 r8: fffff80004c2c020 r9: fffffe000ec57540 > rax: 0000000000000000 rbx: fffff80004bf9000 rbp: ffffffff81f0b700 > r10: fffff80004bc2000 r11: ffffffff81f0b9fc r12: 0000000000000001 > r13: 0000000000000000 r14: fffff80004bf8600 r15: fffff80004c2de00 > trap number = 12 > panic: page fault > cpuid = 2 > time = 1 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xffffffff81f0b3c > 0 > vpanic() at vpanic+0x13f/frame 0xffffffff81f0b4f0 > panic() at panic+0x43/frame 0xffffffff81f0b550 > trap_fatal() at trap_fatal+0x40b/frame 0xffffffff81f0b5b0 > trap_pfault() at trap_pfault+0x46/frame 0xffffffff81f0b600 > calltrap() at calltrap+0x8/frame 0xffffffff81f0b600 > --- trap 0xc, rip = 0xffffffff804a76e2, rsp = 0xffffffff81f0b6d0, rbp = 0xfff > fffff81f0b700 --- > pci_activate_resource() at pci_activate_resource+0x22/frame 0xffffffff81f0b70 > 0 > bus_generic_rman_alloc_resource() at bus_generic_rman_alloc_resource+0xee/fra > me 0xffffffff81f0b740 > nexus_alloc_resource() at nexus_alloc_resource+0x99/frame 0xffffffff81f0b7a0 > acpi_alloc_resource() at acpi_alloc_resource+0x84/frame 0xffffffff81f0b860 [...] Removing PCI-IOV from the kernel config also works around this. -- Cheers, Cy Schubert <Cy.Schubert@cschubert.com> FreeBSD UNIX: <cy@FreeBSD.org> Web: https://FreeBSD.org NTP: <cy@nwtime.org> Web: https://nwtime.org e^(i*pi)+1=0