Linux 4.18 Preparing Many New Features While Dropping 100k+ Lines of Code (phoronix.com) 105
An anonymous reader writes: Linux 4.18 development is going strong with recent 4.18-rc1 release. This kernel cycle has dropped 107,210 lines of code so far but Linux 4.18 is adding many new features. The kernel is coming in lighter as a result of the LustreFS code being removed and other code cleanups. On the feature front, Phoronix reports, "ew AMDGPU support improvements, mainlining of the V3D DRM driver, initial open-source work on NVIDIA Volta GV100 hardware, merging of the Valve Steam Controller kernel driver, merging of the BPFILTER framework, ARM Spectre mitigation work, Speck file-system encryption support, removal of the Lustre file-system, the exciting restartable sequences system call was merged, the new DM writecache target, and much more."
mainlining (Score:2)
Re: (Score:2)
Re: (Score:3)
I thought I had that bug, but It was fixed by switching wireless PCI cards. The ATH9K driver was the culprit on my system.
It was pretty weird because the symptoms were the same-- Only crash at idle or near idle. As long as the CPU was under heavy load, the system ran flawlessly. I tried everything I could find online to mitigate it including the "rcu_nocbs=0-15" parameter.
I finally noticed some ath9k messages in the logs near the time of the crash, so I bought an intel PCI wireless adapter and replaced my o
Re: bug remaining? (Score:1)
Re: (Score:2)
Late reply, but this Atheros card came out of the predecessor of my Ryzen machine (Intel core i5). It worked in that setup without issue with the same OS.
After I replaced the wireless card in my Ryzen machine, I switched my old Atheros card back to the Intel computer where it works flawlessly.
Re: (Score:2)
Almost forgot-- Unloading the ath9k kernel module without replacing the hardware also solved the problem.
Re: (Score:2)
Looks like you still need the bios setting (Score:2)
It looks like anything you do in the kernel is a workaround rather than a fix. So I wouldn't expect it to be "fixed" in the kernel, since it's not really a kernel problem.
From what I can gather, until AMD does a firmware fix (or hardware?) the best option is to select "typical current idle" in bios.
Of course, if the rcu workaround is working for you, you might just leave it at that until AMD really fixes the issue.
You need zenstates (Score:5, Informative)
How can I tell if the bug that was crashing Ryzen processors at idle has been fixed?
In 4,15, Ryzen users had to put in a boot option
"rcu_nocbs=0-15
(this case for 8 cores =0-11 for a six core...)
I had this problem too and the rcu_nocbs=0-15 didn't fix entirely the problem. You need zenstates [github.com] to turn off the C6 power saving state.
Here's the systemd unit file:
[Unit]
/usr/local/src/ZenStates-Linux-master/zenstates.py --c6-disable
Description=Turn off power saving C6 state
[Service]
Type=oneshot
StandardOutput=syslog
ExecStart=/usr/bin/python
[Install]
WantedBy=basic.target
Re: You need zenstates (Score:5, Informative)
Yes, I'm sure she'd rather see error 0×657EA6556778B4732FFED56546
That way she can fire up her hex editor and manually patch the Windows kernel to fix the issue.
Re: (Score:2)
Why would your grandmad do it manually? Instead of you running a script over SSH, like a COMPUTER user.
Running a script over SSH doesn't help if the problem is in the computer's networking configuration, or if the computer is behind an ISP that applies carrier-grade network address translation (CGNAT) because it lacks enough IPv4 addresses for all of its home subscribers.
Re: (Score:2)
Re: (Score:2)
Re: (Score:2)
Additionally using the TLA "DRM" in your device driver is the kind of horrible
Re: (Score:2)
Lustre dead? (Score:4, Interesting)
With Intel shutting down their commercial support business last year and now LustreFS being removed from the mainline kernel is Lustre dead as a common solution? What is replacing it as a scalable FS in HPC applications?
Re: (Score:1)
Glusterfs
Re: (Score:2)
I have recently switched to this over NFS very recently. Native fault tolerance is a good thing!
Re: (Score:2, Informative)
The Lustre devs basically never played nice with the Linux Kernel devs, and Lustre never left the STAGING sub-section of the Linux Kernel because they never (in almost a decade) cleaned up the code to pass Linux Kernel code reviews.
Lustre's most recent full release was just this last April, it's very much under heavy development, but in the HPC world having your code 'upstream' is basically a non-issue because they're used to having to do a million minor adjustments to eek out another 1% performance, since
Re: (Score:3)
This is a major downside of the "everything in the same source tree" Linux philosophy.
In a different universe, we could have pluggable filesystem modules that could be built against each kernel source[1] without having to get it all into the same tree. If the kernel API changed,
Re: (Score:2)
The problem with pluggable filesystem modules is that we still have a lot of innovation to do in the low-level kernel handling of I/O, thus the interface remains in flux. Significant performance gains have been realized and more are possible, and architecture for systems with significantly greater parallelism is still in progress. Taking advantage of new hardware capabilities has also required changes in interfaces.
One of the unique things about Linux is that the developers are allowed to innovate. It's a f
Re: (Score:2)
Indeed. So I would stipulate that the kernel is absolutely allowed to break the plugin API at any point for any reason.
It would be courteous to announce those on some list in advance, but that's all I would even ask those guys to provide.
Re: (Score:2)
We have that now. You build your out of tree module and then modprobe it.
Re: (Score:2)
Never a filesystem module, I'll admit, but they can function fine as a module afaik... Am I wrong?
Re: (Score:2)
Executive Summary: You think you want a stable kernel interface, but you really do not, and you don't even know it. What you want is a stable running driver, and you get that only if your driver is in the main kernel tree. You also get lots of other good benefits if your driver is in the main kernel tree, all of which has made Linux into such a strong, stable, and mature operating system which is the reason you are using it in the first place.
Re: (Score:3)
He's wrong, I prefer a stable API, unstable APIs and bad vendors is why we have the mess we do with Android and why Treble is the kinda solution, by freezing on a LTSR kernel they've effectively created an artificially stable API which they backport everything else around. In an idealized world, yes I'd love to have every driver in mainline so that everything gets updated together and the kernel devs were free to monkey with things to their hearts content, in the real world I live in a stable API allows ven
Re: (Score:2)
I disagree. Stable API are good. Being able to innovate at all layers is good.
My $0.02 is that you should avoid breaking it, but sometimes you gotta. When Windows moved to the new graphics model, they broke a ton of shit. But they also greatly improved platform stability.
Re: (Score:2)
That's what LTS kernels are for. Unless you have a compelling reason, you shouldn't be updating every time Linus releases a kernel. Instead, wait for your distro to backport any critical fixes.
Re: (Score:2)
An interface that you can change at will, provided you change everything that calls it, doesn't really deserve the moniker "interface". It's just a bunch of function calls that can change whenever you want. The entire point of interfaces is to divide development tasks using them, so that one does not have to have everything in the same source tree.
Re: (Score:2)
Can does not imply should.
My view on things was that the kernel devs should be entitled to change the API and that the plugin vendors should not be entitled to complain about the API change. This was meant only to pre-resolve any dispute over who is responsible for breakage.
Given the good reputation of kernel devs, I expect they. would not do so for light and transient reasons, but would change the API when there was a good reason to. It would be stable enough, but power to decide when improvements require
Re: (Score:2)
Repeating it doesn't make it true. Having a module in the main kernel tree only guarantees it will continue to build, because there's no way for the kernel maintainers to actually test drivers for often esoteric and expensive peripherals, specialised filesystems, or other unusual use-cases. I do want stable kernel ABIs, so drivers continue to work and I'm not at the mercy of people having to play constant catch-up when things are shuffled.
Re: (Score:2)
We have that in this universe.
Re: (Score:2)
Re: (Score:3)
Source: Linux literally loses its Lustre – HPC filesystem ditched in new kernel [theregister.co.uk]. The Register, 18 Jun 2
Re: (Score:3)
No, I'm just tired of squinting at attached screenshots rather than the user with a problem just being able to cut paste 160 characters of text into an email.
That and clearly telling the user to click on the thing that looks like a squished beetle and they keep clicking on the deformed grasshopper.
Give us a call after you spend some time maintaining a server you have never actually touched or seen on the other side of the country, then tell us how much you like the gooey interface.
Re: (Score:3)
You obviously haven't reached a skill level where the significant advantages of text based admin come in. Sometimes enterprise means resilliant and effective, but quite often it means brittle and catering to the lowest common denominator.
It''s fine if users use a GUI, but the system itself should be text based so a skilled admin has a chance of actually fixing it when it's not working right. Even MS is starting to recognize that.
As for LAN/WAN, step one when there is a problem is ditch the GUI and get a com
Causing more problems down the line (Score:2)
Re:Causing more problems down the line (Score:5, Informative)
In this case what was removed was mostly components in the staging sub-section that had been there for years (over half a decade in many cases) but hadn't completed appreciable work towards exiting the Staging sub-section. So they're finally getting the boot back out of kernel since they had never graduated to 'full kernel support' due to lack of action on their devs part. Lustre in particular basically stopped contributing to the staging branch since they felt it slowed them down too much versus working on their out-of-tree version of the code instead.
Those ridges are stoney and bristol... (Score:1)
The older AMD Stoney Ridge and Bristol Ridge AMD APUs finally have temperature reporting support.
Stoney Ridge is old. Bristol Ridge is available on AMD's newest platform, AM4.
Re: (Score:2)
But be careful, the NSA also provided advice to NIST that resulted in significantly weakening their crypto standards.
Hash in counter mode is a stream cipher (Score:2)
Except that SHA is a hash, not an encryption scheme.
Any hash function can be turned into a stream cipher by running it in counter mode. This construction, called "Snuffle" by Daniel J. Bernstein, was the insight that led to the United States loosening its cryptography export regulations in the late 1990s. See Bernstein v. US [wikipedia.org] .
"ew AMDGPU" (Score:5, Funny)
Re: (Score:3)
Whoosh
Yah right. (Score:1)
This kernel cycle has dropped 107,210 lines of code so far but Linux 4.18 is adding many new features. The kernel is coming in lighter as a result of the LustreFS code being removed
Yah right. This is nothing to be proud of. It is a failure of the community, to be unable to maintain Lustre. Now it goes more proprietary than it already was. Shame on Linus and his hangers-on.
Re: (Score:2)
This kernel cycle has dropped 107,210 lines of code so far but Linux 4.18 is adding many new features. The kernel is coming in lighter as a result of the LustreFS code being removed
Yah right. This is nothing to be proud of. It is a failure of the community, to be unable to maintain Lustre. Now it goes more proprietary than it already was. Shame on Linus and his hangers-on.
Some weeny with mod points thinks Linus is perfect. No, far from it. Linus is great, but far from perfect, and the whole Lustre thing was obviously mismanaged, including by Linus and hangers-on like Gregkh.
Re: (Score:2)
Or the Lustre guys could have gotten their shit together and it could have been put in the mainline kernel.
They could have been encouraged to do that, instead of just throwing the baby out with the bathwater which is what idiot Gregkh did, because he has not got a fucking clue that this is just as important as the stuff he actually understands. Problem is, he's a bit of a dunce. You can see that in a lot of stuff he does. Crappy coder too.