Request for VIMAGE testing in 11.0-ALPHA6 and later
Hi, during the last weeks and months a lot of changes went into the tree to allow a top-to-bottom network stack teardown to stabilize VNET shutdown and plug some memory leaks. In addition some missing parts were virtualised or the virtualisation was fixed, e.g., pf and ipfilter, ipfw log interface. I have done some testing and stress testing but it's impossible to catch all combinations and setups or even options. So once 11.0-ALPHA6 is out please do test (or if you want to do so now r302302 or later). These changes are only and will only be in FreeBSD 11 for the time being. You will still need to compile your own kernel; GENERIC will not have VIMAGE enabled for 11.0 as that requires at least a performance analysis (due to extra layer of indirection). It will also still print the "experimental" feature line, as we do not want to commit to KPI/KBI or other things yet and we feel more testing would be good. I would advise to start testing on dedicated test-systems and not necessarily production servers but obviously that is your choice. Also if you are using ports that bring their own ifnet interfaces and you are experiencing problems please let us know. If you find problems please file a bug report and make sure to set "vimage" in the Keywords field but feel also free to post to freebsd-virtualisation@ which I'll be monitoring. Thanks a lot to everyone! Bjoern -- Bjoern A. Zeeb r15:7 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035
On, Mon Jun 27, 2016, Andriy Voskoboinyk wrote: > Mon, 27 Jun 2016 20:06:20 +0300 було написано Marcus von Appen > : > > Hi, > > the attached patch may fix this issue (probably) I'm getting downstream rates of around 300 to 500 kbit/s, so it's not much more than before, although the downstream rates seem to be a bit more stable now. [...] > > > > Let me know, what information is necessary to isolate and correct > > that issue. I'll gladly test it. :-) > > You can check number of input errors (netstat -I wlan0); it should be > relatively small (or even zero). It's zero with your patch; I do not have values from before at hand right now, but can provide them later on, should they be of interest. Cheers Marcus signature.asc Description: PGP signature
Re: RTL8812AU / RTL8821AU driver - call for testing
Some updates: - 11n (A-MPDU & A-MSDU) now is supported (hw.usb.urtwm.enable_11n option was removed); - Atheros Fast-Frames support was added in https://github.com/s3erios/urtwm/commit/e835e556a0533d0adf81008dd4330241a7a5fbab . Hi all! The driver is in https://github.com/s3erios/urtwm ; currently it includes most features from urtwn(4) + TCP/UDP/IP checksum validation. 11a is supported too (but without DFS at this moment). Seems to be stable enough with DLINK DWA-171 (RTL8821AU) (11a/b/g support was tested only; you can try to enable 11n Rx supportby adding "hw.usb.urtwm.enable_11n=1" into /boot/loader.conf). ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
P.S. Asynchronous nature of vt is also a poor excuse in my view. There are plenty ways to do it asynchronously, while preserving updates order. It should not be one-or-the-other deal. On Thu, Jun 30, 2016 at 7:21 AM, Maxim Sobolev wrote: > Ed, I think this is bug, not a feature. People expect scrolling and > updates to be smooth these days, the fact that we deliberately break it > just signifies very weird preferences somebody made while developing the > code. The fact that it "looks fine when scrolling stops" is no execuse IMHO. > > -Max > > On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten wrote: > >> Hi Maxim, >> >> 2016-06-28 21:14 GMT+02:00 Maxim Sobolev : >> > P.S. Just if somebody is interested in fixing those "fast scrolling text >> > turns into garbage" display issues, here is some screenshots of one of >> my >> > 11-alpha3 systems captured with a camera at 120fps. As you can see text >> > tears down quite badly. >> >> What happens is that rendering of vt(4) is done asynchronously. In >> addition to the screen contents, vt(4) keeps track of a rectangular >> area of the screen that needs to be updated. During every refresh, the >> rendering thread extracts and resets the coordinates of the >> rectangular area and redraws that area. It only holds a lock while >> extracting the rectangle's coordinates; not when redrawing. >> >> This means that if you have a lot of updates and redrawing is slow, >> you will get 'random' garbage on screen. Once output stops, the screen >> contents get refreshed one final time, making everything look all >> right again. >> >> -- >> Ed Schouten >> Nuxi, 's-Hertogenbosch, the Netherlands >> KvK-nr.: 62051717 >> >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Ed, I think this is bug, not a feature. People expect scrolling and updates to be smooth these days, the fact that we deliberately break it just signifies very weird preferences somebody made while developing the code. The fact that it "looks fine when scrolling stops" is no execuse IMHO. -Max On Thu, Jun 30, 2016 at 6:42 AM, Ed Schouten wrote: > Hi Maxim, > > 2016-06-28 21:14 GMT+02:00 Maxim Sobolev : > > P.S. Just if somebody is interested in fixing those "fast scrolling text > > turns into garbage" display issues, here is some screenshots of one of my > > 11-alpha3 systems captured with a camera at 120fps. As you can see text > > tears down quite badly. > > What happens is that rendering of vt(4) is done asynchronously. In > addition to the screen contents, vt(4) keeps track of a rectangular > area of the screen that needs to be updated. During every refresh, the > rendering thread extracts and resets the coordinates of the > rectangular area and redraws that area. It only holds a lock while > extracting the rectangle's coordinates; not when redrawing. > > This means that if you have a lot of updates and redrawing is slow, > you will get 'random' garbage on screen. Once output stops, the screen > contents get refreshed one final time, making everything look all > right again. > > -- > Ed Schouten > Nuxi, 's-Hertogenbosch, the Netherlands > KvK-nr.: 62051717 > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: console in 11.0-ALPHA4
Hi Maxim, 2016-06-28 21:14 GMT+02:00 Maxim Sobolev : > P.S. Just if somebody is interested in fixing those "fast scrolling text > turns into garbage" display issues, here is some screenshots of one of my > 11-alpha3 systems captured with a camera at 120fps. As you can see text > tears down quite badly. What happens is that rendering of vt(4) is done asynchronously. In addition to the screen contents, vt(4) keeps track of a rectangular area of the screen that needs to be updated. During every refresh, the rendering thread extracts and resets the coordinates of the rectangular area and redraws that area. It only holds a lock while extracting the rectangle's coordinates; not when redrawing. This means that if you have a lot of updates and redrawing is slow, you will get 'random' garbage on screen. Once output stops, the screen contents get refreshed one final time, making everything look all right again. -- Ed Schouten Nuxi, 's-Hertogenbosch, the Netherlands KvK-nr.: 62051717 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
11.0-ALPHA5 ipfw cannot create table type number
While testing the new firewall functionality on head I stumbled in this: root@sensei:~ [0]# ipfw table foo create type number ipfw: Table creation failed: Operation not supported root@sensei:~ [71]# The ipfw man page states this should work, am I missing something? -- Guido Falsi ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: EBR fix for life cycle races was Re: panic with tcp timers
On Tue, 28 Jun 2016 23:19:45 -0700 Matthew Macy wrote
>
>
>
> On Tue, 28 Jun 2016 15:51:57 -0700 K. Macy wrote
>
> > On Tue, Jun 28, 2016 at 10:51 AM, Matthew Macy wrote:
>
> > > You guys should really look at Samy Bahra's epoch based reclamation. I
> solved a similar problem in drm/linuxkpi using it.
> >
> > The point being that this is a bug in the TCP life cycle handling
> > _not_ in callouts. Churning the callout interface is not the best /
> > only solution.
> > -M
>
> Please see see D7017/D7018 as an example for an ultimately more robust
> solution than continued fiddling with the callout interface.
>
> https://reviews.freebsd.org/D7018
I realized that this shortens the race but still leaves one open from the time
the callout lock is dropped to the time the epoch begins. I have a proposed fix
to make read locks never block and to essentially close the race window.
The next issue that comes up is that synchronize is called too often. I'll talk
to Samy about it in a few hours and come up with a better design.
-M
>
> > > On Tue, 28 Jun 2016 02:58:56 -0700 Julien Charbon
> wrote
> > > >
> > > > Hi Randall,
> > > >
> > > > On 6/25/16 4:41 PM, Randall Stewart via freebsd-net wrote:
> > > > > Ok
> > > > >
> > > > > Lets try this again with my source changed to my @freebsd.net :-)
> > > > >
> > > > > Now I am also attaching a patch for you Gleb, this will take some
> poking to
> > > > > get in to your NF-head since it incorporates some changes we made
> earlier.
> > > > >
> > > > > I think this will fix the problem.. i.e. dealing with two locks in
> the callout system (which it was
> > > > > never meant to have done)..
> > > > >
> > > > > Note we probably can move the code to use the callout lock init
> now.. but lets see if this works
> > > > > on your setup on c096 and if so we can think about doing that.
> > > >
> > > > Thanks for proposing a patch. I believe your patch will work with
> > > > callout lock init, but not without: You still have a use-after-free
>
> > > > issue on the tcpcb without callout lock init.
> > > >
> > > > The case being subtle as usual, let me try to describe that could
> happen:
> > > >
> > > > With your patch we have:
> > > >
> > > > void
> > > > tcp_timer_keep(void *xtp)
> > > > {
> > > > struct tcpcb *tp = xtp;
> > > > struct tcptemp *t_template;
> > > > struct inpcb *inp;
> > > > CURVNET_SET(tp->t_vnet);
> > > > #ifdef TCPDEBUG
> > > > int ostate;
> > > >
> > > > ostate = tp->t_state;
> > > > #endif
> > > > inp = tp->t_inpcb;
> > > > KASSERT(inp != NULL, ("%s: tp %p tp->t_inpcb == NULL",
> __func__,
> > > > tp));
> > > > INP_WLOCK(inp);
> > > > if (callout_pending(&tp->t_timers->tt_keep) ### Use after
> free
> > > > of tp here
> > > > !callout_active(&tp->t_timers->tt_keep)) {
> > > > INP_WUNLOCK(inp);
> > > > CURVNET_RESTORE();
> > > > return;
> > > > }
> > > > ...
> > > >
> > > > The use-after-free scenario:
> > > >
> > > > [CPU 1] the callout fires, tcp_timer_keep entered
> > > > [CPU 1] blocks on INP_WLOCK(inp);
> > > > [CPU 2] schedules tcp_timer_keep with callout_reset()
> > > > [CPU 2] tcp_discardcb called
> > > > [CPU 2] tcp_timer_keep callout successfully canceled
> > > > [CPU 2] tcpcb freed
> > > > [CPU 1] unblocks, the tcpcb is used
> > > >
> > > > Then the tcpcb will used just after being freed... Might also
> crash or
> > > > not depending in the case.
> > > >
> > > > Extra notes:
> > > >
> > > > o The invariant I see here is: The "callout successfully canceled"
>
> > > > step should never happen when "the callout is currently being
> executed".
> > > >
> > > > o Solutions I see to enforce this invariant:
> > > >
> > > > - First solution: Use callout lock init with inp lock, your patch
> > > > seems to permit that now.
> > > >
> > > > - Second solution: Change callout_async_drain() behavior: It can
> > > > return 0 (fail) when the callout is currently being executed (no
> matter
> > > > what).
> > > >
> > > > - Third solution: Don't trust callout_async_drain(callout) return
> > > > value of 1 (success) if the previous call of callout_reset(callout)
> > > > returned 0 (fail). That was the exact purpose of r284261 change,
> but
> > > > this solution is also step backward in modernization of TCP
> > > > timers/callout...
> > > >
> > > >
