> | > Specifically, we've seen that newer (9 and higher) have issues with
> | > the doing initial setup and negotiation and that Dell did indeed
> | > release newer firmware to fix the issues. This requires a full
> | > reboot into Linux (probably centos6) to get the update to execute.
> |
> | I c
> > > dev.bce.0.com_no_buffers: 130228
> >
> > Hmm, in HEAD there looks to be a hw.bce.rx_pages that can be set to
> > 1, 2, 4, or 8. It defaults to 2. In the 7 driver it looks like this
> > is a #define in sys/dev/bce/if_bcereg.h (RX_PAGES on line 6710). Try
> > changing RX_PAGES from 2 to 4 (o
>> I also don't understand why sysctl hw.bce.loose_rx_mtu doesn't respect
>> with tunnable hw.bce.strict_rx_mtu. Is there any reason to give them
>> different names?
>It may be an oversight. Personally I don't see any reason except
>debugging purpose to limit RX frame size to interface MTU. It ma
> > >I have an R820 I'm testing. The system seems to boot up fine, but
> > > no network adapters show up. From pciconf -l :
> > >
> > > none4@pci0:1:0:0: class=0x02 card=0x1f5c1028
> chip=0x168a14e4 rev=0x10 hdr=0x00
> > > none5@pci0:1:0:1: class=0x02 card=0x1f5c1028
> chip=
> sysctl -a | g bce.3|g -vE '(%|stat)'; echo; sleep 10; sysctl -a | g bce.3|
> g -vE '(%|stat)'; echo; netstat -m
>
> dev.bce.3.l2fhdr_error_count: 0
> dev.bce.3.mbuf_alloc_failed_count: 2098854
> dev.bce.3.mbuf_frag_count: 2655285
> dev.bce.3.dma_map_addr_rx_failed_count: 0
> dev.bce.3.dma_map_a
> > > dev.bce.3.l2fhdr_error_count: 0
> > > dev.bce.3.mbuf_alloc_failed_count: 2098856
> > > dev.bce.3.mbuf_frag_count: 2655288
> > > dev.bce.3.dma_map_addr_rx_failed_count: 0
> > > dev.bce.3.dma_map_addr_tx_failed_count: 57
> > > dev.bce.3.unexpected_attention_count: 0
> > > dev.bce.3.com_no_buffe
> > > > Hi! I really need broadcom 57711E driver for my FreeBSD 8.0
> i386.
> > > > Does anybody have this driver already?
> > > >
> > > > P.S. Also wanted David Christensen who had previously tried to
> write a driver.
> > >
>
A number of people have asked about a FreeBSD driver for
the Broadcom 10GbE devices (BCM57710 and BCM57711). I
just submitted the initial release of the bxe(4) driver
to -HEAD today so please test and provide your feedback.
Thanks,
Dave
___
freebsd-ne
> You had 282 RX buffer shortages and these frames were dropped. This
> may explain why you see occasional packet loss. 'netstat -m' will
> show which size of cluster allocation were failed.
> However it seems you have 0 com_no_buffers which indicates
> controller was able to receive all packets de
> > > Data sheet says IfHCInBadOctets indicates number of octets received
> > > on the interface, including framing characters for packets that
> > > were dropped in the MAC for any reason.
> >
> > The IfHcInBadOctets counter says the controller received X bytes
> > that were bad on the wire (colli
> > Any thoughts on that? It's the only thing that differs between the
> two
> > switches.
> >
>
> This makes me think possibility of duplex mismatch between bce(4)
> and link partner. You should not use forced media configuration on
> 1000baseT link. If you used manual media configuration on bce
> I was able to reproduce the drops in very large numbers on the internal
> network today. I simply scp'd some large files from 1000/FD hosts to a
> 100/FD host (ie: scp bigfile.tgz oldhost.i:/dev/null). Immediately the
> 1000/FD hosts sending the files showed massive amounts of drops on the
> sw
> I'm running 8.1 and at least on the bce hosts, it looks like flow
> control
> isn't supported, it was added on 4/30/2010:
>
> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=206268&r2=20
> 7411
>
> In my 8.1 sources I still see this comment, which was removed in the
> above
> commit
> > There won't be any indication in the driver since flow control
> > is managed in hardware. You'd need a wire capture to see that
> > bce(4) has stopped sending frames in response to receiving an
> > XOFF flow control frame or started sending frames in response
> > to receiving an XON flow cont
> Thanks for the drivers, but at work we have some issues w/ the driver
> on an HP Blade. We could do some basic pings, but when trying to
> pass DNS traffic, it failed. Turning off both rxcsum and txcsum made
> the driver work. If I only turned one or the other off, DNS traffic
> would still no
> > so, I cracked open my R410 this morning to see what the Ethernet
> chipset
> > had for a indentification mark. It is definitely stamped as a
> BCM5716,
> > so I'm confused.
> >
> > bce(4) has code to handle the 5716 chipset, but its never being
> executed
> > AFAIK. What's going on here?
> >
> > Can't explain either but probably stable/6 bce(4) may have used old
> > firmware.
>
> Ok, I can once again reach the IPMI controller if I remove this:
>
> http://svnweb.freebsd.org/base/head/sys/dev/bce/if_bce.c?r1=210263&r2=21
> 0262&pathrev=210263
>
> Since the driver has control over the
> Whoa ... ok, so now I've run into something horrible.
>
> According to dmidecode, a Dell R410 has a Broadcom 5716 chipset on it.
> On Board Device 2 Information
> Type: Ethernet
> Status: Enabled
> Description: Embedded Broadcom 5716 NIC 1
> On Board Device 3 Information
> Because driver already initialized CPUs and context I thought
> moving bce_pulse() to bce_init() was too late. If that's doable it
> would be more correct way to address this issue.
>
Moving bce_pulse() is a minimum. It might be necessary to move
some other code out of bce_attach()/bce_detach(
> > That's a typo then, 5709 and 5716 share the same ASIC ID.
> >
>
> Thanks for confirmation.
> Could you review the attached patch?
Looks good. ASIC ID matches my Dell R210 system:
bce0: mem 0xda00-0xdbff
irq 16 at device 0.0 on pci2
miibus0: on bce0
bce0: Ethernet address: b8:ac:6
> Thanks for testing.
> Committed with r226123.
> I also noticed that bce(4) may support BCM5716S because brgphy(4)
> already supports BCM5709S. Can you test attached patch on BCM5716S?
I don't have a 5716S system or NIC for testing.
Dave
___
freebsd-n
> > I attempted to disable IPMI via the Dell BIOS tool (DRAC) and I
> couldn't
> > see any driver detection of this status. So, when I add this:
> >
> > > if ((ifp->if_flags & IFF_UP) == 0 &&
> > >(sc->bce_flags & BCE_MFW_PRESENT_FLAG) == 0){
> > > printf("%s: BCE d
> Ran this on my Dell R410. I can clearly see that the tool is
> "disabling" the MFW bit, and that the dell bios interface to the IPMI
> controller/DRAC is impaired, however ...
>
> The system still thinks that the MFW bit is "ON" and proceeds normally
> in this case. The code still fails to det
> Has anyone seen these errors before:
>
> http://www.freebsd.org/cgi/query-pr.cgi?pr=135836&cat=
>
> The system is a Dell R610 and it happens on both cold and warm boots.
>
> I am about to check a second chassis, and test with 8, and
> will follow up after my tests.
Yes, I've seen these error
> Thanks for the rapid response.
>
> Dell have firmware 5.0.9 on their website here: http://tiny.cc/ex834
>
> Will that work?
Yes, that release does include a good version of BCM5709 bootcode (v5.06).
I couldn't really tell until I downloaded the file and looked at the
temporary files inside.
> > After fighting with the update process for a bit and then learning
> > about the live cycle manager I have managed to test the
> R610 with the
> > 5.0.9 firmware.
> >
> > On the face of it, it seems that this resolves the issue.
> >
> After a reboot this morning the error has resurfaced and
> > Can you try a different test? Power-on the system with the network
> > cable attached to an idle switch (i.e. keep all network
> traffic from
> > being forwarded to the NIC during driver initialization). Does the
> > system power up successfully? Repeatedly? The problem I saw was
> > c
> > The next test is to diable the LOM's management firmware
> but boot to
> > an active network. Get the User Diag utility at the bottom of
> > http://www.broadcom.com/support/ethernet_nic/netxtremeii.php.
> > Run the uxdiag utility with the command line:
> > "C:\>uxdiag -c 0 -mfw 0 -c 1 -mfw
Hi,
> we have two new Dell R610 machines with four bce NICs (only
> bce0 is connected at this time). I tried cold (power cycle in
> iDRAC) and warm reboot (shutdown -r now), NIC is working on
> every reboot, but I am still seeing messages:
>
> bce0: /usr/src/sys/dev/bce/if_bce.c(1525): PHY writ
> Is there any progress on this issue? We can provide access
> to hardware with this fault (Specifically the R610).
I haven't been able to reproduce it on the r710 I have in house.
Checking with other groups now to see if they have one a I can
use, though I'm not sure why the system would make a
> > I haven't been able to reproduce it on the r710 I have in house.
> > Checking with other groups now to see if they have one a I can use,
> > though I'm not sure why the system would make a difference for this
> > particular issue. Just wanted to confirm that you're using
> the driver
> > b
> > I haven't been able to reproduce it on the r710 I have in house.
> > Checking with other groups now to see if they have one a I can use,
> > though I'm not sure why the system would make a difference for this
> > particular issue. Just wanted to confirm that you're using
> the driver
> > b
> > For the record we also have not been able to reproduce the issue on
> > the R710 only the R610.
>
> I got hold of an R610 system and I now understand why the
> issue was difficult to replicate on R710. The R610 ships
> without Enterprise iDRAC while the R710 ship with the add-in
> Enterpr
> > Does the attached patch make a difference for you?
>
> This patch seems to do the trick, on at least one of the
> R610's that we have.
>
> Just did cold boot, 5 warm boots, cold boot, 5 warm boots and
> have not had any issues.
>
Thanks for testing. I want to pass the changes by a couple
o
> Can the bge driver use more than one MSI message? If
> possible, what the advantage of this on a SMP system (better
> CPU distribution on interrupts?)?
>
> I have an Broadcom BCM5703X, with 8 MSI messages:
> --
> b...@pci0:1:2:0:class=0x02 card=0x00cb0e11
> chip=0x16a714e4 rev=0x02
>
> > MSI is broken on this device (actually all PCI/PCI-X devices in the
> > 57XX family). The interrupt will be asserted as expected
> but masking
> > the interrupt does not work. For those newer 1Gb PCIe
> devices that do
> > work correctly with MSI, only a single message is actually
> sup
> > I'm working with a system (IBM System x3550 M2) that has
> four onboard
> > bce(4) NICs. Using FreeBSD 8.0, the first two seem to
> function fine,
> > but the second two do not, yielding messages like this when
> a cable is
> > inserted:
> >
> > Jan 12 10:37:19 dmz55 kernel: <2<>N2M>NINM
> While trying to debug the same issue I stumbled across this
> thread ... We've got HS22 blades (IBM BladeCenter) which
> habe the BCM5709S and suffer from exactly the same problem.
>
> Dave, are there any news regarding the PHY implementation?
>
> If there's decent documentation I might even
> > Thanks for testing. I want to pass the changes by a couple other
> > people before I go ahead with a commit.
> >
> > Dave
> >
>
> Hi Dave,
>
> I was just wondering when these changes will hit the tree, I have been
> running your patch in production for some time now and all seems well.
J
> > > If there's decent documentation I might even give it a
> try myself,
> > > provided that it's not too complex. (I've done hardware
> programming
> > > before, but I've never touched a NIC/PHY driver, except for very
> > > trivial fixes.)
> > >
> >
> > Pyunh has taken an active interes
> >> Ooo!!
> >>
> >> Could you link me though to the patch Oliver, I don't seem to find
> >> any post on this thread between today and mid last year?
> >>
> >
> >Let's give more time to David. He can test my guess work and can
> >fix bugs in the patch. When all goes well he may commit the patch.
>
> If I configure the cards individually, I can reach other devices on the
> network. When I enable link aggregation, I can ping the hosts IP
> address,
> but I cannot ping its gateway.
I haven't played with lagg on bce(4) so I definitely haven't tested this.
Can you dump the hardware statistics be
> I'm under the impression the header splitting in bce(4) is for
> LRO(opposite of TSO), not for VM magic to enable page flipping
> tricks.
Header splitting was implemented in the Linux version of bce(4)
to prevent jumbo memory allocations. Allocating 9KB frames was
causing problems on systems us
> 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,
> >> 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
> > 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
> > 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
I'm working on adding MSI-X support for a new network driver
and having some difficulty in actually getting an interrupt.
Does this look right?
/* Select and configure the IRQ. */
sc->bxe_msix_count = pci_msix_count(dev);
rid = 1;
/* Try allocating MSI-X interrupts
I'm working on implementing multi-queue support for a 10Gb
device on FreeBSD and I wanted to find out the current state
of the OS with regards to supporting this. It seems that
support for multiple receive queues can be done today since
most of the routing is done in hardware but the transmit
side
> Ok, thanks for testing anyway.
> I still think that this isn't really a driver bug though but
> you are hitting some hardware-related problem like f.e. a
> silicon bug and the question is how to work around it.
There is a documented errata for the 5701 A3 where a 64bit DMA
read can be termin
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: "David Christensen" <[EMAIL PROTECTED]>
To: "Marius Strobl" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: RE: kern/128833: [bge] Network p
Is there a method or callback in FreeBSD where a driver can
be notified that it has caused a kernel panic in order to
generate a dump of internal hardware state information? I've
written a sysctl call for manual intervention and can handle
some "expected" hardware events completely in the driver
The following reply was made to PR kern/128833; it has been noted by GNATS.
From: "David Christensen" <[EMAIL PROTECTED]>
To: "Marius Strobl" <[EMAIL PROTECTED]>
Cc: "[EMAIL PROTECTED]" <[EMAIL PROTECTED]>
Subject: RE: kern/128833: [bge] Network p
For those who are interested in working on the bge(4) driver, Broadcom has now
posted its Programmer's Guide at
http://www.broadcom.com/collateral/pg/57XX-PG105-R.pdf. This document covers
most of the older chips including 5700, 5701, 5703, 5704, 5714, and 5721,
though since much of the archit
The following reply was made to PR kern/134658; it has been noted by GNATS.
From: "David Christensen"
To: "bug-follo...@freebsd.org" ,
"harald_jen...@dell.com"
Cc:
Subject: Re: kern/134658: [bce] bce driver fails on PowerEdge m610
blade.
Date: Wed, 20
> Is there any near plan to develop drivers for network cards
> based on broadcom NetXtereme II 57710 10 GbE controller?
I have written a driver to support the 57710/57711/57711E
parts, bxe(9), but I haven't released it as I haven't been
able to get much testing mileage on it. The biggest
challe
> Anyone point me in the right direction on how to add the phy
> to support these machine?
>
> Seems like its just a matter of adding the PHY details to
> miidevs but how do I find out the specifics of that?
Sorry, this is the 5709S and I haven't had an opportunity to
implement this PHY yet. U
> >> I don't see how arping or not can be a driver problem, the driver
> >> just sends packets queued by the stack, there exists NO
> mechanism to
> >> communicate that kind of thing down into the driver, -arp is
> >> something that must be negotiated in the stack somewhere,
> as for it
> >>
I'm working on improving the fiber support for the bce driver. One of
the devices supported by the
driver (the 5708) supports a 2.5G mode which is negotiated through next
pages operations during
normal auto negotiation. The mechanism for negotiating this speed uses
standards based
mechanisms, bu
> > I'm working on improving the fiber support for the bce
> driver. One of
>
> Should be fine but you might want to post a patch to be concrete.
>
> Sam
I'm just looking at adding a media type as follows:
#define IFM_2500_SX 21 /* 2500BaseSX - multi-mode fiber */
I've only br
> I have a rather serious problem, I have three dell server (PE1800,
> PE2950 and SC1425) the PE1800 is running FreeBSD 6.1. The
> problem that I
> have is that the PE1800 is responding with two mac adresses
> on the same
> network interface, has anywone seen this before? This causes
> our ro
> I have a version of code ready to MFC, the big difference with CURRENT
> is that TSO is #ifdef'd off until Andre is able to get that back.
Is something broken with TSO? I just added TSO support to bce on
CURRENT
and was planning on MFC'ing to RELENG_6 within the next week.
Dave
__
It's not a problem I've seen before. The driver seems to be
passing an Ethernet frame up the stack with a length of -4.
Is there anything unusual about your network setup like VLAN
tagging, jumbo frames, or anything else that might cause
the Ethernet frame to be formatted in an unusual manner?
Th
> Tom Judge wrote:
>
> [skip]
>
> > Vladimir,
> >
> > Is this the patch attached to your post titled "Serious bug in most
> > (?) ethernet drivers (bge, bce, ixgb etc.).".
> Exactly.
>
That patch was already incorporated in the bce driver (if_bce.c, v1.30)
on May 4th, 2007.
Dave
> David Christensen wrote:
> >> Tom Judge wrote:
> >>
> >> [skip]
> >>
> >>> Vladimir,
> >>>
> >>> Is this the patch attached to your post titled "Serious
> bug in most
> >>> (?) ethernet drivers (bge
since this doesn't present as a performance
problem.
Dave
> -Original Message-
> From: Tom Judge [mailto:[EMAIL PROTECTED]
> Sent: Thursday, June 07, 2007 2:09 PM
> To: David Christensen
> Cc: freebsd-net
> Subject: Re: Problems with BCE network adapter (Dell PE
> Sorry for the top post, but I have just managed to repeat is
> exact crash
> twice on a new PE 1950 system. I have core files available.
>
> It seems that after a couple of reboots the problem goes away. The
> system actually crashed 4 times but 2 of the cores where corrupt.
>
> It also se
> > Sorry for the top post, but I have just managed to repeat is
> > exact crash
> > twice on a new PE 1950 system. I have core files available.
> >
> > It seems that after a couple of reboots the problem goes away. The
> > system actually crashed 4 times but 2 of the cores where corrupt.
> >
> > > Sorry for the top post, but I have just managed to repeat is
> > > exact crash
> > > twice on a new PE 1950 system. I have core files available.
> > >
> > > It seems that after a couple of reboots the problem goes
> away. The
> > > system actually crashed 4 times but 2 of the cores whe
> Sorry for the top post, please try following patch:
> http://people.freebsd.org/~sephe/if_bce.c.diff
>
> This is probably the cause; I noticed it when bce(4) was
> ported to DragonFly.
>
Thanks Sephe, I think you're on to something. I have some
debug code in the driver to simulate mbuf alloc
> Firstly I am not trying to slate David's efforts, however
> there are and
> have been some big problems with the driver.
>
> As for the IPMI integration, our management controllers are
> set to used
> the remote access controller NIC (Set as dedicated in the
> bios) rather
> than share the
> Dave, perhaps you could answer my question?
>
> I'm using the 0.9.6 driver with 6.1 RELEASE. I don't use
> jumbo frames, so
> the only problem I've experienced is the link state going up and down
> occasionally.
>
> Does the more current driver solve the link state problem?
> If it does,
> Some revision of Broadcom GbE NIC with bge driver
> seems to loss 1 packet per 1000 packet at receiving on some occasion.
> Sending doesn't have this problem(receiving only).
>
> This loss doesn't always happen,
> but when happens, it seems that loss is exactly 1 per 1000,
> as the last 3 di
> > It could certainly be argued by some that Cisco is not standards
> > compliant in this case for sending an oversized Ethernet frame
> > and expecting everyone to accept it. Hardware has limitations
> > and assuming that all Ethernet controllers can support frames
> > greater than 1522 bytes is
> Julian Elischer wrote:
> > Ok which clever person did this again?
> >
> > It just broke our product.
> > If it hasn't been removed from 7.0 and 6.x yet it's just
> about to be...
>
>
> on the topic above, I've found that the bce driver seems to
> be throwingaway packets
> larger than the mtu
> > I'm not completely opposed to making such a change, but I don't want
> > to make a default change in the driver's behavior that other people
> > may be depending upon (whether they are aware of it or not). A
> > tunable driver value could be the answer but I'm not entirely sure
> > how it wou
> > > Internet ettiquette demands being gracious in what you accept.
> > > The default policy of FreeBSD is to accept such packets.
> > > This is a really weird bug to track down.
> > > Other drivers support it.
> > >
> > > This isn't worth making a stand over, unless you're trying
> > > to hold u
> The motherboard of my HP proliant DL360 G4p was changed and now I
> cannot see my network cards (BCM5704 netXtreme dual gigabit). I'm
> running FreeBSD 6.2 p5...
>
> Here is what I have in dmsg
>
> bge0: mem
> 0xfdef-0xfdef
> irq 25 at device 2.0 on pci2
> bge0: Reserved 0x1 bytes
ull-height rack style chassis would be best,
though a tower configuration would also be suitable.
I want to do some wider testing on non-Intel based systems with
current and new Broadcom drivers. Feel free to email me directly
if you have a suggestion.
Da
> > I want to do some wider testing on non-Intel based systems with
> > current and new Broadcom drivers. Feel free to email me directly
> > if you have a suggestion.
>
> look at getting a PG powerPC off ebay..
>
> (I can help you set it up if you wish..
> I just did a dozen of them for work).
>
> Just wondering if someone's been working on POLLING support for bce(4)
> Broadcom NetXtreme II (BCM5706/BCM5708) PCI/PCIe Gigabit Ethernet
> adapter driver? AFAIK late in 2006 brueffer@ decided[*] to remove the
> erroneous polling(4) man entry claiming bce support... and that's it.
> Any advancem
I'm trying to build the "bce" driver as a kernel module under RELENG_7 but I'm
finding that not all of the functions in the driver are exported as symbols.
This
makes it difficult to "call" a function from ddb because I get the error "Symbol
not found". I'm building and loading the driver from /
> > I'm trying to build the "bce" driver as a kernel module under
> RELENG_7 but I'm
> > finding that not all of the functions in the driver are exported as
> symbols. This
> > makes it difficult to "call" a function from ddb because I get the
> error "Symbol
> > not found". I'm building and l
> > Yes, I'm building a debug kernel. I have the line listed above as
> well
> > as the following:
> >
> > options KDB
> > options DDB
> > options GDB
> > options INVARIANTS
> > options INVARIANT_SUPPORT
> > options WITNESS
> > options WITNESS_SKIPSPIN
>
> Dave:
>
> What symbols can you n
> > So, it won't hurt if it shows up in ifconfig, and it can be
> controlled, but
> > definitely helps our job, the administrators'.
>
> OK, if people feel strongly about this, and someone wants to implement
> the
> code in ifconfig I'll go along with it.
I believe there are some valid reasons whe
> Greeting colleagues. I've got two DL-360(pciX bus) servers,
> with BCM5704 NetXtreme Dual Gigabit Adapters(bge). The Uname
> is 6.1-RELEASE-p3. The bge interfaces of the both servers are
> connected with each other with a cat6 patchcord.
>Here are my settings:
> kernel config:
> options D
> Dear list,
> I'm running the latest FreeBSD 6.1-RELEASE-p3 on the
> following piece of
> hardware:-
> IBM xSeries 336
> - 1 add-on PCI dual-port NIC (IBM Netxtreme Dualpt Ethernet adapter)
> matching the Broadcom BCM5704C Dual Gigabit Ethernet chipset (detected
> as bge0 and bge1)
> - 2 intern
:[EMAIL PROTECTED]
> Sent: Wednesday, August 23, 2006 9:17 AM
> To: David Christensen
> Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: bge(4) one packet wedge
>
> Colleagues,
>
> I've faced a problem in bge(4) when a single packet is in the RX
> On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> > This "lost interrupt" type of problem is addressed by the use of the
> > status_tag
> > field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> > structure).
>
> > > Could you please answer few questions?
> > >
> > > 1) I've found status tag is returned in status block even if
> > > bit 9 of Misc.
> > >Host Control Register is not set, is it ok?
> >
> > Which controller are you using? This bit is reserved on the 5700
> > (which didn't support tagg
> D> This "lost interrupt" type of problem is addressed by the
> use of the
> D> status_tag
> D> field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> D> structure).
> D> Everytime the status block is updated a new tag value is
> written to the
> D> status block.
> D>
> On Wed, Aug 23, 2006 at 12:53:49PM -0700, David Christensen wrote:
> D> This "lost interrupt" type of problem is addressed by the
> use of the
> D> status_tag
> D> field in the status block. (Listed as bge_rsvd0 in the
> bge_status_block
> D> stru
> I'm testing network failover on IBM BladeCenter running FreeBSD 6.1
> STABLE for Sep 6th.
>
> I suspect a problem with link state change detection in bge code. When
> I disable internal port on chassis built-in ethernet switch, kernel
> floods syslog with messages about link state changes and co
> Finally I got a NIC that has a chip that does tagged status
> block - 5701.
>
> I've prepared a patch, that mimics Linux. If a chip can do status tag,
> then we write it to mailbox register at end of ISR, as you have
> described. If the chip can't, then we force coalescing once
> per second.
>
Polling is not currently supported in the bce driver.
Dave
> Hi,
> We have just upgraded to a Dell 2950 for our main BGP router.
> With the constant rise in traffic through the box, I have started to
> notice some dropped packets so I figured I would take a look
> at putting
> the interfa
> These happen under loads that can't be handled, and generally cause
> thousands of input errors every second. The hardware records dropped
> packets separately from other input errors, but unfortunately
> all types
> of input errors are counted together in if_ierrors, and I haven't done
> more
96 matches
Mail list logo
