Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. Let us know how whatever OS you wind up using instead works for you. I suggest you look for one that will put up with your constant harangues. There are very few people on the mailing lists as nasty and rude as yourself. It is tiresome, demotivating, and childish. Please go elsewhere. mcl ___ 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: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 8:40 AM Pete Wright wrote: > > > On 8/24/18 4:07 PM, blubee blubeeme wrote: > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > > - Move DRM headers to a similar location as Linux > > - > > > > Use kmalloc() instead of malloc(9) > > - Use kref > > - > > > > Use idr and get rid of drm_gem_names.c > > - Use PCI API > > - Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > having a hard time not feeding the troll here...but what specifically is > garbage. as in, what implementation of all this work do you have > available that has been developed independently which also enables > support for modern desktop and portable systems that you can buy today? > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > The idea that FreeBSD relax it's standards just so that some devs have an easier time bringing up a half baked idea is nonsense. Let's take power management, after you guys do all this work to get the graphics card working how much of devd will you need to implement to get that working properly? I don't understand why this concept seems so hard to grasp but FreeBSD is not Linux why are some people continually trying to turn it into some Frankenstein thing. If you guys consider yourself developers then do what developers do and solve problems with constraints, if you cannot accomplish that stop pushing these breaking changes. None of these kmod guys seems to have put any thought into long term maintenance of this project. Look at the mailing list, every few days there's some breaking changes waiting for patches because something changed in Linux-land... If you can't solve the problem in a maintainable way, you will just create bigger problems for developers down the line. Until you guys have something that's at least as stable as what's available now, keep working on it. Some people take pride in their work and deliver a working product, they don't need to twist peoples arms into getting their way. speaking as someone who's been working on this from pretty much the day > of the initial CFT (maybe before?) - i don't know anyone who's getting > paid for this specific work. at least when it comes to GPU support. > but, if you have the means, I'd love to work on this full time and am > open to any serious offers :) > > -pete > I'd hope you have something more compelling than [http://nomadlogic.org] as your calling card. -- 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: drm / drm2 removal in 12
On 8/24/18 4:07 PM, blubee blubeeme wrote: This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. having a hard time not feeding the troll here...but what specifically is garbage. as in, what implementation of all this work do you have available that has been developed independently which also enables support for modern desktop and portable systems that you can buy today? Are these guys insane and please avoid the nonsense about you're doing this in your spare time. speaking as someone who's been working on this from pretty much the day of the initial CFT (maybe before?) - i don't know anyone who's getting paid for this specific work. at least when it comes to GPU support. but, if you have the means, I'd love to work on this full time and am open to any serious offers :) -pete -- 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: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > On 8/24/18 7:07 PM, blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > > > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > >> > >>> On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >>> > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > Just in case anyone misses the change to UPDATING: > > > > 20180821: > > drm and drm2 have been removed. Users on powerpc, 32-bit > hardware, > > or with GPUs predating Radeon and i915 will need to install > >> the > > graphics/drm-legacy-kmod. All other users should be able to > >> use > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > Note that this applies only to 12. > I see that The removal of drm and drm2 has been reverted on svn. Could > you please kindly share the reasons behind the re-inclusion? > > >>> > >>> I can’t really give the blow by blow of internal project drama, but the > >>> gist of it is that “best practices” (which are not yet actually > >> documented > >>> anywhere that I’ve seen) were not followed with regards to the > >> deprecation > >>> process. Warner and others believe that we can address the objectives > of > >>> the drm removal (improving the user experience and communicating that > >>> drm/drm2 are _completely_ unsupported apart from continuing to compile) > >>> through less disruptive means. > >>> > >> Just so. > >> > >> Our only continued frustration is that we were never given any guidance > by > >>> RE or core on said “best practices” when the discussion was taking > place > >> in > >>> May and then those groups behaved as if this were a surprise when the > >>> removal happened. I’m cautiously optimistic that this well expedite > >>> improving communications on those matters. > >>> > >> All the problems that are exposed by this aren't technical. This one is > >> social, but no less important. > >> > >> Warner > >> ___ > >> 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" > >> > > I've been watching this debacle for quite some time now and I'd just like > > to ask why the rush? > > > > The graphics team is working very hard to destroy the stability of > FreeBSD > > just so that they can force their uncooked work down users throats. > > > > The Linuxkpi is unstable at best, alpha level software that's constantly > in > > need of someone to go and fix something on FreeBSD because Linux devs > > decided to make some changes or implement a new feature. > > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > >- Move DRM headers to a similar location as Linux > >- > > > >Use kmalloc() instead of malloc(9) > >- Use kref > >- > > > >Use idr and get rid of drm_gem_names.c > >- Use PCI API > >- Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > > > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > > > If you cannot devote the resources to do something right then don't do it > > at all. > > > > Keep that stuff in to yourself or anyone crazy enough to follow those > steps > > to get it up and running, you guys cannot expect to contaminate the > entire > > FreeBSD project for this mess. > > > > This is nonsense and I hope that more people who see it as such would say > > so and stop having these guys forcing this crap; it's maintenance hell > who > > will maintain it if they decide to leave? > > > > Best, > > Owen > > ___ > > 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" > > I've been personally using the new DRM bits since almost day one. I > haven't found it to be unstable in the slightest. Compared to not having > it and being forced to run 5+ year old hardware, it's been a huge > blessing for those of us who care about running FreeBSD as a modern > desktop / laptop. > > FreeBSD being an open source project, you are welcome to contribute back > your work anytime. But since I don't imagine we'll see that patch coming > anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop > running awesomeness. > > (Written from my brand new Lenovo P71 which worked flawlessly out of box) > > > -- > Kris Moore > Vice President of Engineering > iXsystems > Enterprise Storage & Servers Driven By Open Source > > ___ > freebsd-current@freebsd.org mailing list >
Re: drm / drm2 removal in 12
On 8/24/18 7:07 PM, blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >> >>> On Fri, Aug 24, 2018 at 14:53 Ali wrote: >>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: > > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install >> the > graphics/drm-legacy-kmod. All other users should be able to >> use > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. > Note that this applies only to 12. I see that The removal of drm and drm2 has been reverted on svn. Could you please kindly share the reasons behind the re-inclusion? >>> >>> I can’t really give the blow by blow of internal project drama, but the >>> gist of it is that “best practices” (which are not yet actually >> documented >>> anywhere that I’ve seen) were not followed with regards to the >> deprecation >>> process. Warner and others believe that we can address the objectives of >>> the drm removal (improving the user experience and communicating that >>> drm/drm2 are _completely_ unsupported apart from continuing to compile) >>> through less disruptive means. >>> >> Just so. >> >> Our only continued frustration is that we were never given any guidance by >>> RE or core on said “best practices” when the discussion was taking place >> in >>> May and then those groups behaved as if this were a surprise when the >>> removal happened. I’m cautiously optimistic that this well expedite >>> improving communications on those matters. >>> >> All the problems that are exposed by this aren't technical. This one is >> social, but no less important. >> >> Warner >> ___ >> 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" >> > I've been watching this debacle for quite some time now and I'd just like > to ask why the rush? > > The graphics team is working very hard to destroy the stability of FreeBSD > just so that they can force their uncooked work down users throats. > > The Linuxkpi is unstable at best, alpha level software that's constantly in > need of someone to go and fix something on FreeBSD because Linux devs > decided to make some changes or implement a new feature. > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > Goals > >- Move DRM headers to a similar location as Linux >- > >Use kmalloc() instead of malloc(9) >- Use kref >- > >Use idr and get rid of drm_gem_names.c >- Use PCI API >- Use Linux locking primitives > > is garbage, if you want to use develop Linux code and use Linux then go do > that on Linux. > > Are these guys insane and please avoid the nonsense about you're doing this > in your spare time. > > If you cannot devote the resources to do something right then don't do it > at all. > > Keep that stuff in to yourself or anyone crazy enough to follow those steps > to get it up and running, you guys cannot expect to contaminate the entire > FreeBSD project for this mess. > > This is nonsense and I hope that more people who see it as such would say > so and stop having these guys forcing this crap; it's maintenance hell who > will maintain it if they decide to leave? > > Best, > Owen > ___ > 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" I've been personally using the new DRM bits since almost day one. I haven't found it to be unstable in the slightest. Compared to not having it and being forced to run 5+ year old hardware, it's been a huge blessing for those of us who care about running FreeBSD as a modern desktop / laptop. FreeBSD being an open source project, you are welcome to contribute back your work anytime. But since I don't imagine we'll see that patch coming anytime soon, I'll stick with this new LinuxKPI-powered, Plasma-desktop running awesomeness. (Written from my brand new Lenovo P71 which worked flawlessly out of box) -- Kris Moore Vice President of Engineering iXsystems Enterprise Storage & Servers Driven By Open Source ___ 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 4:20 PM Niclas Zeising wrote: > On 08/24/18 17:20, Warner Losh wrote: > > This would allow the graphics port to have a rc script that sets > > this up so when X11 goes to automatically load the module, the right one > > gets loaded. > > > > I just want to point out that X11 doesn't load the graphics kernel > driver by default when using the drm-*-kmod ports, and I'm not sure the > hack to have the intel ddx (xf86-video-intel) load the drm2 driver is > still around. > > It doesn't really matter though, since upstream is moving away from > having X load the driver, and I'd like us to follow suit by using > devmatch (this is one of the reasons we wanted to get rid of the base > drivers, as I've stated before). X can't always know which driver to > load (when using modesetting for instance), and in my opinion, it should > be the kernel/loader that decides which drivers to load. Excellent. That reduces the compatibility matrix I need to consider. I have some ideas, and will hack on them to see if a clever bit of slide of hand will solve the main problem of loading the wrong driver in a dependency chain. Warner ___ 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: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > > Just in case anyone misses the change to UPDATING: > > > > > > > > 20180821: > > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > > hardware, > > > > or with GPUs predating Radeon and i915 will need to install > the > > > > graphics/drm-legacy-kmod. All other users should be able to > use > > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > > Note that this applies only to 12. > > > > > > I see that The removal of drm and drm2 has been reverted on svn. Could > > > you please kindly share the reasons behind the re-inclusion? > > > > > > > > > I can’t really give the blow by blow of internal project drama, but the > > gist of it is that “best practices” (which are not yet actually > documented > > anywhere that I’ve seen) were not followed with regards to the > deprecation > > process. Warner and others believe that we can address the objectives of > > the drm removal (improving the user experience and communicating that > > drm/drm2 are _completely_ unsupported apart from continuing to compile) > > through less disruptive means. > > > > Just so. > > Our only continued frustration is that we were never given any guidance by > > RE or core on said “best practices” when the discussion was taking place > in > > May and then those groups behaved as if this were a surprise when the > > removal happened. I’m cautiously optimistic that this well expedite > > improving communications on those matters. > > > > All the problems that are exposed by this aren't technical. This one is > social, but no less important. > > Warner > ___ > 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" > I've been watching this debacle for quite some time now and I'd just like to ask why the rush? The graphics team is working very hard to destroy the stability of FreeBSD just so that they can force their uncooked work down users throats. The Linuxkpi is unstable at best, alpha level software that's constantly in need of someone to go and fix something on FreeBSD because Linux devs decided to make some changes or implement a new feature. This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. Are these guys insane and please avoid the nonsense about you're doing this in your spare time. If you cannot devote the resources to do something right then don't do it at all. Keep that stuff in to yourself or anyone crazy enough to follow those steps to get it up and running, you guys cannot expect to contaminate the entire FreeBSD project for this mess. This is nonsense and I hope that more people who see it as such would say so and stop having these guys forcing this crap; it's maintenance hell who will maintain it if they decide to leave? Best, Owen ___ 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: ifnet use after free
On 25 Aug 2018, at 0:26, Matthew Macy wrote: On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: Hey All, Somewhere in the last month or so, a use after free was introduced. I don't have the time right now to bisect the commits and figure out which commit introduced the breakage. Attached is the core.txt (which seems nonsensical because the dump is reporting on a different thread). If the core.txt gets scrubbed, I've posted it here: https://gist.github.com/796ea88cec19a1fd2a85f4913482286a Do you have any guidance on how to reproduce? The hardenedbsd rev isn’t useful - the svn commit that it’s based against is what is needed. For what it’s worth, it’s not a hardenedbsd thing. I’ve been chasing the same one (same offset, same allocation size, same most recent user). Something gets set to zero/NULL. 8 bytes on amd64, so presumably a pointer. I currently only trigger it on a development branch, but I’ll see if I can clean that up into something I can share tomorrow. In my test scenario it happens after shutdown of a vnet jail with a few interfaces in it (including a pfsync interface which will disappear with the jail), and new jails are started. It’s pretty reliable. At a guess something’s wrong with the delayed cleanup of ifnets and vnet shutdown. Regards, Kristof ___ 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: ifnet use after free
On Fri, Aug 24, 2018 at 15:25 Shawn Webb wrote: > Hey All, > > Somewhere in the last month or so, a use after free was introduced. I > don't have the time right now to bisect the commits and figure out > which commit introduced the breakage. Attached is the core.txt (which > seems nonsensical because the dump is reporting on a different > thread). If the core.txt gets scrubbed, I've posted it here: > https://gist.github.com/796ea88cec19a1fd2a85f4913482286a > Do you have any guidance on how to reproduce? The hardenedbsd rev isn’t useful - the svn commit that it’s based against is what is needed. Thanks. -M > I'm running HardenedBSD 12-CURRENT/amd64, commit 6091fec317a. > > FreeBSD hbsd-dev-laptop 12.0-ALPHA2 FreeBSD 12.0-ALPHA2 #4 > 6091fec317a(hardened/current/master)-dirty: Thu Aug 23 18:37:45 EDT > 2018 > shawn@hbsd-dev-laptop:/usr/obj/usr/src/amd64.amd64/sys/LATT-SEC amd64 > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal:+1 443-546-8752 > Tor+XMPP+OTR:latt...@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > ___ 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: drm / drm2 removal in 12
On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > Just in case anyone misses the change to UPDATING: > > > > > > 20180821: > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > hardware, > > > or with GPUs predating Radeon and i915 will need to install the > > > graphics/drm-legacy-kmod. All other users should be able to use > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > Note that this applies only to 12. > > > > I see that The removal of drm and drm2 has been reverted on svn. Could > > you please kindly share the reasons behind the re-inclusion? > > > > > I can’t really give the blow by blow of internal project drama, but the > gist of it is that “best practices” (which are not yet actually documented > anywhere that I’ve seen) were not followed with regards to the deprecation > process. Warner and others believe that we can address the objectives of > the drm removal (improving the user experience and communicating that > drm/drm2 are _completely_ unsupported apart from continuing to compile) > through less disruptive means. > Just so. Our only continued frustration is that we were never given any guidance by > RE or core on said “best practices” when the discussion was taking place in > May and then those groups behaved as if this were a surprise when the > removal happened. I’m cautiously optimistic that this well expedite > improving communications on those matters. > All the problems that are exposed by this aren't technical. This one is social, but no less important. Warner ___ 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: drm / drm2 removal in 12
On Fri, Aug 24, 2018 at 14:53 Ali wrote: > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > Just in case anyone misses the change to UPDATING: > > > > 20180821: > > drm and drm2 have been removed. Users on powerpc, 32-bit > hardware, > > or with GPUs predating Radeon and i915 will need to install the > > graphics/drm-legacy-kmod. All other users should be able to use > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > Note that this applies only to 12. > > I see that The removal of drm and drm2 has been reverted on svn. Could > you please kindly share the reasons behind the re-inclusion? > I can’t really give the blow by blow of internal project drama, but the gist of it is that “best practices” (which are not yet actually documented anywhere that I’ve seen) were not followed with regards to the deprecation process. Warner and others believe that we can address the objectives of the drm removal (improving the user experience and communicating that drm/drm2 are _completely_ unsupported apart from continuing to compile) through less disruptive means. I am only acting as a lightning rod and representative of the graphics team and so have done an inadequate job of tracking their activities with respect to project timelines. As a result of this misunderstanding Johannes Lundberg will be sponsored for a bit and will be able to be involved in internal discussions that impact his work. Our only continued frustration is that we were never given any guidance by RE or core on said “best practices” when the discussion was taking place in May and then those groups behaved as if this were a surprise when the removal happened. I’m cautiously optimistic that this well expedite improving communications on those matters. Cheers. -M ___ 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: priority of paths to kernel modules?
On 08/24/18 17:20, Warner Losh wrote: This would allow the graphics port to have a rc script that sets this up so when X11 goes to automatically load the module, the right one gets loaded. I just want to point out that X11 doesn't load the graphics kernel driver by default when using the drm-*-kmod ports, and I'm not sure the hack to have the intel ddx (xf86-video-intel) load the drm2 driver is still around. It doesn't really matter though, since upstream is moving away from having X load the driver, and I'd like us to follow suit by using devmatch (this is one of the reasons we wanted to get rid of the base drivers, as I've stated before). X can't always know which driver to load (when using modesetting for instance), and in my opinion, it should be the kernel/loader that decides which drivers to load. Regards -- Niclas Zeising ___ 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: drm / drm2 removal in 12
On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > Just in case anyone misses the change to UPDATING: > > 20180821: > drm and drm2 have been removed. Users on powerpc, 32-bit hardware, > or with GPUs predating Radeon and i915 will need to install the > graphics/drm-legacy-kmod. All other users should be able to use > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > graphics/drm-next-kmod, graphics/drm-devel-kmod. > Note that this applies only to 12. I see that The removal of drm and drm2 has been reverted on svn. Could you please kindly share the reasons behind the re-inclusion? > ___ > 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Fri, Aug 24, 2018 at 10:32:06PM +0200, Michael Gmelin wrote: > > > > On 24. Aug 2018, at 21:59, Konstantin Belousov wrote: > > Please apply the following debugging patch on top of the previous 'fix'. > > You need debug.late_console=0. > > Unfortunately debug.late_console=0 doesn???t work on this machine (no more > output on the console), I tried that earlier in this thread - hence the > slightly complicated debugging code I had to add to see the contents of > physmap. > > I could run this code after boot (feeding it an identical physmap) to get > debug output, would this make sense? > Yes, with exactly the same physmap[]. Really, I do not need exactly the output from my patch, but just make it clear why is_kernel_paddr() did not triggered selection from different location. ___ 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
> On 24. Aug 2018, at 21:59, Konstantin Belousov wrote:
>
>> On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
>>
>>
On 22. Aug 2018, at 23:15, Konstantin Belousov wrote:
On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
>> On 22. Aug 2018, at 17:46, Konstantin Belousov
>> wrote:
>>
>> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>>
>>
On 20. Aug 2018, at 17:09, Konstantin Belousov
wrote:
On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
See here for a screenshot (also including the output of "show pte
0xf8000100"):
https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
>>> It is too early for ddb routines to register.
>>> Ok can you try the following debugging patch, to verify my guess ?
>>>
>>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
>>> index 18777d23f09..cd05fdb763f 100644
>>> --- a/sys/amd64/amd64/pmap.c
>>> +++ b/sys/amd64/amd64/pmap.c
>>> @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
>>> pd_p = (pd_entry_t *)DMPDkernphys;
>>> for (i = 0; i < (NPDEPG * nkdmpde); i++)
>>> pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
>>> -X86_PG_M | X86_PG_A | pg_nx |
>>> -bootaddr_rwx(i << PDRSHIFT);
>>> +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
>>> for (i = 0; i < nkdmpde; i++)
>>> pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
>>> X86_PG_V;
>>
>> With this change it boots okay (mptramp_pagetables is 0x100, as
>> expected).
>
> Can you apply the following on top of the previous debugging patch and
> show
> me the line printed ?
>
> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> index 3d70532b7fd..613fa9f2165 100644
> --- a/sys/amd64/amd64/pmap.c
> +++ b/sys/amd64/amd64/pmap.c
> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> pmap->pm_pcids[i].pm_gen = 1;
> }
> pmap_activate_boot(pmap);
> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx
> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL),
> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection,
> (uintptr_t)etext, (uintptr_t)KERNBASE);
> }
>
> void
bootaddr addr 0x100 rwx 0 btext 0x80342000 _end
0x823cf840 brwsection #81a0 etext 0x812041e4
KERNBASE 0x8000
>>>
>>> Try this, please. Revert all debugging pmap.c patches that I provided
>>> before.
>>>
>>> diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
>>> index 4ca2e07e578..2ee8f862854 100644
>>> --- a/sys/amd64/amd64/mp_machdep.c
>>> +++ b/sys/amd64/amd64/mp_machdep.c
>>> @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
>>>
>>> #define GiB(v)(v ## ULL << 30)
>>>
>>> +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
>>> +
>>> externstruct pcpu __pcpu[];
>>>
>>> /* Temporary variables for init_secondary() */
>>> @@ -101,45 +103,78 @@ char *dbg_stack;
>>>
>>> static intstart_ap(int apic_id);
>>>
>>> +static bool
>>> +is_kernel_paddr(vm_paddr_t pa)
>>> +{
>>> +
>>> +return (pa >= trunc_2mpage(btext - KERNBASE) &&
>>> + pa < round_page(_end - KERNBASE));
>>> +}
>>> +
>>> +static bool
>>> +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
>>> +{
>>> +
>>> +return (start + AP_BOOTPT_SZ <= GiB(4) &&
>>> +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
>>> +}
>>> +
>>> /*
>>> * Calculate usable address in base memory for AP trampoline code.
>>> */
>>> void
>>> mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
>>> {
>>> +vm_paddr_t start, end;
>>> unsigned int i;
>>> bool allocated;
>>>
>>> alloc_ap_trampoline(physmap, physmap_idx);
>>>
>>> +/*
>>> + * Find a memory region big enough below the 4GB boundary to
>>> + * store the initial page tables. Region must be mapped by
>>> + * the direct map.
>>> + *
>>> + * Note that it needs to be aligned to a page boundary.
>>> + */
>>> allocated = false;
>>> for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
>>> /*
>>> - * Find a memory region big enough below the 4GB
>>> - * boundary to store the initial page tables. Region
>>> - * must be mapped by the direct map.
>>> - *
>>> - * Note that it needs to be aligned to a page
>>> - * boundary.
>>> + * First, try to chomp at the start of the physmap region.
>>> + * Kernel binary might claim it already.
>>> + */
>>> +start = round_page(physmap[i]);
>>> +end = trunc_page(physmap[i + 1]);
>>> +if (is_mpboot_good(start, end) &&
Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Thu, Aug 23, 2018 at 12:10:34AM +0200, Michael Gmelin wrote:
>
>
> > On 22. Aug 2018, at 23:15, Konstantin Belousov wrote:
> >
> >> On Wed, Aug 22, 2018 at 10:03:54PM +0200, Michael Gmelin wrote:
> >>
> >>
> On 22. Aug 2018, at 17:46, Konstantin Belousov
> wrote:
>
> On Tue, Aug 21, 2018 at 12:14:35AM +0200, Michael Gmelin wrote:
>
>
> >> On 20. Aug 2018, at 17:09, Konstantin Belousov
> >> wrote:
> >>
> >> On Mon, Aug 20, 2018 at 12:45:12AM +0200, Michael Gmelin wrote:
> >>
> >> See here for a screenshot (also including the output of "show pte
> >> 0xf8000100"):
> >>
> >> https://gist.github.com/grembo/78d0f2a100dd4f16775b85a118769658#file-ddb1-png
> > It is too early for ddb routines to register.
> > Ok can you try the following debugging patch, to verify my guess ?
> >
> > diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> > index 18777d23f09..cd05fdb763f 100644
> > --- a/sys/amd64/amd64/pmap.c
> > +++ b/sys/amd64/amd64/pmap.c
> > @@ -1052,8 +1052,7 @@ create_pagetables(vm_paddr_t *firstaddr)
> > pd_p = (pd_entry_t *)DMPDkernphys;
> > for (i = 0; i < (NPDEPG * nkdmpde); i++)
> > pd_p[i] = (i << PDRSHIFT) | X86_PG_V | PG_PS | pg_g |
> > -X86_PG_M | X86_PG_A | pg_nx |
> > -bootaddr_rwx(i << PDRSHIFT);
> > +X86_PG_M | X86_PG_A | pg_nx | X86_PG_RW;
> > for (i = 0; i < nkdmpde; i++)
> > pdp_p[i] = (DMPDkernphys + ptoa(i)) | X86_PG_RW |
> > X86_PG_V;
>
> With this change it boots okay (mptramp_pagetables is 0x100, as
> expected).
> >>>
> >>> Can you apply the following on top of the previous debugging patch and
> >>> show
> >>> me the line printed ?
> >>>
> >>> diff --git a/sys/amd64/amd64/pmap.c b/sys/amd64/amd64/pmap.c
> >>> index 3d70532b7fd..613fa9f2165 100644
> >>> --- a/sys/amd64/amd64/pmap.c
> >>> +++ b/sys/amd64/amd64/pmap.c
> >>> @@ -2662,6 +2662,7 @@ pmap_pinit0(pmap_t pmap)
> >>> pmap->pm_pcids[i].pm_gen = 1;
> >>> }
> >>> pmap_activate_boot(pmap);
> >>> +printf("bootaddr addr %#lx rwx %#lx btext %#lx _end %#lx brwsection %#lx
> >>> etext %#lx KERNBASE %#lx\n", 0x100UL, bootaddr_rwx(0x100UL),
> >>> (uintptr_t)btext, (uintptr_t)_end, (uintptr_t)brwsection,
> >>> (uintptr_t)etext, (uintptr_t)KERNBASE);
> >>> }
> >>>
> >>> void
> >>
> >> bootaddr addr 0x100 rwx 0 btext 0x80342000 _end
> >> 0x823cf840 brwsection #81a0 etext 0x812041e4
> >> KERNBASE 0x8000
> >>
> >
> > Try this, please. Revert all debugging pmap.c patches that I provided
> > before.
> >
> > diff --git a/sys/amd64/amd64/mp_machdep.c b/sys/amd64/amd64/mp_machdep.c
> > index 4ca2e07e578..2ee8f862854 100644
> > --- a/sys/amd64/amd64/mp_machdep.c
> > +++ b/sys/amd64/amd64/mp_machdep.c
> > @@ -87,6 +87,8 @@ __FBSDID("$FreeBSD$");
> >
> > #define GiB(v)(v ## ULL << 30)
> >
> > +#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
> > +
> > externstruct pcpu __pcpu[];
> >
> > /* Temporary variables for init_secondary() */
> > @@ -101,45 +103,78 @@ char *dbg_stack;
> >
> > static intstart_ap(int apic_id);
> >
> > +static bool
> > +is_kernel_paddr(vm_paddr_t pa)
> > +{
> > +
> > +return (pa >= trunc_2mpage(btext - KERNBASE) &&
> > + pa < round_page(_end - KERNBASE));
> > +}
> > +
> > +static bool
> > +is_mpboot_good(vm_paddr_t start, vm_paddr_t end)
> > +{
> > +
> > +return (start + AP_BOOTPT_SZ <= GiB(4) &&
> > +end >= start + AP_BOOTPT_SZ && atop(end) < Maxmem);
> > +}
> > +
> > /*
> > * Calculate usable address in base memory for AP trampoline code.
> > */
> > void
> > mp_bootaddress(vm_paddr_t *physmap, unsigned int *physmap_idx)
> > {
> > +vm_paddr_t start, end;
> >unsigned int i;
> >bool allocated;
> >
> >alloc_ap_trampoline(physmap, physmap_idx);
> >
> > +/*
> > + * Find a memory region big enough below the 4GB boundary to
> > + * store the initial page tables. Region must be mapped by
> > + * the direct map.
> > + *
> > + * Note that it needs to be aligned to a page boundary.
> > + */
> >allocated = false;
> >for (i = *physmap_idx; i <= *physmap_idx; i -= 2) {
> >/*
> > - * Find a memory region big enough below the 4GB
> > - * boundary to store the initial page tables. Region
> > - * must be mapped by the direct map.
> > - *
> > - * Note that it needs to be aligned to a page
> > - * boundary.
> > + * First, try to chomp at the start of the physmap region.
> > + * Kernel binary might claim it already.
> > + */
> > +start = round_page(physmap[i]);
> > +end = trunc_page(physmap[i + 1]);
> > +if (is_mpboot_good(start, end) &&
> > +!is_kernel_paddr(start) &&
Re: priority of paths to kernel modules?
In message <1535127391.1488.23.ca...@freebsd.org>, Ian Lepore writes: > On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > > My idea, which I implemented locally and should probably create a > > phab review, was to ifdef DRM in modules/Makefile. We could do this > > too. Default not to build/install. > > > > This seems like the obvious fix. I thought the whole point of all this > is that we support drm2 on some platforms, but not x86 anymore. So to > me that implies not building the modules by default on x86. Then we limit it knob to only those platforms we wish to remove it from now. I suggested default off however in a private email I received it was intimated to me that default on for the first while would be better. Personally, I don't care about the minutia but I do care that we have some kind of migration roadmap. -- Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 5:43 PM Warner Losh wrote: > > > On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg > wrote: > >> There's some tricks we can do here. >>> >>> First, I talked to Kyle yesterday about augmenting the Lua loader to >>> have a X_loadflag option. Some background. We look at a lot of X_ flags >>> for loading modules. X_load=yes being the most familiar. One way to avoid >>> POLA would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so >>> that by default, we'd run load -K i915kms instead of load i915kms. We'd >>> augment the built-in load command so it knew that -K means 'add the kernel >>> to the path last rather than first'. This would solve one of the POLA >>> violations in a very targeted way: people that put i915kms_load=YES in >>> their loader.conf wouldn't be surprised by this transition. It would be at >>> the cost of 2 entires in loader.conf, I believe, and it shuts down one >>> vector of hassle for our users. People do this, btw, to get more lines / >>> columns in the BIOS boot environment for their console, so it's not an >>> unreasonable path to attend to. >>> >>> We could also have a sysctl that we could set to override specific >>> modules locations. This would allow the graphics port to have a rc script >>> that sets this up so when X11 goes to automatically load the module, the >>> right one gets loaded. This would solve the issue for the people that 'do >>> nothing' except install the port. While it's a small bit of programming for >>> the kernel, it's a general mechanism that's laser-focused on exceptions to >>> the rule w/o wholesale changes. This would solve the other main vector and >>> motivator for the 'kill it with fire' calls that doesn't leave behind a >>> scorched earth. >>> >> >> >> Just a small note here. With the modesetting driver (which is replacing >> the deprecated xf86-video-intel and is built into Xorg), X will not load >> the drm driver for you. It has to be done by putting kld_list="i915kms" in >> your rc.conf (I don't think loading drm next modules from /boot/loader.conf >> works). >> > > I have done this in the past, but I had to jump through a number of hoops > to do it. I'll have to buy a laptop and see if I can do it with modern gear > and modern software. > > But if X isn't loading the module for you, that makes the problem much, > much easier. > Yes for Intel+modesetting. I forgot to mention that for amdgpu and radeon, X might still do it. Need to test to confirm. However, there's nothing stopping you from loading it in rc.conf before starting X (which is probably better anyway). > Warner > ___ 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: priority of paths to kernel modules?
On Fri, 2018-08-24 at 08:35 -0700, Cy Schubert wrote: > My idea, which I implemented locally and should probably create a > phab review, was to ifdef DRM in modules/Makefile. We could do this > too. Default not to build/install. > This seems like the obvious fix. I thought the whole point of all this is that we support drm2 on some platforms, but not x86 anymore. So to me that implies not building the modules by default on x86. -- Ian > --- > Sent using a tiny phone keyboard. > Apologies for any typos and autocorrect. > Also, this old phone only supports top post. Apologies. > > Cy Schubert > or > The need of the many outweighs the greed of the few. > --- > > -Original Message- > From: Johannes Lundberg > Sent: 24/08/2018 01:08 > To: freebsd-current > Subject: priority of paths to kernel modules? > > Hi > > Since we now stuck with drm2 in base for a few more years I have an > idea > would make things much smoother for many of us, hugely reduce the > amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > module_path="/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm- > v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel > have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed > in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct > this is a > flaw and /boot/ should be inserted last so that any > overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and > you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > ___ > 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-unsubscr...@freebsd.org"
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 9:27 AM Johannes Lundberg wrote: > There's some tricks we can do here. >> >> First, I talked to Kyle yesterday about augmenting the Lua loader to have >> a X_loadflag option. Some background. We look at a lot of X_ flags for >> loading modules. X_load=yes being the most familiar. One way to avoid POLA >> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that >> by default, we'd run load -K i915kms instead of load i915kms. We'd augment >> the built-in load command so it knew that -K means 'add the kernel to the >> path last rather than first'. This would solve one of the POLA violations >> in a very targeted way: people that put i915kms_load=YES in their >> loader.conf wouldn't be surprised by this transition. It would be at the >> cost of 2 entires in loader.conf, I believe, and it shuts down one vector >> of hassle for our users. People do this, btw, to get more lines / columns >> in the BIOS boot environment for their console, so it's not an unreasonable >> path to attend to. >> >> We could also have a sysctl that we could set to override specific >> modules locations. This would allow the graphics port to have a rc script >> that sets this up so when X11 goes to automatically load the module, the >> right one gets loaded. This would solve the issue for the people that 'do >> nothing' except install the port. While it's a small bit of programming for >> the kernel, it's a general mechanism that's laser-focused on exceptions to >> the rule w/o wholesale changes. This would solve the other main vector and >> motivator for the 'kill it with fire' calls that doesn't leave behind a >> scorched earth. >> > > > Just a small note here. With the modesetting driver (which is replacing > the deprecated xf86-video-intel and is built into Xorg), X will not load > the drm driver for you. It has to be done by putting kld_list="i915kms" in > your rc.conf (I don't think loading drm next modules from /boot/loader.conf > works). > I have done this in the past, but I had to jump through a number of hoops to do it. I'll have to buy a laptop and see if I can do it with modern gear and modern software. But if X isn't loading the module for you, that makes the problem much, much easier. Warner ___ 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: priority of paths to kernel modules?
My idea, which I implemented locally and should probably create a phab review, was to ifdef DRM in modules/Makefile. We could do this too. Default not to build/install. --- Sent using a tiny phone keyboard. Apologies for any typos and autocorrect. Also, this old phone only supports top post. Apologies. Cy Schubert or The need of the many outweighs the greed of the few. --- -Original Message- From: Johannes Lundberg Sent: 24/08/2018 01:08 To: freebsd-current Subject: priority of paths to kernel modules? Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers ___ 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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 5:20 PM Warner Losh wrote:
>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
> freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
>> wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy
>> wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE
>> wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs
>> of RE
>> > > > and the graphics team + user base on post-2013 hardware - the
>> graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights
>> to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply
>> say we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>
>> Since we are in code freeze we could all go work on those things :-)
>>
>
> Yes. That's why I wanted all removals to wait until after the freeze so
> that I could get the deprecation policy hammered out better, including a
> common set of guidelines to know when to remove, when to disable, and how
> to ease things out of the tree in as a non-disruptive way as possible.
>
>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose
>> to have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>>
>
> There's some tricks we can do here.
>
> First, I talked to Kyle yesterday about augmenting the Lua loader to have
> a X_loadflag option. Some background. We look at a lot of X_ flags for
> loading modules. X_load=yes being the most familiar. One way to avoid POLA
> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
> the built-in load command so it knew that -K means 'add the kernel to the
> path last rather than first'. This would solve one of the POLA violations
> in a very targeted way: people that put i915kms_load=YES in their
> loader.conf wouldn't be surprised by this transition. It would be at the
> cost of 2 entires in loader.conf, I believe, and it shuts down one vector
> of hassle for our users. People do this, btw, to get more lines / columns
> in the BIOS boot environment for their console, so it's not an unreasonable
> path to attend to.
>
> We could also have a sysctl that we could set to override specific modules
> locations. This would allow the graphics port to have a rc script that sets
> this up so when X11 goes to automatically load the module, the right one
> gets loaded. This would solve the issue for the people that 'do nothing'
> except install the port. While it's a small bit of programming for the
> kernel, it's a general mechanism that's laser-focused on exceptions to the
> rule w/o wholesale changes. This would solve the other main vector and
> motivator for the 'kill it with fire' calls that doesn't leave behind a
> scorched earth.
>
Just a small note here. With the modesetting driver (which is replacing the
deprecated xf86-video-intel and is built into Xorg), X will not load the
drm driver for you. It has to be done by putting kld_list="i915kms" in your
rc.conf (I don't think loading drm next modules from /boot/loader.conf
works).
> The people that do nothing, not even install a graphics port, we might be
> able to 'poison pill' the drivers such that we fail the load hard enough
> X11 doesn't start, but with a clear error message about next steps. This is
> a bonus of leaving them in the tree: we would just have a silent failure
> otherwise as X11 tries to load i915kms.ko only to have no driver attach.
>
> > (Putting on my loader ballcap)
>> >
>> > I would like to change this after 12 branches to append by default and
>> > allow one to add ${kernel_path} to their module_path to override that,
>> > since the status quo has been such for 18 years and some may want to
>> > go back to that. I've personally been bitten by it a couple too many
>> > times to be happy with the current situation.
>> >
>> > (Takes off loader ballcap)
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 10:20 AM Warner Losh wrote:
>
>
>
> On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes
> wrote:
>>
>> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
>> > wrote:
>> > >
>> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
>> > >
>> > > > No we're not. x86 and PPC will be disconnected from the build in a
>> > > > subsequent commit during the freeze. Warner was simply too tired to
>> > > > communicate this adequately and still meet the timeline that RE wanted.
>> > > >
>> > > > And take heart. Even if Warner weren't trying to balance the needs of
>> > > > RE
>> > > > and the graphics team + user base on post-2013 hardware - the graphics
>> > > > doesn't _have_ to support 12.x. it's well within the team's rights to
>> > > > simply declare 12.x as unsupported. The team is welcome to simply say
>> > > > we
>> > > > support 11.x and 13.x. The failing was largely in that "expected"
>> > > > processes
>> > > > are not documented and not well communicated.
>>
>> The deprececation policy is documented, though poorly, and I agree in
>> the spirit that much of the processes here in the FreeBSD project are
>> sadly in a similiar situation.
>
>
> To say this is a learning situation for all those involved is not an
> understatement.
>
>>
>> Since we are in code freeze we could all go work on those things :-)
>
>
> Yes. That's why I wanted all removals to wait until after the freeze so that
> I could get the deprecation policy hammered out better, including a common
> set of guidelines to know when to remove, when to disable, and how to ease
> things out of the tree in as a non-disruptive way as possible.
>
>>
>> > > > Warner is acting in good faith. He's just trying to balance many
>> > > > demands
>> > > > in a compressed time period.
>> > > >
>> > > > Cheers.
>> > > > -M
>> > > >
>> > > >
>> > > OK, thanks for the clarification. That's a good compromise I guess.
>> > >
>> > > Still, regardless of drm, aren't modules in overlay folders suppose to
>> > > have
>> > > higher priority than those in the kernel folder?
>>
>> I agree, but usually do not depend on that to get what I need,
>> but rather resort to any special needs by force loading with
>> /boot/loader.conf modules that are loaded out of order.
>
>
> There's some tricks we can do here.
>
> First, I talked to Kyle yesterday about augmenting the Lua loader to have a
> X_loadflag option. Some background. We look at a lot of X_ flags for
> loading modules. X_load=yes being the most familiar. One way to avoid POLA
> would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
> by default, we'd run load -K i915kms instead of load i915kms. We'd augment
> the built-in load command so it knew that -K means 'add the kernel to the
> path last rather than first'. This would solve one of the POLA violations in
> a very targeted way: people that put i915kms_load=YES in their loader.conf
> wouldn't be surprised by this transition. It would be at the cost of 2
> entires in loader.conf, I believe, and it shuts down one vector of hassle for
> our users. People do this, btw, to get more lines / columns in the BIOS boot
> environment for their console, so it's not an unreasonable path to attend to.
>
> We could also have a sysctl that we could set to override specific modules
> locations. This would allow the graphics port to have a rc script that sets
> this up so when X11 goes to automatically load the module, the right one gets
> loaded. This would solve the issue for the people that 'do nothing' except
> install the port. While it's a small bit of programming for the kernel, it's
> a general mechanism that's laser-focused on exceptions to the rule w/o
> wholesale changes. This would solve the other main vector and motivator for
> the 'kill it with fire' calls that doesn't leave behind a scorched earth.
>
> The people that do nothing, not even install a graphics port, we might be
> able to 'poison pill' the drivers such that we fail the load hard enough X11
> doesn't start, but with a clear error message about next steps. This is a
> bonus of leaving them in the tree: we would just have a silent failure
> otherwise as X11 tries to load i915kms.ko only to have no driver attach.
>
>> > (Putting on my loader ballcap)
>> >
>> > I would like to change this after 12 branches to append by default and
>> > allow one to add ${kernel_path} to their module_path to override that,
>> > since the status quo has been such for 18 years and some may want to
>> > go back to that. I've personally been bitten by it a couple too many
>> > times to be happy with the current situation.
>> >
>> > (Takes off loader ballcap)
>>
>> I actually like this solution, it appears to be a win for everyone
>> and would make the road smoother in the future for similiar types
>> of things should they happen.
>
>
> Generally, things don't conflict. I like this notion for a number of reasons.
> It lets me have a 'driver disk'
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 8:13 AM Rodney W. Grimes <
freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote:
> > On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg
> wrote:
> > >
> > > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy
> wrote:
> > >
> > > > No we're not. x86 and PPC will be disconnected from the build in a
> > > > subsequent commit during the freeze. Warner was simply too tired to
> > > > communicate this adequately and still meet the timeline that RE
> wanted.
> > > >
> > > > And take heart. Even if Warner weren't trying to balance the needs
> of RE
> > > > and the graphics team + user base on post-2013 hardware - the
> graphics
> > > > doesn't _have_ to support 12.x. it's well within the team's rights to
> > > > simply declare 12.x as unsupported. The team is welcome to simply
> say we
> > > > support 11.x and 13.x. The failing was largely in that "expected"
> processes
> > > > are not documented and not well communicated.
>
> The deprececation policy is documented, though poorly, and I agree in
> the spirit that much of the processes here in the FreeBSD project are
> sadly in a similiar situation.
>
To say this is a learning situation for all those involved is not an
understatement.
> Since we are in code freeze we could all go work on those things :-)
>
Yes. That's why I wanted all removals to wait until after the freeze so
that I could get the deprecation policy hammered out better, including a
common set of guidelines to know when to remove, when to disable, and how
to ease things out of the tree in as a non-disruptive way as possible.
> > > > Warner is acting in good faith. He's just trying to balance many
> demands
> > > > in a compressed time period.
> > > >
> > > > Cheers.
> > > > -M
> > > >
> > > >
> > > OK, thanks for the clarification. That's a good compromise I guess.
> > >
> > > Still, regardless of drm, aren't modules in overlay folders suppose to
> have
> > > higher priority than those in the kernel folder?
>
> I agree, but usually do not depend on that to get what I need,
> but rather resort to any special needs by force loading with
> /boot/loader.conf modules that are loaded out of order.
>
There's some tricks we can do here.
First, I talked to Kyle yesterday about augmenting the Lua loader to have a
X_loadflag option. Some background. We look at a lot of X_ flags for
loading modules. X_load=yes being the most familiar. One way to avoid POLA
would be to have in boot/defaults/loader.conf a i915kms_loadflag=-K so that
by default, we'd run load -K i915kms instead of load i915kms. We'd augment
the built-in load command so it knew that -K means 'add the kernel to the
path last rather than first'. This would solve one of the POLA violations
in a very targeted way: people that put i915kms_load=YES in their
loader.conf wouldn't be surprised by this transition. It would be at the
cost of 2 entires in loader.conf, I believe, and it shuts down one vector
of hassle for our users. People do this, btw, to get more lines / columns
in the BIOS boot environment for their console, so it's not an unreasonable
path to attend to.
We could also have a sysctl that we could set to override specific modules
locations. This would allow the graphics port to have a rc script that sets
this up so when X11 goes to automatically load the module, the right one
gets loaded. This would solve the issue for the people that 'do nothing'
except install the port. While it's a small bit of programming for the
kernel, it's a general mechanism that's laser-focused on exceptions to the
rule w/o wholesale changes. This would solve the other main vector and
motivator for the 'kill it with fire' calls that doesn't leave behind a
scorched earth.
The people that do nothing, not even install a graphics port, we might be
able to 'poison pill' the drivers such that we fail the load hard enough
X11 doesn't start, but with a clear error message about next steps. This is
a bonus of leaving them in the tree: we would just have a silent failure
otherwise as X11 tries to load i915kms.ko only to have no driver attach.
> (Putting on my loader ballcap)
> >
> > I would like to change this after 12 branches to append by default and
> > allow one to add ${kernel_path} to their module_path to override that,
> > since the status quo has been such for 18 years and some may want to
> > go back to that. I've personally been bitten by it a couple too many
> > times to be happy with the current situation.
> >
> > (Takes off loader ballcap)
>
> I actually like this solution, it appears to be a win for everyone
> and would make the road smoother in the future for similiar types
> of things should they happen.
>
Generally, things don't conflict. I like this notion for a number of
reasons. It lets me have a 'driver disk' which can be placed first in the
load for install and not have to worry about naming. It also gives us more
flexibility for things in the future. The time to propose it, however, was
May so we could shake things out, so it's
Re: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 2:14 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > We're still trying to figure out that issue. I'd like to do this, but there's a lot of moving parts and objections that I need to plow through before it's a done deal. Expect further incremental steps. We already do not build in the kernel for x86 or powerpc, which gives us a lot more flexibility. The revert was a first step, not a final stop. > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > The graphics team doesn't have to support what's in the tree, at all. One of the things that we absolutely will be doing is putting in big scary notices saying that these drivers are deprecated, that you should be using the ports and to not expect any support and these drivers are present only as a transition. Other ideas that I'm exploring, is the notion of a poison pill for the in-tree drivers. So, we put all the IDs for the *NEW* cards into a driver (maybe the intel/radeon one, maybe a new one: there's pros and cons to each that need to be looked at). All this driver does is return a probe value that's tiny so it usually isn't accepted. But when it is, it prints a message saying "This card isn't supported by the in-tree driver. You must install the port" and fails to attach, which would fail X11 startup. Not completely ideal, but the X11 startup already fails with little clue and this would help. Warner is acting in good faith. He's just trying to balance many demands in > a compressed time period. > Yesterday, hours before Johannes' email went out, I was communicating with the Lua boot loader guy about ways we could change the path the boot loader users for certain modules and other such things to mitigate this problem. Warner > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > > > Hi > > > > Since we now stuck with drm2 in base for a few more years I have an idea > > would make things much smoother for many of us, hugely reduce the amount > of > > bug reports we get and I think would be beneficial in other ways too. > > > > Current I run with something like this in /boot/loader.conf > > > > > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > > > So I expect modules to be loaded in that order, with /boot/ > LAST. > > > > However, if you look at this > > sysctl kern.module_path > > kern.module_path: > > > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > > > /boot/kernel is inserted first and probably modules in /boot/kernel have > > the highest priority. This is also proven by everyone wanting to use > > drm*kmods that get drm.ko from base loaded instead of the installed in > > /boot/modules. > > > > Please correct me if I'm wrong but if my understanding is correct this > is a > > flaw and /boot/ should be inserted last so that any overlays or > > custom modules have higher priority than the default ones. > > > > I can imagine this is also useful when building custom modules and you > > don't want to overwrite or delete the default one in /boot/kernel... > > > > Cheers > > ___ > > 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" > ___ 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: priority of paths to kernel modules?
> On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote:
> >
> > On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
> >
> > > No we're not. x86 and PPC will be disconnected from the build in a
> > > subsequent commit during the freeze. Warner was simply too tired to
> > > communicate this adequately and still meet the timeline that RE wanted.
> > >
> > > And take heart. Even if Warner weren't trying to balance the needs of RE
> > > and the graphics team + user base on post-2013 hardware - the graphics
> > > doesn't _have_ to support 12.x. it's well within the team's rights to
> > > simply declare 12.x as unsupported. The team is welcome to simply say we
> > > support 11.x and 13.x. The failing was largely in that "expected"
> > > processes
> > > are not documented and not well communicated.
The deprececation policy is documented, though poorly, and I agree in
the spirit that much of the processes here in the FreeBSD project are
sadly in a similiar situation.
Since we are in code freeze we could all go work on those things :-)
> > > Warner is acting in good faith. He's just trying to balance many demands
> > > in a compressed time period.
> > >
> > > Cheers.
> > > -M
> > >
> > >
> > OK, thanks for the clarification. That's a good compromise I guess.
> >
> > Still, regardless of drm, aren't modules in overlay folders suppose to have
> > higher priority than those in the kernel folder?
I agree, but usually do not depend on that to get what I need,
but rather resort to any special needs by force loading with
/boot/loader.conf modules that are loaded out of order.
> (Putting on my loader ballcap)
>
> I would like to change this after 12 branches to append by default and
> allow one to add ${kernel_path} to their module_path to override that,
> since the status quo has been such for 18 years and some may want to
> go back to that. I've personally been bitten by it a couple too many
> times to be happy with the current situation.
>
> (Takes off loader ballcap)
I actually like this solution, it appears to be a win for everyone
and would make the road smoother in the future for similiar types
of things should they happen.
--
Rod Grimes rgri...@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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 3:22 AM Johannes Lundberg wrote:
>
> On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote:
>
> > No we're not. x86 and PPC will be disconnected from the build in a
> > subsequent commit during the freeze. Warner was simply too tired to
> > communicate this adequately and still meet the timeline that RE wanted.
> >
> > And take heart. Even if Warner weren't trying to balance the needs of RE
> > and the graphics team + user base on post-2013 hardware - the graphics
> > doesn't _have_ to support 12.x. it's well within the team's rights to
> > simply declare 12.x as unsupported. The team is welcome to simply say we
> > support 11.x and 13.x. The failing was largely in that "expected" processes
> > are not documented and not well communicated.
> >
> > Warner is acting in good faith. He's just trying to balance many demands
> > in a compressed time period.
> >
> > Cheers.
> > -M
> >
> >
> OK, thanks for the clarification. That's a good compromise I guess.
>
> Still, regardless of drm, aren't modules in overlay folders suppose to have
> higher priority than those in the kernel folder?
>
(Putting on my loader ballcap)
I would like to change this after 12 branches to append by default and
allow one to add ${kernel_path} to their module_path to override that,
since the status quo has been such for 18 years and some may want to
go back to that. I've personally been bitten by it a couple too many
times to be happy with the current situation.
(Takes off loader ballcap)
Thanks,
Kyle Evans
___
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: priority of paths to kernel modules?
On Fri, Aug 24, 2018 at 10:12 AM Matthew Macy wrote: > No we're not. x86 and PPC will be disconnected from the build in a > subsequent commit during the freeze. Warner was simply too tired to > communicate this adequately and still meet the timeline that RE wanted. > > And take heart. Even if Warner weren't trying to balance the needs of RE > and the graphics team + user base on post-2013 hardware - the graphics > doesn't _have_ to support 12.x. it's well within the team's rights to > simply declare 12.x as unsupported. The team is welcome to simply say we > support 11.x and 13.x. The failing was largely in that "expected" processes > are not documented and not well communicated. > > Warner is acting in good faith. He's just trying to balance many demands > in a compressed time period. > > Cheers. > -M > > OK, thanks for the clarification. That's a good compromise I guess. Still, regardless of drm, aren't modules in overlay folders suppose to have higher priority than those in the kernel folder? > > > > On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg > wrote: > >> Hi >> >> Since we now stuck with drm2 in base for a few more years I have an idea >> would make things much smoother for many of us, hugely reduce the amount >> of >> bug reports we get and I think would be beneficial in other ways too. >> >> Current I run with something like this in /boot/loader.conf >> >> >> module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" >> >> So I expect modules to be loaded in that order, with /boot/ >> LAST. >> >> However, if you look at this >> sysctl kern.module_path >> kern.module_path: >> >> /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays >> >> /boot/kernel is inserted first and probably modules in /boot/kernel have >> the highest priority. This is also proven by everyone wanting to use >> drm*kmods that get drm.ko from base loaded instead of the installed in >> /boot/modules. >> >> Please correct me if I'm wrong but if my understanding is correct this is >> a >> flaw and /boot/ should be inserted last so that any overlays or >> custom modules have higher priority than the default ones. >> >> I can imagine this is also useful when building custom modules and you >> don't want to overwrite or delete the default one in /boot/kernel... >> >> Cheers >> ___ >> 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: priority of paths to kernel modules?
No we're not. x86 and PPC will be disconnected from the build in a subsequent commit during the freeze. Warner was simply too tired to communicate this adequately and still meet the timeline that RE wanted. And take heart. Even if Warner weren't trying to balance the needs of RE and the graphics team + user base on post-2013 hardware - the graphics doesn't _have_ to support 12.x. it's well within the team's rights to simply declare 12.x as unsupported. The team is welcome to simply say we support 11.x and 13.x. The failing was largely in that "expected" processes are not documented and not well communicated. Warner is acting in good faith. He's just trying to balance many demands in a compressed time period. Cheers. -M On Fri, Aug 24, 2018 at 01:06 Johannes Lundberg wrote: > Hi > > Since we now stuck with drm2 in base for a few more years I have an idea > would make things much smoother for many of us, hugely reduce the amount of > bug reports we get and I think would be beneficial in other ways too. > > Current I run with something like this in /boot/loader.conf > > > module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" > > So I expect modules to be loaded in that order, with /boot/ LAST. > > However, if you look at this > sysctl kern.module_path > kern.module_path: > /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays > > /boot/kernel is inserted first and probably modules in /boot/kernel have > the highest priority. This is also proven by everyone wanting to use > drm*kmods that get drm.ko from base loaded instead of the installed in > /boot/modules. > > Please correct me if I'm wrong but if my understanding is correct this is a > flaw and /boot/ should be inserted last so that any overlays or > custom modules have higher priority than the default ones. > > I can imagine this is also useful when building custom modules and you > don't want to overwrite or delete the default one in /boot/kernel... > > Cheers > ___ > 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"
priority of paths to kernel modules?
Hi Since we now stuck with drm2 in base for a few more years I have an idea would make things much smoother for many of us, hugely reduce the amount of bug reports we get and I think would be beneficial in other ways too. Current I run with something like this in /boot/loader.conf module_path="/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays" So I expect modules to be loaded in that order, with /boot/ LAST. However, if you look at this sysctl kern.module_path kern.module_path: /boot/kernel;/boot/modules.drm-v4.16;/boot/modules;/boot/dtb;/boot/overlays /boot/kernel is inserted first and probably modules in /boot/kernel have the highest priority. This is also proven by everyone wanting to use drm*kmods that get drm.ko from base loaded instead of the installed in /boot/modules. Please correct me if I'm wrong but if my understanding is correct this is a flaw and /boot/ should be inserted last so that any overlays or custom modules have higher priority than the default ones. I can imagine this is also useful when building custom modules and you don't want to overwrite or delete the default one in /boot/kernel... Cheers ___ 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"
