On Sun, 8 Mar 1998, Andreas Gustafsson wrote:

> > This can apparently be run into in the procfs/ptreace() code, as well,
> > in certain circumstances.  (I think Mark Brinicombe knows them better
> > than I; i've cc'd him in case he's on port-i386.)
> 
> I think I just ran into one of those circumstances.  I was debugging a
> program using gdb, and when I issued a "run" command, the machine
> crashed.  I was running X on the console, so I didn't get a debugger
> prompt, but when I tried repeating the debugging session without X, I
> got a "panic: ptdi 24bf063".  I suppose that means the bug is
> repeatable.  The ddb backtrace showed the following functions:
> 
>   _Debugger
>   _panic
>   _pmap_enter
>   _vm_fault
>   _gcc2_compiled
>   _procfs_domem
>   _sys_ptrace
>   _syscall

Hi,
  Yes this is the problem I hit trying to debug a static netscape binary
~70MB. I had exactly the same problem on arm32 which is not surprising
since the arm32 pmap was based on the i386 one originally.
The problem is that procfs_domem tries to fault in the page directly with
vm_fault(). However with the old pmap (pre UVM) pmap_enter() required that
a page table already existed for the page being mapped. In the fault
handler in trap.c a specific check is made and if a page table does not
exist an additional vm_fault() call is made to obtain a page table prior
to the vm_fault() call to map the actual faulting page. procfs_domem()
misses this code so a panic situation can arise.

With UVM pmap_enter() can handling mapping the page table if it does not
exist (I believe) so this problem goes away.

Cheers,
				Mark