microcode and suspend
by Chris Murphy
[root@f27h firmware]# journalctl -b | grep -i microcode
Jan 08 16:43:48 f27h.localdomain kernel: microcode: sig=0x406e3,
pf=0x80, revision=0xbe
Jan 08 16:43:48 f27h.localdomain kernel: microcode: Microcode Update
Driver: v2.2.
Jan 09 10:30:45 f27h.localdomain kernel: microcode: microcode updated
early to revision 0xba, date = 2017-04-09
Jan 09 10:30:45 f27h.localdomain kernel: microcode: sig=0x406e3,
pf=0x80, revision=0xba
[root@f27h firmware]#
This looks like a newer version 0xbe, is applied during boot. But upon
wake from suspend to RAM, I get older version 0xba. Is this a correct
interpretation and is it expected?
--
Chris Murphy
6 years, 3 months
adv7511, hikey and commit 8221dd34f
by Jeremy Linton
Hi,
It seems that commit 8221dd34f turned off CONFIG_DRM_I2C_ADV7511. That
is the HDMI transmitter used on the 96boards hikey. The result is that
the framebuffer no longer works..
Can we get that config option enabled for just aarch64?
(I can submit a bug/patch/whatever if that is easier than this bug report).
Thanks,
6 years, 3 months
RFC: Moving kernel-tools out of kernel.spec
by Laura Abbott
Like all good bits of software, the kernel.spec has grown over time.
Part of this growth has come from building more of the userspace
tools that live under the tools directory of the kernel. I've been
experimenting with moving these to a separate spec file.
Advantages:
- Less stuff in the kernel.spec file (~300 line deletion)
- Fewer build deps for things like perf
- People building the kernel only get the kernel
- Issues with userspace tools don't impact the kernel
- Can likely drop most of the debuginfo regex nightmare for the userspace packages
Disadvantages:
- Would need to manually keep in sync on some cadence. This is mostly
an issue for rawhide. Could we actually get away with only re-building
on each new kernel version or do we need to resync on each -rc?
- Would probably need to rework how tools are tied to kernel versions at
the package level
- Others added here
I've experimented with something at https://pagure.io/kernel-tools-pkggit
which is mostly a copy/paste of parts of the kernel.spec file. I'm
mostly looking for general feedback about if this a good idea but
I'm also interested in specific feedback if you have it.
Thanks,
Laura
6 years, 3 months
Fix for rhbz #1409801
by Shaun Assam
Hello Kernel Maintainers,
I would like to submit a fix for bug #1409801 regarding the ethernet
adapter not working on Dell Latitude 3350 (https://bugzilla.redhat.com/
show_bug.cgi?id=1409801). This issue is only related to the Fedora
kernels from 4.4+, and does not affect the upstream kernels used by
other distributions like Ubuntu or Arch.
This issue can be resolved by turning on the ACPI_REV_OVERRIDE option
in the kernel config files for i686 and x86_64. Currently the
configuration is set to:
# CONFIG_ACPI_REV_OVERRIDE_POSSIBLE is not set
By changing it to:
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
The following boot errors no longer occur:
[ 1.972457] pci 0000:00:1c.2: Error enabling bridge (-16),
continuing
[ 1.973304] r8169 0000:03:00.0 (unnamed net_device) (uninitialized):
enable failure
In addition to fixing the ethernet issue, it also fixes an issue with
the Bluetooth device on the laptop automatically switching on after
shutdown/reboot (not when resuming from sleep/hibernate). The Bluetooth
icon would appear in the GNOME System Menu and would have to manually
be turned off. Since applying the ACPI_REV fix, this is no longer a
problem. I have been testing this change for the last three days and
have not encountered any issues resulting from this fix.
The issue regarding this bug has been patched in the upstream kernel
for sometime and is already included in the code for current versions
of the Fedora kernel (see drivers/acpi/blacklist.c for details -- the
code applies to Dell laptops/computers).
I would like to request this fix be included in future Fedora kernel
releases so we may close this bug and possibly fix other, opened, bugs
related to this configuration. I have attached the config files to this
email for your convenience (around line 75).
Regards,
Shaun Assam
6 years, 3 months
Current specfile misapplies v4.14.10 stable update for fc26
by Paul Bolle
0) The v4.14.10 stable updates adds a new executable (tools/objtool/sync-
check.sh). Somehow this was added non-executable during my local build of
v4.14.10 (on fc26, that is). This made the build fail:
[...]
+ make -s ARCH=x86_64 V=1 -j4 bzImage
make[2]: execvp: ./sync-check.sh: Permission denied
make[2]: *** [Makefile:49: [...]/BUILD/kernel-4.14.fc26/linux-4.14.10-1.local0.fc26.x86_64/tools/objtool/objtool] Error 127
make[1]: *** [Makefile:62: objtool] Error 2
make: *** [Makefile:1623: tools/objtool] Error 2
make: *** Waiting for unfinished jobs....
error: Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.fTUkoT (%build)
Anybody else seeing this?
1) Switching the specfile from patch to "git apply" seems to do the right
thing. This is what I tried:
diff --git a/kernel.spec b/kernel.spec
index 965345c2a26e..b2a1ffbe843d 100644
--- a/kernel.spec
+++ b/kernel.spec
@@ -1267,8 +1267,9 @@ fi
# released_kernel with possible stable updates
%if 0%{?stable_base}
# This is special because the kernel spec is hell and nothing is consistent
-xzcat %{SOURCE5000} | patch -p1 -F1 -s
-git commit -a -m "Stable update"
+xzcat %{SOURCE5000} | git apply -
+git add -A
+git commit -m "Stable update"
%endif
# Drop some necessary files from the source dir into the buildroot
2) Would it make sense to further gitify the specfile and move from patch to
"git apply" here (and a few other places)? Or should we expect patch to do the
right thing? (In the latter case I guess I might have to report a bug against
patch.)
Thanks,
Paul Bolle
6 years, 3 months
KPTI and Fedora
by Laura Abbott
Hi,
You may have seen discussion about kernel page table isolation (KPTI)
https://lwn.net/Articles/742404/. These patches are now in the -rc6
kernel which is currently building for rawhide. I turned on the
feature as it's had a good amount of testing and review by now.
Some patches are also queued up for 4.14 so these will be
trickling into F26 and F27 as well per the usual stable cycle.
As always, please report bugs if you find them and let us know
if you have any questions.
Happy New Year!
Laura
6 years, 3 months
