Re: Deadlock in the routing code

Maxime Henrion wrote: > Julian Elischer wrote: > > Gleb Smirnoff wrote: > > >On Thu, Dec 13, 2007 at 10:33:25AM -0800, Julian Elischer wrote: > > >J> Maxime Henrion wrote: > > >J> > Replying to myself on this one, sorry about that. > > >J>

Re: Deadlock in the routing code

Julian Elischer wrote: > Gleb Smirnoff wrote: > >On Thu, Dec 13, 2007 at 10:33:25AM -0800, Julian Elischer wrote: > >J> Maxime Henrion wrote: > >J> > Replying to myself on this one, sorry about that. > >J> > I said in my previous mail that I didn'

Re: Deadlock in the routing code

Stephen Clark wrote: > Maxime Henrion wrote: > > >Replying to myself on this one, sorry about that. > > > >I said in my previous mail that I didn't know yet what process was > >holding the lock of the rtentry that the routed process is dealing > >with in r

Re: Deadlock in the routing code

Gleb Smirnoff wrote: > On Thu, Dec 13, 2007 at 10:33:25AM -0800, Julian Elischer wrote: > J> Maxime Henrion wrote: > J> > Replying to myself on this one, sorry about that. > J> > I said in my previous mail that I didn't know yet what process was > J> >

Deadlock in the routing code

Replying to myself on this one, sorry about that. I said in my previous mail that I didn't know yet what process was holding the lock of the rtentry that the routed process is dealing with in rt_setgate(), and I just could verify that it is held by the swi1: net thread. So, in a nutshell: - The

Deadlock in the routing code

Hi, We've been experiencing frequent deadlocks within the routing code with our gateway servers that are running routed. I finally got sufficient information to precisely pinpoint the problem, so here we go... DDB was helpful in leading me to understanding: chain 1: thread 14 (pid

Re: NVE

K?vesd?n G?bor wrote: > I have installed the HEAD kernel. Is it necessary to upgrade the > userland to HEAD too for testing your fixes? It's not required for testing my fix, though your system may not work with a RELENG_6 userland. I'm not sure about that, and given that RELENG_6 got branched no

Re: NVE

K?vesd?n G?bor wrote: > Maxime Henrion wrote: > > >K??vesd??n G??bor wrote: > > > > > >>[EMAIL PROTECTED] wrote: > >> > >> > >> > >>>Hello list users. > >>> > >>>I have bougth motherboard Epox 8kd

Re: NVE

K??vesd??n G??bor wrote: > [EMAIL PROTECTED] wrote: > > >Hello list users. > > > >I have bougth motherboard Epox 8kda3J, which has NV ethernet adapter MCP7. > >My system was FreeBSD 5.4 and i found NV MCP Driver for FreeBSD here: > >http://www.onthenet.com.au/~q/nvnet/ > >Ok, I got it, install and

Re: Plan to remove GIANT dependence in ixgb driver

ve got a concern about > > this or have already started work... > > > > Great, finally someone with ixgb hardware :-) Would you be interested > in testing out some patches? (altq support and per-interface polling) > Also, Maxime Henrion committed a busdma change to HEAD a couple of

Re: [PATCH] Make em(4) use device sysctl tree

Ackerman, Tony wrote: > Bruce, > Aren't the calls to sysctl_ctx_free() still required? They aren't required because the sysctl tree and the sysctl context are both created by the newbus framework, and also destroyed by the said framework if a device detaches. However, your comment made me

Re: [PATCH] Make em(4) use device sysctl tree

Bruce M Simpson wrote: > Here is a non-critical patch to bring em(4) into line with other > drivers, by using the sysctl tree created for each device by the > bus framework. > > Please review; Thanks. > BMS [patch ripped] Looks good to me. Cheers, Maxime _

Re: malloc (0)

Petri Helenius wrote: > > I?m asking the net list because I came across this when browsing through > the networking / resolver code. > > The question is if the code should check for zero value before calling > malloc or is malloc(0) legal if the pointer is never used? > > I came across this wh

Re: problems with stf(4) and ipv6_gateway_enable

Hajimu UMEMOTO wrote: > Hi, > mux> Well, my interface which is connected to the net is xl1. The interface > mux> connected to the local subnet is xl0. If I change rtadvd_interfaces to > mux> xl1, ping6 on the box behind the router gets a no route to host while > mux> the DNS lookup worked before,

Re: problems with stf(4) and ipv6_gateway_enable

Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Wed, 6 Nov 2002 09:25:34 -0800 > >>>>> Maxime Henrion <[EMAIL PROTECTED]> said: > > mux> However, it still doesn't seem to work properly. When pinging an IPv6 > mux> host from a box in

Re: problems with stf(4) and ipv6_gateway_enable

Hajimu UMEMOTO wrote: > Hi, > > >>>>> On Tue, 5 Nov 2002 17:00:40 -0800 > >>>>> Maxime Henrion <[EMAIL PROTECTED]> said: > > mux> ipv6_enable="YES" > mux> ipv6_defaultrouter="2002:c058:6301::&qu

problems with stf(4) and ipv6_gateway_enable

Hi all, I'm having problems setting my box as an ipv6 router. It's already doing 6to4 using the following configuration without problems. ipv6_enable="YES" ipv6_defaultrouter="2002:c058:6301::" # Use this for 6to4 (RFC 3068) ipv6_prefix_xl1="2002:5143:8351:"

Re: review request: minor cloning API change

Brooks Davis wrote: > The following patch reverts a previous API change which change the > return value of a clonable interfaces' destory function from void to > int to allow the interface to refuse to delete a unit. Since we now > manage unit creation in the generic cloning code and the only use

[CFR] Patch for clonable interfaces

Hi, Currently, every clonable interface which uses the if_clone_*() framework has a chunk of duplicated rman code to handle unit allocation. This is exactly the same code in every clonable interface driver. Moreover, this code is only used in the case of a "wildcard" creation, i.e. when