I need to make work a scheme like this:
http://i.imgur.com/1xsXX.png
So, i have 3 servers: in, out1 and out2; out1 and out2 plugged into
one switched environment, so they can see each other on layer 2, which
is bad for me, because they can make a switching loop in some case.
out1 and out2 connec
Old Synopsis: [patch][if_em] BMC cannot receive IPMI traffic after loading or
enabling the if_em driver
New Synopsis: [em] [patch] BMC cannot receive IPMI traffic after loading or
enabling the if_em driver
Responsible-Changed-From-To: freebsd-bugs->freebsd-net
Responsible-Changed-By: linimon
Res
I'd also like to see the crash information. Does it crash when you
remove the adapter _always_? Or just when it stops functioning?
adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send
Hi,
On Tue, Oct 4, 2011 at 11:03 PM, Chuck Burns wrote:
> On Tuesday, October 04, 2011 9:41:22 PM Arnaud Lacombe wrote:
>
>>
>> You should now have message on the console, don't you ?
>>
>
>
> Actually. I'm not getting any more messages on my console than I have been
> getting before..
>
Lookin
On Tuesday, October 04, 2011 9:41:22 PM Arnaud Lacombe wrote:
>
> You should now have message on the console, don't you ?
>
Actually. I'm not getting any more messages on my console than I have been
getting before..
Some more information:
FreeBSD blackbeast.local 8.2-STABLE FreeBSD 8.2-STAB
Hi,
On Tue, Oct 4, 2011 at 10:32 PM, Chuck Burns wrote:
> On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote:
>
>> I'm not sure how to rebuild just the module with that option URTW_DEBUG
>> enabled.. I'm being told by some to just add the device to my kernel config
>> along with the line
On Tuesday, October 04, 2011 8:54:33 PM Chuck Burns wrote:
> I'm not sure how to rebuild just the module with that option URTW_DEBUG
> enabled.. I'm being told by some to just add the device to my kernel config
> along with the line "option URTW_DEBUG" .. but if there's a better way, let
> me know
My mail client gave no indication that the emails had been sent.. Won't
happen again.
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
On Tuesday, October 04, 2011 8:31:02 PM you wrote:
> Hi,
> could you report that panic, please ?
Well.. if I could get the dump to actually happen, I could report it
correctly, as it is, I will likely just have to take a picture of the screen
when it happens again, although the last few times t
I have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle,
and which uses the if_urtw module.
At random intervals, my internet connection just dies, I cannot ping the AP,
am told "Network is down" by ping.
The LED light on the adapter will have also gone out, and in dmesg, I g
Hi,
[Added driver author, Weongyo Jeong , to the CC: list]
On Tue, Oct 4, 2011 at 9:08 PM, Chuck Burns wrote:
> have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle,
> and which uses the if_urtw module.
>
> At random intervals, my internet connection just dies, I cannot pin
I have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle,
and which uses the if_urtw module.
At random intervals, my internet connection just dies, I cannot ping the AP,
am told "Network is down" by ping.
The LED light on the adapter will have also gone out, and in dmesg, I g
have a Netgear WG111v2 - which is a RealTek 8187 based usb 802.11G dongle,
and which uses the if_urtw module.
At random intervals, my internet connection just dies, I cannot ping the AP,
am told "Network is down" by ping.
The LED light on the adapter will have also gone out, and in dmesg, I ge
Hi,
On Thu, Mar 31, 2011 at 9:51 AM, Arnaud Lacombe wrote:
> Hi
>
> [let's start a new thread :)]
>
> On Wed, Mar 30, 2011 at 2:22 PM, Jack Vogel wrote:
>> Read the code in HEAD, em_local_timer() has a test of ALL the rx queues and
>> will schedule a task that refreshes mbufs if they are empty.
On Tue, Oct 04, 2011 at 11:16:52AM -0400, Arnaud Lacombe wrote:
> Hi,
>
> On Tue, Oct 4, 2011 at 10:39 AM, Adrian Chadd wrote:
> > The non-embedded atheros NICs (ie, not the ath6k series stuff) is all
> > run by the host CPU. There's no firmware that runs on the NIC.
> > This was why the HAL was
Hi,
Yes, I believe this patch will be part of RC1. I just need to follow
through with the release process. I will let you know once confirmed.
--Qing
> -Original Message-
> From: Matt Smith [mailto:m...@xtaz.co.uk]
> Sent: Tuesday, October 04, 2011 12:21 PM
> To: Li, Qing
> Cc: freebsd-
On 4 October 2011 19:17, Li, Qing wrote:
> Hi,
>
> Please download the newer patch from
>
> http://people.freebsd.org/~qingli/in6.c.diff
>
> This patch ought to fix both problems.
Just applied this patch. Yes, this fixes both problems. As far as I
can see now everything is working. So the
Hi,
Please download the newer patch from
http://people.freebsd.org/~qingli/in6.c.diff
This patch ought to fix both problems.
--Qing
> -Original Message-
> From: owner-freebsd-...@freebsd.org [mailto:owner-freebsd-
> n...@freebsd.org] On Behalf Of Li, Qing
> Sent: Tuesday, Octo
I believe there is actually another bug needs fixing. Let me confirm and will
provide
another patch later.
--Qing
From: Matt Smith [m...@xtaz.co.uk]
Sent: Tuesday, October 04, 2011 3:33 AM
To: Li, Qing
Cc: freebsd-net@freebsd.org
Subject: Re: gif interfac
Hi,
On Tue, Oct 4, 2011 at 10:39 AM, Adrian Chadd wrote:
> The non-embedded atheros NICs (ie, not the ath6k series stuff) is all
> run by the host CPU. There's no firmware that runs on the NIC.
> This was why the HAL was binary for so long. Note it is no longer
> binary and hasn't been for a few
Hi,
On Tue, Oct 4, 2011 at 8:28 AM, Adrian Chadd wrote:
> On 4 October 2011 16:37, Matthias Apitz wrote:
>>
>> yes; but with good datasheets this would be more easy;
>
> There's working code for the later chips in Linux and likely (via
> Linux) OpenBSD.
>
> Linux has b43 and brcm drivers. The so
The non-embedded atheros NICs (ie, not the ath6k series stuff) is all
run by the host CPU. There's no firmware that runs on the NIC.
This was why the HAL was binary for so long. Note it is no longer
binary and hasn't been for a few years.
So I think we can ignore the whole "binary firmware" proble
On Tue, Oct 04, 2011 at 10:37:10AM +0200, Matthias Apitz wrote:
> El d?a Tuesday, October 04, 2011 a las 03:34:46PM +0800, Adrian Chadd
> escribi?:
>
> > That's because it's a wifi chip, not an ethernet chip.
>
> Yes, I know and I looked around in their pages; there are no Wifi chips;
> so my qu
On Sat, 1 Oct 2011 14:15:45 +0800 dave jones wrote:
dj> On Fri, Sep 30, 2011 at 9:41 PM, Robert Watson wrote:
>>
>> On Wed, 28 Sep 2011, Mikolaj Golub wrote:
>>
>>> On Mon, 26 Sep 2011 16:12:55 +0200 K. Macy wrote:
>>>
>>> KM> Sorry, didn't look at the images (limited bw), I've seen someth
8.2-RELEASE and stable/8 have the same problem. Ping RTT triples
when MSIX is disabled.
On 10/3/2011 11:50 AM, Jack Vogel wrote:
Can you try the driver in 8.2 and possibly stable/8 to see the behavior there.
And, just curious, why are you disabling MSIX?
Jack
On Mon, Oct 3, 2011 at 12:51 AM
On 4 October 2011 16:37, Matthias Apitz wrote:
>
> yes; but with good datasheets this would be more easy;
There's working code for the later chips in Linux and likely (via
Linux) OpenBSD.
Linux has b43 and brcm drivers. The source is there - what's missing
is someone choosing one and porting it
On 4 October 2011 10:48, Matt Smith wrote:
> I have just applied the patch, recompiled the kernel, and rebooted
> with my original configuration in rc.conf and all interfaces have come
> up as expected now. The routes are there, I can ping everything, and I
> can connect to everything as expected.
On 3 October 2011 22:33, Li, Qing wrote:
> Please give the following patch a try and let me know how it
> works out for you.
>
> http://people.freebsd.org/~qingli/in6.c.diff
I have just applied the patch, recompiled the kernel, and rebooted
with my original configuration in rc.conf and all
El día Tuesday, October 04, 2011 a las 03:34:46PM +0800, Adrian Chadd escribió:
> That's because it's a wifi chip, not an ethernet chip.
Yes, I know and I looked around in their pages; there are no Wifi chips;
so my question was: why is this?
> We sorely need someone to step up and update the br
That's because it's a wifi chip, not an ethernet chip.
We sorely need someone to step up and update the broadcom wifi support. :)
adrian
___
freebsd-net@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, sen
30 matches
Mail list logo
