A while back I opened PR5624 regarding a crash I was seeing fairly
frequently (due to pppasyncstart accessing a freed mbuf).

Using MALLOCLOG and some guesses, I've now found some circumstantial
evidence which points at the culprit.

I believe that the following is happening:

The system is running pppasyncstart at splsoftnet.
An ethernet receive interrupt happens.
The packet gets fed to ether_input
ether_input calls ipflow_fastforward
ipflow_fastforward calls pppoutput 
pppoutput calls pppasyncstart (through sc->sc_start).

the inner invocation of asyncstart frees the mbuf in use by the outer
one, and we fall over when we return to the outer one.

Jason's immediate thought was that pppasyncstart should run at splnet.
I think that's probably overkill (given that compression happens in
asyncstart, which is is relatively CPU-intensive), but I don't know
the code very well; it would make more sense to protect a smaller
critical region around the queues..

					- Bill