Re: port-mac68k/48171: -current does not boot

[Martin Husemann <martin%duskware.de@localhost>]

The following reply was made to PR port-mac68k/48171; it has been noted by 
GNATS.

From: Martin Husemann <martin%duskware.de@localhost>
To: gnats-bugs%NetBSD.org@localhost
Cc: 
Subject: Re: port-mac68k/48171: -current does not boot
Date: Sun, 22 Jun 2014 16:38:58 +0200

 I initially believed this to be a gcc problem, but I am not sure anymore.
 It still happens with gcc 4.8.3 and the crash is here:
 
 root file system type: ffs
 uvm_fault(0x227980, 0x93208000, 0x1) -> 0xe
   type 8, code [mmu,,ssw]: 505             
 trap type 8, code = 0x505, v = 0x93208564
 kernel program counter = 0x9bb90         
 kernel: MMU fault trap          
 pid = 0, lid = 1, pc = 0009BB90, ps = 2008, sfc = 1, dfc = 1
 Registers:                                                  
              0        1        2        3        4        5        6        7
 dreg: 00000001 0000000C 04CFCC9D 93208554 0070909C 0070966C 001C6D82 00000000
 areg: 00000000 002087D0 93208554 00081B54 00081B54 00081C94 0029BEB0 FFFFCFFC
 [..]
 db> bt                                                                    
 cpu_Debugger(?)
 db_panic(8,2000,0,1096d6,29bd4c) + 6
 vpanic(1c5b56,29bd58,29bde4,132606,1c5b56) + 122
 panic(1c5b56,4cfcc9d,93208554,70909c,70966c) + c
 trap(29bdfc,8,505,93208564) + 6e4               
 callout_halt(93208554,0,208480,208554,3c) + 18
 sleepq_block(3c,0,208480,208480,1c6d82,209364,70909c,70966c) + b2
 kpause(1c6d82,0,3c,0) + cc                                       
 uvm_scheduler(709fb4,7095ac,709fb4,0,53a6ed05) + 6c
 main(1,1049a6,64a000,0,1000) + 79c                 
 
 The issue comes from inside sleepq_block. We are running lwp0 here, and
 go into this code:
 
    0x90c8c <sleepq_block+168>:  jsr 0x93650 <mi_switch>
    0x90c92 <sleepq_block+174>:  clrl %sp@-
    0x90c94 <sleepq_block+176>:  movel %d3,%sp@-
    0x90c96 <sleepq_block+178>:  jsr 0x9bb78 <callout_halt>
 
 and the C code is:
 
 261                     if (timo) {
 262                             callout_schedule(&l->l_timeout_ch, timo);
 263                     }
 264                     mi_switch(l);
 265     
 266                     /* The LWP and sleep queue are now unlocked. */
 267                     if (timo) {
 268                             /*
 269                              * Even if the callout appears to have fired, 
we need to
 270                              * stop it in order to synchronise with other 
CPUs.
 271                              */
 272                             if (callout_halt(&l->l_timeout_ch, NULL))
 273                                     error = EWOULDBLOCK;
 274                     }
 
 Before calling mi_switch(l), gcc has placed &l->l_timeout_ch in register
 %d3 and invoked callout_schedule with that argument. At this time, the
 address was fine.
 
 Now after mi_switch, %d3 is different but gcc does not reload it and uses
 the altered value for the callout_halt() call - and we crash there.
 
 As %d3 is callee-saved (and mi_switch code has all the proper push/pop),
 this must mean that something overwrites lwp0's stack. Other m68k machines
 are reported to work (and this all started before the gcc transition),
 so the "something" overwriting the stack *might* be mac68k specific.
 
 Martin