Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y

From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Larry Finger <Larry.Finger@lwfinger.net>
Cc: "linuxppc-dev@ozlabs.org" <linuxppc-dev@ozlabs.org>
Subject: Re: RESEND: Re: Problem booting a PowerBook G4 Aluminum after commit cd08f109 with CONFIG_VMAP_STACK=y
Date: Thu, 13 Feb 2020 14:43:01 +0000	[thread overview]
Message-ID: <9429f86e-8c7d-b2e6-6dc1-8f58c44baadc@c-s.fr> (raw)
In-Reply-To: <7f63e8a8-95c5-eeca-dc79-3c13f4d98d39@lwfinger.net>


On 02/13/2020 02:28 PM, Larry Finger wrote:
> On 2/11/20 1:23 PM, Christophe Leroy wrote:
>> Can you send me a picture of that BUG Unable to handle kernel data 
>> access with all the registers values etc..., together with the 
>> matching vmlinux ?
>>
>> First thing is to identify where we are when that happens. That mean 
>> see what is at 0xc0013674. Can be done with 'ppc-linux-objdump -d 
>> vmlinux' (Or whatever your PPC objdump is named) and get the function 
>> code.
>>
>> Then we need to understand how we reach that function and why it tries 
>> to access a physical address.
>>
>>
>> Another thing I'm thinking about, not necessarily related to that 
>> problem: Some buggy drivers do DMA from stack. This doesn't work 
>> anymore with CONFIG_VMAP_STACK. Most of them can be detected with 
>> CONFIG_DEBUG_VIRTUAL so you should activate it.
> 
> Christophe,
> 
> The previous send of this message failed because the attached vmlinux 
> was too large.
> 
> I have gone about as far as I can in debugging the problem. Setting 
> CONFIG_DEBUG_VIRTUAL made no difference.
> 
> Attached are the final screenshot, and the patches that I have applied. 
> You already have the gzipped vmlinux.
> 

This screenshot makes more sense with the vmlinux you provided, problem 
at 0xc00136dc.

That's in function power_save_ppc32_restore() in 
arch/powerpc/kernel/idle_6xx.S.

c00136c0 <power_save_ppc32_restore>:
c00136c0:	81 2b 00 a0 	lwz     r9,160(r11)
c00136c4:	91 2b 00 90 	stw     r9,144(r11)
c00136c8:	39 60 00 00 	li      r11,0
c00136cc:	7d 30 fa a6 	mfspr   r9,1008
c00136d0:	75 29 00 40 	andis.  r9,r9,64
c00136d4:	41 82 00 18 	beq     c00136ec <power_save_ppc32_restore+0x2c>
c00136d8:	3d 2b 00 7c 	addis   r9,r11,124
 >> c00136dc:	81 29 92 5c 	lwz     r9,-28068(r9)
c00136e0:	7d 36 fb a6 	mtspr   1014,r9
c00136e4:	7c 00 04 ac 	hwsync
c00136e8:	4c 00 01 2c 	isync
c00136ec:	3d 2b 00 7c 	addis   r9,r11,124
c00136f0:	81 29 92 60 	lwz     r9,-28064(r9)
c00136f4:	7d 31 fb a6 	mtspr   1009,r9
c00136f8:	48 00 19 c4 	b       c00150bc <transfer_to_handler_cont>
c00136fc:	00 00 00 00 	.long 0x0

Can you try the change below (won't work anymore without 
CONFIG_VMAP_STACK, will fix it properly later when you confirm it is OK).

diff --git a/arch/powerpc/kernel/idle_6xx.S b/arch/powerpc/kernel/idle_6xx.S
index 0ffdd18b9f26..7be8a0f3fac8 100644
--- a/arch/powerpc/kernel/idle_6xx.S
+++ b/arch/powerpc/kernel/idle_6xx.S
@@ -166,7 +166,7 @@ BEGIN_FTR_SECTION
  	mfspr	r9,SPRN_HID0
  	andis.	r9,r9,HID0_NAP@h
  	beq	1f
-	addis	r9,r11,(nap_save_msscr0-KERNELBASE)@ha
+	addis	r9,r11,nap_save_msscr0@ha
  	lwz	r9,nap_save_msscr0@l(r9)
  	mtspr	SPRN_MSSCR0, r9
  	sync
@@ -174,7 +174,7 @@ BEGIN_FTR_SECTION
  1:
  END_FTR_SECTION_IFSET(CPU_FTR_NAP_DISABLE_L2_PR)
  BEGIN_FTR_SECTION
-	addis	r9,r11,(nap_save_hid1-KERNELBASE)@ha
+	addis	r9,r11,nap_save_hid1@ha
  	lwz	r9,nap_save_hid1@l(r9)
  	mtspr	SPRN_HID1, r9
  END_FTR_SECTION_IFSET(CPU_FTR_DUAL_PLL_750FX)


Thanks
Christophe
