>Number:         10016
>Category:       kern
>Synopsis:       ddb can get stuck in infinite uvm_fault()ing
>Confidential:   no
>Severity:       serious
>Priority:       low
>Responsible:    kern-bug-people
>State:          open
>Class:          sw-bug
>Submitter-Id:   net
>Arrival-Date:   Sat Apr 29 20:06:00 PDT 2000
>Closed-Date:
>Last-Modified:
>Originator:     John Hawkinson
>Release:        29 April 2000
>Organization:
MIT
>Environment:
	
System:
NetBSD zorkmid.mit.edu -current
NetBSD 1.4X (ZORKMID) #8: Sat Apr 29 22:31:17 EDT 2000
M    jhawk@zorkmid.mit.edu:/usr/local/current-src/sys/arch/i386/compile/ZORKMID

>Description:
	ddb can get stuck spewing seemingly infinite uvm_fault()s at
the user. a BREAK doesn't break out of this. Power cycling seems to
be the only way out.

	This is poor. It should be possible to debug kernels across a
serial link with ddb without having remote power cycling gear. I'd
hate to try to debug some problem that was hitting a remote production
server and find that I had hung that machine and it required someone
to go visit it in person.

>How-To-Repeat:
	In this case, attempt to debug a problem with pnpbios code
rebooting on a Sony VAIO PCG-Z505HE after the lpt probe.

> NetBSD/i386 BIOS Boot, Revision 2.6
>Fix:
	Fix uvm_fault()s not to loop like that?
	Perhaps have db_more allow breaking out with
	a 'q' keypress?
>Release-Note:
>Audit-Trail:
>Unformatted:
 >> (jhawk@zorkmid.mit.edu, Tue Apr 25 14:38:24 EDT 2000)
 >> Memory: 638/64448 k
 Use hd1a:netbsd to boot sd0 when wd0 is also installed
 Press return to boot now, any other key for boot menu
 booting wd0a:netbsd - starting in 0
 type "?" or "help" for help.
 > boot /cnetbsd -ds
 booting wd0a:/cnetbsd (howto 0x42)
 3428352+249856+294132+[184836+229274]=0x42ee96
 [ netbsd ELF symbol table not valid ]
 ^M[ preserving 414112 bytes of netbsd a.out symbol table ]
 ^MStopped in  at  _cpu_Debugger+0x4:      leave
 ^Mdb> b lpt_pnpbios_attach
 ^Mdb> c
 ^MCopyright (c) 1996, 1997, 1998, 1999, 2000
 ^M    The NetBSD Foundation, Inc.  All rights reserved.
 ^MCopyright (c) 1982, 1986, 1989, 1991, 1993
 ^M    The Regents of the University of California.  All rights reserved.
 
 ^MNetBSD 1.4X (ZORKMID) #8: Sat Apr 29 22:31:17 EDT 2000
 ^M    jhawk@zorkmid.mit.edu:/usr/local/current-src/sys/arch/i386/compile/ZORKMID
 ^Mcpu0: family 6 model 8 step 1
 ^Mcpu0: Intel Pentium III (E) (686-class)
 ^Mtotal memory = 65088 KB
 ^Mavail memory = 55840 KB
 ^Musing 839 buffers containing 3356 KB of memory
 ^MBIOS32 rev. 0 found at 0xfd880
 ^Mmainbus0 (root)
 ^Mpnpbios0 at mainbus0: nodes 17, max len 210
 ^Mcom3 at pnpbios0 index 14 (PNP0501)
 ^Mcom3: io 3f8-3ff, irq 4
 ^Mcom3: ns16550a, working fifo
 ^Mcom3: console
 ^Mlpt3 at pnpbios0 index 18 (PNP0401)Breakpoint in swapper at        _lpt_pnpbio
 s_attach:    pushl   %ebp
 ^Mdb> until
 ^MAfter 13 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _lpt_pnpbios_attach+0x1a:       call    _pnpbios_io_ma
 p
 ^Mdb> next
 ^MAfter 210 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _pnpbios_io_map+0x47:   ret
 ^Mdb> n
 
 ^Mlpt3: io 378-37f 778-77f, irq 7, dma 3
 ^MAfter 26223 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _lpt_pnpbios_attach+0x68:       ret
 ^Mdb> n
 ^MAfter 26 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _config_attach+0x31e:   ret
 ^Mdb> n
 ^MAfter 7 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _config_found_sm+0x4c:  ret
 ^Mdb> u
 ^MAfter 9 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _pnpbios_attachnode+0x2ac:      ret
 ^Mdb> u
 ^MAfter 14 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _pnpbios_attach+0x1e5:  call    _pnpbios_getnode
 ^Mdb> u
 ^MAfter 20 instructions (0 loads, 0 stores),
 ^MStopped in swapper at   _pnpbios_getnode+0x65:  call    _pnpbioscall
 ^Mdb> u
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^Mkernel: page fault trap, code=0
 ^Muvm_fault(0xc04a561c, 0x0, 0, 1) -> 1
 ^M--db_more-
 
 Note the debugger --db_more- prompt.
 Kind of ironic, I think.