Bug 203699
| Summary: | Kernel 5.2-rc1 fails to boot on a Mac Mini G4: dt_headr_start=0x01501000 | ||
|---|---|---|---|
| Product: | Platform Specific/Hardware | Reporter: | Mathieu Malaterre (mathieu.malaterre) |
| Component: | PPC-32 | Assignee: | platform_ppc-32 |
| Status: | CLOSED CODE_FIX | ||
| Severity: | blocking | CC: | mathieu.malaterre, michael |
| Priority: | P1 | ||
| Hardware: | PPC-32 | ||
| OS: | Linux | ||
| URL: | https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-May/190913.html | ||
| Kernel Version: | Kernel 5.2 | Subsystem: | |
| Regression: | Yes | Bisected commit-id: | |
| Attachments: | Fix symptoms | ||
Created attachment 282929 [details]
Fix symptoms
Did this get fixed along the way? v5.19-rc2 is booting on my mac mini with KASAN enabled, so I'm going to close this as fixed. |
From: Christophe Leroy <> I found the issue. In order to be able to support KASAN, the setup of segments have moved earlier in the boot. Your problem is a side effect of this change. Function setup_disp_bat() is supposed to setup BAT3 for btext data. But setup_disp_bat() rely on someone setting in disp_BAT the values to be loaded into BATs. This is done by btext_prepare_BAT() which is called by bootx_init(). The problem is that bootx_init() is never called, so setup_disp_bat() does nothing and the access to btext data is possible because the bootloader has set an entry for it in the hash table. But by setting up the segment earlier, we break the bootloader hash table, which shouldn't be an issue if the BATs had been set properly as expected. The problematic commit is 215b823707ce ("powerpc/32s: set up an early static hash table for KASAN)" Here is a dirty fix that works for me when CONFIG_KASAN is NOT set. Of course, the real fix has to be to setup the BATs properly, but I won't have time to look at that before June. Maybe you can ?