Date: Tue, 27 Jun 2017 17:45:11 +0000 From: bugzilla-noreply@freebsd.org To: freebsd-bugs@FreeBSD.org Subject: [Bug 219375] vm_fault: fault on nofault entry, addr: fffffe001ff0a000 Message-ID: <bug-219375-8-5ICLmRUNwA@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-219375-8@https.bugs.freebsd.org/bugzilla/> References: <bug-219375-8@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D219375 --- Comment #1 from bobf@mrp3.com --- It appears that one other factor may be involved. As I recall, the problem is NOT showing up when the icecast server isn't running, while being fed an audio stream by 'ices'. Often I was leaving this running even when I wasn't listening to the stream= on a streaming radio that's on my LAN. However, lately, I've been shutting off the audio feed by killing 'ices' (icecast remains running). The installed packages are: icecast2-2.4.3,1 ices-2.0.2_3,1 In the past I have seen some odd performance-related problems with transfer= ring large amounts of data over 'localhost', with applications like iperf (stall= s, lost packets and 'out of buffer space' and similar problems, basically). I have not attempted to reproduce this in FBSD-11 however, but if the stack hasn't changed much this COULD be related. When ices feeds icecast with content, I'm pretty sure it uses localhost to = do it. If not, it's probably using a socket or a pipe. Whichever case this i= s, it's running for DAYS or even WEEKS sometimes, possibly with leakage, or internal corruption, or something else. A typical trigger for the reported problem is a video-related event, such as switching from full screen video back to whatever video mode the GUI is usi= ng.=20 In a few cases it has been caused by attempting to open up a new firefox wi= ndow or a new tab within firefox (i.e. following a link from something else, suc= h as an e-mail). It's possible that it's "the trigger" PLUS the socket/pipe/whatever that ices+icecast is using. It's also possible that it's just creating a rare condition within memory or the kernel configuration that surfaces a bug. But if it _IS_ network stack related, particularly with the 'localhost' adaptor, then this information might be helpful in isolating a potentially = big problem. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-219375-8-5ICLmRUNwA>