On Thu, May 22, 2008 at 1:41 AM, Max Laier <[EMAIL PROTECTED]> wrote:
> I think if_ether.c would be good, where arp_ifinit() is.
>
Here is what i've come up with (some comments after the patch) :
diff -ur /usr/src/.zfs/snapshot/orig/sys/net/if.c /usr/src/sys/net/if.c
--- /usr/src/.zfs/snapshot/or
On Thursday 22 May 2008 00:14:37 Niki Denev wrote:
> On Thu, May 22, 2008 at 12:32 AM, Max Laier <[EMAIL PROTECTED]> wrote:
> > On Wednesday 21 May 2008 23:22:52 Niki Denev wrote:
> >> On Thu, May 22, 2008 at 12:05 AM, Max Laier <[EMAIL PROTECTED]>
wrote:
> >> > Looks good, though I'd probably mov
On Thu, May 22, 2008 at 12:32 AM, Max Laier <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 May 2008 23:22:52 Niki Denev wrote:
>> On Thu, May 22, 2008 at 12:05 AM, Max Laier <[EMAIL PROTECTED]> wrote:
>> > Looks good, though I'd probably move up the _INVOKE to before the
>> > ARPs are sent out. Prob
On Mon, 10 Mar 2008, Robert Watson wrote:
This is another of those boring e-mails about kernel subsystems that still
require Giant. Sorry about that!
As previously published, netatm is a non-MPSAFE protocol stack largely
superseded by our two other ATM stacks, netnatm and the netgraph/atm (
On Wednesday 21 May 2008 23:22:52 Niki Denev wrote:
> On Thu, May 22, 2008 at 12:05 AM, Max Laier <[EMAIL PROTECTED]> wrote:
> > Looks good, though I'd probably move up the _INVOKE to before the
> > ARPs are sent out. Probably between twiddling the hardware and
> > sending ARPs (though that needs
On Thu, May 22, 2008 at 12:05 AM, Max Laier <[EMAIL PROTECTED]> wrote:
> Looks good, though I'd probably move up the _INVOKE to before the ARPs are
> sent out. Probably between twiddling the hardware and sending ARPs
> (though that needs an else-case if the interface is still down). In fact
> the
On Wednesday 21 May 2008 22:44:42 Niki Denev wrote:
> On Wed, May 21, 2008 at 8:44 PM, Max Laier <[EMAIL PROTECTED]> wrote:
> >> It doesn't (and shouldn't have to). I'd simply add an
> >> EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do
> >> that for INET[6] address already. Then
On Wed, May 21, 2008 at 1:26 PM, Jack Vogel <[EMAIL PROTECTED]> wrote:
> On Wed, May 21, 2008 at 12:11 PM, Neil Hoggarth <[EMAIL PROTECTED]> wrote:
>> Hi Folks,
>>
>> I opened PR kern/122928 last month, describing my problems with Intel
>> PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driv
On Wed, May 21, 2008 at 8:44 PM, Max Laier <[EMAIL PROTECTED]> wrote:
>> It doesn't (and shouldn't have to). I'd simply add an
>> EVENTHANDLER_INVOKE(ifaddr_event, ifp) to if_setlladdr() - we do that for
>> INET[6] address already. Then vlan (and any other device interested in
>> LLaddress change
On Wed, May 21, 2008 at 12:11 PM, Neil Hoggarth <[EMAIL PROTECTED]> wrote:
> Hi Folks,
>
> I opened PR kern/122928 last month, describing my problems with Intel
> PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driver: every
> so often the machine would get into a state where it would repeat
On Wed, May 21, 2008 at 8:44 PM, Max Laier <[EMAIL PROTECTED]> wrote:
> On Wednesday 21 May 2008 19:31:46 Niki Denev wrote:
>> If one tries to use lagg0.2 style vlans on lagg0 interface configured
>> from rc.conf it does't work.
>> The problem is that all of the cloned interfaces (lagg0 , lagg0.2,
Hi Folks,
I opened PR kern/122928 last month, describing my problems with Intel
PRO/1000 MT adaptor on 7-STABLE, with v6.7.3 of the em driver: every
so often the machine would get into a state where it would repeatedly
watchdog timeout the em0 interface, and the interface would stop
receiving pac
On Wednesday 21 May 2008 19:31:46 Niki Denev wrote:
> If one tries to use lagg0.2 style vlans on lagg0 interface configured
> from rc.conf it does't work.
> The problem is that all of the cloned interfaces (lagg0 , lagg0.2, etc)
> are created before any other interface configuration is done,
> and
If one tries to use lagg0.2 style vlans on lagg0 interface configured
from rc.conf it does't work.
The problem is that all of the cloned interfaces (lagg0 , lagg0.2, etc)
are created before any other interface configuration is done,
and in this case lagg0 is created, then lagg0.2 is created.
But be
Synopsis: [re][patch] Realtek RTL8111C detection and failure
Responsible-Changed-From-To: freebsd-net->rpaulo
Responsible-Changed-By: rpaulo
Responsible-Changed-When: Wed May 21 10:36:18 UTC 2008
Responsible-Changed-Why:
I'm working on a patch since NetBSD seems to support this card.
http://www.
15 matches
Mail list logo