I think this ctrl+C is important to the problem :)

One thing I need you to help confirm is that does w3m put the socket
into nonblock mode?  I didn't seem to be able to download w3m source
code.

I think it may be caused by following pattern of user code:

s = socket();
/* s is not put into nonblock mode */
while (1) {
  if (connect(s) < 0) {  <==== here you hit ctrl+C
    if (errno == EINTR)
      continue; <==== another connect(2) attempt on 's'
    ...
  }
  ...
}

We probably could create a much simpler test program by using the
above code pattern to reproduce the panic ...

The things from the dump related to my following assumption are:
1) so_state is 0
2) inpcb is on hash list (both the flag and the link fields prove that)

I think following things happened, if w3m used the code pattern I listed above:
- connect(2) is blocking, so first calling of connect(2) will make
kern_connect() block on lwkt_domsg()
- ctrl+C will make the lwkt_domsg() in kern_connect() return.
SS_ISCONNECTING is cleared on so_state, then so_state becomes 0, but
inpcb is left on hash list since former soconnect() succeeded.
- the second connect(2) syscall hits the wall (soconnect calls
so_pru_connect, since so_state is 0)

I will appreciate if you could reproduce the panic by using the user
code I mention above.  I probably could not do it today, I could not
go back home before 10pm today :(

Best Regards,
sephe