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

[Larry Finger]

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.

My kernel is built with commit cd08f1089 with patches applied as in the attached 
file. These include the change to arch/powerpc/kernel/entry_32.S, line 217. The 
next patch was to arch/powerpc/mm/mem.c where I added a call to 
btext_clearscreen() to stop the bootconsole from overwriting lines. If does not 
scroll, but jumps from the bottom to the top.

The other change I made to the program was in kernel/printk/printk.c where I 
returned early from unregister_console() to keep logging going. As you noted, 
the console goes silent when the bootconsole is disabled.

The rest of the changes were made to follow the flow of the program to see where 
if failed. The following change showed where the problem happens:

index 8bf5f2f..c69d91d9 100644
--- a/drivers/video/fbdev/core/fb_ddc.c
+++ b/drivers/video/fbdev/core/fb_ddc.c
@@ -58,13 +58,16 @@ unsigned char *fb_ddc_read(struct i2c_adapter *adapter)
          int i, j;

          algo_data->setscl(algo_data->data, 1);
-
+       pr_info("In %s, line %d\n", __func__, __LINE__);
          for (i = 0; i < 3; i++) {
                  /* For some old monitors we need the
                   * following process to initialize/stop DDC
                   */
+       pr_info("In %s, line %d, algo_data 0x%x, data loc 0x%x\n", __func__, 
__LINE__, algo_data, algo_data->data);
                  algo_data->setsda(algo_data->data, 1);
+       pr_info("In %s, line %d\n", __func__, __LINE__);
                  msleep(13);
+       pr_info("In %s, line %d\n", __func__, __LINE__);

The line before the callback to algo->setsda() and the one following that call 
both print, but the crash happens before the pr_info() after msleep(), thus the 
crash is happening in the sleep operation.

I further traced the sleep with

diff --git a/kernel/time/timer.c b/kernel/time/timer.c
index 4820823..008a99c 100644
--- a/kernel/time/timer.c
+++ b/kernel/time/timer.c
@@ -1890,13 +1890,19 @@ signed long __sched schedule_timeout(signed long timeout)
          expire = timeout + jiffies;

          timer.task = current;
+       pr_info("In %s, line %d\n", __func__, __LINE__);
          timer_setup_on_stack(&timer.timer, process_timeout, 0);
+       pr_info("In %s, line %d\n", __func__, __LINE__);
          __mod_timer(&timer.timer, expire, 0);
+       pr_info("In %s, line %d\n", __func__, __LINE__);
          schedule();
+       pr_info("In %s, line %d\n", __func__, __LINE__);
          del_singleshot_timer_sync(&timer.timer);
+       pr_info("In %s, line %d\n", __func__, __LINE__);

          /* Remove the timer from the object tracker */
          destroy_timer_on_stack(&timer.timer);
+       pr_info("In %s, line %d\n", __func__, __LINE__);

          timeout = expire - jiffies;

The logged output shows that the problem happens in schedule(). At that point, 
we are back in assembler and out of my realm.

Thanks for your help, and I will supply any additional info and testing that you 
need.

Larry

-------------- next part --------------
A non-text attachment was scrubbed...
Name: PPC32_screenshot.jpg
Type: image/jpeg
Size: 3293308 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20200213/2185bfc1/attachment-0001.jpg>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: trial_patch.patch
Type: text/x-patch
Size: 6427 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/linuxppc-dev/attachments/20200213/2185bfc1/attachment-0001.bin>