bug#58320: Hurd VM fails to boot on AMD EPYC (kvm-amd)

[Samuel Thibault]

Ludovic Courtès, le ven. 07 oct. 2022 10:24:22 +0200, a ecrit:
> trap, eip 0xc10305c1                                                          
>                                   
> Breakpoint at  task_terminate:  pushl   %ebp                                  
>                                   
> db> show all threads                                                          
>                                   
>     TASK        THREADS                                                       
>                                   
>   0 gnumach (f5f7cf00): 7 threads:                                            
>                                   
>               0 (f5f7be18) .W..N. 0xc11dac04                                  
>                                   
>               1 (f5f7bcd0) R..O..(idle_thread_continue)                       
>                                   
>               2 (f5f7bb88) .W.ON.(reaper_thread_continue) 0xc12015d4          
>                                   
>               3 (f5f7ba40) .W.ON.(swapin_thread_continue) 0xc11f8e2c          
>                                   
>               4 (f5f7b8f8) .W.ON.(sched_thread_continue) 0                    
>                                   
>               5 (f5f7b7b0) .W.ON.(io_done_thread_continue) 0xc1201f74         
>                                   
>               6 (f5f7b668) .W.ON.(net_thread_continue) 0xc11db0a8             
>                                   
>   1 ext2fs (f5f7ce40): 6 threads:                                             
>                                   
>               0 (f5f7b520) .W.O.F(mach_msg_continue) 0                        
>                                   
>               1 (f5f7b290) .W.O..(mach_msg_receive_continue) 0                
>                                   
>               2 (f5f7b148) .W.O..(mach_msg_receive_continue) 0                
>                                   
>               3 (f5f7b000) .W.O..(mach_msg_continue) 0                        
>                                   
>               4 (f67d4e20) .W.O..(mach_msg_receive_continue) 0                
>                                   
>               5 (f67d4cd8) .W.O..(mach_msg_continue) 0                        
>                                   
>   2 exec (f5f7cd80): (f5f7b3d8) R.....                                        
>                                   
> db> trace/t 0xf5f7b3d8                                                        
>                                   
> task_terminate(f625eb10,0,f5f7cd80,f5f7b3d8,c11da940)                         
>                                   
> exception_try_task(1,1,bffefffc,ffffffff,c1202b4c)+0x58                       
>                                   
> exception(1,1,bffefffc,c10096da,f5957fbc)+0x7a                                
>                                   
> interrupted_pc(1,1,bffefffc,c102ce99,c1202b40)                                
>                                   
> trap_name(1,f5957f80,f5f73f4c,f5f73f58)                                       
>                                   
> vm_fault(f5f6ff30,bffef000,3,0,0,c1008ee4,f5f82550,fb7d9000)+0x74a            
>                                   
> user_trap(f5f7a718)+0x2df                                                     
>                                   
> >>>>> Page fault (14) at 0x1000 <<<<<                                         
> >>>>>                                   
> >>>>> user space <<<<<                                                        
> >>>>>                                   
> db> show map $map2                                                            
>                                   
> Map 0xf5f6ff30: name="exec", pmap=0xf5f71fa8,ref=1,nentries=5                 
>                                   
> size=290816,resident:290816,wired=0                                           
>                                   
> version=14                                                                    
>                                   
>  map entry 0xf625ec08: start=0x0, end=0x1000                                  
>                                   
>  prot=1/7/copy, object=0xf5f6a7d0, offset=0x0                                 
>                                   
>   Object 0xf5f6a7d0: size=0x1000, 1 references                                
>                                   
>   1 resident pages, 0 absent pages, 0 paging ops                              
>                                   
>    memory object=0x0 (offset=0x0),control=0x0, name=0xf5938968                
>                                   
>    uninitialized,temporary      internal,copy_strategy=0                      
>                                   
>    shadow=0x0 (offset=0x0),copy=0x0                                           
>                                   
>  map entry 0xf625ebb0: start=0x1000, end=0x26000                              
>                                   
>  prot=5/7/copy, object=0xf5f6ad70, offset=0x0                                 
>                                   
>   Object 0xf5f6ad70: size=0x25000, 1 references                               
>                                   
>   37 resident pages, 0 absent pages, 0 paging ops                             
>                                   
>    memory object=0x0 (offset=0x0),control=0x0, name=0xf5f82780                
>                                   
>    uninitialized,temporary      internal,copy_strategy=0                      
>                                   
>    shadow=0x0 (offset=0x0),copy=0x0                                           
>                                   
> --8<---------------cut here---------------end--------------->8---
> 
> It says “page fault at 0x1000” but there is apparently a valid mapping
> at that address.
> 
> Funny thing: if I set a breakpoint on ‘read_exec’ and continue each time
> it’s hit, the ‘exec’ process starts just fine.
> 
> Could it be a synchronization issue somewhere?

It'd be surprising that you never gets the issue later on with the
system fully booted.

About the backtrace:

>>>>> user space <<<<<
0x1000(bfffff24,0,0,1160b,0)
0x11627(bfffff9c,0,0,0,2)
0x11bb()

That is quite surprising actually: in my ld.so there is nothing useful
at 0x1000. Perhaps you can check what 0x11627 is all about?

Also,

> Program Header:
>     LOAD off    0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
>          filesz 0x00000dd8 memsz 0x00000dd8 flags r--

We don't have this section in the Debian glibc. It'd probably be useful
to know what this is about.

>     LOAD off    0x00001000 vaddr 0x00001000 paddr 0x00001000 align 2**12
>          filesz 0x000244a1 memsz 0x000244a1 flags r-x
>     LOAD off    0x00026000 vaddr 0x00026000 paddr 0x00026000 align 2**12
>          filesz 0x0000d5e8 memsz 0x0000d5e8 flags r--
>     LOAD off    0x00033f60 vaddr 0x00034f60 paddr 0x00034f60 align 2**12
>          filesz 0x00001910 memsz 0x00001a6c flags rw-


Samuel