July 31 2015 4:21 PM, "Glen Barber" <gjb_at_freebsd.org> wrote: > On Fri, Jul 31, 2015 at 04:18:15AM +0000, Glen Barber wrote: > >> On Thu, Jul 30, 2015 at 06:57:05PM -0500, Larry Rosenman wrote: >>> On 2015-07-30 17:17, Glen Barber wrote: >>>> On Thu, Jul 30, 2015 at 03:20:46PM -0500, Larry Rosenman wrote: >>>>> Kernel compiling -- give mr a bit and I'll boot it and make sure it >>>>> comes >>>>> up. >>>>> >>>> >>>> Larry, have you had any luck with this patch applied? If it resolves >>>> your issue, I want to make sure it is included in the 10.2-RC2 build. >>>> >>>> Thanks. >>>> >>> [...] >>> >>> There are 3 pictures from the CURRENT panic. >>> >>> it STILL fails. :( >>> >> >> Larry, I am sorry this is causing headaches for you, and I certainly >> appreciate the prompt (and detailed) report, and assistance debugging >> this. >> >> Would you be able to try one more test case? >> >> I'm interested in the behavior without the 'nodevice pmsdrv' addition to >> your kernel configuration (effectively, removing the device from the >> GENERIC kernel), and *without* the patch provided from Benno? > > To be more specific on what I'm interested in, 'nodevice pmsdrv' and > 'device pmsdrv' should *both* be removed from the kernel configuration, > and the pms(4) should only be available as a .ko module. > >> In particular, I'm interested in if ahd(4) attaches or if loader(8) >> auto-loads pms(4) after the PCI IDs are detected. >> >> As this issue also affects the upcoming 10.2-RELEASE, your willingness >> to help debug this is greatly appreciated, as you've tripped over >> something that would have caused a great deal of pain after 10.2 was >> release. >> >> I owe you several beers. > > Glen Hi All, I've experienced the same bug although with a mvs(4) device on 10.2-PRERELEASE, once the pms driver is removed from the kernel config the problem disappears, I haven't had time to try the suggested patch as I only found this thread after removing the pms driver from the kernel. Rob Evers P.S. some info from the machine working system: # pciconf -l | grep mvs1 mvs1_at_pci0:5:0:0: class=0x010400 card=0x02439005 chip=0x02439005 rev=0x02 hdr=0x00 Failed boot: cib2: allocated memory range (0xd0400000-0xd04fffff) for rid 10 of pci0:5:0:0 map[18]: type I/O Port, range 32, base 0x3000, size 8, enabled pcib2: allocated I/O port range (0x3000-0x30ff) for rid 18 of pci0:5:0:0 map[1c]: type Memory, range 64, base 0xd0300000, size 20, enabled pcib2: attempting to grow memory window for (0xd0300000-0xd03fffff,0x100000) front candidate range: 0xd0300000-0xd03fffff pci5: pci0:5:0:0 bar 0x1c failed to allocate pcib2: matched entry for 5.0.INTA pcib2: slot 0 INTA hardwired to IRQ 16 pmspcv0 port 0x3000-0x30ff mem 0xd0400000-0xd04fffff irq 16 at device 0.0 on pci5 Fatal trap 12: page fault while in kernel mode cpuid = 0; apic id = 00 fault virtual address = 0x28 fault code = supervisor read data, page not present instruction pointer = 0x20:0xffffffff80a0d984 stack pointer = 0x28:0xffffffff821ac2c0 frame pointer = 0x28:0xffffffff821ac2d0 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) trap number = 12 panic: page fault cpuid = 0 KDB: stack backtrace: #0 0xffffffff80a17a30 at kdb_backtrace+0x60 #1 0xffffffff809db196 at vpanic+0x126 #2 0xffffffff809db063 at panic+0x43 #3 0xffffffff80dee3eb at trap_fatal+0x36b #4 0xffffffff80dee6ed at trap_pfault+0x2ed #5 0xffffffff80dedd8a at trap+0x47a #6 0xffffffff80dd4102 at calltrap+0x8 #7 0xffffffff806b7a20 at agtiapi_attach+0x3a0 #8 0xffffffff80a0e6cd at device_attach+0x43d #9 0xffffffff80a0f82c at bus_generic_attach+0x4c #10 0xffffffff8038069c at acpi_pci_attach+0x15c #11 0xffffffff80a0e6cd at device_attach+0x43d #12 0xffffffff80a0f82c at bus_generic_attach+0x4c #13 0xffffffff803827cc at acpi_pcib_attach+0x22c #14 0xffffffff80383a2f at acpi_pcib_pci_attach+0x9f #15 0xffffffff80a0e6cd at device_attach+0x43d #16 0xffffffff80a0f82c at bus_generic_attach+0x4c #17 0xffffffff8038069c at acpi_pci_attach+0x15c Uptime: 1sReceived on Fri Jul 31 2015 - 02:48:33 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:58 UTC