SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
Michael Larabel (phoronix) just did some interesting overhead benchmarking for the current (out of the box) Spectre&Meltdown mitigations on the newly released 5.0 kernel:
Of 57 benchmarks tested on these three systems with the Linux 5.0 kernel, the Core i9 7980XE performance was down by about 13% based upon the geometric mean of all the test results. The Intel Core i7 8086K performance was down by 17% with these out-of-the-box protections for Spectre and Meltdown.
Fix this by sanitizing IndexCard before using it to index apbs.
Notice that given that speculation windows are large, the policy is
to kill the speculation on the first load and not worry if it can be
completed with a dependent load/store [1].
Re: [Regression] Re: Linux 5.0.2
From: Alan J. Wylie
Date: Thu Mar 14 2019 - 16:43:20 EST
In reply to: Greg KH: "Re: [Regression] Re: Linux 5.0.2"
(Adding Linus, since his tree is also broken)
Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
> On Thu, Mar 14, 2019 at 07:59:00PM +0000, Alan J. Wylie wrote:
>> Greg KH <gregkh@xxxxxxxxxxxxxxxxxxx> writes:
>>
>> > I'm announcing the release of the 5.0.2 kernel.
>>
>> There is a regression for AMD-only builds.
>
> Adding the stable list, which people should do...
>
>>
>> See also Alec Ari's report:
>> https://lkml.org/lkml/2019/3/13/1113
>>
>> > If CONFIG_CPU_SUP_INTEL is disabled with either the 5.0.2 or 4.20.16
>> > kernel, it errors out right away:
>>
>> $ grep "CONFIG_CPU_SUP_" .config
>> # CONFIG_CPU_SUP_INTEL is not set
>> CONFIG_CPU_SUP_AMD=y
>> # CONFIG_CPU_SUP_HYGON is not set
>> # CONFIG_CPU_SUP_CENTAUR is not set
>>
>> CC arch/x86/events/core.o
>> In file included from arch/x86/events/core.c:44:
>> arch/x86/events/perf_event.h:1035:45: warning: âstruct cpu_hw_eventâ declared inside parameter list will not be visible outside of this definition or declaration
>> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
>> ^~~~~~~~~~~~
>> arch/x86/events/perf_event.h:1040:45: warning: âstruct cpu_hw_eventâ declared inside parameter list will not be visible outside of this definition or declaration
>> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
>> ^~~~~~~~~~~~
>> arch/x86/events/core.c: In function âfree_fake_cpucâ:
>> arch/x86/events/core.c:1998:20: error: passing argument 1 of âintel_cpuc_finishâ from incompatible pointer type [-Werror=incompatible-pointer-types]
>> intel_cpuc_finish(cpuc);
>> ^~~~
>> In file included from arch/x86/events/core.c:44:
>> arch/x86/events/perf_event.h:1040:59: note: expected âstruct cpu_hw_event *â but argument is of type âstruct cpu_hw_events *â
>> static inline void intel_cpuc_finish(struct cpu_hw_event *cpuc)
>> ~~~~~~~~~~~~~~~~~~~~~^~~~
>> arch/x86/events/core.c: In function âallocate_fake_cpucâ:
>> arch/x86/events/core.c:2012:25: error: passing argument 1 of
>> âintel_cpuc_prepareâ from incompatible pointer type
>> [-Werror=incompatible-pointer-types] if (intel_cpuc_prepare(cpuc,
>> cpu)) ^~~~ In file included from arch/x86/events/core.c:44:
>> arch/x86/events/perf_event.h:1035:59: note: expected âstruct
>> cpu_hw_event *â but argument is of type âstruct cpu_hw_events *â
>> static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int
>> cpu) ~~~~~~~~~~~~~~~~~~~~~^~~~ cc1: some warnings being treated as
>> errors
>
> Is this a regression?
5.0.1 was fine, git pulled, then "make oldconfig" just answering the default "N"s
> If so, what commit caused this?
It looks as if it's
commit 3ad8e57560d7652a66da12b41c668a593509f3ad
Author: Peter Zijlstra (Intel) <peterz@xxxxxxxxxxxxx>
Date: Tue Mar 5 22:23:15 2019 +0100
perf/x86/intel: Make cpuc allocations consistent
The cpuc data structure allocation is different between fake and
real cpuc's; use the same code to init/free both.
which is the commit which introduces the function:
+static inline int intel_cpuc_prepare(struct cpu_hw_event *cpuc, int cpu)
> Is this also an issue in Linus's tree right now?
Yes, as of 3b319ee220a8795406852a897299dbdfc1b09911
CC arch/x86/entry/common.o
arch/x86/events/core.c: In function âfree_fake_cpucâ:
arch/x86/events/core.c:1998:20: error: passing argument 1 of âintel_cpuc_finishâ from incompatible pointer type [-Werror=incompatible-pointer-types]
intel_cpuc_finish(cpuc);
^~~~
Thanks
Alan
Re: [GIT PULL] PCI changes for v5.1
From: Linus Torvalds
Date: Sun Mar 17 2019 - 17:19:26 EST
On Fri, Mar 8, 2019 at 9:31 AM Bjorn Helgaas <helgaas@xxxxxxxxxx> wrote:
>
> - Report PCIe links that become degraded at run-time (Alexandru Gagniuc)
Gaah. Only now as I'm about to do the rc1 release am I looking at new
runtime warnings, and noticing that this causes
genirq: Threaded irq requested with handler=NULL and !ONESHOT for irq 16
pcie_bw_notification: probe of 0000:00:1b.0cie010 failed with error -22
because you can't have a NULL handler for a level-triggered interrupt
(you need something to shut the interrupt off so that it doesn't keep
screaming!).
Happens on both my desktop and my laptop, regular intel CPU and
chipset, nothing odd in either case.
Everything else works, but the new BW notification obviously will
never work this way.
This is not holding up rc1, obviously, but I thought I'd mention it
since I noticed it as part of my "let's see that nothing regressed"
checks..
Linux 5.1-rc1
From: Linus Torvalds
Date: Sun Mar 17 2019 - 17:51:09 EST
It's Sunday, and two weeks have passed, and everything is normal. You
all know the drill by now - the merge window is closed, and things are
supposed to calm down.
The merge window felt fairly normal to me. And looking at the stats,
nothing really odd stands out either. It's a regular sized release
(which obviously means "big" - , but it's not bigger than usual) and
the bulk of it (just over 60%) is drivers. All kinds of drivers, the
one that stands out for being different is the habanalabs AI
accelerator chip driver, but I suspect we'll be starting to see more
of that kind of stuff. But there are all the usual suspects too - gpu,
networking, block devices etc etc.
A somewhat recent development is how the tools/testing/ updates have
been quite noticeable lately. That's not new to the 5.1 merge window,
it's been going on for a while, but it's maybe just worth a mention
that we have more new selftest changes than we have architecture
updates, for example. The documentation subdirectory is also quite
noticeable.
But on the whole, there's really stuff all over, including core VFS
updates (in addition to all the usual low-level filesystem updates
too, of course).
And as always, the shortlog is much too big to post with 11k+ commits
(12k+ if counting merges). So below is my usual "mergelog" listing
submaintainers and a summary of the git pulls I've done from them..
Go forth and test,
Linus
---
Last edited by cwizardone; 03-17-2019 at 05:31 PM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,134
Original Poster
Rep:
Another round of kernel updates has been scheduled for release Wednesday morning, GMT/UTC.
If there are no problems testing the release candidates they should be available sometime
Tuesday.
The 4.20.y series has been designated, End Of Life.
Quote:
From: Greg Kroah-Hartman
Date: Mon Mar 18 2019 - 05:29:00 EST
------------------
NOTE, this is going to be the LAST 4.20.y release. After this one, 4.20
will be end-of-life. Please move to the 5.0.y tree at this point in
time, or let me know why that is not possible.
------------------
KASAN has found use-after-free in fixed_mdio_bus_init,
commit 0c692d07842a ("drivers/net/phy/mdio_bus.c: call
put_device on device_register() failure") call put_device()
while device_register() fails,give up the last reference
to the device and allow mdiobus_release to be executed
,kfreeing the bus. However in most drives, mdiobus_free
be called to free the bus while mdiobus_register fails.
use-after-free occurs when access bus again, this patch
revert it to let mdiobus_free free the bus.......
Please see the change logs if you need more information.
Last edited by cwizardone; 03-20-2019 at 08:42 AM.
Distribution: Slackware64-current with "True Multilib" and KDE4Town.
Posts: 9,134
Original Poster
Rep:
Another round of kernel updates has been scheduled for release just before Noon Sunday, GMT/UTC.
If no problems are found while testing the release candidates, they should be available sometime Saturday.
5.04, will have 238 patches.
4.19.31, will contain 280 patches.
4.14.108, will include 183 patches.
4.9.165, will incorporate 118 patches.
4.4.177, will assimilate 230 patches.
3.18.137, will integrate 134 patches.
Last edited by cwizardone; 03-22-2019 at 12:25 PM.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.
cie010 failed with error -22
