Hello,
I'm using BCM5715C based NIC card on a FreeBSD 7.2 system. I would like to
simulate condition where the PHY layer is powered-off i.e, the link status
should show as "no carrier". When I do "ifconfig down", it just turns-off the
driver and the link status is still active. Is there is anyt
On Thu, Sep 23, 2010 at 12:41 PM, Sushanth Rai wrote:
> Hello,
>
> I'm using BCM5715C based NIC card on a FreeBSD 7.2 system. I would like to
> simulate condition where the PHY layer is powered-off i.e, the link status
> should show as "no carrier". When I do "ifconfig down", it just turns-off
> t
Hi,
we are seeing these errors repeatedly on a new Dell R300 server:
Sep 23 15:06:29 vcomm kernel: bge0: watchdog timeout -- resetting
Sep 23 15:06:29 vcomm kernel: bge0: link state changed to DOWN
Sep 23 15:06:31 vcomm kernel: bge0: link state changed to UP
Server OS is:
FreeBSD vcomm 7.3-R
On 09/13/2010 03:53 PM, Pyun YongHyeon wrote:
> On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote:
>
>> On 09/13/2010 02:33 PM, Pyun YongHyeon wrote:
>>
>>> On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wrote:
>>>
>>>
>> Without BCE_JUMBO_HDRSPLIT then we see no
Lasse Brandt wrote
in <6be964c4-0838-4da6-9278-12c620ca1...@bitmand.com>:
la> 1) Is the hosting provider actually forcing me to do something "bad"
la> og plain wrong?
In that situation normally you get an IP address in the /59 network
to communicate with the gateway router from ISP. An IP a
On Fri, 24 Sep 2010, Hiroki Sato wrote:
Lasse Brandt wrote
in <6be964c4-0838-4da6-9278-12c620ca1...@bitmand.com>:
la> 1) Is the hosting provider actually forcing me to do something "bad"
la> og plain wrong?
In that situation normally you get an IP address in the /59 network
to communicate wi
Hiroki Sato wrote
in <20100923.053236.231630719@allbsd.org>:
hr> Hello,
hr>
hr> Can anyone try a patch for adding 6rd (RFC 5569) support to stf(4)?
hr> The patch for HEAD can be found at:
hr>
hr> http://people.allbsd.org/~hrs/FreeBSD/stf_6rd_20100921-1.diff
Grr, I noticed it broke 6to
Hi,
Would it be possible to unhide the output of bce_print_adapter_info()
from under boot verbose?
This information is useful for comparing firmware and card versions
between machines.
Alternatively what about adding a sysctl under dev.bce.X for this info?
Thanks
Tom
--
TJU13-ARIN
_
> Would it be possible to unhide the output of bce_print_adapter_info()
> from under boot verbose?
>
> This information is useful for comparing firmware and card versions
> between machines.
>
> Alternatively what about adding a sysctl under dev.bce.X for this info?
I have no problem doing that,
"ifconfig bge1 media none" does change the PHY status temporarily. I see the
following when I run this command:
bge1: flags=8843 metric 0 mtu 1500
options=bb
ether 00:40:d0:b8:1e:0b
media: Ethernet none
status: no carrier
After a few seconds if I do "ifconfig bge1",
On Thu, Sep 23, 2010 at 10:43:52AM -0700, David Christensen wrote:
> > Would it be possible to unhide the output of bce_print_adapter_info()
> > from under boot verbose?
> >
> > This information is useful for comparing firmware and card versions
> > between machines.
> >
> > Alternatively what ab
> >> Under testing I have yet to see a memory fragmentation issue with
> this
> >> driver. I follow up if/when I find a problem with this again.
> >>
> >>
> So here we are again. The system is locking up again because of 9k
> mbuf
> allocation failures.
Failure to allocate a new buffer should ca
On Thu, Sep 23, 2010 at 11:05:08AM -0700, Sushanth Rai wrote:
> "ifconfig bge1 media none" does change the PHY status temporarily. I see the
> following when I run this command:
>
> bge1: flags=8843 metric 0 mtu 1500
> options=bb
> ether 00:40:d0:b8:1e:0b
> media: Ethernet n
On Thu, Sep 23, 2010 at 10:05:33AM -0500, Tom Judge wrote:
> On 09/13/2010 03:53 PM, Pyun YongHyeon wrote:
> > On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote:
> >
> >> On 09/13/2010 02:33 PM, Pyun YongHyeon wrote:
> >>
> >>> On Mon, Sep 13, 2010 at 02:07:58PM -0500, Tom Judge wro
On 09/23/2010 01:21 PM, David Christensen wrote:
Under testing I have yet to see a memory fragmentation issue with
>> this
>>
driver. I follow up if/when I find a problem with this again.
>> So here we are again. The system is locking up again
On 09/23/2010 01:39 PM, Pyun YongHyeon wrote:
> On Thu, Sep 23, 2010 at 10:05:33AM -0500, Tom Judge wrote:
>
>> On 09/13/2010 03:53 PM, Pyun YongHyeon wrote:
>>
>>> On Mon, Sep 13, 2010 at 03:38:41PM -0500, Tom Judge wrote:
>>>
>>>
On 09/13/2010 02:33 PM, Pyun YongHyeon wrote
The throttle command I am using in the tests is the one from here:
http://klicman.org/throttle/
On 09/23/2010 02:26 PM, Tom Judge wrote:
> On 09/23/2010 01:21 PM, David Christensen wrote:
>
> Under testing I have yet to see a memory fragmentation issue with
>
>
Hi,
I was looking though the brgphy code toady looking for a way to control
flow control from the host rather than from the switch but didn't find
any hints.
Is it possible to control the flow control negotiation on these PHY's?
Thanks
Tom
--
TJU13-ARIN
__
> > Failure to allocate a new buffer should cause the driver to
> > drop the received frame and reuse the buffer, not lock up the
> > system. Are you seeing the lockup come from bce(4) or does
> > it come from somewhere else due to the dropped data?
> >
> >
>
> The lockup is not from the NIC as s
On 09/23/2010 03:30 PM, David Christensen wrote:
>>> Failure to allocate a new buffer should cause the driver to
>>> drop the received frame and reuse the buffer, not lock up the
>>> system. Are you seeing the lockup come from bce(4) or does
>>> it come from somewhere else due to the dropped data?
> > What I'd really like to do is revamp the debug code so that it
> > can be enabled/disabled on the fly rather than requiring that
> > the driver be compiled. Adding some performance stuff would
>
> Couldn't it be implemented with sysctl? Users may set a variable
> something like dev.bce.0.diag
On Thu, Sep 23, 2010 at 01:48:13PM -0700, David Christensen wrote:
> > > What I'd really like to do is revamp the debug code so that it
> > > can be enabled/disabled on the fly rather than requiring that
> > > the driver be compiled. Adding some performance stuff would
> >
> > Couldn't it be impl
Implementing IFM_NONE in brgphy_service() to power down PHY works like a charm
!!
Many thanks
Sushanth
--- On Thu, 9/23/10, Pyun YongHyeon wrote:
> From: Pyun YongHyeon
> Subject: Re: Changing link status in bge driver
> To: "Sushanth Rai"
> Cc: "Luiz Otavio O Souza" , freebsd-net@freebsd.or
Hi,
On 09/23/10 16:40, a.sm...@ukgrid.net wrote:
we are seeing these errors repeatedly on a new Dell R300 server:
Sep 23 15:06:29 vcomm kernel: bge0: watchdog timeout -- resetting
Sep 23 15:06:29 vcomm kernel: bge0: link state changed to DOWN
Sep 23 15:06:31 vcomm kernel: bge0: link state chang
Quoting Pieter de Boer :
A 'me too' here. I have a Dell R300 with the same bge hardware, but
this box is running 8.1-RELEASE. This issue did not occur when the
box was running 8.0-RELEASE, so possibly a commit to bge-code
between 8.0 and 8.1 (and possibly 7.2 and 7.3, I guess) has this
On Thu, Sep 23, 2010 at 03:40:54PM +0100, a.sm...@ukgrid.net wrote:
> Hi,
>
> we are seeing these errors repeatedly on a new Dell R300 server:
>
> Sep 23 15:06:29 vcomm kernel: bge0: watchdog timeout -- resetting
> Sep 23 15:06:29 vcomm kernel: bge0: link state changed to DOWN
> Sep 23 15:06:31
Hello Hiroki,
This is great.
I've been looking at 6rd including the srd stuff from
http://bougaidenpa.org/masakazu/archives/54
(which I guess you also got wind of).
I haven't tried your patch yet but I need some clarifications.
RFC 5969 has the following elements for 6rd configuration:
IPv4MaskLe
Ondoy wrote
in :
lo> I haven't tried your patch yet but I need some clarifications.
lo> RFC 5969 has the following elements for 6rd configuration:
lo> IPv4MaskLen, 6rdPrefix, 6rdPrefixLen, 6rdBRIPv4Address.
lo>
lo> >From your example, I think the following takes care of
lo> 6rdPrefix and 6rdPre
28 matches
Mail list logo
