[PATCH] config: Enable CONFIG_MODVERSIONS
by Don Zickus
Hi,
I noticed that CONFIG_MODVERSIONS was not enabled in Fedora. I do not know
the history and would be curious to know if someone knew.
Otherwise, I would like to propose enabling it. Traditionally this option
helps 3rd party drivers update to newer kernel versions if the symbol
checksums match from the symbol list the driver needs in the kernel.
Fedora normally is not interested in 3rd party drivers. I am not going to
ask Fedora to start being interested either. :-)
My reason for enabling this is really to help with RHEL technology. RHEL
does support 3rd party drivers for business reasons. Having better support
in Fedora for 3rd party drivers helps us iron out some of our technology
in this area.
As a bonus, it does help make sure existing Fedora 3rd party drivers don't
accidentally get loaded with the wrong kernel version. This gets blocked at
load time and can help prevent various panics. Though Fedora traditionally
closes such bugs anyway.
Signed-off-by: Don Zickus <dzickus(a)redhat.com>
diff --git a/config-generic b/config-generic
index 7444895..e0e9387 100644
--- a/config-generic
+++ b/config-generic
@@ -91,7 +91,7 @@ CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_LOAD is not set
# -- MODULE_FORCE_UNLOAD is controlled by config-debug/nodebug
-# CONFIG_MODVERSIONS is not set
+CONFIG_MODVERSIONS=y
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_PCI=y
7 years
arm64: F26 vs F25 kernel config for 4.9 (48-bit VA)
by Jon Masters
Hi Folks,
A quick reminder that, while 48-bit VA is enabled in rawhide/26:
commit c0f22caded1d549e532d2ab3ce767f8f3d2206f8
Author: Peter Robinson <pbrobinson(a)gmail.com>
Date: Mon Oct 31 15:45:58 2016 +0000
arm64: Enable 48bit VA
Care should be taken to ensure this doesn't get accidentally pulled in
when F25 rebases later on. Userspace isn't ready for it there. Folks
know this, but we're on an internal RH call and someone asked that we
specifically call this out to make sure everyone knows.
Thanks,
Jon.
--
Computer Architect | Sent from my Fedora powered laptop
7 years
loading early microcode in every core?
by Felix Miata
I ask about this on account of boot delays reported in the following:
http://www.spinics.net/lists/linux-initramfs/msg04173.html
http://www.spinics.net/lists/linux-initramfs/msg04175.html
http://www.spinics.net/lists/linux-initramfs/msg04275.html
I was looking at early portions of dmesg for anything resembling clues and
noticed that early microcode messages are not always reported for every core
present. Here are examples of 'dmesg | grep croco', all taken from machines
with two cpu cores. Notice that some refer to two different cores, while
others make no mention of the existence of more than one core:
Linux big31 4.7.4-200.fc24.x86_64 #1 SMP Thu Sep 15 18:42:09 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.835393] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[ 0.840090] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.8-200.fc24.x86_64 #1 SMP Tue Nov 15 19:41:51 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.851345] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc8.git0.1.fc25.x86_64 #1 SMP Mon Sep 26 17:12:24 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.830256] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.8-300.fc25.x86_64 #1 SMP Tue Nov 15 18:10:06 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.601683] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc1.git3.1.fc26.x86_64 #1 SMP Thu Aug 11 01:00:58 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 1.157172] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.8.0-0.rc8.git1.1.fc26.x86_64 #1 SMP Wed Sep 28 23:21:40 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.965454] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big31 4.9.0-0.rc5.git4.1.fc26.x86_64 #1 SMP Fri Nov 18 17:52:58 UTC
2016 x86_64 x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 1.146158] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Linux big41 4.6.5-300.fc24.x86_64 #1 SMP Thu Jul 28 01:10:12 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.716008] microcode: CPU0 sig=0x1067a, pf=0x1, revision=0xa0b
[ 0.716801] microcode: CPU1 sig=0x1067a, pf=0x1, revision=0xa0b
Linux big41 4.8.7-200.fc24.x86_64 #1 SMP Fri Nov 11 15:44:18 UTC 2016 x86_64
x86_64 x86_64 GNU/Linux
[ 0.000000] microcode: microcode updated early to revision 0xa0b, date =
2010-09-28
[ 0.617156] microcode: sig=0x1067a, pf=0x1, revision=0xa0b
Is it possible that the varying reference or not to CPUx is indicative of
some kind of installation mishandling lurking in microcode installation,
possibly causing microcode to be installed in only one of the two cores,
which could be at root of or affecting the boot initialization delay
described in my linux-initramfs posts? If so, should I file a bug? If yes, in
which tracker, and against which component (kernel? dracut? microcode_ctl?
other?).
--
"The wise are known for their understanding, and pleasant
words are persuasive." Proverbs 16:21 (New Living Translation)
Team OS/2 ** Reg. Linux User #211409 ** a11y rocks!
Felix Miata *** http://fm.no-ip.com/
7 years
power management VT / versus GUI
by Reindl Harald
CTRL+ALT+F2 and the message below appears every 5 seconds on the VT and
in the syslog while when running the dsiplaymanager or GUI all is fine
over days
*what* does the kernel here?
nobody is taking away the mouse and it's working perfect on the GUI
Nov 21 08:59:47 srv-rhsoft kernel: usb 1-1.6: USB disconnect, device
number 9
Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: new low-speed USB device
number 13 using ehci-pci
Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: New USB device found,
idVendor=046d, idProduct=c077
Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: New USB device strings:
Mfr=1, Product=2, SerialNumber=0
Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: Product: USB Optical Mouse
Nov 21 08:59:49 srv-rhsoft kernel: usb 1-1.6: Manufacturer: Logitech
Nov 21 08:59:49 srv-rhsoft kernel: input: Logitech USB Optical Mouse as
/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6/1-1.6:1.0/0003:046D:C077.0009/input/input19
Nov 21 08:59:49 srv-rhsoft kernel: hid-generic 0003:046D:C077.0009:
input,hidraw0: USB HID v1.11 Mouse [Logitech USB Optical Mouse] on
usb-0000:00:1a.0-1.6/input0
Nov 21 08:59:49 srv-rhsoft mtp-probe: checking bus 1, device 13:
"/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.6"
Nov 21 08:59:49 srv-rhsoft mtp-probe: bus: 1, device: 13 was not an MTP
device
7 years
[PATCH 0/2] Add support for tablet mode on the X1 Yoga (2016)
by Lyude
Backport of some patches currently waiting to get accepted upstream, adds
support for detecting tablet mode properly on the X1 Yoga.
Lyude (2):
thinkpad_acpi: Move tablet detection into separate function
thinkpad_acpi: Add support for X1 Yoga (2016) Tablet Mode
Documentation/laptops/thinkpad-acpi.txt | 1 +
drivers/platform/x86/thinkpad_acpi.c | 89 ++++++++++++++++++++++++++-------
2 files changed, 72 insertions(+), 18 deletions(-)
--
2.7.4
7 years
[PATCH] set z10 as minimum architecture level for s390x
by Dan Horák
---
config-s390x | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/config-s390x b/config-s390x
index 5368c01..8923379 100644
--- a/config-s390x
+++ b/config-s390x
@@ -1,7 +1,5 @@
CONFIG_64BIT=y
-# CONFIG_MARCH_Z900 is not set
-CONFIG_MARCH_Z9_109=y
-# CONFIG_MARCH_Z990 is not set
+CONFIG_MARCH_Z10=y
CONFIG_NR_CPUS=64
CONFIG_COMPAT=y
--
2.7.4
7 years
[PATCH 0/5] Cleanups of kernel.spec
by Paul Bolle
This small series contains five cleanups to kernel.spec. The basic theme is the
way we run "make *config" targets on our .config files.
(There was talk, recently, of generating these .config files differently. I do
not know what happenend there. But this series only touches kernel.spec once we
already have .config files, so that's another stage in our build.)
This was only tested for x64_64 on a branch based of f24. It does apply cleanly
to master. A run on the build farms (of which I know nothing) might uncover
bugs in areas my testing didn't cover. I hope it doesn't.
Paul Bolle (5):
Run oldnoconfig make targets silently
Run make listnewconfig only if listnewconfig_fail is set
Only run listnewconfig and oldnoconfig for one arch
Replace 'all_x86' with 'x86_32'
Remove references to (31 bits) s390
kernel.spec | 21 ++++++++++++---------
1 file changed, 12 insertions(+), 9 deletions(-)
--
2.7.4
7 years
[PATCH] Enable flex file support in the NFS server
by Steve Dickson
The upstream commit 9b9960a0c introduced
simple flex file server which enables the
testing of the flex client.
This patch enables the support to be on
by default but the 'pnfs' exports option
is still needed to active the code.
Signed-off-by: Steve Dickson <steved(a)redhat.com>
---
config-generic | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/config-generic b/config-generic
index 42b48fc..e127a40 100644
--- a/config-generic
+++ b/config-generic
@@ -4780,8 +4780,7 @@ CONFIG_NFSD_PNFS=y
CONFIG_NFSD_BLOCKLAYOUT=y
CONFIG_NFSD_SCSILAYOUT=y
CONFIG_NFSD_V4_SECURITY_LABEL=y
-# This is labeled as 'bare minimum' and 'not for production'
-# CONFIG_NFSD_FLEXFILELAYOUT is not set
+CONFIG_NFSD_FLEXFILELAYOUT=y
CONFIG_NFS_FSCACHE=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_PNFS_OBJLAYOUT=m
--
2.7.4
7 years
[PATCH] NFSv4.1 Server BUGs out.
by Steve Dickson
This patch is needed to stop the rawhide NFS server
from oopsing on v4.1 mounts. Found during the
flex file layout work but the oops happens
on all v4.1 mounts.
The patch is making its way upstream
J. Bruce Fields (1):
sunrpc: don't pass on-stack memory to sg_set_buf
net/sunrpc/auth_gss/auth_gss.c | 13 ++++--
net/sunrpc/auth_gss/gss_krb5_crypto.c | 82 +++++++++++++++++++--------------
net/sunrpc/auth_gss/svcauth_gss.c | 21 ++++++---
3 files changed, 71 insertions(+), 45 deletions(-)
7 years