Re: HEADSUP: drm-current-kmod now installs sources
This is super cool, thank you! Is it feasible to integrate other out-of-tree kmods in a similar way, e.g., nvidia-driver? On Tue, Aug 13, 2019 at 2:58 PM John Baldwin wrote: > > With help from zeising@ in particular, I've just committed a change > to the drm-current-kmod port that makes it install sources into > /usr/local/sys/modules by default. This will result in some behavior > changes on HEAD (and only head for now): > > 1) When you build a kernel after installing the updated package, >your buildkernel will now build DRM modules using the sources >from the package. For developers at least I suspect this to be >a win as if you have made changes to the kernel KBI you will >always end up with matching modules installed into /boot/kernel >alongside your kernel. > > 2) In order to use these modules, you need to update the 'kld_list' >lines in your rc.conf to just list the modules without a >path, e.g. "kld_list=i915kms" just as you would for other >modules. This will prefer the module built with your kernel if >one exists and fall back to the module in /boot/modules >otherwise. > > If a change in current breaks the build of DRM modules, you have a > couple of options: > > 1) Pass 'LOCAL_MODULES=' (empty string) on the command line of >'make buildkernel' to disable building the DRM modules. > > 2) Hack on the sources in /usr/local/sys/modules/drm-current-kmod >to fix the compile breakage, perhaps using a patch from the >mailing lists if one exists. > > 3) Wait for a new package/port version and update to that before >doing a buildkernel. > > For developers this means even if you are doing testing on a box > that doesn't use DRM, you can install the package so that kernel > builds will try to compile it and hopefully spot KPI/KBI changes > before they land in the tree so that the port/package can be > patched in tandem with committing changes to HEAD. Note that even > builds of work trees in git checkouts, etc. will find the DRM > modules and try to build them if the package is installed. > > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: drm-current-kmod now installs sources
On Tue, 2019-08-13 at 14:58 -0700, John Baldwin wrote: > For developers this means even if you are doing testing on a box > that doesn't use DRM, you can install the package so that kernel > builds will try to compile it and hopefully spot KPI/KBI changes > before they land in the tree so that the port/package can be > patched in tandem with committing changes to HEAD. Note that even > builds of work trees in git checkouts, etc. will find the DRM > modules and try to build them if the package is installed. That last sentence sounds ominous. Are you saying that when I'm on my amd64 machine building from /my/sources/rpi using TARGET_ARCH=armv6 it's going to find /usr/local/sys/modules/drm-current-kmod and try to crossbuild it for armv6? How about when I'm doing a build of 11-stable for testing, but what's in my /usr/local is sources for a 13-current driver? -- Ian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
HEADSUP: drm-current-kmod now installs sources
With help from zeising@ in particular, I've just committed a change to the drm-current-kmod port that makes it install sources into /usr/local/sys/modules by default. This will result in some behavior changes on HEAD (and only head for now): 1) When you build a kernel after installing the updated package, your buildkernel will now build DRM modules using the sources from the package. For developers at least I suspect this to be a win as if you have made changes to the kernel KBI you will always end up with matching modules installed into /boot/kernel alongside your kernel. 2) In order to use these modules, you need to update the 'kld_list' lines in your rc.conf to just list the modules without a path, e.g. "kld_list=i915kms" just as you would for other modules. This will prefer the module built with your kernel if one exists and fall back to the module in /boot/modules otherwise. If a change in current breaks the build of DRM modules, you have a couple of options: 1) Pass 'LOCAL_MODULES=' (empty string) on the command line of 'make buildkernel' to disable building the DRM modules. 2) Hack on the sources in /usr/local/sys/modules/drm-current-kmod to fix the compile breakage, perhaps using a patch from the mailing lists if one exists. 3) Wait for a new package/port version and update to that before doing a buildkernel. For developers this means even if you are doing testing on a box that doesn't use DRM, you can install the package so that kernel builds will try to compile it and hopefully spot KPI/KBI changes before they land in the tree so that the port/package can be patched in tandem with committing changes to HEAD. Note that even builds of work trees in git checkouts, etc. will find the DRM modules and try to build them if the package is installed. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: 13.0 Current - r350702 exposed a Xorg failure
Thanks Pete, I did have the user in the video group, but I need to look into the permissions issue. I have tried to install Xorg several times since last Friday, including reverting to last weeks current, and never had any luck. Right now the FreeBSD partition is wiped clean. The new snapshot will be out day after tomorrow, but I may have time to try again before that. I certainly will let you know when I get this solved. It may be I would have better luck if I compiled the Xorg ports rather than just installing the binaries. But thanks for the advice. It cheers me up. Clay On Mon, Aug 12, 2019 at 9:49 PM Pete Wright wrote: > > > On 8/9/19 8:56 PM, Clay Daniels Jr. wrote: > > I was eager to load the new 13.0 Current snapshot yesterday as I wanted > to > > play with the new FUSE tools. I was running 13.0 Current r350491 from > last > > week and everything was going great. So last night, a little late I > guess, > > I wiped the older install and loaded r250702. Then I loaded Xorg, all 172 > > packages, and loaded the drm-kmod video driver kernel modules, and then > ran > > startx (as user of course). I got errors & it was late so today I looked > > closer. It said: > > "xauth: file .serverauth.1039 does not exist" > > > > Well, this file is apparently something created automatically. I played > > with the half-running install for a long time. It ran fine in console > mode. > > Then I the wiped it and reloaded the same newer r350702. No Go. > > > > Wiped the new r350702 and reloaded the older r350491 that was working > just > > fine last night. Same Problemserverauth.xxx > > > > Now, I do know that the drm-kmod was the same (g20190710) that had worked > > for me at least two times already. I do not know if the Xorg pkg is the > > same. I couldn't find a date other than "latest". I'm writing this email > > from my Linux partition. > first thing that comes to mind, did you make sure to add your user to > the "video" group? this doesn't sound related though...this does sound > like a local configuration issue. iirc when i ran into this problem in > the past it was due to permissions, either a .serverauth file owned by > root or a UID that no longer exists. > > -p > > -- > Pete Wright > p...@nomadlogic.org > @nomadlogicLA > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)
Hi,
After tearing ACPI apart, there appears to be an issue like following:
1) AcpiUtAcquireMutex() doesn't support recursion, but also fails to
report an error when such a condition is occurring. Here is the
backtrace of the illegal mutex recursion.
> AcpiUtAcquireMutex() at AcpiUtAcquireMutex+0x1fc/frame 0x834815d0
> AcpiWalkNamespace() at AcpiWalkNamespace+0x8a/frame 0x83481640
> AcpiNsInitializeObjects() at AcpiNsInitializeObjects+0x9b/frame
0x834816c0
> AcpiExLoadTableOp() at AcpiExLoadTableOp+0x21c/frame 0x83481730
> AcpiExOpcode_6A_0T_1R() at AcpiExOpcode_6A_0T_1R+0x22e/frame
0x83481790
> AcpiDsExecEndOp() at AcpiDsExecEndOp+0x1dc/frame 0x83481830
> AcpiPsParseLoop() at AcpiPsParseLoop+0x75a/frame 0x83481880
> AcpiPsParseAml() at AcpiPsParseAml+0xfd/frame 0x834818d0
> AcpiPsExecuteMethod() at AcpiPsExecuteMethod+0x27d/frame
0x83481940
> AcpiNsEvaluate() at AcpiNsEvaluate+0x336/frame 0x834819b0
> AcpiEvaluateObject() at AcpiEvaluateObject+0x223/frame 0x83481a10
> AcpiEvaluateObjectTyped() at AcpiEvaluateObjectTyped+0xe0/frame
0x83481aa0
> acpi_EvaluateOSC() at acpi_EvaluateOSC+0xef/frame 0x83481b90
> acpi_cpu_attach() at acpi_cpu_attach+0x432/frame 0x83481cb0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83481cf0
> device_attach() at device_attach+0xb9/frame 0x83481d80
> device_probe_and_attach() at device_probe_and_attach+0x106/frame
0x83481dc0
> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83481df0
> acpi_probe_children() at acpi_probe_children+0x77/frame
0x83481e30
> acpi_attach() at acpi_attach+0xbfe/frame 0x83482050
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x83482090
> device_attach() at device_attach+0xb9/frame 0x83482120
> device_probe_and_attach() at device_probe_and_attach+0x106/frame
0x83482160
> bus_generic_attach() at bus_generic_attach+0x2c/frame 0x83482190
> nexus_acpi_attach() at nexus_acpi_attach+0x59/frame 0x834821b0
> DEVICE_ATTACH() at DEVICE_ATTACH+0x87/frame 0x834821f0
> device_attach() at device_attach+0xb9/frame 0x83482280
> device_probe_and_attach() at device_probe_and_attach+0x106/frame
0x834822c0
> bus_generic_new_pass() at bus_generic_new_pass+0xb5/frame
0x83482300
> BUS_NEW_PASS() at BUS_NEW_PASS+0x87/frame 0x83482340
> bus_set_pass() at bus_set_pass+0x8f/frame 0x83482360
> root_bus_configure() at root_bus_configure+0xe/frame 0x83482370
> configure() at configure+0x11/frame 0x83482390
> mi_startup() at mi_startup+0x2dc/frame 0x834823f0
> btext() at btext+0x2c
> ACPI Error: AE_ALREADY_ACQUIRED, During WalkNamespace
(20190703/nsinit-232)
The illegal mutex recursion ends up leaking a lock, which later on
causes a boot deadlock due to accesses to ACPI hanging forever.
2) This patch works around the issue.
> diff --git a/sys/contrib/dev/acpica/components/utilities/utmutex.c
b/sys/contrib/dev/acpica/components/utilities/utmutex.c
> index 4853bf5c3a6..33a67a731c6 100644
> --- a/sys/contrib/dev/acpica/components/utilities/utmutex.c
> +++ b/sys/contrib/dev/acpica/components/utilities/utmutex.c
> @@ -378,6 +378,16 @@ AcpiUtAcquireMutex (
>
> ThisThreadId = AcpiOsGetThreadId ();
>
> +if (AcpiGbl_MutexInfo[MutexId].ThreadId == ThisThreadId)
> +{
> + ACPI_ERROR ((AE_INFO,
> + "Mutex [%s] already acquired by this thread [%u]",
> + AcpiUtGetMutexName (MutexId),
> + (UINT32) ThisThreadId));
> +
> + return (AE_ALREADY_ACQUIRED);
> +}
> +
> #ifdef ACPI_MUTEX_DEBUG
> {
> UINT32
--HPS
On 2019-08-01 15:58, Scott Long wrote:
I’m 99% sure that the boot breakage is due to this commit:
Author: jkim
Date: Tue Jul 9 18:02:36 2019
New Revision: 349863
URL: https://svnweb.freebsd.org/changeset/base/349863
Log:
MFV: r349861
Import ACPICA 20190703.
I have two systems now that are affected, and both of them
are “fixed” by reverting this. I don’t know the root cause yet,
see my email to the svn-src-all mailing list.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Bug report commit request
Dear Committers, Would someone please commit following bug report? Bug 236564 - periodic.sh: Anticongestion function does not work as is expected. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236564 Best Regards. --- Yasuhiro KIMURA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
