OT: github.com version of NDISulator
Hi, I have to use ndisulator for my wifi card and the one in base panics the kernel. I read that the fork(?) at github has got some bugs fixed and I'd like to try it out. It doesn't compile on 10-STABLE. Would somebody on this list have any ideas about it? Thanks, Nikos ___ 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: EM(4) - Link flap when bridged and adding members (em bridge flap)
El 10/12/14 a les 19.25, Ryan Stone ha escrit: >>From a quick look at the code, whenever an interface is added to a > bridge, if that interface does not support a feature currently enabled > on the bridge then it has to disable that feature on all member > interfaces of that bridge. That would re-init the em interface, which > would cause a link flap. This is something specific to the em driver implementation I guess, because I've tried it with other drivers (bge and bce) and the connection is not dropped when the normalization of options happens. Roger. ___ 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"
Label and Packaging
Hello , Would you be interested in acquiring contacts from Label & Package Printing Industry Lists 2014-2015? which includes complete verified email addresses of - All Key Decision makers List, All C-level executives List of - Manufacturers, Packaging Professionals, Food & Beverages Manufacturers, Web printing Companies, Overprinting & Inspection Professionals, Pre-press, Radio frequency Professionals, Security Managers, Industrial Production Managers, Food Batch makers, Book/Magazines Publishers, Equipment Manufacturers, Foil Manufacturers, Rubber & Plastic Manufacturers, Graphic Designers, Supply & logistics Managers, Product development managers, Buyers, Suppliers, Importers/Exporters and many more! across US/UK/Global. Our List Includes : Label printers/converters Flexible packaging printers/converters Folding carton printers/converters Packaging printers/converters General printers/converters Brand owners Label designers Industry suppliers and many more.. If your target audience is not mentioned above, kindly let me know. Kindly confirm your exact target audience (Geographic Location / Business Vertical / Job Titles) so that we can send you few sample records for your internal review. Looking forward to connect with you! Thanks, Katherine Willis | Inside Sales We are expertise in:- B2B and B2C Email List, Email Appending, Reverse Appending, Email Campaign, Data Appending, Fax Appending, Phone Appending Services. ___ 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: Adding new media types to if_media.h
Any other thoughts, or should I start looking at seeing what I can take copy from net80211? Also adding -net, since this is pretty relevant. On Tue, Dec 9, 2014 at 10:40 AM, Adrian Chadd wrote: > > On 9 December 2014 at 07:27, Rui Paulo wrote: > > On Dec 9, 2014, at 01:05, Eric Joyner wrote: > >> > >> This is a continuation of a discussion from off the list: > >> > >> ixgbe needs to support devices with media types that aren't in > if_media.h; > >> for now those are 10GBaseKR, 10GBaseKX4, and 1000baseKX. Immediately, > we're > >> running into the issue that there is no room for all of these types > under > >> the IFM_ETHER category; there's only room for two more (and per John > >> Baldwin, only one more if one of those two unused types is to be used > for a > >> reserved type). Long term, there are going to be tons of media types for > >> future ethernet speeds like 25G, 50G, 100G, and etc, and ixl already > >> supports media types that aren't in if_media.h, either. > >> > >> So, something needs to change. Does anyone have any thoughts on what > should > >> happen? I've thought of a few things, but I don't have an adequate > grasp of > >> what the pros/cons of each are: > >> > >> 1. Add a new media category (like IFM_ETHER) and change kernel code to > >> treat it like the existing IFM_ETHER. This creates ~28 new media types > we > >> can use, but it may just be delaying the inevitable for a short time. > >> > >> 2. Extend media value from 32-bits to 64-bits. I don't have a good idea > of > >> what the consequences are of this on architectures that aren't amd64. > >> > >> 3. (Initially suggested by Adrian) would be to create a new media type > >> struct (instead of using an int value) or adding an extra value to the > >> existing ifmedia/ifmedia_entry struct for this. This sounds like the > best > >> solution to me, but I don't know how much effort it would take to > implement > >> -- does ifconfig need a lot of changing to handle this? > > > > ifconfig is a macro-intensive application, so maybe it's not that much > work. > > > >> Thoughts? Any previous discussions worth looking at? > > > > Hmm, it looks like you're limited in the number of bits because of how > the word was laid out. We can't simple remove token ring and get more bits > for ethernet... We could create another IFM_40GETHERNET type to replace > token ring but that would be ugly (the IFM_TYPE() macro could handle this > idiosyncrasy). > > > > I think if_media should probably be a structure with unions to store the > subtypes. net80211 has the same problem with MCS rates and we ended up > storing them outside if_media because of this. > > I think solving this like how it's done in net80211 (ie, with an > external structure that represents the media type details for a given > media) is the right thing to do. > > Otherwise it'll be a path to madness in the future. > > The net80211 side of things is mostly extensible and I'm going to > (eventually) end up using it for the 11ac rates that have shown up. I > couldn't do that whilst trying to cram it into the existing ifmedia > variable. > > > -adrian > ___ 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"
