Fwd: NIC RoCE Driver
Greetings net@ I can go through these changes, but there's a lot of APIs that I have only a passing familiarity with. If anybody here has some time to review a bunch of low-level changes to the bxnt driver, that would be great! Thanks Warner -- Forwarded message - From: Chandrakanth Patil Date: Mon, May 6, 2024 at 10:24 PM Subject: NIC RoCE Driver To: Warner Losh Hi Warner, We have submitted the new NIC RoCE driver for review a week back. Could you please review and provide the feedback. Below are the patches link: https://reviews.freebsd.org/D45005 https://reviews.freebsd.org/D45006 https://reviews.freebsd.org/D45007 https://reviews.freebsd.org/D45008 https://reviews.freebsd.org/D45009 https://reviews.freebsd.org/D45010 https://reviews.freebsd.org/D45011 -ckp
Re: review request: changing the default ifconfig(8) address format to CIDR
I'll remind everybody that ifconfig has had IFCONFIG_FORMAT since ``` commit 7c2aa744374aa3449ad81f60852e74ad73d823e6 Author: Allan Jude Date: Tue May 31 17:30:08 2016 + ifconfig(8) now supports some output formatting options ``` so we've already 7 years into this process. This is nothing new and the desire to migrate has been around a long time. As such, we can transition in 15, and put a release note into 14.1 release that's coming up and still give people years worth of notice. We don't need to give 4 or 5 years notice to do this in 16. That's too long and people will take their eye off the ball and it will be 17 or 18 before it happens. I've had several things I "gratuitously" had a long horizon on, only to forget about until it was too late (14.0 was supposed to have an awk that didn't decode hex number, for example). Also, broken scripts are a 1 line fix away from working, so the impact is rather small, and that one line can be set globally for people that have a lot of these scripts. The fix can be placed into the release notes as well. In addition, there's plenty of time for us to get a feel on how many scripts there actually are here. We can back off to a longer time horizon if it proves to be too disruptive. It would be even better if ifconfig, or a similar tool, could produce easy to use in scripts data (like json via libxo). I'm surprised there's no libxo option to it today. Of course these would be a more intrusive change, but would insulate us from data change like we've done in nearly every other system. I don't support more weird options, though, to make the current formats more maillable. We need to start pushing people into scripting with useful data formats. That includes doing stragglers like nvmecontrol, camcontrol, ifconfig up with libxo options. So I agree with Mike Karels's post in the bug review on this... We should do it *NOW* for 15, document well the workarounds and collect data to see if people are right about the scope. If so, we take a step back and do this in 16. If not, we go forward. This will still give corporate users 2 or 3 years to get their act together for a release (dropping in the IFCONFIG_FORMAT today in their scripts will work and keep them working well into the future with all supported FreeBSD version, and then some). Warner On Sat, May 4, 2024 at 12:35 PM Tomoaki AOKI wrote: > On Sat, 4 May 2024 16:34:03 +0100 > Lexi Winter wrote: > > > hi, > > > > i've just submitted this PR: > > > > https://github.com/freebsd/freebsd-src/pull/1216 > > > > which contains this commit: > > > > commit 57d273c90ee1c17446236aba25ed0bd291c4f126 (HEAD -> lf/main, > hemlock/lf/main) > > Author: Lexi Winter > > Date: Sat May 4 16:11:21 2024 +0100 > > > > ifconfig(8): change default IP address format to 'cidr' > > > > 'netmasks' haven't been used in IP networking for decades. Change > the > > default address format for both IPv4 and IPv6 addreses in > ifconfig(8) to > > 'cidr', which prints addreses in the format most users will be more > > familiar with. > > > > The previous format is still available using -finet:hex or > -finet6:numeric. > > > > imp@ suggested i should ask arch@ and net@ about this, so here i am! > > > > i understand there might be some backward-compat concerns with scripting > > here, but it's well past time this change was made, and anyone who > > really can't update their scripts can use ifconfig -f or > > $IFCONFIG_FORMAT to retain the old behaviour. > > Hi. > > If you raally want it to be landed, you should wait at least 2 major > releases. Propagate the future change on Relesase Notes at 15.0, then, > actually change in 16.0 shoule be the earliest. Maybe 17.0 would be > reasonable. > > This could be t hazardous on corporate-class users having > scripts/configurations for current style. > > We SHALL give enough YEARS for their admins to look into ALL their > scripts/configuratins and fix everything affected. Moreover, if the > fixes are widely affecting with their internal apps, they could need to > acquire budgets to do so. > > Possibly, introducing environment variable set in /etc/defaults/rc.conf > to select which format to use could help them. With it, they can set it > to use current format for all their computers running FreeBSD until > they fix all they need. > Something like IP_FORMAT=CIDR or IP_FORMAT=NETMASK. > > Regards. > > -- > Tomoaki AOKI > >
Re: Question about netinet6/in6.h
On Fri, Apr 26, 2024, 9:33 PM Bakul Shah wrote:
>
>
> > On Apr 26, 2024, at 5:02 PM, Mike Karels wrote:
> >
> > On 26 Apr 2024, at 18:06, Warner Losh wrote:
> >
> >> On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
> >>
> >>> On 26 Apr 2024, at 15:49, Mike Karels wrote:
> >>>
> >>>> On 26 Apr 2024, at 15:01, Warner Losh wrote:
> >>>>
> >>>>> This has to be a FAQ
> >>>>>
> >>>>> I'm porting a program from Linux, I often see an error like:
> >>>>> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in
> >>> 'struct
> >>>>> in6_addr'
> >>>>> 95 | ipv6->sin6_addr.s6_addr32[3] = 0;
> >>>>> | ~~~ ^
> >>>>> but yet, we kinda define them, but only for the kernel and boot
> loader:
> >>>>> /*
> >>>>> * IPv6 address
> >>>>> */
> >>>>> struct in6_addr {
> >>>>>union {
> >>>>>uint8_t __u6_addr8[16];
> >>>>>uint16_t__u6_addr16[8];
> >>>>>uint32_t__u6_addr32[4];
> >>>>>} __u6_addr;/* 128-bit IP6 address */
> >>>>> };
> >>>>>
> >>>>> #define s6_addr __u6_addr.__u6_addr8
> >>>>> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */
> >>>>> #define s6_addr8 __u6_addr.__u6_addr8
> >>>>> #define s6_addr16 __u6_addr.__u6_addr16
> >>>>> #define s6_addr32 __u6_addr.__u6_addr32
> >>>>> #endif
> >>>>>
> >>>>> I'm wondering if anybody why it's like that? git blame suggests we
> >>> imported
> >>>>> that from kame, with
> >>>>> only tweaks by people that are now deceased*.*
> >>>>>
> >>>>> Why not just expose them?
> >>>>
> >>>> Looks like only s6_addr is specified in the RFCs (2553 and 3493).
> Oddly,
> >>>> though, the RFCs give an example implementation using that union with
> >>>> different element names (like _S6_u8), and show the one #define.
> >>>> Similarly, POSIX specifies only s6_addr, but it allows other members
> >>>> of the structure, so I don't see a problem with exposing them all even
> >>>> in a POSIX environment.
> >>>>
> >>>> I would have no objection to exposing all four definitions, especially
> >>>> if Linux apps use them.
> >>>
> >>> I put the change, along with an explanatory comment, in
> >>> https://reviews.freebsd.org/D44979. Comments welcome.
> >>>
> >>
> >> Thanks! I was testing a similar change, but I like yours better...
> though
> >> maybe
> >> we should just make it visible when __BSD_VISIBLE is true I'll have
> to
> >> look
> >> closely at what Linux does here... I think they have it always visible,
> or
> >> at least
> >> musl does that (glibc is harder to track down due to the many layers of
> >> indirection).
> >
> > I thought briefly about __BSD_VISIBLE, but wasn't sure it was necessary.
> > Let me know what you find out. I think it should work either way; in.h
> > includes cdefs.h, so it's guaranteed to have been included.
>
> If the -ms-extensions option is used with gcc or clang, this ugliness can
> go away as you can have nested anonymous unions or -structs and their
> fields
> can be referenced as if they're directly in the parent struct/union.
>
> [IIRC this was present in Plan9 C from very early on. Also in C11 or later]
True. In fact c11 and newer doesn't need anything on the command line here.
If it were only in the kernel then I'd chamge it like thay while I was
here... but lots of code in ports will specify c99 + POSIX 2001 and to
compile there your only hope is this construct
Warner
Re: Question about netinet6/in6.h
On Fri, Apr 26, 2024 at 4:21 PM Mike Karels wrote:
> On 26 Apr 2024, at 15:49, Mike Karels wrote:
>
> > On 26 Apr 2024, at 15:01, Warner Losh wrote:
> >
> >> This has to be a FAQ
> >>
> >> I'm porting a program from Linux, I often see an error like:
> >> ./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in
> 'struct
> >> in6_addr'
> >>95 | ipv6->sin6_addr.s6_addr32[3] = 0;
> >> | ~~~ ^
> >> but yet, we kinda define them, but only for the kernel and boot loader:
> >> /*
> >> * IPv6 address
> >> */
> >> struct in6_addr {
> >> union {
> >> uint8_t __u6_addr8[16];
> >> uint16_t__u6_addr16[8];
> >> uint32_t__u6_addr32[4];
> >> } __u6_addr;/* 128-bit IP6 address */
> >> };
> >>
> >> #define s6_addr __u6_addr.__u6_addr8
> >> #if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */
> >> #define s6_addr8 __u6_addr.__u6_addr8
> >> #define s6_addr16 __u6_addr.__u6_addr16
> >> #define s6_addr32 __u6_addr.__u6_addr32
> >> #endif
> >>
> >> I'm wondering if anybody why it's like that? git blame suggests we
> imported
> >> that from kame, with
> >> only tweaks by people that are now deceased*.*
> >>
> >> Why not just expose them?
> >
> > Looks like only s6_addr is specified in the RFCs (2553 and 3493). Oddly,
> > though, the RFCs give an example implementation using that union with
> > different element names (like _S6_u8), and show the one #define.
> > Similarly, POSIX specifies only s6_addr, but it allows other members
> > of the structure, so I don't see a problem with exposing them all even
> > in a POSIX environment.
> >
> > I would have no objection to exposing all four definitions, especially
> > if Linux apps use them.
>
> I put the change, along with an explanatory comment, in
> https://reviews.freebsd.org/D44979. Comments welcome.
>
Thanks! I was testing a similar change, but I like yours better... though
maybe
we should just make it visible when __BSD_VISIBLE is true I'll have to
look
closely at what Linux does here... I think they have it always visible, or
at least
musl does that (glibc is harder to track down due to the many layers of
indirection).
Warner
Question about netinet6/in6.h
This has to be a FAQ
I'm porting a program from Linux, I often see an error like:
./test/mock-ifaddrs.c:95:19: error: no member named 's6_addr32' in 'struct
in6_addr'
95 | ipv6->sin6_addr.s6_addr32[3] = 0;
| ~~~ ^
but yet, we kinda define them, but only for the kernel and boot loader:
/*
* IPv6 address
*/
struct in6_addr {
union {
uint8_t __u6_addr8[16];
uint16_t__u6_addr16[8];
uint32_t__u6_addr32[4];
} __u6_addr;/* 128-bit IP6 address */
};
#define s6_addr __u6_addr.__u6_addr8
#if defined(_KERNEL) || defined(_STANDALONE) /* XXX nonstandard */
#define s6_addr8 __u6_addr.__u6_addr8
#define s6_addr16 __u6_addr.__u6_addr16
#define s6_addr32 __u6_addr.__u6_addr32
#endif
I'm wondering if anybody why it's like that? git blame suggests we imported
that from kame, with
only tweaks by people that are now deceased*.*
Why not just expose them?
Warner
CI tests disabled
The following CI tests have been failing for a while (weeks?). I've disabled them in CI and filed bugs. sys.net.if_bridge_test.span sys.netpfil.pf.forward.v6 sys.netpfil.pf.set_tos.v6 sys.netpfil.pf.killstate.v6 https://bugs.freebsd.org/260461 https://bugs.freebsd.org/260460 https://bugs.freebsd.org/260459 https://bugs.freebsd.org/260458 Feel free to re-enable them after they are working in CI again. Warner
Re: RFC: removing ndis(4)
On Wed, Dec 2, 2020 at 5:13 PM Brooks Davis wrote: > I'd like to propose that we remove the ndis(4) driver prior to FreeBSD > 13. It was a clever idea in the early 2000's when the market was > flooded with 10/100 NICs with Windows-only drivers, but that hasn't been > the case for ages and the driver has had no meaningful maintenance in > ages[0]. I'd be a bit surprised if it worked at all today (it surely > won't work with modern Windows drivers). > > To try to examine the popularity of ndis, I checked dmesgd.nycbug.org > and there are 5 total entries with the most recent being 2007. > > The PC Card attachments are currently marked for deletion prior to > FreeBSD 13. > > Unless there is surprising outcry I plan to add (and MFC) deprecation > notices in about a week's time and remove the driver shortly thereafter. > > -- Brooks > > [0] I noticed today that part of the ndis 802.11 ioctl handler has been > broken since 2005. > Like PC Card, it's time to bid this old friend farewell... Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
On Sun, May 12, 2019, 9:28 PM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > Eugene Grosbein wrote: > > > 11.05.2019 22:59, Julian H. Stacey wrote: > > > > > > >> 11.05.2019 21:32, Julian H. Stacey wrote: > > > >> > > > I've posted a review to remove obsolete 10 and 10/100 Ethernet > drivers > > > as previous approved in FCP-101. > > > The following drivers are slated for > > > removal from FreeBSD-HEAD (to be FreeBSD-13): > > > > > > ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, > xe > > > >>> > > > >>> OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > > >>> spare) that will never be able to upgrade. > > > >> > > > >> Do those boxes have 10M-only or 100Mbps variants of ed(4)? > > > >> What kind of hardware do they have (CPU and memory-wise)? > > > > > > > > Thanks for question. I ran a quick check: > > > > cd /usr/src; > > > > # Apply my patches: > > > > # customise `pwd` > > > > # http://www.berklix.com/~jhs/bin/.csh/customise > > > > cd /sys/amd64/conf > > > > grep device [A-Z][A-Z][A-Z][A-Z].small | grep ed > > > > DUAL.small:device ed > > > > FILM.small:device ed > > > > KING.small:device ed > > > > LAPA.small:device ed > > > > LAPD.small:device ed > > > > LAPL.small:device ed > > > > LAPN.small:device ed > > > > LOFT.small:device ed > > > > MINI.small:device ed > > > > SCAN.small:device ed0 at isa? port 0x280 irq 15 iomem 0xd iosiz > 0x1 > > > > SLIM.small:device ed > > > > SNOW.small:device ed0 at isa? port 0x280 irq 5 iomem 0xc8000 > > > > WIND.small:device ed > > > > > > I've asked not for configuration files but for description of hardware. > > > ed(4) supports many different models. Some of them do 10Mbps only > > > but some are 100M-capable including PCI-connected. > > > > > > And it's interesting to know what is CPU and memory type/amount of > boxes. > > > > Info I had long pre saved, exported here: > > http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/ > > Many boxes run newer releases than logs show, but eg dmesg shows memory > etc. > > It would help if you could run this from the hosts directory above and > post the output here, I doubt anyone besides me well bother looking > any further than this email at this data, but they well if you post > this output: > > find . -type f | grep /dmesg | xargs egrep 'CPU:|real memory|Ethernet' > > That should give us machine name by file path, CPU type, memory and > what ethernet cards are in it. > > I found one box, the second one I looked at, > http://www.berklix.com/~jhs/src/bsd/fixes/FreeBSD/hosts/logs/blak/dmesg0 > that clearly has enough CPU and memory to run 13: > CPU: Pentium II/Pentium II Xeon/Celeron (334.09-MHz 686-class CPU) > real memory = 536858624 (511 MB) > ed0: at port 0x240-0x25f iomem 0xcc000-0xc > irq 5 pnpid EDI0119 on isa0 > ed0: [ITHREAD] > ed0: WARNING: using obsoleted if_watchdog interface > ed0: Ethernet address: 00:00:b4:36:a5:04 > > > Re Gary's: > > > 2) what versions of FBSD is Julian now running on his hardware? > > > 3) does he ever plan to upgrade this hardware to >= FBSD 13? > > > > Not many, if any of them; I should idealy find time to purge some, > > but I also have sundry newer PCs, & spare ed etc cards, so a pity to > loose ed. > > > > > > More generaly It won't be just me with ed. With 13 I can power up any > time, > > (+ other pcmcia & PCI & ISA cards in boxes) there's probably many more > globaly. > > > > But sys admins often don't have time to read developer lists like > > current@ & arch@. So developer considering zapping things, will > > not be seen by users it will hit later. > > > > First many will know is seeing in a RELNOTES "XYZ will be removed > > in release [0-9].[0-9]" No chance to answer an earlier "Are many > > still using XYZ, we're thinking of deleting it ?" > > I believe all of the proposed cards have been announcing > they are gone in FreeBSD 13 starting at FreeBSD 12. > > I am NOT clear if these gonein notices got backported to > 11, if not they should be ASAP as getting notice out to > the 11.3 users is important too. > > > If ed is the biggest legacy NIC, best be cautious ? > > I agree to some extent, but have no hard use evedence. > Last time I ran the reports from nycbug dmesg reports. Ed was rare starting in 7, and absent 9 and newer. That suggests it's once dominant position has decayed to almost nothing in the 25 years since it was king. I'd included this data at some point in the past, I thought. Warner > (BTW I also have 2 boxes running today's current, not just old Rels here.) > > > > Cheers, > > Julian > > -- > > Julian Stacey, Consultant Systems Engineer, BSD Linux Unix, Munich > Aachen Kent > > http://stolenvotes.uk Brexit ref. stole votes from 700,000 Brits in > EU. > > Lies bought; Groups fined; 1.9 M young had no vote, 1.3 M old leavers > died. > > ___ > > freebsd-curr...@freebsd.org mailing list > >
Re: FCP-101: obsolete driver removal planned for 2019-05-18
On Sun, May 12, 2019, 12:00 PM Eugene Grosbein wrote: > 12.05.2019 8:21, Warner Losh wrote: > > > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet > drivers > > >> as previous approved in FCP-101. > > >> The following drivers are slated for > > >> removal from FreeBSD-HEAD (to be FreeBSD-13): > > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, > xe > > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > > spare) that will never be able to upgrade. > > Do those boxes have 10M-only or 100Mbps variants of ed(4)? > > What kind of hardware do they have (CPU and memory-wise)? > > > > There are no 100M ed variants. There are some PC Card variants that have > 100M MII connections, but they are limited to about 12Mbps due to bus > limits. Even the PCI ones didn't have 100M mii connections. > > There was RTL8029AS "NE2000-compatible" 100M 32 bit PCI 2.1 adapter. > Not sure if ed(4) supports RTL8029AS. > It does, but there is the same limitations. The card can't do DMA, so it's limited by inb/outb limitations. It also only has a 10Mbps transceiver built in. If people sold 100M attachments, it still won't do much more than 10Mbps. Warner > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
On Sat, May 11, 2019, 12:52 PM Eugene Grosbein wrote: > 11.05.2019 21:32, Julian H. Stacey wrote: > > >> I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > >> as previous approved in FCP-101. > >> The following drivers are slated for > >> removal from FreeBSD-HEAD (to be FreeBSD-13): > >> > >> ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > spare) that will never be able to upgrade. > > Do those boxes have 10M-only or 100Mbps variants of ed(4)? > What kind of hardware do they have (CPU and memory-wise)? > There are no 100M ed variants. There are some PC Card variants that have 100M MII connections, but they are limited to about 12Mbps due to bus limits. Even the PCI ones didn't have 100M mii connections. Warner > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-101: obsolete driver removal planned for 2019-05-18
On Sat, May 11, 2019, 12:03 PM Rodney W. Grimes < freebsd-...@gndrsh.dnsmgr.net> wrote: > > > I've posted a review to remove obsolete 10 and 10/100 Ethernet drivers > > > as previous approved in FCP-101. > > > The following drivers are slated for > > > removal from FreeBSD-HEAD (to be FreeBSD-13): > > > > > > ae, bm, cs, de, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, wb, xe > > > > OMG ! ed ! That EOL's loads of PC boxes I have (& a show box of > > spare) that will never be able to upgrade. > > I thought ed was already saved from this process, as that is the NE2000 > driver, probably the most cloned network device on the planet. > It was even a decade ago, but the world moved on. virtualization has supported newer NICs for years. Ed(4) doesn't do DMA and is quite limited in terms of what it can do. But even so, we'd set the threshold at 5 or 10 installed machines running 11 or newer. If Julian legit has that many machines, then we can remove it from the list. In the initial period of this process, all the folks that were concerned turned put to not have machines. The nycbug dmesg stats also showed no use after 8 or so. Warner -- > Rod Grimes > rgri...@freebsd.org > ___ > freebsd-curr...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Reminder: FCP-101: pending removal of some 10/100 Ethernet drivers
On Fri, Feb 1, 2019, 11:05 AM Brooks Davis On Fri, Feb 01, 2019 at 04:00:50AM -0800, Rodney W. Grimes wrote: > > > On Thu, Jan 31, 2019 at 11:43:44PM +, Brooks Davis wrote: > > > > We are currently planning to remove the following less-popular 10/100 > > > > Ethernet drivers in the March/April timeframe: > > > > > > > > ae, bm, cs, de, dme, ed, ep, ex, fe, pcn, sf, sn, tl, tx, txp, vx, > wb, xe > > > > > > > > All of these drivers generate warnings in FreeBSD 12 and to the best > of > > > > my knowledge, none have cleared the bar specified in the FCP[0]: > > > > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > > > Hi, > > > > > > The above document states that the support lifetime for FreeBSD 12 is > 2023. > > > > > > The expected EOL (but not decided) for 12 is June 30, 2020 however, > according to > > > > Can someone please go revise where ever this is posted based on the 18 > month > > minima that was set to simply state "undetermined", people are reading > too much > > into the date posted there. > > > > > https://www.freebsd.org/security/security.html#sup > > > > > > So, hardware in some of my machines will only be supported until > sometime next > > > year. > > > > Brooks, > > Given that at the time FCP-101 was written part of it was > > based on the assumption of a 5 year life time for 12.0. Since that > > assumption is now invalid, and worse, unknown, I would ask that until > > a decision about the life of 12.0 is made we back off on the FCP-101 > process > > and not do anything about removing drivers until that support > > model adjustment is finalized and we can evaluate the impact on > > FCP-101's assumption. > > Per the text of my email and the schedule in the FCP, no deletions > will occur until after the support lifetime of 12 is scheduled to be > resolved. Should that date slip then any deletions would also slip. > Should the lifetime of 12 be drastically reduced relative to the > original lifetime, then yes we should revisit our list and schedule. > > A majority of these devices have *zero* confirmed users so we should > likely delete them before 13 no matter what happens to 12-STABLE's > lifetime. > None of the drivers on the current list, with the possible exception of ae, are used enough that the 12.x support timeline matters at all. And only in the craziest of scenarios would ae come close to mattering. The rest are all already dead and not even a close call between completely irrelevant and almost completely irrelevant, let alone meeting a standard of relevant enough to provide net value to the project. No further action beyond data collection is scheduled on this FCP until > after the end of the quarter. I should run a new report based on the data we have around that time as well... Warner -- Brooks > > P.S. All of this hardware will be supported until at least September 30, > 2021 on FreeBSD 11-STABLE. > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Tue, Oct 23, 2018 at 6:02 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > -- Start of PGP signed section. > > On Tue, Oct 23, 2018 at 04:26:45PM -0700, Rodney W. Grimes wrote: > > > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > > > I'd also suggest that rl stands in stark contrast to the cs, > wb, sn, > > > > > smc, > > > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > > > thread, and > > > > > > > > which I doubt are in use in any FreeBSD system of any age > today. > > > > > > > > > > > > > > vr is used by my TV driver laptop: > > > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > > > vr0: flags=8843 metric > 0 mtu > > > > > 1500 > > > > > > > options=82808 > > > > > > > ether 00:40:d0:5e:26:38 > > > > > > > inet 192.168.91.65 netmask 0xff00 broadcast > 192.168.91.255 > > > > > > > media: Ethernet autoselect (100baseTX > > > > > ) > > > > > > > status: active > > > > > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade > soon > > > > > > > when I also configure it to receive from a raspberry-pi TV VPN > server. > > > > > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > > > > > -- Brooks > > > > > Brooks, > > > > > Is there a public revised version of FCP-0101 that > reflects the > > > > > feedback which is what core is voting on? > > > > > > > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > > > submit pull requests against and track: > > > > > > I have no gh account, desires no gh account, so have no way to > > > submit a change request other than through direct email to > > > brooks or another gh user. This is fundementally flawed. > > > > > > > https://github.com/freebsd/fcp/blob/master/fcp-0101.md > > > > > > Thank you for the link, I had looked at it before MeetBSD, > > > which did not have most of the recent changes done "a day ago". > > > > > > Isnt this document now in a frozen state while core reviews/votes? > > > > I sent it to a vote at c224c67557297d7cba909ad008542cb60980cc6b only > > to notice a bug in table rendering. I submitted a pull request fix > > that and a missing word which was merged since neither was material. I > > suppose they could have waited or been skipped, but there's no value in > > the FCP process being bound by the sort of pointless rigidity that led > > to -DPOSIX_MISTAKE in every libc compile line. > > The FCP process itself is unclear on this point, > I think this should be clarified. > > It is much more clear on post approval: > Changes after acceptance > > FCPs may need revision after they have been moved into the > accepted state. In such cases, the author SHOULD update the > FCP to reflect the final conclusions. > If the changes are major, the FCP SHOULD be withdrawn > and restarted. > Good point Rod. While common sense suggests that trivial changes during the voting should be allowed for editorial purposes (eg fix grammar mistakes, table rendering etc), it's better to spell that out so there's no confusion. diff --git a/fcp-.md b/fcp-.md index b4fe0f3..c8cc6f7 100644 --- a/fcp-.md +++ b/fcp-.md @@ -144,7 +144,10 @@ When the discussion of a change has come to a suitable and acceptable close it SHOULD be updated to the `vote` state. At this time the FreeBSD Core Team will vote on the subject of the FCP. The -result of vote moves the FCP into the `accepted` or `rejected` state. +result of vote moves the FCP into the `accepted` or `rejected` state. The +core team MAY make minor edits to the FCP to correct minor mistakes. Core +MAY return the proposal to the submitter if there are major problems that +need to be addressed. FCPs in the `accepted` state can be updated and corrected. See the "Changes after acceptance" section for more information. Normally I'd submit that as a pull request, but since I know you don't use github, I thought I'd present it here to see if this answers your concerns before doing so. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Tue, Oct 23, 2018 at 5:26 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < > > freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > > > > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, > sn, > > > smc, > > > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > > > thread, and > > > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > > > > > vr is used by my TV driver laptop: > > > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > > > vr0: flags=8843 metric 0 > mtu > > > 1500 > > > > > options=82808 > > > > > ether 00:40:d0:5e:26:38 > > > > > inet 192.168.91.65 netmask 0xff00 broadcast > 192.168.91.255 > > > > > media: Ethernet autoselect (100baseTX > > > ) > > > > > status: active > > > > > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > > > when I also configure it to receive from a raspberry-pi TV VPN > server. > > > > > > > > The above was a typo. vr is on the the STAY list. > > > > > > > > -- Brooks > > > Brooks, > > > Is there a public revised version of FCP-0101 that reflects the > > > feedback which is what core is voting on? > > > > > > > Its on github, just like it's been the whole time for anybody to see, > > submit pull requests against and track: > > I have no gh account, desires no gh account, so have no way to > submit a change request other than through direct email to > brooks or another gh user. This is fundementally flawed. > The fcp process was officially approved by core.9. You can make suggestions to core for improvements to the process. Lord knows this FCP hasn't been trouble free (though we've learned some valuable lessons). Submissions to the author is always an option should you choose not to use the widely used technology we've chosen to automate this process. Some FreeBSD users don't have accounts, however, many non-developers have github accounts and I think it's a reasonable way to do outreach to the larger community w/o requiring everybody to get a freebsd account (since they are already likely to have a github account, and if not they are trivial to get). So yea, it's a flawed process, and we'd love feedback on actionable items we can do to make it better. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Tue, Oct 23, 2018 at 3:57 PM Julian H. Stacey wrote: > Doug Hardie wrote: > > I have a number of production servers that only have bge and I don't see > that listed in either category. None of them are running FreeBSD 12 yet as > it has not been released. Also there are some with rl. Those are add-on > boards so they could be changed, but would require extensive effort as the > machines are about a 4 hour drive from here and would require > reconfiguration (an error prone process when you are tired). > > bge is also used by my main laptop with current Oct 15 18:33 > /boot/kernel/kernel > > bge0: flags=8843 metric 0 mtu 1500 > > options=c019b > media: Ethernet autoselect (1000baseT ) > > Doug, I think bge must be safe as man 4 bge: > "bge - Broadcom BCM57xx/BCM590x Gigabit/Fast Ethernet driver" > & Brooks proposal was ... "a plan to deprecate most 10/100 Ethernet > drivers" > Indeed. https://github.com/freebsd/fcp/blob/master/fcp-0101.md shows bge is not on the list to go. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Tue, Oct 23, 2018 at 5:07 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Tue, Oct 23, 2018 at 11:33:35PM +0200, Julian H. Stacey wrote: > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, > smc, > > > > sf, tl, tx and vr drivers, which nobody has mentioned in this > thread, and > > > > which I doubt are in use in any FreeBSD system of any age today. > > > > > > vr is used by my TV driver laptop: > > > http://www.berklix.com/~jhs/hardware/laptops/novatech-8355/ > > > vr0: flags=8843 metric 0 mtu > 1500 > > > options=82808 > > > ether 00:40:d0:5e:26:38 > > > inet 192.168.91.65 netmask 0xff00 broadcast 192.168.91.255 > > > media: Ethernet autoselect (100baseTX > ) > > > status: active > > > > > > Which currently runs 8.4-RELEASE & eg xrandr, but I'll upgrade soon > > > when I also configure it to receive from a raspberry-pi TV VPN server. > > > > The above was a typo. vr is on the the STAY list. > > > > -- Brooks > Brooks, > Is there a public revised version of FCP-0101 that reflects the > feedback which is what core is voting on? > Its on github, just like it's been the whole time for anybody to see, submit pull requests against and track: https://github.com/freebsd/fcp/blob/master/fcp-0101.md Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Wed, Oct 17, 2018 at 11:52 AM Matthieu Volat wrote: > Would it be possible to set a wiki page/section in 12 that display the > current status of removal of those devices? That might be easier for people > to look at their hardware actual state rather than try to trace every > answer to this thread... > The FCP is being updated and will be uploaded when that's done. At this point, it seems that we have all the data to make the right decisions, at least to tag the drivers deprecated for the 12.0 release when I'm sure will get us additional data. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Mon, Oct 8, 2018 at 11:03 AM Brooks Davis wrote: > On Sun, Oct 07, 2018 at 11:25:48AM +0200, Andrea Venturoli wrote: > > On 10/4/18 3:07 PM, Warner Losh wrote: > > > > > At the root of this problem is the community's long resistance to > having > > > data reported back to the project data about the machines running > FreeBSD. > > > Absent any real and significant data, the only way to know if things > are > > > unused is to ask. We cannot have the act of merely asking cause people > to > > > freak out and hurl expletives all over the place. That's significantly > not > > > cool. > > > > First off, I absolutely don't want to flame: I'm glad you asked and I > > was happy to answer. > > > > Just out of curiosity, don't we have sysutils/bsdstats (which I install > > on all the boxes I manage, but I understand won't be present in most > > embedded systems)? > > Is that project such a failure? > > If so, should it be better promoted or would it be pointless? > > In theory it would provide valuable data, but in practice the website is > broken and unable to produce device data. I've asked multiple times for > it to be fixed. It would be great if it worked and we could use it. > There's also a few problems with using the data that's there for what we want to do with it. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Fri, Oct 5, 2018 at 9:05 AM Andrew Turner wrote: > > > On 3 Oct 2018, at 22:05, Brooks Davis wrote: > > > Please direct replies to freebsd-arch <<< > > > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > > and remove them in FreeBSD 13 to reduce the burden of maintaining and > > improving the network stack. We have discussed this within the > > core team and intend to move forward as proposed. We are solictiting > > feedback on the list of drivers to be excepted from removal. > > > > The current list of drivers slated for REMOVAL is: > > > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > > ste, tl, tx, txp, vx, wb, xe > > smc is found in the Arm models (simulators) [1]. I’ve seen it in the > Foundation and Architecture Envelope Models. I assume it’s also in the > other models, but don’t have a license for them to check. > Do we currently support those simulators? I see it is in the VERSATILEPB simulator that QEMU provides. Does that still work? Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Fri, Oct 5, 2018 at 8:46 AM Julian H. Stacey wrote: > > >>> Please direct replies to freebsd-arch <<< > > > > FCP-01010 (https://github.com/freebsd/fcp/blob/master/fcp-0101.md) > > outlines a plan to deprecate most 10/100 Ethernet drivers in FreeBSD 12 > > and remove them in FreeBSD 13 to reduce the burden of maintaining and > > improving the network stack. We have discussed this within the > > core team and intend to move forward as proposed. We are solictiting > > feedback on the list of drivers to be excepted from removal. > > > > The current list of drivers slated for REMOVAL is: > > > > ae, bfe, bm, cs, dme, ed, ep, ex, fe, pcn, rl, sf, smc, sn, > > ste, tl, tx, txp, vx, wb, xe > > I have many hosts using ed & rl, several using ep, & at least one > using xe or ex. That's just from memory, maybe other drivers in peril. > Later in the thread rl was removed from the list. What systems are you running ed, ex and/or xe on? So far I've heard no reports of people using the latter two in about a decade. Unless the functionality of drivers is sub-sumed in to other drivers, > stripping all those drivers would motivate some to never upgrade > again, or dump FreeBSD for a more conservative BSD, or fork FreeBSD etc. > You could also create a port/pkg for them and assume the burden of maintenance yourself. > Stripping dead code helps developers play easier, but stripping > live code is offensive. Some who periodicaly propose code demolitions > forget that many users of FreeBSD don't subscribe lists, except > maybe announce, as too busy, maintaining FreeBSD on networks ... > until their nets don't work. > I think in this case there will be plenty of warning. They will upgrade to 12, one assumes, and see the deprecation message in their new kernel logs. There's going to be about a 6 month window between when this is announced and when it happens to collect evidence that removal is unwarranted, to show they are still in use by enough people to justify their on-going (yes non-zero) cost to keep in the tree. There's over 2 years before they will be removed from a released version: also plenty of time to build a case that they are in use and/or upgrade to different, supported NICs. If you look at the rest of the thread, you'll see several people have made compelling cases and/or provided evidence of continued use into the future to keep the drivers in the tree. Evidence will save them, but harsh words will not. I think expecting people to blindly maintain code on the off chance someone is still using is offensive as well. We must weigh the costs of continuing with the benefits those cost provide. We don't have good sources of data for what's still in use and what's not, so we have to rely on these periodic calls for data to ensure we aren't wasting our time on hardware that's no longer used. Warner > Cheers, > Julian > -- > Julian Stacey, Computer Consultant, Systems Engineer, BSD Linux Unix, > Munich > Brexit: 3,700,000 stolen votes in 1st referendum inc. 700,000 from Brits > in EU > Campaign lies & criminal funding, economy & pound down: New referendum > needed. > http://exitbrexit.uk > ___ > freebsd-...@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-fcp > To unsubscribe, send any mail to "freebsd-fcp-unsubscr...@freebsd.org" > ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 12:18 PM Eugene Grosbein wrote: > 05.10.2018 0:38, Warner Losh wrote: > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > > which I doubt are in use in any FreeBSD system of any age today. > > vr(4) mentioned in the STAY list or else I would be first yelling as > it is still very common in embedded solutions (including integrated ports > in my home router). > Sorry, I'd meant to type vx. :) It's for the first generation of 3com cards after the 3C5x9 ones supported by the ep driver. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 11:47 AM Ian Lepore wrote: > On Thu, 2018-10-04 at 11:38 -0600, Warner Losh wrote: > > On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore wrote: > > > > > > > > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote: > > > > > > > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan > > > > wrote: > > > > > > > > > > > > > > > > > > > tech-lists wrote: > > > > > > > > > > > > > > > > > > > > > > > > I'm astonished you're considering removing rl given how common > it is. > > > > > > > > > > > I'll second that comment - though no disrespect to Brooks. Brooks > as > > > > > far as I can see is just the messenger. > > > > > > > > > Absent good data, one has to make one's best guesses. I guessed wrong > > > here > > > > > > > > in my comments to Brooks about which ones were must keeps. I knew it > was > > > > popular back in the day (~2000), but had thought it's popularity had > > > waned > > > > > > > > much more than it apparently has. I last deployed systems with rl in > them > > > > around 2007, and at the time it was trailing edge gear (the SBCs we > used > > > at > > > > > > > > Timing Solutions tended to use popular, but ~5-year-old technology > > > because > > > > > > > > that market segment wanted longevity of spare availability...). > > > > > > > > Warner > > > 11 years later, we (Timing Solutions, now a division of Microchip) are > > > still using SBCs with rl(4) hardware and still shipping software > > > updates with that driver built into the kernel. We build systems with a > > > lifespan in the field of 20 years or more, and the stability and > > > compatibility across OS upgrades over that kind of span is a BIG reason > > > to use freebsd rather than linux for such things. > > > > > OK. I'd have thought those SBCs would have gone out of production years > > ago It's a good datapoint to know that there's multiple users of > > FreeBSD using these parts in products that are still shipping. That's a > > clear and compelling benefit to the project that offsets the efforts that > > it's taken them to keep things current with rl. > > > > In this case, though, rl is off the list, so that hardware should still > be > > good. The only other SBC I was aware of at Timing Solutions was one that > > had an 'ed' chip on it (an ISA realtek part IIRC) that was used in around > > 2001, but in a 'one off' custom setup that I don't think will ever be > > upgraded But I have to ask since I know how things worked during my > > time there and systems that 'would never be upgraded' often times were > > later... > > > > I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, > > sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and > > which I doubt are in use in any FreeBSD system of any age today. > > > > Warner > > I checked all our various kernel configs, and the only one on the list > we still use appears to be rl. > > One driver I was surprised to see was not on the list was vte. So I'll > just preemptively mention that we do use that one too. > I'll assume that you've deployed more than 5 of these systems and that you may someday upgrade them as well? Which of the Vortex86 processors are you using, if you can answer that... Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 11:26 AM Ian Lepore wrote: > On Thu, 2018-10-04 at 10:21 -0600, Warner Losh wrote: > > On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan > > wrote: > > > > > > > > tech-lists wrote: > > > > > > > > > > > > I'm astonished you're considering removing rl given how common it is. > > > > > > > I'll second that comment - though no disrespect to Brooks. Brooks as > > > far as I can see is just the messenger. > > > > > Absent good data, one has to make one's best guesses. I guessed wrong > here > > in my comments to Brooks about which ones were must keeps. I knew it was > > popular back in the day (~2000), but had thought it's popularity had > waned > > much more than it apparently has. I last deployed systems with rl in them > > around 2007, and at the time it was trailing edge gear (the SBCs we used > at > > Timing Solutions tended to use popular, but ~5-year-old technology > because > > that market segment wanted longevity of spare availability...). > > > > Warner > > 11 years later, we (Timing Solutions, now a division of Microchip) are > still using SBCs with rl(4) hardware and still shipping software > updates with that driver built into the kernel. We build systems with a > lifespan in the field of 20 years or more, and the stability and > compatibility across OS upgrades over that kind of span is a BIG reason > to use freebsd rather than linux for such things. > OK. I'd have thought those SBCs would have gone out of production years ago It's a good datapoint to know that there's multiple users of FreeBSD using these parts in products that are still shipping. That's a clear and compelling benefit to the project that offsets the efforts that it's taken them to keep things current with rl. In this case, though, rl is off the list, so that hardware should still be good. The only other SBC I was aware of at Timing Solutions was one that had an 'ed' chip on it (an ISA realtek part IIRC) that was used in around 2001, but in a 'one off' custom setup that I don't think will ever be upgraded But I have to ask since I know how things worked during my time there and systems that 'would never be upgraded' often times were later... I'd also suggest that rl stands in stark contrast to the cs, wb, sn, smc, sf, tl, tx and vr drivers, which nobody has mentioned in this thread, and which I doubt are in use in any FreeBSD system of any age today. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 10:15 AM Michelle Sullivan wrote: > tech-lists wrote: > > > > I'm astonished you're considering removing rl given how common it is. > > > > I'll second that comment - though no disrespect to Brooks. Brooks as > far as I can see is just the messenger. > Absent good data, one has to make one's best guesses. I guessed wrong here in my comments to Brooks about which ones were must keeps. I knew it was popular back in the day (~2000), but had thought it's popularity had waned much more than it apparently has. I last deployed systems with rl in them around 2007, and at the time it was trailing edge gear (the SBCs we used at Timing Solutions tended to use popular, but ~5-year-old technology because that market segment wanted longevity of spare availability...). Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 9:59 AM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert > > wrote: > > > > > I'm willing to help out with rl(4) as I have one here. Others, not > > > scheduled for removal, that I can help one way or another are are NICs, > > > including wireless, currently installed here. > > > > > > > There's an iflib man page that's a decent place to start. The API has > > evolved over time, so corrections to the man page would be welcome (and > > committed as quickly as the freeze allows). I'm reading through the > current > > iflib drivers to see which one would be best to recommend. > > Nothing in the current state of the "freeze" would block a > man page correction. > All commits, no matter how trivial, require re@ approval. That necessarily slows things down, hence my phrase "as quickly as the freeze allows." Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 9:46 AM Cy Schubert wrote: > I'm willing to help out with rl(4) as I have one here. Others, not > scheduled for removal, that I can help one way or another are are NICs, > including wireless, currently installed here. > There's an iflib man page that's a decent place to start. The API has evolved over time, so corrections to the man page would be welcome (and committed as quickly as the freeze allows). I'm reading through the current iflib drivers to see which one would be best to recommend. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 8:40 AM Alexey Dokuchaev wrote: > On Thu, Oct 04, 2018 at 02:26:44PM +, Mark Linimon wrote: > > On Thu, Oct 04, 2018 at 08:44:11AM +, Alexey Dokuchaev wrote: > > > OK I guess I can understand removing 10 (I personally haven't seen > > > one in a very long time) but 100 are omnipresent and most of my NICs > > > are in fact 100. > > > > Sigh. If you really plan to still be using i386 and 10/100 ether in > > 2024, perhaps you should consider NetBSD. > > I don't quite understand why are you grouping 10/100 vs. 1000 rather than > 10 vs. 100/1000. > As far as I know, none of the drivers listed could do 1Gbps. They were all specifically 10Mbps or 10/100Mbps. Support for 10Mbps or 100Mbps isn't being removed from the tree: there's still dozens of GigE drivers that can do those speeds that have PCI or better bus attachments. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 2:45 AM Alexey Dokuchaev wrote: > Looking at the commits they require near zero maintenance. What exactly > is the burden here? > I believe that characterization is incorrect. There's a burden. And it's death of a thousand cuts. And many of those cuts have been inflicted on brooks@. Most of these drivers have had dozens or hundreds of commits each over the years to keep up with the API changes. This acts as a tax on innovation because it's such a pain in the back side to change all the drivers in the tree. I did a back of the envelope computation that this is on the order of hundreds of hours of time, spread across all the drivers over all the years we've supported them. Some of these drivers are clearly unused, and so that's 100% wasted effort. Most of these drivers are on machines that most likely won't be able to run 13.0 well when it comes out in 2 years due to increased memory demands that it will almost certainly have. The declining use means we anticipate that if we were to maintain them until 13, it would be wasted effort for at least some on the list. That's why that one way to get the driver off the list is to convert to iflib. That greatly reduces the burden by centralizing all the stupid, common things of a driver so that we only have to change one place, not dozens. At the root of this problem is the community's long resistance to having data reported back to the project data about the machines running FreeBSD. Absent any real and significant data, the only way to know if things are unused is to ask. We cannot have the act of merely asking cause people to freak out and hurl expletives all over the place. That's significantly not cool. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: FCP-0101: Deprecating most 10/100 Ethernet drivers
On Thu, Oct 4, 2018 at 6:53 AM Luciano Mannucci wrote: > On Thu, 4 Oct 2018 13:03:01 +0700 > Eugene Grosbein wrote: > > > The current list of drivers that will STAY in the tree is: > > > > > > dc, ffec, fxpl, hme, le, sis, vr, xl > > > > "fxpl" should have been "fxp" here, I suppose. > Yes. > > While I have no objection for general direction, I have doubts about > removal > > of ste(4) and especially rl(4). These are cheap 100Mbit VERY popular NICs > > sold in enourmous values in certain markets by vendors like D-Link and > > TP-Link using various trade names. > Enough people are using rl that it's off the list by my count. > > Lack of support for such popular 100M cards won't be good for FreeBSD, I > > suppose. > > I have a lot of them in production systems. It would be a pity that they > will never get a 12.x or newer version ever. I can replace few de cards > but not everything... > To be clear, the proposal is that 12.x be the last branch they are supported in and not in 13. So while we'd remove them from current soon, they'd still be in 12 for the life of the 12.x branch, so into the early 2020's. Warner ___ freebsd-net@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)
imp added a comment. So why doesn't the lle* code set mpsafe to 1? After re-reading the man page several times, I'm thinking that's the solution here. It already uses other locks and reference counts to synchronize things, so why get Giant involved at all? REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ 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
[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)
imp added a comment. For the lle* code, it looks like the reference count for the data structure improperly doesn't cover the implicit use of the mutex by the callout system. That seems to be the real bug here, no? Protecting a mutex with a reference count without holding a reference to that mutex until the callout code cannot use it again? Not sure how, however, we can properly drop the reference count to the mutex with the current callout API :( REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, lstewart, jhb, kostikbel, sbruno, imp, adrian, hselasky Cc: julian, hiren, jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ 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
[Differential] [Updated] D1761: Extend LRO support to accumulate more than 65535 bytes
imp added a comment. Except for the signed / unsigned issue, I like this change. However, please get approval from some of the networking guys before committing. INLINE COMMENTS sys/netinet/ip_input.c:1450 Shouldn't this be unsigned? sys/netinet/ip_output.c:129 shouldn't this be unsigned? sys/netinet/ip_output.c:709 unsigned? sys/netinet/tcp_lro.c:233 This really isn't a compile time constant (though I think FreeBSD has magic to kinda make it such). I don't see what's wrong with uint16_t p_len = htons(65535) honestly. The enum type is also signed, which may cause some grief with subtle assumptions in the code. REVISION DETAIL https://reviews.freebsd.org/D1761 To: hselasky, rmacklem, rrs, glebius, gnn, emaste, bz, adrian, rwatson, imp Cc: freebsd-net ___ 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
[Differential] [Accepted] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).
imp accepted this revision. imp added a comment. I think we're ready to land. It fixes all the issues discussed, and enhanced testing shows no additional errors. INLINE COMMENTS kern/kern_timeout.c:1159 When the callout wheel runs, it will ignore this callout maybe is a better phrase to use here rather than have an ambiguous callout that refers to two different things in the same sentence. kern/kern_timeout.c:1234 tiny nit: I think this is indented wrong, but Phabric is so lame I can't tell for sure. Please check and fix if it isn't indented 4 spaces. sys/callout.h:67 I'd be tempted to create a callout_processed() macro too and use it in the last chunk of kern_timeout.c, but that can be done as a separate commit. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, sbruno, lstewart, jhb, kostikbel, hselasky, adrian, imp Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ 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
[Differential] [Commented On] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests)
imp added a comment. I agree that the kernel test framework should be done differently as well. I didn't realize the number of mechanical changes my request to use the macros produced :( INLINE COMMENTS sys/sys/callout_test.h:1 I'm not sure that the callout_test.h belong in sys. Seems like needless pollution. sys/sys/kern_testfrwk.h:1 Does this need to live in sys as well? REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, adrian, sbruno, lstewart, imp, hselasky Cc: jhb, kostikbel, emaste, delphij, neel, erj, freebsd-net ___ 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
[Differential] [Updated] D1711: Changes to the callout code to restore active semantics and also add a test-framework and test to validate thecallout code (and potentially for use by other tests).
imp added a comment. For the commit, I'd separate out the timeout fix from the kernel testframework. REVISION DETAIL https://reviews.freebsd.org/D1711 To: rrs, gnn, rwatson, adrian, sbruno, lstewart, hselasky, imp Cc: delphij, neel, erj, freebsd-net ___ 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: RFC: Enabling VIMAGE in GENERIC
On Nov 17, 2014, at 12:46 AM, Craig Rodrigues rodr...@freebsd.org wrote: Hi, PROPOSAL == I would like to get feedback on the following proposal. In the head branch (CURRENT), I would like to enable VIMAGE with this commit: PATCH == Index: sys/conf/NOTES === --- sys/conf/NOTES (revision 274300) +++ sys/conf/NOTES (working copy) @@ -784,8 +784,8 @@ device mn # Munich32x/Falc54 Nx64kbit/sec cards. # Network stack virtualization. -#options VIMAGE -#options VNET_DEBUG # debug for VIMAGE +optionsVIMAGE +optionsVNET_DEBUG # debug for VIMAGE # # Network interfaces: I would like to enable VIMAGE for the following reasons: REASONS (1) VIMAGE cannot be enabled off to the side in a separate library or kernel module. When enabled, it is a kernel ABI incompatible change. This has impact on 3rd party code such as the kernel modules which come with VirtualBox. So the time to do it in CURRENT is now, otherwise we can't consider doing it until FreeBSD-12 timeframe, which is quite a while away. (2) VIMAGE is used in some 3rd party products, such as FreeNAS. These 3rd party products are mostly happy with VIMAGE, but sometimes they encounter problems, and FreeBSD doesn't see these problems because it is disabled by default. (3) Most of the major subsystems like ipfw and pf have been fixed for VIMAGE, and the only way to shake out the last few issues is to make it the default and get feedback from the community. ipfilter still needs to be VIMAGE-ified. (4) Not everyone uses bhyve. FreeBSD jails are an excellent virtualization platform for FreeBSD. Jails are still very popular and performant. VIMAGE makes jails even better by allowing per-jail network stacks. (5) Olivier Cochard-Labbe has provided good network performance results in VIMAGE vs. non-VIMAGE kernels: https://lists.freebsd.org/pipermail/freebsd-net/2014-October/040091.html (6) Certain people like Vitaly wishmaster artem...@ukr.net have been running VIMAGE jails in a production environment for quite a while, and would like to see it be the default. ACTION PLAN === (1) Coordinate/communicate with portmgr, since this has kernel ABI implications (2) Work with clusteradm@, and try to get a test instance of one of the PF firewalls in the cluster working with a VIMAGE enabled kernel. (3) Take a pass through http://wiki.freebsd.org/VIMAGE/TODO and https://bugs.freebsd.org/bugzilla/buglist.cgi?quicksearch=vimage%20or%20vnet and try to clean things up. Get help from net@ developers to do this. And if these don’t get cleaned up? (4) Take a pass on trying to VIMAGE-ify ipfilter. I'll need help from the ipfilter maintainers for this and some net@ developers. And if this doesn’t happen? (5) Enable VIMAGE by default in CURRENT on January 5, 2015. This will *not* be enabled in STABLE. What do people think? How do you plan to address the problems seen by FreeNAS in #2 above? I don’t see that in the action plan. Without it, we’re enabling an option that has know, serious issue making 11 potentially a more unstable release. Warner signature.asc Description: Message signed with OpenPGP using GPGMail
Re: miibus0: mii_mediachg: can't handle non-zero PHY instance 31
On Apr 1, 2014, at 12:58 AM, Yonghyeon PYUN pyu...@gmail.com wrote: On Mon, Mar 31, 2014 at 07:57:28AM -0700, Chris H wrote: On Sun, Mar 30, 2014 at 01:12:20PM -0700, chr...@ultimatedns.net wrote: Greetings, I'm not sure whether this best belonged on net@, or stable@ so I'm using both. :) I'm testing both releng_9, and MB, and I encountered a new message I don't usually see using the nfe(4) driver: miibus0: mii_mediachg: can't handle non-zero PHY instance 1 ... miibus0: mii_mediachg: can't handle non-zero PHY instance 31 Truncated for brevity (31 lines in total; 1-31). I don't know how interpret this. An issue with my version of the driver, or the hardware itself? This occurred with both GENERIC, as well as my custom kernel. Would you show me the dmesg output? Happily: Calibrating TSC clock ... TSC clock: 3231132841 Hz CPU: AMD Sempron(tm) 140 Processor (3231.13-MHz K8-class CPU) Origin = AuthenticAMD Id = 0x100f62 Family = 0x10 Model = 0x6 Stepping = 2 Features=0x78bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2 Features2=0x802009SSE3,MON,CX16,POPCNT AMD Features=0xee500800SYSCALL,NX,MMX+,FFXSR,Page1GB,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x37fdLAHF,SVM,ExtAPIC,CR8,ABM,SSE4A,MAS,Prefetch,OSVW,IBS,SKINIT,WDT [...] nfe0: NVIDIA nForce MCP61 Networking Adapter port 0xe480-0xe487 mem 0xdff7d000-0xdff7dfff irq 20 at device 7.0 on pci0 nfe0: attempting to allocate 8 MSI vectors (8 supported) msi: routing MSI IRQ 257 to local APIC 0 vector 56 msi: routing MSI IRQ 258 to local APIC 0 vector 57 msi: routing MSI IRQ 259 to local APIC 0 vector 58 msi: routing MSI IRQ 260 to local APIC 0 vector 59 msi: routing MSI IRQ 261 to local APIC 0 vector 60 msi: routing MSI IRQ 262 to local APIC 0 vector 61 msi: routing MSI IRQ 263 to local APIC 0 vector 62 msi: routing MSI IRQ 264 to local APIC 0 vector 63 nfe0: using IRQs 257-264 for MSI nfe0: Using 8 MSI messages miibus0: MII bus on nfe0 rlphy0: RTL8201L 10/100 media interface PHY 0 on miibus0 rlphy0: OUI 0x04, model 0x0020, rev. 1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy1: RTL8201L 10/100 media interface PHY 1 on miibus0 rlphy1: OUI 0x04, model 0x0020, rev. 1 rlphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow [...] rlphy30: RTL8201L 10/100 media interface PHY 30 on miibus0 rlphy30: OUI 0x04, model 0x0020, rev. 1 rlphy30: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow rlphy31: RTL8201L 10/100 media interface PHY 31 on miibus0 rlphy31: OUI 0x04, model 0x0020, rev. 1 rlphy31: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow nfe0: bpf attached nfe0: Ethernet address: 40:61:86:cd:44:97 mii(4) thinks it has 32 PHYs and this is the reason why mii(4) complains. Due to unknown reason, accessing PHY registers in device probe stage got valid response which in turn makes the driver think there are 32 PHYs. Did you ever see this this kind of message on old FreeBSD release? Or could you try cold-boot and see whether it makes any difference? I’ve seen this a few times when the resources were AFU on CardBus cards.. But never this coherently… I’ve also seen it during early bring up when I got the MII address wrong, but you should be well past that with the rl driver :) The voices in Bill Paul’s head from that are almost old enough to collect retirement... 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: IFNAMSIZ/IF_NAMESIZE change proposal
On Sep 14, 2013, at 2:44 AM, Anuranjan Shukla wrote: At Juniper Networks, interface name size was needed to be longer than what FreeBSD has. We're trying to reduce our local changes to FreeBSD to allow us an easier time upgrading to newer FreeBSD releases, and support the modularization of the network stack we'd proposed earlier. I'm sending this out to propose changing IFNAMSIZ from 16 to 60 (this is the size we use) in FreeBSD. We don't see any downside (other than increasing the ifreq structure size for one) to doing this, as allowing longer interface names can be handy for vendors. I'd like to hear if there's a strong objection to this. If not, we'd like to get this into to the FreeBSD codebase. Any thoughts/objections highly appreciated. 56 or 64 would be better for alignment, wouldn't it? 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: mbuf autotuning effect
On Sep 6, 2013, at 7:11 PM, Adrian Chadd wrote: Yeah, why is VM_KMEM_SIZE only 12mbyte for MIPS? That's a little low for a platform that has a direct map that's slightly larger than 12mb :) Warner? Juli? All architectures have it at 12MB, except sparc64 where it is 16MB. This can be changed with the options VM_KMEM_SIZE=x in the config file. So my guess as to why this is the case: cut and paste worked, so nobody changed it after that. # Still need to reads hiren's email to comprehend it... Warner -adrian On 6 September 2013 16:36, hiren panchasara hiren.panchas...@gmail.comwrote: We are seeing an interesting thing on a mips board with 32MB ram. We run out of mbuf very easily and looking at numbers it seems we are only getting 6mb of maxmbufmem. # sysctl -a | grep hw | grep mem hw.physmem: 33554432 hw.usermem: 21774336 hw.realmem: 33554432 # # sysctl -a | grep maxmbuf kern.ipc.maxmbufmem: 6291456 I believe that number is very low for a board with 32mb of ram. Looking at the code: sys/kern/kern_mbuf.c : tunable_mbinit() 124 realmem = qmin((quad_t)physmem * PAGE_SIZE, vm_kmem_size); 125 maxmbufmem = realmem / 2; 126 TUNABLE_QUAD_FETCH(kern.ipc.maxmbufmem, maxmbufmem); 127 if (maxmbufmem realmem / 4 * 3) 128 maxmbufmem = realmem / 4 * 3; So, realmem plays important role in determining maxmbufmem. physmem = 32mb PAGE_SIZE = 4096 vm_kmem_size is calculated inside sys/kern/kern_malloc.c : kmeminit() 705 vm_kmem_size = VM_KMEM_SIZE + nmbclusters * PAGE_SIZE; 706 mem_size = cnt.v_page_count; 707 708 #if defined(VM_KMEM_SIZE_SCALE) 709 vm_kmem_size_scale = VM_KMEM_SIZE_SCALE; 710 #endif 711 TUNABLE_INT_FETCH(vm.kmem_size_scale, vm_kmem_size_scale); 712 if (vm_kmem_size_scale 0 713 (mem_size / vm_kmem_size_scale) (vm_kmem_size / PAGE_SIZE)) 714 vm_kmem_size = (mem_size / vm_kmem_size_scale) * PAGE_SIZE; here, VM_KMEM_SIZE = 12*1024*1024 nmbclusters = 0 (initially) PAGE_SIZE = 4096 # sysctl -a | grep v_page_count vm.stats.vm.v_page_count: 7035 and VM_KMEM_SIZE_SCALE = 3 for mips. So, vm_kmem_size = 12mb. Going back to tunable_mbinit(), we get realmem = 12mb. and masmbufmem = 6mb. Wanted to see if I am following the code correctly and how autotuning should work here. cheers, Hiren ___ 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 ___ freebsd-m...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-mips To unsubscribe, send any mail to freebsd-mips-unsubscr...@freebsd.org ___ 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: [net] protecting interfaces from races between control and data ?
On Aug 5, 2013, at 11:20 AM, Adrian Chadd wrote: .. and I bet it's not a design pattern, and this is total conjecture on my part: * the original drivers weren't SMP safe; * noone really sat down and figured out how to correctly synchronise all of this stuff; * people did the minimum amount of work to keep the driver from immediately crashing, but didn't really think things through at a larger scale. Almost every driver is this way Luigi. :-) Most of the drivers in the three don't support hardware that performs well enough for this to be a problem. :) Any driver that's still around from the pre-locking days can easily saturate the lines (or the hardware) on today's (and even yesterday's hardware). All the rest have come up with different ways to cope... 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: Replace bcopy() to update ether_addr
On Aug 22, 2012, at 6:02 AM, John Baldwin wrote: On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: Hi, What about just creating an ETHER_ADDR_COPY(dst, src) and putting that in a relevant include file, then hide the ugliness there? The same benefits will likely appear when copying wifi MAC addresses to/from headers. Thanks, I'm glad someone noticed this. I doubt we even _need_ the ugliness. We should just use *dst = *src unless there is a compelling reason not to. Agreed. We should do that, and then check the generated code to be sure there isn't a compelling reason 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: Replace bcopy() to update ether_addr
On Aug 22, 2012, at 12:54 PM, Adrian Chadd wrote: On 22 August 2012 05:02, John Baldwin j...@freebsd.org wrote: On Tuesday, August 21, 2012 12:34:42 pm Adrian Chadd wrote: Hi, What about just creating an ETHER_ADDR_COPY(dst, src) and putting that in a relevant include file, then hide the ugliness there? The same benefits will likely appear when copying wifi MAC addresses to/from headers. Thanks, I'm glad someone noticed this. I doubt we even _need_ the ugliness. We should just use *dst = *src unless there is a compelling reason not to. Because it's not very clear? :-) I'd much prefer my array-of-things copies to be explicit. But it isn't an array of things. It is a structure.a Also, the optimisation and compiler silliness may not be THAT obvious on intel (except when you're luigi and using netmap) but I can't help but wonder whether the same does hold for MIPS/ARM. Getting it wrong there will lead to some very very poor performing code. Which is why we need to check that output to make sure it isn't too horrible. 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: Replace bcopy() to update ether_addr
On Aug 21, 2012, at 5:26 AM, Marius Strobl wrote: On Mon, Aug 20, 2012 at 01:20:29PM -0600, Warner Losh wrote: On Aug 20, 2012, at 1:17 PM, Wojciech Puchar wrote: or use ++. i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. should is the most important word in Your post. what it actually do - i don't know. If we are requiring this to be __aligned(2), we should tag it as such to enforce this. Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... While the __aligned(2) approach certainly works, I've actually rather mixed experiences on x86 with it as the compiler doesn't necessarily produce the small and efficient one would expect from code it. Such a change certainly shouldn't be done just on the assumption that the compiler has all hints required to produce good code from it but the resulting asm should be verified across all affected architectures. Very true... I would have thought that went without saying... 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: Replace bcopy() to update ether_addr
On Aug 21, 2012, at 1:42 AM, Wojciech Puchar wrote: Even without this tagging, the code to do a structure level copy of 6 bytes is going to be tiny... true. just to make sure it will be absolutely portable how about bcopymacaddress(dst,src) and then define it whatever you find it fastest on any architecture? How about just changing it to the *dst = *src, compiling it on all architectures and then deciding if the improvement of the code from a hand-tweaked thing is worth that uglification? 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: Replace bcopy() to update ether_addr
On Aug 20, 2012, at 8:46 AM, Mitya wrote:
Hi.
I found some overhead code in /src/sys/net/if_ethersubr.c and
/src/sys/netgraph/ng_ether.c
It contains strings, like bcopy(src, dst, ETHER_ADDR_LEN);
When src and dst are struct ether_addr*, and ETHER_ADDR_LEN equal 6.
This code call every time, when we send Ethernet packet.
On example, on my machine in invoked nearly 20K per second.
Why we are use bcopy(), to copy only 6 bytes?
Answer - in some architectures we are can not directly copy unaligned data.
True for shorts, longs, etc. But why do we need it for ether_addr? It is a
struct that's just an array... That's always safe.
I propose this solution.
In file /usr/src/include/net/ethernet.h add this lines:
static inline void ether_addr_copy(ether_addr* src, ether_addr* dst) {
#if defined(__i386__) || defined(__amd64__)
Bleck. that's uber ugly. We have a define for unaligned vs aligned
architectures. we should use that here. If we even need this ifdef at all.
Warner
*dst = *src;
#else
bcopy(src, dst, ETHER_ADDR_LEN);
#endif
}
On platform i386 gcc produce like this code:
leal-30(%ebp), %eax
leal6(%eax), %ecx
leal-44(%ebp), %edx
movl(%edx), %eax
movl%eax, (%ecx)
movzwl 4(%edx), %eax
movw%ax, 4(%ecx)
And clang produce this:
movl-48(%ebp), %ecx
movl%ecx, -26(%ebp)
movw-44(%ebp), %si
movw%si, -22(%ebp)
All this variants are much faster, than bcopy()
___
freebsd-hack...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
___
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: Replace bcopy() to update ether_addr
On Aug 20, 2012, at 10:48 AM, Wojciech Puchar wrote: #if defined(__i386__) || defined(__amd64__) *dst = *src; #else bcopy(src, dst, ETHER_ADDR_LEN); #else short *tmp1=((*short)src),*tmp2=((*short)dst); *tmp2=*tmp1; *(tmp2+1)=*(tmp1+1); *(tmp2+2)=*(tmp1+2); or use ++. i think it is always aligned to 2 bytes and this should produce usable code on any CPU? should be 6 instructions on MIPS and PPC IMHO. We should tag it as __aligned(2) then, no? If so, then the compiler should generate the code you posted. 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: 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: bounty / work for hire for PR 115623 ... xircom, pcmcia, etc.
I'd say this PR is off the mark. I use PC Card and CardBus cards all the time. The Xircom patch in question should be in -current already. I likely haven't MFC'd it. There are two classes of problems lingering from the old days: the Xircom one (where a certain type of CIS fails, but so far one Xircom card is the only one that has it). The second is the inability to find what resources the Host Bridge decodes, so you need to hack it with the memory ranges manually. John Baldwin recently committed a fix for newer ACPIs that would solve this, if only older ACPIs implemented it... Part of the problem here is that my primary laptop no longer is CardBus based, so problems linger longer than I like to see... All my fast laptops have died, and I'm stuck with ancient, slow ones with dying batteries that work poorly these days... 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: move setfib(1)
In message: 4bfe04e5.1010...@semmy.ru Sergey Matveychuk s...@semmy.ru writes: : 26.05.2010 20:38, Julian Elischer wrote: : On 5/26/10 9:32 AM, M. Warner Losh wrote: : In message:4bfd158d.7020...@freebsd.org : Sergey Matveychuks...@freebsd.org writes: : : Does is possible to move setfib(1) to /sbin for smooth using it in : : rc.d scripts? : : Can you tell us why you need it so early? : : We could do it, but eventually everything ends up moving to /sbin or : /bin unless we need a good reason. : : : I'm thinking about this after Doug's message: : http://lists.freebsd.org/pipermail/freebsd-rc/2010-May/001954.html Right, and the only way that /usr/bin isn't going to be available if the network isn't up will be if you have NFS mounted root, but have a separate /usr partition. Otherwise, critmount happens before the network comes up, and that will ensure that you'll have /usr available at the point in the boot scripts you want to use it. Even if you have / and /usr separate on NFS partitions, you can specify netfs_types= in the NFS root's rc.conf and all NFS mounts will mount too very early. Since you are proposing this for /etc/rc.d/routing, I think you can actually use it there and there will be no problem, even for whacked out NFS setups. Did I miss something? Warner P.S. On my system at least: rcorder says: /etc/rc.d/dumpon /etc/rc.d/ddb /etc/rc.d/initrandom /etc/rc.d/geli /etc/rc.d/gbde /etc/rc.d/encswap /etc/rc.d/ccd /etc/rc.d/swap1 /etc/rc.d/fsck /etc/rc.d/root /etc/rc.d/hostid /etc/rc.d/mdconfig /etc/rc.d/mountcritlocal so these wuold be the only places where you can't use binaries from /usr, right? ___ 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: move setfib(1)
In message: 20100527.001534.807935107107604070@bsdimp.com M. Warner Losh i...@bsdimp.com writes: : at the point in the boot scripts you want to use it. Even if you have : / and /usr separate on NFS partitions, you can specify netfs_types= : in the NFS root's rc.conf and all NFS mounts will mount too very : early. s/will mount too very early/will mount early as well/g Sorry. 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: move setfib(1)
In message: 4bfd158d.7020...@freebsd.org Sergey Matveychuk s...@freebsd.org writes: : Does is possible to move setfib(1) to /sbin for smooth using it in : rc.d scripts? It is small enough. I think that's a good idea. However, it would only be a problem if we are mounting / and /usr off NFS as separate partitions, right? 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
Small patch to ipfilter for arm
OK. I'd like to propose the following patch for ipfilter: Index: sys/contrib/ipfilter/netinet/ip_compat.h === --- sys/contrib/ipfilter/netinet/ip_compat.h(revision 205838) +++ sys/contrib/ipfilter/netinet/ip_compat.h(working copy) @@ -975,7 +975,6 @@ # define SPL_NET(x) ; # define SPL_IMP(x) ; # define SPL_SCHED(x); -extern int in_cksum __P((struct mbuf *, int)); # else # define SPL_SCHED(x)x = splhigh() # endif /* __FreeBSD_version = 500043 */ This declaration is wrong, and it prevents arm from building ipfilter. Why is it wrong? Because we have: # if (__FreeBSD_version = 52) # include netinet/in_systm.h # include netinet/ip.h # include machine/in_cksum.h # endif # if (__FreeBSD_version = 500043) ... the above code ... # endif So, we have in_cksum.h being included *AND* we're defining this function. However, in_cksum.h is supposed to do this. Why don't we see problems today? No architecture except arm has an assembler in_cksum in the tree. All the other architectures have #define in_cksum(a, b) in_cksum_skip(a, b, 0) in their headers. Since the above extern uses __P to hide the args, in_cksum doesn't expand the macro, so we don't see any problems or conflicts. On arm, where we define in_cksum() correctly to return u_short, there's a conflict. So, it would best if we just dropped this one line from ip_compat.h, since it was always wrong anyway. Comments? 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: struct sockaddr * and alignment
In message: b649e5e1002100148r759f3aacr3d5fcdfb5efd9...@mail.gmail.com
Marius Nünnerich mar...@nuenneri.ch writes:
: On Tue, Feb 9, 2010 at 18:34, M. Warner Losh i...@bsdimp.com wrote:
: Greetings,
:
: I've found a few inconsistencies in the sockaddr stuff in the tree.
: I'm not sure where to go to get a definitive answer, so I thought I'd
: start here.
:
: I got here looking at the recent wake breakage on mips. It turns out
: that the warning was:
:
: src/usr.sbin/wake/wake.c: In function 'find_ether':
: src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment of
target type
:
: which comes from
: sdl = (struct sockaddr_dl *)ifa-ifa_addr;
:
: The problem is that on MIPS struct sockaddr * is byte aligned and
: sockaddr_dl * is word aligned, so the compiler is rightly telling us
: that there might be a problem here.
:
: However, further digging shows that there will never be a problem
: here with alignment. struct sockaddr_storage has a int64 in it to
: force it to be __aligned(8). So I thought to myself why don't I just
: add __aligned(8) to the struct sockaddr definition? After all, the
: kernel goes to great lengths to return data so aligned, and user code
: also keeps things aligned.
:
: Sure enough, that fixes this warning. Yea. But, sadly, it causes
: other problems. If you look at sbin/atm/atmconfig/natm.c you'll see
: code like:
:
: static void
: store_route(struct rt_msghdr *rtm)
: {
: ...
: char *cp
: struct sockaddr *sa;
: ...
:
: cp = (char *)(rtm + 1);
: ...
: sa = (struct sockaddr *)cp;
: cp += roundup(sa-sa_len, sizeof(long));
: ...
:
: which breaks because we're now casting from an __aligned(1) char * to
: an __aligned(8) sockaddr *.
:
: And it is only rounding the size of the structure to long, rather than
: int64 like sockaddr_storage suggests is the proper alignment. But I
: haven't looked in the kernel to see if there's an issue there with
: routing sockets or not.
:
: The other extreme is to put __aligned(1) on all the sockaddr_foo
: structures. This would solve the compiler warning, but would have a
: negative effect on performance in accessing these elements (because
: the compiler would have to generate calls to bcopy or equivalent to
: access the scalar members that are larger than a byte). This cure
: would be worse than the disease.
:
: So the question here is What is the right solution here? It has me
: stumped. So I dropped WARNS level down from 6 to 3 for wake.c.
:
: Hi Warner,
:
: I got into the same kind of trouble when I tried to raise the WARNS
: level above 3 for inetd and others. I guess everything which uses some
: sockaddr casting or (in the case of inetd) some of these macros:
: http://fxr.googlebit.com/source/sys/netinet6/in6.h?v=8-CURRENT#L233
:
: It's a pity that only this keeps some programs from going to a WARNS level of
6.
Well, if there were some way to tell the compiler Yes, I know this is
right then we'd be set. But I've not found what that way might be.
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
struct sockaddr * and alignment
Greetings,
I've found a few inconsistencies in the sockaddr stuff in the tree.
I'm not sure where to go to get a definitive answer, so I thought I'd
start here.
I got here looking at the recent wake breakage on mips. It turns out
that the warning was:
src/usr.sbin/wake/wake.c: In function 'find_ether':
src/usr.sbin/wake/wake.c:123: warning: cast increases required alignment of
target type
which comes from
sdl = (struct sockaddr_dl *)ifa-ifa_addr;
The problem is that on MIPS struct sockaddr * is byte aligned and
sockaddr_dl * is word aligned, so the compiler is rightly telling us
that there might be a problem here.
However, further digging shows that there will never be a problem
here with alignment. struct sockaddr_storage has a int64 in it to
force it to be __aligned(8). So I thought to myself why don't I just
add __aligned(8) to the struct sockaddr definition? After all, the
kernel goes to great lengths to return data so aligned, and user code
also keeps things aligned.
Sure enough, that fixes this warning. Yea. But, sadly, it causes
other problems. If you look at sbin/atm/atmconfig/natm.c you'll see
code like:
static void
store_route(struct rt_msghdr *rtm)
{
...
char *cp
struct sockaddr *sa;
...
cp = (char *)(rtm + 1);
...
sa = (struct sockaddr *)cp;
cp += roundup(sa-sa_len, sizeof(long));
...
which breaks because we're now casting from an __aligned(1) char * to
an __aligned(8) sockaddr *.
And it is only rounding the size of the structure to long, rather than
int64 like sockaddr_storage suggests is the proper alignment. But I
haven't looked in the kernel to see if there's an issue there with
routing sockets or not.
The other extreme is to put __aligned(1) on all the sockaddr_foo
structures. This would solve the compiler warning, but would have a
negative effect on performance in accessing these elements (because
the compiler would have to generate calls to bcopy or equivalent to
access the scalar members that are larger than a byte). This cure
would be worse than the disease.
So the question here is What is the right solution here? It has me
stumped. So I dropped WARNS level down from 6 to 3 for wake.c.
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
How does rpc.lockd know where to send a request
I have a problem. All systems are running freebsd-current form sometime in the last month, although similar systems running 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS client is doing something that baffles my mind entirely, maybe you can help. Please bear with me, this is a little complicated, but I wanted to include all the details. I have a host, let's call it dune. dune is at 10.0.0.5. dune is also the master for the carp interface 10.0.0.99. It is running rpc.lockd and is an nfs server. I've told nfs, rpcbind, lockd and statd to only listen on address 10.0.0.99. I have a second host. maud-dib is 10.0.0.8. I do mount 10.0.0.99:/dune /dune on maud-dib. Wireshark shows all the traffic going to 10.0.0.99. All is happy in the world. When I start, there's no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. Until I do the following 'lockf /dune/imp/junk ls' (I have write perms to /dune/imp). At this point, rpc.lockd hangs. I get the message 10.0.0.99:/dune: lockd not responding which seems odd. lockd is really there. However, wireshark shows the NLM traffic going to IP address 10.0.0.5. maud-dib has no carp interfaces. That's odd. So my question is 'how does lockd know where to go to talk the NLM protocol?' I did a packet capture from before I did the mount on maud-dib. I can see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to 10.0.0.5. This gets an ICMP port unreachable message, since I told nfs, et al, to bind only to 10.0.0.99. So, I thought, 'the answer is obvious, I'll just look for the packet that has the string 'dune' in it (which is the hostname of 10.0.0.5). No packets have that string in it, other than the mount packet which has /dune in it. Nor is there any DNS activity doing a lookup. Nor is there any static mapping in /etc/hosts on 10.0.0.8. Next thought: Oh, somebody like portmapper or the NFS protocol from 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do locking requests to 10.0.0.5. That's trivial to find, I think to myself. I'll look for the octets 0a 00 00 05 (hex). The only instances of that are in the ARP packet, the NLM request and the ICMP unreachable packets. No other packets includes these bytes. Nor do any include the reverse. Right after the mount, there's nothing in the connection table that points to 10.0.0.5, only 10.0.0.99. So I'm having a serious WTF moment. How the heck is this even possible. Any ideas on where to look for where this gets set and/or communicated? thanks a bunch for any insight that you can give... 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: How does rpc.lockd know where to send a request
In message: 4b6e2b40.1070...@elischer.org Julian Elischer jul...@elischer.org writes: : M. Warner Losh wrote: : I have a problem. All systems are running freebsd-current form : sometime in the last month, although similar systems running : 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : client is doing something that baffles my mind entirely, maybe you can : help. Please bear with me, this is a little complicated, but I wanted : to include all the details. : I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : the master for the carp interface 10.0.0.99. It is running rpc.lockd : and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : listen on address 10.0.0.99. : I have a second host. maud-dib is 10.0.0.8. I do mount : 10.0.0.99:/dune /dune on maud-dib. Wireshark shows all the traffic : going to 10.0.0.99. All is happy in the world. When I start, there's : no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : to /dune/imp). At this point, rpc.lockd hangs. I get the message : 10.0.0.99:/dune: lockd not responding which seems odd. lockd is : really there. However, wireshark shows the NLM traffic going to IP : address 10.0.0.5. maud-dib has no carp interfaces. : That's odd. So my question is 'how does lockd know where to go to : talk the NLM protocol?' : : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. But wouldn't the response from 10.0.0.5 mean I could search for the hex string and see 0a05 in the packet header? : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. No, dune's daemon is sitting on 10.0.0.99. : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Normally, I'd believe you. But since there's nothing listening on the * address, and also nothing listening on the 10.0.0.5 address, I'm less sure. After looking at the wireshark dump, I don't see any 10.0.0.5 packets until the ARP for it near the end of the trace. http://people.freebsd.org/~imp/wireshark.dat if you are interested. This is a good theory, and I'll have to look into it deeper. Warner : I did a packet capture from before I did the mount on maud-dib. I can : see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : 10.0.0.5. This gets an ICMP port unreachable message, since I told : nfs, et al, to bind only to 10.0.0.99. : So, I thought, 'the answer is obvious, I'll just look for the packet : that has the string 'dune' in it (which is the hostname of 10.0.0.5). : No packets have that string in it, other than the mount packet which : has /dune in it. Nor is there any DNS activity doing a lookup. Nor : is there any static mapping in /etc/hosts on 10.0.0.8. : Next thought: Oh, somebody like portmapper or the NFS protocol from : 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : locking requests to 10.0.0.5. That's trivial to find, I think to : myself. I'll look for the octets 0a 00 00 05 (hex). The only : instances of that are in the ARP packet, the NLM request and the ICMP : unreachable packets. No other packets includes these bytes. Nor do : any include the reverse. : Right after the mount, there's nothing in the connection table that : points to 10.0.0.5, only 10.0.0.99. : So I'm having a serious WTF moment. How the heck is this even : possible. Any ideas on where to look for where this gets set and/or : communicated? : thanks a bunch for any insight that you can give... : 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 : : ___ 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: How does rpc.lockd know where to send a request
In message: 4b6e2b40.1070...@elischer.org Julian Elischer jul...@elischer.org writes: : M. Warner Losh wrote: : I have a problem. All systems are running freebsd-current form : sometime in the last month, although similar systems running : 8.0-RELEASE exhibit exactly the same problem. rpc.lockd on an NFS : client is doing something that baffles my mind entirely, maybe you can : help. Please bear with me, this is a little complicated, but I wanted : to include all the details. : I have a host, let's call it dune. dune is at 10.0.0.5. dune is also : the master for the carp interface 10.0.0.99. It is running rpc.lockd : and is an nfs server. I've told nfs, rpcbind, lockd and statd to only : listen on address 10.0.0.99. : I have a second host. maud-dib is 10.0.0.8. I do mount : 10.0.0.99:/dune /dune on maud-dib. Wireshark shows all the traffic : going to 10.0.0.99. All is happy in the world. When I start, there's : no ARP entry for 10.0.0.5 on 10.0.0.8, nor is there after the mount. : Until I do the following 'lockf /dune/imp/junk ls' (I have write perms : to /dune/imp). At this point, rpc.lockd hangs. I get the message : 10.0.0.99:/dune: lockd not responding which seems odd. lockd is : really there. However, wireshark shows the NLM traffic going to IP : address 10.0.0.5. maud-dib has no carp interfaces. : That's odd. So my question is 'how does lockd know where to go to : talk the NLM protocol?' : : : my recollection is that maud-dib will sent an initial packet to dune : and dune will respond but that the response may come from 10.0.0.5, : after which maud-dib will redirect all requests there, which will not : work because dune is not listenning there. : : teh problem is that dune's daemon is setting a local address of : IPADDR_ANY (0.0.0.0) which tells the packets to use a from : address that is the address ofthe interface that they exit from. : : Since 10.0.0.5 is the primary address on that interface, that gets : selected. : you may try some trickery where you add the .5 address AFTER the .99 : address so that the .99 is the primary address. Actually, it looks like this is getting returned, as a ASCII string '10.0.0.5' in frame 68 in response to the GETADDR call. Since I've told it specifically '-h 10.0.0.99' I'd have thought it would respect that. Since it is supposed to be bound to 10.0.0.99, I'd proffer the argument this is a bug in rpcbind's implementation of GETADDR. I never would have thought it would have been returned as an ASCII string, but you live and learn, eh? Now, on to fixing the bug. Warner P.S. http://people.freebsd.org/~imp/wireshark.dat has the trace I'm referring to (and I've posted it in another message on this thread). : I did a packet capture from before I did the mount on maud-dib. I can : see the NFS mount, the NFS traffic, all to 10.0.0.99. I then see an : ARP for 10.0.0.5, followed by the NLM request from 10.0.0.8 to : 10.0.0.5. This gets an ICMP port unreachable message, since I told : nfs, et al, to bind only to 10.0.0.99. : So, I thought, 'the answer is obvious, I'll just look for the packet : that has the string 'dune' in it (which is the hostname of 10.0.0.5). : No packets have that string in it, other than the mount packet which : has /dune in it. Nor is there any DNS activity doing a lookup. Nor : is there any static mapping in /etc/hosts on 10.0.0.8. : Next thought: Oh, somebody like portmapper or the NFS protocol from : 10.0.0.99 is telling 10.0.0.8's rpc.lockd (or something else) to do : locking requests to 10.0.0.5. That's trivial to find, I think to : myself. I'll look for the octets 0a 00 00 05 (hex). The only : instances of that are in the ARP packet, the NLM request and the ICMP : unreachable packets. No other packets includes these bytes. Nor do : any include the reverse. : Right after the mount, there's nothing in the connection table that : points to 10.0.0.5, only 10.0.0.99. : So I'm having a serious WTF moment. How the heck is this even : possible. Any ideas on where to look for where this gets set and/or : communicated? : thanks a bunch for any insight that you can give... : 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 : : ___ 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: [ed] link state constantly going down and up
In message: 261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com Miki miki@gmail.com writes: : 2009/4/29 M. Warner Losh i...@bsdimp.com : : : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : : the link state is constantly going down and up : : : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN : : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP : ... : : the problem appear with the following commit : : : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) : : I do not see any link state change if I revert the commit. : : Doh! : : I needed to force auto negotiation for other cards to work. Let me : see if I can dig up the DFE-670TXD and go from there... Are you also : seeing really horrible network performance as well? Do you see this : only under load, or just at idle? : : Warner : : : Yes network performance suffers from this. The problem only appears under : load : but not when idle. Thanks. I'll try to reproduce it here. I noticed this on one of the cards, but had trouble reproducing it, but I'll try harder. 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: [ed] link state constantly going down and up
In message: 261c29700904300029s6757d39ei86fbf69ef816f...@mail.gmail.com Miki miki@gmail.com writes: : 2009/4/30 M. Warner Losh i...@bsdimp.com : : In message: 261c2970090434k4bc02635m2729a0a54c09c...@mail.gmail.com : Miki miki@gmail.com writes: : : 2009/4/29 M. Warner Losh i...@bsdimp.com : : : : : I have a problem with a D-Link DFE-670TXD which is handled by if_ed : : : : the link state is constantly going down and up : : : : Apr 28 14:21:33 iut-mir-o kernel: ed0: link state changed to DOWN : : : Apr 28 14:21:35 iut-mir-o kernel: ed0: link state changed to UP : : ... : : : the problem appear with the following commit : : : : SVN rev 190643 on 2009-04-02 16:58:45Z by imp (CVS rev 1.126) : : : I do not see any link state change if I revert the commit. : : : : Doh! : : : : I needed to force auto negotiation for other cards to work. Let me : : see if I can dig up the DFE-670TXD and go from there... Are you also : : seeing really horrible network performance as well? Do you see this : : only under load, or just at idle? : : : : Warner : : : : : : Yes network performance suffers from this. The problem only appears under : : load : : but not when idle. : : Thanks. I'll try to reproduce it here. I noticed this on one of the : cards, but had trouble reproducing it, but I'll try harder. : : Warner : : : I can easily reproduce this by downloading an ISO image via ftp : and doing a checkout of a subversion repository OK. I'll try that. Do you know if you are able to trigger it with ttcp too? That's where I saw the odd symptoms before... 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
Small change to ukphy
I've encountered a number of PHY chips that need auto negotiation
kicked off to come out of ISO state. This makes sense, because the
ukphy driver never seems to take the PHY out of isolation state
otherwise.
Index: ukphy.c
===
--- ukphy.c (revision 190463)
+++ ukphy.c (working copy)
@@ -146,6 +146,7 @@
sc-mii_phy = ma-mii_phyno;
sc-mii_service = ukphy_service;
sc-mii_pdata = mii;
+ sc-mii_flags |= MIIF_FORCEANEG;
mii-mii_instance++;
This forces auto negotiation. The reason for this is that it takes it
out of ISO state (Isolate). Once out of that state, things work
well. The question I have is will we properly go back into ISO state
for PHYs that should be isolated.
NetBSD has many of its NIC drivers setting this flag. Their APIs
allow them to set this directly at mii attach time. Ours don't, so
none of our drivers set this flag.
The other fix for this might be:
Index: mii_physubr.c
===
--- mii_physubr.c (revision 190463)
+++ mii_physubr.c (working copy)
@@ -113,7 +113,9 @@
int bmcr, anar, gtcr;
if (IFM_SUBTYPE(ife-ifm_media) == IFM_AUTO) {
- if ((PHY_READ(sc, MII_BMCR) BMCR_AUTOEN) == 0 ||
+ bmcr = PHY_READ(sc, MII_BMCR);
+ if ((bmcr BMCR_AUTOEN) == 0 ||
+ (bmcr BMCR_ISO) ||
(sc-mii_flags MIIF_FORCEANEG))
(void) mii_phy_auto(sc);
return;
Which says that if auto negotiation is enabled, and ISO is set to go
ahead and kick off an auto negotiation. I'm less sure of this path,
but it is an alternative. Otherwise, we never write to the BMCR to
take the device out of isolation. If there's a better place to do
this, then I'm all ears.
Either one of these hacks make several PC Cards that I have start to
work... In fact, I'm starting to approach 100% (up from 50%) of my
ed-based PC Cards working with this simple change (and others to the
ed driver). I know that these cards are a little behind the leading
edge, but I'd like to get them working since I've put a few hours into
investigating things here.
Comments?
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: Small change to ukphy
In message: 20090401100939.gb12...@michelle.cdnetworks.co.kr
Pyun YongHyeon pyu...@gmail.com writes:
: On Wed, Apr 01, 2009 at 01:32:46AM -0600, M. Warner Losh wrote:
: I've encountered a number of PHY chips that need auto negotiation
: kicked off to come out of ISO state. This makes sense, because the
: ukphy driver never seems to take the PHY out of isolation state
: otherwise.
:
: Index: ukphy.c
: ===
: --- ukphy.c (revision 190463)
: +++ ukphy.c (working copy)
: @@ -146,6 +146,7 @@
: sc-mii_phy = ma-mii_phyno;
: sc-mii_service = ukphy_service;
: sc-mii_pdata = mii;
: + sc-mii_flags |= MIIF_FORCEANEG;
:
: mii-mii_instance++;
:
:
: This forces auto negotiation. The reason for this is that it takes it
: out of ISO state (Isolate). Once out of that state, things work
:
: If the purpose is to take PHY out of isolated state couldn't this
: be handled in ifm_change_cb_t handler of parent interface? I guess
: the callback can reset the PHY and subsequent mii_mediachg() call
: may start auto-negotiation.
This callback isn't called. The problem is that the PHY is in ISO
state. Since it is in ISO state with auto negotiation enabled, we
never kick off an explicit auto negotiation, so the state never
changes so we never get this callback...
: well. The question I have is will we properly go back into ISO state
: for PHYs that should be isolated.
:
:
: If the PHY requires special handing for ISO state in reset it may
: need separated PHY driver as ukphy(4) does not set MIIF_NOISOLATE.
: As you said it would be really great if we have a generic way to
: pass various MII flags or driver specific information to mii(4).
This seems to be a common quirk. I'd hate to have a driver that's
just ukphy but with the one line added above and play what-a-mole with
all the odd-balls that are out there. Doesn't seem like a strategy
that will win the day.
I think we have a way to do this... I could do the following in my
attach routine:
mii = device_get_softc(sc-miibus);
LIST_FOREACH(miisc, mii-mii_phys, mii_list) {
miisc-mii_flags |= MIIF_FORCEANEG;
mii_phy_reset(miisc);
}
mii_mediachg(mii);
which is similar to what fxp does in its change routine (it is what I
put in my status change routine). Also MIIF_NOISOLATE works as well.
Is the above too insane?
Warner
: NetBSD has many of its NIC drivers setting this flag. Their APIs
: allow them to set this directly at mii attach time. Ours don't, so
: none of our drivers set this flag.
:
: The other fix for this might be:
: Index: mii_physubr.c
: ===
: --- mii_physubr.c (revision 190463)
: +++ mii_physubr.c (working copy)
: @@ -113,7 +113,9 @@
: int bmcr, anar, gtcr;
:
: if (IFM_SUBTYPE(ife-ifm_media) == IFM_AUTO) {
: - if ((PHY_READ(sc, MII_BMCR) BMCR_AUTOEN) == 0 ||
: + bmcr = PHY_READ(sc, MII_BMCR);
: + if ((bmcr BMCR_AUTOEN) == 0 ||
: + (bmcr BMCR_ISO) ||
: (sc-mii_flags MIIF_FORCEANEG))
: (void) mii_phy_auto(sc);
: return;
:
: Which says that if auto negotiation is enabled, and ISO is set to go
: ahead and kick off an auto negotiation. I'm less sure of this path,
: but it is an alternative. Otherwise, we never write to the BMCR to
: take the device out of isolation. If there's a better place to do
: this, then I'm all ears.
:
: Either one of these hacks make several PC Cards that I have start to
: work... In fact, I'm starting to approach 100% (up from 50%) of my
: ed-based PC Cards working with this simple change (and others to the
: ed driver). I know that these cards are a little behind the leading
: edge, but I'd like to get them working since I've put a few hours into
: investigating things here.
:
: Comments?
:
: 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: HEADS UP: vimage - virtualized global variables in the network stack
From: Max Laier m...@love2party.net Subject: Re: HEADS UP: vimage - virtualized global variables in the network stack Date: Sat, 13 Dec 2008 20:45:16 +0100 On Saturday 13 December 2008 20:33:53 Bjoern A. Zeeb wrote: ... This state of having the variables in parallel, global and in the container struct, will be maintained for another (short) time until the entire virtualization framework is in. This is needed, so that all three possible states can be benchmarked from exactly the same code changeset. For developers comitting new code or changing code it is important to properly add virtualized variables in the way that: 1) the globals and externs (if needed) are added/kept in sync as both a) globals under #ifdef VIMAGE_GLOBALS and b) to the appropriate container struct + the V_ macro. When used somewhere in code one has to use the V_foobarbaz version. Is there (an easy) way to have the tinderbox build every other run without VIMAGE_GLOBALS so that the most obvious error (global available, but not in the container struct - or the other way around) can be warned about? This actually points out why the 'tinderbox' name is bogus for the universe plus failure: universe builds all the kernels. Tinderbox builds LINT only. 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: Code review
In message: [EMAIL PROTECTED] John Baldwin [EMAIL PROTECTED] writes: : On Monday 25 August 2008 02:23:16 am M. Warner Losh wrote: : I did this a few years ago when trying to track down a problem with : some realtek network chips that I was having problems with at Timing : Solutions. I'd like to get this into the tree, since it was helpful : then. : : Comments? : : When you are running a faster tick I think want to only call the mii and : watchdog stuff once a second still. I know this will break the tx watchdog : for example. Since it's kind of tricky to manage that I think you should : just use a separate timer for the twister stuff. Is this in general, or do you have a specific problem in mind with the rl change? In general, we're not transmitting during this exercise and it happens only once... Is it worth the extra hair? Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Code review
I did this a few years ago when trying to track down a problem with
some realtek network chips that I was having problems with at Timing
Solutions. I'd like to get this into the tree, since it was helpful
then.
Comments?
Warner
diff -ur src/sys/pci/if_rl.c newcard/src/sys/pci/if_rl.c
--- src/sys/pci/if_rl.c 2008-08-23 22:21:15.0 -0600
+++ newcard/src/sys/pci/if_rl.c 2008-08-23 22:26:09.0 -0600
@@ -1253,18 +1253,120 @@
}
static void
+rl_twister_update(struct rl_softc *sc)
+{
+ uint16_t linktest;
+ static const uint32_t param[4][4] = {
+ {0xcb39de43, 0xcb39ce43, 0xfb38de03, 0xcb38de43},
+ {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83},
+ {0xcb39de43, 0xcb39ce43, 0xcb39ce83, 0xcb39ce83},
+ {0xbb39de43, 0xbb39ce43, 0xbb39ce83, 0xbb39ce83}
+ };
+
+ /*
+* Tune the so-called twister registers of the RTL8139. These
+* are used to compensate for impendence mismatches. The
+* method for tuning these registes is undocumented and the
+* following proceedure is collected from public sources.
+*/
+ switch (sc-rl_twister)
+ {
+ case CHK_LINK:
+ /*
+* If we have a sufficent link, then we can proceed in
+* the state machine to the next stage. If not, then
+* disable further tuning after writing sane defaults.
+*/
+ if (CSR_READ_2(sc, RL_CSCFG) RL_CSCFG_LINK_OK) {
+ CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_OFF_CMD);
+ sc-rl_twister = FIND_ROW;
+ } else {
+ CSR_WRITE_2(sc, RL_CSCFG, RL_CSCFG_LINK_DOWN_CMD);
+ CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST);
+ CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF);
+ CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF);
+ sc-rl_twister = DONE;
+ }
+ break;
+ case FIND_ROW:
+ /*
+* Read how long it took to see the echo to find the tuning
+* row to use.
+*/
+ linktest = CSR_READ_2(sc, RL_CSCFG) RL_CSCFG_STATUS;
+ if (linktest == RL_CSCFG_ROW3)
+ sc-rl_twist_row = 3;
+ else if (linktest == RL_CSCFG_ROW2)
+ sc-rl_twist_row = 2;
+ else if (linktest == RL_CSCFG_ROW1)
+ sc-rl_twist_row = 1;
+ else
+ sc-rl_twist_row = 0;
+ sc-rl_twist_col = 0;
+ sc-rl_twister = SET_PARAM;
+ break;
+ case SET_PARAM:
+ if (sc-rl_twist_col == 0)
+ CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET);
+ CSR_WRITE_4(sc, RL_PARA7C,
+ param[sc-rl_twist_row][sc-rl_twist_col]);
+ if (++sc-rl_twist_col == 4) {
+ if (sc-rl_twist_row == 3)
+ sc-rl_twister = RECHK_LONG;
+ else
+ sc-rl_twister = DONE;
+ }
+ break;
+ case RECHK_LONG:
+ /*
+* For long cables, we have to double check to make sure we
+* don't mistune.
+*/
+ linktest = CSR_READ_2(sc, RL_CSCFG) RL_CSCFG_STATUS;
+ if (linktest == RL_CSCFG_ROW3)
+ sc-rl_twister = DONE;
+ else {
+ CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_RETUNE);
+ sc-rl_twister = RETUNE;
+ }
+ break;
+ case RETUNE:
+ /* Retune for a shorter cable (try column 2) */
+ CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_CBL_TEST);
+ CSR_WRITE_4(sc, RL_PARA78, RL_PARA78_DEF);
+ CSR_WRITE_4(sc, RL_PARA7C, RL_PARA7C_DEF);
+ CSR_WRITE_4(sc, RL_NWAYTST, RL_NWAYTST_RESET);
+ sc-rl_twist_row--;
+ sc-rl_twist_col = 0;
+ sc-rl_twister = SET_PARAM;
+ break;
+
+ case DONE:
+ break;
+ }
+
+}
+
+static void
rl_tick(void *xsc)
{
struct rl_softc *sc = xsc;
struct mii_data *mii;
+ int ticks;
RL_LOCK_ASSERT(sc);
mii = device_get_softc(sc-rl_miibus);
mii_tick(mii);
+ if (sc-rl_twister != DONE)
+ rl_twister_update(sc);
+ if (sc-rl_twister != DONE)
+ ticks = hz / 10;
+ else
+ ticks = hz;
rl_watchdog(sc);
- callout_reset(sc-rl_stat_callout, hz, rl_tick, sc);
+ callout_reset(sc-rl_stat_callout, ticks, rl_tick, sc);
}
#ifdef DEVICE_POLLING
@@ -1490,6 +1592,13 @@
rl_stop(sc);
/*
+* Reset
Code review request
I've been shepherding this patch in my p4 tree for a long time. It
removes the obsolete support for other systems in if_spppsubr.c. Is
there a reason I shouldn't commit this?
Warner
Index: if_spppsubr.c
===
--- if_spppsubr.c (revision 182085)
+++ if_spppsubr.c (working copy)
@@ -23,38 +23,22 @@
#include sys/param.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
#include opt_inet.h
#include opt_inet6.h
#include opt_ipx.h
-#endif
-#ifdef NetBSD1_3
-# if NetBSD1_3 6
-# include opt_inet.h
-# include opt_inet6.h
-# include opt_iso.h
-# endif
-#endif
-
#include sys/systm.h
#include sys/kernel.h
#include sys/module.h
#include sys/sockio.h
#include sys/socket.h
#include sys/syslog.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
#include sys/random.h
-#endif
#include sys/malloc.h
#include sys/mbuf.h
#include sys/vimage.h
-#if defined (__OpenBSD__)
-#include sys/md5k.h
-#else
#include sys/md5.h
-#endif
#include net/if.h
#include net/netisr.h
@@ -65,10 +49,6 @@
#include netinet/ip.h
#include net/slcompress.h
-#if defined (__NetBSD__) || defined (__OpenBSD__)
-#include machine/cpu.h /* XXX for softnet */
-#endif
-
#include machine/stdarg.h
#include netinet/in_var.h
@@ -82,11 +62,7 @@
#include netinet6/scope6_var.h
#endif
-#if defined (__FreeBSD__) || defined (__OpenBSD__)
-# include netinet/if_ether.h
-#else
-# include net/ethertypes.h
-#endif
+#include netinet/if_ether.h
#ifdef IPX
#include netipx/ipx.h
@@ -95,12 +71,7 @@
#include net/if_sppp.h
-#if defined(__FreeBSD__) __FreeBSD__ = 3
-# define IOCTL_CMD_T u_long
-#else
-# define IOCTL_CMD_T int
-#endif
-
+#define IOCTL_CMD_Tu_long
#define MAXALIVECNT 3 /* max. alive packets */
/*
@@ -261,13 +232,8 @@
void(*scr)(struct sppp *sp);
};
-#if defined(__FreeBSD__) __FreeBSD__ = 3 __FreeBSD_version 501113
-#defineSPP_FMT %s%d:
-#defineSPP_ARGS(ifp) (ifp)-if_name, (ifp)-if_unit
-#else
#defineSPP_FMT %s:
#defineSPP_ARGS(ifp) (ifp)-if_xname
-#endif
#define SPPP_LOCK(sp) \
do { \
@@ -1422,11 +1388,7 @@
++sp-pp_loopcnt;
/* Generate new local sequence number */
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-pp_seq[IDX_LCP] = random();
-#else
- sp-pp_seq[IDX_LCP] ^= time.tv_sec ^ time.tv_usec;
-#endif
break;
}
sp-pp_loopcnt = 0;
@@ -2671,11 +2633,7 @@
if (magic == ~sp-lcp.magic) {
if (debug)
log(-1, magic glitch );
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-lcp.magic = random();
-#else
- sp-lcp.magic = time.tv_sec +
time.tv_usec;
-#endif
} else {
sp-lcp.magic = magic;
if (debug)
@@ -2856,11 +2814,7 @@
if (sp-lcp.opts (1 LCP_OPT_MAGIC)) {
if (! sp-lcp.magic)
-#if defined(__FreeBSD__) __FreeBSD__ = 3
sp-lcp.magic = random();
-#else
- sp-lcp.magic = time.tv_sec + time.tv_usec;
-#endif
opt[i++] = LCP_OPT_MAGIC;
opt[i++] = 6;
opt[i++] = sp-lcp.magic 24;
@@ -4383,15 +4337,7 @@
/* Compute random challenge. */
ch = (u_long *)sp-myauth.challenge;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
read_random(seed, sizeof seed);
-#else
- {
- struct timeval tv;
- microtime(tv);
- seed = tv.tv_sec ^ tv.tv_usec;
- }
-#endif
ch[0] = seed ^ random();
ch[1] = seed ^ random();
ch[2] = seed ^ random();
@@ -4900,17 +4846,7 @@
* aliases don't make any sense on a p2p link anyway.
*/
si = 0;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
-#elif defined(__NetBSD__) || defined (__OpenBSD__)
- for (ifa = TAILQ_FIRST(ifp-if_addrlist);
-ifa;
-ifa = TAILQ_NEXT(ifa, ifa_list))
-#else
- for (ifa = ifp-if_addrlist;
-ifa;
-ifa = ifa-ifa_next)
-#endif
if (ifa-ifa_addr-sa_family == AF_INET) {
si = (struct sockaddr_in *)ifa-ifa_addr;
sm = (struct sockaddr_in *)ifa-ifa_netmask;
@@ -4949,17 +4885,7 @@
* aliases don't make any sense on a p2p link anyway.
*/
si = 0;
-#if defined(__FreeBSD__) __FreeBSD__ = 3
TAILQ_FOREACH(ifa, ifp-if_addrhead, ifa_link)
-#elif defined(__NetBSD__) || defined (__OpenBSD__)
- for (ifa = TAILQ_FIRST(ifp-if_addrlist);
-ifa;
-
Re: Code review request
In message: [EMAIL PROTECTED] Roman Kurakin [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : I've been shepherding this patch in my p4 tree for a long time. It : removes the obsolete support for other systems in if_spppsubr.c. Is : there a reason I shouldn't commit this? : : It was there to ease the keeping code in sync with other systems. : Please ask Joerg Wunsch before removal. Yea, I knew that history. But there's been a lot of hacking on this file, and the ifdef's are for other systems that were contemporaneous with FreeBSD 3.0, but nothing newer. Plus the FreeBSDisms that are newer haven't been ifdef'd. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEAD UP: non-MPSAFE network drivers to be disabled
In message: [EMAIL PROTECTED] Robert Watson [EMAIL PROTECTED] writes: : : On Mon, 26 May 2008, Bruce M. Simpson wrote: : : Given that this is (a) 2008 and (b) 8.x we're talking about, are there : really that many consumers of SLIP to warrant it being carried forward at : all? : : It's kind of a basic. [C]SLIP has been historically handy to have around for : situations which warrant it. Mind you, given that we have had tun(4) in the : tree for years now, a userland implementation of SLIP is possible. : : As with all of these things it's down to someone sitting down and doing it. : : I'm not volunteering to support any of this as I don't use it myself (got : enough on my plate), merely pointing out that support for SLIP in a system : is something many people have taken for granted over the years, and for : prototyping something or providing IP over a simple serial link without the : configuration overhead of PPP, SLIP is something someone might be using. : : P.S. ahc(4) is commodity hardware, I think it can stay right where it is : thank-you. : : My suspicion is that getting SLIP basically working in userspace is fairly : straight forward, SLiRP and friends have been doing this for years. I made my living for about a year working on TIA, which was a portable, userland implementation of PPP and SLIP/CSLIP. This was in about 1995 or so. It isn't that hard... : SLIP has its subtleties, but the current implementation is relatively : straight-forward, well-documented, etc. Yes, especially CSLIP. But frankly, they are a whole lot easier than PPP to get up and going... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: HEAD UP: non-MPSAFE network drivers to be disabled
In message: [EMAIL PROTECTED] Bruce M. Simpson [EMAIL PROTECTED] writes: : Other than that, line disciplines can go away. In the past I've uesd line disciplines to implement a keyboard driver for the Apple Newton Keyboard (serial protocol) so I could use it at any point after the loader (the system didn't run X11, so I couldn't use the X11 driver I wrote there). This system has been retired, and I don't think I ever forward ported them past about 3.mumble, if even that far. This code is badly decayed, and I have no requirement that it continues to work. But I know similar techniques are used in some embedded systems. Expect some delayed complaining if they go away entirely. But that may be OK given we're ridding tty of Giant. Now, if we could only sort out the syscons/keyboard/mouse mess... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: upkhy ed driver problem
looks like somebody took out my bogus filter for mii addresses. Grump. Will track this down. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Issue with huge numbers of connections
Greetings, I have a friend who is having problems with a service he's running. He gets billions and billions of connections to this service a day. Somewhere between 10^8 and 10^9 connections, he notices that his servers lose the ability to accept new connections. These are TCP connections. This is with FreeBSD 6.1R. My first question is: does anybody know if the fixes to -current/7.0 have fixed this? Is there a fix that can be back ported? He's currently working around the problem by having a number of different machines that reboot in a round robin fashion, but would like a better solution. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Issue with huge numbers of connections
In message: [EMAIL PROTECTED] Joe Holden [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : Greetings, : : I have a friend who is having problems with a service he's running. : He gets billions and billions of connections to this service a day. : Somewhere between 10^8 and 10^9 connections, he notices that his : servers lose the ability to accept new connections. These are TCP : connections. : : This is with FreeBSD 6.1R. My first question is: does anybody know if : the fixes to -current/7.0 have fixed this? Is there a fix that can be : back ported? He's currently working around the problem by having a : number of different machines that reboot in a round robin fashion, but : would like a better solution. : : Warner : ___ : Warner, if he hasn't done so already, have you suggested tweaking the : sysctl variables, such as: : kern.maxfilesperproc : kern.ipc.nmbclusters : kern.maxprocperuid : kern.maxfiles : kern.ipc.somaxconn : kern.maxvnodes : : Tweaking those may help, or he may just be exhausting available : resources, IIRC its limited to 65k connections per interface, someone : correct me if I am wrong. Here's the bug report I got: There is still a vague problem with the FreeBSD network interface -- especially the part that handles TCP. Something strange happens after about a week or so (after handling about 10^8 or 10^9 connections). The system becomes unreachable for TCP connections. I have fixed this problem by having all of the FreeBSD systems reboot automatically once a week using a cron job. I have not been able to isolate this issue, but I suspect that there is some kind of problem with the error handling and some resource gets depleted slowly. I realize that this is pretty vague, but I have not been able to find out what actually happens in this case. I believe that each connection lasts on the order of tens or hundreds milliseconds, given what I know about the systems in place. My earlier rephrase omitted a few key points. I suggested that he try to use a newer version of FreeBSD, but since these are a production system, he's hesitant to mess with them... Doing the math on 10^9 connections in a week translates to ~1650/s, so we'd expect there are on the order of 100-200 connections steady state at any time. I suspect that the peak load may be up to 100 times that, which is still only 2 connections. The hangs don't seem to hang at a peak, but randomly. Given all that, I'm not sure which of the above to try. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD NFS Client, Windows 2003 NFS server
In message: [EMAIL PROTECTED] Harti Brandt [EMAIL PROTECTED] writes: : On Thu, 7 Dec 2006, Harti Brandt wrote: : : HBOn Thu, 7 Dec 2006, M. Warner Losh wrote: : HB : HBMWLIn message: [EMAIL PROTECTED] : HBMWLHarti Brandt [EMAIL PROTECTED] writes: : HBMWL: MWLDoes anybody have experience with using FreeBSD 4.x or 6.x NFS clients : HBMWL: MWLagainst a Windows 2003 NFS server? What is the performance relative : HBMWL: MWLto using a FreeBSD NFS server? What is the stability? Does locking : HBMWL: MWLwork? Does the Windows 2003 server have extensions that grok file : HBMWL: MWLsystem flags? : HBMWL: : HBMWL: I use this regularily (well, -CURRENT). I have no numbers, but performance : HBMWL: is ok. I have the home directories on a W2003k server and it 'feels' fast : HBMWL: enough. : HBMWL : HBMWLWe see FreeBSD to FreeBSD NFS feeling fast enough for most things, but : HBMWLwhen we do a full build of our system from scratch it takes 10 hours : HBMWLover NFS vs 1 hour on a local disk. We're worried that if we were to : HBMWLtry to do heavy NFS traffic to a Win2003 server with SFU this would be : HBMWLeven slower. : HB : HBOk. I did a very short test (no time to do much more). Read performance : HBwith dd if=/nfs/bigfile of=/dev/null bs=4k is around 9MByte/sec. Write : HBperformance with dd if=/dev/zero of=/nfs/bigfile bs=4k is 4MByte/sec. : HB : HBClient is something around 1GHz with a 100Mbps link. Fileserver is a : HBdouble proc Xeon with a 1Gbps link. The Server has a load of around 30% : HB(from the antivirus scanner). : HB : HB72Mbps on a 100Mbps link looks actually ok for me. I've no FreeBSD on a : HBGigabit link to test with. : HB : HBIf you want I could try to do a buildworld. : : Ok. To answer my own mail. A buildworld with a local /usr/src takes 2:50h : on that machine, with /usr/src on the W2003 server 3:50h. Looks not that bad. So we're talking 33% slower here rather than 90% slower that I see for my entire product build. So the speed is similar to what I've seen over NFS here... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD NFS Client, Windows 2003 NFS server
In message: [EMAIL PROTECTED] Harti Brandt [EMAIL PROTECTED] writes: : : Hi Warner, : : On Wed, 6 Dec 2006, M. Warner Losh wrote: : : MWLDoes anybody have experience with using FreeBSD 4.x or 6.x NFS clients : MWLagainst a Windows 2003 NFS server? What is the performance relative : MWLto using a FreeBSD NFS server? What is the stability? Does locking : MWLwork? Does the Windows 2003 server have extensions that grok file : MWLsystem flags? : : I use this regularily (well, -CURRENT). I have no numbers, but performance : is ok. I have the home directories on a W2003k server and it 'feels' fast : enough. : : The only problem I see is a lot of 'file server not reponding' and 'file : server up again' (with 2-3 seconds in between). This is usually when : saving a large mail from pine. Linux clients see the same problem, so I : suppose it is a problem on the SFU side. Locking seems to work. Problems : are with filenames that are illegal for NTFS - hosting a 2.11BSD source : tree on a W2003 NFS share does not work because of filenames containing : ':' :-). I've not tested what other characters are illegal. This is excellent information. So building a ports tree would be, ummm, problematic. : Another problem is that on the NTFS side there is no good way to backup, : copy, whatever the trees, because while NTFS handles Makefile and : makefile, no Windows tool can access both of them. Even worse thinks like : ADSM backup sometimes die with internal errors. That's good information. : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools : and cygwin all see different numbers which is rather annoying. The same is : with symbolic links. Also good information. : The file flags are not supported by the server. There are no extensions : that I know of. This is the one I knew about! The others are far more important :-) Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD NFS Client, Windows 2003 NFS server
In message: [EMAIL PROTECTED] Harti Brandt [EMAIL PROTECTED] writes: : MWLDoes anybody have experience with using FreeBSD 4.x or 6.x NFS clients : MWLagainst a Windows 2003 NFS server? What is the performance relative : MWLto using a FreeBSD NFS server? What is the stability? Does locking : MWLwork? Does the Windows 2003 server have extensions that grok file : MWLsystem flags? : : I use this regularily (well, -CURRENT). I have no numbers, but performance : is ok. I have the home directories on a W2003k server and it 'feels' fast : enough. We see FreeBSD to FreeBSD NFS feeling fast enough for most things, but when we do a full build of our system from scratch it takes 10 hours over NFS vs 1 hour on a local disk. We're worried that if we were to try to do heavy NFS traffic to a Win2003 server with SFU this would be even slower. : The only problem I see is a lot of 'file server not reponding' and 'file : server up again' (with 2-3 seconds in between). This is usually when : saving a large mail from pine. Linux clients see the same problem, so I : suppose it is a problem on the SFU side. So building large binaries might be a problem? : Locking seems to work. Does seems to work mean it really does work, or does SFU just do the old trick of saying 'ok, your lock worked'? : Problems : are with filenames that are illegal for NTFS - hosting a 2.11BSD source : tree on a W2003 NFS share does not work because of filenames containing : ':' :-). I've not tested what other characters are illegal. That would be a problem for hosting a ports tree on the NTFS nfs partition, no? : Another problem is that on the NTFS side there is no good way to backup, : copy, whatever the trees, because while NTFS handles Makefile and : makefile, no Windows tool can access both of them. Even worse thinks like : ADSM backup sometimes die with internal errors. That's ugly. : Mapping of UIDs and GIDs is rather magic. The FreeBSD side, the SFU tools : and cygwin all see different numbers which is rather annoying. The same is : with symbolic links. Symblic links point elsewhere? or have different destinations? Does it matter absolute or relative? : The file flags are not supported by the server. There are no extensions : that I know of. Same problem with FreeBSD to FreeBSD NFS. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
FreeBSD NFS Client, Windows 2003 NFS server
Does anybody have experience with using FreeBSD 4.x or 6.x NFS clients against a Windows 2003 NFS server? What is the performance relative to using a FreeBSD NFS server? What is the stability? Does locking work? Does the Windows 2003 server have extensions that grok file system flags? Thanks much Warner P.S. If this is the wrong place to ask, please suggest a better one. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: cvs commit: src/sys/net if_vlan.c
In message: [EMAIL PROTECTED] Brooks Davis [EMAIL PROTECTED] writes: : and act as though the interface is not there. We could then consider : either holding the interface for a configurable or computed length : of time or adding some sort of refcounting (probably impractical). Refcounting would be good for the 'macro' things (coming and going) that are infrequent, but we might have mulitple people doing. You are right it likely is too inefficient to do with mbugs. One other option might be to have a configurable time after the last time that it was accessed via the 'safe' routines that were setup. This way we'd tie the removal of the interface to a period of time after it was last used, rather than after it was removed. I don't know if such a difference would matter much in practice. The only other 'issue' that I see with this approach is if I remove a card, and then insert it again before the timeout happens. Does that card get a new interface name? And would people care or not... Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: hosts.allow default behaviour: IPv6 on its own lines
From: Dmitry Morozovsky [EMAIL PROTECTED] Subject: hosts.allow default behaviour: IPv6 on its own lines Date: Thu, 16 Feb 2006 14:03:37 +0300 (MSK) Dear colleagues, at least rpcbind brokes on parsing hosts.allow file when built with NO_INET6: Feb 16 13:55:41 ... rpcbind: error: /etc/hosts.allow, line 42: missing option name Feb 16 13:55:41 ... rpcbind: connect from 127.0.0.1 to getport/addr(mountd): request from unauthorized host Maybe split default line to simplify commenting second one out? Index: hosts.allow === RCS file: /home/ncvs/src/etc/hosts.allow,v retrieving revision 1.19 diff -u -r1.19 hosts.allow --- hosts.allow 3 Aug 2004 08:58:34 - 1.19 +++ hosts.allow 16 Feb 2006 10:58:00 - @@ -36,7 +36,9 @@ # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). -ALL : localhost 127.0.0.1 [::1] : allow +ALL : localhost 127.0.0.1 : allow +# Comment out next line if you use kernel without IPv6. +ALL : [::1] : allow ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s The comment isn't quite right. If the kernel doesn't have IPv6, then it is fine. It is only if userland is compiled with NO_IPV6 that there's a problem. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: USB CDC ACM
I beleive that umodem implements the usb cdc acm interface. Warner ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mem leak in mii ? (fwd)
In message: [EMAIL PROTECTED]
Bjoern A. Zeeb [EMAIL PROTECTED] writes:
: * all PHY drivers currently seem to use mii_phy_detach for
: device_detach. If any implements his own function it will be
: responsible for freeing the ivars allocated in miibus_probe. This
: should perhaps be documented somewhere ?
I think that the current patches are incorrect from a newbus point of
view. They may solve the problem, but just smell wrong...
:
: patch can also be found at
: http://sources.zabbadoz.net/freebsd/patchset/mii-memleaks.diff
:
:
: Index: mii.c
: ===
: RCS file: /local/mirror/FreeBSD/r/ncvs/src/sys/dev/mii/mii.c,v
: retrieving revision 1.20
: diff -u -p -r1.20 mii.c
: --- mii.c 15 Aug 2004 06:24:40 - 1.20
: +++ mii.c 23 Nov 2004 17:08:58 -
: @@ -111,7 +111,7 @@ miibus_probe(dev)
: struct mii_attach_args ma, *args;
: struct mii_data *mii;
: device_tchild = NULL, parent;
: - int bmsr, capmask = 0x;
: + int count = 0, bmsr, capmask = 0x;
:
: mii = device_get_softc(dev);
: parent = device_get_parent(dev);
: @@ -145,12 +145,26 @@ miibus_probe(dev)
:
: args = malloc(sizeof(struct mii_attach_args),
: M_DEVBUF, M_NOWAIT);
: + if (args == NULL) {
: + device_printf(dev, %s: memory allocation failure,
: + phyno %d, __func__, ma.mii_phyno);
: + continue;
: + }
: bcopy((char *)ma, (char *)args, sizeof(ma));
: child = device_add_child(dev, NULL, -1);
: + if (child == NULL) {
: + free(args, M_DEVBUF);
: + device_printf(dev, %s: device_add_child failed,
: + __func__);
: + continue;
: + }
: device_set_ivars(child, args);
: + count++;
: + /* XXX should we break here or is it really possible
: + * to find more then one PHY ? */
: }
:
: - if (child == NULL)
: + if (count == 0)
: return(ENXIO);
:
: device_set_desc(dev, MII bus);
: @@ -173,12 +187,15 @@ miibus_attach(dev)
:*/
: mii-mii_ifp = device_get_softc(device_get_parent(dev));
: v = device_get_ivars(dev);
: + if (v == NULL)
: + return (ENXIO);
: ifmedia_upd = v[0];
: ifmedia_sts = v[1];
: + device_set_ivars(dev, NULL);
: + free(v, M_DEVBUF);
: ifmedia_init(mii-mii_media, IFM_IMASK, ifmedia_upd, ifmedia_sts);
: - bus_generic_attach(dev);
:
: - return(0);
: + return (bus_generic_attach(dev));
: }
newbusly, this is bogus. device foo should never set its own ivars.
Nor should it ever get its own ivars to do anything with. parent
accessor functions are needed here.
: int
: @@ -186,8 +203,14 @@ miibus_detach(dev)
: device_tdev;
: {
: struct mii_data *mii;
: + void*v;
:
: bus_generic_detach(dev);
: + v = device_get_ivars(dev);
: + if (v != NULL) {
: + device_set_ivars(dev, NULL);
: + free(v, M_DEVBUF);
: + }
: mii = device_get_softc(dev);
: ifmedia_removeall(mii-mii_media);
: mii-mii_ifp = NULL;
Newbusly, this is incorrect. The parent bus should be freeing the
ivars, since it is the one that should have put the ivars there in the
first place.
: @@ -305,12 +328,15 @@ mii_phy_probe(dev, child, ifmedia_upd, i
: int bmsr, i;
:
: v = malloc(sizeof(vm_offset_t) * 2, M_DEVBUF, M_NOWAIT);
: - if (v == 0) {
: + if (v == NULL)
: return (ENOMEM);
: - }
: v[0] = ifmedia_upd;
: v[1] = ifmedia_sts;
: *child = device_add_child(dev, miibus, -1);
: + if (*child == NULL) {
: + free(v, M_DEVBUF);
: + return (ENXIO);
: + }
: device_set_ivars(*child, v);
:
: for (i = 0; i MII_NPHY; i++) {
This appears to be correct, because the ivars are set on the child
that's added.
: @@ -324,14 +350,22 @@ mii_phy_probe(dev, child, ifmedia_upd, i
: }
:
: if (i == MII_NPHY) {
: + device_set_ivars(dev, NULL);
: + free(v, M_DEVBUF);
: device_delete_child(dev, *child);
: *child = NULL;
: return(ENXIO);
: }
:
: - bus_generic_attach(dev);
: + i = bus_generic_attach(dev);
:
: - return(0);
: + v = device_get_ivars(*child);
: + if (v != NULL) {
: + device_set_ivars(*child, NULL);
: + free(v, M_DEVBUF);
: + }
: +
: + return (i);
: }
This appears to be correct, since it is the bus managing the child's
ivars.
: /*
: Index: mii_physubr.c
:
Re: cuaa0ttyd0's bug?
In message: [EMAIL PROTECTED] Bernd Walter [EMAIL PROTECTED] writes: : On Tue, May 18, 2004 at 09:05:52PM +0800, wsk wrote: : hi,folks: : It seems that the ttyd0 isn't the dialin line to login , and : the cuaa0 like is both the dialin/out device!under 4.9 above : and 5.X .but the ttyd0 work well under 4.8. : here is my test: : I wanna direct connected two bsd box via a null-modem cable,on : a box ,I congfiured the ttys as follow: : # The 'dialup' keyword identifies dialin lines to login, fingerd etc. : ttyd0 /usr/libexec/getty std.9600 dialup on secure : ttyd1 /usr/libexec/getty std.9600 dialup off secure : and kill -HUP 1 : on the other box , I use cu connenct the box: : cu -l /dev/cuaa0 : connected : and then , nothing more i could recv! : but if I confirgure the ttys as below: : # The 'dialup' keyword identifies dialin lines to login, fingerd etc. : cuaa0 /usr/libexec/getty std.9600 dialup on secure : ttyd1 /usr/libexec/getty std.9600 dialup off secure : and do it like before i do , it worked! : why It's a bug??? : : The behavour is intentional. : Your cable doesn't supply DCD signal. : Either use a cable with DCD suport or stay with cuaa. : It's OK to use cuaa if you don't need dialout support. or turn off modem flow control in the lock device... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: prism 2.5 timeout in wi_cmd 0x010b
In message: [EMAIL PROTECTED] Lorenzo Vicisano [EMAIL PROTECTED] writes: : However after upgrding the Prism firmware (1.1.0 - 1.1.1) : the lock up stopped. You really really really want to be using 1.4.5 firmware. Older firmware is known to be buggy. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: prism 2.5 timeout in wi_cmd 0x010b
In message: [EMAIL PROTECTED] Lorenzo Vicisano [EMAIL PROTECTED] writes: : Warner, : : On Sun, Jan 11, 2004 at 02:23:57PM -0700, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Lorenzo Vicisano [EMAIL PROTECTED] writes: : : However after upgrding the Prism firmware (1.1.0 - 1.1.1) : : the lock up stopped. : : You really really really want to be using 1.4.5 firmware. Older : firmware is known to be buggy. : : I was referring to the primary, as for the station : I went from 1.4.2 to 1.7.4 .. but does the station : firmware affect the functionality as a client anyways ? Yes. It does. I've had reports of problems with newer versions of the firmware... I've been too swamped to try it out. The newer versions implement AP to AP junk, as well as WPA enhancements... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: finishing the if.h/if_var.h split
In message: [EMAIL PROTECTED] Brooks Davis [EMAIL PROTECTED] writes: : Six years and eight months ago, net/if.h was split into if.h and : if_var.h. At the time, if_var.h was included at the end if if.h as : follows (this is the current code, but it's equivalent): ... : Does this sound reasonable? I'd go ahead and finish the split. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: SMC 2602W PCI Wireless
In message: [EMAIL PROTECTED] Daniel Dias Goncalves [EMAIL PROTECTED] writes: : The device SMC 2602W PCI works in the FreeBSD? : vendor = 'Admtek Inc' unlikely. The adm wireless driver is still being ported. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Netgear MA401 stopped working
In message: [EMAIL PROTECTED] Nathan Clark [EMAIL PROTECTED] writes: : I have an IBM Thinkpad 600X which dual boots 5.1-Current and XP-Pro. I : purchased a Netgear MA401 wireless 802.11b card which worked fine under : both OS's for about a week. This past Saturday, however, I was unable : to connect to websites, my mail server etc. The symptoms are the same : under both OS's: After an extended time of waiting, I eventually resolve : the host, seem to be sending packets, but never receive anything back. Both OSes doing the same thing indicates a problem with the card, or a problem with the AP. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: ifconfig question
In message: [EMAIL PROTECTED] Wes Peters [EMAIL PROTECTED] writes: : Only if the spec says those are the only valid ranges. Then we have to : keep up to date with changes in the spec, too. Either some simple sanity : checks or checking for truly valid lengths -- 0, 40 bits, 128 bits -- : makes even better sense. 128 bits isn't a valid length either. Only 40 and 104 bits, which we currently semi-bogusly report as 64-bit and 128-bit. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to [EMAIL PROTECTED]
ifconfig question
The code that prints out the keys for the 802.11 wireless stuff has
the following it it:
void
ieee80211_status (int s, struct rt_addrinfo *info __unused)
{
...
if (ireq.i_len == 0 || ireq.i_len 13)
continue;
...
}
Should that check really be there? Newer wep does 256bits Not
that the rest of the code supports that, but I was just curious.
Second, should ifconfig report the wep key if run as root? wicontrol
does if it is run as root, for example. Any objections for fixing
this?
Warner
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Proper -current if_attach locking?
In message: [EMAIL PROTECTED] Terry Lambert [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Nate Lawson [EMAIL PROTECTED] writes: : : I was looking into some could sleep messages and found some bogus : : locking in the attach routine of many drivers. Several init a mtx in : : their softc and then lock/unlock it in their attach routine. This, of : : course, does nothing to provide exclusive access to a device. I assume : : there is going to be a global IF_LOCK or something to be used in attach : : routines. Can someone fill me in on the intended design? : : The locking in the attach routines is generally bogus. Locking is : only needed when you have more than one thread of execution. You : don't have more than one thread of execution until after you establish : the ISR and turn on interrupts. We should likely not be enabling : interrupts until very late in the attach routine so that we don't need : any locking in them. : : I looked at this. It seems to me that it's not quite that : simple (sorry). I think that there are issues with locking : because you don't know if this is a driver that's getting : loaded well after the system has booted, or if this is a : PCCARD or other hot plug device that has just arrived in : the system. That doesn't mattar at all. If it is a new device that's just arrived, the attach still won't be interrupted *by other code in the driver* until after it has setup its ISR and told the hardware to start generating interrupts. No device locking is needed in the attach routine until after interrupts are enabled in the hardware. : It also seems to me that the reversal problems that would : result by simply inserting locking have to do with the fact : that the code is relatively schitzophrenic on deciding whether : it's locking data, or it's locking a critical path. The reversal is because of the bogus locking. The first time through it locks the device then the interface. However, after that it locks the interface and then the device, which can be bad. It does point to a problem, however, in that sometimes we'll take out the locks in one order and other times other orders depending on the code path if we aren't careful. I should go look at the new code more closely. I worry that in the non interrupt case we get things in the IF, DEV order (because the IF locks, then calls the callback routines, which then call the DEV lock). But in the interrupt case we get the DEV lock first, then try to queue data and that somehow causes the IF locks to be grabbed. But you are right, I do need to go look at the code to see what, exactly, is happening and how the new interface locking code is interacting with the semi-bogus locking than many of the wpaul drivers have in them now. : I can't be the only one who finds FreeBSD 5.x to be in such a state : of flux that it's almost impossible to know what a correct : implementation is supposed to look like, for a given subsystem : and/or device driver, list, etc.. There we agree. It takes a lot to keep up, and even then I fall behind when something new happens behind my back. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Proper -current if_attach locking?
I was right (and I think you are too). We do have lock issues.
dc_attach does approximately:
DC_LOCK
ether_attach() (which does a IFNET_WLOCK/UNLOCK pair)
DC_UNLOCK
(this sets the lock order to be DC_LOCK, IFNET_WLOCK).
However in if_slowtimo we have:
if_slowtimo(arg)
{
... IFNET_RLOCK();
... if (ifp-if_watchdog)
(*ifp-if_watchdog)(ifp);
... IFNET_RUNLOCK();
}
and dc_watchdog does a DC_LOCK/UNLOCK pair). This is a Lock Order
Reversal, and not a LotR :-)
What's worse is that dc_intr does:
DC_LOCK
...dc_start (which calls IF_PREPEND which does the IFNET_LOCK/UNLOCK thing)
DC_UNLOCK
So even if we remove the one from attach, it looks like we have others
lurking in the code.
Either that, or it is too late for me to be looking at code like this
:-(
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: Proper -current if_attach locking?
In message: [EMAIL PROTECTED] Andrew Gallatin [EMAIL PROTECTED] writes: : : M. Warner Losh writes: : In message: [EMAIL PROTECTED] : Andrew Gallatin [EMAIL PROTECTED] writes: : : The IFNET_RLOCK() called in if_slowtimo() is a global lock for the : : list of ifnet structs to ensure that no devices are removed or added : : while something may be using it. There is one ifnet list in the system. : : So this means that only the locking in attach is bogus, and similar : locking in detach is also bogus because they produce lock order : reversals as the global lock is held to insert/remove if interfaces. : : Yes. Though I haven't looked at if_dc myself, there may be other : locking problems. I've only been commenting on the ones that you : brought up. : : But back to an earlier point. Somebody (you?) validly pointed out : that the driver should not be callable and should not generate : interrupts until its finished attaching. The lock in its attach was : probably a somewhat misguided attempt at that. Yes. That was me. There are some drivers that have separated front/back ends that makes this harder, but most of them don't. : The first point can be accomplished by doing the ether_ifattach() : last, but the second may be harder. I do that by poking a bit on my : card which prevents it from generating interrupts while the device is : being setup. Not sure if a similar bit exists on tulip cards. All PCI cards have to be able to turn off their interrupt sources, otherwise interrupt storms result. At least that's my understanding. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Proper -current if_attach locking?
In message: [EMAIL PROTECTED] Nate Lawson [EMAIL PROTECTED] writes: : I was looking into some could sleep messages and found some bogus : locking in the attach routine of many drivers. Several init a mtx in : their softc and then lock/unlock it in their attach routine. This, of : course, does nothing to provide exclusive access to a device. I assume : there is going to be a global IF_LOCK or something to be used in attach : routines. Can someone fill me in on the intended design? The locking in the attach routines is generally bogus. Locking is only needed when you have more than one thread of execution. You don't have more than one thread of execution until after you establish the ISR and turn on interrupts. We should likely not be enabling interrupts until very late in the attach routine so that we don't need any locking in them. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ep(4) does not support mediaopt full-duplex
In message: [EMAIL PROTECTED] Eugene Grosbein [EMAIL PROTECTED] writes: : Is there a good reason for : not supporting full-duplex? I don't think 3c589 supports full duplex at the hardware level. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ep(4) does not support mediaopt full-duplex
In message: [EMAIL PROTECTED] Mike Silbersack [EMAIL PROTECTED] writes: : So I conclude 3C589D does support full duplex at the hardware level. : : You say you're using a 3C589D, which is detected by if_ep_pccard.c as : such: : : case 0x9058: /* 3C589 */ : return (3Com Etherlink III 3C589); : : However, in if_xlreg.h, I see us define the following: : : #define TC_DEVICEID_CYCLONE_10_100_COMBO0x9058 : : Are these actually both the same card, or are PCI and PCCARD IDs : unrelated? If they are the same card, then clearly the solution is to : make if_xl work with the card instead of if_ep. :) These aren't the same. The vx driver should really be if_ep_pci acccording to Matt Dodd. if_xl might also be a if_ep_pci driver, but I'm not 100% about that. Matt knows for sure. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: ep(4) does not support mediaopt full-duplex
In message: [EMAIL PROTECTED] Mike Silbersack [EMAIL PROTECTED] writes: : From what I've read, the vortex cards do resemble the older Etherlink : IIIs, so yes those two could probably be merged. They are merged in NetBSD. I think Matt Dodd has some patches that do this. : However, the 3c900+ : cards have a true bus mastering PCI architecture, so it makes sense to fit : them into a seperate driver, such as if_xl. Just because it is true bus mastering doesn't mean that it makes sense to have a different driver... I haven't looked at the structure of these two drivers to know if this makes sense or not. I was mostly speculating out loud... : Here's another thing I'm confused about: : : from if_xlreg.h: : : #define TC_DEVICEID_HURRICANE_556 0x6055 : : from if_ep_pccard.c: : : case 0x6055: /* 3C556 */ : : Is it possible that 3Com used the same chip in mini-pci and pccard : designs? This does seem possible, as 3c905 (pre-B, I don't know about the : mini-PCI version) cards support the 3c509 interface. Likely just a compat thing. The 3com interfaces seem to have lots backward compat stuff (did you know you can get the EISA id out of pcmcia devices, at least the 3c1?) Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Netgraph and KQUEUE(2)
: 1) Device driver in Netgraph node. When hardware is :activated new Netgraph node is created and new :kevent sent. devd (or something like devd) listens :for these events and does something (loads firmware, :activates device, etc.) Device drivers are not netgraph nodes. They will have a device_t associated with them, which already sends a message via /dev/devctl to devd. You can do anything you want with the results. There's no need to reinvent the wheel that I'm almost done inventing. There's absolutely no need to bring netgraph into it all, and doing so makes it a less generic implementation. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Netgraph and KQUEUE(2)
In message: [EMAIL PROTECTED] Julian Elischer [EMAIL PROTECTED] writes: : : : On Wed, 6 Nov 2002, M. Warner Losh wrote: : : : 1) Device driver in Netgraph node. When hardware is : :activated new Netgraph node is created and new : :kevent sent. devd (or something like devd) listens : :for these events and does something (loads firmware, : :activates device, etc.) : : Device drivers are not netgraph nodes. They will have a device_t : associated with them, which already sends a message via /dev/devctl to : devd. You can do anything you want with the results. There's no need : to reinvent the wheel that I'm almost done inventing. There's : absolutely no need to bring netgraph into it all, and doing so makes : it a less generic implementation. : : devices that are netgraph nodes may not have any entry in /dev : and might only appear in the netgraph namespace.. : e.g. if_ar.c if_sr.c It doesn't matter. *ALL* devices have device_t entries. Recall that device_t is not dev_t. dev_t appears in /dev/. Hardware devices have to attach to some bus. That's why devd is done in newbus land rather than in dev_t land. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Comments Please
In message: [EMAIL PROTECTED] Luigi Rizzo [EMAIL PROTECTED] writes: : On Sat, Oct 12, 2002 at 05:18:09PM -0600, M. Warner Losh wrote: : OK. I'm not a network wonk, so I thought I'd run this by people : here. What do people think. : : sounds ok -- removing explicit constants is always good. : On passing: : : * While you are at it, : grep etherbroadcastaddr sys/net*/* : reveals the use of an explicit constant (6) in net/if_arp.h and : netinet/if_ether.c; there is more of the same in net/bridge.c : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c atmsubr? Doesn't ATM have its own constants? : * there is no real reason to have etherbroadcastaddr as a : variable. net/bridge.c has a macro, IS_ETHER_BROADCAST, : which is much faster to evaluate on i386, and : could be moved e.g. in net/ethernet.h and be used : to check for ethernet broadcast addresses in : net/if_ethersubr.c : net/if_iso88025subr.c : netatalk/aarp.c : net/if_fddisubr.c : This only leaves some usages of etherbroadcastaddr is in : netinet/if_ether.c to set the address for outgoing broadcast : packets. I'll let others deal with that. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: Comments Please
In message: [EMAIL PROTECTED]
Luigi Rizzo [EMAIL PROTECTED] writes:
: On Sat, Oct 12, 2002 at 08:07:47PM -0600, M. Warner Losh wrote:
: ...
: : reveals the use of an explicit constant (6) in net/if_arp.h and
: : netinet/if_ether.c; there is more of the same in net/bridge.c
: : (my fault), net/if_atmsubr.c, netinet/if_ether.c, netncp/ncp_subr.c
:
: atmsubr? Doesn't ATM have its own constants?
:
: eh, that's the problem with explicit constants, you can never tell
: whether 6 is english, german or italian... in any case the
: relevant piece of code is:
:
: net/if_atmsubr.c: if (bcmp(alc, ATMLLC_HDR, 6)) {
:
: I have no idea if it has any relation with ethernet header sizes.
Looks like that one should be something else, since it is an atm llc
header. Of course the atm code should be using if_llc.h to get this
stuff, but that's another story...
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-net in the body of the message
Re: Multicast problem with wi driver in promiscuous mode - anyresolution?
I don't think anybody has applied fixes to the wi driver in that time frame for this purpose. Have fun :-(. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
Re: 802.11: WaveLAN/Orinoco Cards
In message: 005b01c1f4db$e3563f20$020a@bender Martin Minkus [EMAIL PROTECTED] writes: : But it's a standard WaveLAN/Orinico card, which is what the wi driver is : intended for? : : I never had to worry about any of this when I had the old white/bronze : 2mbit wavelan cards, but with silver and gold cards, its been nothing : but fun and games Yea. Terry is wrong here. Ignore what he says, for he knowest not what he talkest about. The wi driver might be getting some of them wrong, but it is impossible to say because you didn't include the version you were using (there was a bug releated to this fixed in the not too distant past). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-net in the body of the message
