November 2015 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] Use pvops-enabled kernel for Xen (fate#315712)
by Michal Marek 20 Jan '16

20 Jan '16

Hi, you have probably noticed that the SUSE virtualization developers have been working on porting features from the kernel-source patches.xen series to the upstream Xen implementation. This mostly works nowadays, so at the SUSE Labs Conference last month, we agreed to finally get rid of kernel-xen in Factory and instead use kernel-default with CONFIG_XEN (the mainline option) enabled. I prepared a branch on github https://github.com/michal42/kernel-source stable-noxen which does exactly this. Test packages are building here: https://build.opensuse.org/project/show/home:michal-m:kernel-stable-noxen The kernel boots and works on my machine, both on bare metal and under the hypervisor (*), but there is some integration work to be done before it can be submitted to Factory: - The installer needs to cope with kernel-xen not available and choose kernel-default. Something like the attached patch should fix it (untested). - perl-Bootloader: Right now, it creates a Xen multiboot entry if the kernel is named -xen, otherwise it creates a regular linux entry. Create both entries if the Xen hypervisor is installed? - kernel-xen needs to be dropped from the patterns, but that's trivial - We have been building a kernel-obs-build-xen package for the OBS workers, which now disappears. Of course, there is lot more work to be done in making the xen -> pvops transition seamless in all corner cases. But that should not be a barrier to pushing the kernel to factory. (*) With the -default kernel, I do not see the kernel messages on the serial console with kernel /boot/xen.gz com1=115200 console=com1,vga module /boot/vmlinuz-4.2.2-0.g980fcdb-default ... console=tty0 console=ttyS0,115200 while I see them with kernel-xen. Michal

6 16

[opensuse-kernel] Please raise disk size constraints for kernel builds
by Stefan Bruens 11 Jan '16

11 Jan '16

Hi, builds of kernel packages occasionally fail due to unsufficient disk space. Happens for kernel-default,-vanilla,-... on 64bit archs. Used resources on for Kernel:stable/Kernel:HEAD (MBytes) Kernel:stable standard x86_64 kernel-vanilla Disk: 16273, Memory: 728, Time: 20519 Kernel:HEAD standard x86_64 kernel-debug Disk: 16279, Memory: 758, Time: 24744 Kernel:HEAD standard x86_64 kernel-default Disk: 16232, Memory: 1260, Time: 5804 Kernel:HEAD standard x86_64 kernel-pv Disk: 16366, Memory: 1263, Time: 4837 Kernel:HEAD standard x86_64 kernel-vanilla Disk: 16860, Memory: 751, Time: 17809 Kernel:HEAD PPC ppc64 kernel-vanilla Disk: 15142, Memory: 1117, Time: 6345 Kernel:HEAD ARM aarch64 kernel-vanilla Disk: 15214, Memory: 746, Time: 10565 Kind regards, Stefan -- Stefan Brüns / Bergstraße 21 / 52062 Aachen home: +49 241 53809034 mobile: +49 151 50412019 work: +49 2405 49936-424 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 6

[opensuse-kernel] revert to 4K pagesize for ppc64
by Olaf Hering 02 Dec '15

02 Dec '15

Neither firewire nor nouveau seem to support 64K pagesize. Any objection to revert to 4K pages for ppc64/default? ppc64le can remain 64K. Olaf -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

6 17

[opensuse-kernel] i386/vanilla non-pae?
by Michal Marek 30 Nov '15

30 Nov '15

Hi, does anybody know if there is a reason why the i386/vanilla flavor does not enable pae? I assume that those who still run 32bit kernels do so on pae-cabable hardware and run kernel-pae, so a vanilla flavor with the same config would make more sense, wouldn't it? Thanks, Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

5 7

[opensuse-kernel] CONFIG_SWIOTLB=n in powerpc vanilla configs
by Michal Marek 30 Nov '15

30 Nov '15

Hi, Is there a reason why we do not set CONFIG_SWIOTLB in the powerpc vanilla configs? The configs are otherwise almost identical do the respective default ones, this is the only difference no explained by our patches. Thanks, Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 3

[opensuse-kernel] erratic behaviour and failure of marvell SATA card (only on Linux, test fine on Windows)
by DetlevCM 27 Nov '15

27 Nov '15

Dear All, after posting on the OpenSUSE forum ( https://forums.opensuse.org/showthread.php/511116-Sata-card-erratic-behavio… ) and on Unix Stackexchange ( http://unix.stackexchange.com/questions/244419/marvell-88se9128-9123-sata-c… ) it was suggested this may be a case for the mailing list. So a short description (for those not reading the threads at the links - but extensive dmesg output is linked in the two threads): I have a Dell T20 home server with OpenSUSE and use a Marvell 88SE9123 (labelled 88SE9128) chipset based SATA card (2 ports) of which one is used. When a drive is connected to the SATA card and written to (file copy or zero fill) it will drop randomly and vanish from the listed devices, taking a reboot to reappear. The drive is definitely OK (recertified Seagate) and an alternative drive has also been tested. When using Windows (even installing on the Dell on a spare harddrive), the SATA card tests fine running 5 passes of a 32GB CrystalDisk benchmark - using the same cable as well as the same harddrive (and alternative harddrive has been tested too just in case). But Linux... trouble... - I have now tested a Ubuntu LiveUSB with Kernel 3.13, OpenSUSE 13.2 with Kernel 3.16 - and regularly the server runs on OpenSUSE Leap 42.1 (Kernel 4.1 right now). Whether Native Command Queuing is on or off seems to make no difference whatsoever - be it on the fly via command line or as a Kernel parameter. My conlusion is therefore that the problem can only be in two locations: 1) the Linux driver OR 2) the card's firmware itself (I cannot chose any kinds of settings on the card - it has the latest available BIOS, it is a StarTech PEXSAT32) Maybe someone here has any ideas? Side note: I am happy to collect logs etc. but while I am spending seemingly more and more time with Linux, I do not have any troubleshooting experience and would appreciate precise idiotproof instructions if extra logs/etc. are required. Many thanks. -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 2

[opensuse-kernel] Leap update kernel questions
by Marcus Meissner 26 Nov '15

26 Nov '15

Hi, As I am just processing the Leap Update kernel. 1. Do we want to keep the kABI stable? I see this diff currently in -default: -ksym(default:pci_disable_msi) = 3219b64b -ksym(default:pci_disable_msix) = 588a518 +ksym(default:pci_disable_msi) = 345bfdda +ksym(default:pci_disable_msix) = 67e3b2c4 -ksym(default:pci_enable_msi_range) = 9ced3242 -ksym(default:pci_enable_msix) = d5c6189f -ksym(default:pci_enable_msix_range) = 4a1554ac +ksym(default:pci_enable_msi_range) = 50b78261 +ksym(default:pci_enable_msix) = c21e9f +ksym(default:pci_enable_msix_range) = fef96feb -ksym(default:pci_msi_vec_count) = 9de2639f -ksym(default:pci_msix_vec_count) = 5b24f2ce +ksym(default:pci_msi_vec_count) = 70960234 +ksym(default:pci_msix_vec_count) = 5d290135 -ksym(default:pci_restore_msi_state) = d89dbc38 +ksym(default:pci_restore_msi_state) = d5774c0e Although I do not know how much modules would use these apis. 2. Updating kmps together For 13.1 and 13.2 I have to update the kmps together with the kernel, but it seems we switched back from uname-r requires to ksym requires again, so it seems unnecessary. Ciao, Marcus -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 8

[opensuse-kernel] strange (and broken) patch in our kernels
by Michal Kubecek 26 Nov '15

26 Nov '15

Hello, I accidentally noticed a really strange patch in our master branch and then found it also in other branches, e.g. SLE12 (but not in e.g. SLE11-SP4): patches.fixes/bridge-module-get-put.patch The purpose of this patch is to disallow unloading bridge module if there is at least one bridge device. This causes various problems: 1. It deviates from upstream kernel behaviour which allows unloading the module (removing all existing bridge devices). There should be a good reason for such difference in behaviour and I don't find the reasoning in bsc#267651 convincing. 2. It is inconsistent with to other types of virtual devices: "rmmod bonding" removes all bonding devices, "rmmod 8021q" removes all vlan devices etc. Why should bridge be different? 3. The patch is in fact broken as it only takes/drops the reference if the bridge device is added/deleted using the old ioctl interface (brctl command) but not if it is done using netlink (ip and most likely also wicked). This can result in refcount leak: 12sp0:~ # modprobe bridge 12sp0:~ # brctl addbr br1 12sp0:~ # ip link del br1 12sp0:~ # lsmod | grep '^bridge' bridge 123100 1 or even negative refcount: 12sp0:~ # modprobe bridge 12sp0:~ # ip link add br1 type bridge 12sp0:~ # brctl delbr br1 12sp0:~ # lsmod | grep '^bridge' bridge 123100 -1 This is definitely wrong. I'm afraid we can't get rid of the patch in SLE12 and SLE12-SP1 but I would like to drop it from master/stable so that it doesn't get into future releases (including SLE12-SP2). Does anyone have a strong argument for keeping (and fixing) the patch? Michal Kubeček -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 3

[opensuse-kernel] Planned Leap 42.1 kernel update
by Takashi Iwai 24 Nov '15

24 Nov '15

Hi, I'm going to submit the kernel update for openSUSE Leap 42.1 tomorrow. The update will include 4.1.13 stable updates (that has some nouveau fixes), a few security fixes and lots of other fixes, mainly for i915 and HD-audio. It's a good time, about one month after the release, and the next 4.1.14 will be likely with another huge updates from 4.4-rc1, so better to push before that for now. If anything is missing, please let me know. We can align the schedule. thanks, Takashi -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 4

[opensuse-kernel] Kernel-xen is being dropped
by Jiri Slaby 24 Nov '15

24 Nov '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Hi, with request#345827, kernel-xen, -pv, and -ec2 packages will be dropped from factory. Instead, kernel-default will obsolete them by xen through pv-ops. I.e. install kernel-default, report potential bugs, and have fun, - -- js suse labs -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJWUv+nAAoJEL0lsQQGtHBJ2foP/1h2gX2kxzZphU26rXJuQirT DoZCBrKMbggw0SX8EY/b06lyjpmVKnlbDiGOlmX1h4yHyQAKmfMrQ7JPpudlRdd0 H8xA8Fh4fPL8fpvxLMsMgHp3AB5Le2hTOsMB6DW43uP2OC+QrhnBZPr2LdVo+6Zv NOple3ChHn5g1gGDf3Uj6gTw3ReawtzGjz4ip4APBt0WzOF1hJLYS7AH+LLhfL4T c1tBaFrRZBDs0zkv/HrKGTPtbGFWrtRhLmMJeVd/p9khE3FCa/vqZbJ2HtCtLhdc rpvFBLlfY0jlCKfOVXWo67gsa+3F2miM3W94LsTvhcJIw2HMn1yXz13VvnHNP+CI w1LvJOhTSCRjJ4hx4pYjU5lNOu1/dxjbKIIEXOLGsWSmEFP+fcB5CZOFxbzLXSXn fnba8xLSJFa3Tf3JGrtepcVgs1K6T7mmAJ2eLnGSzdhv1GpYGSdouefAK5F9tNXY ntSnzWwn+kMA8BnY0BHy5kTjvfeJbGj2LK54FlHmtr78kPuwklvmjcxvakcUSt6I Gk39ssOwW9QGue6OLJAlZSpugQUUUirJoRY75pWou3tFWy1h9QJz9lZvwdE4uzNN Ar7s+h+zhpv2h6XYA964xCyRF2G6kQZKkSYilpOh6y9KudNRVK+tWa2W5uVwkE4e soEvHaT0jnK91COqhhGV =Of7c -----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

4 4