Re: em watchdog problem

Jack Vogel wrote: This morning I had an idea about what the source of the watchdog problem is. Also, we have repro'd at least one type of watchdog inhouse. One question, is this problem only happening for those running STABLE with the 6.6.6 merged driver? We found the problem does not seem to h

Re: UDP catchall

On Tue, Oct 30, 2007 at 09:04:11PM +0100, Jeremie Le Hen wrote: > I can think of a possible implementation of mtund(8) without kernel > patching. The next pf(4) import from OpenBSD will likely allow to log > to some particular pflog(4) interface (instead of the default pflog0). > > It will then b

Re: UDP catchall

On Mon, Oct 29, 2007 at 07:49:47PM +, Bruce M. Simpson wrote: > Brooks Davis wrote: >> While I think this idea has some merit, I think we specifically want >> the current wildcard ability to allow for a system that requires >> minimal configuration. The problem with a range is that it doesn't

Re: TCP listenall

On Sat, Oct 27, 2007 at 04:55:15AM +0100, Bruce M. Simpson wrote: > listenallr is static and is going to get trashed by concurrent threads, > unless there is a serialization with a lock, which I don't see. I have used sys/netinet/ip_icmp.c:badport_bandlim() for inspiration. There it did not seem

Re: icmp echo_user

On Sat, Oct 27, 2007 at 03:56:29AM +0100, Bruce M. Simpson wrote: > Matus Harvan wrote: >> Hi, >> >> I was wondering if I could get some feedback about the patch and >> whether others think it could be committed. >> > > Thanks for your hard work on mtund. I'm not keen on this patch going into

In Memoriam: Jun-ichiro Hagino

A recent posting in BUGTRAQ[1] has announced that Itojun has passed away. Itojun was a past FreeBSD committer and very active in KAME and the IPv6 world. No details of his passing were in the BUGTRAQ posting but some information in Japanese is available at http://www.hoge.org/~koyama/itojun.txt

Re: UDP catchall

On Mon, Oct 29, 2007 at 07:49:47PM +, Bruce M. Simpson wrote: > Brooks Davis wrote: > > While I think this idea has some merit, I think we specifically want > > the current wildcard ability to allow for a system that requires > > minimal configuration. The problem with a range is that it does

em watchdogs - OS involvement

Things just keep getting stranger... its no wonder I didn't see this... I had been trying to repro the watchdog on a machine in my cube at work without success, but in the test Lab they were successful. I scratched my head for a while wondering why... But then I realized I had the Sept snapshot i

em watchdog problem

This morning I had an idea about what the source of the watchdog problem is. Also, we have repro'd at least one type of watchdog inhouse. One question, is this problem only happening for those running STABLE with the 6.6.6 merged driver? We found the problem does not seem to happen on 7.0. Right

Re: RFC: Evolution of the em driver

On 10/30/07, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > At Mon, 29 Oct 2007 10:45:17 -0700, > Jack Vogel wrote: > > > > I have an important decision to make and I thought rather than just make > > it and spring it on you I'd present the issues and see what opinions were. > > > > Our newer hardw

Re: Fwd: [PATCH] PF+dummynet

Ermal Luçi wrote: > Ok thanks to remko@ for hosting it! > > You can find it here: > http://people.freebsd.org/~remko/patches/dummynet_pf.tar.gz > > Please test and give feedback. I am really interested in your patch and hope that I will soon have time to test it. Meanwhile, I would like to ask

Re: kern/117456: ipv6 neighbour discovery / bce multicast problem

The following reply was made to PR kern/117456; it has been noted by GNATS. From: Jacek Zapala <[EMAIL PROTECTED]> To: [EMAIL PROTECTED] Cc: Subject: Re: kern/117456: ipv6 neighbour discovery / bce multicast problem Date: Tue, 30 Oct 2007 16:32:38 +0100 OK, it looks like I have reinvented the

Re: RFC: Evolution of the em driver

At Mon, 29 Oct 2007 10:45:17 -0700, Jack Vogel wrote: > > I have an important decision to make and I thought rather than just make > it and spring it on you I'd present the issues and see what opinions were. > > Our newer hardware uses new features that, more and more, require > parallel code pat

Re: Realtek Gigabit Network Card 0xd6088086

Daniel Dias Gonçalves wrote: > What is WIP version ? http://www.acronymfinder.com/af-query.asp?Acronym=WIP&Find=find&string=exact -- Tuomo ... Drawing on my fine command of language, I said nothing ___ freebsd-net@freebsd.org mailing list http://lis

Re: Realtek Gigabit Network Card 0xd6088086

Quoting Daniel Dias Gonalves, who wrote on Mon, Oct 29, 2007 at 06:40:59PM -0200 .. > Pyun YongHyeon escreveu: > >On Wed, Oct 24, 2007 at 10:28:46PM -0200, Daniel Dias Gon?alves wrote: > > > Hi, > > > > > > FreeBSD 6.2-STABLE can support this network card? > > > > > > [EMAIL PROTECTED]:0:0: clas

Re: RFC: Evolution of the em driver

I prefer (2) - non-intrusive on em, and the new one doesn't have to deal with legacy or backward compatibility with em. Any commonality with ixgbe? Later Brian. On 10/29/07, Jack Vogel <[EMAIL PROTECTED]> wrote: > > I have an important decision to make and I thought rather than just make > it

Re: Realtek Gigabit Network Card 0xd6088086

On Mon, Oct 29, 2007 at 06:40:59PM -0200, Daniel Dias Gon?alves wrote: > Pyun YongHyeon escreveu: > >On Wed, Oct 24, 2007 at 10:28:46PM -0200, Daniel Dias Gon?alves wrote: > > > Hi, > > > > > > FreeBSD 6.2-STABLE can support this network card? > > > > > > [EMAIL PROTECTED]:0:0: class=0x020

Re: RFC: Evolution of the em driver

Jack, you should know by now that we're not Linux. All we care about is that you not break the code that we rely on. I'm still slightly embarrassed when I explain to people that I build if_em as a module because em0 doesn't come up sometimes due to a race condition on initialization, so I need to b