February 2020 - openSUSE Kernel - openSUSE Mailing Lists

[opensuse-kernel] [PATCH] config: enable CONFIG_EROFS_FS_ZIP=y
by Gao Xiang 17 Mar '20

17 Mar '20

People reported they cannot read EROFS compressed file in openSUSE distribution recently. Turn on the missing configurations (which are the default configurations currently as well.) Signed-off-by: Gao Xiang <gaoxiang25(a)huawei.com> --- RESEND due to being blocked by Mlmmj program previously. config/arm64/default | 3 ++- config/armv6hl/default | 3 ++- config/armv7hl/default | 3 ++- config/armv7hl/lpae | 3 ++- config/i386/pae | 3 ++- config/ppc64/default | 3 ++- config/ppc64le/default | 3 ++- config/s390x/default | 3 ++- config/x86_64/default | 3 ++- 9 files changed, 18 insertions(+), 9 deletions(-) diff --git a/config/arm64/default b/config/arm64/default index 53620976e4d8..97dd4fcd40d9 100644 --- a/config/arm64/default +++ b/config/arm64/default @@ -9995,7 +9995,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/armv6hl/default b/config/armv6hl/default index 2d1cbe602c35..86f58cbbae67 100644 --- a/config/armv6hl/default +++ b/config/armv6hl/default @@ -7324,7 +7324,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/armv7hl/default b/config/armv7hl/default index 29ef65bbf959..5795d7813161 100644 --- a/config/armv7hl/default +++ b/config/armv7hl/default @@ -10213,7 +10213,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/armv7hl/lpae b/config/armv7hl/lpae index b76e5ba54728..86f56105e8b9 100644 --- a/config/armv7hl/lpae +++ b/config/armv7hl/lpae @@ -9802,7 +9802,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/i386/pae b/config/i386/pae index de12c2cf466c..908c042eb9a2 100644 --- a/config/i386/pae +++ b/config/i386/pae @@ -9041,7 +9041,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/ppc64/default b/config/ppc64/default index 6f9f1a4e22b4..2d57c920a3e4 100644 --- a/config/ppc64/default +++ b/config/ppc64/default @@ -7111,7 +7111,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/ppc64le/default b/config/ppc64le/default index e2a93e1fc031..f9ec83b0c67c 100644 --- a/config/ppc64le/default +++ b/config/ppc64le/default @@ -6964,7 +6964,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/s390x/default b/config/s390x/default index 76405f53b4cc..1b63e6411604 100644 --- a/config/s390x/default +++ b/config/s390x/default @@ -3430,7 +3430,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m diff --git a/config/x86_64/default b/config/x86_64/default index fcc371484fe7..1c062a2106db 100644 --- a/config/x86_64/default +++ b/config/x86_64/default @@ -8850,7 +8850,8 @@ CONFIG_EROFS_FS=m CONFIG_EROFS_FS_XATTR=y CONFIG_EROFS_FS_POSIX_ACL=y CONFIG_EROFS_FS_SECURITY=y -# CONFIG_EROFS_FS_ZIP is not set +CONFIG_EROFS_FS_ZIP=y +CONFIG_EROFS_FS_CLUSTER_PAGE_LIMIT=1 CONFIG_NETWORK_FILESYSTEMS=y CONFIG_NFS_FS=m CONFIG_NFS_V2=m -- 2.17.1 -- 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] is sendfile(2) support depending on network card driver?
by Stefan Seyfried 22 Feb '20

22 Feb '20

Hi all, yesterday, I replaced the broken network card in my server machine at home running Leap 15.1. Old NIC was onboard e1000e, 8086:10df, new NIC is pci-e r8169, 10ec:8168 Everything looked good so far, but I wondered why the web pages served from apache on this host looked a bit "simple" :-). Something like "script generated content delivered, but static content missing". I could not find anything in apache logs, so I resorted to stracing it with a simple request that returned nothing: | seife@strolchi:~> curl -v http://server/owncloud/core/img/loading-dark.gif | * Trying 192.168.200.1:80... | * TCP_NODELAY set | * Connected to server (192.168.200.1) port 80 (#0) | > GET /owncloud/core/img/loading-dark.gif HTTP/1.1 | > Host: server | > User-Agent: curl/7.68.0 | > Accept: */* | > | * Mark bundle as not supporting multiuse | < HTTP/1.1 200 OK | < Date: Sat, 22 Feb 2020 09:08:59 GMT | < Server: Apache/2.4.33 (Linux/SUSE) | < Last-Modified: Wed, 03 Jul 2019 11:17:17 GMT | < ETag: "90c-58cc501036940" | < Accept-Ranges: bytes | < Content-Length: 2316 | < Content-Type: image/gif | < | * transfer closed with 2316 bytes remaining to read | * Closing connection 0 | curl: (18) transfer closed with 2316 bytes remaining to read The strace output contained: [pid 16528] openat(AT_FDCWD, "/srv/www/htdocs/owncloud/core/img/loading-dark.gif", O_RDONLY|O_CLOEXEC) = 22 [pid 16528] read(21, 0x5587151055c8, 8000) = -1 EAGAIN (Resource temporarily unavailable) [pid 16528] setsockopt(21, SOL_TCP, TCP_CORK, [1], 4) = 0 [pid 16528] writev(21, [{iov_base="HTTP/1.1 200 OK\r\nDate: Sat, 22 F"..., iov_len=234}], 1) = 234 [pid 16528] sendfile(21, 22, [0], 2316) = -1 EOPNOTSUPP (Operation not supported) [pid 16528] setsockopt(21, SOL_TCP, TCP_CORK, [0], 4) = 0 [pid 16528] write(15, "192.168.200.12 - - [22/Feb/2020:"..., 126) = 126 ==> sendfile EOPNOTSUPP I looked into the apache config, found /etc/apache2/server-tuning.conf where "EnableSendfile on" was configured, changed that to "off", restarted apache and everything is fine again. Now I'm just wondering what could have caused this to happen. The filesystem on /srv is XFS, underlying blockdevice is bcache and this has worked before without a problem. I cannot remember changing anything else than adding the new network card, but it is of course possible that I did (accidentally) change something since last reboot. (and of course, apache should not fail silently, but that's another bug to report) Any hints? Thanks, seife -- Stefan Seyfried "For a successful technology, reality must take precedence over public relations, for nature cannot be fooled." -- Richard Feynman -- 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] Kernel 5.4.18 for TW
by Hans-Peter Jansen 07 Feb '20

07 Feb '20

Dear Kernel hackers and maintainers, can we have a late 5.4 kernel for TW before going to 5.5, *please*. The virtualbox woes with 5.5 will keep that move more painful than ever. While at it, is KVM fully tested with 5.5 on both sides? Thank you for consideration. Cheers, Pete -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

3 5

Re: [opensuse-factory] Re: [opensuse-kernel] Kernel 5.4.18 for TW
by Michal Kubecek 07 Feb '20

07 Feb '20

On Fri, Feb 07, 2020 at 10:14:16AM +0100, Dan Čermák wrote: > Jiri Slaby <jslaby(a)suse.cz> writes: > > > >> The virtualbox woes with 5.5 will keep that move more painful than ever. > > > > You have to complain to virtualbox authors. It's apparently their fault > > not to upstream the modules in the past decade. It cannot stop new > > kernels to roll in openSUSE. > > > > The other option is to politely ask our vbox maintainer to keep vbox up > > with 5.5. What's the problem, actually? > > As the maintainer of Vagrant, that was designed to primarily use > VirtualBox (not on openSUSE though), I'd like to know too. The "issues with virtualbox vs. new kernel" usually mean there is some change in the internal kernel API which the out-of-tree modules need to be adjusted to. It's the same with any other project dependent on out-of-tree modules (VMware, NVidia, ...). But I have no idea what exactly does virtualbox have problem with as 5.5 was in fact one of the few recent versions which did _not_ break the build of host modules for VMware Workstation/Player. In any case, I agree that it's a problem of virtualbox and no reason to delay the switch to 5.5 kernel (unless there actually is a kernel bug). Michal -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe(a)opensuse.org To contact the owner, e-mail: opensuse-kernel+owner(a)opensuse.org

1 0