Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
David Christensen wrote (on 2009-08-01): > Sorry, this is the 5709S and I haven't had an opportunity to > implement this PHY yet. Unfortunately it's more than just a > change to miidevs since the SerDes is actually an IEEE clause > 45 compliant device (instead of the more common Clause 22 > devices found in 1GbE controllers). The registers are > diffrerent so the effort is more substantial. No estimate > yet on when I can get to it. 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 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.) Best regards Oliver -- Oliver Fromme, secnetix GmbH & Co. KG, Marktplatz 29, 85567 Grafing b. M. Handelsregister: Registergericht Muenchen, HRA 74606, Geschäftsfuehrung: secnetix Verwaltungsgesellsch. mbH, Handelsregister: Registergericht Mün- chen, HRB 125758, Geschäftsführer: Maik Bachmann, Olaf Erb, Ralf Gebhart FreeBSD-Dienstleistungen, -Produkte und mehr: http://www.secnetix.de/bsd "File names are infinite in length, where infinity is set to 255 characters." -- Peter Collinson, "The Unix File System" ___ 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"
Re: "PHY read timeout" with bce2 & 3 on FreeBSD 8.0
Pyun YongHyeon wrote: > On Mon, Jan 18, 2010 at 10:40:55AM -0500, Charles Owens wrote: >> Hello, >> >> 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 IM INISMI AI S AIIS SAA >> 22cc2,,c , E2EIcIES,SIAS AA >> E I00 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: S0 >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: <<22>>A >> Jan 12 10:37:19 dmz55 kernel: >> Jan 12 10:37:19 dmz55 kernel: 0 >> Jan 12 10:37:28 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): >> Error: PHY read timeout! >> phy = 1, reg = 0x0001 >> >> >> What's are the best next steps to take in figuring this out? Thanks in >> advance for any assistance. Kernel boot log appending below. >> > > Are you using ASF/IMPI/UMP on bce2 or bce3? > If so would you try attached patch? Publicly available datasheet > lacks details on management firmware handling so I'm not sure what > is really happening here. > davidch may shed light on this(CCed). Ok, I've got the patch in place plus the PRINTF buffer option that David suggested. More observations: * bce2 and 3 now seem usable. Could this be the patch? Or maybe I just was moving too fast before. * Trouble (similar error messages then eventually reboot) begins only when I plug into the IMM management port. Why is this related to the bce ports? Below are the error logs. Note that I've got now got bce2 configured as the active NIC on local LAN. You can see here that I unplug bce2. What you don't see is that I plug cable into the IMM port, wait 10 seconds or so, then move the cable back to bce2. Within a second or two the error messages start flowing... and finally the system reboots about a minute later. Jan 20 06:50:02 dmz55 kernel: bce2: link state changed to DOWN Jan 20 06:50:23 dmz55 kernel: NMI ISNAM I ISNAM 2IcN ,I2M cSE,AI IISESA2AIcS, AE I00S Jan 20 06:50:23 dmz55 kernel: Jan 20 06:50:23 dmz55 kernel: A Jan 20 06:50:23 dmz55 kernel: 2c0, Jan 20 06:50:23 dmz55 kernel: E Jan 20 06:50:23 dmz55 kernel: ISA 0 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0001 Jan 20 06:50:23 dmz55 last message repeated 3 times Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0004 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0005 Jan 20 06:50:23 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0019 Jan 20 06:50:24 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1533): Error: PHY read timeout! phy = 1, reg = 0x0001 Jan 20 06:50:24 dmz55 last message repeated 3 times ... etc., with eventually some of these showing up as well: Jan 20 06:50:37 dmz55 kernel: bce2: /usr/src/sys/dev/bce/if_bce.c(1608): PHY write timeout! Thanks, Charles ___ 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"
RE: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
> 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 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 interest in this effort and sent out a patch yesterday, though he doesn't have hardware to test. I'm planning on giving his patch a try today to see how close he got on his first attempt. Dave ___ 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"
best way to optimize ipfw-dummynet interaction ?
Hi,
I am trying to solve the following problem:
when ipfw passes a packet to dummynet, the packet is tagged with a
'pipe number' which dummynet needs to look up to find the pointer
to the correct object -- something like this:
IPFW_LOCK()
rule = find_matching_rule();
1. ... pkt.tag.pipeNR = rule->pipe_number;
IPFW_UNLOCK()
...
// now ipfw_pfil_hook calls dummynet:
DUMMYNET_LOCK()
2. pipePTR = lookup(pkt.tag.pipeNR)
... dummynet processing
DUMMYNET_UNLOCK()
// ... after some time the packet is delivered
3. ip_output(pkt)
It would be nice to cache the result of a lookup in the ipfw rule
or in the table entry so we don't have to pay the cost all the times
(the result would be stored as a tuple
same as ipfw rule pointers, so you can detect changes and do a
lookup if the generation number changes.)
But i cannot think of a good way of doing it -- i have two options
in mind:
A) right after #1, call into dummynet while still holding the IPFW LOCK:
if (rule->pipePTR.generation != dummynet.generation) {
DUMMYNET_LOCK()
rule->pipePTR = lookup(pkt.tag.pipeNR)
DUMMYNET_UNLOCK()
}
We can probably do the check outside the lock because the cached
value is only advisory and if wrong we will detect it some other
time (as long as the dummynet.generation variable does not go away).
B) + right after #1, store a reference to the rule (in the usual way
involving a generation number) in the packet tag;
+ right after #2, store a reference to the pipePTR in the packet tag;
+ after #3, if the packet happens to enter IPFW again (or if it
does not, do it on purpose) and the rulePTR is still valid, then
store the result in rulePTR.
Solution A is somewhat simpler because the code is exactly the one i
wrote above, but i am not particularly fond of the nesting of the locks.
Solution B solves the lock nesting problem by piggybacking the message
onto the packet, but it might require a bit of extra work for copying
and checking those "safe references". Finally, we should make sure
that the 'reinjection' of information occurs even if packets are
systematically dropped (not unlikely to configure an ipfw rule that
points to a non-existing pipe, in which case we have useless lookups;
we could cache a negative info and save the lookup).
Comments or suggestions anyone ? With the recent optimization work
on ipfw and dummynet this is probably the last piece that uses
a suboptimal algorithm (the lookup is through a hash table but
constants do matter here).
cheers
luigi
___
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"
Re: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
On Wed, Jan 20, 2010 at 10:57:15AM -0800, David Christensen wrote: > > 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 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 interest in this effort and sent out > a patch yesterday, though he doesn't have hardware to test. I'm > planning on giving his patch a try today to see how close he got > on his first attempt. Where can I find this patch? We can also give it a try on our m610. Hugo ___ 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"
RE: bce(4) BCM5907 CTX write errors on 7.2 driver
> > 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. Just committed the changes today. Dave ___ 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"
Re: kern/143034: [panic] system reboots itself in tcp code [regression]
Old Synopsis: system reboots itself New Synopsis: [panic] system reboots itself in tcp code [regression] Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Wed Jan 20 21:58:59 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143034 ___ 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"
RE: kern/134658: [bce] bce driver fails on PowerEdge m610 blade.
> > > 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 interest in this effort and sent > out a patch > > yesterday, though he doesn't have hardware to test. I'm > planning on > > giving his patch a try today to see how close he got on his first > > attempt. > > Where can I find this patch? We can also give it a try on our m610. Let me give it a try first, if I can get link I'll pass it along. Dave ___ 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"
freeBSD8.0 multicast routing problem
how to enable multicast routing in freeBSD8.0,please give the steps of configuration. ___ 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"
Re: kern/143046: [mxge] [panic] panics since mxge(4) update
Old Synopsis: panics since mxge(4) update New Synopsis: [mxge] [panic] panics since mxge(4) update Responsible-Changed-From-To: freebsd-bugs->freebsd-net Responsible-Changed-By: linimon Responsible-Changed-When: Thu Jan 21 04:56:43 UTC 2010 Responsible-Changed-Why: Over to maintainer(s). http://www.freebsd.org/cgi/query-pr.cgi?pr=143046 ___ 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"
