Re: Ethernet Switch Framework
On Jan 28, 2012, at 4:00 PM, Juli Mallett wrote: > It makes me wonder if the understanding of the relationship in FreeBSD > isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but > you can conceptualize of it as a child of the PHY, rather than the > parent of it, especially in systems with switch chipsets. Especially > in systems where there is a switch chipset attached to multiple MACs. > > In that model, it makes sense to semi-generically attach a > CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) > to a MAC generically, but that doesn't meant that the switch itself is > attached generically to the MAC. I think that the main issue here is that we have an assumption that we have a tree structure. However, it is more of a DAG across different domains. The hierarchy works well when each device owns all the devices below it and only interacted with them. Most devices are that way. However, in the embedded world, there's lots of reach-accrosses that are expected that break the model. Plus, MDIO is more than what we call mii/phy, so there's an imperfect match there. Warner ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
> What happens if you set hw.bge.allow_asf to 0 and use auto-negotiation > on both sides? it works! the switch was already auto-neg, and i forced auto-neg on the server side. thanks. this was not pleasant. did i remember to whine that i am in tokyo and the server is on the beast coast of the states? :) i think a bit of a warning about hw.bge.allow_asf in UPDATING might help folk. thank you *very* much for your help. randy ___ 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/164534: [bpf] net.bpf.zerocopy_enable=1 makes pflogd eat cpu and hang
Synopsis: [bpf] net.bpf.zerocopy_enable=1 makes pflogd eat cpu and hang Responsible-Changed-From-To: freebsd-net->csjp Responsible-Changed-By: csjp Responsible-Changed-When: Sun Jan 29 02:52:14 UTC 2012 Responsible-Changed-Why: Take, we have fixes for this, but not real sure we have a solution agreed upon yet. http://www.freebsd.org/cgi/query-pr.cgi?pr=164534 ___ 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: Ethernet Switch Framework
On Sat, Jan 28, 2012 at 14:12, Aleksandr Rybalko wrote: > As I see from your patch, mdio/miiproxy require special bits in MAC > driver. When I design switch framework, I keeping in mind that > MAC drivers should be standard as possible I don't understand why this is desirable in practice. It's a nice theory, but it falls down when one thinks in depth about how Ethernet interfaces are used and administered vs. how switches are used and administered. What should media report? What should media changes do? What is link status? Do you show the CPU-to-switch port, or all switch ports? It makes me wonder if the understanding of the relationship in FreeBSD isn't backwards. Yes, the MAC sits on a bus and is memory-mapped, but you can conceptualize of it as a child of the PHY, rather than the parent of it, especially in systems with switch chipsets. Especially in systems where there is a switch chipset attached to multiple MACs. In that model, it makes sense to semi-generically attach a CPU-to-switch port's pseudo-PHY (or actual PHY, depending on hardware) to a MAC generically, but that doesn't meant that the switch itself is attached generically to the MAC. There are a lot of switches out there that don't look or act much like MII-driven PHYs, but which are connected over MDIO, as I've tried to stress before. I hope there will be as much separation between the MII work that is being done and the switch work that is being done as possible. I think anything else will prove rapidly-obsolete and perhaps even obstructive as soon as anyone seeks to add support for more switch chipsets to FreeBSD. I suppose the most likely reality, though, is that people simply won't add switch support to FreeBSD, and will administer them out-of-band from userland, using gross kernel shims. That is probably true whether any of the currently-outstanding work is committed or not, unfortunately :( I just hope we'll end up with something flexible enough, broad enough in applicability, narrow enough in requirements, etc., that we'll have feature-rich support for a few chipsets in tree that work in sufficiently-different manners that they can be models for other drivers in the future. Thanks, Juli. ___ 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: Ethernet Switch Framework
On Wed, 25 Jan 2012 09:57:32 +0100 Stefan Bethke wrote: > My suggestion is to take my bus attachment code (incl. mdio and > miiproxy) and ray's ioctl and userland code. As I see from your patch, mdio/miiproxy require special bits in MAC driver. When I design switch framework, I keeping in mind that MAC drivers should be standard as possible, that why I send you patch http://my.ddteam.net/files/2012-01-22_arge.patch which clean most phymask features from if_arge driver. You may ask me why I do so? It is because arge H/W is not the single implementation, it is just FPGA design that also used in many other devices, f.e. if_et. Look into dev/et/if_etreg.h, begin from line: #define ET_MAC_CFG1 0x5000 There is the same registers, same logic, just mapped at 0x5000 in device PCI BAR, instead of 0x1900(arge) and I bet it is not last time when that FPGA design used :) > > Aleksandr's approach for the driver attachment is to have a generic > switch "bus" driver that abstracts the mii, i2c, memory mapped I/O, > etc. busses the devices are physically attached to, and present a > uniform register file to the chip-specific switch driver. I believe > that this is unnecessarily complicated for two reasons: newbus > already provides that abstraction, and chip-specific drivers usually > differ in so many aspects, including their register files, that code > sharing between chips will be somewhat limited anyway. newbus allow attach anything to anything, but bus interfaces implemented in different ways (for mem/mdio we call read/write, for SPI/IIC we call transfer). When we made that interfaces consistent we be able really forget about "bus glue". While we still not done it(even still not doing it), model with single parent (switch0) require bus glue for each supported interface (MDIO, MEM, SPI, etc.). But model with direct attach driver to bus will require bus glue per driver. If only one interface is supported, then glue in driver file, else - separate file per each supported interface. And two words about "complicated": 1. If we about complicated structure of devices - yes switch0 with bcm5325_switch0 more complicated, than just bcm5325_switch0, but device tree will care about it. 2. If we about code size, then I will say my model much smaller even having more drivers. My personal decision - is 2, because - less code better for maintenance. > > One aspect that I would enjoy looking into in more detail is how > register accesses on, for example, MDIO, can be provided through the > bus space API. From my cursory reading, it seems that the code > currently is tailored towards register accesses that can be > implemented through CPU native instructions, instead of indirectly > through a controller. > > Aleksandr has defined a quite comprehensive ethernet switch control > API that the framework provides towards in-kernel clients as well as > userland. I think it would be really helpful if we could concentrate > on those API functions that can be controlled through the userland > utility, have immediate use cases (for example, VLAN configuration on > the TL-WR1043ND to separate the WAN from the LAN ports), and we have > test hardware for. In short, don't commit dead code. It is not dead code, it is TODO :) > > Having a description of the generic switch model that the API assumes > and driver-specific documentation also wouldn't hurt. (Yes, I'm > volunteering.) It is also TODO :) On Thu, 26 Jan 2012 22:03:58 -0800 Adrian Chadd wrote: > Ok, I do like the idea of: > > * mdiobus/miibus proxy tidyup; > * then the switch API; > * then the switch devices themselves. > > Can we get some consensus/agreement from Marius (and others) about the > first step? I think we don't need to "rewrite" miibus now. :) > > > Adrian WBW -- Aleksandr Rybalko ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Sun, Jan 29, 2012 at 04:56:28AM +0900, Randy Bush wrote: > > Hrm, the problem apparently is that while when probing, the PHY > > still knows about the media it supports, it just has forgotten > > about it after the reset during attach. There was a change prior > > to 8.2 which would turn this from silently being ignored (which > > generally might or might not work) into resulting what you see > > now (the upper layers arguably shouldn't trigger a panic in this > > case though). I can't remember a change to either bge(4) or > > brgphy(4) between 8.2 and now which could trigger this though. > > Have you tried to set the loader-tunable hw.bge.allow_asf to 0? > > The default for that option still is different between 8 and 9+. > > it no longer panics when booting, but the interface comes up not seeing > carrier > > bge0: flags=8843 metric 0 mtu 1500 > > options=8009b > ether 00:30:48:82:11:a2 > inet 198.180.150.1 netmask 0xff80 broadcast 198.180.150.127 > inet6 fe80::230:48ff:fe82:11a2%bge0 prefixlen 64 scopeid 0x1 > inet6 2001:418:8006::1 prefixlen 64 > inet 198.180.150.2 netmask 0x broadcast 198.180.150.2 > nd6 options=21 > media: Ethernet 1000baseT (none) > status: no carrier > Are you sure that the other end is also forced to 1000baseT half-duplex? What happens if you set hw.bge.allow_asf to 0 and use auto-negotiation on both sides? Marius ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
>> Have you tried to set the loader-tunable hw.bge.allow_asf to 0? >> The default for that option still is different between 8 and 9+. > it no longer panics when booting, but the interface comes up not > seeing carrier an additional datum. o with hw.bge.allow_asf untouched, i.e. default o with /boot/device.hints having hint.bge.0.disabled=1 o with /etc/rc.conf having ifconfig_bge0="198.180.150.1/25 media 1000baseTX" ifconfig_bge0_alias0="inet 198.180.150.2/32" etc o it boots but bge0 carrier is down and can not be brought up comment out the bge0 entries in /etc/rc.conf, and it boots, carrier is up, and can be hand configured with the address assignments, and works. randy ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
> Hrm, the problem apparently is that while when probing, the PHY > still knows about the media it supports, it just has forgotten > about it after the reset during attach. There was a change prior > to 8.2 which would turn this from silently being ignored (which > generally might or might not work) into resulting what you see > now (the upper layers arguably shouldn't trigger a panic in this > case though). I can't remember a change to either bge(4) or > brgphy(4) between 8.2 and now which could trigger this though. > Have you tried to set the loader-tunable hw.bge.allow_asf to 0? > The default for that option still is different between 8 and 9+. it no longer panics when booting, but the interface comes up not seeing carrier bge0: flags=8843 metric 0 mtu 1500 options=8009b ether 00:30:48:82:11:a2 inet 198.180.150.1 netmask 0xff80 broadcast 198.180.150.127 inet6 fe80::230:48ff:fe82:11a2%bge0 prefixlen 64 scopeid 0x1 inet6 2001:418:8006::1 prefixlen 64 inet 198.180.150.2 netmask 0x broadcast 198.180.150.2 nd6 options=21 media: Ethernet 1000baseT (none) status: no carrier randy ___ 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: a question about flowtable
On 01/28/2012 02:12 AM, Weongyo Jeong wrote: > Hello Kip, > > I had looked flowtable code briefly and still not sure whether I > understand it correctly. At this moment I have a question. > > Is it possible to apply flowtable techniques for forwarding packets? If > I understand it right it looks it's impossible at current status because > flowtable is only applied when ro == NULL at ip_output(). Is it > intentional one? > You can pass in a struct route filled in by a flowtable lookup in ip_output. I have made this change in a number of branches and I know at least one firewall is seeing good results from doing this. The one thing to be careful about is that the number of cached flows scales with the number of IPs and not the number of prefixes. Cheers, Kip ___ 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: kerberized NFS
Thank you to all of you for your replies. I'll try next week and let you know. My mail server was down for a few hours, but everything should be ok now... Giulio. ___ 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: kerberized NFS
Giulio Ferro wrote: > I forgot to mentioned that I compiled both servers with > option KGSSAPI and device crypto, and I enabled gssd > on both. > > Is there anyone who was able to configure this setup? > I had a server at the nfsv4 testing event last June and it worked ok. I haven't tried one since then. Step 1: make sure that nfsv4 mounts work over auth_sys. (You'll need to add "sys" to the sec= flavours, so your /etc/exports will look something like: V4: /usr/src -sec=sys:krb5:krb5i:krb5p /usr/src -sec=sys:krb5:krb5i:krb5p Then on the client: # mount -t nfs -o nfsv4 :/ / (Where "<" and ">" indicate "replace this with what yours".) - Then cd / and do an "ls -l" to see that the file ownership looks ok. If it doesn't, it will be related to "nfsuserd", which must be running in both client and server. Once, Step 1 looks fine: Step 2: Check that Kerberos is working ok in the server. - Log into the server as root and do the following: # kinit -k nfs/@ - This should work ok. # klist - This should list a TGT for nfs/@ If this doesn't work, something isn't right in the Kerberos setup on the server. The NFS server (not client) must have a /etc/krb5.keytab file with an entry for: nfs/@ in it. You should create it on your KDC with encryption type DES-CBC_CRC initially and you should specify that as your default enctype in your /etc/krb5.conf. Once that is working, make sure all the daemons are running on the server. mountd, nfsd, nfsuserd and gssd If this all looks good, go to the client: # sysctl vfs.usermount=1 - make sure these daemons are running nfsuserd, gssd - Log in as non-root user: % kinit % klist - there should be a TGT for the user you are logged in as - Now, try a kerberos mount, as follows: % mount -t nfs -o nfsv4,sec=krb5 :/ / - if that works % cd / % ls -l If these last steps fail, it is not easy to figure out why. (Look in /var/log/messages for any errors. If you get what the gssd calls an minor status, that is the kerberos error.) rick ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Sat, Jan 28, 2012 at 09:34:04PM +0900, Randy Bush wrote: > >> ok, i > >> o used device.hints to disable both bge interfaces > >> o booted successfully > >> o used serial console > >> o ifconfiged bge0 to the normal addresses > >> o and it is working > >> > >> i suspect that something sucks in bge initialization at startup. > >> insightful, i know. sorry. > > > > Has that worked before with FreeBSD and if yes with which reversion? > > yes, the bge and config worked for a long time on 7.foo and 8.foo, most > recently 8.2. > Hrm, the problem apparently is that while when probing, the PHY still knows about the media it supports, it just has forgotten about it after the reset during attach. There was a change prior to 8.2 which would turn this from silently being ignored (which generally might or might not work) into resulting what you see now (the upper layers arguably shouldn't trigger a panic in this case though). I can't remember a change to either bge(4) or brgphy(4) between 8.2 and now which could trigger this though. Have you tried to set the loader-tunable hw.bge.allow_asf to 0? The default for that option still is different between 8 and 9+. Marius ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
>> ok, i >> o used device.hints to disable both bge interfaces >> o booted successfully >> o used serial console >> o ifconfiged bge0 to the normal addresses >> o and it is working >> >> i suspect that something sucks in bge initialization at startup. >> insightful, i know. sorry. > > Has that worked before with FreeBSD and if yes with which reversion? yes, the bge and config worked for a long time on 7.foo and 8.foo, most recently 8.2. randy ___ 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: 9-stable - ifmedia_set: no match for 0x0/0xfffffff
On Thu, Jan 26, 2012 at 12:24:11PM +0900, Randy Bush wrote: > ok, i > o used device.hints to disable both bge interfaces > o booted successfully > o used serial console > o ifconfiged bge0 to the normal addresses > o and it is working > > i suspect that something sucks in bge initialization at startup. > insightful, i know. sorry. > Has that worked before with FreeBSD and if yes with which reversion? Marius ___ 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: kerberized NFS
I forgot to mentioned that I compiled both servers with option KGSSAPI and device crypto, and I enabled gssd on both. Is there anyone who was able to configure this setup? ___ 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"
