The usual collection of resyncs and minor updates including pending fixes post 462.

This includes a fix for some uniprocessor build problems courtesy of Serge Belyshev. If you still have boot problems with uniprocessor builds the workaround is to create an SMP kernel.

I've finally bit the bullet and removed the block flush code from within the main schedule() call, in keeping with how mainline does it. This is a problem that has recurred every time I've removed this change from previous kernels and had to re-add it every time. Complete hangs under particularly heavy IO used to be the problem, please report back if these come back with this kernel, hence the warning.

On the previous kernel, some had crashes unless they enabled NUMA. I have no idea what caused these and have done no specific changes to address it. I don't want people to enable NUMA unnecessarily but if you have crashes this is the first thing to try and please report back.

There's a pattern here and it's almost certainly related to the warning I gave in the announce post. Here's a test patch that returns the code to the old behaviour which should fix this problem (and possibly others):bfs463-revert-unplugged.patch

Thanks for the quick feedback. That seems like once again it's a pretty significant bugfix. It seems this is the only way to flush unplugged IO in BFS. Let's see if it has any impact on the other issues out there as well but sometime in the near future I'll include this patch in the next BFS.

Hello and sorry for bad english.I have some weird thing happening with linux-ck k10, that i dont have with standart kernel. I'm using archlinux and repo-ck. It is not about some last releases, because i had this problem more then year ago.

After some uptime(more then 6-8 hours) all sites in any browser load only after 10-15 seconds? in the same time there is no problem with connection. coz there is no packets lost when i ping some url or use curl/torrent clients to download something. At first i thought its something with r8169 module for my Realtek RTL8168, so i changed it to r8168-ck - but that didnt help. So maybe it is with bfs and my harware?Pls direct me which additional information do you need to help fix this problem, any logs etc. So i can post them somewhere. Did anyone ever have the same problem as me?

Oner person has reported this problem with r8169 (it might have been you) but there is no code that touches that driver. What I suspect is happening is there's a race condition in the driver itself that is brought out by using BFS and is far less likely to happen on the mainline kernel. This means unless you can reproduce it on the mainline kernel and report the bug, I have no way to help you with it unfortunately.

Maybe it's not even with network(this module)? As i said connection are fine, just a browser behavior is weird. And this thing never happens with mainline kernel so i dont think i can reproduce it. Anyway, you don't think any logs when this will happen again would help you recognize a problem?

I didn't say there's no way... The real answer is I don't know. Perhaps get the output of 'top' running while it's happening to see if it's a problem of wasted CPU cycles or just sitting idle. Try your browser without plugins, try BFS without SMT nice.

still having the crashes (complete freeze) with BFS under heavy IO (old AMD CPU).Copying some data (ok, its was a large amount of it) from USB drive to SATA drive freezes the whole system. Only hard reset was working. Hadn't any logs within the systemd-journal. (Maybe, because I stripped down the debugging in my kernel config).My second test on another computer (i7 laptop) leads to an crash during USB stick test with f3write/f3read.