I suspect this may just be a case of "don't DO that," but in case anyone
cares, I've inadvertantly discovered that if you configure a gif interface
with no route to the far endpoint, then point the default route *over*
that gif interface, the kernel will hang.

Here's what ddb shows at that point:

Stopped in pid 1495.1 (ntpd) at netbsd:cpu_Debugger+0x4:        popl    %ebp
db> trace/u
cpu_Debugger(0,0,0,0,800) at netbsd:cpu_Debugger+0x4
comintr(c04a5400,5,c02e0010,30,10) at netbsd:comintr+0xcd
Xintr_legacy4() at netbsd:Xintr_legacy4+0xa4
--- interrupt ---
m_adj(c08ff200,ffffffec,c08ff944,0,1) at netbsd:m_adj+0xb4
ip_fragment(c08ff200,c0571000,14,c0515e80,0) at netbsd:ip_fragment+0x2e3
ip_output(c08ff200,0,c05711e4,0,0) at netbsd:ip_output+0x781
in_gif_output(c0571000,2,c08ff200,4fc,c0565d40) at netbsd:in_gif_output+0x26f
gifintr(c0571000,0,c0100b1e,c6b7fe78,c0102884) at netbsd:gifintr+0xd1
softintr_dispatch(1,23d0,c0557100,0,c6b7feb0) at netbsd:softintr_dispatch+0xa7
Xsoftnet() at netbsd:Xsoftnet+0x54
--- interrupt ---
uvm_fault(0xc6ae2370, 0, 0, 1) -> 0xe
kernel: page fault trap, code=0
Faulted in DDB; continuing...
db> 

I discovered this while configuring a box to be a wireless router;
the interface that the route to the far end of the gif tunnel would have
been over wasn't inserted, and it took me a fair while to figure
out that this is what was happening (since the configuration had worked
just swimmingly before).  

To duplicate, on a system with no configured interfaces:

ifconfig gif0 create
ifconfig gif0 tunnel 192.168.1.1 192.168.1.2
ifconfig gif0 192.168.100.1 192.168.100.2 netmask 255.255.255.252
ifconfig gif0 up
route add default 192.168.100.2
ping 192.168.255.1 

...and there you go.

This is on a 1.6ZG/i386 system, in case it matters.

(Thanks to David Young for the ddb help)

+j

-- 
Jeff Rizzo                                         http://boogers.sf.ca.us/~riz