From owner-freebsd-current@freebsd.org Wed Sep 12 21:13:56 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 85ADA109D380 for ; Wed, 12 Sep 2018 21:13:56 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from wout2-smtp.messagingengine.com (wout2-smtp.messagingengine.com [64.147.123.25]) (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 EDF23723E3 for ; Wed, 12 Sep 2018 21:13:55 +0000 (UTC) (envelope-from yuripv@yuripv.net) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 22D2D344 for ; Wed, 12 Sep 2018 17:13:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Wed, 12 Sep 2018 17:13:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yuripv.net; h= content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=fm2; bh=Gtx8nCR9iVsN8crfBVv6e2hJq5pE4 qH7PzPS72iP9yI=; b=pkEEKPCOHJk5DjE1lAHswtezAda6QOeXL1CgurkGFrn8f K15XVgB8xyBWBa5zOMxOg4BWI8bkofJU4YLym2WPQ2sA3WLY4sZJzsiKxwek7HKz 2sioheTiPbgZwFzdtc/GGPBGvs8VF7Zke6eNvCVtS/PtVL8E48xWQftBzuj8W52v UVazQYII8Huxj4sMhzaCgG26fFCu0lXtIrNwARyzzNwDAlyPEOEJZu7b6FUAOxVO tPFwUeWsdGYV8uBxJAC3dNWfan1prYf2JrBxzHLepBBSHcLnNvh4FMVG6Fws8PcQ DEeJXblcmnGcBcBbbSd+XoZ9qYXqT9FNkI66+2FKA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=Gtx8nC R9iVsN8crfBVv6e2hJq5pE4qH7PzPS72iP9yI=; b=TBOrIa/jiAlaga2vYnTWWU L7Lxf9+1gCtwFHRhgZEsL1VD28dSur2EYFdJNxLTDgFm6CfzzT34QFSmaCBIinpy TQ65HRUUk+bbE7l8k/ykbdW9DalLlOfjOA7WqEYBh+2NPSkqRuaPprCw7nXOK55p 8z557JNQ7abThHMAUm/W1clTw4f559mQFdthKXdG+0TLTpKvRZR211Uuu+pJao5D QHkJz8nso0pYy0y9sNgjyUUFQjKVx+GaHzpOuYYLQO98Bvy6MqQs0z+OEJAK9Zcr wSxxS+k42gGUFG9yzF2gJwlus7W7jHKqZVdHkcCi8zbXADfXUHyycJPMQNvC2TOg == X-ME-Proxy: X-ME-Sender: Received: from [192.168.1.2] (unknown [178.34.113.240]) by mail.messagingengine.com (Postfix) with ESMTPA id 6F20B102D6 for ; Wed, 12 Sep 2018 17:13:52 -0400 (EDT) Subject: Re: r336876 breaks sysutils/acpi_call To: freebsd-current References: <72380894-6f0c-30e9-b755-d79a8a38a1eb@gmail.com> From: Yuri Pankov Message-ID: Date: Thu, 13 Sep 2018 00:13:51 +0300 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 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: Wed, 12 Sep 2018 21:13:56 -0000 Max Ignatenko wrote: > Hi, > > Sorry for a late reply! > > First of all, thank you for taking time to investigate and even providing a > fix (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230993) ! Your patch > makes perfect sense to me and modifying userspace memory from kernel is > indeed something I didn't consider to be a problem at the time. > > Second, I'm not actively participating in FreeBSD community and development > at the moment, and if you're willing to take over sysutils/acpi_call - I'll > be happy to cooperate. Otherwise, I'll try to take time to incorporate your > fix in the few upcoming weeks. > > > On Sun, 26 Aug 2018 at 04:51, Theron wrote: > >> >> A recent change in CURRENT has sysutils/acpi_call reliably cause a >> kernel panic when run on a Dell XPS laptop system. I bisected this to >> r336876: Use SMAP on amd64. I would have thought that this is a simple >> compatibility problem requiring only a port update, except that the same >> kernel and acpi_call on different hardware are not affected. On the >> problematic system, the kernel module loads without incident; it is when >> executing ACPI commands, even normally harmless operations such as >> requesting read-only constants, that the system freeze occurs. ACPI >> functionality seems otherwise unaffected. >> >> Kernel debugging console and crash dumps are also broken on this system >> (I suspect due to Intel graphics) however it is an unrelated problem, >> and is only an excuse for my inability to provide any further crash >> information. >> >> Having already bisected to the breaking commit, is there anything else I >> should do to improve the chances this problem gets fixed, or are there >> any hardware compatibility notes I may have missed? Just wondering if we could follow what DFBSD did, and integrate this utility in the base as it seems simple enough, and apparently useful in a lot of cases.