openSUSE Kernel August 2014

kernel@lists.opensuse.org

28 participants
20 discussions

[opensuse-kernel] Keep 3.11.y kernel for openSUSE 13.1 updates?

by Takashi Iwai

Hi, Since 3.11.y maintenance was discontinued by Greg, Ubuntu took over it. It made me wonder: are we willing to continue 3.11.y for openSUSE 13.1 updates, just relying on Ubuntu? Or, can we just move on 3.12.y? Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 10 months

[opensuse-kernel] Factory -> Rolling releases: What does it mean for the kernel package?

by Jeff Mahoney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi folks - The openSUSE team recently announced[1] that openSUSE Factory is moving to a rolling development model, similar to how Tumbleweed has functioned for some time. I think this will do wonders for the stability of Factory and hopefully make it interesting again for those of us who used to sync nightly and zypper dup first thing every morning. It does bring a few questions with it, though. How do we handle the kernel with a rolling release? Having multiple outstanding versions isn't an issue unique to the kernel, but few other projects are as large and have as much churn between releases. The folks trying to support the kernel as best we can are short on time as it is, so I'm concerned about establishing parameters for which bug reports will be considered valid[2]. I'd like to define what those are so that anyone going through bug reports (even someone not actively involved in kernel development or maintenance) and see which ones can be closed or, at least, put on hold until they've been reproduced with the latest version. 1) How do we handle releases of the Factory kernel? 2) What releases will be considered "supported" simultaneously? For 1), I propose we make it official that Kernel:stable is now the external repository for openSUSE Factory. Even though Factory has already been pulling from Kernel:stable, making it an official thing means that security fixes and other backports are actively added to it rather than it being Jiri's side project. Factory would only contain point releases moving forward and release candidates would be confined to Kernel:HEAD. As a result of the change, I'd start adding -rc1 updates to Kernel:HEAD rather than waiting until -rc2 as I have in the past. It also means that there would no longer be a delay for things like Xen and ARM in Factory. As for 2), I'd like to hear suggestions. With only so much time to devote to supporting the Factory kernel, we'll need to find a balance between convenience for users and bugs actually getting fixed. We have options between supporting every release (which I would actively fight) and dropping support for any previous kernel as soon as a new one is added to the repository. I've added some interested parties to the CC list, but I'd like to hear from anyone with an opinion. Related to 2, I'd like to put more effort into trimming down the number of patches we carry in the openSUSE kernel. Over the years, we've done a pretty good job of that (compare the number of patches in a SLES release vs openSUSE), but we can do more. SUSE has already hired several engineers to work on getting our divergent Xen implementation into something that is mergeable upstream. Once that happens, the openSUSE kernel patchset should only contain security/stability backports. - -Jeff [1] https://news.opensuse.org/2014/07/29/factory-rolling-release/#more-18251 [2] I'll be the first to admit we're open to criticism in how fast openSUSE bugs are handled already - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT2lNmAAoJEB57S2MheeWyBw0P/iwhsLnc9IECJ3dGc6DylTEN M3DCvT5LsWajXZ1PrKpByww4ZeMKCiYKf7Y4Jo6Jd864ipZ5mFGviCkm5x9Q7sI+ 5qX9izy742kdlgQyFM3v+AYqtz+CVlzKwcHa1GTjLq5nOycxr6G6UWw6StD3FVoy r/a1wQUzRj0Y/ypwqtF0F4Mifbt+JATHutDJsfSmbyJlhB8nF+nYCTQKrmDV9zVZ Qekm5zzns4OwG3cL82vp5x1Mj8gr86/TwiO/DY3D7U/Dcv8m7izRLSSpRHkkuKtL VutxMXgbrZ5ga2c8ocatTj1e2Ntw1c8sLCzKJ6ubuXXCBQJ4z3eXQayliHiXExBJ yfThxnK49rD7CNEL6LhKdAaiJFEwudopmy2gEClOQV9xrFhrCBUuM5Ml7VBD2xTD d8k73OgxzpXA3UCwc7omR4DS1I1QfyxQaPRfXFi8kdywWe6gNmkmITst7gAdyjmi XjOM0O9jqBgi6TcXsxF+RiS2vxtR330aZty7VrlCu4+n4jzD4fk0FXL7u7pNmW2D n9/m33yq9cyxUeS3+ERq5hCojztTaqrs9sky1+BwdHeonCBAkpwvCKyoO8FhnM4k fZpF7eVNYBL8TZfhJ4YBXw/TRvWjqataI7RfzLdpiYxuBiluhuRBFJxs5d0t9Na1 vJpQbJP6jRTsuJnA7Zk1 =+cb1 -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 10 months

[opensuse-kernel] YAMA

by Richard Weinberger

Hi! I'd like to see the YAMA security LSM enabled on openSUSE kernels. Especially the ptrace() restrictions are very valuable IMHO. Using SECURITY_YAMA_STACKED it can be used in combination with Apparmor. Or is there a specific reason why it is not enabled on openSUSE? Thanks, //richard -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 10 months

[opensuse-kernel] i810 segfault starting server

by Felix Miata

Factory with kernel 3.16.0, server 1.16.0 and driver 2.99.914 segfaults. Factory with kernel 3.16.0, server 1.16.0 and driver 3.0.0git-199 (BS:sumski) is OK. The 3git driver was known on the intel-gfx mailing list to have fixed the problem more than 3 months ago. Why is such an old and known broken intel driver still in Factory? I don't see any open bug about getting Factory past 2.99. Is a new bug needed here? -- "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/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 10 months

[opensuse-kernel] [PATCH] config: armv7hl/default: Disable pcie-spear13xx and gpio-zynq

by Matwey V. Kornilov

From: "Matwey V. Kornilov" <matwey.kornilov(a)gmail.com> This is for master (Kernel:HEAD) to fix build: [30000s] ERROR: "dw_pcie_host_init" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_handle_msi_irq" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_pcie_msi_init" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_pcie_cfg_write" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_pcie_cfg_read" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_pcie_setup_rc" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30000s] ERROR: "dw_pcie_link_up" [drivers/pci/host/pcie-spear13xx.ko] undefined! [30003s] ERROR: "handle_fasteoi_irq" [drivers/gpio/gpio-zynq.ko] undefined! Signed-off-by: Matwey V. Kornilov <matwey.kornilov(a)gmail.com> --- However, the fix is trivial for zynq, after it will be fixed in upstream (I am testing the patch) it would be reenabled. config/armv7hl/default | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/config/armv7hl/default b/config/armv7hl/default index ff8833e..71ae044 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -682,7 +682,7 @@ CONFIG_PCI_TEGRA=y # CONFIG_PCI_RCAR_GEN2 is not set # CONFIG_PCI_RCAR_GEN2_PCIE is not set CONFIG_PCI_HOST_GENERIC=y -CONFIG_PCIE_SPEAR13XX=m +# CONFIG_PCIE_SPEAR13XX is not set CONFIG_PCIEPORTBUS=y CONFIG_PCIEAER=y # CONFIG_PCIE_ECRC is not set @@ -3607,7 +3607,7 @@ CONFIG_GPIO_RCAR=m CONFIG_GPIO_SPEAR_SPICS=y CONFIG_GPIO_SYSCON=m CONFIG_GPIO_XILINX=y -CONFIG_GPIO_ZYNQ=m +# CONFIG_GPIO_ZYNQ is not set # CONFIG_GPIO_VX855 is not set CONFIG_GPIO_GRGPIO=m -- 1.8.1.4 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 10 months

[opensuse-kernel] [PATCH] config: arm64/default: reenable ARM64_CRYPTO

by Andreas Schwab

--- config/arm64/default | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/config/arm64/default b/config/arm64/default index fc94d66..5af7171 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -4796,6 +4796,7 @@ CONFIG_CRYPTO_WORKQUEUE=y CONFIG_CRYPTO_CRYPTD=m CONFIG_CRYPTO_AUTHENC=m # CONFIG_CRYPTO_TEST is not set +CONFIG_CRYPTO_ABLK_HELPER=m # # Authenticated Encryption with Associated Data @@ -4897,7 +4898,14 @@ CONFIG_PUBLIC_KEY_ALGO_RSA=m CONFIG_X509_CERTIFICATE_PARSER=m CONFIG_PKCS7_MESSAGE_PARSER=m # CONFIG_PKCS7_TEST_KEY is not set -# CONFIG_ARM64_CRYPTO is not set +CONFIG_ARM64_CRYPTO=y +CONFIG_CRYPTO_SHA1_ARM64_CE=m +CONFIG_CRYPTO_SHA2_ARM64_CE=m +CONFIG_CRYPTO_GHASH_ARM64_CE=m +CONFIG_CRYPTO_AES_ARM64_CE=m +CONFIG_CRYPTO_AES_ARM64_CE_CCM=m +CONFIG_CRYPTO_AES_ARM64_CE_BLK=m +CONFIG_CRYPTO_AES_ARM64_NEON_BLK=m CONFIG_BINARY_PRINTF=y # -- 2.1.0 -- Andreas Schwab, SUSE Labs, schwab(a)suse.de GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7 "And now for something completely different." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 11 months

[opensuse-kernel] Enable build with Factory repo in Kernel:stable

by Max Lin

Hi, Can someone enable build with Factory repo. in Kernel:stable? otherwise the submission from Kernel:stable would not pass check by factory-repochecker, ie. https://build.opensuse.org/request/show/245242 Best regards, Max -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 11 months

[opensuse-kernel] [RFC] Reintroducing split packages

by Jeff Mahoney

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi all - I'm doing the integration work for 3.17-rc1 and, as usual, there are a ton of drivers that are typically only used for embedded devices. Generally, I'd prefer to just disable them, but there are always a few people who want to run openSUSE on things like tiny Atoms. Do we want to consider moving uncommon drivers into something like kernel-default-uncommon and save disk space on most every other system? Of course, then there's also the concept of kernel-default-base again, where it would probably contain typical file systems (xfs/ext4/btrfs) and drivers for devices most commonly offered by qemu-kvm. I understand it doesn't cover cases like device assignment, but those are more advanced use cases in which the full kernel-default package would be used. The problem I'm looking to solve is "what would work well for several major use cases?" I'd define those as typical desktop/server/notebook hardware and KVM instances without device assignment. (Xen is a different conversation since dom0 and domU have different requirements WRT drivers.) The fallback for not fitting into one of the nice boxes is just installing another package which uses as much disk space as the old kernel package used to, so it's not a huge inconvenience. OTOH, having multiple kernel sub-packages has been somewhat of a PITA WRT updates and dependencies, so I thought I'd solicit opinions. - -Jeff - -- Jeff Mahoney SUSE Labs -----BEGIN PGP SIGNATURE----- Version: GnuPG/MacGPG2 v2.0.19 (Darwin) iQIcBAEBAgAGBQJT90a1AAoJEB57S2MheeWyvQsP/3w4RhrNsESul6jNNqiEHVuZ yKA0IcyyJiZgJOV6qtgz2j4JWEd14o06QTX+QsL6oyE48SQi/NqH0flAoVJGGZsz DmremRuhWUT5R2hC2rmMZgo6hZkROGqEtdTbgpb/o31vsDZK2n8dZAzz7IiTWn2W BYG1Ixf4I2Q2J1cjGJRaSpfBGmSdCCwtSV42tIg2Ka4EMbOfdRRSUhPSobHMWPCy MXRPCfbJ1pN6NlN5XF++kiM8H2gFEt14jPzeMO7NYpRSAPa4V/CMANBRjEEsLh6n YNspFJCkZSLuRFOOcwgUge2gbcfUNVF4O4BZhruHHSW49aWMVuIOJtg3cM7xcYYD qkHNXcYTZssiPIMg6o2tl2vJB1dKhAwef1l6A75V4dc1+2QZznv7cty0NZE8mVYp 3J7M4LHwvGZMC1KEe5wDsOJNwIC4Kt74i6ZgDfl3/0GquM6ODDWZOTQykKRuP8dY /eYDfj/rItOiVXMsIxqwdq7Komk3X4kDhgaUlveXFN524Ivplq5/uspYfyB3nTCU yRgPJHOfj3FOp1pxAloKHfgBs1cso/yUw92PwWSY/lsUN4K3YOoys25BLElIeYhX RrrcF19hjZkkjQvzrQl/EW0RUqTPil3UAhz0KlY/ZvKEL/rlWvhC7bD2GtUaLU8k pXuQJ99gfpVcwUHbIoZW =Srwn -----END PGP SIGNATURE----- -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 11 months

[opensuse-kernel] upgrade gfxcard -> radeondrmfb nightmare

by Felix Miata

I didn't really expect to, since they look like kernel modules, and I really only have a problem with the latter. I bought a $30US HD5450 (Evergreen) Radeon so I'd have some non-Intel gfxchip newer than 7 years old here. It will have cost $15 net once I claim the available rebate. I first tried it in a 32 bit i915G system after freshly updating 12.3, 13.1 and 13.2. Everything worked as expected in all three, then I put in the Radeon, and tried first 13.2. Init progressed for about 20 seconds, then announced "switching to radeondrmfb from VESA VGA", and promptly stopped updating the screen. From there I experimented a bit and figured out I can keep video working by eliminating both vga= and video= from cmdline, but that's not OK here. I pulled the card back out, then updated 13.1 and 13.2 on a 64 bit Intel 4000 system that already had Radeon, an older X600. After determining everything works as expected on 12.3, 13.1 and 13.2, I swapped the 5450 into the X600's slot. Everything works as expected with it too. So, I undid the swap, put the newer system back on the shelf, and put the 5450 back into the i915 system. I tried 13.1/Jiri's 3.12.22 kernel, but same problem. Next, 12.3, no problem. Next, 13.1 again, but with 3.11.10, and video stays working. Rawhide/3.17rc1git2 on the 915 system with 5450 card finds the radeondrmfb during boot and works as expected. Lsmod there shows drm_kms_helper and radeon and ttm for drm. In 13.1 remote login I see this excerpt in dmesg: [ 22.500935] r600_cp: Failed to load firmware "radeon/CEDAR_pfp.bin" [ 22.500957] [drm:evergreen_init] *ERROR* Failed to load firmware! [ 22.500973] radeon 0000:01:00.0: Fatal error during GPU init [ 22.500987] [drm] radeon: finishing device. [ 22.508073] [TTM] Finalizing pool allocator [ 22.508142] [TTM] Zone kernel: Used memory at exit: 0 kiB [ 22.508157] [TTM] Zone highmem: Used memory at exit: 0 kiB [ 22.508164] [drm] radeon: ttm finalized [ 22.508688] radeon: probe of 0000:01:00.0 failed with error -2 Searhing for string radeondrmfb in Novell Bugzilla turns up nothing. Searching for *drm* in /lib/modules I see no differences in names for 3.11 and 3.12. Searching with zypper for irmware I see nothing that looks like it's for ATI or Radeon or any installed kernel. Remote login is broken for 13.2. I tried without proper cmdline to install 3.17rc1vanilla in 13.2, but initrd creation failed (and yet do_purge_kernels got created). At that point I uninstalled vanilla, and tried installing kernel-firmware. That worked, after 5 hours of head banging. :-( Why this impediment to upgrading gfxcards in openSUSE? Shouldn't kernel-firmware have already been installed? Why do only some gfxchips need it? -- "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/ -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 11 months

[opensuse-kernel] 3.16.1 kernel for STABLE?

by Andreas Jaeger

HEAD is currently at 3.16.0 and stable at 3.15.8. Could somebody update, please? Thanks, Andreas -- Andreas Jaeger aj(a){suse.com,opensuse.org} Twitter/Identica: jaegerandi SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Jeff Hawn,Jennifer Guild,Felix Imendörffer,HRB16746 (AG Nürnberg) GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 years, 11 months

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

openSUSE Kernel August 2014