[Skiboot] [PATCH] core/pci-dt-slot: Fix booting with no slot map

Stewart Smith stewart at linux.vnet.ibm.com
Thu Mar 1 14:57:35 AEDT 2018


Michael Neuling <mikey at neuling.org> writes:
> Currently if you don't have a slot map in the device tree in
> /ibm,pcie-slots, you can crash with a back trace like this:
>
> CPU 0034 Backtrace:
>  S: 0000000031cd3370 R: 000000003001362c   .backtrace+0x48
>  S: 0000000031cd3410 R: 0000000030019e38   ._abort+0x4c
>  S: 0000000031cd3490 R: 000000003002760c   .exception_entry+0x180
>  S: 0000000031cd3670 R: 0000000000001f10 *
>  S: 0000000031cd3850 R: 00000000300b4f3e * cpu_features_table+0x1d9e
>  S: 0000000031cd38e0 R: 000000003002682c   .dt_node_is_compatible+0x20
>  S: 0000000031cd3960 R: 0000000030030e08   .map_pci_dev_to_slot+0x16c
>  S: 0000000031cd3a30 R: 0000000030091054   .dt_slot_get_slot_info+0x28
>  S: 0000000031cd3ac0 R: 000000003001e27c   .pci_scan_one+0x2ac
>  S: 0000000031cd3ba0 R: 000000003001e588   .pci_scan_bus+0x70
>  S: 0000000031cd3cb0 R: 000000003001ee74   .pci_scan_phb+0x100
>  S: 0000000031cd3d40 R: 0000000030017ff0   .cpu_process_jobs+0xdc
>  S: 0000000031cd3e00 R: 0000000030014cb0   .__secondary_cpu_entry+0x44
>  S: 0000000031cd3e80 R: 0000000030014d04   .secondary_cpu_entry+0x34
>  S: 0000000031cd3f00 R: 0000000030002770   secondary_wait+0x8c
> [   73.016947149,3] Fatal MCE at 0000000030026054   .dt_find_property+0x30
> [   73.017073254,3] CFAR : 0000000030026040
> [   73.017138048,3] SRR0 : 0000000030026054 SRR1 : 9000000000201000
> [   73.017198375,3] HSRR0: 0000000000000000 HSRR1: 0000000000000000
> [   73.017263210,3] DSISR: 00000008         DAR  : 7c7b1b7848002524
> [   73.017352517,3] LR   : 000000003002602c CTR  : 000000003009102c
> [   73.017419778,3] CR   : 20004204         XER  : 20040000
> [   73.017502425,3] GPR00: 000000003002682c GPR16: 0000000000000000
> [   73.017586924,3] GPR01: 0000000031c23670 GPR17: 0000000000000000
> [   73.017643873,3] GPR02: 00000000300fd500 GPR18: 0000000000000000
> [   73.017767091,3] GPR03: fffffffffffffff8 GPR19: 0000000000000000
> [   73.017855707,3] GPR04: 00000000300b3dc6 GPR20: 0000000000000000
> [   73.017943944,3] GPR05: 0000000000000000 GPR21: 00000000300bb6d2
> [   73.018024709,3] GPR06: 0000000031c23910 GPR22: 0000000000000000
> [   73.018117716,3] GPR07: 0000000031c23930 GPR23: 0000000000000000
> [   73.018195974,3] GPR08: 0000000000000000 GPR24: 0000000000000000
> [   73.018278350,3] GPR09: 0000000000000000 GPR25: 0000000000000000
> [   73.018353795,3] GPR10: 0000000000000028 GPR26: 00000000300be6fb
> [   73.018424362,3] GPR11: 0000000000000000 GPR27: 0000000000000000
> [   73.018533159,3] GPR12: 0000000020004208 GPR28: 0000000030767d38
> [   73.018642725,3] GPR13: 0000000031c20000 GPR29: 00000000300b3dc6
> [   73.018737925,3] GPR14: 0000000000000000 GPR30: 0000000000000010
> [   73.018794428,3] GPR15: 0000000000000000 GPR31: 7c7b1b7848002514
>
> This has been seen in the lab on a witherspoon using the device tree
> entry point (ie. no HDAT).
>
> This fixes the null pointer deref.
>
> Signed-off-by: Michael Neuling <mikey at neuling.org>

Thanks! Merged to master as of bb3348c865a8e673d9119d696c6c682356df5801
-- 
Stewart Smith
OPAL Architect, IBM.



More information about the Skiboot mailing list