NVRM: GPU at 0000:01:00.0 has fallen off the bus. NVRM: RmInitAdapter failed! (0x25:0x28:1169) nvidia0: NVRM: rm_init_adapter() failed!
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0x8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0xffffffff817eeeb5
stack pointer = 0x28:0xfffffe021d481420
frame pointer = 0x28:0xfffffe021d481500
code segment = base 0x0, limit 0xfffff, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 3
current process = 73254 (Xorg)
trap number = 12
panic: page fault
cpuid = 2
Uptime: 12h17m8s
It looks like rm_init_adapter is contained in nvidia's .o file that
comes with the driver, so I'm out of luck for trying to track it down.
I can't tell whether this is caused by the ACPI errors or not...
On 08/17/2014 08:31, Eric McCorkle wrote:
Finally got time to do some more poking around regarding this. I haven't read the entire ACPI spec, so bear with me... As John Baldwin said, the wrapper nvidia_acpi.c passes in a buffer instead of a package. In the definition for _DSM, you can see calls to NVOP, NVPS, and NBCI. I looked at all three, and they seem to treat Arg3 as a buffer as well (they call CreateField on it, which according to the ACPI spec, should take a buffer argument). So it looks like both the nvidia driver as well as the ALS code are pretty thoroughly convinced that Arg3 (the fourth arg) is a buffer instead of a package, despite what the spec says about what it "should" be. Could this possibly be fixed by adding some kind of quirk to the ACPI execution engine that says "_DSM's fourth argument is a buffer"? On 06/24/2014 20:51, Eric McCorkle wrote:It looks like this is the definition: Method (_DSM, 4, NotSerialized) // _DSM: Device-Specific Method { If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0xF8, 0xD8, 0x86, 0xA4, 0xDA, 0x0B, 0x1B, 0x47, /* 0008 */ 0xA7, 0x2B, 0x60, 0x42, 0xA6, 0xB5, 0xBE, 0xE0 })) { Return (NVOP (Arg0, Arg1, Arg2, Arg3)) } If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0x01, 0x2D, 0x13, 0xA3, 0xDA, 0x8C, 0xBA, 0x49, /* 0008 */ 0xA5, 0x2E, 0xBC, 0x9D, 0x46, 0xDF, 0x6B, 0x81 })) { Return (NVPS (Arg0, Arg1, Arg2, Arg3)) } If (\WIN8) { If (\CMPB (Arg0, Buffer (0x10) { /* 0000 */ 0x75, 0x0B, 0xA5, 0xD4, 0xC7, 0x65, 0xF7, 0x46, /* 0008 */ 0xBF, 0xB7, 0x41, 0x51, 0x4C, 0xEA, 0x02, 0x44 })) { Return (NBCI (Arg0, Arg1, Arg2, Arg3)) } } Return (Buffer (0x04) { 0x01, 0x00, 0x00, 0x80 }) } Not sure if that's helpful at all...Ah, the nvidia driver calls _DSM and it has the bug. In its nvidia_acpi.c file it uses a Buffer instead of a Package for the fourth argument to _DSM. OTOH, the warning doesn't prevent the method from running, so the warning may be harmless. You can try contacting the nvidia folks to tell them about the warning and point out the bug in their _DSM wrapper in nvidia_acpi.c to see what they say.Will do. Is there a preferred point of contact?_______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
_______________________________________________ freebsd-acpi@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-acpi To unsubscribe, send any mail to "freebsd-acpi-unsubscr...@freebsd.org"
