From owner-freebsd-questions@freebsd.org Mon Dec 30 18:51:41 2019 Return-Path: Delivered-To: freebsd-questions@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 A79B31E763F for ; Mon, 30 Dec 2019 18:51:41 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (enterprise.ximalas.info [IPv6:2001:700:1100:1::8]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) server-signature RSA-PSS (4096 bits) client-signature RSA-PSS (4096 bits) client-digest SHA256) (Client CN "ximalas.info", Issuer "Hostmaster ximalas.info" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 47mmk43n2Jz4Mrf for ; Mon, 30 Dec 2019 18:51:40 +0000 (UTC) (envelope-from trond.endrestol@ximalas.info) Received: from enterprise.ximalas.info (Ximalas@localhost [127.0.0.1]) by enterprise.ximalas.info (8.15.2/8.15.2) with ESMTPS id xBUIpZmM010439 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NO) for ; Mon, 30 Dec 2019 19:51:35 +0100 (CET) (envelope-from trond.endrestol@ximalas.info) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=ximalas.info; s=default; t=1577731895; bh=bIMUM6EGx9HLpa/HgHt6nxYqatFYBSuo54KG5b9MGbw=; h=Date:From:To:Subject:In-Reply-To:References; b=i9zNDv+oeecN9UnCZCwVHMB8bA4mDHJR6SDVwHUfKAyNrT9vc+czO2Y0nKOJDhFzH 2Qoww4oFKX3KrvROIWbQAc+wI/BeBZtdVM79/mFoRWBIy7Gh3vhQW1LVS67BowrkvO bQ2gKs4FK+wX9jPmmuq33zIYuGkRfBWNxHKSM0LPA9nM/pjSY4t5cbj8JkwpbxzD+L DT6w7HAUAbTzKFGxZt8HxS0m7z11dFAO6cQ9hNBi8a/jhVG5jSK1h5ZZa+Oow0YEgr kn6ZVnVKvN0FXgSbmksofiJaI/G4oJQ1AlFM/lJFqZCjlzPD7EOXf/7RmomofslOHy RC+3vD3woAwBA== Received: from localhost (trond@localhost) by enterprise.ximalas.info (8.15.2/8.15.2/Submit) with ESMTP id xBUIpZpV010436 for ; Mon, 30 Dec 2019 19:51:35 +0100 (CET) (envelope-from trond.endrestol@ximalas.info) X-Authentication-Warning: enterprise.ximalas.info: trond owned process doing -bs Date: Mon, 30 Dec 2019 19:51:35 +0100 (CET) From: =?UTF-8?Q?Trond_Endrest=C3=B8l?= Sender: Trond.Endrestol@ximalas.info To: freebsd-questions@freebsd.org Subject: Re: perl confusion --> failed to start spamd In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21.99999 (BSF 352 2019-06-22) OpenPGP: url=http://ximalas.info/about/tronds-openpgp-public-key MIME-Version: 1.0 X-Spam-Status: No, score=-0.8 required=5.0 tests=ALL_TRUSTED,DKIM_INVALID, DKIM_SIGNED autolearn=no autolearn_force=no version=3.4.3 X-Spam-Checker-Version: SpamAssassin 3.4.3 (2019-12-06) on enterprise.ximalas.info X-Rspamd-Queue-Id: 47mmk43n2Jz4Mrf X-Spamd-Bar: --- Authentication-Results: mx1.freebsd.org; dkim=pass header.d=ximalas.info header.s=default header.b=i9zNDv+o; dmarc=pass (policy=none) header.from=ximalas.info; spf=pass (mx1.freebsd.org: domain of trond.endrestol@ximalas.info designates 2001:700:1100:1::8 as permitted sender) smtp.mailfrom=trond.endrestol@ximalas.info X-Spamd-Result: default: False [-3.98 / 15.00]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; R_DKIM_ALLOW(-0.20)[ximalas.info:s=default]; FROM_HAS_DN(0.00)[]; R_SPF_ALLOW(-0.20)[+a:c]; TO_MATCH_ENVRCPT_ALL(0.00)[]; MIME_GOOD(-0.10)[multipart/mixed,text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-questions@freebsd.org]; TO_DN_NONE(0.00)[]; RCPT_COUNT_ONE(0.00)[1]; NEURAL_HAM_LONG(-1.00)[-1.000,0]; RCVD_COUNT_THREE(0.00)[3]; HAS_XAW(0.00)[]; DKIM_TRACE(0.00)[ximalas.info:+]; CTYPE_MIXED_BOGUS(1.00)[]; DMARC_POLICY_ALLOW(-0.50)[ximalas.info,none]; FROM_EQ_ENVFROM(0.00)[]; MIME_TRACE(0.00)[0:+,1:+]; RCVD_TLS_LAST(0.00)[]; ASN(0.00)[asn:224, ipnet:2001:700::/32, country:NO]; IP_SCORE(-1.98)[ip: (-7.88), ipnet: 2001:700::/32(-1.28), asn: 224(-0.74), country: NO(-0.01)] Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT X-Content-Filtered-By: Mailman/MimeDel 2.1.29 X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 18:51:41 -0000 On Mon, 30 Dec 2019 19:45+0100, Trond Endrestøl wrote: > Either pkg add net-mgmt/p5-NetAddr-IP, or (forcefully) reapply > mail/spamassassin. I'm sorry, that's pkg install net-mgmt/p5-NetAddr-IP. -- Trond. From owner-freebsd-questions@freebsd.org Mon Dec 30 19:29:48 2019 Return-Path: Delivered-To: freebsd-questions@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 BA0A31E7EF3 for ; Mon, 30 Dec 2019 19:29:48 +0000 (UTC) (envelope-from per@hedeland.org) Received: from mailout.easydns.com (mailout.easydns.com [64.68.202.10]) (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 47mnZ356mGz4Nvy for ; Mon, 30 Dec 2019 19:29:47 +0000 (UTC) (envelope-from per@hedeland.org) Received: from localhost (localhost [127.0.0.1]) by mailout.easydns.com (Postfix) with ESMTP id 988CAA0498; Mon, 30 Dec 2019 19:29:46 +0000 (UTC) Received: from mailout.easydns.com ([127.0.0.1]) by localhost (emo13-pco.easydns.vpn [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dcQQflbQGeAa; Mon, 30 Dec 2019 19:29:46 +0000 (UTC) Received: from hedeland.org (81-228-157-209-no289.tbcn.telia.com [81.228.157.209]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mailout.easydns.com (Postfix) with ESMTPSA id 0482FA2554; Mon, 30 Dec 2019 19:29:44 +0000 (UTC) Received: from pluto.hedeland.org (pluto.hedeland.org [10.1.1.5]) by tellus.hedeland.org (8.15.2/8.15.2) with ESMTPS id xBUJTgAT059838 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128 verify=NO); Mon, 30 Dec 2019 20:29:42 +0100 (CET) (envelope-from per@hedeland.org) Subject: Re: kernel: drmn0: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg To: Polytropon Cc: freebsd-questions@freebsd.org References: <20191230045740.GA20668@admin.sibptus.ru> <20191230065405.eb83eb86.freebsd@edvax.de> <20191230060307.GA25721@admin.sibptus.ru> <20191230072754.0c7a8920.freebsd@edvax.de> <20191230064017.GA28510@admin.sibptus.ru> <20191230091749.b86d5622.freebsd@edvax.de> <20191230090855.GA37814@admin.sibptus.ru> <49ac8c7e-31f7-251f-60c4-098b7269a52d@hedeland.org> <20191230183522.8f4af4bf.freebsd@edvax.de> From: Per Hedeland Message-ID: <534a7760-7774-58d8-b150-7086b97ff876@hedeland.org> Date: Mon, 30 Dec 2019 20:29:42 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.6.1 MIME-Version: 1.0 In-Reply-To: <20191230183522.8f4af4bf.freebsd@edvax.de> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47mnZ356mGz4Nvy X-Spamd-Bar: + Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of per@hedeland.org has no SPF policy when checking 64.68.202.10) smtp.mailfrom=per@hedeland.org X-Spamd-Result: default: False [1.54 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; RCVD_COUNT_FIVE(0.00)[5]; RECEIVED_SPAMHAUS_PBL(0.00)[209.157.228.81.khpj7ygk5idzvmvt5x4ziurxhy.zen.dq.spamhaus.net : 127.0.0.11]; FROM_HAS_DN(0.00)[]; TO_DN_SOME(0.00)[]; NEURAL_HAM_MEDIUM(-0.26)[-0.257,0]; MIME_GOOD(-0.10)[text/plain]; RCVD_TLS_LAST(0.00)[]; DMARC_NA(0.00)[hedeland.org]; AUTH_NA(1.00)[]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCPT_COUNT_TWO(0.00)[2]; NEURAL_SPAM_LONG(0.53)[0.529,0]; R_SPF_NA(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[10.202.68.64.list.dnswl.org : 127.0.5.1]; R_DKIM_NA(0.00)[]; MIME_TRACE(0.00)[0:+]; ASN(0.00)[asn:16686, ipnet:64.68.200.0/22, country:CA]; MID_RHS_MATCH_FROM(0.00)[]; IP_SCORE(0.47)[ip: (0.64), ipnet: 64.68.200.0/22(0.12), asn: 16686(1.70), country: CA(-0.09)]; FROM_EQ_ENVFROM(0.00)[] X-BeenThere: freebsd-questions@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: User questions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Dec 2019 19:29:48 -0000 On 2019-12-30 18:35, Polytropon wrote: > On Mon, 30 Dec 2019 11:49:45 +0100, Per Hedeland wrote: >> On 2019-12-30 10:08, Victor Sudakov wrote: >>> Polytropon wrote: >>>>>>>> On Mon, 30 Dec 2019 11:57:40 +0700, Victor Sudakov wrote: >>>>>>>>> On an "HP ProBook 6560b" notebook running FreeBSD 12.1, I've installed >>>>>>>>> graphics/drm-kmod and loaded it via >>>>>>>>> kld_list="/boot/modules/radeonkms.ko" in rc.conf. The X server even works OK. >>>>>>>>> >>>>>>>>> # pkg which "/boot/modules/radeonkms.ko" >>>>>>>>> /boot/modules/radeonkms.ko was installed by >>>>>>>>> package drm-fbsd12.0-kmod-4.16.g20191120 >>>>>>>>> >>>>>>>>> However, the kernel complains: >>>>>>>>> >>>>>>>>> "kernel: drmn0: This code is obsolete abandonware. >>>>>>>>> Install the graphics/drm-legacy-kmod pkg" >>>>>>>>> >>>>>>>>> Is this some kind of bug? >> >> The message is from the in-kernel drm version, not the one installed >> by the package - from a 12.1-RELEASE + >> drm-fbsd12.0-kmod-4.16.g20191120 (built from the port) install: >> >> $ strings -f /boot/kernel/drm*.ko | grep obsolete >> /boot/kernel/drm.ko: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg >> /boot/kernel/drm2.ko: This code is obsolete abandonware. Install the graphics/drm-legacy-kmod pkg >> >> $ strings -f /boot/modules/drm*.ko | grep obsolete >> >> When you load one of the hardware-specific modules from the package >> (as you do with the recommended kld_list setting in rc.conf), it will >> in turn load /boot/modules/drm.ko (from the package) - at least that >> happens with i915kms.ko that I'm using. > > Very strange. I'm also using the explicit loading method for > i915kms.ko (installed via pkg) and still get the abandonware > message. I did not install drm-legacy-kmod, but drm-kmod, and > per your definition (and my now grown understanding, thanks) > this should have installed and loaded (!) drm.ko from the > package, not the OS one. Well, what can I say - "it works for me":-) (and actually for at least some other users). And I believe it should be expected to work. Are you sure you don't have an explicit "load instruction" somewhere that ends up loading /boot/kernel/drm.ko? I guess it could also be a "secondary/dependent" load - e.g. if you load i915kms without path somewhere, it will (attempt to) load /boot/kernel/i915kms.ko, and presumably pull in /boot/kernel/drm.ko. >> Are you loading a drm module explicitly somehow? E.g. 'kld_load drm' >> or equivalent loads the in-kernel version by default, based on: >> >> $ sysctl kern.module_path >> kern.module_path: /boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays > > Is it suggested to "manually" load drm.ko with the kld_list= > setting in /etc/rc.conf, in addition to the graphics driver > fitting the hardware? I have not seen such a suggestion from the maintainers of the "new drm". In a past discussion, not sure if it was here or in x11@, someone ("a") did suggest it, someone else ("b") pointed out that it wasn't necessary, and "a" reported back that it worked without. I guess it may be considered a matter of taste - personally I prefer to tell the kernel as little as possible about which modules to load, and have it figure things out from the existing hardware and inter- module dependencies, except for the cases where that just doesn't/can't work. Wanting to have "absolute control" and spell everything out is also a valid approach, but it seems to me that it has a higher risk of breaking due to updates. >>>>>>>> No, it's intended. You'll also see such warnings during >>>>>>>> the boot process and in the system message log file. >>>>>>>> >>>>>>> >>>>>>> It cannot be intended with graphics/drm-kmod installed which is by >>>>>>> definition not "legacy" or "obsolete". Quite the opposite, it should be >>>>>>> the newer driver. >> >> Correct, see above. > > In that case, the description shown on FreshPorts (see quotes > in my previous replies) is misleading, isn't it? Here is the initial part again (it's also in graphics/drm-kmod/pkg-descr): amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components on amd64, i915 and radeonkms DRM modules from the former base DRM component on other architectures. It's not entirely trivial to parse, but after a reading it a few times (and double-checking the port's Makefile:-), I believe it is saying: For amd64: amdgpu, i915, and radeon DRM modules for the linuxkpi-based KMS components For other architectures: i915 and radeonkms DRM modules from the former base DRM component I.e. the "really" new stuff is only for amd64, for other architectures you get a "forward-port" of the old stuff. >>>>>> Not really. From the description: >>>>>> >>>>>> amdgpu, i915, and radeon DRM modules for the >>>>>> linuxkpi-based KMS components on amd64, i915 >>>>>> and radeonkms DRM modules from the former >>>>>> base DRM component on other architectures. >>>>>> >>>>>> Metaport for different versions of Linux >>>>>> DRM based on the FreeBSD version in use. >>>>>> >>>>>> This port is a meta-port of the drivers previously contained >>>>> >>>>> Which "this port", graphics/drm-legacy-kmod (which I don't have >>>>> installed) or graphics/drm-kmod (which I have installed)? >>>> >>>> The graphics/drm-kmod (installed) = "old drivers" at the >>>> moment; >> >> No - as mentioned this is a meta-port, which will actually install the >> current version of graphics/drm-fbsd12.0-kmod if you are running 12.x. > > Does graphics/drm-kmod do more than install graphics/drm-fbsd12.0-kmod? > If no - why is there a meta-port installing just one other port? I believe the idea is that drm-kmod should figure out *which* other port to install (based on amd64 arch or not, as well as based on FreeBSD version for amd64 - see the Makefile), to save the user the trouble. In yet another discussion, it was suggested that using a meta-port for this was a Bad Idea(tm) - I'm not sure whether it is, at least when installing it seems very convenient to me. There are some strange behaviors for e.g. 'delete' and 'reinstall', but it seems to me that they are a general consequence of how meta-ports are implemented (i.e. all meta-ports "suffer" from those). --Per