Synopsis: [tun] Killing tun0 iface ssh tunnel causes Panic String: page fault
State-Changed-From-To: open-closed
State-Changed-By: bz
State-Changed-When: Fri Oct 15 09:45:00 UTC 2010
State-Changed-Why:
Duplicate of PR kern/116837.
Responsible-Changed-From-To: freebsd-net-bz
On 4 Sep 2010, at 01:53, Pyun YongHyeon wrote:
On Fri, Sep 03, 2010 at 07:59:26AM +0100, Melissa Jenkins wrote:
Thank you for your very quick response :)
[...]
Also I'd like to know whether both RX and TX are dead or only one
RX/TX path is hung. Can you see incoming traffic with
On Thu, 14 Oct 2010, Attilio Rao wrote:
No, what I'm saying is: UMA needs to not call its drain handlers, and
ideally not call into VM to fill slabs, from the dumping context. That's
easy to implement and will cause the dump to fail rather than causing the
system to hang.
My point is,
On 15 Oct 2010, at 20:39, Garrett Cooper wrote:
But there are already some cases that aren't properly handled
today in the ddb area dealing with dumping that aren't handled
properly. Take for instance the following two scenarios:
1. Call doadump twice from the debugger.
2. Call doadump,
On Fri, Oct 15, 2010 at 12:25 PM, Robert Watson rwat...@freebsd.org wrote:
On Thu, 14 Oct 2010, Attilio Rao wrote:
No, what I'm saying is: UMA needs to not call its drain handlers, and
ideally not call into VM to fill slabs, from the dumping context. That's
easy to implement and will cause
On Fri, Oct 15, 2010 at 01:25:08PM +0100, Melissa Jenkins wrote:
On 4 Sep 2010, at 01:53, Pyun YongHyeon wrote:
On Fri, Sep 03, 2010 at 07:59:26AM +0100, Melissa Jenkins wrote:
Thank you for your very quick response :)
[...]
Also I'd like to know whether both RX and TX are
