[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #106 from Cassiano Peixoto --- (In reply to Eugene Grosbein from comment #105) Ok, i kept web console on. I'm starting mpd5 using rc.d script: # ps -ax | grep mpd 1278 - Ss 25:03.78 /usr/local/sbin/mpd5 -p /var/run/mpd5

[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #105 from Eugene Grosbein --- (In reply to Cassiano Peixoto from comment #104) I do not think web console has any connection to this new problem, keep it on. How do you start mpd5 - do you use its standard startup (rc.d) script

[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #104 from Cassiano Peixoto --- Hi, It wasn't zombie, it looks like zombie because the kind of behavior. See process top output below: PID USERNAME THR PRI NICE SIZERES STATE C TIMEWCPU COMMAND 1295 root

[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #103 from Eugene Grosbein --- (In reply to Cassiano Peixoto from comment #101) In fact, a zombie process is not a process anymore. It does not prevent your from restarting new instance of mpd5. Did you look at ps output to chec

[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 Eugene Grosbein changed: What|Removed |Added Flags|maintainer-feedback?(mav@Fr |maintainer-feedback+

[Bug 186114] net/mpd5 hangs after a certain number of users connect

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=186114 --- Comment #101 from Cassiano Peixoto --- (In reply to Konstantin Belousov from comment #100) Hi guys, I had the issue today, but with a different behavior. It didn't show on CPU state as uwrlck anymore. The process was running as usual,

Re: m_move_pkthdr leaves m_nextpkt 'dangling'

2017-07-05 Thread Adrian Chadd
On 30 June 2017 at 08:42, Karim Fodil-Lemelin wrote: > Hi, > > As many of you know, when dealing with IP fragments the kernel will build a > list of packets (fragments) chained together through the m_nextpkt pointer. > This is all good until someone tries to do a M_PREPEND on one of the packet > i

Fwd: AW: axge0 and AX88179

2017-07-05 Thread Oleg Lelchuk
-- Forwarded message -- From: Oleg Lelchuk Date: Wed, Jul 5, 2017 at 10:17 AM Subject: Re: AW: axge0 and AX88179 To: Hans Petter Selasky You are addressing it to Shteryana, right? On Wed, Jul 5, 2017 at 7:21 AM, Hans Petter Selasky wrote: > On 07/05/17 07:28, Oleg Lelchuk wro

[Bug 148807] [panic] "panic: sbdrop" and "panic: sbsndptr: sockbuf _ and mbuf _ clashing" (8.1-RELEASE/10.1-STABLE/11-CURRENT)

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=148807 Kubilay Kocak changed: What|Removed |Added Resolution|FIXED |Not Enough Information --- Comment

[Bug 218653] Intel e1000 network link drops under high network load

2017-07-05 Thread bugzilla-noreply
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218653 Kubilay Kocak changed: What|Removed |Added Status|Open|Closed Resolution|---

Re: AW: axge0 and AX88179

2017-07-05 Thread Hans Petter Selasky
On 07/05/17 07:28, Oleg Lelchuk wrote: Yes, I am having exactly the same problem that Shteryana described. I also got messages about wrong ip length when I started dhclient for ue0. If I plug my device into a usb 2.0 port and enable flow control, I get networking speeds that are around 250 Mbit/s

Re: NULL pointer dereference bug triggered by netmap

2017-07-05 Thread Marius Strobl
On Mon, Jul 03, 2017 at 05:08:09PM +0200, Vincenzo Maffione wrote: > Details here: > > https://github.com/luigirizzo/netmap/issues/322 > > Is it acceptable to commit the proposed patch? As suggested by hselasky@, the outliner problem at hand is better solved by a dummy if_start method in order t