[patch rawhide kernel] config: Enable Mellanox mlxsw driver
by Jiri Pirko
This patch just simply enables mlxsw driver in Fedora Rawhide kernel.
This driver was introduced in 4.4.
Signed-off-by: Jiri Pirko <jiri(a)resnulli.us>
---
config-generic | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/config-generic b/config-generic
index e4f0a11..2830de7 100644
--- a/config-generic
+++ b/config-generic
@@ -1706,7 +1706,11 @@ CONFIG_MLX4_INFINIBAND=m
CONFIG_MLX5_CORE=m
CONFIG_MLX5_CORE_EN=y
CONFIG_MLX5_INFINIBAND=m
-# CONFIG_MLXSW_CORE is not set
+CONFIG_MLXSW_CORE=m
+CONFIG_MLXSW_CORE_HWMON=y
+CONFIG_MLXSW_PCI=m
+CONFIG_MLXSW_SWITCHX2=m
+CONFIG_MLXSW_SPECTRUM=m
# CONFIG_MLX4_DEBUG is not set
# CONFIG_SFC is not set
--
2.4.3
7 years, 4 months
Building a kernel
by Michael Hill
Since the last version of Fedlet came out, I've been building a kernel
package on my Baytrail tablet from the fc24 source rpm following these
instructions:
https://fedoraproject.org/wiki/Building_a_custom_kernel
This worked for a number of 4.2 kernels as well as a couple of 4.4 rc
kernels. On or about rc6 and continuing with 4.4.0-1, I've been
running this step:
rpmbuild -bb --with baseonly --without debuginfo --target=i686 kernel.spec
...and (after the patches are applied), failing like this:
Applying: i2c: designware: Convert to use unified device property API
Applying: drm/udl: Use unlocked gem unreferencing
+ chmod +x scripts/checkpatch.pl
+ touch .scmversion
+ mkdir configs
+ for i in '*.config'
+ mv kernel-4.4.0-aarch64.config .config
++ head -1 .config
++ cut -b 3-
+ Arch=arm64
+ grep -E '^CONFIG_'
+ make ARCH=arm64 listnewconfig
+ '[' -s .newoptions ']'
+ cat .newoptions
CONFIG_CM3218X
+ exit 1
error: Bad exit status from /var/tmp/rpm-tmp.niuQ3f (%prep)
RPM build errors:
Bad exit status from /var/tmp/rpm-tmp.niuQ3f (%prep)
a. Is there something obvious I can fix?
b. Is there a better place to ask?
Thanks,
Mike
7 years, 4 months
unsubscribe
by 杨 立明
unsubscribe
________________________________
yanglm488(a)hotmail.com
7 years, 4 months
kernel testing app questions
by Chris Murphy
Hi,
Starting here: http://fedoraproject.org/wiki/KernelRegressionTestGuidelines I grab the current test from git and run as root 'sh runtests.sh -t stress' and I experience the following, each of which is confusing so I don't know if it's expected behavior, or a bug, or what to do with this information if anything. The kernel is 4.4.0-1.fc24.x86_64, on otherwise updated Fedora 23 systems (an old Mac and a new NUC).
1. One system, dropcaches fails non-deterministically. I can't tell what the pattern is. When it fails the log reports:
Starting test ./default/cachedrop
100+0 records in
100+0 records out
104857600 bytes (105 MB) copied, 0.0516614 s, 2.0 GB/s
10+0 records in
10+0 records out
10485760 bytes (10 MB) copied, 0.00891013 s, 1.2 GB/s
TestError: Can't free dentries and inodes and pagecache
484736 484724
Could not run tests
2. The sysfs-perms test always fails on both systems:
Starting test ./default/sysfs-perms
Found world-writable files in sysfs.
./runtest.sh: line 9: ignore-files.sh: command not found
3. There are quit a few selinux AVC denials during the selinux DAC test, but at about the same time I also see these segfaults. Are they expected?
[128460.313903] anonmap[12806]: segfault at 7fabf1da4000 ip 00007fabf1da4000 sp 00007fff3ab17538 error 15
[128460.936435] execbss[12811]: segfault at 6020b0 ip 00000000006020b0 sp 00007fffaeade218 error 15 in execbss[602000+1000]
[128461.135687] execdata[12819]: segfault at 6020a0 ip 00000000006020a0 sp 00007ffecc006378 error 15 in execdata[602000+1000]
[128461.309108] execheap[12827]: segfault at eea130 ip 0000000000eea130 sp 00007ffe8f2f9ae8 error 15
[128461.502195] execstack[12835]: segfault at 7fff102b3810 ip 00007fff102b3810 sp 00007fff102b3808 error 15
[128461.701582] shlibbss[12840]: segfault at 7f0b168a4060 ip 00007f0b168a4060 sp 00007ffc0c983188 error 15 in shlibtest2.so[7f0b168a3000+2000]
[128461.903294] shlibdata[12846]: segfault at 7f3c0ae25040 ip 00007f3c0ae25040 sp 00007ffd7752ee38 error 15 in shlibtest2.so[7f3c0ae25000+2000]
[128462.192413] mprotheap[12862]: segfault at 2555130 ip 0000000002555130 sp 00007ffd64752c88 error 15
4. The stress test log file on both systems is 95M and the upload page won't accept that, so I take it only the minimal and default tests are uploadable and the stress test isn't something that's really interesting to the kernel team? The browser message when trying to upload is: Request Entity Too Large The data value transmitted exceeds the capacity limit. Even if it's bzip'd, it's 3+MB and that's still too big for the web interface.
5. fedora_submit.py fails:
[chris@f23m kernel-tests]$ python fedora_submit.py -u chrismurphy -p pw -l logs/kernel-test-1452835548.log.txt
Traceback (most recent call last):
File "fedora_submit.py", line 45, in <module>
password=password
File "/usr/lib/python2.7/site-packages/fedora/client/openidbaseclient.py", line 283, in login
openid_insecure=self.openid_insecure)
File "/usr/lib/python2.7/site-packages/fedora/client/openidproxyclient.py", line 138, in openid_login
raise AuthError(output['message'])
fedora.client.AuthError: Authentication failed
No idea what to do with that. Uploading this file (default sized) through the web interface does work.
6. Both systems skip the module signing test.
Starting test ./default/modsign
Module signing not enabled
Could not run tests
This makes sense on the EFI system that doesn't support secure boot, but the other one does.
$ mokutil --sb-state
SecureBoot enabled
So... why is module signing not enabled?
7. The -t stress option, testing hasn't completed after 15+ hours on both systems, and both were unresponsive to local and remote login so I ended up hard resetting them. How long should it run and are there some tests where it's expected the system is unresponsive for more than an hour at a time?
For one machine, the kernel-test log modification time was ~ 6 hours older than the time of the hard reset, so the system may have just locked up. Both journals are unrevealing, they lack any entries for those last 6 or more hours (I'm somewhat regularly hitting bug 1295612, so I've started running rsyslog as of today to see if it'll write out what's either not written to the journal or is getting corrupted and can't be viewed by journalctl). The last 10 lines of one kernel-test log look like this:
ipcrm -m 720896
ipcrm -m 229377
ipcrm -m 917510
ipcrm -m 720896
ipcrm -m 229377
ipcrm -m 917510
ipc_str complete
ipcrm -m 720896
ipcrm -m 229377
ipcrm -m 917510
Thanks,
Chris Murphy
7 years, 4 months
kernel-tests master: Fix modsign test (366cb1a)
by Justin Forbes
Repository : http://git.fedorahosted.org/cgit/kernel-tests.git
On branch : master
>---------------------------------------------------------------
commit 366cb1abea36a5c2d0ea1f0a9fa3e5ab41742aa1
Author: Justin M. Forbes <jforbes(a)redhat.com>
Date: Fri Jan 15 23:02:49 2016 -0600
Fix modsign test
>---------------------------------------------------------------
default/modsign/modsign_tests.sh | 11 ++++++-----
1 files changed, 6 insertions(+), 5 deletions(-)
diff --git a/default/modsign/modsign_tests.sh b/default/modsign/modsign_tests.sh
index b0bab67..750e045 100755
--- a/default/modsign/modsign_tests.sh
+++ b/default/modsign/modsign_tests.sh
@@ -7,8 +7,8 @@ modsign_check_modules()
# Grab a module to mess around with. We'll pick one that is fairly
# stand-alone and rarely used.
- cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko .
-
+ cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz .
+ xz -d minix.ko.xz
# Make sure we have the signed module marker
cat ./minix.ko | strings | grep "~Module signature appended~" &> /dev/null
if [ "$?" -ne "0" ]
@@ -59,7 +59,8 @@ modsign_unsigned()
{
# Grab a module to mess around with. We'll pick one that is fairly
# stand-alone and rarely used.
- cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko .
+ cp /lib/modules/`uname -r`/kernel/fs/minix/minix.ko.xz .
+ xz -d minix.ko.xz
strip -g ./minix.ko
# Make sure it isn't already loaded
@@ -109,13 +110,13 @@ modsign_third_party()
modsign=0
if [ -f /proc/keys ]
then
- cat /proc/keys | grep module_sign &> /dev/null
+ cat /proc/keys | grep system_keyring &> /dev/null
if [ $? -ne "0" ]
then
echo Module signing not enabled
exit 3
fi
- keyring=`cat /proc/keys | grep module_sign | cut -f 1 -d " "`
+ keyring=`cat /proc/keys | grep system_keyring | cut -f 1 -d " "`
keyctl list 0x${keyring} | grep "Fedora kernel signing key" &> /dev/null
if [ $? == "0" ]
then
7 years, 4 months
Tweaks to kernel core modules filtering
by Peter Robinson
Hi All,
This is a small series of changes to the filtering of kernel modules from core. Each patch is a mostly self contained subject like usb/drm/network protocols. I split them out to separate patches just to make each one easier to see the bits that were changing.
Peter
7 years, 4 months
[PATCH] Disable deprecated rfkill-input driver
by Bastien Nocera
From: Bastien Nocera <hadess(a)hadess.net>
As noted in https://www.kernel.org/doc/Documentation/rfkill.txt
rfkill-input is deprecated, and rfkill keys are handled in user-space.
---
config-generic | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/config-generic b/config-generic
index 055d5d2..cbe4571 100644
--- a/config-generic
+++ b/config-generic
@@ -1381,7 +1381,7 @@ CONFIG_LWTUNNEL=y
CONFIG_RFKILL=m
CONFIG_RFKILL_GPIO=m
-CONFIG_RFKILL_INPUT=y
+CONFIG_RFKILL_INPUT=n
CONFIG_ETHERNET=y
--
2.5.0
7 years, 4 months
Re: [PATCH] Disable deprecated rfkill-input driver
by Josh Boyer
On Mon, Jan 11, 2016 at 8:02 PM, Bastien Nocera <hadess(a)hadess.net> wrote:
> On Mon, 2016-01-11 at 14:21 -0500, Josh Boyer wrote:
>> On Sun, Jan 10, 2016 at 7:54 AM, Bastien Nocera <bnocera(a)redhat.com>
>> wrote:
>> > From: Bastien Nocera <hadess(a)hadess.net>
>> >
>> > As noted in https://www.kernel.org/doc/Documentation/rfkill.txt
>> > rfkill-input is deprecated, and rfkill keys are handled in user-
>> > space.
>>
>> That may be what the document says, but the Kconfig at least seems to
>> imply something else.
>
> What says that in the Kconfig?
The fact that disabling it is still enforced behind CONFIG_EXPERT
upstream. It's certainly likely that people are terrible at cleaning
up and it should have been done long ago, but it wasn't.
> This is the relevant commit which explains what rfkill-input is used
> for (basically, if you don't have a desktop environment and you still
> want the keys to work):
>
> commit c64fb01627e24725d1f9d535e4426475a4415753
> Author: Johannes Berg <johannes(a)sipsolutions.net>
> Date: Tue Jun 2 13:01:38 2009 +0200
>
> rfkill: create useful userspace interface
>
> The new code added by this patch will make rfkill create
> a misc character device /dev/rfkill that userspace can use
> to control rfkill soft blocks and get status of devices as
> well as events when the status changes.
>
> Using it is very simple -- when you open it you can read
> a number of times to get the initial state, and every
> further read blocks (you can poll) on getting the next
> event from the kernel. The same structure you read is
> also used when writing to it to change the soft block of
> a given device, all devices of a given type, or all
> devices.
>
> This also makes CONFIG_RFKILL_INPUT selectable again in
> order to be able to test without it present since its
> functionality can now be replaced by userspace entirely
> and distros and users may not want the input part of
> rfkill interfering with their userspace code. We will
> also write a userspace daemon to handle all that and
> consequently add the input code to the feature removal
> schedule.
The feature removal schedule doesn't exist anymore and hasn't for a
number of years. Even if it did, the feature is clearly not removed.
Out of curiosity, which daemon(s) handle the "new" interface?
> In order to have rfkilld support both kernels with and
> without CONFIG_RFKILL_INPUT (or new kernels after its
> eventual removal) we also add an ioctl (that only exists
> if rfkill-input is present) to disable rfkill-input.
> It is not very efficient, but at least gives the correct
> behaviour in all cases.
>
> Signed-off-by: Johannes Berg <johannes(a)sipsolutions.net>
> Acked-by: Marcel Holtmann <marcel(a)holtmann.org>
> Signed-off-by: John W. Linville <linville(a)tuxdriver.com>
>
> Does it really make sense to cater for that use?
No. I don't really care either way. But did you even read the rest
of my original email? I can't turn it off without turning on
CONFIG_EXPERT, and I'm not going to do that. Also, did you test your
patch on e.g. Fedora Workstation?
So perhaps pursue dropping that requirement upstream, or just deleting
the whole thing entirely. It was originally scheduled to be removed
in 2.6.33, which was 6 years ago.
josh
7 years, 4 months
Re: Policy for driver backports?
by Josh Boyer
Adding the kernel list on CC because this is a good question and
there's no reason to not answer a broader number of people.
On Thu, Jan 7, 2016 at 3:17 PM, Andrew Lutomirski <andy(a)luto.us> wrote:
> Other than the bug I filed, 4.3 is missing two things for full Dell Skylake
> support:
>
> The Broadcom driver, available in 4.4, needed for WiFi on some models.
Have to think about this. We tend to avoid full driver backports and
4.4.y will be released fairly soon. I don't believe 4.3 will live
very long in F23, perhaps a month at most so doing a full backport
might not be worthwhile.
> The intel-hid driver, queued for 4.5, needed for the WiFi button on all
> models.
Similar answer. We'd be more likely to backport it to 4.4 than 4.3.
And in both this and the above case, it would probably have to go into
rawhide and live there for a while to get some testing.
> I don't know about the former, but the latter is self-contained and trivial
> to backport. What's your/Fedora's opinion on driver backports?
So we have no fast and hard rules, but as I said we tend to avoid full
driver backports. Feature additions to existing driver and bugfixes
are much easier to carry. In either case, the code needs to be
upstream or very clearly headed there in a not distant release. It's
probably best to think of our approach as a slightly less restrictive
version of the upstream stable process. We'll occasionally take
things from trees other than Linus' but only if it looks like it is
heading there soon anyway.
And we reserve the right to break our own approach :).
> There are also some pending dell-wmi fixes, but they fix warnings instead of
> adding missing functionality.
There's been some back and forth on those IIRC. Probably not worth
grabbing for 4.3 at this point.
josh
7 years, 5 months