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

[Christophe Leroy]

Le 11/02/2020 à 17:06, Larry Finger a écrit :
> On 2/11/20 12:55 AM, Christophe Leroy wrote:
>>
>>
>> Le 10/02/2020 à 13:55, Larry Finger a écrit :
>>> On 2/9/20 12:19 PM, Christophe Leroy wrote:
>>>> Do you have CONFIG_TRACE_IRQFLAGS in your config ?
>>>> If so, can you try the patch below ?
>>>>
>>>> https://patchwork.ozlabs.org/patch/1235081/
>>>>
>>>> Otherwise, can you send me your .config and tell me exactly where it 
>>>> stops during the boot.
>>>
>>> Christophe,
>>>
>>> That patch did not work. My .config is attached.
>>>
>>> It does boot if CONFIG_VMAP_STACK is not set.
>>>
>>> The console display ends with the "DMA ranges" output. A screen shot 
>>> is also appended.
>>>
>>> Larry
>>>
>>
>> Hi,
>>
>> I tried your config under QEMU, it works.
>>
>> In fact your console display is looping on itself, it ends at "printk: 
>> bootconsole [udbg0] disabled".
>>
>> Looks like you get stuck at the time of switching to graphic mode. 
>> Need to understand why.
> 
> I'm not surprised that a real G4 differs from QEMU. For one thing, the 
> real hardware uses i2c to connect to the graphics hardware.
> 
> I realized that the screen was not scrolling and output was missing. To 
> see what was missed, I added a call to btext_clearscreen(). As you 
> noted, it ends at the bootconsole disabled statement.
> 
> As I could not find any console output after that point, I then turned 
> off the bootconsole disable. I realize this action may cause a different 
> problem, but in this configuration, the computer hit a BUG Unable to 
> handle kernel data access at 0x007a84fc. The faulting instruction 
> address was 0x00013674. Those addresses look like physical, not virtual, 
> addresses.
> 

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