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

[Larry Finger <Larry.Finger@lwfinger.net>]

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.

I then added pr_info statements to bracket the failure. In file 
drivers/video/fbdev/core/fb_ddc.c, the code reaches line 66, which is
	algo_data->setsda(algo_data->data, 1);
Both pointers seem OK with algo_data = 0xeedfb4bc, and algo_data->data = 
0xeedb25c. The code faults before returning. I then annotated that callback 
routine radeon_gpio_setsda(), and found that execution is OK to the end of the 
routine, but the fault happens on the return from this routine as though the 
stack were corrupted.

I will be busy for about 8 hours, but if you can think of any debugging I can do 
on this routine, please let me know.

Thanks,

Larry