March 2017 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] kernel repository over rsync not updated
by Giacomo Comes 04 Apr '17

04 Apr '17

I'm not sure were to report this issue, so i'm doing it here. Please forward it to the appropriate place. If I run: wget -q -O - http://download.opensuse.org/repositories/Kernel:/HEAD/standard/noarch/ | grep kernel-source-4 I get: <img src="/icons/rpm.png" alt="[ ]" /> <a href="kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm">kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm</a> 17-Mar-2017 08:55 91M <a href="kernel-source-4.11.rc2-2.1.g01218d4.noarch.rpm.mirrorlist">Details</a> which is ok. But if I run: rsync rsync.opensuse.org::buildservice-repos-main/Kernel:/HEAD/standard/noarch/ | grep kernel-source-4 I get: -rw-r--r-- 93971273 2017/02/21 04:01:01 kernel-source-4.10.0-1.1.g12a7a6d.noarch.rpm The kernel (and also kernel-stable) repository accessible with rsync is not getting updated. Giacomo -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 2

[opensuse-kernel] Dirty COW fix causes some apps to freeze; patch is available in upstream
by Christian Mauderer 22 Mar '17

22 Mar '17

Hello, I run across a problem with an application using wine on OpenSUSE 42.1. After some search, I found out that it is a known bug and that there is an fix available: https://bugs.winehq.org/show_bug.cgi?id=41637 Basically the (backported) Dirty COW fix misses some adaptions in a second file and that leads to problems in some very special cases. For details please see the LKML thread with the fix: https://lkml.org/lkml/2017/1/5/13 Is there any chance that this patch will be backported to the OpenSUSE 42.1 Kernel too? If I have seen it right, the OpenSUSE 42.2 Kernel is also affected. If necessary I'm able to apply the patch and build a kernel myself but I have no idea what I would have to do to submit it to the official OpenSUSE kernel. Any hints? Kind regards Christian Mauderer -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

8 14

[opensuse-kernel] How to solve the delayed grant mapping problem with blkback?
by Xieyingtai 20 Mar '17

20 Mar '17

Hello, Recently I got a problem when I use virtual machines in Xen virtualization, description just as follws. Grant table and grant mapping were used for data communication with in Xen front end driver and back end driver. A delay work will be set up to release grant mapping pages in end_block_io_op as bio callbacks, the code as below: static void __gnttab_unmap_refs_async(struct gntab_unmap_queue_data* item) { int ret; int pc; for (pc = 0; pc < item->count; pc++) { if (page_count(item->pages[pc]) > 1) { unsigned long delay = GNTTAB_UNMAP_REFS_DELAY * (item->age + 1); schedule_delayed_work(&item->gnttab_work, msecs_to_jiffies(delay)); return; } } ret = gnttab_unmap_refs(item->unmap_ops, item->kunmap_ops, item->pages, item->count); item->done(ret, item); } Only if the page count of grant mapping page was decrease to one, a response would be made to notify the vm front end. But in the scenario which a network cable was extracted, the TCP transport layer will retransmit the socket data. As a result, the grant mapping pages were occupied by the TCP retransmition which may continued for a long time. And then in blkback driver, the grant unmap delay work will continue until the TCP releases all the pages. As an application of TCP protocol, Is there any method to solve this problem in iscsi driver layer? I have already attempted to modified some parameters provide by iscsi, but it was a futile effort. The socket connection seems not be closed in the network cable extracted scenario. Thanks -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

2 1

[opensuse-kernel] Kernel tools packaging for Factory
by Andreas Färber 07 Mar '17

07 Mar '17

Hello, For v4.7, the kvm_stat utility was removed from QEMU and added to the kernel. We therefore had to adapt qemu packaging, and Bruce added a Virtualization/kvm_stat package built from kernel-source. https://build.opensuse.org/package/show/Virtualization/kvm_stat As part of the Factory submission review, although it was accepted, it was suggested that we add it as sub-package to devel:tools/linux-tools instead. I have done that now. https://build.opensuse.org/package/show/devel:tools/linux-tools However, linux-tools is not in Factory. Therefore we can't drop our kvm_stat package yet, which was the intended purpose of the submission. Are there any plans to submit linux-tools to Factory, or what is holding it up? Should this rather be integrated with kernel-source somehow, like dtb-source recently, so that it rebuilds with kernel updates and can take build breakages like for v4.10 into account? Thanks, Andreas -- SUSE Linux GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany GF: Felix Imendörffer, Jane Smithard, Graham Norton HRB 21284 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 2