Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon

> > The reason is performance for overall network stack, not ideology. > For a practical reasons, "it works but slow" is better than > "doesn't work at all (due to absence of code in the src tree)". > "Make it work. Make it right. Make it fast. In that order", know this? > Sacrificing "work" for "

Re: MSIX failure

On Tue 2010-09-07 (10:00), Jack Vogel wrote: > First off, this device was not supported in 8.0 REL, what were you running > that last worked? Hey, I was running 8.0 REL and it worked. I installed the system from the 8.0 .iso, but the onboard card didn't work. I added the PCI card and it worked. >

Re: MSIX failure

On Tue 2010-09-07 (13:25), Jack Vogel wrote: > I've looked at the code, this message was misleading, what really happens > is that the driver fails to be able to setup either MSIX OR MSI, when this > happens it will fall back and use a Legacy interrupt, so its non-fatal and > the device should work

Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)

Hi v...@freebsd.org! On Wed, 08 Sep 2010 07:01:55 +0200; v...@freebsd.org wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': > On 09/07/10 23:31, Vadim Goncharov wrote: >> 07.09.10 @ 18:53 Andriy Gapon wrote: >>> The reason is performance for overall network stack, not ideology.

Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)

Hi Doug Barton! On Tue, 07 Sep 2010 20:37:07 -0700; Doug Barton wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': > On 09/07/2010 02:31 PM, Vadim Goncharov wrote: >> 07.09.10 @ 18:53 Andriy Gapon wrote: >> >>> on 07/09/2010 13:38 Vadim Goncharov said the following: > Just to

Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)

Hi Mark Linimon! On Wed, 8 Sep 2010 07:30:19 +; Mark Linimon wrote about 'Re: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon': >>> The reason is performance for overall network stack, not ideology. >> For a practical reasons, "it works but slow" is better than >> "doesn't work at all (due

Re: Network memory allocation failures

Please provide output from the following: netstat -m /etc/sysctl.conf 08.09.2010 1:24, Jeremy Chadwick wrote: > Please provide output from the following: > > * uname -a(if desired, XXX out hostname) > * vmstat -i > * ifconfig -a (if desired, XXX out IPs and MACs) > * netstat -inbd

Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)

On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: > > Because the original I4B code didn't > > work without the Giant lock, and because no one stepped forward to fix > > that, the code had to be removed. > > No. The code needn't removal, the stack should be modified to be fast w

Re: Policy for removing working code

Hi John Baldwin! On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': > On Wednesday, September 08, 2010 6:24:11 am Vadim Goncharov wrote: >>> Because the original I4B code didn't >>> work with

Re: Policy for removing working code

on 08/09/2010 17:01 Vadim Goncharov said the following: > Big thanks for your work, but unfortunately, the problem itself is not ISDN or > network stack, it is deeper. It is the policy or may be style of thought, > discourse. Something like: >progress dictates we need fix/maintainership to feat

Re: Policy for removing working code

[ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: > Hi John Baldwin! > > On Wed, 8 Sep 2010 08:42:28 -0400; John Baldwin wrote about 'Re: Policy for > removing working code (Was: HEADS UP: FreeBSD 6.4 and 8.0 EoLs coming soon)': > > > On Wednesday, Se

Re: Network memory allocation failures

On Tue, Sep 07, 2010, Jeremy Chadwick wrote: > > I figured there might memory exhaustion of sorts, possibly in the bce(4) > driver itself, that could cause the OP's problem. bce(4) might not be > the problem at all. But the OP's issue seems to only occur when > transmitting data, not receiving:

Re: Network memory allocation failures

On Tue, Sep 07, 2010, Pyun YongHyeon wrote: > > [...] > > You may see more detailed MAC statistics if controller saw some kind > of memory related failure from the output of "sysctl dev.bce.0". Snagged that output immediately after an allocation error. I don't see anything "bad" here, but sendi

Re: Policy for removing working code

John Baldwin wrote: [ Trimming cc's a bit ] On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: Big thanks for your work, but unfortunately, the problem itself is not ISDN or network stack, it is deeper. It is the policy or may be style of thought, discourse. Something like:

Re: Policy for removing working code

On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: > John Baldwin wrote: > > [ Trimming cc's a bit ] > > > > On Wednesday, September 08, 2010 10:01:22 am Vadim Goncharov wrote: > > >> Big thanks for your work, but unfortunately, the problem itself is not > >> ISDN or > >> network stac

RE: if_rtdel: error 47 (netgraph or mpd issue?)

At 07:24 PM 9/1/2010, Li, Qing wrote: http://svn.freebsd.org/viewvc/base/head/sys/netinet/in.c?r1=201811&r2=20 3401 Maybe related and something similar needs to be done for IPv6 ... Hi, Another 6 days and another crash. The coredump seems to be in the same location as before

Re: Policy for removing working code

Erik Trulsson wrote: On Wed, Sep 08, 2010 at 03:31:11PM +0100, Mark Blackman wrote: On top of which, I'd say that the general philosopy is always that you stick with the release that works for you. Surely the people who "need" those ISDN drivers, simply stay with the release that works for the

Re: if_rtdel: error 47 (netgraph or mpd issue?)

At 11:30 AM 9/8/2010, Vlad Galu wrote: On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: [...] FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No Netgraph on that box. Unfortunately, the stack was too corrupted to be able to see the outer frames. Hi, Actually, I d

Re: if_rtdel: error 47 (netgraph or mpd issue?)

On Wed, Sep 8, 2010 at 6:12 PM, Mike Tancsa wrote: [...] FWIW, I've had a few crashes in if_rtdel() while playing with ECMP. No Netgraph on that box. Unfortunately, the stack was too corrupted to be able to see the outer frames. -- Good, fast & cheap. Pick any two. _

Re: MSIX failure

This is what'd I'd expect, the onboard is PCH chipset, support was not in 8.0, but as I said, in 8.1 (and hence stable/8) it is supported, and it should work. I do not know why you don't have MSI support, but it should still work with Legacy interrupts. Jack On Wed, Sep 8, 2010 at 2:40 AM, Gare

Re: Network memory allocation failures

On Wed, Sep 08, 2010 at 07:34:44AM -0700, Mahlon E. Smith wrote: > On Tue, Sep 07, 2010, Jeremy Chadwick wrote: > > > > I figured there might memory exhaustion of sorts, possibly in the bce(4) > > driver itself, that could cause the OP's problem. bce(4) might not be > > the problem at all. But t

Re: My kernel panics suck

* William D. Colburn (Schlake) [100702 12:19] wrote: > I got my new 8-stable system up, and now I just have recurrent disk > controller failures. The machine can't stay more than about ten > minutes before it panics into a hung kernel, or simple reboots. > Unfortunately, I know the root cause of

RE: if_rtdel: error 47 (netgraph or mpd issue?)

I am working with Mike offline. -- Qing > -Original Message- > From: Mike Tancsa [mailto:m...@sentex.net] > Sent: Wednesday, September 08, 2010 8:35 AM > To: Vlad Galu > Cc: Li, Qing; freebsd-stable@freebsd.org > Subject: Re: if_rtdel: error 47 (netgraph or mpd issue?) > > At 11:30 AM 9