I was able to reproduce the problem here with your ACPI tables. Will look at your patch, and get back to you. You should probably open a bugzilla on this. Thanks, Bob > -----Original Message----- > From: linux-acpi-owner@xxxxxxxxxxxxxxx [mailto:linux-acpi- > owner@xxxxxxxxxxxxxxx] On Behalf Of Vlastimil Babka > Sent: Monday, July 02, 2012 1:45 AM > To: linux-acpi@xxxxxxxxxxxxxxx > Subject: PROBLEM: NULL pointer dereference in > acpi_ns_check_object_type() > > Hello, > > I've been experiencing kernel panic with NULL pointer dereference in > acpi_ns_check_object_type since kernel 3.4 on a MacPro machine. > > By recompiling as much of ACPI as possible as modules, I was able to > get the system running and postpone the error until doing 'modprobe > acpi-cpufreq', which now results in oops, not panic. The log is > attached as error.log. > > By bisecting linus tree between 3.3 and 3.4, I found the guilty commit > 6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9 > "ACPICA: Object repair code: Support to add Package wrappers" [1] > However this patch does not directly touch the functions in the stack > trace. > > Next I created a kdump of the oops, and looked around with gdb. > - In acpi_ns_check_package(), the null pointer is in the parameter > return_object_ptr, which is dereferenced when initializing the variable > return_object. > - The calling function acpi_ns_check_package_list() is in the 'case > ACPI_PTYPE2_COUNT:' part, the passed null pointer is in the > sub_elements variable. > - Before the switch, sub_elements is initialized like this: > > sub_elements = sub_package->package.elements > > interestingly, in the crashdump, sub_elements is null, but > sub_package->package.elements is non-null > > I've added some printk's and verified that the call of status = > acpi_ns_check_object_type(data, &sub_package, > ACPI_RTYPE_PACKAGE, i); > > makes sub_package->package.elements become non-null, but sub_elements > was already initialized before this call and remains null. > > The above led me to create the attached patch which simply moves the > initialization of sub_elements after the sub_package check. I think > it's this check that results in the Integer to Package > conversion/wrapping. > > After this patch, the null pointer dereference is gone, but the debug > output of ACPI (acpi.debug_layer=0xffffffff > acpi.debug_level=0x00000008) shows that something is probably still > wrong: > > [ 1.353677] nsrepair-0681 [4294967287] ns_wrap_with_package : > \_PR_.CPU0._PSD: Wrapped Integer with expected Package object > [ 1.353869] nsrepair-0681 [4294967287] ns_wrap_with_package : > \_PR_.CPU0._PSD: Wrapped Integer with expected Package object > [ 1.354059] ACPI Warning: For \_PR_.CPU0._PSD: Return Sub-Package[0] > is too small - found 1 elements, expected 5 (20120320/nspredef-905) > [ 1.354253] ACPI: Invalid package argument > [ 1.354322] ACPI: Invalid _PSD data > ... (the same for other CPUx) > > > In comparison, 3.3 kernel with same acpi debug options shows only stuff > like: > [ 1.494238] nsrepair-0728 [4294967287] ns_repair_package_list: > \_PR_.CPU0._PSD: Repaired incorrectly formed Package > [ 1.494449] nsrepair-0728 [4294967287] ns_repair_package_list: > \_PR_.CPU2._PSD: Repaired incorrectly formed Package > [ 1.494657] nsrepair-0728 [4294967287] ns_repair_package_list: > \_PR_.CPU4._PSD: Repaired incorrectly formed Package ... (the same for > other CPUx) > > Since I don't know much about this subsystem, I figured that I should > just report my findings at this point. The patched system is usable, > but I guess it's not a complete fix. > > I also attach the output of acpidump. I hope I didn't forget anything > important, please ask for more information if needed. > > Thanks, > Vlastimil Babka > > [1] > git.kernel.org/?p=linux/kernel/git/torvalds/linux- > 2.6.git;a=commit;h=6a99b1c94d053b3420eaa4a4bc8b2883dd90a2f9 ��.n��������+%������w��{.n�����{�����ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f
