From owner-freebsd-current@freebsd.org Sat Jun 27 14:56:11 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3AEE1353AA2; Sat, 27 Jun 2020 14:56:11 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49vGzH0k3Yz437M; Sat, 27 Jun 2020 14:56:11 +0000 (UTC) (envelope-from owner-freebsd-quarterly-calls@freebsd.org) Delivered-To: freebsd-quarterly-calls@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B9BDF353554; Sat, 27 Jun 2020 14:52:41 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vGvF4TNdz42yW; Sat, 27 Jun 2020 14:52:41 +0000 (UTC) (envelope-from debdrup@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1471) id 7ED0568F5; Sat, 27 Jun 2020 14:52:41 +0000 (UTC) To: freebsd-quarterly-calls@FreeBSD.org Subject: [LAST OFFICIAL REMINDER] Call for 2020Q2 quarterly status reports Message-Id: <20200627145241.7ED0568F5@freefall.freebsd.org> Date: Sat, 27 Jun 2020 14:52:41 +0000 (UTC) From: Daniel Ebdrup Jensen X-Mailman-Approved-At: Sat, 27 Jun 2020 14:56:10 +0000 X-BeenThere: freebsd-quarterly-calls@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: owner-freebsd-quarterly-calls@freebsd.org Sender: owner-freebsd-quarterly-calls@freebsd.org X-Mailman-Approved-At: Sun, 28 Jun 2020 06:51:52 +0000 X-BeenThere: freebsd-current@freebsd.org List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 27 Jun 2020 14:56:11 -0000 Dear FreeBSD Community, The deadline for the next FreeBSD Quarterly Status update is July, 1st 2020 for work done since the last round of Quarterly Reports: April 2020 - June 2020. I would like to remind you that reports are collected during the last month of every quarter. Status report submissions do not need to be very long. They may be about anything happening in the FreeBSD project and community, and they provide a great way to inform FreeBSD users and developers about work that is underway or has been completed. Report submissions are not limited to committers; anyone doing anything interesting and FreeBSD related can -- and should -- write one! The preferred method is to follow the guidelines at the Quarterly GitHub repository: https://github.com/freebsd/freebsd-quarterly Alternatively you can fetch the Markdown template, fill it in, and email it to quarterly-submissions@FreeBSD.org. The template can be found at: https://raw.githubusercontent.com/freebsd/freebsd-quarterly/master/report-sample.md We look forward to seeing your 2020Q2 reports! Thanks, Daniel Ebdrup Jensen (on behalf of quarterly@) _______________________________________________ freebsd-quarterly-calls@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-quarterly-calls To unsubscribe, send any mail to "freebsd-quarterly-calls-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sun Jun 28 16:26:38 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7819A350731 for ; Sun, 28 Jun 2020 16:26:38 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: from mail-wm1-x331.google.com (mail-wm1-x331.google.com [IPv6:2a00:1450:4864:20::331]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49vwx94mffz4bcd for ; Sun, 28 Jun 2020 16:26:37 +0000 (UTC) (envelope-from grahamperrin@gmail.com) Received: by mail-wm1-x331.google.com with SMTP id f18so13895244wml.3 for ; Sun, 28 Jun 2020 09:26:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=Q+aCE0jSRJN2sNTnUlwzAvJWznnbIH4Jo6yeXHhDGTc=; b=BoLS4TUFSwu34shB4R3T7B3G/nKjCdp3R9hJ/K+noQ+SshfBax11nzjJOBRWOX/eA3 +wyGhZXiMDUwbfLrWsjiEh0es05DM41UiTOLb+2YAXU5jlJTlZyGzIucbRFEa9QK4hFu UOGVM35+5mkCXOiRMZJ//8QuYoeDC17O+9mnrJ6o87ZTJ4UNfABva/Q9+bx824M6v5ul AZ3psWFXGrg8GDz4RiU2TS84bqkXi+Ucx7IeWJvTT3AlQcyh1WsM3zzbCZGLIfnQg7et RNxbXoU/cW2WOlSa0mxEx0rh+TZ4sXsW34pKj4eYo5kkpt3iYsmSdcD2W69Pi6i6Zp3Z gtXQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=Q+aCE0jSRJN2sNTnUlwzAvJWznnbIH4Jo6yeXHhDGTc=; b=aWRtCgTVyE4DeoCiTF+y3QIJ6lQGAsLItVy+MAuLE5HOZu0D0wZaJaS9N+wJ9DqBkX TdpWWdkRCzgd6fw+vVNRO4qyGGkWS89ouvDyn/3Dob4bgfc5IcKu/Z23OKRV5EQwSWLO jpk+UlEhxN8GG64nmPJP6YyxKFr2WGRCIFXREDDug8OVRzUKwHVcrUoAFXVx46j5YeUJ +ZJSHOkX44LZ8DYA1Rt2652Y7ldf7szfrbIJDYrbPflwvtO8jPgcG5ldtoQv8W4uevGL iLIN8jKsKrYA35bWHR8kSEyCq15ehWVXUuJqZp7XCWBefyo4yrdsh9sTT/ErN/jYbM9y ozPQ== X-Gm-Message-State: AOAM530Cw+PsVSlEaTa2fiPm78qmq8SAaJ1DwmbWnCS4ogEFTPT+PVxF cAv8J7XHD9PFwwJN6B00xRgK+DFr/aA= X-Google-Smtp-Source: ABdhPJwQvL3nZAkumM32EwjyB7gWrz+B29sBGoD30Lh7P1mw0jRtUtxTTN9KAvdONvV4nQKkDNE7pw== X-Received: by 2002:a1c:98cc:: with SMTP id a195mr12905280wme.89.1593361595766; Sun, 28 Jun 2020 09:26:35 -0700 (PDT) Received: from [192.168.1.7] (79-66-147-78.dynamic.dsl.as9105.com. [79.66.147.78]) by smtp.gmail.com with ESMTPSA id 40sm23512308wrc.27.2020.06.28.09.26.34 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 28 Jun 2020 09:26:35 -0700 (PDT) Subject: mesa-dri, mesa-libs, libglvnd, software rasteriser From: Graham Perrin To: freebsd-current@FreeBSD.org References: <0f2c1ce1-90e3-6c5a-502d-b6006c05960c@gmail.com> Message-ID: <95b7926d-a392-45f4-12c4-3409de840e27@gmail.com> Date: Sun, 28 Jun 2020 17:26:33 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <0f2c1ce1-90e3-6c5a-502d-b6006c05960c@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-GB X-Rspamd-Queue-Id: 49vwx94mffz4bcd X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=BoLS4TUF; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of grahamperrin@gmail.com designates 2a00:1450:4864:20::331 as permitted sender) smtp.mailfrom=grahamperrin@gmail.com X-Spamd-Result: default: False [-2.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2a00:1450:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; TO_DN_NONE(0.00)[]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.01)[-0.009]; RECEIVED_SPAMHAUS_PBL(0.00)[79.66.147.78:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2a00:1450::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.91)[-0.910]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.90)[-0.899]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; RCVD_IN_DNSWL_NONE(0.00)[2a00:1450:4864:20::331:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 28 Jun 2020 16:26:38 -0000 Re: my e-mail of 25th June (below) If I lock mesa-dri and mesa-libs before pkg upgrade, then I am free of the software rasteriser problem following an upgrade. However: the locks cause libglvnd to not install at upgrade time; and then applications such as Firefox and Thunderbird will not start. Should I treat the software rasteriser problem as a bug with mesa-dri, mesa-libs or libglvnd? If I unlock the packages then allow installation of libglvnd, might there be a workaround to the software rasteriser problem? Thanks ---- root@momh167-gjp4-8570p:~ # date ; uname -v Sun Jun 28 16:56:31 BST 2020 FreeBSD 13.0-CURRENT #58 r361769: Thu Jun  4 09:45:38 BST 2020 root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG root@momh167-gjp4-8570p:~ # pkg lock -l Currently locked packages: mesa-dri-19.0.8_4 mesa-libs-19.0.8 waterfox-2019.12.c root@momh167-gjp4-8570p:~ # pkg install libglvnd Updating FreeBSD repository catalogue... FreeBSD repository is up to date. Updating poudriere repository catalogue... poudriere repository is up to date. All repositories are up to date. Checking integrity... done (0 conflicting) The following 1 package(s) will be affected (of 0 checked): New packages to be INSTALLED:         libglvnd: 1.3.1 [FreeBSD] Number of packages to be installed: 1 The process will require 4 MiB more space. Proceed with this action? [y/N]: y [1/1] Installing libglvnd-1.3.1... pkg: libglvnd-1.3.1 conflicts with mesa-libs-19.0.8 (installs files into the same place).  Problematic file: /usr/local/include/EGL/egl.h root@momh167-gjp4-8570p:~ # exit logout grahamperrin@momh167-gjp4-8570p:~ % firefox ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "pthread_setname_np@FBSD_1.6" grahamperrin@momh167-gjp4-8570p:~ % thunderbird ld-elf.so.1: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "pthread_setname_np@FBSD_1.6" grahamperrin@momh167-gjp4-8570p:~ % virtualbox VirtualBox: supR3HardenedMainGetTrustedMain: dlopen("/usr/local/lib/virtualbox/VirtualBox.so",) failed: /usr/local/lib/libglib-2.0.so.0: Undefined symbol "pthread_setname_np@FBSD_1.6" grahamperrin@momh167-gjp4-8570p:~ % beadm list BE       Active Mountpoint  Space Created Waterfox -      -            1.4G 2020-03-10 18:24 r357746h -      -            1.7G 2020-04-08 09:28 r361769c -      -            2.7G 2020-06-12 13:52 r361769d NR     /           84.7G 2020-06-28 16:02 grahamperrin@momh167-gjp4-8570p:~ % sudo beadm activate r361769c grahamperrin's password: Activated successfully grahamperrin@momh167-gjp4-8570p:~ % ---- On 25/06/2020 16:45, Graham Perrin wrote: Subject: Hardware acceleration lost (?) following pkg upgrade > For me, all recent attempts to upgrade lead to plasmashell using > excessive CPU and frequently crashing. > > Discussion in IRC led to an observation that I'm apparently without > hardware acceleration after these upgrades. For example (GL_RENDERER   > = Software Rasterizer): > > grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v > Wed 24 Jun 2020 11:13:00 BST > FreeBSD 13.0-CURRENT #58 r361769: Thu Jun  4 09:45:38 BST 2020 > root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > grahamperrin@momh167-gjp4-8570p:~ % glxgears -info > GL_RENDERER   = Software Rasterizer > GL_VERSION    = 2.1 Mesa 19.0.8 > GL_VENDOR     = Mesa Project > GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra > GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract > GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object > GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture > GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters > GL_EXT_draw_range_elements GL_EXT_packed_pixels > GL_EXT_point_parameters GL_EXT_rescale_normal > GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp > GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp > GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_multitexture > GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat > GL_3DFX_texture_compression_FXT1 GL_ARB_texture_cube_map > GL_ARB_texture_env_add GL_ARB_transpose_matrix > GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays > GL_EXT_secondary_color GL_EXT_texture_env_add > GL_EXT_texture_filter_anisotropic GL_EXT_texture_lod_bias > GL_INGR_blend_func_separate GL_NV_blend_square > GL_NV_light_max_exponent GL_NV_texgen_reflection > GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays > GL_ARB_texture_border_clamp GL_ARB_texture_compression > GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc > GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos > GL_NV_packed_depth_stencil GL_NV_texture_rectangle > GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow > GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar > GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat > GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side > GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_point_sprite > GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program > GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program > GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 > GL_ATI_texture_float GL_EXT_depth_bounds_test GL_EXT_shadow_funcs > GL_EXT_stencil_wrap GL_MESA_pack_invert GL_MESA_ycbcr_texture > GL_ARB_depth_clamp GL_ARB_fragment_program_shadow > GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite > GL_ARB_shading_language_100 GL_ARB_sync > GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object > GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate > GL_OES_read_format GL_ARB_pixel_buffer_object > GL_ARB_texture_compression_rgtc GL_ARB_texture_float > GL_ARB_texture_rectangle GL_ATI_texture_compression_3dc > GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 > GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp > GL_EXT_texture_rectangle GL_EXT_texture_sRGB > GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object > GL_EXT_framebuffer_blit GL_EXT_packed_depth_stencil > GL_APPLE_object_purgeable GL_ARB_vertex_array_object > GL_ATI_separate_stencil GL_ATI_texture_mirror_once > GL_EXT_draw_buffers2 GL_EXT_draw_instanced > GL_EXT_gpu_program_parameters GL_EXT_texture_array > GL_EXT_texture_compression_latc GL_EXT_texture_sRGB_decode > GL_ARB_copy_buffer GL_ARB_draw_instanced GL_ARB_half_float_vertex > GL_ARB_map_buffer_range GL_ARB_texture_rg GL_ARB_texture_swizzle > GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle > GL_EXT_vertex_array_bgra GL_NV_conditional_render GL_ARB_debug_output > GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location > GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex > GL_ARB_sampler_objects GL_EXT_provoking_vertex > GL_ARB_get_program_binary GL_ARB_robustness > GL_ARB_separate_shader_objects GL_ARB_texture_compression_bptc > GL_ANGLE_texture_compression_dxt3 GL_ANGLE_texture_compression_dxt5 > GL_ARB_compressed_texture_pixel_storage GL_ARB_map_buffer_alignment > GL_ARB_texture_storage GL_AMD_shader_trinary_minmax > GL_ARB_clear_buffer_object GL_ARB_invalidate_subdata > GL_ARB_program_interface_query GL_ARB_vertex_attrib_binding > GL_KHR_debug GL_ARB_multi_bind GL_ARB_texture_mirror_clamp_to_edge > GL_ARB_get_texture_sub_image GL_KHR_context_flush_control > GL_KHR_no_error GL_ARB_texture_filter_anisotropic > VisualID 289, 0x121 > 1454 frames in 5.0 seconds = 290.590 FPS > 1056 frames in 5.0 seconds = 211.197 FPS > X connection to :0 broken (explicit kill or server shutdown). > grahamperrin@momh167-gjp4-8570p:~ % > > /var/log/Xorg.0.log from 21st June in IRC: https://pastebin.com/grYJNQez > > ---- > > After reverting to a non-bugged boot environment: > > grahamperrin@momh167-gjp4-8570p:~ % date ; uname -v > Wed 24 Jun 2020 11:25:27 BST > FreeBSD 13.0-CURRENT #58 r361769: Thu Jun  4 09:45:38 BST 2020 > root@momh167-gjp4-8570p:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG > grahamperrin@momh167-gjp4-8570p:~ % glxgears -info > GL_RENDERER   = llvmpipe (LLVM 8.0, 256 bits) > GL_VERSION    = 3.1 Mesa 19.0.8 > GL_VENDOR     = VMware, Inc. > GL_EXTENSIONS = GL_ARB_multisample GL_EXT_abgr GL_EXT_bgra > GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract > GL_EXT_copy_texture GL_EXT_subtexture GL_EXT_texture_object > GL_EXT_vertex_array GL_EXT_compiled_vertex_array GL_EXT_texture > GL_EXT_texture3D GL_IBM_rasterpos_clip GL_ARB_point_parameters > GL_EXT_draw_range_elements GL_EXT_packed_pixels > GL_EXT_point_parameters GL_EXT_rescale_normal > GL_EXT_separate_specular_color GL_EXT_texture_edge_clamp > GL_SGIS_generate_mipmap GL_SGIS_texture_border_clamp > GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_ARB_framebuffer_sRGB > GL_ARB_multitexture GL_EXT_framebuffer_sRGB > GL_IBM_multimode_draw_arrays GL_IBM_texture_mirrored_repeat > GL_ARB_texture_cube_map GL_ARB_texture_env_add GL_ARB_transpose_matrix > GL_EXT_blend_func_separate GL_EXT_fog_coord GL_EXT_multi_draw_arrays > GL_EXT_secondary_color GL_EXT_texture_env_add GL_EXT_texture_lod_bias > GL_INGR_blend_func_separate GL_NV_blend_square > GL_NV_light_max_exponent GL_NV_texgen_reflection > GL_NV_texture_env_combine4 GL_S3_s3tc GL_SUN_multi_draw_arrays > GL_ARB_texture_border_clamp GL_ARB_texture_compression > GL_EXT_framebuffer_object GL_EXT_texture_compression_s3tc > GL_EXT_texture_env_combine GL_EXT_texture_env_dot3 GL_MESA_window_pos > GL_NV_packed_depth_stencil GL_NV_texture_rectangle > GL_ARB_depth_texture GL_ARB_occlusion_query GL_ARB_shadow > GL_ARB_texture_env_combine GL_ARB_texture_env_crossbar > GL_ARB_texture_env_dot3 GL_ARB_texture_mirrored_repeat > GL_ARB_window_pos GL_ATI_fragment_shader GL_EXT_stencil_two_side > GL_EXT_texture_cube_map GL_NV_depth_clamp GL_NV_fog_distance > GL_APPLE_packed_pixels GL_ARB_draw_buffers GL_ARB_fragment_program > GL_ARB_fragment_shader GL_ARB_shader_objects GL_ARB_vertex_program > GL_ARB_vertex_shader GL_ATI_draw_buffers GL_ATI_texture_env_combine3 > GL_ATI_texture_float GL_EXT_shadow_funcs GL_EXT_stencil_wrap > GL_MESA_pack_invert GL_MESA_ycbcr_texture GL_NV_primitive_restart > GL_ARB_depth_clamp GL_ARB_fragment_program_shadow > GL_ARB_half_float_pixel GL_ARB_occlusion_query2 GL_ARB_point_sprite > GL_ARB_shading_language_100 GL_ARB_sync > GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object > GL_ATI_blend_equation_separate GL_EXT_blend_equation_separate > GL_OES_read_format GL_ARB_color_buffer_float > GL_ARB_pixel_buffer_object GL_ARB_texture_compression_rgtc > GL_ARB_texture_float GL_ARB_texture_rectangle > GL_ATI_texture_compression_3dc GL_EXT_packed_float > GL_EXT_pixel_buffer_object GL_EXT_texture_compression_dxt1 > GL_EXT_texture_compression_rgtc GL_EXT_texture_mirror_clamp > GL_EXT_texture_rectangle GL_EXT_texture_sRGB > GL_EXT_texture_shared_exponent GL_ARB_framebuffer_object > GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample > GL_EXT_packed_depth_stencil GL_ARB_vertex_array_object > GL_ATI_separate_stencil GL_ATI_texture_mirror_once > GL_EXT_draw_buffers2 GL_EXT_draw_instanced > GL_EXT_gpu_program_parameters GL_EXT_texture_array > GL_EXT_texture_compression_latc GL_EXT_texture_integer > GL_EXT_texture_sRGB_decode GL_EXT_timer_query GL_OES_EGL_image > GL_AMD_texture_texture4 GL_ARB_copy_buffer GL_ARB_depth_buffer_float > GL_ARB_draw_instanced GL_ARB_half_float_vertex GL_ARB_instanced_arrays > GL_ARB_map_buffer_range GL_ARB_texture_buffer_object GL_ARB_texture_rg > GL_ARB_texture_swizzle GL_ARB_vertex_array_bgra GL_EXT_texture_swizzle > GL_EXT_vertex_array_bgra GL_NV_conditional_render > GL_AMD_conservative_depth GL_AMD_draw_buffers_blend > GL_AMD_seamless_cubemap_per_texture GL_AMD_shader_stencil_export > GL_ARB_ES2_compatibility GL_ARB_blend_func_extended > GL_ARB_compatibility GL_ARB_debug_output GL_ARB_draw_buffers_blend > GL_ARB_draw_elements_base_vertex GL_ARB_explicit_attrib_location > GL_ARB_fragment_coord_conventions GL_ARB_provoking_vertex > GL_ARB_sampler_objects GL_ARB_seamless_cube_map > GL_ARB_shader_stencil_export GL_ARB_shader_texture_lod > GL_ARB_texture_buffer_object_rgb32 GL_ARB_texture_cube_map_array > GL_ARB_texture_gather GL_ARB_texture_multisample > GL_ARB_texture_query_lod GL_ARB_texture_rgb10_a2ui > GL_ARB_uniform_buffer_object GL_ARB_vertex_type_2_10_10_10_rev > GL_EXT_provoking_vertex GL_EXT_texture_snorm > GL_MESA_texture_signed_rgba GL_ARB_draw_indirect > GL_ARB_get_program_binary GL_ARB_robustness > GL_ARB_separate_shader_objects GL_ARB_shader_bit_encoding > GL_ARB_shader_subroutine GL_ARB_texture_compression_bptc > GL_ARB_timer_query GL_ARB_transform_feedback2 > GL_ARB_transform_feedback3 GL_ARB_viewport_array > GL_AMD_multi_draw_indirect GL_ANGLE_texture_compression_dxt3 > GL_ANGLE_texture_compression_dxt5 GL_ARB_base_instance > GL_ARB_compressed_texture_pixel_storage GL_ARB_conservative_depth > GL_ARB_internalformat_query GL_ARB_map_buffer_alignment > GL_ARB_shading_language_420pack GL_ARB_shading_language_packing > GL_ARB_texture_storage GL_ARB_transform_feedback_instanced > GL_EXT_framebuffer_multisample_blit_scaled GL_EXT_transform_feedback > GL_AMD_shader_trinary_minmax GL_ARB_ES3_compatibility > GL_ARB_arrays_of_arrays GL_ARB_clear_buffer_object GL_ARB_copy_image > GL_ARB_explicit_uniform_location GL_ARB_fragment_layer_viewport > GL_ARB_invalidate_subdata GL_ARB_multi_draw_indirect > GL_ARB_program_interface_query GL_ARB_stencil_texturing > GL_ARB_texture_buffer_range GL_ARB_texture_query_levels > GL_ARB_texture_storage_multisample GL_ARB_texture_view > GL_ARB_vertex_attrib_binding GL_KHR_debug > GL_KHR_texture_compression_astc_ldr GL_ARB_buffer_storage > GL_ARB_clear_texture GL_ARB_enhanced_layouts > GL_ARB_internalformat_query2 GL_ARB_multi_bind > GL_ARB_seamless_cubemap_per_texture > GL_ARB_texture_mirror_clamp_to_edge GL_ARB_texture_stencil8 > GL_ARB_vertex_type_10f_11f_11f_rev GL_EXT_shader_integer_mix > GL_ARB_clip_control GL_ARB_conditional_render_inverted > GL_ARB_cull_distance GL_ARB_direct_state_access > GL_ARB_get_texture_sub_image GL_ARB_pipeline_statistics_query > GL_ARB_transform_feedback_overflow_query GL_EXT_polygon_offset_clamp > GL_KHR_context_flush_control GL_KHR_no_error > GL_KHR_texture_compression_astc_sliced_3d > GL_MESA_shader_integer_functions GL_ARB_polygon_offset_clamp > VisualID 800, 0x320 > 6454 frames in 5.0 seconds = 1290.682 FPS > 8886 frames in 5.0 seconds = 1777.002 FPS > 8847 frames in 5.0 seconds = 1769.343 FPS > X connection to :0 broken (explicit kill or server shutdown). > grahamperrin@momh167-gjp4-8570p:~ % > > ---- > > HP EliteBook 8570p, Thames [Radeon HD 7550M/7570M/7650M] > > Any suggestions? > > TIA From owner-freebsd-current@freebsd.org Mon Jun 29 04:57:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3E1B335DDCA for ; Mon, 29 Jun 2020 04:57:35 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-qb1can01on0616.outbound.protection.outlook.com [IPv6:2a01:111:f400:fe5c::616]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wFbd4xYYz4Jvf; Mon, 29 Jun 2020 04:57:33 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=K9SDrbWpqey989jhZJVi1zSZtcDtv1n59ETC2Wq2TAwr6Ly+zzEmggtCDN6BWrLiIQOHuqznN1+YxRJ6APRjAIVuK524XwOe9uU+JGRas7U8W9gFN2MJX4/RdLtKofE9GxjOQXYKgkvd/j5vLivXcRDmQ/wjOy6dR9GbEfy3QXdG6qaur3kXxF8/zB6y3mbCqqo9sCJvlkYu+tXTyPB4KLpo+4pODJsRmn8xTb2oV3qrLUpVWMu15tpqcNmW87bpwVuNXc/ct5p69+VkZ2mOvUP+n2rYN/X2J9GiNtCE4SKbX0ND1HNKTNbfAjTLnyZL+VShZdDwXcNXBshAiQIy4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9a+JwYRvCOOcS60de0ACIxYB8lj4c0yZDeY4SpBG95s=; b=Je6C63C0i8Np0zvzZOQIqNWQ2iGiSfMw9/3jhbHv2mX0yZselEihykFsIxiRiSPlfKAov3jLmBKahfUOmOBgItD6UqPh3gE9BR6YQXw4CzLQJX8RjjOf2/eojvPC6tJ+5HloU4hwuWhMdndYQQLO312woTlzb9J8xNz5ppqvFDomqegjd92egaSr0wUa0MWbIxpvS5Y8iIx2xvv8KB9VJjGHdBwUJ30fUI7JJlwLwlR3TIkOilJhthw7dtm39l+U3+PCGTlj96gjjXFeyXXX4GE5AODpM0KK8fuLE6yvTSyXM0POQOrp1ANCOCDu1ZpZmKEaSsTD+3LF6Ldq3TCGFw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=9a+JwYRvCOOcS60de0ACIxYB8lj4c0yZDeY4SpBG95s=; b=GvUppEDr/TGgXPoWLD4HL1lol3sgSanmb72J+6ys85cfriQCKavIA4UDmbYblUkm3L7Sp/Mw2aSIWRD8PCTSKADJyq6N5gljRelXn9hu51LT8RGM+HTx0CniYrO4eqs03q3AhxhqUwvRJ6knE1HFuFUndzdp+A/rbUp44yLOlRzOV5A0VY9XSqzZGJQGU+saZSi2dafbQZ7iUup4LfxiiGOVKnSDrKAu9Auonym2QfV32aIjdD+QKruQT55IniW3xwCMVdieRMTTcbwzXCZxCSJ8Hl8K+Hz2BdfVZ3ff/cJXA+ktZa1xpLrzht2OFg1snDNYHhXBErJ+wzkW9su56Q== Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:38::14) by YQXPR01MB3669.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:47::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3131.20; Mon, 29 Jun 2020 04:57:31 +0000 Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91]) by QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91%7]) with mapi id 15.20.3131.026; Mon, 29 Jun 2020 04:57:23 +0000 From: Rick Macklem To: Ryan Libby CC: Konstantin Belousov , Jeff Roberson , "freebsd-current@freebsd.org" Subject: Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc Thread-Topic: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc Thread-Index: AQHWReusQxRwbcmYh0+wsR7fidfwj6jvFvdc Date: Mon, 29 Jun 2020 04:57:23 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6c923ed2-3dfb-4c64-04e8-08d81be8e94c x-ms-traffictypediagnostic: YQXPR01MB3669: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:6430; x-forefront-prvs: 044968D9E1 x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: dzxUN0SQOuSmXLYRYZ5gII/db2viy663VPqGbQrOQtxn6Zc4Urc4+q98OJtqcMSG6MGqNi5MCbDz603iIy2CTI5jCC7FrROp34w5fLnKwFRzFZ0BB3cMDmay6b8npgPpZXDA56UgbXIzakpe4NTORCszu429Yn069fYNkx5FdY6ZtDhiNVMBKiwi6HBW+4RzbPn8pNeormIeQ/nz8PG+9u9Qvnyy3gbQ+I6d3pZbuTyvBIcl5eOhNKcdwwEFglEiHq9Uihu3+bHjL73ZEm02upm8DNkXmEQwLLYLCNGUFDaLD5B6Pxe8xXVMqFjJhLPVIJebvYNP4UfQ/t5x3ySu1m20pOR707wXLy5hR+ZWby3ADIei64jKrXm8MbkbiLQ0neuhhlCTYifxxKEvI4SGNsvxXaGg188GO9WlfWcTXHJM1d5+2Lr8TjT+Y38SuJXMfmyCA2+piA81zuxsNnHUGw== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(136003)(366004)(396003)(39850400004)(376002)(346002)(966005)(7696005)(8676002)(6916009)(86362001)(53546011)(6506007)(2906002)(54906003)(5660300002)(478600001)(8936002)(71200400001)(33656002)(186003)(52536014)(450100002)(4326008)(55016002)(9686003)(316002)(786003)(83380400001)(30864003)(66946007)(66476007)(64756008)(76116006)(66556008)(66446008)(299355004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: cGAehz9fYH9o6crEcCLFHNKc9i/VQLHfvOTWHdpa7+yEDDj+ubSPy9hdV9mSOnufyF9/qMcWE2MFYI/oZDU9HrN75/tqj6amcz/wpJiYeczq9P25yAiOYKVFCxSnaQOeD4y70rrEfPl9s5O8eEoB73S7iTbR90P3XXD0FVu5igKUvlgwuVKndrORJXMptuRp6jK1gLDv3QoKUYqHHrCdeGdFr87cxsO3R5AteKQWu4FRlPg2QLiszbp7y7scErYqHUNINtRXg1Xq7f7QmKIu2SDJKROXC059L2RfORjifkLlhh6z6twXjErcLxTj7lvViMR2YSMBwNmaP/Hevt6xA3Enu84EQHTF5UMpBxYxgwZuR1jIONFdmUH9kQ7dfRnWbYiTx6dYK94mqjKEQMR2pRgGAWDoyUOc0jP7flffOwwlm8zWj3gsTlMwcN8PFzNpacerw0/a1J+wsicL7VitJx3RCn1iIOsNpPQNno7d3V0BvwJCibMeUoDNqHb8ZdKlxEtLoImXZ5O40FKeSEu+92Lcrn/SsrKRqggrdXbxikpFkPHB8t58trgr1HIu30fr x-ms-exchange-transport-forked: True Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 6c923ed2-3dfb-4c64-04e8-08d81be8e94c X-MS-Exchange-CrossTenant-originalarrivaltime: 29 Jun 2020 04:57:23.1702 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: aq/U95HN3Yh20ndzgGFZ79UMqbnMgkt9G8zDsGpL1QGM759OvhVe2a6oKpiqc1iXORPK40cNC4gi5BUMU4Ds7A== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR01MB3669 X-Rspamd-Queue-Id: 49wFbd4xYYz4Jvf X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=GvUppEDr; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 2a01:111:f400:fe5c::616 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.30 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.02)[-1.021]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[text/plain]; R_SPF_ALLOW(-0.20)[+ip6:2a01:111:f400::/48]; DMARC_NA(0.00)[uoguelph.ca]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-0.82)[-0.816]; NEURAL_HAM_LONG(-0.96)[-0.965]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:2a01:111:f000::/36, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 04:57:35 -0000 Just in case you were waiting for another email, I have now run several cycles of the kernel build over NFS on a recent head kernel with the one line change and it has not hung. I don't know if this is the correct fix, but it would be nice to get someth= ing into head to fix this. If I don't hear anything in the next few days, I'll put it in a PR so it doesn't get forgotten. rick ________________________________________ From: owner-freebsd-current@freebsd.org = on behalf of Rick Macklem Sent: Thursday, June 18, 2020 11:42 PM To: Ryan Libby Cc: Konstantin Belousov; Jeff Roberson; freebsd-current@freebsd.org Subject: Re: r358252 causes intermittent hangs where processes are stuck sl= eeping on btalloc Ryan Libby wrote: >On Mon, Jun 15, 2020 at 5:06 PM Rick Macklem wrote: >> >> Rick Macklem wrote: >> >r358098 will hang fairly easily, in 1-3 cycles of the kernel build over= =3D NFS. >> >I thought this was the culprit, since I did 6 cycles of r358097 without= =3D a hang. >> >However, I just got a hang with r358097, but it looks rather different. >> >The r358097 hang did not have any processes sleeping on btalloc. They >> >appeared to be waiting on two different locks in the buffer cache. >> >As such, I think it might be a different problem. (I'll admit I should = h=3D ave >> >made notes about this one before rebooting, but I was flustrated that >> >it happened and rebooted before looking at it mush detail.) >> Ok, so I did 10 cycles of the kernel build over NFS for r358096 and neve= r >> got a hang. >> --> It seems that r358097 is the culprit and r358098 makes it easier >> to reproduce. >> --> Basically runs out of kernel memory. >> >> It is not obvious if I can revert these two commits without reverting >> other ones, since there were a bunch of vm changes after these. >> >> I'll take a look, but if you guys have any ideas on how to fix this, ple= a=3D se >> let me know. >> >> Thanks, rick > >Interesting. Could you try re-adding UMA_ZONE_NOFREE to the vmem btag >zone to see if that rescues it, on whatever base revision gets you a >reliable repro? Good catch! That seems to fix it. I've done 8 cycles of kernel build over NFS without a hang (normally I'd get one in the first 1-3 cycles). I don't know if the intend was to delete UMA_ZONE_VM and r358097 had a typo in it and deleted UMA_ZONE_NOFREE or ??? Anyhow, I just put it back to UMA_ZONE_VM | UMA_ZONE_NOFREE and the hangs seem to have gone away. The small patch I did is attached, in case that isn't what you meant. I'll run a few more cycles just in case, but I think this fixes it. Thanks, rick > > Jeff, to fill you in, I have been getting intermittent hangs on a Pentium= =3D 4 > (single core i386) with 1.25Gbytes ram when doing kernel builds using > head kernels from this winter. (I also saw one when doing a kernel build > on UFS, so they aren't NFS specific, although easier to reproduce that wa= =3D y.) > After a typical hang, there will be a bunch of processes sleeping on "bta= =3D lloc" > and several processes holding the following lock: > exclusive sx lock @ vm/vm_map.c:4761 > - I have seen hangs where that is the only lock held by any process excep= =3D t > the interrupt thread. > - I have also seen processes waiting on the following locks: > kern/subr_vmem.c:1343 > kern/subr_vmem.c:633 > > I can't be absolutely sure r358098 is the culprit, but it seems to make t= =3D he > problem more reproducible. > > If anyone has a patch suggestion, I can test it. > Otherwise, I will continue to test r358097 and earlier, to try and see wh= =3D at hangs > occur. (I've done 8 cycles of testing of r356776 without difficulties, bu= =3D t that > doesn't guarantee it isn't broken.) > > There is a bunch more of the stuff I got for Kostik and Ryan below. > I can do "db" when it is hung, but it is a screen console, so I need to > transcribe the output to email by hand. (ie. If you need something > specific I can do that, but trying to do everything Kostik and Ryan asked > for isn't easy.) > > rick > > > > Konstantin Belousov wrote: > >On Fri, May 22, 2020 at 11:46:26PM +0000, Rick Macklem wrote: > >> Konstantin Belousov wrote: > >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: > >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem = =3D wrote: > >> >> > > >> >> > Hi, > >> >> > > >> >> > Since I hadn't upgraded a kernel through the winter, it took me a= =3D while > >> >> > to bisect this, but r358252 seems to be the culprit. > No longer true. I succeeded in reproducing the hang to-day running a > r358251 kernel. > > I haven't had much luck sofar, but see below for what I have learned. > > >> >> > > >> >> > If I do a kernel build over NFS using my not so big Pentium 4 (si= =3D ngle core, > >> >> > 1.25Gbytes RAM, i386), about every second attempt will hang. > >> >> > When I do a "ps" in the debugger, I see processes sleeping on bta= =3D lloc. > >> >> > If I revert to r358251, I cannot reproduce this. > As above, this is no longer true. > > >> >> > > >> >> > Any ideas? > >> >> > > >> >> > I can easily test any change you might suggest to see if it fixes= =3D the > >> >> > problem. > >> >> > > >> >> > If you want more debug info, let me know, since I can easily > >> >> > reproduce it. > >> >> > > >> >> > Thanks, rick > >> >> > >> >> Nothing obvious to me. I can maybe try a repro on a VM... > >> >> > >> >> ddb ps, acttrace, alltrace, show all vmem, show page would be welco= =3D me. > >> >> > >> >> "btalloc" is "We're either out of address space or lost a fill race= =3D ." > From what I see, I think it is "out of address space". > For one of the hangs, when I did "show alllocks", everything except the > intr thread, was waiting for the > exclusive sx lock @ vm/vm_map.c:4761 > > >> > > >> >Yes, I would be not surprised to be out of something on 1G i386 machi= =3D ne. > >> >Please also add 'show alllocks'. > >> Ok, I used an up to date head kernel and it took longer to reproduce a= =3D hang. > Go down to Kostik's comment about kern.maxvnodes for the rest of what I'v= =3D e > learned. (The time it takes to reproduce one of these varies greatly, but= =3D I usually > get one within 3 cycles of a full kernel build over NFS. I have had it ha= =3D ppen > once when doing a kernel build over UFS.) > > >> This time, none of the processes are stuck on "btalloc". > > I'll try and give you most of the above, but since I have to type it in= =3D by hand > > from the screen, I might not get it all. (I'm no real typist;-) > > > show alllocks > > exclusive lockmgr ufs (ufs) r =3D3D 0 locked @ kern/vfs_subr.c: 3259 > > exclusive lockmgr nfs (nfs) r =3D3D 0 locked @ kern/vfs_lookup.c:737 > > exclusive sleep mutex kernel area domain (kernel arena domain) r =3D3D = 0 =3D locked @ kern/subr_vmem.c:1343 > > exclusive lockmgr bufwait (bufwait) r =3D3D 0 locked @ kern/vfs_bio.c:1= 66=3D 3 > > exclusive lockmgr ufs (ufs) r =3D3D 0 locked @ kern/vfs_subr.c:2930 > > exclusive lockmgr syncer (syncer) r =3D3D 0 locked @ kern/vfs_subr.c:24= 74 > > Process 12 (intr) thread 0x.. (1000008) > > exclusive sleep mutex Giant (Giant) r =3D3D 0 locked @ kern/kern_intr.c= :1=3D 152 > > > > > ps > > - Not going to list them all, but here are the ones that seem interesti= =3D ng... > > 18 0 0 0 DL vlruwt 0x11d939cc [vnlru] > > 16 0 0 0 DL (threaded) [bufdaemon] > > 100069 D qsleep [bufdaemon] > > 100074 D - [bufspacedaemon-0] > > 100084 D sdflush 0x11923284 [/ worker] > > - and more of these for the other UFS file systems > > 9 0 0 0 DL psleep 0x1e2f830 [vmdaemon] > > 8 0 0 0 DL (threaded) [pagedaemon] > > 100067 D psleep 0x1e2e95c [dom0] > > 100072 D launds 0x1e2e968 [laundry: dom0] > > 100073 D umarcl 0x12cc720 [uma] > > =3DE2=3D80=3DA6 a bunch of usb and cam ones > > 100025 D - 0x1b2ee40 [doneq0] > > =3DE2=3D80=3DA6 > > 12 0 0 0 RL (threaded) [intr] > > 100007 I [swi6: task queue] > > 100008 Run CPU 0 [swi6: Giant taskq] > > =3DE2=3D80=3DA6 > > 100000 D swapin 0x1d96dfc [swapper] > > - and a bunch more in D state. > > Does this mean the swapper was trying to swap in? > > > > > acttrace > > - just shows the keyboard > > kdb_enter() at kdb_enter+0x35/frame > > vt_kbdevent() at vt_kdbevent+0x329/frame > > kdbmux_intr() at kbdmux_intr+0x19/frame > > taskqueue_run_locked() at taskqueue_run_locked+0x175/frame > > taskqueue_run() at taskqueue_run+0x44/frame > > taskqueue_swi_giant_run(0) at taskqueue_swi_giant_run+0xe/frame > > ithread_loop() at ithread_loop+0x237/frame > > fork_exit() at fork_exit+0x6c/frame > > fork_trampoline() at 0x../frame > > > > > show all vmem > > vmem 0x.. 'transient arena' > > quantum: 4096 > > size: 23592960 > > inuse: 0 > > free: 23592960 > > busy tags: 0 > > free tags: 2 > > inuse size free size > > 16777216 0 0 1 23592960 > > vmem 0x.. 'buffer arena' > > quantum: 4096 > > size: 94683136 > > inuse: 94502912 > > free: 180224 > > busy tags: 1463 > > free tags: 3 > > inuse size free size > > 16384 2 32768 1 16384 > > 32768 39 1277952 1 32768 > > 65536 1422 93192192 0 0 > > 131072 0 0 1 131072 > > vmem 0x.. 'i386trampoline' > > quantum: 1 > > size: 24576 > > inuse: 20860 > > free: 3716 > > busy tags: 9 > > free tags: 3 > > inuse size free size > > 32 1 48 1 52 > > 64 2 208 0 0 > > 128 2 280 0 0 > > 2048 1 2048 1 3664 > > 4096 2 8192 0 0 > > 8192 1 10084 0 0 > > vmem 0x.. 'kernel rwx arena' > > quantum: 4096 > > size: 0 > > inuse: 0 > > free: 0 > > busy tags: 0 > > free tags: 0 > > vmem 0x.. 'kernel area dom' > > quantum: 4096 > > size: 56623104 > > inuse: 56582144 > >> free: 40960 > >> busy tags: 11224 > >> free tags: 3 > >I think this is the trouble. > > > >Did you tried to reduce kern.maxvnodes ? What is the default value for > >the knob on your machine ? > The default is 84342. > I have tried 64K, 32K and 128K and they all hung sooner or later. > For the 32K case, I did see vnodes being recycled for a while before it g= =3D ot hung, > so it isn't just when it hits the limit. > > Although it is much easier for me to reproduce on an NFS mount, I did see > a hang while doing a kernel build on UFS (no NFS mount on the machine at > that time). > > So, I now know that the problem pre-dates r358252 and is not NFS specific= =3D . > > I'm not bisecting back further to try and isolate the commit that causes = =3D this. > (Unfortunately, each test cycle can take days. I now know that I have to = =3D do > several of these kernel builds, which take hours each, to see if a hang i= =3D s going > to happen.) > > I'll post if/when I have more, rick > > We scaled maxvnodes for ZFS and UFS, might be NFS is even more demanding, > having larger node size. > > > inuse size free size > > 4096 11091 45428736 0 0 > > 8192 63 516096 0 0 > > 16384 12 196608 0 0 > > 32768 6 196608 0 0 > > 40960 2 81920 1 40960 > > 65536 16 1048576 0 0 > > 94208 1 94208 0 0 > > 110592 1 110592 0 0 > > 131072 15 2441216 0 0 > > 262144 15 3997696 0 0 > > 524288 1 524288 0 0 > > 1048576 1 1945600 0 0 > > vmem 0x.. 'kernel arena' > > quantum: 4096 > > size: 390070272 > > inuse: 386613248 > > free: 3457024 > > busy tags: 873 > > free tags: 3 > > inuse size free size > > 4096 35 143360 1 4096 > > 8192 2 16384 2 16384 > > 12288 1 12288 0 0 > > 16384 30 491520 0 0 > > 20480 140 2867200 0 0 > > 65536 1 65536 0 0 > > 131072 631 82706432 0 0 > > 1048576 0 0 1 1339392 > > 2097152 27 56623104 1 2097152 > > 8388608 1 13774848 0 0 > > 16777216 3 74883072 0 0 > > 33554432 1 36753408 0 0 > > 67108864 1 118276096 0 0 > > > > > alltrace > > - I can't face typing too much more, but I'll put a few > > here that look interesting > > > > - for csh > > sched_switch() > > mi_switch() > > kern_yield() > > getblkx() > > breadn_flags() > > ffs_update() > > ufs_inactive() > > VOP_INACTIVE() > > vinactivef() > > vput_final() > > vm_object_deallocate() > > vm_map_process_deferred() > > kern_munmap() > > sys_munmap() > > > > - For cc > > sched_switch() > > mi_switch() > > sleepq_switch() > > sleepq_timedwait() > > _sleep() > > pause_sbt() > > vmem_bt_alloc() > > keg_alloc_slab() > > zone_import() > > cache_alloc() > > cache_alloc_retry() > > uma_zalloc_arg() > > bt_fill() > > vmem_xalloc() > > vmem_alloc() > > kmem_alloc() > > kmem_malloc_domainset() > > page_alloc() > > keg_alloc_slab() > > zone_import() > > cache_alloc() > > cache_alloc_retry() > > uma_zalloc_arg() > > nfscl_nget() > > nfs_create() > > vop_sigdefer() > > nfs_vnodeops_bypass() > > VOP_CREATE_APV() > > vn_open_cred() > > vn_open() > > kern_openat() > > sys_openat() > > > > Then there are a bunch of these... for cc, make > > sched_switch() > > mi_switch() > > sleepq_switch() > > sleepq_catch_signals() > > sleepq_wait_sig() > > kern_wait6() > > sys_wait4() > > > > - for vnlru > > sched_switch() > > mi_switch() > > sleepq_switch() > > sleepq_timedwait() > > _sleep() > > vnlru_proc() > > fork_exit() > > fork_trampoline() > > > > - for syncer > > sched_switch() > > mi_switch() > > critical_exit_preempt() > > intr_event_handle() > > intr_execute_handlers() > > lapic_handle_intr() > > Xapic_isr1() > > - interrupt > > memset() > > cache_alloc() > > cache_alloc_retry() > > uma_zalloc_arg() > > vmem_xalloc() > > vmem_bt_alloc() > > keg_alloc_slab() > > zone_import() > > cache_alloc() > > cache_alloc_retry() > > uma_zalloc_arg() > > bt_fill() > > vmem_xalloc() > > vmem_alloc() > > bufkva_alloc() > > getnewbuf() > > getblkx() > > breadn_flags() > > ffs_update() > > ffs_sync() > > sync_fsync() > > VOP_FSYNC_APV() > > sched_sync() > > fork_exit() > > fork_trampoline() > > > > - For bufdaemon (a bunch of these) > > sched_switch() > > mi_switch() > > sleepq_switch() > > sleepq_timedwait() > > _sleep() > > buf_daemon() > > fork_exit() > > fork_trampoline() > > > > vmdaemon and pagedaemon are basically just like above, > > sleeping in > > vm_daemon() > > or > > vm_pageout_worker() > > or > > vm_pageout_laundry_worker() > > or > > uma_reclaim_worker() > > > > That's all the typing I can take right now. > > I can probably make this happen again if you want more specific stuff. > > > > rick > > > > > > > > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= =3D " > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= =3D " > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org From owner-freebsd-current@freebsd.org Mon Jun 29 07:03:45 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 5ED88340BAF for ; Mon, 29 Jun 2020 07:03:45 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.19]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wJPD1dKYz4R98 for ; Mon, 29 Jun 2020 07:03:43 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593414220; bh=03e4su8TvRN1gyH3pwp5Dtk/0KeqsoXsOJCoOgASrLA=; h=X-UI-Sender-Class:Date:From:To:Subject; b=NancXb1Ax9ipA7RNi50psQR/PG67zsPN+8Mr7lvSwYA9iiP8gOXCd9vG8fOd3n+Fr PhIU8BTurmvwcYmcxeRtX6tJDPp+dKVIcUfaCG9muZk1tyY/Jq4epEo0w7few6qldF 6XQ+SJTNRikV3TGJf4iuKL5GPIPDVFAklLQ0FPV4= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from freyja ([79.192.169.141]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MvbBk-1j0acM1Eu6-00scv2 for ; Mon, 29 Jun 2020 09:03:40 +0200 Date: Mon, 29 Jun 2020 09:03:32 +0200 From: "O. Hartmann" To: freebsd-current Subject: CURRENT: swap issues and dying jails Message-ID: <20200629090326.63b4830b@freyja> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Provags-ID: V03:K1:+8g8uGeMKO0xPEhE0VmdWT9PFn2VOXPlYReeIyBSmwmLSbBgK4c hETGWYkwK4e28Y4vyU0DfumN6Jditmb5/FllnXaEm8nmCJg0HEmJX38AfAiI2xS4bme/7dO lflpsODnSLrmwLTAdh/oHrv1pyko1DwbCdPWyZU1D+MeT/KydIfUXoEBD7NQxD3KIIe/o23 diP+2iDo7I9ueULJMzcYQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:HSuKk58AT/g=:UalXEt7nCPCFVpTfIE+YcQ kDfzG77UIYBqTgt47wBp53adyeq61xDTjQQvmwxeneUaKfF547FZhmXPet47jLhnmJwCU41Bm DlAlsQCCI6ympGoen6wRvGs2qwyrCPbGPOHDH4s+KNnu/t0nwyJXBNO9QL3eBLGYund1JPs9u iKuTxfVQbs3Unva91Pvxror7Hy44TL1/tVN/86Q/4Tky0AG+cP+hBSTtyI/bqvKb2FXdmbhU4 SYdnpz1QPf0wJX+ZOeq/qkXWURVazokDeQ2VvOZFfjeKRzJzXwD9hr6BKrpJbZf9MX4dmRpyC HlJ05TgSMO/1VVva+TzEYYPiI0f0p/GlZrM8JcSMuvMqgKB1fg4fLoxv0OppNkq5PtukS4i0S dEtCYTqnpkDPsCU3jgD8FlWxLiLAX3ZonXR/Sb3+cP2VovZQTDpZ3HqQYhTo+gG2ZZK87GLy0 4bukguDCneJVkbpfq9AEOR0MUvBQiDYznkO1gxNOr444hwxz5RneUEUhlUSRC1CFtqpNhDGXl TbM44oDNyv7rWGrrTermBHTI/YYyaKy40Vh3vfoyUPAeyBV/Ek8swDg7htNeskR8RIkhSX/v3 VDXw/FBvJTlFpnebS7ynsE2xRWMc31b+F8qGL2Cz2phqM8XZRc+bzEuHsE/FCt/jGaK0pIOul p2wuaj/QnnQcLjAk0G+uNiI/wAeOJ9vjDKypjzEwRD/T8pFCA/Fd/+ipuydGu2u9XfwmMKYut kCO2/1CYHYMcPeLCbODnpv+5rACS709k2rDNie5X1FF96vIMmJZtIdei1z8kmxvkLWOmKJ0tV wvPHFxhYHRPGMIFV68+cEhA+v+6YRJ2H5+S1FBMT2lL5FhkoBlxkks8XYohFKGYc9zqliDLaK G+R3A5N4RKrEKeLkdZupiAvpVen+j+TyPEDADZNbOQsnLEBAnTCe7m6+fv4cfRABsNoxgIsBX LBbNup3anDQ+I35UKdbnbiKjkGLD+DnHB+IGe60rj7F71FemyIenIHNRKIhTijohRB2+qhFci p/HbWYyV32rRyvszDi32VnNR+a8wU4QQLyuEd7Ii6oRolMpm467BPUx+Z1S4mpQZQtvDSZx/m +eWxX56cPeyjNMEoW1q+Ktq+MJdqXyNV9oHwUQrHK33kAncr39E8UR0cPh8C1sR68yGXN0/8I KLa7++1slQfc7OcXb78o506pK9O/QoADjJ1a0Lfypt0gGld9sAAv2pVsZlFNDmODsa1LES/+3 IoYoZVYoDw+J0og1/clf0BEmaD+w4TIsoDOJNYw== X-Rspamd-Queue-Id: 49wJPD1dKYz4R98 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=NancXb1A; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.15.19) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-0.50 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.19:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.48)[-0.484]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; RECEIVED_SPAMHAUS_PBL(0.00)[79.192.169.141:received]; NEURAL_HAM_MEDIUM(-0.37)[-0.368]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; NEURAL_SPAM_SHORT(0.25)[0.252]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; MID_RHS_NOT_FQDN(0.50)[]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.19:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 07:03:45 -0000 Due to the circumstance I have no access anymore to the host in question, I'll report a problem occured out of the blue around last week's update of CURRENT with poudriere and swapspace. Problem: under heavy load, the host dies - no ssh connection possible anymore, all jails are in the state "dead". The box in question is running CURRENT, most recent, last update yesterday morning (28th of June, around 1400 UTC). Revision numbers are added as soon I have access to the box again. The host has 16 GB phsyical RAM and 64 GB configured swap - which the kernel complains about to increase swapzone or something similar. The host runs poudriere with both CURRENT and 12-STABLE jails (both recent versions). In the past 18 months we pushed the box to the limits with poudriere allwoing 4 poudriere jobs with each 4 threads - never had any problem except slowing down the system, but always responsive anyhow and never crashing or loosing network connection. The first time the box died this way was 28th, after the last update of both host and jails has been performed 26th June, ~ 1400 UTC. Jails running 12-stable are the first poudriere jobs running and that is the state were the first crash/hung occured yesterday. Is this a known problem? Kind regards, oliver From owner-freebsd-current@freebsd.org Mon Jun 29 08:03:38 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3F4DE341B71 for ; Mon, 29 Jun 2020 08:03:38 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (static-24-113-41-81.wavecable.com [24.113.41.81]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "ultimatedns.net", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wKkK6z6fz4VJC for ; Mon, 29 Jun 2020 08:03:37 +0000 (UTC) (envelope-from bsd-lists@BSDforge.com) Received: from udns.ultimatedns.net (localhost [IPv6:0:0:0:0:0:0:0:1]) by udns.ultimatedns.net (8.15.2/8.15.2) with ESMTPS id 05T83aNx058932 (version=TLSv1.2 cipher=DHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 29 Jun 2020 01:03:42 -0700 (PDT) (envelope-from bsd-lists@BSDforge.com) X-Mailer: Cypht MIME-Version: 1.0 Cc: "O. Hartmann" In-Reply-To: <20200629090326.63b4830b@freyja> From: Chris Reply-To: bsd-lists@BSDforge.com To: freebsd-current Subject: Re: CURRENT: swap issues and dying jails Date: Mon, 29 Jun 2020 01:03:42 -0700 Message-Id: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 49wKkK6z6fz4VJC X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:11404, ipnet:24.113.0.0/16, country:US]; local_wl_ip(0.00)[24.113.41.81] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 08:03:38 -0000 On Mon, 29 Jun 2020 09:03:32 +0200 O=2E Hartmann ohartmann@walstatt=2Eorg said > Due to the circumstance I have no access anymore to the host in question, > I'll > report a problem occured out of the blue around last week's update of > CURRENT > with poudriere and swapspace=2E >=20 > Problem: under heavy load, the host dies - no ssh connection possible > anymore, > all jails are in the state "dead"=2E > The box in question is running CURRENT, most recent, last update yesterda= y > morning (28th of June, around 1400 UTC)=2E Revision numbers are added as so= on > I > have access to the box again=2E >=20 > The host has 16 GB phsyical RAM and 64 GB configured swap - which the ker= nel > complains about to increase swapzone or something similar=2E The host runs > poudriere with both CURRENT and 12-STABLE jails (both recent versions)=2E I= n > the > past 18 months we pushed the box to the limits with poudriere allwoing 4 > poudriere jobs with each 4 threads - never had any problem except slowing > down > the system, but always responsive anyhow and never crashing or loosing > network > connection=2E >=20 > The first time the box died this way was 28th, after the last update of b= oth > host and jails has been performed 26th June, ~ 1400 UTC=2E Jails running > 12-stable are the first poudriere jobs running and that is the state were > the > first crash/hung occured yesterday=2E >=20 > Is this a known problem? There was a situation very similar to yours mentioned over the last week on freebsd-stable@=2E By Donald Wilde, under the title: swap space issues I believe he also used 12=2E There was a great deal of technical advice that appeared to improve his situation=2E Interestingly; he was also experiencing this on his "builder" altho he was using synth as opposed to poudriere=2E Maybe it'll help your situation? --Chris >=20 > Kind regards, >=20 > oliver > _______________________________________________ > freebsd-current@freebsd=2Eorg mailing list > https://lists=2Efreebsd=2Eorg/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd=2Eorg= " From owner-freebsd-current@freebsd.org Mon Jun 29 17:26:28 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id DAB2434F32F for ; Mon, 29 Jun 2020 17:26:28 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wZCm5SpWz46K4 for ; Mon, 29 Jun 2020 17:26:28 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p548612f6.dip0.t-ipconnect.de [84.134.18.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 5D468188BF for ; Mon, 29 Jun 2020 17:26:28 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 29 Jun 2020 19:26:26 +0200 From: Gordon Bergling To: freebsd-current@freebsd.org Subject: Undeletable files after kyua test runs Message-ID: <20200629172626.GA63722@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 7:12PM up 2 days, 5:56, 5 users, load averages: 1.13, 1.08, 1.07 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 17:26:28 -0000 Hi, I recently stumbled across undeletable files that are generated by kyua test runs, for example -rwxr-xr-x 1 root wheel 0 May 9 13:10 /tmp/kyua.aB4q62/8676/work/fileforaudit I haven't yet identified the test that generate those files, but it is impossible to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but on every boot the system argues that these file aren't deletable. I tried to 'rm -rf' them by hand but, even this wasn't possible. I have looked for any extend attributes, but I didn't find any. Has anyone an idea how this is possible and may how these files can be deleted? --Gordon From owner-freebsd-current@freebsd.org Mon Jun 29 17:32:56 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id D473534F994 for ; Mon, 29 Jun 2020 17:32:56 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: from mail-ot1-x32a.google.com (mail-ot1-x32a.google.com [IPv6:2607:f8b0:4864:20::32a]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wZMD3YwGz471R; Mon, 29 Jun 2020 17:32:56 +0000 (UTC) (envelope-from kob6558@gmail.com) Received: by mail-ot1-x32a.google.com with SMTP id 18so16250564otv.6; Mon, 29 Jun 2020 10:32:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jPBSrg5sg8kVH1WnPM3gUVwZ1Cu/CuMWQcDnPN11+Kk=; b=RsULrzxfv/6lvxyFw1DmEfdJdFETEetDB/BFobpoYMqauvryVGqGFmh02S1ItLbP5Y r++pRpRZzL0fFMvPtm5ozWmrDeh7mwO1nSyaC0Jng9mtto3sW8CtOm6SPZCd5RwHhqPG qPTdaP+Z5QX7oGWK2B6wvhvOQocHOhDaq/3hVrIrLhdNub2fTWi6dPsjQq3X/mfr6i8k 9Mqb0H+ipLHcZpVWt2+KjTLeU3qcZJrTTOtPoD5+ITI8bIYozMaP1q9gBfYNobubGIhC 6LGyfnH3qYa90/DMEYOMiIRMFEN+TDPzoHv2ba8jCHdeCAxHEBeBVzC6D+yYlMorQws3 d7kA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jPBSrg5sg8kVH1WnPM3gUVwZ1Cu/CuMWQcDnPN11+Kk=; b=C6fuq5LDCbrLuL2EphwrItcWghtTtIYS+W6eaXwmeZOWOA/jKC5xN+Xkxk+u8NGvHM aLDsKEY4dj/wHT0lzCdJcu8mlNny+3pE5XdcGGEZA0/IIyK4BIqn2g7lkrnDP3HC8J9h JOB6pfOsqZQ5M2D+F7cKHce9mQW7wYXL3o2GhbHedyCM7alyvN74HrDd18KE2p1Jji6V Z/E2lUVwqBRNtEUGZVHYNT5fPf/42YlvX48lmlu9/qa4tEW/+RKckngVjp63zWcfGeUX dql+K3DrnpMvea9fSDc6sr8gnWmAyyt/nqrQKkkFZ8ac/872eG4DkmiU7zE9l7J0dNRW eH9Q== X-Gm-Message-State: AOAM531zJe+TVjQcd75gbbC31eifZXHTjT9NBT2RbaCSbnis2Iw6CAds wVF7K13+zr4cjWr8xEdmj+5je7yvVKsn/WLZEHzcpjmGF10= X-Google-Smtp-Source: ABdhPJwsUJrKY5xNmrv35NqVC8aNNHzABIiiT8TBrvY/z81ccanhntECN0DFovqh5webQJxXpOT+VCq5B9zJpRvkdZk= X-Received: by 2002:a9d:3a24:: with SMTP id j33mr14131281otc.271.1593451974883; Mon, 29 Jun 2020 10:32:54 -0700 (PDT) MIME-Version: 1.0 References: <20200629172626.GA63722@lion.0xfce3.net> In-Reply-To: <20200629172626.GA63722@lion.0xfce3.net> From: Kevin Oberman Date: Mon, 29 Jun 2020 10:32:38 -0700 Message-ID: Subject: Re: Undeletable files after kyua test runs To: Gordon Bergling Cc: FreeBSD Current X-Rspamd-Queue-Id: 49wZMD3YwGz471R X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; REPLY(-4.00)[]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US] Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 17:32:56 -0000 On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > Hi, > > I recently stumbled across undeletable files that are generated by kyua > test runs, > for example > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > /tmp/kyua.aB4q62/8676/work/fileforaudit > > I haven't yet identified the test that generate those files, but it is > impossible > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > on every boot the system argues that these file aren't deletable. > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > looked for > any extend attributes, but I didn't find any. > > Has anyone an idea how this is possible and may how these files can be > deleted? > > --Gordon Have you done 'ls -o' to check for flags like schg? -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkoberman@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 From owner-freebsd-current@freebsd.org Mon Jun 29 17:42:14 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id A5AD134FC6F for ; Mon, 29 Jun 2020 17:42:14 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wZYy3ynXz47Y7; Mon, 29 Jun 2020 17:42:14 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p548612f6.dip0.t-ipconnect.de [84.134.18.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 1619C18E81; Mon, 29 Jun 2020 17:42:13 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 29 Jun 2020 19:42:12 +0200 From: Gordon Bergling To: Kevin Oberman Cc: FreeBSD Current , david@catwhisker.org Subject: Re: Undeletable files after kyua test runs Message-ID: <20200629174212.GA80071@lion.0xfce3.net> References: <20200629172626.GA63722@lion.0xfce3.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 7:37PM up 2 days, 6:22, 6 users, load averages: 1.38, 1.13, 1.09 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 17:42:14 -0000 Hi Kevin, Hi David, On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > I recently stumbled across undeletable files that are generated by kyua > > test runs, > > for example > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > I haven't yet identified the test that generate those files, but it is > > impossible > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > > on every boot the system argues that these file aren't deletable. > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > > looked for > > any extend attributes, but I didn't find any. > > > > Has anyone an idea how this is possible and may how these files can be > > deleted? > > Have you done 'ls -o' to check for flags like schg? > -- > Kevin Oberman, Part time kid herder and retired Network Engineer > E-mail: rkoberman@gmail.com > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 Argh, I haven't thought about chflags for quite some time. The chflags bit was set and after an # find /tmp/ -type f -exec chflags -R 0 {} \; I was able to finally delete them. Thanks for the fast respone, Gordon From owner-freebsd-current@freebsd.org Mon Jun 29 18:59:14 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 4B6C635223F for ; Mon, 29 Jun 2020 18:59:14 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (br1.CN84in.dnsmgr.net [69.59.192.140]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49wcGn5FVmz4Dkb; Mon, 29 Jun 2020 18:59:13 +0000 (UTC) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: from gndrsh.dnsmgr.net (localhost [127.0.0.1]) by gndrsh.dnsmgr.net (8.13.3/8.13.3) with ESMTP id 05TIwlal048487; Mon, 29 Jun 2020 11:58:47 -0700 (PDT) (envelope-from freebsd-rwg@gndrsh.dnsmgr.net) Received: (from freebsd-rwg@localhost) by gndrsh.dnsmgr.net (8.13.3/8.13.3/Submit) id 05TIwlGL048486; Mon, 29 Jun 2020 11:58:47 -0700 (PDT) (envelope-from freebsd-rwg) From: "Rodney W. Grimes" Message-Id: <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> Subject: Re: Undeletable files after kyua test runs In-Reply-To: <20200629174212.GA80071@lion.0xfce3.net> To: Gordon Bergling Date: Mon, 29 Jun 2020 11:58:47 -0700 (PDT) CC: Kevin Oberman , FreeBSD Current , david@catwhisker.org X-Mailer: ELM [version 2.4ME+ PL121h (25)] MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=US-ASCII X-Rspamd-Queue-Id: 49wcGn5FVmz4Dkb X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:13868, ipnet:69.59.192.0/19, country:US]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 18:59:14 -0000 > Hi Kevin, > Hi David, > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > > I recently stumbled across undeletable files that are generated by kyua > > > test runs, > > > for example > > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > > > I haven't yet identified the test that generate those files, but it is > > > impossible > > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > > > on every boot the system argues that these file aren't deletable. > > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > > > looked for > > > any extend attributes, but I didn't find any. > > > > > > Has anyone an idea how this is possible and may how these files can be > > > deleted? > > > > Have you done 'ls -o' to check for flags like schg? > > -- > > Kevin Oberman, Part time kid herder and retired Network Engineer > > E-mail: rkoberman@gmail.com > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > Argh, I haven't thought about chflags for quite some time. The chflags > bit was set and after an > > # find /tmp/ -type f -exec chflags -R 0 {} \; ^^Only files ^^ meaningless when chflags is given ONLY files You probably could of done: chflags -R 0 /tmp/ > > I was able to finally delete them. > > Thanks for the fast respone, > > Gordon > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > -- Rod Grimes rgrimes@freebsd.org From owner-freebsd-current@freebsd.org Mon Jun 29 19:08:58 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0352A35274B for ; Mon, 29 Jun 2020 19:08:58 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wcV16JGtz4Fkx; Mon, 29 Jun 2020 19:08:57 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p548612f6.dip0.t-ipconnect.de [84.134.18.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 796BA194DD; Mon, 29 Jun 2020 19:08:57 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 29 Jun 2020 21:08:56 +0200 From: Gordon Bergling To: "Rodney W. Grimes" Cc: Gordon Bergling , Kevin Oberman , FreeBSD Current , david@catwhisker.org Subject: Re: Undeletable files after kyua test runs Message-ID: <20200629190856.GA44618@lion.0xfce3.net> References: <20200629174212.GA80071@lion.0xfce3.net> <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 8:59PM up 2 days, 7:44, 5 users, load averages: 1.23, 1.17, 1.10 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:08:58 -0000 On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling wrote: > > > > I recently stumbled across undeletable files that are generated by kyua > > > > test runs, > > > > for example > > > > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > > > > > I haven't yet identified the test that generate those files, but it is > > > > impossible > > > > to delete them. I have clear_tmp_enable="YES" set in the /etc/rc.conf, but > > > > on every boot the system argues that these file aren't deletable. > > > > I tried to 'rm -rf' them by hand but, even this wasn't possible. I have > > > > looked for > > > > any extend attributes, but I didn't find any. > > > > > > > > Has anyone an idea how this is possible and may how these files can be > > > > deleted? > > > > > > Have you done 'ls -o' to check for flags like schg? > > > -- > > > Kevin Oberman, Part time kid herder and retired Network Engineer > > > E-mail: rkoberman@gmail.com > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > > Argh, I haven't thought about chflags for quite some time. The chflags > > bit was set and after an > > > > # find /tmp/ -type f -exec chflags -R 0 {} \; > ^^Only files ^^ meaningless when chflags is given ONLY files > > You probably could of done: > chflags -R 0 /tmp/ Okay, I am currently working on an update for clear_tmp_enable="YES" to include a check like this. I would think that an rc option like this should delete everything in /tmp. > > I was able to finally delete them. > > > > Thanks for the fast respone, > > > > Gordon --Gordon From owner-freebsd-current@freebsd.org Mon Jun 29 19:18:18 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 86E93352C2F for ; Mon, 29 Jun 2020 19:18:18 +0000 (UTC) (envelope-from ian@freebsd.org) Received: from outbound2k.ore.mailhop.org (outbound2k.ore.mailhop.org [54.148.219.64]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49wchn6dp8z4GRZ for ; Mon, 29 Jun 2020 19:18:17 +0000 (UTC) (envelope-from ian@freebsd.org) ARC-Seal: i=1; a=rsa-sha256; t=1593458296; cv=none; d=outbound.mailhop.org; s=arc-outbound20181012; b=iD304tpprtM/1lgYCj6deCKhNUMfMwqgoQi91WNOQunBm+gfImfs1OSOkPO8gNT03oMaOjpCom8p6 KILXPl3yF5rnKPLqA1P7F3bkGfHabhqhKux7va95wYFI0m9+c1m2kqp4tvyNUF2U0n4oH1Jw4tMczA A1p3GUCtM9dvbr1ozD4DFe1Z5Ggl/ISBgOpUisVJHRGYqKqxN/9zZF99764Iv7Gfvusmlk2jJQfACf o1gAfh/SGTSAINTuJR/R/NrWgQ+d2XPUzlHX8qkJTa6AlEb4y43buztonXeLORjHpTgxEcWrwCZ2QT zjnHpJxkI6+0f3/VZN9NVlUNeS4CH2w== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=arc-outbound20181012; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:dkim-signature:from; bh=XOaYVOJlRbOl5UZrDoiuWIU1AZyOJwDJ6K7DkfIQajA=; b=iOS9EYav/Id4IKzacoDJ5ngBLRnwHGUGc01JG3HGzIWN2/3A121mM8FAD1DqyQkZUp9Cg2OTrsTZJ loo+U2GiwBltXVaPcaiXcB1R58A85S1FByi9kx3I88PIMQN8ginLKKq6/MaXES8QihqF0evov+CHhN ZWojkZxH4w3qkAj+F36mXxsmIfloRuaydvkZiP6yUMg+qyuU3ca39iFIJnYYgSJO21huEKmwj0TTsq /DmKxr/39mG/bp++va3nIUoRdp4aSEEXPFhiqvjvMNXVnjW0gOCiwW49mIN/C3PcF7HCtmT8iepzUa Axc/cP5QVhFYUPNOFAnLxhbxMhenomw== ARC-Authentication-Results: i=1; outbound4.ore.mailhop.org; spf=softfail smtp.mailfrom=freebsd.org smtp.remote-ip=67.177.211.60; dmarc=none header.from=freebsd.org; arc=none header.oldest-pass=0; DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outbound.mailhop.org; s=dkim-high; h=content-transfer-encoding:mime-version:content-type:references:in-reply-to: date:cc:to:from:subject:message-id:from; bh=XOaYVOJlRbOl5UZrDoiuWIU1AZyOJwDJ6K7DkfIQajA=; b=EI1dQQ5r/jXaie10iXI/KGiuyNMeGWMXYQTKAj5IgxqhzgY0vdFpfKK9DqA9c/l/sXGYnwRsrbxm4 obc+GtAn33DUINWlxIEKdC7SiE6WW3w4VfzaqraU0lZMkXLB34+vnll3Su2RtCWUsZPQNAuyP8v+PE s+msj9LzcJWSPRG+8lgN3wSb5s1PgCffYTvrS3K0W+Kt3fwlIwzVarDT4r1dEsXetk0GuBwvFA5baU uUi7w2j4IbjotfrVLQR6Utrx/AAXj11uIjdm8lGLJMXM0lKUii8c2wEs+Ba/J1gaZZXPMCpJtVhmvp EXAc1kX519RYWpQXrsrwaL/+90F0F+g== X-MHO-RoutePath: aGlwcGll X-MHO-User: 46c36b56-ba3d-11ea-b630-6b8aa7872eb8 X-Report-Abuse-To: https://support.duocircle.com/support/solutions/articles/5000540958-duocircle-standard-smtp-abuse-information X-Originating-IP: 67.177.211.60 X-Mail-Handler: DuoCircle Outbound SMTP Received: from ilsoft.org (c-67-177-211-60.hsd1.co.comcast.net [67.177.211.60]) by outbound4.ore.mailhop.org (Halon) with ESMTPSA id 46c36b56-ba3d-11ea-b630-6b8aa7872eb8; Mon, 29 Jun 2020 19:18:15 +0000 (UTC) Received: from rev (rev [172.22.42.240]) by ilsoft.org (8.15.2/8.15.2) with ESMTP id 05TJICVc085702; Mon, 29 Jun 2020 13:18:12 -0600 (MDT) (envelope-from ian@freebsd.org) Message-ID: <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> Subject: Re: Undeletable files after kyua test runs From: Ian Lepore To: Gordon Bergling , "Rodney W. Grimes" Cc: Kevin Oberman , FreeBSD Current , david@catwhisker.org Date: Mon, 29 Jun 2020 13:18:12 -0600 In-Reply-To: <20200629190856.GA44618@lion.0xfce3.net> References: <20200629174212.GA80071@lion.0xfce3.net> <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> <20200629190856.GA44618@lion.0xfce3.net> Content-Type: text/plain; charset="ASCII" X-Mailer: Evolution 3.28.5 FreeBSD GNOME Team Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 49wchn6dp8z4GRZ X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:16509, ipnet:54.148.0.0/15, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:18:18 -0000 On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote: > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling < > > > > gbe@freebsd.org> wrote: > > > > > I recently stumbled across undeletable files that are > > > > > generated by kyua > > > > > test runs, > > > > > for example > > > > > > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > > > > > > > I haven't yet identified the test that generate those files, > > > > > but it is > > > > > impossible > > > > > to delete them. I have clear_tmp_enable="YES" set in the > > > > > /etc/rc.conf, but > > > > > on every boot the system argues that these file aren't > > > > > deletable. > > > > > I tried to 'rm -rf' them by hand but, even this wasn't > > > > > possible. I have > > > > > looked for > > > > > any extend attributes, but I didn't find any. > > > > > > > > > > Has anyone an idea how this is possible and may how these > > > > > files can be > > > > > deleted? > > > > > > > > Have you done 'ls -o' to check for flags like schg? > > > > -- > > > > Kevin Oberman, Part time kid herder and retired Network > > > > Engineer > > > > E-mail: rkoberman@gmail.com > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > > > > Argh, I haven't thought about chflags for quite some time. The > > > chflags > > > bit was set and after an > > > > > > # find /tmp/ -type f -exec chflags -R 0 {} \; > > > > ^^Only files ^^ meaningless when chflags is > > given ONLY files > > > > You probably could of done: > > chflags -R 0 /tmp/ > > Okay, I am currently working on an update for clear_tmp_enable="YES" > to include > a check like this. I would think that an rc option like this should > delete > everything in /tmp. > I disagree. One of the few things those immutable flags are good for is protecting files from things like an rc script or other automation that deletes files. Those flags are typically set and maintained by users and admins, and automation should not change them in order to delete files. The real fix we need is for the kyua tests to properly clean up after themselves, including fixing the flags on temporary files created or used by the tests, and then deleting them. -- Ian > > > > I was able to finally delete them. > > > > > > Thanks for the fast respone, > > > > > > Gordon > > --Gordon > _______________________________________________ > From owner-freebsd-current@freebsd.org Mon Jun 29 19:24:03 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 6CC6335326F for ; Mon, 29 Jun 2020 19:24:03 +0000 (UTC) (envelope-from freebsd@grem.de) Received: from mail.evolve.de (mail.evolve.de [213.239.217.29]) (using TLSv1.2 with cipher ECDHE-RSA-CHACHA20-POLY1305 (256/256 bits)) (Client CN "mail.evolve.de", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wcqQ4RJbz4HNT; Mon, 29 Jun 2020 19:24:02 +0000 (UTC) (envelope-from freebsd@grem.de) Received: by mail.evolve.de (OpenSMTPD) with ESMTP id 4cd180ce; Mon, 29 Jun 2020 19:23:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; s=20180501; bh=rT0JHeGoCfFWt5 FbLT+hMOKhkI8=; b=Uts+zn0SecC1GuOLSF4GOHylVAeRv8yHlFZvLVG6pnGehL 8F4vidF7K0kLmZRphPcFkJWe+IYXlUsoRjtg6OXJLFwjx73ZOEyuLdjnBfMOXQuS YFyd3az6Ed8fwCkdxhC7ORwyREH6fxbEPbYxVs4U4M2JSOkQZEy4lDxgEMZVLUbp 33ey76vUncxPwXz4HVqVP9tCtifBzioibTG39LoOtfute6X9Lc/lQx/6pW5b2v2M kSUsT5s5tvyJyXYy+OorNgED5REME8no6TlGxLsimAFbXY5JEGWTWgcA6shksoZ6 KWzOBQLoDPA1GlgWMhfzK00NRkXy91NX0Fqc3guw== DomainKey-Signature: a=rsa-sha1; c=nofws; d=grem.de; h=content-type :content-transfer-encoding:mime-version:subject:from:in-reply-to :date:cc:message-id:references:to; q=dns; s=20180501; b=awoJ9n9y mBdgi+RgrqfKdlWTadWq/KYjqA0pqLLj1VRVccDUe5IIF4BKV5Ukkw3bFt+8gaEE wxnoKtXT5eQfosJsqqJYVE6Ngu0OO6FJMjE3A59A52f5AfMHKxwcanw1aCpd0nXj W1uMgQSMFQ348vpYQ3Ot0HmwdXGUcLmZR1K+bNFrRqAifH/5H1z4EjMjlEdJ7dIg HI6CT4/QViIk6Z0AavR+av8hZB2Tqmt6wqbLM+GdhatsxMz2flEOLiOe3PhZMEMe NcbI3CvyjU05C3l5wGqtbl3K2fnWV6Ydjq7oDR+WXPPuyUf5hYRC0yPIRFOsD6g2 DS2M0t3HtrN4Fw== Received: by mail.evolve.de (OpenSMTPD) with ESMTPSA id 5a0f8963 (TLSv1.2:ECDHE-RSA-CHACHA20-POLY1305:256:NO); Mon, 29 Jun 2020 19:23:50 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mime-Version: 1.0 (1.0) Subject: Re: Undeletable files after kyua test runs From: Michael Gmelin In-Reply-To: <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> Date: Mon, 29 Jun 2020 21:23:48 +0200 Cc: Gordon Bergling , "Rodney W. Grimes" , Kevin Oberman , FreeBSD Current , david@catwhisker.org Message-Id: References: <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> To: Ian Lepore X-Mailer: iPhone Mail (17F80) X-Rspamd-Queue-Id: 49wcqQ4RJbz4HNT X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; ASN(0.00)[asn:24940, ipnet:213.239.192.0/18, country:DE]; REPLY(-4.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:24:03 -0000 > On 29. Jun 2020, at 21:18, Ian Lepore wrote: >=20 > =EF=BB=BFOn Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote: >> On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: >>>> On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: >>>>> On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling < >>>>> gbe@freebsd.org> wrote: >>>>>> I recently stumbled across undeletable files that are >>>>>> generated by kyua >>>>>> test runs, >>>>>> for example >>>>>>=20 >>>>>> -rwxr-xr-x 1 root wheel 0 May 9 13:10 >>>>>> /tmp/kyua.aB4q62/8676/work/fileforaudit >>>>>>=20 >>>>>> I haven't yet identified the test that generate those files, >>>>>> but it is >>>>>> impossible >>>>>> to delete them. I have clear_tmp_enable=3D"YES" set in the >>>>>> /etc/rc.conf, but >>>>>> on every boot the system argues that these file aren't >>>>>> deletable. >>>>>> I tried to 'rm -rf' them by hand but, even this wasn't >>>>>> possible. I have >>>>>> looked for >>>>>> any extend attributes, but I didn't find any. >>>>>>=20 >>>>>> Has anyone an idea how this is possible and may how these >>>>>> files can be >>>>>> deleted? >>>>>=20 >>>>> Have you done 'ls -o' to check for flags like schg? >>>>> -- >>>>> Kevin Oberman, Part time kid herder and retired Network >>>>> Engineer >>>>> E-mail: rkoberman@gmail.com >>>>> PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 >>>>=20 >>>> Argh, I haven't thought about chflags for quite some time. The >>>> chflags >>>> bit was set and after an >>>>=20 >>>> # find /tmp/ -type f -exec chflags -R 0 {} \; >>>=20 >>> ^^Only files ^^ meaningless when chflags is >>> given ONLY files >>>=20 >>> You probably could of done: >>> chflags -R 0 /tmp/ >>=20 >> Okay, I am currently working on an update for clear_tmp_enable=3D"YES" >> to include >> a check like this. I would think that an rc option like this should >> delete=20 >> everything in /tmp. >>=20 >=20 > I disagree. One of the few things those immutable flags are good for > is protecting files from things like an rc script or other automation > that deletes files. Those flags are typically set and maintained by > users and admins, and automation should not change them in order to > delete files. >=20 > The real fix we need is for the kyua tests to properly clean up after > themselves, including fixing the flags on temporary files created or > used by the tests, and then deleting them. >=20 +1, having a routine script remove schg automatically IMHO defeats the purpo= se of setting this flag. Cheers, Michael From owner-freebsd-current@freebsd.org Mon Jun 29 19:26:35 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id E3D9B353734 for ; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [IPv6:2610:1c1:1:606c::24b:4]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49wctM5kmGz4Hjy; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Received: from localhost (p548612f6.dip0.t-ipconnect.de [84.134.18.246]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) (Authenticated sender: gbe) by smtp.freebsd.org (Postfix) with ESMTPSA id 4E28E19257; Mon, 29 Jun 2020 19:26:35 +0000 (UTC) (envelope-from gbe@freebsd.org) Date: Mon, 29 Jun 2020 21:26:34 +0200 From: Gordon Bergling To: Ian Lepore Cc: Gordon Bergling , "Rodney W. Grimes" , Kevin Oberman , FreeBSD Current , david@catwhisker.org Subject: Re: Undeletable files after kyua test runs Message-ID: <20200629192634.GA58164@lion.0xfce3.net> References: <20200629174212.GA80071@lion.0xfce3.net> <202006291858.05TIwlGL048486@gndrsh.dnsmgr.net> <20200629190856.GA44618@lion.0xfce3.net> <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="vkogqOf2sHV7VnPd" Content-Disposition: inline In-Reply-To: <934817c6a90cecc186bf06d3eec1ccba50dd834a.camel@freebsd.org> X-Url: X-Operating-System: FreeBSD 12.1-STABLE amd64 X-Host-Uptime: 9:21PM up 2 days, 8:05, 5 users, load averages: 1.19, 1.14, 1.11 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Jun 2020 19:26:35 -0000 --vkogqOf2sHV7VnPd Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Mon, Jun 29, 2020 at 01:18:12PM -0600, Ian Lepore wrote: > On Mon, 2020-06-29 at 21:08 +0200, Gordon Bergling wrote: > > On Mon, Jun 29, 2020 at 11:58:47AM -0700, Rodney W. Grimes wrote: > > > > On Mon, Jun 29, 2020 at 10:32:38AM -0700, Kevin Oberman wrote: > > > > > On Mon, Jun 29, 2020 at 10:26 AM Gordon Bergling < > > > > > gbe@freebsd.org> wrote: > > > > > > I recently stumbled across undeletable files that are > > > > > > generated by kyua > > > > > > test runs, > > > > > > for example > > > > > >=20 > > > > > > -rwxr-xr-x 1 root wheel 0 May 9 13:10 > > > > > > /tmp/kyua.aB4q62/8676/work/fileforaudit > > > > > >=20 > > > > > > I haven't yet identified the test that generate those files, > > > > > > but it is > > > > > > impossible > > > > > > to delete them. I have clear_tmp_enable=3D"YES" set in the > > > > > > /etc/rc.conf, but > > > > > > on every boot the system argues that these file aren't > > > > > > deletable. > > > > > > I tried to 'rm -rf' them by hand but, even this wasn't > > > > > > possible. I have > > > > > > looked for > > > > > > any extend attributes, but I didn't find any. > > > > > >=20 > > > > > > Has anyone an idea how this is possible and may how these > > > > > > files can be > > > > > > deleted? > > > > >=20 > > > > > Have you done 'ls -o' to check for flags like schg? > > > > > -- > > > > > Kevin Oberman, Part time kid herder and retired Network > > > > > Engineer > > > > > E-mail: rkoberman@gmail.com > > > > > PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683 > > > >=20 > > > > Argh, I haven't thought about chflags for quite some time. The > > > > chflags > > > > bit was set and after an > > > >=20 > > > > # find /tmp/ -type f -exec chflags -R 0 {} \; > > >=20 > > > ^^Only files ^^ meaningless when chflags is > > > given ONLY files > > >=20 > > > You probably could of done: > > > chflags -R 0 /tmp/ > >=20 > > Okay, I am currently working on an update for clear_tmp_enable=3D"YES" > > to include > > a check like this. I would think that an rc option like this should > > delete=20 > > everything in /tmp. > >=20 >=20 > I disagree. One of the few things those immutable flags are good for > is protecting files from things like an rc script or other automation > that deletes files. Those flags are typically set and maintained by > users and admins, and automation should not change them in order to > delete files. >=20 > The real fix we need is for the kyua tests to properly clean up after > themselves, including fixing the flags on temporary files created or > used by the tests, and then deleting them. >=20 > -- Ian A fix for the causing RC script was my first idea, but I had of course the same idea that a kyua test could be fixed to not end in a state that leads to file that has chflags set to a value that couldn't be deleted by a job that is proposed to so. I take this as a homework and look at the kyua scripts that created those files. --Gordon --vkogqOf2sHV7VnPd Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGTBAEBCgB9FiEEYbWI0KY5X7yH/Fy4OQX2V8rP09wFAl76QGlfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDYx QjU4OEQwQTYzOTVGQkM4N0ZDNUNCODM5MDVGNjU3Q0FDRkQzREMACgkQOQX2V8rP 09yckAf/ShcqQRmAVH/F28e/syV5fm8GQbLEJVdDXPwZXyjp5BQ1jSWxQDQP73QR Fde0oReiF5v3zjkiYC01yZvcsFLq3+3s5Rm9DAZ7SmdHYPkSkNn9XWOiau+2QjSv MqlKSDYJ+JGR4Ok7rXy2akejvUmJEAbWJRMx9ZDrqxLtLpWLHu7pafv2UIXyE939 618gyyf7+O6CHFo7otwmTwahUQEafgPbbXdRVAkdFeHp5rGCOPVYSlsKkxy+Xcx0 zG7ohEX+HiXy8BduWOnOhA4wp94rxDo8Mv6IOUtAr6T9Zc1+ximXv77DqhBspAyM p6zOMxZj8M9xz+wveaqdhmRsMJn+GQ== =U1Va -----END PGP SIGNATURE----- --vkogqOf2sHV7VnPd-- From owner-freebsd-current@freebsd.org Tue Jun 30 12:01:26 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 478643678D4 for ; Tue, 30 Jun 2020 12:01:26 +0000 (UTC) (envelope-from 01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com) Received: from a48-91.smtp-out.amazonses.com (a48-91.smtp-out.amazonses.com [54.240.48.91]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49x2yF4YMZz4KPc for ; Tue, 30 Jun 2020 12:01:25 +0000 (UTC) (envelope-from 01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593518484; h=Reply-To:To:From:Subject:Message-ID:Date:MIME-Version:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=TOGdtrpGJX8d3EpR+9dD6jIhpAFaYa1PrAhl7+4L/Qo=; b=IXKe705AZjzw0OXMdtSj5UUK/mP9UJDsZsuzgewx8ZJuHEp5Dcq9fW2j9EDGIH8r VDEFwbDaKyaDDsyERZkt2zfXdSq4DCHQrJff9xv6cP7g0k/7EGfM28c8spIuJZLeGUT f3FIZ5PyIlr+0n/hRxzfGhlBtaBa01WN0yO5saw4= Reply-To: lausts@acm.org To: freebsd-current@freebsd.org From: Thomas Laus Subject: Geli encryption issue on r362779 Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJeCkKSBQkjjKomAAoJEOv/gtRiCDbPtWkAn3Sn 1ksVTC5TGCvd/QuLacFbBSZqAJ9NEUmlaosaPc/YoxezSnkpG8MQTbkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAl4KQ6YFCRpPSIoACgkQ6/+C1GIINs+S6wCeI2n/+azjnVivvCryW5TX3DDh o2oAoLnebgcEDawA/CrxKxpkTiXtL7VGuQENBDx1NXQQBACO2D8nP7d2/ugxmJl9edxI97vG vHvxByQNOhyWXvEOos1uI4M/Sn6By9opJyt2Tl0HGMO2ksn3f4ESKlPH8+9Q2GhJhbdP8KC6 UPrf1hB8XrvAZsqax5Zr9f00SG4cdqWsGDHY4mUG7B/F0SFEAEgczQciYfJKT0J0fnHyjRAg gwADBQP+L1gGS1XuaHh9VtAn0hzXFQlIH3UAX0+9tlenOTA1aTBqrbNepGJH0zFlwQjQN1c+ qz7ULswo9LGWob0nRAoZ2g9hIQs+8p1KMwBs/V2j6PkNwSj/fUsMXAOvor0HcEHjpIW952KV h9oGbPEbB+LaDVb5BKjbOhAzfdrlPlBx0F6IdAQoEQIANBYhBBloSoDtPqFEokqZd+v/gtRi CDbPBQJeCk0cFh0BVXBncmFkZSB0byBtb3JlIGJpdHMACgkQ6/+C1GIINs8CPQCeJKOtIuT/ zMxWEN9B3VucBIQ5TPcAoMsPLPJWp71kv+1s+JPeJcv/zJNYiEwEGBECAAwFAlaX+EQFCRwG mUgACgkQ6/+C1GIINs90KwCeN8z1KIVcvhLKMVq3Qy6eZkDCAA4AoIOVlXHHiZE1vQ50HJ0R HoghYce3 Message-ID: <01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@email.amazonses.com> Date: Tue, 30 Jun 2020 12:01:24 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2020.06.30-54.240.48.91 Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-Rspamd-Queue-Id: 49x2yF4YMZz4KPc X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=IXKe705A; dmarc=none; spf=pass (mx1.freebsd.org: domain of 01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com designates 54.240.48.91 as permitted sender) smtp.mailfrom=01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com X-Spamd-Result: default: False [-0.11 / 15.00]; HAS_REPLYTO(0.00)[lausts@acm.org]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; NEURAL_HAM_MEDIUM(-0.71)[-0.711]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; MIME_GOOD(-0.10)[text/plain]; TO_DN_NONE(0.00)[]; REPLYTO_ADDR_EQ_FROM(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.91)[-0.910]; DMARC_NA(0.00)[acm.org]; DKIM_TRACE(0.00)[amazonses.com:+]; NEURAL_HAM_SHORT(-0.79)[-0.793]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.91:from]; FORGED_SENDER(0.30)[lausts@acm.org,01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com]; RCVD_COUNT_ZERO(0.00)[0]; MIME_TRACE(0.00)[0:+]; RWL_MAILSPIKE_VERYGOOD(0.00)[54.240.48.91:from]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:01:26 -0000 This is a repost to this list because of my submission email address did not match the one on record. ================================== List: I just upgraded a couple of computers from r362220 to r362779 and have booting issue on my Core2 duo laptop with the passphrase unlocking the encrypted partition. If I type in the correct passphrase, my laptop reboots. If I type in an incorrect one, it prompts me to enter another one. On my i5 Skylake desktop, everything works as expected. I had to copy an older 'gptzfsboot' file from a distribution CD to allow me to boot my laptop. The Core2 duo doesn't have the hardware encryption feature and uses software emulation of AESNI. The i5 has the hardware encryption feature. Once I copied the old 'gptzfsboot' file to my laptop, it boots OK. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Tue Jun 30 12:22:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id F2AE03493A5 for ; Tue, 30 Jun 2020 12:22:51 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-ztdg06011201.me.com (mr85p00im-ztdg06011201.me.com [17.58.23.181]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49x3Qz1pKnz4Lyd for ; Tue, 30 Jun 2020 12:22:51 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by mr85p00im-ztdg06011201.me.com (Postfix) with ESMTPSA id AB001400D7B; Tue, 30 Jun 2020 12:22:48 +0000 (UTC) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Geli encryption issue on r362779 From: Toomas Soome In-Reply-To: <01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@email.amazonses.com> Date: Tue, 30 Jun 2020 15:22:46 +0300 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@email.amazonses.com> To: lausts@acm.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=1 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006300092 X-Rspamd-Queue-Id: 49x3Qz1pKnz4Lyd X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.09 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.48)[-0.484]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.007]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.181:from]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.998]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[me.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.23.181:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 12:22:52 -0000 > On 30. Jun 2020, at 15:01, Thomas Laus wrote: >=20 > This is a repost to this list because of my submission email address = did > not match the one on record. >=20 > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > List: >=20 > I just upgraded a couple of computers from r362220 to r362779 and have > booting issue on my Core2 duo laptop with the passphrase unlocking the > encrypted partition. If I type in the correct passphrase, my laptop > reboots. If I type in an incorrect one, it prompts me to enter = another > one. On my i5 Skylake desktop, everything works as expected. I had = to > copy an older 'gptzfsboot' file from a distribution CD to allow me to > boot my laptop. >=20 > The Core2 duo doesn't have the hardware encryption feature and uses > software emulation of AESNI. The i5 has the hardware encryption > feature. Once I copied the old 'gptzfsboot' file to my laptop, it = boots OK. >=20 > Tom >=20 The boot bits do not use hardware encryption at all, so it must be = something else. Unfortunately testing it is a bit annoying and time = consuming task, but we should go through it if we want to get to the = bottom of the issue. It means, we need to insert printf=E2=80=99s to the = code to see how far we get and why we end up with reboot. Please let me = know when you can spend time with testing. rgds, toomas= From owner-freebsd-current@freebsd.org Tue Jun 30 17:19:31 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 294E235173A for ; Tue, 30 Jun 2020 17:19:31 +0000 (UTC) (envelope-from 01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com) Received: from a48-103.smtp-out.amazonses.com (a48-103.smtp-out.amazonses.com [54.240.48.103]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xB1F3bTtz3Ss9 for ; Tue, 30 Jun 2020 17:19:29 +0000 (UTC) (envelope-from 01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com) DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/simple; s=224i4yxa5dv7c2xz3womw6peuasteono; d=amazonses.com; t=1593537568; h=Reply-To:Subject:To:References:From:Message-ID:Date:MIME-Version:In-Reply-To:Content-Type:Content-Transfer-Encoding:Feedback-ID; bh=dv5oIATzgrQJnNNtU89W1F0RcmOvZvhXQga+TQ6s73M=; b=Qa/aA3KP/T+I10WLSZTo8ybwwWYLDgyEB1QG+x+D8YLWTCPEAQXGR3WPKIPfggfB L4OyKhzPZs2pOyyI8JRoaEOA//97qMNTPFOQBip+VvhhYq5EHFjqIIiHXpI3VyrqAkJ jEymGf67Y0N4H2OdZj4wHwooqp1sryUQ1AmSJO0Q= Reply-To: lausts@acm.org Subject: Re: Geli encryption issue on r362779 To: Toomas Soome , freebsd-current@freebsd.org References: <01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@email.amazonses.com> <0100017305bed46f-20efa601-2169-491f-bc95-a4fd8cffafa3-000000@email.amazonses.com> <9ACB03CF-2168-4CCE-B1DC-6D76E33DE9C8@me.com> From: Thomas Laus Autocrypt: addr=lausts@acm.org; prefer-encrypt=mutual; keydata= mQGiBDx1NWwRBADARalI5I8kGeBYYYWnZB73T1fU4333yCuRokRvzlAZ5Zhb3hqsNdTEMheN FDjZSL8J5jeJtvSRinY2p09CxpAMoJR9zHLmHl+zEOY8fInbB+KiFtSfGf0blSEY9/+isQP9 xmUIQWUj0kwVtrns7m1HrYLiI07NVFzbHNKqQcbPuwCg0n/KKi+VJiUs5MqLKwGuPotGeZME AIluMetTQwfLyovundMwFYlSZ/Z8JjkMybqgKuiRrZnaBVVZ80NjAYZI73yAZPfQh9mvFxW9 ipc2tSALwDy/tYDpQRK0k+0EsDmwG/wM6OarkqSuFcYx+tP86+2+6Xitn6E/hriIWa/ZQVef /fx7dZzdwhXH6fd34v8o/BuqhawLBACs4MTMGbdSmyI56vCMXWY1yxRPmuygd4vUnXqYwlrM Ee/LjQdreg1zTAJnnW1K+PgOUW/jvS+uAbgxLa3i59/Z4Uu7nB6G1y+Y1cThojUsLnvoJlt1 4XE1U/vnOcvO3evo6knB1qjbAMsZGaVleiVKDq+7XE7swe4WtBJKbYJthbQcVGhvbWFzIExh dXMgPGxhdXN0c0BhY20ub3JnPoh/BBMRAgA/AheAAh4BBgsJCAcDAgYVCAIJCgsEFgIDAQIZ ARYhBBloSoDtPqFEokqZd+v/gtRiCDbPBQJeCkKSBQkjjKomAAoJEOv/gtRiCDbPtWkAn3Sn 1ksVTC5TGCvd/QuLacFbBSZqAJ9NEUmlaosaPc/YoxezSnkpG8MQTbkCDQRFspgcEAgAjXsi 9WqowAKZ7d2ix6t7fiYgu2QBGWq36NvN+cPBJIu0CnagL1v4W1UrRW/0cInLzgqlWrSU7SFg y1+rGBlusMHf8/faGeZD0XwMdYgTIYdjdK5VZ0GaRWUs0LbHAOJQkOFRHLMAEG8wrc3f1xrn uVJ4JPOA81kTmTXvYTyQNXJBySc0oNSgvSut8aBbNGBZhw9U2V3yXXnnMeWR8+DYrriYdOdR eK7S0LNN8TPY60PJx3KLN9vUY9Cb5Ly0NavF3wREPQqYlNfTMoG/GA/n8XB6SCoMj73oKCyw FLbckBUjFsl7wTeKKvU68V8kWG762fscXhOhRduETGrja09MbwADBQf/WiycmdfNtB41+vvT HQqz9tm3ZHAW2yE53CxfQpvlyS/KwnWgLjl/iV0SHRDede0NJ5yTEqPVhqq7WCdlqVsHPSpX FfvyOgbNmjPmOY/a1nW4UnWSqA7bgQvkthahhoLeHzkU8YKupW0m05RIBpqQER6HwBOksTq4 sWV/lUy1P0VT8GqqPLNklKe2BEu+KhuhLV6XwEG3VrHNoY6/R5CMGvBhZbtiUViCZktmxJAj Fq0VCcuj7+Oo52eq4BL2vMrzLX+2Ib1JSWid6t0N+grXxbr2mv7H2V2/4Vo0XI3IKxPX1mdG y9RBkbRUGyV9A8RlaS0QTnXvsxZTjOnmjxPX64hmBBgRAgAmAhsMFiEEGWhKgO0+oUSiSpl3 6/+C1GIINs8FAl4KQ6YFCRpPSIoACgkQ6/+C1GIINs+S6wCeI2n/+azjnVivvCryW5TX3DDh o2oAoLnebgcEDawA/CrxKxpkTiXtL7VGuQENBDx1NXQQBACO2D8nP7d2/ugxmJl9edxI97vG vHvxByQNOhyWXvEOos1uI4M/Sn6By9opJyt2Tl0HGMO2ksn3f4ESKlPH8+9Q2GhJhbdP8KC6 UPrf1hB8XrvAZsqax5Zr9f00SG4cdqWsGDHY4mUG7B/F0SFEAEgczQciYfJKT0J0fnHyjRAg gwADBQP+L1gGS1XuaHh9VtAn0hzXFQlIH3UAX0+9tlenOTA1aTBqrbNepGJH0zFlwQjQN1c+ qz7ULswo9LGWob0nRAoZ2g9hIQs+8p1KMwBs/V2j6PkNwSj/fUsMXAOvor0HcEHjpIW952KV h9oGbPEbB+LaDVb5BKjbOhAzfdrlPlBx0F6IdAQoEQIANBYhBBloSoDtPqFEokqZd+v/gtRi CDbPBQJeCk0cFh0BVXBncmFkZSB0byBtb3JlIGJpdHMACgkQ6/+C1GIINs8CPQCeJKOtIuT/ zMxWEN9B3VucBIQ5TPcAoMsPLPJWp71kv+1s+JPeJcv/zJNYiEwEGBECAAwFAlaX+EQFCRwG mUgACgkQ6/+C1GIINs90KwCeN8z1KIVcvhLKMVq3Qy6eZkDCAA4AoIOVlXHHiZE1vQ50HJ0R HoghYce3 Message-ID: <01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@email.amazonses.com> Date: Tue, 30 Jun 2020 17:19:28 +0000 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <9ACB03CF-2168-4CCE-B1DC-6D76E33DE9C8@me.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-SES-Outgoing: 2020.06.30-54.240.48.103 Feedback-ID: 1.us-east-1.9pbSdi8VQuDGy3n7CRAr3/hYnLCug78GrsPo0xSgBOs=:AmazonSES X-Rspamd-Queue-Id: 49xB1F3bTtz3Ss9 X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=amazonses.com header.s=224i4yxa5dv7c2xz3womw6peuasteono header.b=Qa/aA3KP; dmarc=none; spf=pass (mx1.freebsd.org: domain of 01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com designates 54.240.48.103 as permitted sender) smtp.mailfrom=01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com X-Spamd-Result: default: False [-0.63 / 15.00]; HAS_REPLYTO(0.00)[lausts@acm.org]; FORGED_SENDER(0.30)[lausts@acm.org,01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com]; R_DKIM_ALLOW(-0.20)[amazonses.com:s=224i4yxa5dv7c2xz3womw6peuasteono]; ARC_NA(0.00)[]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:54.240.0.0/18]; NEURAL_HAM_LONG(-0.99)[-0.993]; MIME_GOOD(-0.10)[text/plain]; REPLYTO_ADDR_EQ_FROM(0.00)[]; DMARC_NA(0.00)[acm.org]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[amazonses.com:+]; RCPT_COUNT_TWO(0.00)[2]; RCVD_IN_DNSWL_NONE(0.00)[54.240.48.103:from]; NEURAL_HAM_SHORT(-0.97)[-0.966]; NEURAL_HAM_MEDIUM(-0.97)[-0.969]; FREEMAIL_TO(0.00)[me.com,freebsd.org]; RCVD_COUNT_ZERO(0.00)[0]; RWL_MAILSPIKE_POSSIBLE(0.00)[54.240.48.103:from]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:14618, ipnet:54.240.48.0/23, country:US]; FROM_NEQ_ENVFROM(0.00)[lausts@acm.org,01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@amazonses.com]; FORGED_MUA_THUNDERBIRD_MSGID_UNKNOWN(2.50)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 17:19:31 -0000 On 2020-06-30 11:31, Toomas Soome wrote: > > hi! > > 362431: https://svnweb.freebsd.org/base?view=revision&revision=362431 > > The majority of the code is now shared with loader (libsa/libi386), > however, we do have some bits in zfsboot.c, which is common part of > gptzfsboot and zfsboot. > That looks like the problem revision. My i5 can still boot this revision, but my Core2 Duo can not. At least this narrows things a bit. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF From owner-freebsd-current@freebsd.org Tue Jun 30 18:02:44 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 29FDB352608 for ; Tue, 30 Jun 2020 18:02:44 +0000 (UTC) (envelope-from tsoome@me.com) Received: from mr85p00im-ztdg06011801.me.com (mr85p00im-ztdg06011801.me.com [17.58.23.199]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49xBz73C7Nz3WLr for ; Tue, 30 Jun 2020 18:02:43 +0000 (UTC) (envelope-from tsoome@me.com) Received: from nazgul.lan (148-52-235-80.sta.estpak.ee [80.235.52.148]) by mr85p00im-ztdg06011801.me.com (Postfix) with ESMTPSA id 685D7C0393; Tue, 30 Jun 2020 18:02:38 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Geli encryption issue on r362779 From: Toomas Soome In-Reply-To: <01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@email.amazonses.com> Date: Tue, 30 Jun 2020 21:02:35 +0300 Cc: freebsd-current@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: References: <01000173051a6c1b-ceec77e5-6fee-4969-ada0-70ad8789e1dd-000000@email.amazonses.com> <0100017305bed46f-20efa601-2169-491f-bc95-a4fd8cffafa3-000000@email.amazonses.com> <9ACB03CF-2168-4CCE-B1DC-6D76E33DE9C8@me.com> <01000173063d9d8d-f46774e6-d490-43cc-925d-e729c82904fa-000000@email.amazonses.com> To: lausts@acm.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235, 18.0.687 definitions=2020-06-30_06:2020-06-30, 2020-06-30 signatures=0 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 malwarescore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1015 mlxscore=0 mlxlogscore=654 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-2004280000 definitions=main-2006300124 X-Rspamd-Queue-Id: 49xBz73C7Nz3WLr X-Spamd-Bar: ---- X-Spamd-Result: default: False [-4.39 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[me.com]; MV_CASE(0.50)[]; TO_DN_NONE(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:17.58.0.0/16]; DKIM_TRACE(0.00)[me.com:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[me.com,quarantine]; NEURAL_HAM_SHORT(-0.78)[-0.780]; RECEIVED_SPAMHAUS_PBL(0.00)[80.235.52.148:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[me.com]; MID_RHS_MATCH_FROM(0.00)[]; ASN(0.00)[asn:714, ipnet:17.58.16.0/20, country:US]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.01)[-1.008]; R_DKIM_ALLOW(-0.20)[me.com:s=1a1hai]; RCVD_IN_DNSWL_LOW(-0.10)[17.58.23.199:from]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-1.00)[-0.997]; MIME_GOOD(-0.10)[text/plain]; DWL_DNSWL_LOW(-1.00)[me.com:dkim]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RWL_MAILSPIKE_POSSIBLE(0.00)[17.58.23.199:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 18:02:44 -0000 > On 30. Jun 2020, at 20:19, Thomas Laus wrote: >=20 > On 2020-06-30 11:31, Toomas Soome wrote: >>=20 >> hi! >>=20 >> 362431: https://svnweb.freebsd.org/base?view=3Drevision&revision=3D3624= 31 >>=20 >> The majority of the code is now shared with loader (libsa/libi386), >> however, we do have some bits in zfsboot.c, which is common part of >> gptzfsboot and zfsboot. >>=20 > That looks like the problem revision. My i5 can still boot this > revision, but my Core2 Duo can not. At least this narrows things a = bit. >=20 > Tom >=20 Yes, that was suspect from start. But lets see where this rabbit hole = will go.. rgds, toomas From owner-freebsd-current@freebsd.org Tue Jun 30 19:29:56 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 9D2963543DB for ; Tue, 30 Jun 2020 19:29:56 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: from mail-qt1-f172.google.com (mail-qt1-f172.google.com [209.85.160.172]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49xDvl3ZCgz3bth; Tue, 30 Jun 2020 19:29:55 +0000 (UTC) (envelope-from rlibby@gmail.com) Received: by mail-qt1-f172.google.com with SMTP id d27so16536156qtg.4; Tue, 30 Jun 2020 12:29:55 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Hg3EXqCwD5sQG8cY8Q0gaErzWPyg/x623S8s7KVNC6Y=; b=bj6CRh5UIAp9Iar9Nig0ps/5oIhmYyaPGjKjtFbaq4/TPj1/oTPvWMUSzkLudfZBlW LFFao78fSikRmJcFVAp2oyJMEWRuZh0htJC3sNXpyLZ0S9ZgyYfnvdRWX0JOWdrK4rmh nk0cqDQKQ9aYSTVfvdVtPEP7QFUo/HA5lmYbWzbXWXJ6u95GhW9UjY2pHT7xYz9UOoBG y1PvtVKHvJiqqVVnW0Zx62PCUz998aMu7S/LcSwI8f8uPAZo5CDFsoJNDfLODoa7m70f M3cE6T9VM48Bsabm4AExGa1S1p4L/FS6Y3pIENfMjmpdIKMEWXNZoZf+dbWA3NurSyM8 P+6g== X-Gm-Message-State: AOAM5316oAHepjOi062SnrdvJ8R0S4LQN3nWlw1txSt+Dq/9kNyh5EjA yNBU0grL1tANB2UnAvnh8yK0H7cg X-Google-Smtp-Source: ABdhPJwfAb23HM2HyX8Qcjm333V5x/h3Zdpgt09t6nO7j2jGpNNGrvQPyv2r1qK58aAvClyUgD8T3A== X-Received: by 2002:ac8:1c09:: with SMTP id a9mr22658130qtk.64.1593545392793; Tue, 30 Jun 2020 12:29:52 -0700 (PDT) Received: from mail-qk1-f179.google.com (mail-qk1-f179.google.com. [209.85.222.179]) by smtp.gmail.com with ESMTPSA id k18sm3498967qki.30.2020.06.30.12.29.52 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Tue, 30 Jun 2020 12:29:52 -0700 (PDT) Received: by mail-qk1-f179.google.com with SMTP id j80so19798861qke.0; Tue, 30 Jun 2020 12:29:52 -0700 (PDT) X-Received: by 2002:a05:620a:7d6:: with SMTP id 22mr21508708qkb.311.1593545392177; Tue, 30 Jun 2020 12:29:52 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Ryan Libby Date: Tue, 30 Jun 2020 12:29:41 -0700 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc To: Rick Macklem Cc: Konstantin Belousov , Jeff Roberson , "freebsd-current@freebsd.org" Content-Type: text/plain; charset="UTF-8" X-Rspamd-Queue-Id: 49xDvl3ZCgz3bth X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of rlibby@gmail.com designates 209.85.160.172 as permitted sender) smtp.mailfrom=rlibby@gmail.com X-Spamd-Result: default: False [-2.12 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_TLS_ALL(0.00)[]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:209.85.128.0/17]; MIME_GOOD(-0.10)[text/plain]; DMARC_NA(0.00)[freebsd.org]; ARC_NA(0.00)[]; NEURAL_HAM_LONG(-1.00)[-1.003]; RCVD_COUNT_THREE(0.00)[4]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.15)[-0.145]; RCVD_IN_DNSWL_NONE(0.00)[209.85.160.172:from]; NEURAL_HAM_MEDIUM(-0.97)[-0.974]; FORGED_SENDER(0.30)[rlibby@freebsd.org,rlibby@gmail.com]; RWL_MAILSPIKE_POSSIBLE(0.00)[209.85.160.172:from]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; FROM_NEQ_ENVFROM(0.00)[rlibby@freebsd.org,rlibby@gmail.com]; FREEMAIL_ENVFROM(0.00)[gmail.com] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 30 Jun 2020 19:29:56 -0000 On Sun, Jun 28, 2020 at 9:57 PM Rick Macklem wrote: > > Just in case you were waiting for another email, I have now run several > cycles of the kernel build over NFS on a recent head kernel with the > one line change and it has not hung. > > I don't know if this is the correct fix, but it would be nice to get something > into head to fix this. > > If I don't hear anything in the next few days, I'll put it in a PR so it > doesn't get forgotten. > > rick Thanks for the follow through on this. I think the patch is not complete. It looks like the problem is that for systems that do not have UMA_MD_SMALL_ALLOC, we do uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc); but we haven't set an appropriate free function. This is probably why UMA_ZONE_NOFREE was originally there. When NOFREE was removed, it was appropriate for systems with uma_small_alloc. So by default we get page_free as our free function. That calls kmem_free, which calls vmem_free ... but we do our allocs with vmem_xalloc. I'm not positive, but I think the problem is that in effect we vmem_xalloc -> vmem_free, not vmem_xfree. Three possible fixes: 1: The one you tested, but this is not best for systems with uma_small_alloc. 2: Pass UMA_ZONE_NOFREE conditional on UMA_MD_SMALL_ALLOC. 3: Actually provide an appropriate vmem_bt_free function. I think we should just do option 2 with a comment, it's simple and it's what we used to do. I'm not sure how much benefit we would see from option 3, but it's more work. Ryan > > ________________________________________ > From: owner-freebsd-current@freebsd.org on behalf of Rick Macklem > Sent: Thursday, June 18, 2020 11:42 PM > To: Ryan Libby > Cc: Konstantin Belousov; Jeff Roberson; freebsd-current@freebsd.org > Subject: Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc > > Ryan Libby wrote: > >On Mon, Jun 15, 2020 at 5:06 PM Rick Macklem wrote: > >> > >> Rick Macklem wrote: > >> >r358098 will hang fairly easily, in 1-3 cycles of the kernel build over = > NFS. > >> >I thought this was the culprit, since I did 6 cycles of r358097 without = > a hang. > >> >However, I just got a hang with r358097, but it looks rather different. > >> >The r358097 hang did not have any processes sleeping on btalloc. They > >> >appeared to be waiting on two different locks in the buffer cache. > >> >As such, I think it might be a different problem. (I'll admit I should h= > ave > >> >made notes about this one before rebooting, but I was flustrated that > >> >it happened and rebooted before looking at it mush detail.) > >> Ok, so I did 10 cycles of the kernel build over NFS for r358096 and never > >> got a hang. > >> --> It seems that r358097 is the culprit and r358098 makes it easier > >> to reproduce. > >> --> Basically runs out of kernel memory. > >> > >> It is not obvious if I can revert these two commits without reverting > >> other ones, since there were a bunch of vm changes after these. > >> > >> I'll take a look, but if you guys have any ideas on how to fix this, plea= > se > >> let me know. > >> > >> Thanks, rick > > > >Interesting. Could you try re-adding UMA_ZONE_NOFREE to the vmem btag > >zone to see if that rescues it, on whatever base revision gets you a > >reliable repro? > Good catch! That seems to fix it. I've done 8 cycles of kernel build over > NFS without a hang (normally I'd get one in the first 1-3 cycles). > > I don't know if the intend was to delete UMA_ZONE_VM and r358097 > had a typo in it and deleted UMA_ZONE_NOFREE or ??? > > Anyhow, I just put it back to UMA_ZONE_VM | UMA_ZONE_NOFREE and > the hangs seem to have gone away. > > The small patch I did is attached, in case that isn't what you meant. > > I'll run a few more cycles just in case, but I think this fixes it. > > Thanks, rick > > > > > Jeff, to fill you in, I have been getting intermittent hangs on a Pentium= > 4 > > (single core i386) with 1.25Gbytes ram when doing kernel builds using > > head kernels from this winter. (I also saw one when doing a kernel build > > on UFS, so they aren't NFS specific, although easier to reproduce that wa= > y.) > > After a typical hang, there will be a bunch of processes sleeping on "bta= > lloc" > > and several processes holding the following lock: > > exclusive sx lock @ vm/vm_map.c:4761 > > - I have seen hangs where that is the only lock held by any process excep= > t > > the interrupt thread. > > - I have also seen processes waiting on the following locks: > > kern/subr_vmem.c:1343 > > kern/subr_vmem.c:633 > > > > I can't be absolutely sure r358098 is the culprit, but it seems to make t= > he > > problem more reproducible. > > > > If anyone has a patch suggestion, I can test it. > > Otherwise, I will continue to test r358097 and earlier, to try and see wh= > at hangs > > occur. (I've done 8 cycles of testing of r356776 without difficulties, bu= > t that > > doesn't guarantee it isn't broken.) > > > > There is a bunch more of the stuff I got for Kostik and Ryan below. > > I can do "db" when it is hung, but it is a screen console, so I need to > > transcribe the output to email by hand. (ie. If you need something > > specific I can do that, but trying to do everything Kostik and Ryan asked > > for isn't easy.) > > > > rick > > > > > > > > Konstantin Belousov wrote: > > >On Fri, May 22, 2020 at 11:46:26PM +0000, Rick Macklem wrote: > > >> Konstantin Belousov wrote: > > >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote: > > >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem = > wrote: > > >> >> > > > >> >> > Hi, > > >> >> > > > >> >> > Since I hadn't upgraded a kernel through the winter, it took me a= > while > > >> >> > to bisect this, but r358252 seems to be the culprit. > > No longer true. I succeeded in reproducing the hang to-day running a > > r358251 kernel. > > > > I haven't had much luck sofar, but see below for what I have learned. > > > > >> >> > > > >> >> > If I do a kernel build over NFS using my not so big Pentium 4 (si= > ngle core, > > >> >> > 1.25Gbytes RAM, i386), about every second attempt will hang. > > >> >> > When I do a "ps" in the debugger, I see processes sleeping on bta= > lloc. > > >> >> > If I revert to r358251, I cannot reproduce this. > > As above, this is no longer true. > > > > >> >> > > > >> >> > Any ideas? > > >> >> > > > >> >> > I can easily test any change you might suggest to see if it fixes= > the > > >> >> > problem. > > >> >> > > > >> >> > If you want more debug info, let me know, since I can easily > > >> >> > reproduce it. > > >> >> > > > >> >> > Thanks, rick > > >> >> > > >> >> Nothing obvious to me. I can maybe try a repro on a VM... > > >> >> > > >> >> ddb ps, acttrace, alltrace, show all vmem, show page would be welco= > me. > > >> >> > > >> >> "btalloc" is "We're either out of address space or lost a fill race= > ." > > From what I see, I think it is "out of address space". > > For one of the hangs, when I did "show alllocks", everything except the > > intr thread, was waiting for the > > exclusive sx lock @ vm/vm_map.c:4761 > > > > >> > > > >> >Yes, I would be not surprised to be out of something on 1G i386 machi= > ne. > > >> >Please also add 'show alllocks'. > > >> Ok, I used an up to date head kernel and it took longer to reproduce a= > hang. > > Go down to Kostik's comment about kern.maxvnodes for the rest of what I'v= > e > > learned. (The time it takes to reproduce one of these varies greatly, but= > I usually > > get one within 3 cycles of a full kernel build over NFS. I have had it ha= > ppen > > once when doing a kernel build over UFS.) > > > > >> This time, none of the processes are stuck on "btalloc". > > > I'll try and give you most of the above, but since I have to type it in= > by hand > > > from the screen, I might not get it all. (I'm no real typist;-) > > > > show alllocks > > > exclusive lockmgr ufs (ufs) r =3D 0 locked @ kern/vfs_subr.c: 3259 > > > exclusive lockmgr nfs (nfs) r =3D 0 locked @ kern/vfs_lookup.c:737 > > > exclusive sleep mutex kernel area domain (kernel arena domain) r =3D 0 = > locked @ kern/subr_vmem.c:1343 > > > exclusive lockmgr bufwait (bufwait) r =3D 0 locked @ kern/vfs_bio.c:166= > 3 > > > exclusive lockmgr ufs (ufs) r =3D 0 locked @ kern/vfs_subr.c:2930 > > > exclusive lockmgr syncer (syncer) r =3D 0 locked @ kern/vfs_subr.c:2474 > > > Process 12 (intr) thread 0x.. (1000008) > > > exclusive sleep mutex Giant (Giant) r =3D 0 locked @ kern/kern_intr.c:1= > 152 > > > > > > > ps > > > - Not going to list them all, but here are the ones that seem interesti= > ng... > > > 18 0 0 0 DL vlruwt 0x11d939cc [vnlru] > > > 16 0 0 0 DL (threaded) [bufdaemon] > > > 100069 D qsleep [bufdaemon] > > > 100074 D - [bufspacedaemon-0] > > > 100084 D sdflush 0x11923284 [/ worker] > > > - and more of these for the other UFS file systems > > > 9 0 0 0 DL psleep 0x1e2f830 [vmdaemon] > > > 8 0 0 0 DL (threaded) [pagedaemon] > > > 100067 D psleep 0x1e2e95c [dom0] > > > 100072 D launds 0x1e2e968 [laundry: dom0] > > > 100073 D umarcl 0x12cc720 [uma] > > > =E2=80=A6 a bunch of usb and cam ones > > > 100025 D - 0x1b2ee40 [doneq0] > > > =E2=80=A6 > > > 12 0 0 0 RL (threaded) [intr] > > > 100007 I [swi6: task queue] > > > 100008 Run CPU 0 [swi6: Giant taskq] > > > =E2=80=A6 > > > 100000 D swapin 0x1d96dfc [swapper] > > > - and a bunch more in D state. > > > Does this mean the swapper was trying to swap in? > > > > > > > acttrace > > > - just shows the keyboard > > > kdb_enter() at kdb_enter+0x35/frame > > > vt_kbdevent() at vt_kdbevent+0x329/frame > > > kdbmux_intr() at kbdmux_intr+0x19/frame > > > taskqueue_run_locked() at taskqueue_run_locked+0x175/frame > > > taskqueue_run() at taskqueue_run+0x44/frame > > > taskqueue_swi_giant_run(0) at taskqueue_swi_giant_run+0xe/frame > > > ithread_loop() at ithread_loop+0x237/frame > > > fork_exit() at fork_exit+0x6c/frame > > > fork_trampoline() at 0x../frame > > > > > > > show all vmem > > > vmem 0x.. 'transient arena' > > > quantum: 4096 > > > size: 23592960 > > > inuse: 0 > > > free: 23592960 > > > busy tags: 0 > > > free tags: 2 > > > inuse size free size > > > 16777216 0 0 1 23592960 > > > vmem 0x.. 'buffer arena' > > > quantum: 4096 > > > size: 94683136 > > > inuse: 94502912 > > > free: 180224 > > > busy tags: 1463 > > > free tags: 3 > > > inuse size free size > > > 16384 2 32768 1 16384 > > > 32768 39 1277952 1 32768 > > > 65536 1422 93192192 0 0 > > > 131072 0 0 1 131072 > > > vmem 0x.. 'i386trampoline' > > > quantum: 1 > > > size: 24576 > > > inuse: 20860 > > > free: 3716 > > > busy tags: 9 > > > free tags: 3 > > > inuse size free size > > > 32 1 48 1 52 > > > 64 2 208 0 0 > > > 128 2 280 0 0 > > > 2048 1 2048 1 3664 > > > 4096 2 8192 0 0 > > > 8192 1 10084 0 0 > > > vmem 0x.. 'kernel rwx arena' > > > quantum: 4096 > > > size: 0 > > > inuse: 0 > > > free: 0 > > > busy tags: 0 > > > free tags: 0 > > > vmem 0x.. 'kernel area dom' > > > quantum: 4096 > > > size: 56623104 > > > inuse: 56582144 > > >> free: 40960 > > >> busy tags: 11224 > > >> free tags: 3 > > >I think this is the trouble. > > > > > >Did you tried to reduce kern.maxvnodes ? What is the default value for > > >the knob on your machine ? > > The default is 84342. > > I have tried 64K, 32K and 128K and they all hung sooner or later. > > For the 32K case, I did see vnodes being recycled for a while before it g= > ot hung, > > so it isn't just when it hits the limit. > > > > Although it is much easier for me to reproduce on an NFS mount, I did see > > a hang while doing a kernel build on UFS (no NFS mount on the machine at > > that time). > > > > So, I now know that the problem pre-dates r358252 and is not NFS specific= > . > > > > I'm not bisecting back further to try and isolate the commit that causes = > this. > > (Unfortunately, each test cycle can take days. I now know that I have to = > do > > several of these kernel builds, which take hours each, to see if a hang i= > s going > > to happen.) > > > > I'll post if/when I have more, rick > > > > We scaled maxvnodes for ZFS and UFS, might be NFS is even more demanding, > > having larger node size. > > > > > inuse size free size > > > 4096 11091 45428736 0 0 > > > 8192 63 516096 0 0 > > > 16384 12 196608 0 0 > > > 32768 6 196608 0 0 > > > 40960 2 81920 1 40960 > > > 65536 16 1048576 0 0 > > > 94208 1 94208 0 0 > > > 110592 1 110592 0 0 > > > 131072 15 2441216 0 0 > > > 262144 15 3997696 0 0 > > > 524288 1 524288 0 0 > > > 1048576 1 1945600 0 0 > > > vmem 0x.. 'kernel arena' > > > quantum: 4096 > > > size: 390070272 > > > inuse: 386613248 > > > free: 3457024 > > > busy tags: 873 > > > free tags: 3 > > > inuse size free size > > > 4096 35 143360 1 4096 > > > 8192 2 16384 2 16384 > > > 12288 1 12288 0 0 > > > 16384 30 491520 0 0 > > > 20480 140 2867200 0 0 > > > 65536 1 65536 0 0 > > > 131072 631 82706432 0 0 > > > 1048576 0 0 1 1339392 > > > 2097152 27 56623104 1 2097152 > > > 8388608 1 13774848 0 0 > > > 16777216 3 74883072 0 0 > > > 33554432 1 36753408 0 0 > > > 67108864 1 118276096 0 0 > > > > > > > alltrace > > > - I can't face typing too much more, but I'll put a few > > > here that look interesting > > > > > > - for csh > > > sched_switch() > > > mi_switch() > > > kern_yield() > > > getblkx() > > > breadn_flags() > > > ffs_update() > > > ufs_inactive() > > > VOP_INACTIVE() > > > vinactivef() > > > vput_final() > > > vm_object_deallocate() > > > vm_map_process_deferred() > > > kern_munmap() > > > sys_munmap() > > > > > > - For cc > > > sched_switch() > > > mi_switch() > > > sleepq_switch() > > > sleepq_timedwait() > > > _sleep() > > > pause_sbt() > > > vmem_bt_alloc() > > > keg_alloc_slab() > > > zone_import() > > > cache_alloc() > > > cache_alloc_retry() > > > uma_zalloc_arg() > > > bt_fill() > > > vmem_xalloc() > > > vmem_alloc() > > > kmem_alloc() > > > kmem_malloc_domainset() > > > page_alloc() > > > keg_alloc_slab() > > > zone_import() > > > cache_alloc() > > > cache_alloc_retry() > > > uma_zalloc_arg() > > > nfscl_nget() > > > nfs_create() > > > vop_sigdefer() > > > nfs_vnodeops_bypass() > > > VOP_CREATE_APV() > > > vn_open_cred() > > > vn_open() > > > kern_openat() > > > sys_openat() > > > > > > Then there are a bunch of these... for cc, make > > > sched_switch() > > > mi_switch() > > > sleepq_switch() > > > sleepq_catch_signals() > > > sleepq_wait_sig() > > > kern_wait6() > > > sys_wait4() > > > > > > - for vnlru > > > sched_switch() > > > mi_switch() > > > sleepq_switch() > > > sleepq_timedwait() > > > _sleep() > > > vnlru_proc() > > > fork_exit() > > > fork_trampoline() > > > > > > - for syncer > > > sched_switch() > > > mi_switch() > > > critical_exit_preempt() > > > intr_event_handle() > > > intr_execute_handlers() > > > lapic_handle_intr() > > > Xapic_isr1() > > > - interrupt > > > memset() > > > cache_alloc() > > > cache_alloc_retry() > > > uma_zalloc_arg() > > > vmem_xalloc() > > > vmem_bt_alloc() > > > keg_alloc_slab() > > > zone_import() > > > cache_alloc() > > > cache_alloc_retry() > > > uma_zalloc_arg() > > > bt_fill() > > > vmem_xalloc() > > > vmem_alloc() > > > bufkva_alloc() > > > getnewbuf() > > > getblkx() > > > breadn_flags() > > > ffs_update() > > > ffs_sync() > > > sync_fsync() > > > VOP_FSYNC_APV() > > > sched_sync() > > > fork_exit() > > > fork_trampoline() > > > > > > - For bufdaemon (a bunch of these) > > > sched_switch() > > > mi_switch() > > > sleepq_switch() > > > sleepq_timedwait() > > > _sleep() > > > buf_daemon() > > > fork_exit() > > > fork_trampoline() > > > > > > vmdaemon and pagedaemon are basically just like above, > > > sleeping in > > > vm_daemon() > > > or > > > vm_pageout_worker() > > > or > > > vm_pageout_laundry_worker() > > > or > > > uma_reclaim_worker() > > > > > > That's all the typing I can take right now. > > > I can probably make this happen again if you want more specific stuff. > > > > > > rick > > > > > > > > > > > > > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= > " > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org= > " > > _______________________________________________ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org From owner-freebsd-current@freebsd.org Fri Jul 3 02:57:48 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0007A36665E for ; Fri, 3 Jul 2020 02:57:47 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x535.google.com (mail-pg1-x535.google.com [IPv6:2607:f8b0:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yflZ61xDz4ZW8; Fri, 3 Jul 2020 02:57:46 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg1-x535.google.com with SMTP id m22so4054978pgv.9; Thu, 02 Jul 2020 19:57:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mhQXdmpdvTQJc+JVKbEIeBXQpu0lID2n6ldOSNY7Ruw=; b=biqOinZtdE/d+uCVprAjHcIcof+F+/d5w4erAHIHqQmtOasyyr13DmSeRgKFhhRbxm ltyu9yN2z33daZXkbMcseLWUPOQ0qwukr/wCDfms7VwbtfKWfRRBn7XGQ5nhj4ep8nBi Ml/1lcRpcvQKulaGlaGFHRqgfOzipVHvtcByVoQcQkgfeALW4m3Fv4y27CMg4tIRpSBH ZVcaFk6tNppMjcIP3RUPWfISxN7fJ501MsCYAGKEM2A0oknpDUUo+zK7kygH1T/2y4Il Zuvvlo2Bms4Ise1Es01hsSIEveOtm6Z2JpAmKclQoHsp+MpiIgf+pihRiHHzMEnAuiss 8hqw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=mhQXdmpdvTQJc+JVKbEIeBXQpu0lID2n6ldOSNY7Ruw=; b=HawzLCLr5XSEYGwpeX1QuxnsIndnZ3qTEVdbUHTQVCDOcpQnTAXyxoNGkwj2LgzI4B xnqO9YU9hSrZkgfokjPIVgQVYE21p6iKgfZRMQuLJBpcsWC/tBOPRHr2/WHHRF5t2Ud8 tPl6TOohFbhpPA/ZizyGbpqWGRi7LXzOUyDWfnfdu8MxKo64FfnVculp6i5HVCAE1bHb GN2mItmDs/EWZhD2O/W4MGjI8evA+HiDO4/lcyxYAOU5pj6/hN3cYbkcfg1uAr1iLmtM u4w2DKRg63pJboWU40xBR7lCInTvoMjiP3MawgEtNg7Rt1isKxRYLYG3s0xVqV8obsWv qHCQ== X-Gm-Message-State: AOAM531nr4tBR8NCMrAsyNTkqVg/Qvy0h8BV4wCwQX1ISDCirtekX5Do WkHYRld7O/g7V6ryFrh+w1RxXQVOmX0= X-Google-Smtp-Source: ABdhPJwqXAUoqqd09OqGm+QacFx9nh0fkBS6Su9Dot7AfFRDUUGiuP1G6lIR4ztrBt/bYyeXt7FBRQ== X-Received: by 2002:a05:6a00:15ca:: with SMTP id o10mr31637188pfu.169.1593745064922; Thu, 02 Jul 2020 19:57:44 -0700 (PDT) Received: from [192.168.20.26] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id g9sm9324479pfm.151.2020.07.02.19.57.43 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 02 Jul 2020 19:57:44 -0700 (PDT) Content-Type: text/plain; charset=utf-8 Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Undeletable files after kyua test runs From: Enji Cooper In-Reply-To: <20200629172626.GA63722@lion.0xfce3.net> Date: Thu, 2 Jul 2020 19:57:43 -0700 Cc: freebsd-current , Alan Somers Content-Transfer-Encoding: quoted-printable Message-Id: References: <20200629172626.GA63722@lion.0xfce3.net> To: Gordon Bergling X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49yflZ61xDz4ZW8 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=biqOinZt; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::535 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-2.51 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.02)[-0.025]; RECEIVED_SPAMHAUS_PBL(0.00)[73.19.52.228:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.998]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.985]; MIME_GOOD(-0.10)[text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::535:from]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 02:57:48 -0000 > On Jun 29, 2020, at 10:26 AM, Gordon Bergling wrote: >=20 > Hi, >=20 > I recently stumbled across undeletable files that are generated by = kyua test runs, > for example >=20 > -rwxr-xr-x 1 root wheel 0 May 9 13:10 = /tmp/kyua.aB4q62/8676/work/fileforaudit >=20 > I haven't yet identified the test that generate those files, but it is = impossible > to delete them. I have clear_tmp_enable=3D"YES" set in the = /etc/rc.conf, but=20 > on every boot the system argues that these file aren't deletable.=20 > I tried to 'rm -rf' them by hand but, even this wasn't possible. I = have looked for > any extend attributes, but I didn't find any. >=20 > Has anyone an idea how this is possible and may how these files can be = deleted? The issue is tests/sys/audit/file-attribute-modify.c , based on the file = present that can=E2=80=99t be deleted. Can you please provide more = information about the test run in a PR (I see how it can leave files = behind, but I want to make sure it is what I think it is, first)? Cheers, -Enji= From owner-freebsd-current@freebsd.org Fri Jul 3 07:17:30 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 239A736CA98 for ; Fri, 3 Jul 2020 07:17:30 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) Received: from CAN01-QB1-obe.outbound.protection.outlook.com (mail-eopbgr660068.outbound.protection.outlook.com [40.107.66.68]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "mail.protection.outlook.com", Issuer "GlobalSign Organization Validation CA - SHA256 - G3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49ymWD70tPz3cM1; Fri, 3 Jul 2020 07:17:28 +0000 (UTC) (envelope-from rmacklem@uoguelph.ca) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=gCGEoVgrlOrMidmfS2oWc8fU0MgNjdV27blagGkCd+8jV8cXAkBu0q3oWy3raRLDT5B5+HGNRsPZaiBIqIdu/g6bxikuLmG12FMMJZQdQt8mHqgJJ0+EIEzhZcHSy1YLeTE1ArhHAoC/CH9ia8pYzjin5gTNqTJQfK+MfzpcKF72CdQhNJmR8w18A2FmLbMEND8ChqyPi85xBWydO3/O0YwfIvihauF3zQn2Jc5FwYsQlNAhjB29qpuAF3PnnEjC/RnGNECc61uGx4ygf8tY4kxtfoZY9OSltM3nCnZ/vVvhyGSBuzDn6IjtYjayTI65VwNauKihamRdzDPt3ia5/A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5oE1W12vJ5BwY8QUd8/hN2CU70wmqbBULyN4NZvrxM=; b=S9y1oPBwU8rhS6tjRirs7sK+dNh2ARkAUyzWFA7d3UJ9+Vk+QY8Bd0vYVcthPVgjU8QdhlpUxIcDzlN/jaqa0NcrbfA8eG+36F+bwGYJXO5sQhHK7xCbZXCtj6RmoVOapzsem6kAJZXf2gMEHrvGpZe+vtAaVtzXaPpgzCyFlM0/60zfLyZtULyz0tusvrcPxlKcOvyHywryrT7oUzrvqu31I2QZIlXeryZki+xb2hOKD90S8+K0vEa8RvB4siOU71a/35+jiENDtyQuLuDWv7Fa6lvFZAIcxgRrveF3pqwDa/UbeApPl6wi9U/eKjyY5aBDhEYF0cYHR6wuoQOa9Q== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=uoguelph.ca; dmarc=pass action=none header.from=uoguelph.ca; dkim=pass header.d=uoguelph.ca; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=uoguelph.ca; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=S5oE1W12vJ5BwY8QUd8/hN2CU70wmqbBULyN4NZvrxM=; b=MWrQVu944bWc60xr6Hm+gws4HEN7ynJgrUhvnhVJNjnOXQB51axjlYtczysD7zW4zRi1/8Q/eGt/0crvrsORwIA7tXQNZT8LbYVbxpe3WdqIpRvVyft788Nu9/9H4Npky3ZQ9DxuBHWpIssstBsga6YmlT+xVwt/2RISCRSibMq+6uCNa1yGnZcrhX/FJsvX4dFqpDq/WU2h8D90oBnOZ9pcz2kbf0qRF2JFn536ahhiJ/Z93FfJ17P2D9A42MvnOM6syyN1G6kDC/YdmsxBZudPyJr1i7BLCccdGC0ENOeZk1S0QAiRPLHl6b8uTSUmA2j/q5tRpQqtbZe4+zbSKA== Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:38::14) by YQXPR0101MB1366.CANPRD01.PROD.OUTLOOK.COM (2603:10b6:c00:22::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3153.23; Fri, 3 Jul 2020 07:17:25 +0000 Received: from QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91]) by QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM ([fe80::60f3:4ca2:8a4a:1e91%7]) with mapi id 15.20.3153.024; Fri, 3 Jul 2020 07:17:25 +0000 From: Rick Macklem To: Ryan Libby CC: Konstantin Belousov , Jeff Roberson , "freebsd-current@freebsd.org" Subject: Re: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc Thread-Topic: r358252 causes intermittent hangs where processes are stuck sleeping on btalloc Thread-Index: AQHWReusQxRwbcmYh0+wsR7fidfwj6jvFvdcgAKGy4CAA+h0jg== Date: Fri, 3 Jul 2020 07:17:25 +0000 Message-ID: References: , In-Reply-To: Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: yes X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: a466b2ed-333c-4ff5-ff81-08d81f21230e x-ms-traffictypediagnostic: YQXPR0101MB1366: x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:9508; x-forefront-prvs: 045315E1EE x-ms-exchange-senderadcheck: 1 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: sfp89+SLZSmRxHK+V/E0NSSYBETihzXsgMISpzJGeqMQR1Quxlx7TseH0ojt7l9y/tgMSFpL6WYuna1VV+URewzoiS8WOMR+enCE075TXs9gAZllSCfPaz7hzegfpjWpGuW0ToVRgW76DxTlzstcCgKbCGlfcvzHBUfNHHCZtcUG58AGat53I9XL+ma7uBGmghvIrAJSDQbZtEK4NhGFsgKmh+5esDezciQ4djy1UmbGWj2uMlohwXKqR4IZvvKmXEqrXAiojTVWTuLsQvLIgRM3J3KZRl6yKxkNg8l+7k6CHAaaz/eyED8fXtMp8SOWd/fdI/z0IbmMNsAZqLDfU8rT32N3q2AjTdTXtTLiOS4eN9aHOHpKVT8RFM/svz58Lnueoe6E9GMARRJt+TpAlW0nA4sn5H8rnrIurlUeHR/IsjfyoagueuS9PWHOROSFxuErWWfybocGxwF7cSijRQ== x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFTY:; SFS:(366004)(376002)(136003)(396003)(346002)(39860400002)(786003)(54906003)(71200400001)(6916009)(9686003)(316002)(55016002)(52536014)(33656002)(83380400001)(6506007)(53546011)(478600001)(966005)(4326008)(450100002)(8936002)(7696005)(99936003)(8676002)(2906002)(186003)(5660300002)(86362001)(66556008)(64756008)(66446008)(30864003)(66616009)(66476007)(66946007)(76116006)(299355004); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata: aKJzwisYaYSapHA00VE9rZw30ZVYJLy9HOnGjLkSzsxUQyHkOQtlCNsXc2hMr3WrdiZ8Qoe8+kBIMqomV1Voz+Q5dGkldBHEVa7f7ZXtFt+WE/hoykH4uuNHaSBgz5BcQZxuts12ZDNz9zN7kr3+Ew/RTM9Z7eTWzMYySz0KX9bEzAOt+VmXVsELn7p/7deoZLkXrxkaniUd/u+lHYMsO5jP/SEzGPGjKym3oo6vhINTeXApXmBe+pDeniu+o/uwoPX94OEZ/T18xxuyx6xJ66N/fwwUt7zn47KWqJTBd62wSZCDRhYKVpwWGX6eBU7xZJSEIvSS1T+0BYh4lHtGbdKsw+CKcl1TSQoBJo0F7r7XrZIsemom3bHNzCJdF33+D0F57NVM5G0/la+QSfs6GLBU7gsc7V+3iS1+vO6j/OH9XslkS3/dw6fKZGn/dN9pNjBtAd16nrzz0yZ/4a/gL4kN1jIq7bIi0LP/HxZoUwjNF4M/nNf9mZ4oGU/YkJL7UYAhPM9OhdDihUYeDkWE+lqAWMjtlOXu8ixtMwGF/Ww= x-ms-exchange-transport-forked: True Content-Type: multipart/mixed; boundary="_002_QB1PR01MB3364709D9D16CD0E550DAC7CDD6A0QB1PR01MB3364CANP_" MIME-Version: 1.0 X-OriginatorOrg: uoguelph.ca X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: QB1PR01MB3364.CANPRD01.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: a466b2ed-333c-4ff5-ff81-08d81f21230e X-MS-Exchange-CrossTenant-originalarrivaltime: 03 Jul 2020 07:17:25.4413 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: be62a12b-2cad-49a1-a5fa-85f4f3156a7d X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: LOx/bmYB+PjSWznOKYEctM/QKewJoSyTXf4Ri5ZEopKm99VpUv9uhMd1aGcRfGpBOHyq8wcj8KqbZknjIv1eow== X-MS-Exchange-Transport-CrossTenantHeadersStamped: YQXPR0101MB1366 X-Rspamd-Queue-Id: 49ymWD70tPz3cM1 X-Spamd-Bar: ----- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=uoguelph.ca header.s=selector1 header.b=MWrQVu94; dmarc=none; spf=pass (mx1.freebsd.org: domain of rmacklem@uoguelph.ca designates 40.107.66.68 as permitted sender) smtp.mailfrom=rmacklem@uoguelph.ca X-Spamd-Result: default: False [-5.22 / 15.00]; TO_DN_EQ_ADDR_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-1.03)[-1.025]; R_DKIM_ALLOW(-0.20)[uoguelph.ca:s=selector1]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[4]; TO_DN_SOME(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; HAS_ATTACHMENT(0.00)[]; DMARC_NA(0.00)[uoguelph.ca]; R_SPF_ALLOW(-0.20)[+ip4:40.107.0.0/16]; DWL_DNSWL_LOW(-1.00)[uoguelph.ca:dkim]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[uoguelph.ca:+]; NEURAL_HAM_SHORT(-0.71)[-0.706]; RCVD_IN_DNSWL_NONE(0.00)[40.107.66.68:from]; NEURAL_HAM_LONG(-0.99)[-0.989]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:8075, ipnet:40.104.0.0/14, country:US]; ARC_ALLOW(-1.00)[microsoft.com:s=arcselector9901:i=1]; RWL_MAILSPIKE_POSSIBLE(0.00)[40.107.66.68:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 07:17:30 -0000 --_002_QB1PR01MB3364709D9D16CD0E550DAC7CDD6A0QB1PR01MB3364CANP_ Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Ryan Libby wrote:=0A= >On Sun, Jun 28, 2020 at 9:57 PM Rick Macklem wrote:= =0A= >>=0A= >> Just in case you were waiting for another email, I have now run several= =0A= >> cycles of the kernel build over NFS on a recent head kernel with the=0A= >> one line change and it has not hung.=0A= >>=0A= >> I don't know if this is the correct fix, but it would be nice to get som= ething=0A= >> into head to fix this.=0A= >>=0A= >> If I don't hear anything in the next few days, I'll put it in a PR so it= =0A= >> doesn't get forgotten.=0A= >>=0A= >> rick=0A= >=0A= >Thanks for the follow through on this.=0A= >=0A= >I think the patch is not complete. It looks like the problem is that=0A= >for systems that do not have UMA_MD_SMALL_ALLOC, we do=0A= > uma_zone_set_allocf(vmem_bt_zone, vmem_bt_alloc);=0A= >but we haven't set an appropriate free function. This is probably why=0A= >UMA_ZONE_NOFREE was originally there. When NOFREE was removed, it was=0A= >appropriate for systems with uma_small_alloc.=0A= >=0A= >So by default we get page_free as our free function. That calls=0A= >kmem_free, which calls vmem_free ... but we do our allocs with=0A= >vmem_xalloc. I'm not positive, but I think the problem is that in=0A= >effect we vmem_xalloc -> vmem_free, not vmem_xfree.=0A= >=0A= >Three possible fixes:=0A= > 1: The one you tested, but this is not best for systems with=0A= > uma_small_alloc.=0A= > 2: Pass UMA_ZONE_NOFREE conditional on UMA_MD_SMALL_ALLOC.=0A= > 3: Actually provide an appropriate vmem_bt_free function.=0A= >=0A= >I think we should just do option 2 with a comment, it's simple and it's=0A= >what we used to do. I'm not sure how much benefit we would see from=0A= >option 3, but it's more work.=0A= I set hw.physmem to 1Gbyte on my amd64 system (did not have the patch)=0A= and ran 6 cycles of the kernel build over NFS without a hang, so I don't=0A= think any fix is needed for systems that support UMA_MD_SMALL_ALLOC.=0A= =0A= The trivial patch for option 2 is attached.=0A= I didn't do a comment, since you understand this and can probably=0A= describe it more correctly.=0A= =0A= Thanks, rick=0A= =0A= Ryan=0A= =0A= >=0A= > ________________________________________=0A= > From: owner-freebsd-current@freebsd.org on behalf of Rick Macklem =0A= > Sent: Thursday, June 18, 2020 11:42 PM=0A= > To: Ryan Libby=0A= > Cc: Konstantin Belousov; Jeff Roberson; freebsd-current@freebsd.org=0A= > Subject: Re: r358252 causes intermittent hangs where processes are stuck = sleeping on btalloc=0A= >=0A= > Ryan Libby wrote:=0A= > >On Mon, Jun 15, 2020 at 5:06 PM Rick Macklem wrot= e:=0A= > >>=0A= > >> Rick Macklem wrote:=0A= > >> >r358098 will hang fairly easily, in 1-3 cycles of the kernel build ov= er =3D=0A= > NFS.=0A= > >> >I thought this was the culprit, since I did 6 cycles of r358097 witho= ut =3D=0A= > a hang.=0A= > >> >However, I just got a hang with r358097, but it looks rather differen= t.=0A= > >> >The r358097 hang did not have any processes sleeping on btalloc. They= =0A= > >> >appeared to be waiting on two different locks in the buffer cache.=0A= > >> >As such, I think it might be a different problem. (I'll admit I shoul= d h=3D=0A= > ave=0A= > >> >made notes about this one before rebooting, but I was flustrated that= =0A= > >> >it happened and rebooted before looking at it mush detail.)=0A= > >> Ok, so I did 10 cycles of the kernel build over NFS for r358096 and ne= ver=0A= > >> got a hang.=0A= > >> --> It seems that r358097 is the culprit and r358098 makes it easier= =0A= > >> to reproduce.=0A= > >> --> Basically runs out of kernel memory.=0A= > >>=0A= > >> It is not obvious if I can revert these two commits without reverting= =0A= > >> other ones, since there were a bunch of vm changes after these.=0A= > >>=0A= > >> I'll take a look, but if you guys have any ideas on how to fix this, p= lea=3D=0A= > se=0A= > >> let me know.=0A= > >>=0A= > >> Thanks, rick=0A= > >=0A= > >Interesting. Could you try re-adding UMA_ZONE_NOFREE to the vmem btag= =0A= > >zone to see if that rescues it, on whatever base revision gets you a=0A= > >reliable repro?=0A= > Good catch! That seems to fix it. I've done 8 cycles of kernel build over= =0A= > NFS without a hang (normally I'd get one in the first 1-3 cycles).=0A= >=0A= > I don't know if the intend was to delete UMA_ZONE_VM and r358097=0A= > had a typo in it and deleted UMA_ZONE_NOFREE or ???=0A= >=0A= > Anyhow, I just put it back to UMA_ZONE_VM | UMA_ZONE_NOFREE and=0A= > the hangs seem to have gone away.=0A= >=0A= > The small patch I did is attached, in case that isn't what you meant.=0A= >=0A= > I'll run a few more cycles just in case, but I think this fixes it.=0A= >=0A= > Thanks, rick=0A= >=0A= > >=0A= > > Jeff, to fill you in, I have been getting intermittent hangs on a Penti= um=3D=0A= > 4=0A= > > (single core i386) with 1.25Gbytes ram when doing kernel builds using= =0A= > > head kernels from this winter. (I also saw one when doing a kernel buil= d=0A= > > on UFS, so they aren't NFS specific, although easier to reproduce that = wa=3D=0A= > y.)=0A= > > After a typical hang, there will be a bunch of processes sleeping on "b= ta=3D=0A= > lloc"=0A= > > and several processes holding the following lock:=0A= > > exclusive sx lock @ vm/vm_map.c:4761=0A= > > - I have seen hangs where that is the only lock held by any process exc= ep=3D=0A= > t=0A= > > the interrupt thread.=0A= > > - I have also seen processes waiting on the following locks:=0A= > > kern/subr_vmem.c:1343=0A= > > kern/subr_vmem.c:633=0A= > >=0A= > > I can't be absolutely sure r358098 is the culprit, but it seems to make= t=3D=0A= > he=0A= > > problem more reproducible.=0A= > >=0A= > > If anyone has a patch suggestion, I can test it.=0A= > > Otherwise, I will continue to test r358097 and earlier, to try and see = wh=3D=0A= > at hangs=0A= > > occur. (I've done 8 cycles of testing of r356776 without difficulties, = bu=3D=0A= > t that=0A= > > doesn't guarantee it isn't broken.)=0A= > >=0A= > > There is a bunch more of the stuff I got for Kostik and Ryan below.=0A= > > I can do "db" when it is hung, but it is a screen console, so I need to= =0A= > > transcribe the output to email by hand. (ie. If you need something=0A= > > specific I can do that, but trying to do everything Kostik and Ryan ask= ed=0A= > > for isn't easy.)=0A= > >=0A= > > rick=0A= > >=0A= > >=0A= > >=0A= > > Konstantin Belousov wrote:=0A= > > >On Fri, May 22, 2020 at 11:46:26PM +0000, Rick Macklem wrote:=0A= > > >> Konstantin Belousov wrote:=0A= > > >> >On Wed, May 20, 2020 at 11:58:50PM -0700, Ryan Libby wrote:=0A= > > >> >> On Wed, May 20, 2020 at 6:04 PM Rick Macklem =3D=0A= > wrote:=0A= > > >> >> >=0A= > > >> >> > Hi,=0A= > > >> >> >=0A= > > >> >> > Since I hadn't upgraded a kernel through the winter, it took me= a=3D=0A= > while=0A= > > >> >> > to bisect this, but r358252 seems to be the culprit.=0A= > > No longer true. I succeeded in reproducing the hang to-day running a=0A= > > r358251 kernel.=0A= > >=0A= > > I haven't had much luck sofar, but see below for what I have learned.= =0A= > >=0A= > > >> >> >=0A= > > >> >> > If I do a kernel build over NFS using my not so big Pentium 4 (= si=3D=0A= > ngle core,=0A= > > >> >> > 1.25Gbytes RAM, i386), about every second attempt will hang.=0A= > > >> >> > When I do a "ps" in the debugger, I see processes sleeping on b= ta=3D=0A= > lloc.=0A= > > >> >> > If I revert to r358251, I cannot reproduce this.=0A= > > As above, this is no longer true.=0A= > >=0A= > > >> >> >=0A= > > >> >> > Any ideas?=0A= > > >> >> >=0A= > > >> >> > I can easily test any change you might suggest to see if it fix= es=3D=0A= > the=0A= > > >> >> > problem.=0A= > > >> >> >=0A= > > >> >> > If you want more debug info, let me know, since I can easily=0A= > > >> >> > reproduce it.=0A= > > >> >> >=0A= > > >> >> > Thanks, rick=0A= > > >> >>=0A= > > >> >> Nothing obvious to me. I can maybe try a repro on a VM...=0A= > > >> >>=0A= > > >> >> ddb ps, acttrace, alltrace, show all vmem, show page would be wel= co=3D=0A= > me.=0A= > > >> >>=0A= > > >> >> "btalloc" is "We're either out of address space or lost a fill ra= ce=3D=0A= > ."=0A= > > From what I see, I think it is "out of address space".=0A= > > For one of the hangs, when I did "show alllocks", everything except the= =0A= > > intr thread, was waiting for the=0A= > > exclusive sx lock @ vm/vm_map.c:4761=0A= > >=0A= > > >> >=0A= > > >> >Yes, I would be not surprised to be out of something on 1G i386 mac= hi=3D=0A= > ne.=0A= > > >> >Please also add 'show alllocks'.=0A= > > >> Ok, I used an up to date head kernel and it took longer to reproduce= a=3D=0A= > hang.=0A= > > Go down to Kostik's comment about kern.maxvnodes for the rest of what I= 'v=3D=0A= > e=0A= > > learned. (The time it takes to reproduce one of these varies greatly, b= ut=3D=0A= > I usually=0A= > > get one within 3 cycles of a full kernel build over NFS. I have had it = ha=3D=0A= > ppen=0A= > > once when doing a kernel build over UFS.)=0A= > >=0A= > > >> This time, none of the processes are stuck on "btalloc".=0A= > > > I'll try and give you most of the above, but since I have to type it = in=3D=0A= > by hand=0A= > > > from the screen, I might not get it all. (I'm no real typist;-)=0A= > > > > show alllocks=0A= > > > exclusive lockmgr ufs (ufs) r =3D3D 0 locked @ kern/vfs_subr.c: 3259= =0A= > > > exclusive lockmgr nfs (nfs) r =3D3D 0 locked @ kern/vfs_lookup.c:737= =0A= > > > exclusive sleep mutex kernel area domain (kernel arena domain) r =3D3= D 0 =3D=0A= > locked @ kern/subr_vmem.c:1343=0A= > > > exclusive lockmgr bufwait (bufwait) r =3D3D 0 locked @ kern/vfs_bio.c= :166=3D=0A= > 3=0A= > > > exclusive lockmgr ufs (ufs) r =3D3D 0 locked @ kern/vfs_subr.c:2930= =0A= > > > exclusive lockmgr syncer (syncer) r =3D3D 0 locked @ kern/vfs_subr.c:= 2474=0A= > > > Process 12 (intr) thread 0x.. (1000008)=0A= > > > exclusive sleep mutex Giant (Giant) r =3D3D 0 locked @ kern/kern_intr= .c:1=3D=0A= > 152=0A= > > >=0A= > > > > ps=0A= > > > - Not going to list them all, but here are the ones that seem interes= ti=3D=0A= > ng...=0A= > > > 18 0 0 0 DL vlruwt 0x11d939cc [vnlru]=0A= > > > 16 0 0 0 DL (threaded) [bufdaemon]=0A= > > > 100069 D qsleep [bufdaemon]=0A= > > > 100074 D - [bufspacedaemon-0]=0A= > > > 100084 D sdflush 0x11923284 [/ worker]=0A= > > > - and more of these for the other UFS file systems=0A= > > > 9 0 0 0 DL psleep 0x1e2f830 [vmdaemon]=0A= > > > 8 0 0 0 DL (threaded) [pagedaemon]=0A= > > > 100067 D psleep 0x1e2e95c [dom0]=0A= > > > 100072 D launds 0x1e2e968 [laundry: dom0]=0A= > > > 100073 D umarcl 0x12cc720 [uma]=0A= > > > =3DE2=3D80=3DA6 a bunch of usb and cam ones=0A= > > > 100025 D - 0x1b2ee40 [doneq0]=0A= > > > =3DE2=3D80=3DA6=0A= > > > 12 0 0 0 RL (threaded) [intr]=0A= > > > 100007 I [swi6: task queue]=0A= > > > 100008 Run CPU 0 [swi6: Giant taskq]=0A= > > > =3DE2=3D80=3DA6=0A= > > > 100000 D swapin 0x1d96dfc [swapper]=0A= > > > - and a bunch more in D state.=0A= > > > Does this mean the swapper was trying to swap in?=0A= > > >=0A= > > > > acttrace=0A= > > > - just shows the keyboard=0A= > > > kdb_enter() at kdb_enter+0x35/frame=0A= > > > vt_kbdevent() at vt_kdbevent+0x329/frame=0A= > > > kdbmux_intr() at kbdmux_intr+0x19/frame=0A= > > > taskqueue_run_locked() at taskqueue_run_locked+0x175/frame=0A= > > > taskqueue_run() at taskqueue_run+0x44/frame=0A= > > > taskqueue_swi_giant_run(0) at taskqueue_swi_giant_run+0xe/frame=0A= > > > ithread_loop() at ithread_loop+0x237/frame=0A= > > > fork_exit() at fork_exit+0x6c/frame=0A= > > > fork_trampoline() at 0x../frame=0A= > > >=0A= > > > > show all vmem=0A= > > > vmem 0x.. 'transient arena'=0A= > > > quantum: 4096=0A= > > > size: 23592960=0A= > > > inuse: 0=0A= > > > free: 23592960=0A= > > > busy tags: 0=0A= > > > free tags: 2=0A= > > > inuse size free size=0A= > > > 16777216 0 0 1 23592960=0A= > > > vmem 0x.. 'buffer arena'=0A= > > > quantum: 4096=0A= > > > size: 94683136=0A= > > > inuse: 94502912=0A= > > > free: 180224=0A= > > > busy tags: 1463=0A= > > > free tags: 3=0A= > > > inuse size free size=0A= > > > 16384 2 32768 1 16384=0A= > > > 32768 39 1277952 1 32768=0A= > > > 65536 1422 93192192 0 0=0A= > > > 131072 0 0 1 131072=0A= > > > vmem 0x.. 'i386trampoline'=0A= > > > quantum: 1=0A= > > > size: 24576=0A= > > > inuse: 20860=0A= > > > free: 3716=0A= > > > busy tags: 9=0A= > > > free tags: 3=0A= > > > inuse size free size=0A= > > > 32 1 48 1 52=0A= > > > 64 2 208 0 0=0A= > > > 128 2 280 0 0=0A= > > > 2048 1 2048 1 3664=0A= > > > 4096 2 8192 0 0=0A= > > > 8192 1 10084 0 0=0A= > > > vmem 0x.. 'kernel rwx arena'=0A= > > > quantum: 4096=0A= > > > size: 0=0A= > > > inuse: 0=0A= > > > free: 0=0A= > > > busy tags: 0=0A= > > > free tags: 0=0A= > > > vmem 0x.. 'kernel area dom'=0A= > > > quantum: 4096=0A= > > > size: 56623104=0A= > > > inuse: 56582144=0A= > > >> free: 40960=0A= > > >> busy tags: 11224=0A= > > >> free tags: 3=0A= > > >I think this is the trouble.=0A= > > >=0A= > > >Did you tried to reduce kern.maxvnodes ? What is the default value fo= r=0A= > > >the knob on your machine ?=0A= > > The default is 84342.=0A= > > I have tried 64K, 32K and 128K and they all hung sooner or later.=0A= > > For the 32K case, I did see vnodes being recycled for a while before it= g=3D=0A= > ot hung,=0A= > > so it isn't just when it hits the limit.=0A= > >=0A= > > Although it is much easier for me to reproduce on an NFS mount, I did s= ee=0A= > > a hang while doing a kernel build on UFS (no NFS mount on the machine a= t=0A= > > that time).=0A= > >=0A= > > So, I now know that the problem pre-dates r358252 and is not NFS specif= ic=3D=0A= > .=0A= > >=0A= > > I'm not bisecting back further to try and isolate the commit that cause= s =3D=0A= > this.=0A= > > (Unfortunately, each test cycle can take days. I now know that I have t= o =3D=0A= > do=0A= > > several of these kernel builds, which take hours each, to see if a hang= i=3D=0A= > s going=0A= > > to happen.)=0A= > >=0A= > > I'll post if/when I have more, rick=0A= > >=0A= > > We scaled maxvnodes for ZFS and UFS, might be NFS is even more demandin= g,=0A= > > having larger node size.=0A= > >=0A= > > > inuse size free size=0A= > > > 4096 11091 45428736 0 0=0A= > > > 8192 63 516096 0 0=0A= > > > 16384 12 196608 0 0=0A= > > > 32768 6 196608 0 0=0A= > > > 40960 2 81920 1 40960=0A= > > > 65536 16 1048576 0 0=0A= > > > 94208 1 94208 0 0=0A= > > > 110592 1 110592 0 0=0A= > > > 131072 15 2441216 0 0=0A= > > > 262144 15 3997696 0 0=0A= > > > 524288 1 524288 0 0=0A= > > > 1048576 1 1945600 0 0=0A= > > > vmem 0x.. 'kernel arena'=0A= > > > quantum: 4096=0A= > > > size: 390070272=0A= > > > inuse: 386613248=0A= > > > free: 3457024=0A= > > > busy tags: 873=0A= > > > free tags: 3=0A= > > > inuse size free size=0A= > > > 4096 35 143360 1 4096=0A= > > > 8192 2 16384 2 16384=0A= > > > 12288 1 12288 0 0=0A= > > > 16384 30 491520 0 0=0A= > > > 20480 140 2867200 0 0=0A= > > > 65536 1 65536 0 0=0A= > > > 131072 631 82706432 0 0=0A= > > > 1048576 0 0 1 1339392=0A= > > > 2097152 27 56623104 1 2097152=0A= > > > 8388608 1 13774848 0 0=0A= > > > 16777216 3 74883072 0 0=0A= > > > 33554432 1 36753408 0 0=0A= > > > 67108864 1 118276096 0 0=0A= > > >=0A= > > > > alltrace=0A= > > > - I can't face typing too much more, but I'll put a few=0A= > > > here that look interesting=0A= > > >=0A= > > > - for csh=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > kern_yield()=0A= > > > getblkx()=0A= > > > breadn_flags()=0A= > > > ffs_update()=0A= > > > ufs_inactive()=0A= > > > VOP_INACTIVE()=0A= > > > vinactivef()=0A= > > > vput_final()=0A= > > > vm_object_deallocate()=0A= > > > vm_map_process_deferred()=0A= > > > kern_munmap()=0A= > > > sys_munmap()=0A= > > >=0A= > > > - For cc=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > sleepq_switch()=0A= > > > sleepq_timedwait()=0A= > > > _sleep()=0A= > > > pause_sbt()=0A= > > > vmem_bt_alloc()=0A= > > > keg_alloc_slab()=0A= > > > zone_import()=0A= > > > cache_alloc()=0A= > > > cache_alloc_retry()=0A= > > > uma_zalloc_arg()=0A= > > > bt_fill()=0A= > > > vmem_xalloc()=0A= > > > vmem_alloc()=0A= > > > kmem_alloc()=0A= > > > kmem_malloc_domainset()=0A= > > > page_alloc()=0A= > > > keg_alloc_slab()=0A= > > > zone_import()=0A= > > > cache_alloc()=0A= > > > cache_alloc_retry()=0A= > > > uma_zalloc_arg()=0A= > > > nfscl_nget()=0A= > > > nfs_create()=0A= > > > vop_sigdefer()=0A= > > > nfs_vnodeops_bypass()=0A= > > > VOP_CREATE_APV()=0A= > > > vn_open_cred()=0A= > > > vn_open()=0A= > > > kern_openat()=0A= > > > sys_openat()=0A= > > >=0A= > > > Then there are a bunch of these... for cc, make=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > sleepq_switch()=0A= > > > sleepq_catch_signals()=0A= > > > sleepq_wait_sig()=0A= > > > kern_wait6()=0A= > > > sys_wait4()=0A= > > >=0A= > > > - for vnlru=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > sleepq_switch()=0A= > > > sleepq_timedwait()=0A= > > > _sleep()=0A= > > > vnlru_proc()=0A= > > > fork_exit()=0A= > > > fork_trampoline()=0A= > > >=0A= > > > - for syncer=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > critical_exit_preempt()=0A= > > > intr_event_handle()=0A= > > > intr_execute_handlers()=0A= > > > lapic_handle_intr()=0A= > > > Xapic_isr1()=0A= > > > - interrupt=0A= > > > memset()=0A= > > > cache_alloc()=0A= > > > cache_alloc_retry()=0A= > > > uma_zalloc_arg()=0A= > > > vmem_xalloc()=0A= > > > vmem_bt_alloc()=0A= > > > keg_alloc_slab()=0A= > > > zone_import()=0A= > > > cache_alloc()=0A= > > > cache_alloc_retry()=0A= > > > uma_zalloc_arg()=0A= > > > bt_fill()=0A= > > > vmem_xalloc()=0A= > > > vmem_alloc()=0A= > > > bufkva_alloc()=0A= > > > getnewbuf()=0A= > > > getblkx()=0A= > > > breadn_flags()=0A= > > > ffs_update()=0A= > > > ffs_sync()=0A= > > > sync_fsync()=0A= > > > VOP_FSYNC_APV()=0A= > > > sched_sync()=0A= > > > fork_exit()=0A= > > > fork_trampoline()=0A= > > >=0A= > > > - For bufdaemon (a bunch of these)=0A= > > > sched_switch()=0A= > > > mi_switch()=0A= > > > sleepq_switch()=0A= > > > sleepq_timedwait()=0A= > > > _sleep()=0A= > > > buf_daemon()=0A= > > > fork_exit()=0A= > > > fork_trampoline()=0A= > > >=0A= > > > vmdaemon and pagedaemon are basically just like above,=0A= > > > sleeping in=0A= > > > vm_daemon()=0A= > > > or=0A= > > > vm_pageout_worker()=0A= > > > or=0A= > > > vm_pageout_laundry_worker()=0A= > > > or=0A= > > > uma_reclaim_worker()=0A= > > >=0A= > > > That's all the typing I can take right now.=0A= > > > I can probably make this happen again if you want more specific stuff= .=0A= > > >=0A= > > > rick=0A= > > >=0A= > > >=0A= > > >=0A= > > >=0A= > > _______________________________________________=0A= > > freebsd-current@freebsd.org mailing list=0A= > > https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg=3D=0A= > "=0A= > > _______________________________________________=0A= > > freebsd-current@freebsd.org mailing list=0A= > > https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg=3D=0A= > "=0A= > > _______________________________________________=0A= > > freebsd-current@freebsd.org mailing list=0A= > > https://lists.freebsd.org/mailman/listinfo/freebsd-current=0A= > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.o= rg=0A= --_002_QB1PR01MB3364709D9D16CD0E550DAC7CDD6A0QB1PR01MB3364CANP_ Content-Type: application/octet-stream; name="uma.patch" Content-Description: uma.patch Content-Disposition: attachment; filename="uma.patch"; size=718; creation-date="Fri, 03 Jul 2020 07:16:39 GMT"; modification-date="Fri, 03 Jul 2020 07:16:39 GMT" Content-Transfer-Encoding: base64 LS0tIGtlcm4vc3Vicl92bWVtLmMuc2F2CTIwMjAtMDYtMjIgMjI6MDA6MzguNDExNzU2MDAwIC0w NzAwCisrKyBrZXJuL3N1YnJfdm1lbS5jCTIwMjAtMDctMDEgMTc6MDQ6NDcuMTE4NDk2MDAwIC0w NzAwCkBAIC02NjgsMTAgKzY2OCwxNCBAQCB2bWVtX3N0YXJ0dXAodm9pZCkKIAl2bWVtX3pvbmUg PSB1bWFfemNyZWF0ZSgidm1lbSIsCiAJICAgIHNpemVvZihzdHJ1Y3Qgdm1lbSksIE5VTEwsIE5V TEwsIE5VTEwsIE5VTEwsCiAJICAgIFVNQV9BTElHTl9QVFIsIDApOworI2lmZGVmIFVNQV9NRF9T TUFMTF9BTExPQwogCXZtZW1fYnRfem9uZSA9IHVtYV96Y3JlYXRlKCJ2bWVtIGJ0YWciLAogCSAg ICBzaXplb2Yoc3RydWN0IHZtZW1fYnRhZyksIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsCiAJICAg IFVNQV9BTElHTl9QVFIsIFVNQV9aT05FX1ZNKTsKLSNpZm5kZWYgVU1BX01EX1NNQUxMX0FMTE9D CisjZWxzZQorCXZtZW1fYnRfem9uZSA9IHVtYV96Y3JlYXRlKCJ2bWVtIGJ0YWciLAorCSAgICBz aXplb2Yoc3RydWN0IHZtZW1fYnRhZyksIE5VTEwsIE5VTEwsIE5VTEwsIE5VTEwsCisJICAgIFVN QV9BTElHTl9QVFIsIFVNQV9aT05FX1ZNIHwgVU1BX1pPTkVfTk9GUkVFKTsKIAltdHhfaW5pdCgm dm1lbV9idF9sb2NrLCAiYnRhZyBsb2NrIiwgTlVMTCwgTVRYX0RFRik7CiAJdW1hX3ByZWFsbG9j KHZtZW1fYnRfem9uZSwgQlRfTUFYQUxMT0MpOwogCS8qCg== --_002_QB1PR01MB3364709D9D16CD0E550DAC7CDD6A0QB1PR01MB3364CANP_-- From owner-freebsd-current@freebsd.org Fri Jul 3 15:25:14 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 7A0E7351235 for ; Fri, 3 Jul 2020 15:25:14 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.22]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yzL11YYDz4P5D for ; Fri, 3 Jul 2020 15:25:12 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593789910; bh=SbgPd64BAs0IvmBBs0U8PTJ/GWSTckQ/+lpPgpRQ4+Y=; h=X-UI-Sender-Class:Date:From:To:Subject; b=ZGm3RzhzaEPYh3qz4lqfkAVgMGd9XTe9pTD5W1D3W/awdj7H9fvrK1OGLmRJ8u1RV pP2CYHhFO0Ryr6mi734U87qYDhx1wNtG9A1JLhGW6wXzQWksdDJI6bGcTDYcHb2C0r ri66h2D6tUS11/TCNvhyQXD+l7Bsq/ZGRFlsZwe0= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from thor.intern.walstatt.dynvpn.de ([77.11.197.214]) by mail.gmx.com (mrgmx104 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MRCKC-1jUDy629cC-00NAPO for ; Fri, 03 Jul 2020 17:25:10 +0200 Date: Fri, 3 Jul 2020 17:24:36 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: CURRENT: bc -e results in empty string/result Message-ID: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:67rDzJClQJvZW6KM7xK5T32lLgAkdRPw/bigRpv6V513B08/ndM hAmqx3G6S/E75C7hg8NbTDF1JhKc8C32+pszJPjsHKdxcBHxmpbTnD50dcvDJG/H0H3AIRJ hpQMymsv988z3o3dGmwnP7tmXq4MVNfQpUj8yau7Aw1HLRio4z3oMY4qXrC7Te6w1zJ+UIZ IkBNaopHJsDGThRzvUSxQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:5ksUMC5YXwI=:FgYVhZdXXZl0CsSUiqLed3 Ev3ysMZhhp//3wDC3H+rkwdWOjPJxQ0vgjGpC8B9R12lnEo1Bm58XMmqd5CFmyxf3di1E+sKA DHso8qMD0MG04UcCw0FZvDEw90cNn1RCvCjmwtjrPup8tr5GFBDKqKbpW3ZalNGUDtvf8wsIu zd4Ilt0fwhlpVYNMRoy1OCwciwDUFrrIwUalGbtmqNQ21oiJvAwjNlECLzxFbwdVFcQ0ljULP nqztEauzhqJXfpnyoNJM9l/iyJOENlZQ09+94g5d3Bk3Ej+MVHYOCaQwWqQyd25wbBF03cNQ0 3Jnx+XGxPSVeic8MaZQQgB/+MTb7O5VpaNK7aruLI03T3vNMV+psWv1LL1Fm60r2bwsaDPD+i Qsv0EKUYWhUDpkjGahzkNOEFSSPE1CPLvLZgooXzzuURbyqxfr8zL37QeLaZ9vQiWd/2/0IaI aFS0lisGkvwPiCOCIQDNZraTxMQVmAWe5lo1jKCJtJdcujxl6JXPkidPruRfWDdIbR7b2lIr+ V6e7ZXiIoMyQucVJvBKsTFkUaFQbYgmA9iWeanpj4TfYuPjeYJCBogQkN3IJfgl/CbiGHHIAa eTGEGbk1ZlemfOnVunR8N5TZK8l7Jy6pnuB/4O5n+3FU69wnh97iriq3juRuXZbrGK5vi1UpG SrrTLWXk7YQ7JTmJqZWIiG+mye0HpuSsR4/HFZ+v75kEQMK1ylI+1uLgjn3vOXFZ+2fWnt+TW QM5ajZdl0XZ3zzXXIWY7TWsMVmaX8PEWE3suEfcbFO+TNwhWnz1/mKXl1h4PGsn0wDdMG3rK+ tvpQsh9C2rM9kRFaeEA3Vg9kSHuw6cgDtuXw3g4R2Cr7YFkBcy/x+m97ubMqN0mZgJk53Do0f bHM1B6m+aiyzMqBL3cV/qjVX6XcnQ89zZBwP1NzjWUGwXvzGAkzd5yLXS42z06T9CSQpfBdy8 5Dy5dmCYX4zZlwiVoGqkGRXJS5nPtlyscMzbNnyIiEBWyq/cZVPwJ40UEBIaQgchIUQMjtdtW THZMhILy184MDmAG+k5CxSYkhbr3fNKw2+H8GcnjqWKITJyI13Psz6r7bPxoDqdH4f/p/VhE/ ODtcAwD1/qQ31Vy0sk+YgLlUyDleKAdvvXZkjCwJp8FKWY4cEBJG2LUkgZsNRTg79mDkmZiJV QtwpwIXymSH9WqgK5ETeLNDgSw24Phpjndqye/WoDeU++AKRxUnuV2x2bh8sNXF02mJrDu6zf MnQCV+Y1xV2lKBNkbewbPXFFdbI2o7mJCIUL54g== X-Rspamd-Queue-Id: 49yzL11YYDz4P5D X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=ZGm3Rzhz; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.17.22) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-0.05 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.27)[-0.273]; RECEIVED_SPAMHAUS_PBL(0.00)[77.11.197.214:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.22:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.34)[-0.338]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.14)[-0.143]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.22:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:25:14 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkhlbGxv IGxpc3QsDQoNCnJ1bm5pbmcgc29tZSBzY3JpcHRzIGNhbHVjbGF0aW5nIHZpYSBiYygpIHRoZSBl eHByZXNzaW9uIHNob3duIGJlbG93Og0KDQpiYyAtZSAnNjU4MjAzMSAtIDEwNDg1NzYgLSAwIC0g NDA5NjAwIC0gMTAyNCAtIDQwIC0gNDA5NicgLWUgcXVpdA0KDQpyZXN1bHRzIG9uIHJlY2VudCBD VVJSRU5UICggRnJlZUJTRCAxMy4wLUNVUlJFTlQgIzgwIHIzNjI4ODQ6IFRodSBKdWwgIDIgMTA6 MDg6MjMgQ0VTVCAyMDIwDQphbWQ2NCkgd2l0aCBhbiBlbXB0eSByZXN1bHQsIHdoaWxlIGl0IGlz IGNhbGN1bGF0ZWQgY29ycmVjdGx5IG9uIDEyLVNUQUJMRSAoRnJlZUJTRA0KMTIuMS1TVEFCTEUg IzY3IHIzNjI3MTk6IFN1biBKdW4gMjggMDk6NTk6MjAgQ0VTVCAyMDIwIGFtZDY0KSBhbmQgYSBD VVJSRU5UIGRhdGVkIGZyb20gIFN1bg0KSnVuIDI4dGggKGhhdmUgbm8gcmV2aXNpb24gbnVtYmVy IGFueW1vcmUsIHRoZSBleHByZXNzaW9uIGFib3ZlIHdhcyBjYWxjdWxhdGVkIGNvcnJlY3RseSBv bg0KdGhlIHNhbWUgYm94IHdoaWNoIG5vdyBoYXMgcjM2Mjg4NCBhbmQgaXMgZmFpbGluZykuDQoN CldoYXRzIHdyb25nPw0KDQpLaW5kIHJlZ2FyZHMsDQoNCm9saXZlcg0KDQotLS0tLUJFR0lOIFBH UCBTSUdOQVRVUkUtLS0tLQ0KDQppSFVFQVJZSUFCMFdJUVN5OElCeEFQRGtxVkJhVEo0NE4xWlpQ YmE1UndVQ1h2OU56d0FLQ1JBNE4xWlpQYmE1DQpSenQ0QVFEWnM5TUVEL016enZ5NGpOQkRJMzRq dllwRDUzNnVQaGZRQnZUS3FpbmRDZ0VBcXFsalBsWDViS203DQp4dGo4Vlo0aDNTTDZKZG53RVpL bW5HR1NLVHA2QUE4PQ0KPTZ6dDYNCi0tLS0tRU5EIFBHUCBTSUdOQVRVUkUtLS0tLQ0K From owner-freebsd-current@freebsd.org Fri Jul 3 15:39:49 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0F1933515EB for ; Fri, 3 Jul 2020 15:39:49 +0000 (UTC) (envelope-from ohartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yzfq5WQdz4PkV for ; Fri, 3 Jul 2020 15:39:47 +0000 (UTC) (envelope-from ohartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593790785; bh=eiVZOI+Yau1DUWutmKXldmfLLRpyBzIDm3O3aPV6TgY=; h=X-UI-Sender-Class:Date:From:To:Subject:In-Reply-To:References; b=bnwHYpTLHy2TsvH9wqRSrNpKVRxz/ywzijOb11dbWBvjvqv5o+B+OoB2wPvWGiy8/ si//rRAvFCCWYF5z4Xx8QObQXQ9DdmP7NfgMmICwWhVvm21orgTlRR7dHnaTAP8Soa bNnJ+9eZ8nqEB/3ncYbdyDljlLib7Jf0OuT9UmIY= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from thor.intern.walstatt.dynvpn.de ([77.11.197.214]) by mail.gmx.com (mrgmx004 [212.227.17.190]) with ESMTPSA (Nemesis) id 1MjjCL-1j6Xj02cbj-00lCRc for ; Fri, 03 Jul 2020 17:39:45 +0200 Date: Fri, 3 Jul 2020 17:39:10 +0200 From: "O. Hartmann" To: FreeBSD CURRENT Subject: Re: CURRENT: bc -e results in empty string/result Message-ID: <20200703173937.5c4db920@thor.intern.walstatt.dynvpn.de> In-Reply-To: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> References: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> Organization: WALSTATT User-Agent: OutScare 3.1415926 X-Operating-System: ImNotAnOperatingSystem 3.141592527 MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: base64 X-Provags-ID: V03:K1:4kVkV6kvGlAbSTY5DTJxtKzKqI1sCAwPam1ijDi2HGSSuCD9AJg z5yu2HOWeqy0UdCaARclmQtlbVNNj7bvNANhQURXz4d2M1brL7zCYcPNngrOJQfKZFWEzgA Ge320cKm9Eorgz0hTc0H2StLdM6LHFgz8MAKSz+rx7YJ3/QJjPypY5pE55Ks17Pgprtf9Jl k2WRJcQBWUKMPQX4im8YQ== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:lnZ45ySVeLU=:P//QfL1z130kwBB9UfRNW2 C7g61BnVndYSlxHUb7+0gMeQ/SvK+7Vh6c5lJqLChv9jN8mk2SNmhIBrbwJAUci23qhSco7mJ zoR4jQYTidt+XBic219gfYhwqEyupGNPptm6QmduD8T24opWZXjTVmdLolt+0DUkqSHVAGDFI LhYs6vbuNkiBq6rv0fhnyF7370IUSaxehdTzZ2ptOo+/VzT/1iUAROAzlzftFY0IHt55wUOYq 5ZypnrzZsrT3neQScTRfm8Y2MT+RyQ036V5U/Cag5o2QdQiZhiI57oENIFQtF5DuRrmpta6Dl Y/FhlC6ag2ZrQyk2EUsoQidbJtej7vSxpWPCQNYu65JAk0S0PjzWrN6hHua2WCWTgeyyiG+6M 4vIczSLiHC2XeIhm+3ZAR6c/wul4nlkXbFGyhlCmyUvfWoRaXvXAa5o3UamqiDf6UUfiWu9kI KscyHPxe03cJYWaYcwMmVeHwCq3IGzPqETXBT4OVvjoc4S7t+nDBHZRq4oOgA8eW2yUPGdWNY ocYDoIa8t2zPpC+BlMzDhSyG6DL2gvn6zwzzqETmB9Ocun5Z3eusO4JGqvxVBvQ12Pz/uoq6B KFCNIGw/ojqnAREsmkJ29J/pEz1EQCkil9PfbNKkoKyRRZBbNgfYazf6hHDrV5bRRTjNU6i7c 08XP0ldicQgpULgbt+QdMS2jEz6ydlZo//QdpOUistABr6i3wvVUP5hywTHi/j432jkSWWnv/ gKOS1R3gL8QdG6RV4K3FxDSi6SCN1SgymadfHpd7FBVAWWWb1DNIrrUyf5zEI8DFBVGyaOfqW lqXq5LfLdaDGLsSsUJsxX9KgRH5oSru/L83MjWY1XPSC0T7kQPPRT7VnWD+Qiu4vY2Y2Pg2Ca i+Xy1aybQD1pPMFaF8+tzNweAhrbx/VQiZ/u0WU/iQ9bJDPG+hnLt6iDV1CjQ6CRFCAk8rAAu L5dUCfdiDx81rfiW6QWIREoPHQo6x9SYMqqxsLVTWLhtR+/4/iE6OLqAtzcY1JwX4yro+K9V/ WHOO+wBI5CUVAHlrGVtSxxcwCKmdSNLA3Z6nGYys+y20WdTDTmReZc1U7LDk7ofpoEUM0m/zV U9is+igXF7LvqvO3WwjPkm2bWE3fVNyQA1mCZGjnwZy86TOrRkhpmrs+9cHd3CVhLNMIBcFUX 28qY48iQFzLpXhBMItbu/OvnZORxtvjXsIQmIuOL9F+3mWw7P66d1dFtmUuIIOm4qLcKsvlOY Xi47nwjyGy+Q5vTu0fUfs628Mpc+USOCEky909g== X-Rspamd-Queue-Id: 49yzfq5WQdz4PkV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=bnwHYpTL; dmarc=none; spf=none (mx1.freebsd.org: domain of ohartmann@walstatt.org has no SPF policy when checking 212.227.15.15) smtp.mailfrom=ohartmann@walstatt.org X-Spamd-Result: default: False [-0.16 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MIME_BASE64_TEXT_BOGUS(1.00)[]; HAS_ORG_HEADER(0.00)[]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; MIME_BASE64_TEXT(0.10)[]; NEURAL_HAM_SHORT(-0.28)[-0.275]; RECEIVED_SPAMHAUS_PBL(0.00)[77.11.197.214:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.15.15:from]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.38)[-0.379]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.21)[-0.209]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[walstatt.org]; RCPT_COUNT_ONE(0.00)[1]; R_SPF_NA(0.00)[no SPF record]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.15.15:from]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:39:49 -0000 LS0tLS1CRUdJTiBQR1AgU0lHTkVEIE1FU1NBR0UtLS0tLQ0KSGFzaDogU0hBMjU2DQoNCkFtIEZy aSwgMyBKdWwgMjAyMCAxNzoyNDozNiArMDIwMA0KIk8uIEhhcnRtYW5uIiA8b2hhcnRtYW5uQHdh bHN0YXR0Lm9yZz4gc2NocmllYjoNCg0KPiAtLS0tLUJFR0lOIFBHUCBTSUdORUQgTUVTU0FHRS0t LS0tDQo+IEhhc2g6IFNIQTI1Ng0KPiANCj4gSGVsbG8gbGlzdCwNCj4gDQo+IHJ1bm5pbmcgc29t ZSBzY3JpcHRzIGNhbHVjbGF0aW5nIHZpYSBiYygpIHRoZSBleHByZXNzaW9uIHNob3duIGJlbG93 Og0KPiANCj4gYmMgLWUgJzY1ODIwMzEgLSAxMDQ4NTc2IC0gMCAtIDQwOTYwMCAtIDEwMjQgLSA0 MCAtIDQwOTYnIC1lIHF1aXQNCj4gDQo+IHJlc3VsdHMgb24gcmVjZW50IENVUlJFTlQgKCBGcmVl QlNEIDEzLjAtQ1VSUkVOVCAjODAgcjM2Mjg4NDogVGh1IEp1bCAgMiAxMDowODoyMyBDRVNUIDIw MjANCj4gYW1kNjQpIHdpdGggYW4gZW1wdHkgcmVzdWx0LCB3aGlsZSBpdCBpcyBjYWxjdWxhdGVk IGNvcnJlY3RseSBvbiAxMi1TVEFCTEUgKEZyZWVCU0QNCj4gMTIuMS1TVEFCTEUgIzY3IHIzNjI3 MTk6IFN1biBKdW4gMjggMDk6NTk6MjAgQ0VTVCAyMDIwIGFtZDY0KSBhbmQgYSBDVVJSRU5UIGRh dGVkIGZyb20gIFN1bg0KPiBKdW4gMjh0aCAoaGF2ZSBubyByZXZpc2lvbiBudW1iZXIgYW55bW9y ZSwgdGhlIGV4cHJlc3Npb24gYWJvdmUgd2FzIGNhbGN1bGF0ZWQgY29ycmVjdGx5IG9uDQo+IHRo ZSBzYW1lIGJveCB3aGljaCBub3cgaGFzIHIzNjI4ODQgYW5kIGlzIGZhaWxpbmcpLg0KPiANCj4g V2hhdHMgd3Jvbmc/DQo+IA0KPiBLaW5kIHJlZ2FyZHMsDQo+IA0KPiBvbGl2ZXINCj4gDQo+IC0t LS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0tDQo+IA0KPiBpSFVFQVJZSUFCMFdJUVN5OElCeEFQ RGtxVkJhVEo0NE4xWlpQYmE1UndVQ1h2OU56d0FLQ1JBNE4xWlpQYmE1DQo+IFJ6dDRBUURaczlN RUQvTXp6dnk0ak5CREkzNGp2WXBENTM2dVBoZlFCdlRLcWluZENnRUFxcWxqUGxYNWJLbTcNCj4g eHRqOFZaNGgzU0w2SmRud0VaS21uR0dTS1RwNkFBOD0NCj4gPTZ6dDYNCj4gLS0tLS1FTkQgUEdQ IFNJR05BVFVSRS0tLS0tDQo+IF9fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19f X19fX19fX19fDQo+IGZyZWVic2QtY3VycmVudEBmcmVlYnNkLm9yZyBtYWlsaW5nIGxpc3QNCj4g aHR0cHM6Ly9saXN0cy5mcmVlYnNkLm9yZy9tYWlsbWFuL2xpc3RpbmZvL2ZyZWVic2QtY3VycmVu dA0KPiBUbyB1bnN1YnNjcmliZSwgc2VuZCBhbnkgbWFpbCB0byAiZnJlZWJzZC1jdXJyZW50LXVu c3Vic2NyaWJlQGZyZWVic2Qub3JnIg0KDQoNCkl0IHNlZW1zLCB0aGF0IHRoZSAiLWUgcXVpdCIg c3RhdGVtZW50IGlzIHRoZSBjdWxwcml0LiANCi0tLS0tQkVHSU4gUEdQIFNJR05BVFVSRS0tLS0t DQoNCmlIVUVBUllJQUIwV0lRU3k4SUJ4QVBEa3FWQmFUSjQ0TjFaWlBiYTVSd1VDWHY5Uk9RQUtD UkE0TjFaWlBiYTUNClI2MGtBUDk2V095OEJnUmF4d0M0Qk1leUdzbGZ1NDczMzRYa2Y3ejlnMTNN WGtJZWx3RDlFY2FDd2JjU01pb2ENCmF0V3hpcGtZZFlHVm14UEZUc2NhUHJxeWdHRWdaQUU9DQo9 c1RrOQ0KLS0tLS1FTkQgUEdQIFNJR05BVFVSRS0tLS0tDQo= From owner-freebsd-current@freebsd.org Fri Jul 3 15:47:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id EE040351A4D; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2610:1c1:1:6074::16:84]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "freefall.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49yzr75xL0z4QQL; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) (envelope-from lwhsu@freebsd.org) Received: by freefall.freebsd.org (Postfix, from userid 1129) id BC99018A3C; Fri, 3 Jul 2020 15:47:51 +0000 (UTC) Date: Fri, 3 Jul 2020 15:47:51 +0000 From: Li-Wen Hsu To: freebsd-testing@freebsd.org Cc: freebsd-current@freebsd.org, freebsd-stable@freebsd.org Subject: FreeBSD CI Weekly Report 2020-06-28 Message-ID: <20200703154751.GA89871@freefall.freebsd.org> Reply-To: freebsd-testing@freebsd.org MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:47:52 -0000 (Please send the followup to freebsd-testing@ and note Reply-To is set.) FreeBSD CI Weekly Report 2020-06-28 =================================== Here is a summary of the FreeBSD Continuous Integration results for the period from 2020-06-22 to 2020-06-28. During this period, we have: * 2388 builds (94.4% (+0.5) passed, 5.6% (-0.5) failed) of buildworld and buildkernel (GENERIC and LINT) were executed on aarch64, amd64, armv6, armv7, i386, mips, mips64, powerpc, powerpc64, powerpcspe, riscv64, sparc64 architectures for head, stable/12, stable/11 branches. * 283 test runs (89.1% (+9.3) passed, 10.2% (-2.9) unstable, 0.7% (-6.4) exception) were executed on amd64, i386, riscv64 architectures for head, stable/12, stable/11 branches. * 96.0 doc and www builds (96.0% (-4.0) passed, 4.0% (+4.0) failed) Test case status (on 2020-xx-xx 23:59): | Branch/Architecture | Total | Pass | Fail | Skipped | | ------------------- | --------- | --------- | ----- | -------- | | head/amd64 | 7857 (-6) | 7766 (+2) | 0 (0) | 91 (-8) | | head/i386 | 7855 (-6) | 7754 (-2) | 0 (0) | 101 (-4) | | 12-STABLE/amd64 | 7593 (+2) | 7535 (+3) | 0 (0) | 58 (-1) | | 12-STABLE/i386 | 7591 (+2) | 7525 (0) | 0 (0) | 66 (+2) | | 11-STABLE/amd64 | 6888 (+1) | 6837 (+3) | 0 (0) | 51 (-2) | | 11-STABLE/i386 | 6886 (+1) | 6833 (0) | 0 (0) | 53 (+1) | (The statistics from experimental jobs are omitted) If any of the issues found by CI are in your area of interest or expertise please investigate the PRs listed below. The latest web version of this report is available at https://hackmd.io/@FreeBSD-CI/report-20200628 and archive is available at https://hackmd.io/@FreeBSD-CI/ , any help is welcome. ## Fixed test cases * bin.sh.execution.functional_test.bg12 https://bugs.freebsd.org/247559 ## Failing jobs * https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc6_build/ ``` /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /tmp/obj/workspace/src/amd64.amd64/lib/clang/liblldb/liblldb.a(IOHandlerCursesGUI.o): in function `curses::Window::Box(unsigned int, unsigned int)': /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' /usr/local/bin/x86_64-unknown-freebsd12.1-ld: /workspace/src/contrib/llvm-project/lldb/source/Core/IOHandlerCursesGUI.cpp:361: undefined reference to `box' collect2: error: ld returned 1 exit status ``` ## Regressions * lib.libexecinfo.backtrace_test.backtrace_fmt_basic starts failing on amd64 after r360915 https://bugs.freebsd.org/246537 * (head, stable/12, stable/11) 2 tests start failing after llvm10 import * lib.msun.ctrig_test.test_inf_inputs https://bugs.freebsd.org/244732 * (DTrace) common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d https://bugs.freebsd.org/244823 * Lock-order reversals triggered by tests under sys.net.if_lagg_test.* on i386 https://bugs.freebsd.org/244163 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) * sys.net.if_lagg_test.lacp_linkstate_destroy_stress panics i386 kernel https://bugs.freebsd.org/244168 Discovered by newly endabled sys.net.* tests. ([r357857](https://svnweb.freebsd.org/changeset/base/357857)) Fix in review: https://reviews.freebsd.org/D25284 ## Failing and Flaky tests (from experimental jobs) * https://ci.freebsd.org/job/FreeBSD-head-amd64-dtrace_test/ * cddl.usr.sbin.dtrace.common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237641 * cddl.usr.sbin.dtrace.common.pid.t_dtrace_contrib.err_D_PROC_OFF_toobig_d * https://bugs.freebsd.org/244823 * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/ * There are ~13 failing and ~109 skipped cases, including flakey ones, see https://ci.freebsd.org/job/FreeBSD-head-amd64-test_zfs/lastCompletedBuild/testReport/ for more details * Work for cleaning these failing cass are in progress * https://ci.freebsd.org/job/FreeBSD-head-amd64-test_ltp/ * Total 3749 tests, 2277 success, 646 failures, 826 skipped ## Disabled Tests * sys.fs.tmpfs.mount_test.large https://bugs.freebsd.org/212862 * sys.fs.tmpfs.link_test.kqueue https://bugs.freebsd.org/213662 * sys.kqueue.libkqueue.kqueue_test.main https://bugs.freebsd.org/233586 * sys.kern.ptrace_test.ptrace__PT_KILL_competing_stop https://bugs.freebsd.org/220841 * lib.libc.regex.exhaust_test.regcomp_too_big (i386 only) https://bugs.freebsd.org/237450 * sys.netinet.socket_afinet.socket_afinet_bind_zero https://bugs.freebsd.org/238781 * sys.netpfil.pf.names.names * sys.netpfil.pf.synproxy.synproxy https://bugs.freebsd.org/238870 * sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger https://bugs.freebsd.org/239292 * sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger https://bugs.freebsd.org/239397 * sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger https://bugs.freebsd.org/239399 * sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger https://bugs.freebsd.org/239425 * lib.libc.gen.getmntinfo_test.getmntinfo_test https://bugs.freebsd.org/240049 * sys.sys.qmath_test.qdivq_s64q https://bugs.freebsd.org/240219 * sys.kern.ptrace_test.ptrace__getppid https://bugs.freebsd.org/240510 * lib.libc.sys.stat_test.stat_socket https://bugs.freebsd.org/240621 * lib.libarchive.functional_test.test_write_filter_zstd https://bugs.freebsd.org/240683 * lib.libcasper.services.cap_dns.dns_test.main https://bugs.freebsd.org/241435 * local.kyua.* (31 cases) & local.lutok.* (3 cases) on 11-i386 https://ci.freebsd.org/job/FreeBSD-stable-11-i386-test/2278/testReport/ * sys.kern.ptrace_test.ptrace__procdesc_reparent_wait_child https://bugs.freebsd.org/243605 * sys.kern.ptrace_test.ptrace__parent_wait_after_attach https://bugs.freebsd.org/244055 * sys.kern.ptrace_test.ptrace__parent_exits_before_child https://bugs.freebsd.org/244056 * sys.net.if_lagg_test.witness (i386) https://bugs.freebsd.org/244163 * PipePdfork.WildcardWait in sys.capsicum.capsicum-test.main https://bugs.freebsd.org/244165 * sys.net.if_lagg_test.lacp_linkstate_destroy_stress (i386) https://bugs.freebsd.org/244168 * sys.netinet6.frag6.frag6_07.frag6_07 https://bugs.freebsd.org/244170 * sys.netinet.fibs_test.udp_dontroute6 https://bugs.freebsd.org/244172 * sys.netpfil.pf.nat.exhaust https://bugs.freebsd.org/244703 * sys.geom.class.gate.ggate_test.ggated (i386) (new) https://bugs.freebsd.org/244737 * sys.kern.sysv_test.msg https://bugs.freebsd.org/233649 (new) ## Issues ### Cause build fails * https://bugs.freebsd.org/233735 Possible build race: genoffset.o /usr/src/sys/sys/types.h: error: machine/endian.h: No such file or directory * https://bugs.freebsd.org/233769 Possible build race: ld: error: unable to find library -lgcc_s ### Cause kernel panics * https://bugs.freebsd.org/238870 sys.netpfil.pf.names.names and sys.netpfil.pf.synproxy.synproxy cause panic ### Open * https://bugs.freebsd.org/237403 Tests in sys/opencrypto should be converted to Python3 * https://bugs.freebsd.org/237641 Flakey test case: common.misc.t_dtrace_contrib.tst_dynopt_d * https://bugs.freebsd.org/237656 "Freed UMA keg (rtentry) was not empty (18 items). Lost 1 pages of memory." seen when running sys/netipsec tests * https://bugs.freebsd.org/238781 sys.netinet.socket_afinet.socket_afinet_bind_zero does not work when mac_portacl(4) loaded * https://bugs.freebsd.org/239292 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_child_detached_unrelated_debugger * https://bugs.freebsd.org/239397 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_both_attached_unrelated_debugger * https://bugs.freebsd.org/239399 Flakey test case: sys.kern.ptrace_test.ptrace__parent_sees_exit_after_child_debugger * https://bugs.freebsd.org/239425 Flakey test case: sys.kern.ptrace_test.ptrace__follow_fork_parent_detached_unrelated_debugger * https://bugs.freebsd.org/241662 Flakey test case: lib.libarchive.functional_test.test_fuzz_iso9660 * https://bugs.freebsd.org/246443 sys.net.if_clone_test.epair_stress sometimes exceeds timeout limit but not caught by kyua * https://bugs.freebsd.org/247510 (new) sys.net.if_lagg_test.status_stress panics kernel on i386 ### Others * [Tickets related to testing@](https://preview.tinyurl.com/y9maauwg) From owner-freebsd-current@freebsd.org Fri Jul 3 15:58:34 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 129D335242A for ; Fri, 3 Jul 2020 15:58:34 +0000 (UTC) (envelope-from se@freebsd.org) Received: from smtp.freebsd.org (smtp.freebsd.org [96.47.72.83]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "smtp.freebsd.org", Issuer "Let's Encrypt Authority X3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49z04T6lD2z4RJj; Fri, 3 Jul 2020 15:58:33 +0000 (UTC) (envelope-from se@freebsd.org) Received: from Stefans-MacBook-Pro-449.fritz.box (p200300cd5f2033002024905b0514c3cf.dip0.t-ipconnect.de [IPv6:2003:cd:5f20:3300:2024:905b:514:c3cf]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) (Authenticated sender: se/mail) by smtp.freebsd.org (Postfix) with ESMTPSA id 3752E22F1C; Fri, 3 Jul 2020 15:58:33 +0000 (UTC) (envelope-from se@freebsd.org) Subject: Re: CURRENT: bc -e results in empty string/result To: "O. Hartmann" , FreeBSD CURRENT References: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> From: =?UTF-8?Q?Stefan_E=c3=9fer?= Autocrypt: addr=se@freebsd.org; keydata= mQENBFVxiRIBCADOLNOZBsqlplHUQ3tG782FNtVT33rQli9EjNt2fhFERHIo4NxHlWBpHLnU b0s4L/eItx7au0i7Gegv01A9LUMwOnAc9EFAm4EW3Wmoa6MYrcP7xDClohg/Y69f7SNpEs3x YATBy+L6NzWZbJjZXD4vqPgZSDuMcLU7BEdJf0f+6h1BJPnGuwHpsSdnnMrZeIM8xQ8PPUVQ L0GZkVojHgNUngJH6e21qDrud0BkdiBcij0M3TCP4GQrJ/YMdurfc8mhueLpwGR2U1W8TYB7 4UY+NLw0McThOCLCxXflIeF/Y7jSB0zxzvb/H3LWkodUTkV57yX9IbUAGA5RKRg9zsUtABEB AAG0J1N0ZWZhbiBFw59lciAoRnJlZUJTRCkgPHNlQGZyZWVic2Qub3JnPokBVAQTAQoAPgIb AwULCQgHAwUVCgkICwUWAwIBAAIeAQIXgBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+q BQkLJQETAAoJEEfrte9a/fVEOeMH/icmdK1eZQvB3U8quJo9VMaZsaTuCMbUE4NThyfsIvIm MCd+rb/yULmMYwqNfjyKB1x4ikR4x+94l+yJoz7K0Usks+eNKDmMGJM6pWWssTigaJubFdVd hVVC+C1QJi7JshYSib08uONoPmO4lv5Az0TDYGtsMzsES2sIlc62c9go5WPGYhQFRbX3Lk6y V6m8OHh+G9XGSj3oPO4UteRwu+SzTdOLunZBWG1wu34+IeZm663D+2gOppQLWpLa2qaTerqw THu377ayZ2B2LPJ5JkvkZeHYPkwDQ+b5PGn0UhfkxPnDVYki5F7qKxvQ5uq1/q9YaCX7mmOl H2yO7tgVsrW5AQ0EVXGJEgEIALEj9qCXMZVucjpcd3QxM/TlUr98m5viEd1z4tCnPUyRWcIC EVtj2h5xMH+2iB0q1+KWhq+NsWtvScmEmfHnsr7dJ1K677OdpDhKVaJk61eeRulFY1R4yb6C 1MMxK+WgYB+vvpG0UeyR0M4uBewcPvRsq4yGUHFQKtLAbMdoPTSryJA+ElnmK1vdY+rPcHgi OIMBZM7ahsPXC0C9K4e5SP9clGyIoMpbfHXdx9q+Rp3zVtlbhyk3BS/xccu/+9pk9ICXL6GR js2sNnJ0wxdU1DsAlC59a5MnSruwiZFwRnkQhr3x6wk97Lg7sLS9jjTnCN7LGlVmSmpOEMy6 uq1AWfUAEQEAAYkBPAQYAQoAJgIbDBYhBKNx6mWcC+zIK3FTE0frte9a/fVEBQJa8u+rBQkL JQEZAAoJEEfrte9a/fVEuesH/2DNxGWnHvWwMyiyhlQtafvDKwEn/wAgR8gHJFodB7emf8rA TnukH7MVttCoHtjN5lvv9RSBHjNTZls5wR/ANlwdRuPQHd8ZGxLe3S6IuUB3zDSwFltLGurO N2kOMhs5mTGyypSa+uw3rtQbUAVYf1oPbiR4FLtiM8FLyEvE95hX5fPq9Qvx9FmN79kmCIEw jDKPqDaUf/OR2fEF0LSIbXHEk4tNqCEwx5DIJ0fp5/z5UzICUAmwxyRs5O/Hre1jzPsMVyud Ml9t7UTOJGKVWwRory1PMnOFxN+iz5/d4FhYSKXF7kfMiFgol4LuWaxJRwbBrr71VGBrRy2a L1nw6Bc= Message-ID: <82c80079-2e33-dfea-4553-37806c6fbe60@freebsd.org> Date: Fri, 3 Jul 2020 17:58:27 +0200 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 MIME-Version: 1.0 In-Reply-To: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> Content-Type: text/plain; charset=windows-1252 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 15:58:34 -0000 Am 03.07.20 um 17:24 schrieb O. Hartmann: > Hello list, > > running some scripts caluclating via bc() the expression shown below: > > bc -e '6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096' -e quit The bc in -CURRENT has been replaced by a new implementation. It seems there is one deviation from the behavior of the "old" version, in that it executes the "quit" immediately after parsing it. There is a difference between "quit" and "halt", and the following command works as expected: $ bc -e '6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096' -e halt 5118695 >From the bc man-page: The quit statement causes bc(1) to quit, even if it is on a branch that will not be executed (it is a compile-time command). The halt statement causes bc(1) to quit, if it is executed. (Unlike quit if it is on a branch of an if statement that is not executed, bc(1) does not quit.) This behavior is identical to that of GNU bc: $ echo "6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096; quit " | gbc $ echo "6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096; halt " | gbc 5118695 > results on recent CURRENT ( FreeBSD 13.0-CURRENT #80 r362884: Thu Jul 2 10:08:23 CEST 2020 > amd64) with an empty result, while it is calculated correctly on 12-STABLE (FreeBSD > 12.1-STABLE #67 r362719: Sun Jun 28 09:59:20 CEST 2020 amd64) and a CURRENT dated from Sun > Jun 28th (have no revision number anymore, the expression above was calculated correctly on > the same box which now has r362884 and is failing). > > Whats wrong? The behavior of the "old" bc in FreeBSD was non-conformant in several details, the result of a modulo operation with negative operands was the most critical, in my opinion. This is what POSIX says with regard to the "quit" command: The quit statement ( quit) shall stop execution of a bc program at the point where the statement occurs in the input, even if it occurs in a function definition, or in an if, for, or while statement. But I'm not sure whether this covers the behavior of GNU bc and this new bc, since it does not say, that "quit" will be executed as soon as seen by the parser. Regards, STefan From owner-freebsd-current@freebsd.org Fri Jul 3 16:13:17 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 25FB7352A60 for ; Fri, 3 Jul 2020 16:13:17 +0000 (UTC) (envelope-from core-secretary@freebsd.org) Received: from mailman.nyi.freebsd.org (mailman.nyi.freebsd.org [IPv6:2610:1c1:1:606c::50:13]) by mx1.freebsd.org (Postfix) with ESMTP id 49z0PT0DxLz4S9Y for ; Fri, 3 Jul 2020 16:13:17 +0000 (UTC) (envelope-from core-secretary@freebsd.org) Received: by mailman.nyi.freebsd.org (Postfix) id 081C93529CC; Fri, 3 Jul 2020 16:13:17 +0000 (UTC) Delivered-To: current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 07E47352D0C for ; Fri, 3 Jul 2020 16:13:17 +0000 (UTC) (envelope-from core-secretary@freebsd.org) Received: from mail-ej1-f49.google.com (mail-ej1-f49.google.com [209.85.218.49]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49z0PS4xTNz4SRV for ; Fri, 3 Jul 2020 16:13:16 +0000 (UTC) (envelope-from core-secretary@freebsd.org) Received: by mail-ej1-f49.google.com with SMTP id a1so34808185ejg.12 for ; Fri, 03 Jul 2020 09:13:16 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:reply-to:mime-version:subject:message-id :date:to; bh=+4eVNwGTIZ5QGKH9zT4lfqMv8Fb8yujgFdASGbJWvME=; b=Otb3lpSoodpGiDN1KTiutwXT3bwZlpJpsHvaI8VO8CHemgKPQAXOSm+xRrTXnimdoC duc9mOBTPdT0QbwYLbBk8FwD/7lGwsp80r35u5DoqxG/ve0sR4LaHYsfXcXxbbZRyVOj mqPnqaLhORrT7DenuHOt38+eVZtt2/rR4FiZfukt1sR+zYTKmvwxQLUdBImC7/lb+aAC FXUtJm0BqUmNfmMvBwzQMJMkEzjB3/cK2pnQN53Ht5QsxH1hErAKYATE8Ae3cpK+KxHk Aor5AKE/8r+sQrXhi8OkmfhZcRhaR5I9nuWS7yObOJXAEDAhq27QzkqcYPpk6Prx1SVC wvFw== X-Gm-Message-State: AOAM530oWwQeGf1bECWszFiFlezsrKhWxBP7wHP4+SFiPejHo+boKNqa XgpNrv80pWSgMsDVWCw4t//Gx7DeoOvcUovkg4T5uneYflq+F7GMXB71LhFYgY9Xs+H8fqHktIU hNKL4xSKDLqAZ6gwNZmM625d1N15gKyzIK3tOL+nkCvhp1+ZU+ELsY5eMA4SSfuK251QTZAmkFc /xzQ== X-Google-Smtp-Source: ABdhPJzo+9OA0BT+y1uZf+NIZYo/SbsdUvpL2PV5AmNCDfcz/NYeU0htQEGocBdaaKeSCTOCKhwX2A== X-Received: by 2002:a17:906:c453:: with SMTP id ck19mr6992856ejb.185.1593792794989; Fri, 03 Jul 2020 09:13:14 -0700 (PDT) Received: from mx.bofh.network (mx.bofh.network. [2001:19f0:5001:2b77:5400:2ff:fe7b:aa2c]) by smtp.gmail.com with ESMTPSA id di20sm13230245edb.26.2020.07.03.09.13.14 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 03 Jul 2020 09:13:14 -0700 (PDT) Received: from [192.168.30.38] ( [118.179.171.14]) by mx.bofh.network (OpenSMTPD) with ESMTPSA id a1484647 (TLSv1.2:ECDHE-RSA-AES256-GCM-SHA384:256:NO) for ; Fri, 3 Jul 2020 16:13:13 +0000 (UTC) From: FreeBSD Core Team Secretary Content-Type: multipart/signed; boundary="Apple-Mail=_960CD292-40E5-43BE-985D-8D4BA10AC759"; protocol="application/pgp-signature"; micalg=pgp-sha512 Reply-To: FreeBSD Core Team Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Core Team Office Hours Message-Id: <58CACAC0-82E9-4D49-928F-3C55DF54E684@freebsd.org> Date: Fri, 3 Jul 2020 22:13:04 +0600 To: current@freebsd.org X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49z0PS4xTNz4SRV X-Spamd-Bar: / Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [0.00 / 15.00]; ASN(0.00)[asn:15169, ipnet:209.85.128.0/17, country:US]; local_wl_from(0.00)[freebsd.org] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Jul 2020 16:13:17 -0000 --Apple-Mail=_960CD292-40E5-43BE-985D-8D4BA10AC759 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 FreeBSD recently held an election for its governing body called the = =E2=80=98Core Team=E2=80=99. The newly elected Core Team would like to = invite you to a virtual town hall meeting. We=E2=80=99ll be holding two = sessions, one timed well for Europe and the Americas; the other timed = well for Asia, Africa and India. Sessions will be held at 1800 UTC on = July 7, 2020 and 0200 UTC on July 8, 2020. See = https://wiki.freebsd.org/OfficeHours for details on how to join either a = live stream to watch, or an interactive meeting to participate. A link = to this agenda (and any updates) will be there as well. We=E2=80=99ll be discussing the following topics and taking general = questions at the end. We=E2=80=99ll have a moderator who will help call = on people in the meeting to ask questions (or to offer comments) as well = as relay relevant questions from IRC. =E2=80=A2 Introduce core members -- All the core team members in = attendance will briefly introduce themselves and say a few words about = their goals for this core term. =E2=80=A2 Discuss proposed terminology changes -- Recently, the = prior core team had sent out a proposal about how to handle shifts in = language based on societal change. The initial message was poorly = written and didn=E2=80=99t strike the right tone. We=E2=80=99ll discuss = it, the underlying issue and how the new core team plans on doing things = better. =E2=80=A2 Recruiting for project teams -- When a new core team = takes over, it=E2=80=99s a good time to assess the needs of each of the = teams that we have running different aspects of the project, such as = administering our machines and helping keep FreeBSD secure. One common = theme is the need for more help. We=E2=80=99ll discuss what teams there = are, and make a recruiting pitch and answer any questions. =E2=80=A2 Core TODO List publishing -- To continue the openness = initiative, the core team will start publishing out TODO list. This will = be in addition to the normal meeting minutes and other openness ideas. = The new core team would love to hear from the community how to improve = our communications. =E2=80=A2 Git Transition -- To raise awareness, Ed Maste and = Warner Losh will be giving a brief presentation about the state of the = project=E2=80=99s planned transition to git. They can answer a few = questions here, but are also planning an entire office hours on the git = transition (tentatively scheduled in two weeks). =E2=80=A2 General Questions -- Time permitting, the new core = team can answer any other questions or concerns the community might = have. Thanks! We look forward to meeting you. The New Core Team: Sean Chittenden Baptiste Daroussin Kyle Evans Mark Johnston Scott Long Warner Losh Ed Maste George V. Neville-Neil Hiroki Sato --Apple-Mail=_960CD292-40E5-43BE-985D-8D4BA10AC759 Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename=signature.asc Content-Type: application/pgp-signature; name=signature.asc Content-Description: Message signed with OpenPGP -----BEGIN PGP SIGNATURE----- iQKTBAEBCgB9FiEES2Tp4L3ps+zAa1xm2MjIO0nybxcFAl7/WRBfFIAAAAAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDRC NjRFOUUwQkRFOUIzRUNDMDZCNUM2NkQ4QzhDODNCNDlGMjZGMTcACgkQ2MjIO0ny bxfkVBAAn8++MI1u4OvPSser2/ffH3GDOTE5aKYgrJH0XBhycjMkxedxfbWtNKU2 TWrXjSYnL0w4Wl+yH0jB6YXwaP62glZYCnhqmdBe6n0EnuT+pMvXHACxA5Z20yb5 E6to5Y7lDGyEiuaXYhH35HPGepOYlbMIlj1zsRFlh04w1DGCNekjaTPRNru57iPV bFpa1eGqCaefSazWlD7pPfOJf447bRJ3EduqhhnY05nI7GlD8VK6NdvfPdxtj1iN gRn+vjp6u0Nbo6/qYPB6QHQpfyoycWi54iObkW7HbLAKklQP5Ry29hKI51t8tC6N c37CGr2xHpze/U1neDwx1h9QSyG0YO6+fnByPEXzFaIb5GxXSqOuTheahrfLbS4R h89HHl0fWlbEFKEgBroxY01YS/MurgVaveZ8Jkl0LsPRAm3oIuolQ2AzpTZVEu+e SVVR4ImAssc2o3+WucpQM9z6CGfDRpddlbGOwCK2hzno6fRGU4ojS0/PBbGJWT1+ A/bU3u73oZTX+C2vOWOL9N/77XDHO+FSxkJEdWjl8N16tcfQJ6RwtmTTf0SFW72u jOcn7OtvNZaJJ5urVUqTSUXQujziUMGKJpuXAZ92i4f47MXltlecgULxF4+4NM4j uy5e32PgWfqP8VwE79ymMkYaUnGWSGSIr9sxUD5xM1R84W7hmwI= =fNo+ -----END PGP SIGNATURE----- --Apple-Mail=_960CD292-40E5-43BE-985D-8D4BA10AC759-- From owner-freebsd-current@freebsd.org Sat Jul 4 09:50:44 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id B265C367562 for ; Sat, 4 Jul 2020 09:50:44 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-256) server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "mout.gmx.net", Issuer "TeleSec ServerPass Class 2 CA" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zRsb4Gq0z4RRF; Sat, 4 Jul 2020 09:50:43 +0000 (UTC) (envelope-from o.hartmann@walstatt.org) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.net; s=badeba3b8450; t=1593856240; bh=T+tSGgIyDAG6zfNnXYwHuQyxAkI/0FFZK/43AmtUlXk=; h=X-UI-Sender-Class:Date:From:To:Cc:Subject:In-Reply-To:References; b=knMOO7m5LZXVAK8pPFxK5lmGIbCj+es2F1MGTZ9VwPhQjcxNEBykKi1EGWCWW+Qlu 4n80Xv8u51/jJx0RE8B3P7aR6T2NxRrWEP3pCh1fq/KOs7rWcEMf8WTZW2ZLbd84sE SL59EM5uUKkZnX6Jb+CpGZdI+byK39GciyUc4E3A= X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from hermann.fritz.box ([77.191.123.155]) by mail.gmx.com (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1M8ykg-1jxhDy1VVW-0069ax; Sat, 04 Jul 2020 11:50:40 +0200 Date: Sat, 4 Jul 2020 11:50:31 +0200 From: "Hartmann, O." To: Stefan =?ISO-8859-1?Q?E=DFer?= Cc: FreeBSD CURRENT Subject: Re: CURRENT: bc -e results in empty string/result Message-ID: <20200704115031.5f9ee55c@hermann.fritz.box> In-Reply-To: <82c80079-2e33-dfea-4553-37806c6fbe60@freebsd.org> References: <20200703172503.5b739102@thor.intern.walstatt.dynvpn.de> <82c80079-2e33-dfea-4553-37806c6fbe60@freebsd.org> Organization: walstatt.org MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/av3=YoL9+Cp2o74+XQe3Sjx"; protocol="application/pgp-signature" X-Provags-ID: V03:K1:XSiZZCSvKaQAO+ulSzVrpYY96zcwiBrZZafg91HaoxvUGmSebdL t/nOTC/IaD9xoNLBzEtN498bTmKBTfQ7nDfGmjgNJwpYxBaNwyg+opyNmDzjQ9isiMwhiFf CFCRqfB/1q3jJoLRPfT0SDkN/WW8HnqZRY0itrHyKOfbCoUB5++pVI4KcHm9QiULfQu0Ozh mzps6xhg1Wumtz4kCPl6w== X-Spam-Flag: NO X-UI-Out-Filterresults: notjunk:1;V03:K0:AEoInhEl6l4=:A09DuYTZauoYqf6Q5n9l54 xkeZqK9mEZZYo9vE0kBHBm4DhR2+R4L+X71G7pN/7QSiKz6VCDiWDG1n8gjXoZkhKRc/uRhwk 38q6flzAdweunB8nBLDqT6JerjpooknC+CV5Rf7Bvf0KIrpdaJWFeGat76fj0cAa7eIZs+w8M RHiSemA2fMA5JlXjmfBAZ/k+iLuICjiOA1pzPY5gVlg/U4e3zDoSS75kG/DyQmvYNcoQ8VFOP zKfmABEJqnAGHicVq/xM/ioKvELS9PhQnGUnl0rcfApMJ7p+NX76ZIJr6R22eyTRayy9xaWrF Mjtpope3EV8tQB9VZVY4Bk/mLAF2tiDXHYz64H+RpPs3GSSFruqfFEvLze2kQCW5KcNIiNIvA RbAKEWtsgJfn09NwbYHNU20llFleCducon0KUB04xlxCoYdxiJXVzIbeLc3rXUcu4KKocPsP5 ge6IT8IMMij8KxJLgB7vGc/M2naRotCjHMnQezFmufQgzQCwNgpi7eEqhTcfwG/KViyhL6pUu ovGGeSKZ45HjxEiGYMpltlV/DrB6V984PEsUrXNdiRy567qrYGmFfnaVgebZ0qDWyhEQfgMs8 1Qg8FbckoM7YrPTT0GEhxhhW4C10x/b2t92auYFLCkhuURBQig8ilPifCfBWLltlSaX1E36d8 P64GRPTquTPu67+0zNuWdmf+gUxmxl2gg/2h2jw1K2iynSFKckOW59slN+Q+dBJ+9LWqtGIJ5 W0JiX+l+++JgJHiZoRHNe79cG2WVMqJcQlN/LX/o1t3iTUpHYIX3RV4zpuD3bwsqHHstfOLbD QGmSHXCA8zmsltkBcfTnT9mD+PJIbmFuhOHfwn7stfNLD9Nh6AW0qAXyHUV0O1MP0H2yagYxD R310QpicRLoLUeRVB81Qf8+pyrGFj3t5ZXRfkSN7HoW0ACkdnfOFl0GMBClnBPOwbm30lWgaL +L5Z7XQjBoOwJ5RoFJZogrc1QgPYMYFe5ZHg5Y8kFzYr4n3NWJ6P2jNDKCi+SFHuAHzEXbjj4 AsgF2cFarL41qwblybcn24QikQ8kej6olYZdu6o6iel69ttQz2p1EyCjFFGCd7lRzP+cRzkBP avgz8qmndhX6kxxTI+f/OpqKz78QXjpRnbQdxlb3ZqPC3C4kLTrGqlpAmmghNufT9XO7a5tYE qJY9hbJeXGtLNyqG4cLr8KpOaCeWa7YZWFrLDNNRXaE5Ugo1ihTSVfuk0n1KP9S9PphLvhKDb R8beK2g5vdoaSHp7t X-Rspamd-Queue-Id: 49zRsb4Gq0z4RRF X-Spamd-Bar: - Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmx.net header.s=badeba3b8450 header.b=knMOO7m5; dmarc=none; spf=none (mx1.freebsd.org: domain of o.hartmann@walstatt.org has no SPF policy when checking 212.227.17.20) smtp.mailfrom=o.hartmann@walstatt.org X-Spamd-Result: default: False [-1.82 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[gmx.net:s=badeba3b8450]; RWL_MAILSPIKE_POSSIBLE(0.00)[212.227.17.20:from]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.37)[-0.372]; MIME_GOOD(-0.20)[multipart/signed,text/plain]; DMARC_NA(0.00)[walstatt.org]; NEURAL_HAM_MEDIUM(-0.83)[-0.825]; HAS_ORG_HEADER(0.00)[]; RECEIVED_SPAMHAUS_PBL(0.00)[77.191.123.155:received]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmx.net:+]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_HAM_SHORT(-0.13)[-0.128]; R_SPF_NA(0.00)[no SPF record]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:8560, ipnet:212.227.0.0/16, country:DE]; RCVD_COUNT_TWO(0.00)[2]; RCVD_TLS_ALL(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[212.227.17.20:from] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 09:50:44 -0000 --Sig_/av3=YoL9+Cp2o74+XQe3Sjx Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Fri, 3 Jul 2020 17:58:27 +0200 Stefan E=C3=9Fer wrote: > Am 03.07.20 um 17:24 schrieb O. Hartmann: > > Hello list, > >=20 > > running some scripts caluclating via bc() the expression shown > > below: > >=20 > > bc -e '6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096' -e quit =20 >=20 > The bc in -CURRENT has been replaced by a new implementation. >=20 > It seems there is one deviation from the behavior of the "old" > version, in that it executes the "quit" immediately after parsing it. >=20 > There is a difference between "quit" and "halt", and the following > command works as expected: >=20 > $ bc -e '6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096' -e halt > 5118695 >=20 > From the bc man-page: >=20 > The quit statement causes bc(1) to quit, even if it is on a branch > that will not be executed (it is a compile-time command). >=20 > The halt statement causes bc(1) to quit, if it is executed. (Unlike > quit if it is on a branch of an if statement that is not executed, > bc(1) does not quit.) >=20 > This behavior is identical to that of GNU bc: >=20 > $ echo "6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096; quit " | > gbc $ echo "6582031 - 1048576 - 0 - 409600 - 1024 - 40 - 4096; halt " > | gbc 5118695 >=20 > > results on recent CURRENT ( FreeBSD 13.0-CURRENT #80 r362884: Thu > > Jul 2 10:08:23 CEST 2020 amd64) with an empty result, while it is > > calculated correctly on 12-STABLE (FreeBSD 12.1-STABLE #67 r362719: > > Sun Jun 28 09:59:20 CEST 2020 amd64) and a CURRENT dated from Sun > > Jun 28th (have no revision number anymore, the expression above was > > calculated correctly on the same box which now has r362884 and is > > failing). > >=20 > > Whats wrong? =20 >=20 > The behavior of the "old" bc in FreeBSD was non-conformant in several > details, the result of a modulo operation with negative operands was > the most critical, in my opinion. >=20 > This is what POSIX says with regard to the "quit" command: >=20 > The quit statement ( quit) shall stop execution of a bc program at > the point where the statement occurs in the input, even if it occurs > in a function definition, or in an if, for, or while statement. >=20 > But I'm not sure whether this covers the behavior of GNU bc and this > new bc, since it does not say, that "quit" will be executed as soon > as seen by the parser. >=20 > Regards, STefan Hello. Unfortunately, there was no remark in UPDATING and in the hurry I did not find any traces of the change, so it hit me since several scripts failed. As a workaround, it helped to replace "-e quit" by "-e halt", although this might semantically also an unfortunate way to do. Thanks very much for the fast response, regards Oliver --Sig_/av3=YoL9+Cp2o74+XQe3Sjx Content-Type: application/pgp-signature Content-Description: OpenPGP digital signature -----BEGIN PGP SIGNATURE----- iHUEARYIAB0WIQSy8IBxAPDkqVBaTJ44N1ZZPba5RwUCXwBQ6AAKCRA4N1ZZPba5 R1F/AQDL7Abkp+QOwsWM1DMnKhKWjyXFIGkgEahNyb3wW3gh9AEAvciCbkTRIQP6 DbKczphSp50pqt3NaXgS2DjLbqdL/gE= =d0Vi -----END PGP SIGNATURE----- --Sig_/av3=YoL9+Cp2o74+XQe3Sjx-- From owner-freebsd-current@freebsd.org Sat Jul 4 13:12:55 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 0E50734D67F for ; Sat, 4 Jul 2020 13:12:55 +0000 (UTC) (envelope-from jesper@schmitz.computer) Received: from mail.northatlanticmusicsupplies.com (mail.northatlanticmusicsupplies.com [212.237.182.202]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zXLs3Mltz3RYt for ; Sat, 4 Jul 2020 13:12:52 +0000 (UTC) (envelope-from jesper@schmitz.computer) Received: by mail.northatlanticmusicsupplies.com (Postfix, from userid 58) id 4A6059A68A2; Sat, 4 Jul 2020 13:12:44 +0000 (UTC) X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on mailjail X-Spam-Level: X-Spam-Status: No, score=-1.2 required=5.0 tests=ALL_TRUSTED,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,HTML_MESSAGE autolearn=ham autolearn_force=no version=3.4.4 Received: from freebsd2.freebsd.lan (unknown [192.168.1.5]) by mail.northatlanticmusicsupplies.com (Postfix) with ESMTPSA id C00A39A680B for ; Sat, 4 Jul 2020 13:12:42 +0000 (UTC) Subject: =?UTF-8?B?UmU6INCSINC+0YLQstC10YIg0L3QsDogUmU6IGVkaXRvcnMvbGlicmVv?= =?UTF-8?Q?ffice_PDF_export/printing_broken?= To: freebsd-current@freebsd.org References: <1240905853.3700064.1592845431061.ref@mail.yahoo.com> <1240905853.3700064.1592845431061@mail.yahoo.com> <2008475768.3775242.1592850379401@mail.yahoo.com> From: Jesper Schmitz Mouridsen Message-ID: <77b13788-cf29-807c-59e5-2913a9cd2675@schmitz.computer> Date: Sat, 4 Jul 2020 15:12:39 +0200 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:68.0) Gecko/20100101 Thunderbird/68.9.0 MIME-Version: 1.0 In-Reply-To: <2008475768.3775242.1592850379401@mail.yahoo.com> Content-Language: en-US X-Rspamd-Queue-Id: 49zXLs3Mltz3RYt X-Spamd-Bar: --- X-Spamd-Result: default: False [-3.28 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; ARC_NA(0.00)[]; R_DKIM_ALLOW(-0.20)[schmitz.computer:s=202002]; NEURAL_HAM_MEDIUM(-1.00)[-1.002]; FROM_HAS_DN(0.00)[]; TO_MATCH_ENVRCPT_ALL(0.00)[]; R_SPF_ALLOW(-0.20)[+mx]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; TO_DN_NONE(0.00)[]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-0.99)[-0.989]; RCVD_COUNT_THREE(0.00)[3]; DKIM_TRACE(0.00)[schmitz.computer:+]; DMARC_POLICY_ALLOW(-0.50)[schmitz.computer,reject]; NEURAL_HAM_SHORT(-0.29)[-0.286]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; ASN(0.00)[asn:204151, ipnet:212.237.176.0/21, country:DK]; RCVD_TLS_ALL(0.00)[]; MID_RHS_MATCH_FROM(0.00)[] Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 13:12:55 -0000 Accidentally found on twitter Colin Percival @cperciva In case anyone else (including future-me) runs into the same problem: If LibreOffice"export to PDF" produces pages without any text, set "SAL_VCL_QT5_USE_CAIRO=true" in the environment. No, I have no idea why. Ran into this on FreeBSD; found the fix on the Lubuntu forum. On 22.06.2020 20.26, Kostya Berger wrote: > No need to pkg upgrade. They are all freshly installed from official repo. Clean install, new fresh user. > The same in my second install, Synth built local repo. Same thing. > And I'm talking about the PDF button in LO interface. Or File> Export to PDF. > > > Отправлено из Yahoo Почты для Android > > пн, 22 июн. 2020 в 20:22 Gleb Popov<6yearold@gmail.com> написал(-а): On Mon, Jun 22, 2020 at 9:04 PM Kostya Berger wrote: > >> r362292In editors/libreoffice 6.4.4 PDF export is broken, including also >> PDF print to file. Tried with locally built 6.4.4 and pre-built package >> 6.4.4.2 from official repo (separate installation for testing purposes). >> Symptoms: of all content only graphics/tables elements get exported to >> PDF. No text. PS printing is all right.As regards PDF printing to file in >> general, it still works fine in Firefox. Only LO is affected. I filed a bug >> report as well. >> >> With kindest regards, >> Kostya Berger >> > Hum, can't reproduce this on my side. Can you do `pkg upgrade`, maybe some > dependency is out of date? > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" > > _______________________________________________ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org" From owner-freebsd-current@freebsd.org Sat Jul 4 13:22:19 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 3A10034DEB2 for ; Sat, 4 Jul 2020 13:22:19 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from home.opsec.eu (home.opsec.eu [IPv6:2001:14f8:200::1]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zXYk4hD3z3Ry9 for ; Sat, 4 Jul 2020 13:22:18 +0000 (UTC) (envelope-from pi@opsec.eu) Received: from pi by home.opsec.eu with local (Exim 4.92.3 (FreeBSD)) (envelope-from ) id 1jri7L-000FG9-1x; Sat, 04 Jul 2020 15:22:07 +0200 Date: Sat, 4 Jul 2020 15:22:07 +0200 From: Kurt Jaeger To: Jesper Schmitz Mouridsen Cc: freebsd-current@freebsd.org Subject: Re: editors/libreoffice PDF export/printing broken Message-ID: <20200704132207.GF39563@home.opsec.eu> References: <1240905853.3700064.1592845431061.ref@mail.yahoo.com> <1240905853.3700064.1592845431061@mail.yahoo.com> <2008475768.3775242.1592850379401@mail.yahoo.com> <77b13788-cf29-807c-59e5-2913a9cd2675@schmitz.computer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <77b13788-cf29-807c-59e5-2913a9cd2675@schmitz.computer> X-Rspamd-Queue-Id: 49zXYk4hD3z3Ry9 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=pass (mx1.freebsd.org: domain of pi@opsec.eu designates 2001:14f8:200::1 as permitted sender) smtp.mailfrom=pi@opsec.eu X-Spamd-Result: default: False [-2.90 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+mx:c]; NEURAL_HAM_LONG(-1.00)[-1.001]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[opsec.eu]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_HAM_SHORT(-0.61)[-0.613]; RCPT_COUNT_TWO(0.00)[2]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:12502, ipnet:2001:14f8::/32, country:DE]; RCVD_COUNT_TWO(0.00)[2] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 13:22:19 -0000 Hi! There is https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247444 which discusses this in more detail. -- pi@opsec.eu +49 171 3101372 Now what ? From owner-freebsd-current@freebsd.org Sat Jul 4 13:24:11 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 62CE334DEFB for ; Sat, 4 Jul 2020 13:24:11 +0000 (UTC) (envelope-from greg@unrelenting.technology) Received: from out0.migadu.com (out0.migadu.com [IPv6:2001:41d0:2:267::]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 49zXbt0xPhz3S7r for ; Sat, 4 Jul 2020 13:24:09 +0000 (UTC) (envelope-from greg@unrelenting.technology) Date: Sat, 04 Jul 2020 13:23:56 +0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=unrelenting.technology; s=default; t=1593869041; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=dMcGGAodGBy69SRtR0c3MGq+HPPW7fPuk9CljZOpXgk=; b=goHiKXVt0o4IJzIZ2b2pJQgKaZRrnVrAeLwpvFQm/VVJ2PdGfVpUOZ0gbkOz1mqyEAXvWh NoGq1bqqsPAgc+4DEYGq4E8HlPGgrBM6WjRswM5bqEGtG3hEAm4x5eKP2R778DdGfQX4TB ILZ6H9ZB3JnTHqO6PafECDm1LB1/hCk= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. From: myfreeweb To: freebsd-current@freebsd.org, Jesper Schmitz Mouridsen Subject: =?UTF-8?Q?Re=3A_=D0=92_=D0=BE=D1=82=D0=B2=D0=B5=D1=82_=D0=BD=D0=B0=3A_?= =?UTF-8?Q?Re=3A_editors/libre?= =?UTF-8?Q?office_PDF_export/printing_broken?= In-Reply-To: <77b13788-cf29-807c-59e5-2913a9cd2675@schmitz.computer> References: <1240905853.3700064.1592845431061.ref@mail.yahoo.com> <1240905853.3700064.1592845431061@mail.yahoo.com> <2008475768.3775242.1592850379401@mail.yahoo.com> <77b13788-cf29-807c-59e5-2913a9cd2675@schmitz.computer> Message-ID: <586839DF-D3CC-4EA6-88ED-16E19CBB3590@unrelenting.technology> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.10 X-Rspamd-Queue-Id: 49zXbt0xPhz3S7r X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=unrelenting.technology header.s=default header.b=goHiKXVt; dmarc=pass (policy=none) header.from=unrelenting.technology; spf=pass (mx1.freebsd.org: domain of greg@unrelenting.technology designates 2001:41d0:2:267:: as permitted sender) smtp.mailfrom=greg@unrelenting.technology X-Spamd-Result: default: False [-4.18 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-0.996]; R_DKIM_ALLOW(-0.20)[unrelenting.technology:s=default]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip6:2001:41d0:2:267::]; NEURAL_HAM_LONG(-1.00)[-1.005]; MIME_GOOD(-0.10)[text/plain]; TO_MATCH_ENVRCPT_SOME(0.00)[]; DKIM_TRACE(0.00)[unrelenting.technology:+]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[unrelenting.technology,none]; NEURAL_HAM_SHORT(-1.18)[-1.182]; RCVD_COUNT_ZERO(0.00)[0]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16276, ipnet:2001:41d0::/32, country:FR]; MID_RHS_MATCH_FROM(0.00)[] X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 13:24:11 -0000 On July 4, 2020 1:12:39 PM UTC, Jesper Schmitz Mouridsen wrote: >Accidentally found on twitter > >Colin Percival >@cperciva > > >In case anyone else (including future-me) runs into the same problem: If= =20 >LibreOffice"export to PDF" produces pages without any text, set=20 >"SAL_VCL_QT5_USE_CAIRO=3Dtrue" in the environment=2E No, I have no idea w= hy=2E=20 >Ran into this on FreeBSD; found the fix on the Lubuntu forum=2E Maybe switching the default UI backend to qt5 was a mistake ;) gtk3 isn't really "broken", it has a relatively minor visual bug that only= happens on FreeBSD=2E Maybe if it was the default, someone would be motiva= ted enough to fix it=2E From owner-freebsd-current@freebsd.org Sat Jul 4 15:59:41 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 37692351E19 for ; Sat, 4 Jul 2020 15:59:41 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pf1-x435.google.com (mail-pf1-x435.google.com [IPv6:2607:f8b0:4864:20::435]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zc3J2t5Tz3bQX; Sat, 4 Jul 2020 15:59:40 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pf1-x435.google.com with SMTP id x3so9625855pfo.9; Sat, 04 Jul 2020 08:59:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=qw6Nx2nv6nBS1rCn/APJTVXavkUZ4vJvfIp3X92341w=; b=DwQQDo9GJjRjIl5/riiUsqgQr8Dv3Agas6prKnpbIda3k3BUBXI14a3RKiedRRfgbG aMkOmflLja7TwIKACEU2yIpDXXn6KJpZkP6OOwwBnV22xdm5yBtkeuaGg1rqNnqyh42v wbPlYBB8ioepsopa51QHUQ0BmbT6zObIx1fp5JXbPlLBGxSqfYGoK9hseg+GTzUhVY5n mqebbzrzzpgAYiA+tlQgzFFYPxaevYY/xLQTWHv198cIAKxqy20lzNIIDFaRjXKtlrB6 HHhYilJbxNkkMrR+/LhXm3e0s5ruLMQ5xtcATN9SHNWbr/Dn8Zpf/JHO1xFaFTD+G6gL Iq9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=qw6Nx2nv6nBS1rCn/APJTVXavkUZ4vJvfIp3X92341w=; b=L9p7L6FHx4gF735gw8zsHXA9z2cf40JeymnuTxWZwoK0yhzr21Q+jnx97P3o0M7P4F RdomrGgb3DRdiuygUUDrwP4rBniXSgxxiGj1c7jqtyUogymsk1SFrOg9cb4EBIYnoKu5 g4qiu0CXaLf1mjiLNDkLo3EbQB8jl6ggW4HRdkGR3rzMQanKeii0B3M44o8U3yf8fr2y BvBq/oTSdHkuEiknV5WFrJ+PRFGEarY9zJqzvC5TXi1r2zIcP5TtcfEIrotUKFzf2hgL 4uGNTVLZaKfGlTDkSW6xPOonCgGMqTxoATZFOjrdYuFRo4i1BNzNyD8F2IiYiaBtIFHk CpZg== X-Gm-Message-State: AOAM530/MvDmbABnB6xWW0H59wvH2HfzY9JE9Jbt9m7oHT8iwJHOtWuB tGpYxZys//bDnJJ5qbQbfbrQJ9LUw/w= X-Google-Smtp-Source: ABdhPJw9WAzzHwYaMcPgpe9fO+l/DgRV8FLlhESHRpXS6iDXMyCEgZLdN4JltIypmOiqa8G6vF/STA== X-Received: by 2002:a63:2d44:: with SMTP id t65mr23408718pgt.257.1593878378340; Sat, 04 Jul 2020 08:59:38 -0700 (PDT) Received: from [192.168.20.26] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id c71sm13443372pje.32.2020.07.04.08.59.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2020 08:59:37 -0700 (PDT) From: Enji Cooper Message-Id: <28F5E543-5B64-4CC0-A450-A2719D3C3A65@gmail.com> Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Undeletable files after kyua test runs Date: Sat, 4 Jul 2020 08:59:36 -0700 In-Reply-To: Cc: freebsd-current , Alan Somers To: Gordon Bergling References: <20200629172626.GA63722@lion.0xfce3.net> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zc3J2t5Tz3bQX X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=DwQQDo9G; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::435 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-2.87 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36:c]; FREEMAIL_FROM(0.00)[gmail.com]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.41)[-0.412]; RECEIVED_SPAMHAUS_PBL(0.00)[73.19.52.228:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.977]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::435:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 15:59:41 -0000 > On Jul 2, 2020, at 7:57 PM, Enji Cooper wrote: >=20 >>=20 >> On Jun 29, 2020, at 10:26 AM, Gordon Bergling = wrote: >>=20 >> Hi, >>=20 >> I recently stumbled across undeletable files that are generated by = kyua test runs, >> for example >>=20 >> -rwxr-xr-x 1 root wheel 0 May 9 13:10 = /tmp/kyua.aB4q62/8676/work/fileforaudit >>=20 >> I haven't yet identified the test that generate those files, but it = is impossible >> to delete them. I have clear_tmp_enable=3D"YES" set in the = /etc/rc.conf, but=20 >> on every boot the system argues that these file aren't deletable.=20 >> I tried to 'rm -rf' them by hand but, even this wasn't possible. I = have looked for >> any extend attributes, but I didn't find any. >>=20 >> Has anyone an idea how this is possible and may how these files can = be deleted? >=20 > The issue is tests/sys/audit/file-attribute-modify.c , based on the = file present that can=E2=80=99t be deleted. Can you please provide more = information about the test run in a PR (I see how it can leave files = behind, but I want to make sure it is what I think it is, first)? PR filed: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247761 = . Working = on a CR. Thanks, -Enji From owner-freebsd-current@freebsd.org Sat Jul 4 17:02:51 2020 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 244193535C8 for ; Sat, 4 Jul 2020 17:02:51 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: from mail-pg1-x533.google.com (mail-pg1-x533.google.com [IPv6:2607:f8b0:4864:20::533]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1O1" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 49zdS95kG5z3ff4; Sat, 4 Jul 2020 17:02:49 +0000 (UTC) (envelope-from yaneurabeya@gmail.com) Received: by mail-pg1-x533.google.com with SMTP id k27so369376pgm.2; Sat, 04 Jul 2020 10:02:49 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=ISvOp2W1eVFnStiLghNcRrelp5HMHixETesAVJN12Q4=; b=PKhe/KR09IJDVx8vwcnmDXm85YuXpMclm4r2N8J8nvf2EJYTWO04JtwxmguZbSI/ga p1yOvhH4juXuLp9otMkROBpUGrrXhschCzt7XTDTDIDTv2idxDtCUcCjz5Fp1GqeSnmi QeYSltZpOEKVHnQ9kbeAt1CMXTTn91BEubFx2SpS+r+xwoH5iYcgwMkWfiiChFKykYeo 5FkkUORr081q8CRE6HDsgZSid8n2f0w6nza4oEVKvdQHzJSLNM+pSerlhdOm5TJzY8dV U777IGerP2FSkRxDuskuJ2/nsyhz76JH3RDuRGgXhhGWUTDjxyGVE90Z2iVsBEwdvXJh sGZQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=ISvOp2W1eVFnStiLghNcRrelp5HMHixETesAVJN12Q4=; b=doho7XlIW5g3HctDa4c9xCD3GIjxqMGngURdI5HSlW+Zsf4Eu1ZZ5AHo8BIDZT6sAw f8Z3mFTXZY7JH5D7XxrN1URmTzKocaf/jjGhyuEDxswUrtoVCD2lFNdhq0fhu0TwOVRW MRiiMQwkdTv6MVAt45hbcZXEzlhTvpgr0xOWUq/7MDC1OxPyi8Y8ELkaXQ04w9uvVWRg q6t72q3xNSGWr2gc+6rEZ/XK0mMNVzKd8zG6FLV8WMfr4dUbVUgBKubhoyF/Z89crHM2 8CKh6s0MJSGQkwduwwXt5TOWGbQRX81Xzhc4CufI1554mwb+wl7DVT/MhFgY6DDH5dnJ JDFQ== X-Gm-Message-State: AOAM530woO3Cg7D9iyg7Q0wi+OD1GooMLXEGM3n84JEK4YDNP0JE2Uit JHeUc6mCMCvrgotDwXQj/HtMFSA3/ME= X-Google-Smtp-Source: ABdhPJw+MuYwE3rfrnkH5slKeVtZQ/vKUQfvbC7Ah5BCoGWJIkDVearl6MsmsSDs3+luQIfoo9MT2Q== X-Received: by 2002:a63:2241:: with SMTP id t1mr33289130pgm.440.1593882167570; Sat, 04 Jul 2020 10:02:47 -0700 (PDT) Received: from [192.168.20.26] (c-73-19-52-228.hsd1.wa.comcast.net. [73.19.52.228]) by smtp.gmail.com with ESMTPSA id d22sm14604012pfd.105.2020.07.04.10.02.45 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Sat, 04 Jul 2020 10:02:46 -0700 (PDT) From: Enji Cooper Message-Id: Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\)) Subject: Re: Undeletable files after kyua test runs Date: Sat, 4 Jul 2020 10:02:45 -0700 In-Reply-To: <28F5E543-5B64-4CC0-A450-A2719D3C3A65@gmail.com> Cc: freebsd-current , Alan Somers To: Gordon Bergling References: <20200629172626.GA63722@lion.0xfce3.net> <28F5E543-5B64-4CC0-A450-A2719D3C3A65@gmail.com> X-Mailer: Apple Mail (2.3608.80.23.2.2) X-Rspamd-Queue-Id: 49zdS95kG5z3ff4 X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=gmail.com header.s=20161025 header.b=PKhe/KR0; dmarc=pass (policy=none) header.from=gmail.com; spf=pass (mx1.freebsd.org: domain of yaneurabeya@gmail.com designates 2607:f8b0:4864:20::533 as permitted sender) smtp.mailfrom=yaneurabeya@gmail.com X-Spamd-Result: default: False [-3.31 / 15.00]; RCVD_VIA_SMTP_AUTH(0.00)[]; FREEMAIL_FROM(0.00)[gmail.com]; MV_CASE(0.50)[]; R_SPF_ALLOW(-0.20)[+ip6:2607:f8b0:4000::/36]; RCVD_COUNT_THREE(0.00)[3]; TO_DN_ALL(0.00)[]; DKIM_TRACE(0.00)[gmail.com:+]; DMARC_POLICY_ALLOW(-0.50)[gmail.com,none]; NEURAL_HAM_SHORT(-0.85)[-0.848]; RECEIVED_SPAMHAUS_PBL(0.00)[73.19.52.228:received]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+,2:~]; FREEMAIL_ENVFROM(0.00)[gmail.com]; ASN(0.00)[asn:15169, ipnet:2607:f8b0::/32, country:US]; MID_RHS_MATCH_FROM(0.00)[]; DWL_DNSWL_NONE(0.00)[gmail.com:dkim]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.99)[-0.986]; R_DKIM_ALLOW(-0.20)[gmail.com:s=20161025]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_MATCH_ENVRCPT_ALL(0.00)[]; NEURAL_HAM_LONG(-0.98)[-0.975]; MIME_GOOD(-0.10)[multipart/alternative,text/plain]; RCVD_IN_DNSWL_NONE(0.00)[2607:f8b0:4864:20::533:from]; RCVD_TLS_ALL(0.00)[] Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.33 X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.33 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 04 Jul 2020 17:02:51 -0000 > On Jul 4, 2020, at 8:59 AM, Enji Cooper wrote: >=20 >>=20 >> On Jul 2, 2020, at 7:57 PM, Enji Cooper > wrote: >>=20 >>>=20 >>> On Jun 29, 2020, at 10:26 AM, Gordon Bergling > wrote: >>>=20 >>> Hi, >>>=20 >>> I recently stumbled across undeletable files that are generated by = kyua test runs, >>> for example >>>=20 >>> -rwxr-xr-x 1 root wheel 0 May 9 13:10 = /tmp/kyua.aB4q62/8676/work/fileforaudit >>>=20 >>> I haven't yet identified the test that generate those files, but it = is impossible >>> to delete them. I have clear_tmp_enable=3D"YES" set in the = /etc/rc.conf, but=20 >>> on every boot the system argues that these file aren't deletable.=20 >>> I tried to 'rm -rf' them by hand but, even this wasn't possible. I = have looked for >>> any extend attributes, but I didn't find any. >>>=20 >>> Has anyone an idea how this is possible and may how these files can = be deleted? >>=20 >> The issue is tests/sys/audit/file-attribute-modify.c , based on the = file present that can=E2=80=99t be deleted. Can you please provide more = information about the test run in a PR (I see how it can leave files = behind, but I want to make sure it is what I think it is, first)? >=20 > PR filed: = https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D247761 = . Working = on a CR. Hi, I just created the following CR: = https://reviews.freebsd.org/D25561 = and added the following related GitHub issue to PR: = https://github.com/jmmv/kyua/issues/142 = . This should be completed to = avoid issues like this in the future from occurring. Thank you for the report! -Enji=