Re: r336876 breaks sysutils/acpi_call
On Sat, Aug 25, 2018 at 11:51:21PM -0400, Theron wrote: > > A recent change in CURRENT has sysutils/acpi_call reliably cause a > kernel panic when run on a Dell XPS laptop system. I bisected this to > r336876: Use SMAP on amd64. I would have thought that this is a simple > compatibility problem requiring only a port update, except that the same > kernel and acpi_call on different hardware are not affected. On the > problematic system, the kernel module loads without incident; it is when > executing ACPI commands, even normally harmless operations such as > requesting read-only constants, that the system freeze occurs. ACPI > functionality seems otherwise unaffected. Does system freeze or panic ? I would expect the later. The fact that it occurs on some system and not another is encouraging and if my expectations are right, it fails on the system where SMAP is supported by hardware. If true, this means that this kernel module is already broken and accesses userspace directly without using copyin(9). Detecting such situations and stopping the system is the whole point of SMAP. > > Kernel debugging console and crash dumps are also broken on this system > (I suspect due to Intel graphics) however it is an unrelated problem, > and is only an excuse for my inability to provide any further crash > information. > > Having already bisected to the breaking commit, is there anything else I > should do to improve the chances this problem gets fixed, or are there > any hardware compatibility notes I may have missed? ___ 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"
r336876 breaks sysutils/acpi_call
A recent change in CURRENT has sysutils/acpi_call reliably cause a kernel panic when run on a Dell XPS laptop system. I bisected this to r336876: Use SMAP on amd64. I would have thought that this is a simple compatibility problem requiring only a port update, except that the same kernel and acpi_call on different hardware are not affected. On the problematic system, the kernel module loads without incident; it is when executing ACPI commands, even normally harmless operations such as requesting read-only constants, that the system freeze occurs. ACPI functionality seems otherwise unaffected. Kernel debugging console and crash dumps are also broken on this system (I suspect due to Intel graphics) however it is an unrelated problem, and is only an excuse for my inability to provide any further crash information. Having already bisected to the breaking commit, is there anything else I should do to improve the chances this problem gets fixed, or are there any hardware compatibility notes I may have missed? Theron ___ 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 Sun, Aug 26, 2018 at 10:51 AM cpghost wrote: > On 8/25/18 5:34 PM, Dave Cottlehuber wrote: > >> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen < > sh+freebsd-curr...@codevoid.de> > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > 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. > > > > Ditto. I'd like to express my heartfelt thanks for all the people who > have been > > working on the drm-next code for over 2 years now. It's fantastic and an > > incredible piece of effort to pull it all together. > > Same here. A big THANK YOU to the Graphics Team for drm-next. > I've been running it on STABLE with amdgpu driver on an RX 580 > at 4K res, and had ZERO issues with it so far... except for broken > opencl on drm-stable-kmod, but I can live with that until its fixed. > > > A+++ > > Dave > > -cpghost. > > > > There's a whole lot of cheerleading and that's wonderful keep it up. Enjoy building and applying your patches no one will take that away from you guys. Although the way you guys continually dodge, deflect and run away from 3 simple questions is astonishing, see below. You guys can keep on cheerleading but that still doesn't answer the questions that I have asked numerous time. Cheerleading does not solve engineering problems, it's just noise. I'll post this again to keep the focus on the issue at hand. If The Graphics team has already done these tests, show us. If The Graphics team has not, then maybe they should take some time to do the work required get the code submitted upstream. === 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base to create a port 3) update the working [test] system after applying your changes How does your changes affect a [test] system that is already up and running? Have any of you guys tried that? Do you have any documentation on how it'll affect users. You guys want to remove things from the current system but you come with; it works for us hobbyists. Where do users go to get steps to do all of this stuff? You've repeatedly said what you want to do sure, but have you tested it? ___ 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/25/18 5:34 PM, Dave Cottlehuber wrote: >> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > 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. > > Ditto. I'd like to express my heartfelt thanks for all the people who have > been > working on the drm-next code for over 2 years now. It's fantastic and an > incredible piece of effort to pull it all together. Same here. A big THANK YOU to the Graphics Team for drm-next. I've been running it on STABLE with amdgpu driver on an RX 580 at 4K res, and had ZERO issues with it so far... except for broken opencl on drm-stable-kmod, but I can live with that until its fixed. > A+++ > Dave -cpghost. smime.p7s Description: S/MIME Cryptographic Signature
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 07:22:06PM -0700, Randy Bush wrote: > plonk Indeed. I encourage everyone else to do the same. I'm far too old for proof-by-repetition. 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"
head -r338319 all_subdir_stand/i386/btx/btx use of -no-integrated-as and WITHOUT_BINUTILS_BOOTSTRAP= resulted in
Is head buildworld buildkernel supposed to work with: WITHOUT_BINUTILS_BOOTSTRAP= without providing an alternate binutils binding for clang to find? My attempt failed: --- buildworld --- make[1]: "/usr/src/Makefile.inc1" line 341: SYSTEM_COMPILER: Determined that CC=cc matches the source tree. Not bootstrapping a cross-compiler. make[1]: "/usr/src/Makefile.inc1" line 346: SYSTEM_LINKER: Determined that LD=ld matches the source tree. Not bootstrapping a cross-linker. --- buildworld_prologue --- . . . ===> stand/i386/btx (all) --- all_subdir_stand/i386/btx/btx --- ===> stand/i386/btx/btx (all) Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx.o . . . --- all_subdir_stand --- --- btx.o --- cc: error: unable to execute command: Executable "as" doesn't exist! cc: error: assembler command failed with exit code 1 (use -v to see invocation) --- all_subdir_share --- Building /usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/share/i18n/esdb/ISO646/ISO646-SE.esdb --- all_subdir_stand --- *** [btx.o] Error code 1 make[6]: stopped in /usr/src/stand/i386/btx/btx .ERROR_TARGET='btx.o' .ERROR_META_FILE='/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx/btx.o.meta' .MAKE.LEVEL='6' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' _ERROR_CMD='cc -target x86_64-unknown-freebsd12.0 --sysroot=/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp -B/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin -O2 -pipe -I/usr/src/stand/i386/btx/lib -nostdinc -I/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/libsa32 -I/usr/src/stand/libsa -D_STANDALONE -I/usr/src/sys -Ddouble=jagged-little-pill -Dfloat=floaty-mcfloatface -DLOADER_GELI_SUPPORT -I/usr/src/stand/libsa/geli -DLOADER_DISK_SUPPORT -m32 -ffreestanding -mno-mmx -mno-sse -mno-avx -mno-avx2 -msoft-float -march=i386 -I. -DBTX_FLAGS=0x0 -I/usr/src/stand/i386/common -std=gnu99 -Wsystem-headers -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Wno-parentheses -Oz -Qunused-arguments -no-int egrated-as -c /usr/src/stand/i386/btx/btx/btx.S -o btx.o; ;' .CURDIR='/usr/src/stand/i386/btx/btx' .MAKE='make' .OBJDIR='/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/stand/i386/btx/btx' .TARGETS='all' DESTDIR='/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20180512' PATH='/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/usr/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/legacy/bin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/sbin:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/tmp/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /root/src.configs/src.conf.amd64-clang.amd64-host /usr/src/share/mk/bsd.mkopt.mk /usr/src/share/mk/src.sys.obj.mk /usr/src/share/mk/auto.obj.mk /usr/src/share/mk/bsd.suffixes.mk /root/src.configs/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /dev/null /usr/src/stand/i386/btx/btx/Makefile /usr/src/share/mk/bsd.init.mk /usr/src/share/mk/bsd.opts.mk /usr/src/share/mk/bsd.cpu.mk /usr/src/share/mk/local.init.mk /usr/src/share/mk/src.init.mk /usr/src/stand/i386/btx/btx/../Makefile.inc /usr/src/stand/i386/btx/btx/../../Makefile.inc /usr/src/stand/i386/btx/btx/../../../Makefile.inc /usr/src/stand/i386/btx/btx/../../../defs.mk /usr/src/share/mk/src.opts.mk /usr/src/share/mk/bsd.own.mk /usr/src/share/mk/bsd.compiler.mk /usr/src/share/mk/bsd.linker.mk /usr/src/share/mk/bsd.prog.mk /usr/src/share/mk/bsd.libnames.mk /usr/src/share/mk/src.libnames.mk /usr/src/share/ mk/bsd.nls.mk /usr/src/share/mk/bsd.confs.mk /usr/src/share/mk/bsd.files.mk /usr/src/share/mk/bsd.dirs.mk /usr/src/share/mk/bsd.incs.mk /usr/src/share/mk/bsd.links.mk /usr/src/share/mk/bsd.man.mk /usr/src/share/mk/bsd.dep.mk /usr/src/share/mk/bsd.clang-analyze.mk /usr/src/share/mk/bsd.obj.mk /usr/src/share/mk/bsd.subdir.mk /usr/src/share/mk/bsd.sys.mk' .PATH='. /usr/src/stand/i386/btx/btx' 1 error For reference: examples of -no-integrated-as (and CLANG_NO_IAS/CLANG_NO_IAS34) . . . # grep -r "\-no-integrated-as" /usr/src/ | grep -v "/\.svn/" | more /usr/src/share/mk/bsd.sys.mk:CLANG_NO_IAS= -no-integrated-as /usr/src/contrib/llvm/tools/clang/include/clang/Frontend/CodeGenOptions.def:CODEGENOPT(DisableIntegratedAS, 1, 0) ///<
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 10:05 AM Allan Jude wrote: > On 2018-08-25 21:20, blubee blubeeme wrote: > > On Sun, Aug 26, 2018 at 9:08 AM Paul McNary wrote: > > > >> I think you can pay XinuOS to support FreeBSD in a LTS situation. > >> It is just like linux where you have to pay Red Hat, Suse, etc. > >> They break things even with point releases. Suse majorly > >> screwed with video drivers back in the 9.x series. Totally > >> broke major release. Their answer then was pay us or > >> re-install bare metal and figure it out on your own. > >> Other wise linux has always been, you get what you get for free. > >> BSD is the same. If you are lucky some one like red hat, suse, XinuOS > >> will be supporting and make their notes public, otherwise the > >> OSS model doesn't include anything more than community support > >> for what ever that is worth. > >> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and > >> several incremental upgrades sometimes to multiple point releases > >> with in a major release. There is nothing really for free. > >> > >> > >> On 8/25/2018 7:47 PM, blubee blubeeme wrote: > >>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg > >>> wrote: > >>> > > On Sun, Aug 26, 2018 at 00:25 blubee blubeeme > >> wrote: > > > On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav > >> wrote: > > > >> blubee blubeeme writes: > >>> True on both points my tone is just a reflection of attitudes of > the > >>> individuals that I am currently addressing. > >> Well, congratulations on alienating absolutely everybody you have > >> interacted with on this topic. > >> > >>> Some people enjoy making contributions w/o waving a banner > constantly > >>> wanting acknowledgement, a pat on the head and good job from > >> everyone. > >> The only person I see constantly craving attention and validation > from > >> others here is you. > >> > >>> How far will core FreeBSD bend over backwards to accommodate these > >>> devs. > >> The core team does not decide what goes into the tree or not. The > >> developers do. > >> > >>> This is the beauty of an open source project, we bring the best to > >> the > >>> table, [...] > >> Who exactly is “we” here? You are not a member of the project, you > do > >> not speak for the project, and after seeing how you treat our fellow > >> developers, our friends, most of us want nothing to do with you. If > >> can't live with that, I'm sure you can figure out how to install > >> Linux. > >> > >> DES > >> -- > >> Dag-Erling Smørgrav - d...@des.no > > > > Some on here want to attack my personality because they think that I > am > > abrasive, fine but that's not the issue. > > > > Some claim that they run the code and it works wonderful for them > with > >> no > > issues, again that's lovely keep on running the code. > > > > Nevertheless let me restate the point that you guys are all seeming > >> to > > miss; If you can go out and build custom kernels with custom options > >> and > > out of mainline tree that's fine, keep doing that until you have > >> something > > that's production ready and as easy to install as the rest of FreeBSD > > system. > > > > The graphics stack on FreeBSD is pretty bad as it stands but all the > > documentation currently out there is about using it as it stands now. > > > > Why do you need to rip out the current graphics drivers which will > >> break > > systems for the vast majority of silent users who will not complain > and > > just leave? > > > > A little background > > Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never > update > > their phones to the latest android version? > > > > It's because the Linux kernel is such a mess they know it's a waste > of > > resources to try. You should not have to ask how or why I know this > >> but if > > it's unclear I was in the field. > > --- > > > > Now you guys who claim to only be hobbyist doing this in their free > >> time > > expect to maintain this when those companies with all their resources > > cannot? > > > > Those 30,000 ports many of them bring bugs with them because of this > > Linuxkpi stuff. Just recently there was a user who said google earth > > doesn't work the answer was it doesn't work and that's that. > > > > They get ported and then get dropped so while the ports tree is > large, > >> if > > you actually try to use some of those programs they are broken, > > maintenance > > hell for the developers and confusion for the users. > > > > Johannes Lundberg I know that you are one of the main working on this > > linuxkpi stuff but anyone else is free to answer as well. > > > > Let's have an open discussion why do you
Re: drm / drm2 removal in 12
> I'll just post this again to try and keep the focus on the issue at hand. plonk ___ 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
I think you can pay XinuOS to support FreeBSD in a LTS situation. It is just like linux where you have to pay Red Hat, Suse, etc. They break things even with point releases. Suse majorly screwed with video drivers back in the 9.x series. Totally broke major release. Their answer then was pay us or re-install bare metal and figure it out on your own. Other wise linux has always been, you get what you get for free. BSD is the same. If you are lucky some one like red hat, suse, XinuOS will be supporting and make their notes public, otherwise the OSS model doesn't include anything more than community support for what ever that is worth. I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and several incremental upgrades sometimes to multiple point releases with in a major release. There is nothing really for free. On 8/25/2018 7:47 PM, blubee blubeeme wrote: On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg wrote: On Sun, Aug 26, 2018 at 00:25 blubee blubeeme wrote: On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: blubee blubeeme writes: True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. How far will core FreeBSD bend over backwards to accommodate these devs. The core team does not decide what goes into the tree or not. The developers do. This is the beauty of an open source project, we bring the best to the table, [...] Who exactly is “we” here? You are not a member of the project, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES -- Dag-Erling Smørgrav - d...@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? A little background Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. --- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work? This has been discussed over and over on the mailing list and I don’t think anyone wants to do it over again so please feel free to search the archives. You’re misinformed. We are not removing anything for anyone. We are moving it to ports. “pkg install drm-legacy-kmod” will install those drivers for you that were earlier in base. I thought we have been clear about this but maybe we haven’t been clear enough. ___ 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 " Have you or anyone working on this drm-legacy-kmod stuff done any testings of how this will affect current users? 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base
Re: drm / drm2 removal in 12
On 2018-08-25 21:20, blubee blubeeme wrote: > On Sun, Aug 26, 2018 at 9:08 AM Paul McNary wrote: > >> I think you can pay XinuOS to support FreeBSD in a LTS situation. >> It is just like linux where you have to pay Red Hat, Suse, etc. >> They break things even with point releases. Suse majorly >> screwed with video drivers back in the 9.x series. Totally >> broke major release. Their answer then was pay us or >> re-install bare metal and figure it out on your own. >> Other wise linux has always been, you get what you get for free. >> BSD is the same. If you are lucky some one like red hat, suse, XinuOS >> will be supporting and make their notes public, otherwise the >> OSS model doesn't include anything more than community support >> for what ever that is worth. >> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and >> several incremental upgrades sometimes to multiple point releases >> with in a major release. There is nothing really for free. >> >> >> On 8/25/2018 7:47 PM, blubee blubeeme wrote: >>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg >>> wrote: >>> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme >> wrote: > On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav >> wrote: > >> blubee blubeeme writes: >>> True on both points my tone is just a reflection of attitudes of the >>> individuals that I am currently addressing. >> Well, congratulations on alienating absolutely everybody you have >> interacted with on this topic. >> >>> Some people enjoy making contributions w/o waving a banner constantly >>> wanting acknowledgement, a pat on the head and good job from >> everyone. >> The only person I see constantly craving attention and validation from >> others here is you. >> >>> How far will core FreeBSD bend over backwards to accommodate these >>> devs. >> The core team does not decide what goes into the tree or not. The >> developers do. >> >>> This is the beauty of an open source project, we bring the best to >> the >>> table, [...] >> Who exactly is “we” here? You are not a member of the project, you do >> not speak for the project, and after seeing how you treat our fellow >> developers, our friends, most of us want nothing to do with you. If >> can't live with that, I'm sure you can figure out how to install >> Linux. >> >> DES >> -- >> Dag-Erling Smørgrav - d...@des.no > > Some on here want to attack my personality because they think that I am > abrasive, fine but that's not the issue. > > Some claim that they run the code and it works wonderful for them with >> no > issues, again that's lovely keep on running the code. > > Nevertheless let me restate the point that you guys are all seeming >> to > miss; If you can go out and build custom kernels with custom options >> and > out of mainline tree that's fine, keep doing that until you have >> something > that's production ready and as easy to install as the rest of FreeBSD > system. > > The graphics stack on FreeBSD is pretty bad as it stands but all the > documentation currently out there is about using it as it stands now. > > Why do you need to rip out the current graphics drivers which will >> break > systems for the vast majority of silent users who will not complain and > just leave? > > A little background > Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update > their phones to the latest android version? > > It's because the Linux kernel is such a mess they know it's a waste of > resources to try. You should not have to ask how or why I know this >> but if > it's unclear I was in the field. > --- > > Now you guys who claim to only be hobbyist doing this in their free >> time > expect to maintain this when those companies with all their resources > cannot? > > Those 30,000 ports many of them bring bugs with them because of this > Linuxkpi stuff. Just recently there was a user who said google earth > doesn't work the answer was it doesn't work and that's that. > > They get ported and then get dropped so while the ports tree is large, >> if > you actually try to use some of those programs they are broken, > maintenance > hell for the developers and confusion for the users. > > Johannes Lundberg I know that you are one of the main working on this > linuxkpi stuff but anyone else is free to answer as well. > > Let's have an open discussion why do you need to remove the current > graphics stack to continue with your work? This has been discussed over and over on the mailing list and I don’t think anyone wants to do it over again so please feel free to search the archives. You’re misinformed. We are not removing
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 9:08 AM Paul McNary wrote: > I think you can pay XinuOS to support FreeBSD in a LTS situation. > It is just like linux where you have to pay Red Hat, Suse, etc. > They break things even with point releases. Suse majorly > screwed with video drivers back in the 9.x series. Totally > broke major release. Their answer then was pay us or > re-install bare metal and figure it out on your own. > Other wise linux has always been, you get what you get for free. > BSD is the same. If you are lucky some one like red hat, suse, XinuOS > will be supporting and make their notes public, otherwise the > OSS model doesn't include anything more than community support > for what ever that is worth. > I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and > several incremental upgrades sometimes to multiple point releases > with in a major release. There is nothing really for free. > > > On 8/25/2018 7:47 PM, blubee blubeeme wrote: > > On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg > > wrote: > > > >> > >> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme > wrote: > >> > >>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav > wrote: > >>> > blubee blubeeme writes: > > True on both points my tone is just a reflection of attitudes of the > > individuals that I am currently addressing. > Well, congratulations on alienating absolutely everybody you have > interacted with on this topic. > > > Some people enjoy making contributions w/o waving a banner constantly > > wanting acknowledgement, a pat on the head and good job from > everyone. > The only person I see constantly craving attention and validation from > others here is you. > > > How far will core FreeBSD bend over backwards to accommodate these > > devs. > The core team does not decide what goes into the tree or not. The > developers do. > > > This is the beauty of an open source project, we bring the best to > the > > table, [...] > Who exactly is “we” here? You are not a member of the project, you do > not speak for the project, and after seeing how you treat our fellow > developers, our friends, most of us want nothing to do with you. If > can't live with that, I'm sure you can figure out how to install > Linux. > > DES > -- > Dag-Erling Smørgrav - d...@des.no > >>> > >>> Some on here want to attack my personality because they think that I am > >>> abrasive, fine but that's not the issue. > >>> > >>> Some claim that they run the code and it works wonderful for them with > no > >>> issues, again that's lovely keep on running the code. > >>> > >>> Nevertheless let me restate the point that you guys are all seeming > to > >>> miss; If you can go out and build custom kernels with custom options > and > >>> out of mainline tree that's fine, keep doing that until you have > something > >>> that's production ready and as easy to install as the rest of FreeBSD > >>> system. > >>> > >>> The graphics stack on FreeBSD is pretty bad as it stands but all the > >>> documentation currently out there is about using it as it stands now. > >>> > >>> Why do you need to rip out the current graphics drivers which will > break > >>> systems for the vast majority of silent users who will not complain and > >>> just leave? > >>> > >>> A little background > >>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update > >>> their phones to the latest android version? > >>> > >>> It's because the Linux kernel is such a mess they know it's a waste of > >>> resources to try. You should not have to ask how or why I know this > but if > >>> it's unclear I was in the field. > >>> --- > >>> > >>> Now you guys who claim to only be hobbyist doing this in their free > time > >>> expect to maintain this when those companies with all their resources > >>> cannot? > >>> > >>> Those 30,000 ports many of them bring bugs with them because of this > >>> Linuxkpi stuff. Just recently there was a user who said google earth > >>> doesn't work the answer was it doesn't work and that's that. > >>> > >>> They get ported and then get dropped so while the ports tree is large, > if > >>> you actually try to use some of those programs they are broken, > >>> maintenance > >>> hell for the developers and confusion for the users. > >>> > >>> Johannes Lundberg I know that you are one of the main working on this > >>> linuxkpi stuff but anyone else is free to answer as well. > >>> > >>> Let's have an open discussion why do you need to remove the current > >>> graphics stack to continue with your work? > >> > >> This has been discussed over and over on the mailing list and I don’t > >> think anyone wants to do it over again so please feel free to search the > >> archives. > >> > >> You’re misinformed. We are not removing anything for anyone. We are > moving > >> it to ports. > >> “pkg install
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg wrote: > > > On Sun, Aug 26, 2018 at 00:25 blubee blubeeme wrote: > >> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: >> >> > blubee blubeeme writes: >> > > True on both points my tone is just a reflection of attitudes of the >> > > individuals that I am currently addressing. >> > >> > Well, congratulations on alienating absolutely everybody you have >> > interacted with on this topic. >> > >> > > Some people enjoy making contributions w/o waving a banner constantly >> > > wanting acknowledgement, a pat on the head and good job from everyone. >> > >> > The only person I see constantly craving attention and validation from >> > others here is you. >> > >> > > How far will core FreeBSD bend over backwards to accommodate these >> > > devs. >> > >> > The core team does not decide what goes into the tree or not. The >> > developers do. >> > >> > > This is the beauty of an open source project, we bring the best to the >> > > table, [...] >> > >> > Who exactly is “we” here? You are not a member of the project, you do >> > not speak for the project, and after seeing how you treat our fellow >> > developers, our friends, most of us want nothing to do with you. If >> > can't live with that, I'm sure you can figure out how to install Linux. >> > >> > DES >> > -- >> > Dag-Erling Smørgrav - d...@des.no >> >> >> Some on here want to attack my personality because they think that I am >> abrasive, fine but that's not the issue. >> >> Some claim that they run the code and it works wonderful for them with no >> issues, again that's lovely keep on running the code. >> >> Nevertheless let me restate the point that you guys are all seeming to >> miss; If you can go out and build custom kernels with custom options and >> out of mainline tree that's fine, keep doing that until you have something >> that's production ready and as easy to install as the rest of FreeBSD >> system. >> >> The graphics stack on FreeBSD is pretty bad as it stands but all the >> documentation currently out there is about using it as it stands now. >> >> Why do you need to rip out the current graphics drivers which will break >> systems for the vast majority of silent users who will not complain and >> just leave? >> >> A little background >> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update >> their phones to the latest android version? >> >> It's because the Linux kernel is such a mess they know it's a waste of >> resources to try. You should not have to ask how or why I know this but if >> it's unclear I was in the field. >> --- >> >> Now you guys who claim to only be hobbyist doing this in their free time >> expect to maintain this when those companies with all their resources >> cannot? >> >> Those 30,000 ports many of them bring bugs with them because of this >> Linuxkpi stuff. Just recently there was a user who said google earth >> doesn't work the answer was it doesn't work and that's that. >> >> They get ported and then get dropped so while the ports tree is large, if >> you actually try to use some of those programs they are broken, >> maintenance >> hell for the developers and confusion for the users. >> >> Johannes Lundberg I know that you are one of the main working on this >> linuxkpi stuff but anyone else is free to answer as well. >> >> Let's have an open discussion why do you need to remove the current >> graphics stack to continue with your work? > > > This has been discussed over and over on the mailing list and I don’t > think anyone wants to do it over again so please feel free to search the > archives. > > You’re misinformed. We are not removing anything for anyone. We are moving > it to ports. > “pkg install drm-legacy-kmod” will install those drivers for you that were > earlier in base. I thought we have been clear about this but maybe we > haven’t been clear enough. > > > >> ___ >> 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 >> " >> > Have you or anyone working on this drm-legacy-kmod stuff done any testings of how this will affect current users? 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base to create a port 3) update the working [test] system after applying your changes How does your changes affect a [test] system that is already up and running? Have any of you guys tried that? Do you have any documentation on how it'll affect users. You guys want to remove things from the current system but you come with; it works for us hobbyists. Where do users go to get steps to do all of this stuff? You've repeatedly said what you want to do sure, but have you tested it? ___
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 00:25 blubee blubeeme wrote: > On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: > > > blubee blubeeme writes: > > > True on both points my tone is just a reflection of attitudes of the > > > individuals that I am currently addressing. > > > > Well, congratulations on alienating absolutely everybody you have > > interacted with on this topic. > > > > > Some people enjoy making contributions w/o waving a banner constantly > > > wanting acknowledgement, a pat on the head and good job from everyone. > > > > The only person I see constantly craving attention and validation from > > others here is you. > > > > > How far will core FreeBSD bend over backwards to accommodate these > > > devs. > > > > The core team does not decide what goes into the tree or not. The > > developers do. > > > > > This is the beauty of an open source project, we bring the best to the > > > table, [...] > > > > Who exactly is “we” here? You are not a member of the project, you do > > not speak for the project, and after seeing how you treat our fellow > > developers, our friends, most of us want nothing to do with you. If > > can't live with that, I'm sure you can figure out how to install Linux. > > > > DES > > -- > > Dag-Erling Smørgrav - d...@des.no > > > Some on here want to attack my personality because they think that I am > abrasive, fine but that's not the issue. > > Some claim that they run the code and it works wonderful for them with no > issues, again that's lovely keep on running the code. > > Nevertheless let me restate the point that you guys are all seeming to > miss; If you can go out and build custom kernels with custom options and > out of mainline tree that's fine, keep doing that until you have something > that's production ready and as easy to install as the rest of FreeBSD > system. > > The graphics stack on FreeBSD is pretty bad as it stands but all the > documentation currently out there is about using it as it stands now. > > Why do you need to rip out the current graphics drivers which will break > systems for the vast majority of silent users who will not complain and > just leave? > > A little background > Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update > their phones to the latest android version? > > It's because the Linux kernel is such a mess they know it's a waste of > resources to try. You should not have to ask how or why I know this but if > it's unclear I was in the field. > --- > > Now you guys who claim to only be hobbyist doing this in their free time > expect to maintain this when those companies with all their resources > cannot? > > Those 30,000 ports many of them bring bugs with them because of this > Linuxkpi stuff. Just recently there was a user who said google earth > doesn't work the answer was it doesn't work and that's that. > > They get ported and then get dropped so while the ports tree is large, if > you actually try to use some of those programs they are broken, maintenance > hell for the developers and confusion for the users. > > Johannes Lundberg I know that you are one of the main working on this > linuxkpi stuff but anyone else is free to answer as well. > > Let's have an open discussion why do you need to remove the current > graphics stack to continue with your work? This has been discussed over and over on the mailing list and I don’t think anyone wants to do it over again so please feel free to search the archives. You’re misinformed. We are not removing anything for anyone. We are moving it to ports. “pkg install drm-legacy-kmod” will install those drivers for you that were earlier in base. I thought we have been clear about this but maybe we haven’t been clear enough. > ___ > 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: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: > blubee blubeeme writes: > > True on both points my tone is just a reflection of attitudes of the > > individuals that I am currently addressing. > > Well, congratulations on alienating absolutely everybody you have > interacted with on this topic. > > > Some people enjoy making contributions w/o waving a banner constantly > > wanting acknowledgement, a pat on the head and good job from everyone. > > The only person I see constantly craving attention and validation from > others here is you. > > > How far will core FreeBSD bend over backwards to accommodate these > > devs. > > The core team does not decide what goes into the tree or not. The > developers do. > > > This is the beauty of an open source project, we bring the best to the > > table, [...] > > Who exactly is “we” here? You are not a member of the project, you do > not speak for the project, and after seeing how you treat our fellow > developers, our friends, most of us want nothing to do with you. If > can't live with that, I'm sure you can figure out how to install Linux. > > DES > -- > Dag-Erling Smørgrav - d...@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? A little background Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. --- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work? ___ 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: issues with usb mouse detection on 12.0-ALPHA3
On 8/25/18 11:51 AM, Warner Losh wrote: On Sat, Aug 25, 2018, 12:17 PM Pete Wright wrote: On 8/25/18 11:10 AM, Yuri Pankov wrote: Pete Wright wrote: howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. d'oh - didn't even think to check bugzilla. Just committed a change to devmatch. It looks like I committed from the wrong tree, dropping a new line.:( Warner thanks! yep that fix 'er up on my end. initially i thought it didn't work because i had only installed an updated kernel. once i realized my mistake, rebuilding devmatch with your latest patch applied fixed everything up. cheers! -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: nvidia-driver build error (last ports, FreeBSD-HEAD)
On 08/22/2018 10:29, Alan Cox wrote: > On 08/22/2018 08:48, tech-lists wrote: >> On 22/08/2018 05:29, Manfred Antar wrote: On Aug 21, 2018, at 7:23 PM, Alexey Dokuchaev wrote: On Tue, Aug 21, 2018 at 11:22:56PM +0700, Alex V. Petrov wrote: > Перенаправленное сообщение > Тема: nvidia-driver build error (last ports, FreeBSD-HEAD) > Дата: Tue, 21 Aug 2018 16:41:42 +0700 > От: Alex V. Petrov > Кому: FreeBSD Ports Should be fixed as of r477761. ./danfe >> It's not fixed, seems to error elsewhere now: >> >> context: 12.0-ALPHA1 #0 r337886 / ports r477782 / empty /etc/make.conf >> >> This is a bare metal installation. >> >> root@desktop:/usr/ports/x11/nvidia-driver# make distclean && make >> clean && make MAKE_JOBS_UNSAFE=yes >> >> [...] >> >> cc -O2 -pipe -fno-strict-aliasing -DNV_VERSION_STRING=\"390.77\" >> -D__KERNEL__ -DNVRM -Wno-unused-function -Wuninitialized -O2 >> -fno-strict-aliasing -mno-red-zone -mcmodel=kernel -Wno-sign-compare >> -Wno-format-extra-args -UDEBUG -U_DEBUG -DNDEBUG -Werror=undef >> -Werror -D_KERNEL -DKLD_MODULE -nostdinc -I. -I../common/inc -I. >> -I/usr/src/sys -I/usr/src/sys/contrib/ck/include -fno-common >> -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -MD >> -MF.depend.nvidia_subr.o -MTnvidia_subr.o -mcmodel=kernel >> -mno-red-zone -mno-mmx -mno-sse -msoft-float >> -fno-asynchronous-unwind-tables -ffreestanding -fwrapv >> -fstack-protector -Wall -Wredundant-decls -Wnested-externs >> -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Wcast-qual >> -Wundef -Wno-pointer-sign -D__printf__=__freebsd_kprintf__ >> -Wmissing-include-dirs -fdiagnostics-show-option -Wno-unknown-pragmas >> -Wno-error-tautological-compare -Wno-error-empty-body >> -Wno-error-parentheses-equality -Wno-error-unused-function >> -Wno-error-pointer-sign -Wno-error-shift-negative-value >> -Wno-address-of-packed-member -mno-aes -mno-avx -std=iso9899:1999 -c >> nvidia_subr.c -o nvidia_subr.o >> nvidia_subr.c:1131:41: error: too many arguments to function call, >> expected 7, have 8 >> sc->dma_mask, PAGE_SIZE, 0, attr); >> ^~~~ >> /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here >> vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, >> ^ >> nvidia_subr.c:1269:45: error: too many arguments to function call, >> expected 7, have 8 >> sc->dma_mask, PAGE_SIZE, 0, attr); >> ^~~~ >> /usr/src/sys/vm/vm_extern.h:61:1: note: 'kmem_alloc_contig' declared here >> vm_offset_t kmem_alloc_contig(vm_size_t size, int flags, >> ^ >> 2 errors generated. >> *** Error code 1 >> >> Stop. >> make[4]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src/nvidia >> *** Error code 1 >> >> Stop. >> make[3]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77/src >> *** Error code 1 >> >> Stop. >> make[2]: stopped in >> /usr/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-390.77 >> *** Error code 1 >> >> Stop. >> make[1]: stopped in /usr/ports/x11/nvidia-driver >> *** Error code 1 >> >> Stop. >> make: stopped in /usr/ports/x11/nvidia-driver >> root@desktop:/usr/ports/x11/nvidia-driver# >> > All of kmem_alloc_attr(), kmem_alloc_contig(), and kmem_malloc() should > have their first parameter, typically kernel_arena, but sometimes > kmem_arena, removed in FreeBSD 12. > > There is still one more pending change to kmem_free() that has not hit > HEAD yet. That change will be the last. The last change in this series has been committed to HEAD. With that change, you will want to remove the first argument, which should be an arena pointer, from kmem_free() calls. Alan ___ 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 Sat, Aug 25, 2018 at 12:10 PM Kristof Provost wrote: > You may be right about that. With memguard (on ifnet) it implicates pf: > > pfi_cleanup_vnet() at pfi_cleanup_vnet+0xa4/frame 0xfe084f775320 > vnet_pf_uninit() at vnet_pf_uninit+0x85f/frame 0xfe084f7757c0 > vnet_destroy() at vnet_destroy+0x12c/frame 0xfe084f7757f0 > prison_deref() at prison_deref+0x29d/frame 0xfe084f775830 > sys_jail_remove() at sys_jail_remove+0x28a/frame 0xfe084f775880 > amd64_syscall() at amd64_syscall+0x28c/frame 0xfe084f7759b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe084f7759b0 > --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x8003130da, rsp > = 0x7fffe848, rbp = 0x7fffe8d0 --- > > I’ll investigate that. Sorry for the noise. > Thanks for the pointer to memguard. Very useful. > > And thank you for updating me. -M > Kristof > > On 25 Aug 2018, at 19:44, Matthew Macy wrote: > > I'll take a look. But it's likely to not be the OP's issue. For future > reference memguard on the memory type in question is extremely useful in > catching use after free. > > -M > > On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: > >> On 25 Aug 2018, at 0:47, Kristof Provost wrote: >> >> 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. >> >> I see this: >> >> Memory modified after free 0xf800623ab000(2040) val=0 @ >> 0xf800623ab398 >> panic: Most recently used by ifnet >> >> cpuid = 7 >> time = 1535199812 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >> 0xfe008c8e13c0 >> vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420 >> panic() at panic+0x43/frame 0xfe008c8e1480 >> mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0 >> uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510 >> malloc() at malloc+0x9a/frame 0xfe008c8e1560 >> if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590 >> epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610 >> if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660 >> ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750 >> kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0 >> sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880 >> amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0 >> --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = >> 0x7fffe208, rbp = 0x7fffe250 --- >> KDB: enter: panic >> [ thread pid 1426 tid 100466 ] >> Stopped at kdb_enter+0x3b: movq$0,kdb_why >> db> >> >> It does require a couple of bug fixes in pfsync to trigger. You can get >> them from the pfsync_vnet branch in >> https://github.com/kprovost/freebsd/tree/pfsync_vnet >> >> After that: >> kldload pfsync >> pkg install scapy >> cd /usr/tests/sys/netpfil/pf >> kyua test >> >> It should panic reliably. >> >> 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
You may be right about that. With memguard (on ifnet) it implicates pf: pfi_cleanup_vnet() at pfi_cleanup_vnet+0xa4/frame 0xfe084f775320 vnet_pf_uninit() at vnet_pf_uninit+0x85f/frame 0xfe084f7757c0 vnet_destroy() at vnet_destroy+0x12c/frame 0xfe084f7757f0 prison_deref() at prison_deref+0x29d/frame 0xfe084f775830 sys_jail_remove() at sys_jail_remove+0x28a/frame 0xfe084f775880 amd64_syscall() at amd64_syscall+0x28c/frame 0xfe084f7759b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe084f7759b0 --- syscall (508, FreeBSD ELF64, sys_jail_remove), rip = 0x8003130da, rsp = 0x7fffe848, rbp = 0x7fffe8d0 --- I’ll investigate that. Sorry for the noise. Thanks for the pointer to memguard. Very useful. Kristof On 25 Aug 2018, at 19:44, Matthew Macy wrote: I'll take a look. But it's likely to not be the OP's issue. For future reference memguard on the memory type in question is extremely useful in catching use after free. -M On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: On 25 Aug 2018, at 0:47, Kristof Provost wrote: 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. I see this: Memory modified after free 0xf800623ab000(2040) val=0 @ 0xf800623ab398 panic: Most recently used by ifnet cpuid = 7 time = 1535199812 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe008c8e13c0 vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420 panic() at panic+0x43/frame 0xfe008c8e1480 mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0 uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510 malloc() at malloc+0x9a/frame 0xfe008c8e1560 if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590 epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610 if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660 ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750 kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0 sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880 amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = 0x7fffe208, rbp = 0x7fffe250 --- KDB: enter: panic [ thread pid 1426 tid 100466 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> It does require a couple of bug fixes in pfsync to trigger. You can get them from the pfsync_vnet branch in https://github.com/kprovost/freebsd/tree/pfsync_vnet After that: kldload pfsync pkg install scapy cd /usr/tests/sys/netpfil/pf kyua test It should panic reliably. 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: issues with usb mouse detection on 12.0-ALPHA3
___ 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: issues with usb mouse detection on 12.0-ALPHA3
On Sat, Aug 25, 2018, 12:17 PM Pete Wright wrote: > > > On 8/25/18 11:10 AM, Yuri Pankov wrote: > > Pete Wright wrote: > >> howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed > >> that my usb mouse is not being detected. i made sure to do a proper > >> mergemaster after building my kernel and world, and verified that > >> updates to devd configs were picked up as per UPDATING. > >> > >> i am seeing the following in my dmesg console: > >> ugen0.2: at usbus0 (disconnected) > >> ugen0.2: at usbus0 > >> > >> > >> this seems to happen every 60secs or so. starting moused also > >> reports the following: > >> $ sudo service moused start > >> Starting default mousedmoused: unable to open /dev/psm0: No such file > >> or directory > >> > >> not really sure what the best way to debug this is as i'm a bit > >> uncertain about devd and devmatch's recent changes, so let me know if > >> more info is needed or if i'm just missing something obvious. > > > > See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. > > d'oh - didn't even think to check bugzilla. > Just committed a change to devmatch. It looks like I committed from the wrong tree, dropping a new line.:( Warner thanks! > -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" > ___ 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: issues with usb mouse detection on 12.0-ALPHA3
On 8/25/18 11:10 AM, Yuri Pankov wrote: Pete Wright wrote: howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. d'oh - didn't even think to check bugzilla. thanks! -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: issues with usb mouse detection on 12.0-ALPHA3
Pete Wright wrote: howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. ___ 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
blubee blubeeme writes: > True on both points my tone is just a reflection of attitudes of the > individuals that I am currently addressing. Well, congratulations on alienating absolutely everybody you have interacted with on this topic. > Some people enjoy making contributions w/o waving a banner constantly > wanting acknowledgement, a pat on the head and good job from everyone. The only person I see constantly craving attention and validation from others here is you. > How far will core FreeBSD bend over backwards to accommodate these > devs. The core team does not decide what goes into the tree or not. The developers do. > This is the beauty of an open source project, we bring the best to the > table, [...] Who exactly is “we” here? You are not a member of the project, you do not speak for the project, and after seeing how you treat our fellow developers, our friends, most of us want nothing to do with you. If can't live with that, I'm sure you can figure out how to install Linux. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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"
issues with usb mouse detection on 12.0-ALPHA3
howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. thx! -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: ifnet use after free
I'll take a look. But it's likely to not be the OP's issue. For future reference memguard on the memory type in question is extremely useful in catching use after free. -M On Sat, Aug 25, 2018 at 05:51 Kristof Provost wrote: > On 25 Aug 2018, at 0:47, Kristof Provost wrote: > > 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. > > I see this: > > Memory modified after free 0xf800623ab000(2040) val=0 @ 0xf800623ab398 > panic: Most recently used by ifnet > > cpuid = 7 > time = 1535199812 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe008c8e13c0 > vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420 > panic() at panic+0x43/frame 0xfe008c8e1480 > mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0 > uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510 > malloc() at malloc+0x9a/frame 0xfe008c8e1560 > if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590 > epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610 > if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660 > ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750 > kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0 > sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880 > amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0 > --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = > 0x7fffe208, rbp = 0x7fffe250 --- > KDB: enter: panic > [ thread pid 1426 tid 100466 ] > Stopped at kdb_enter+0x3b: movq$0,kdb_why > db> > > It does require a couple of bug fixes in pfsync to trigger. You can get > them from the pfsync_vnet branch in > https://github.com/kprovost/freebsd/tree/pfsync_vnet > > After that: > kldload pfsync > pkg install scapy > cd /usr/tests/sys/netpfil/pf > kyua test > > It should panic reliably. > > 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: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
>> On 24. Aug 2018, at 22:39, Konstantin Belousov wrote:
>>
>> 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.
I have to apologize, something went wrong
when I applied your previous fix, so it was never really used when I tested.
Now, with the patch applied correctly, the machine actually boots.
Before calling init_ops.mp_bootaddress in
getmemsize (machdep.c), physmap looks like this:
physmap_idx: 8
i mem atop
0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf7a000 0x7bf7a
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
With your patch, it looks like this now
(after calling getmemsize)
0 0x0 0x0
1 0x3 0x30
2 0x4 0x40
3 0x9e400 0x9e
4 0x10 0x100
5 0xf0 0xf00
6 0x100 0x1000
7 0x7bf77000 0x7bf77
8 0x1 0x10
9 0x10060 0x100600
10 0x0 0x0
PAGETABLES is 0x7bf77000
So I guess this means that the gap is now at the last three pages of [0x1000,
0x7bf7a[.
If this is what was intended, I guess it's good, as the machine boots okay now.
Sorry again for the extra roundtrip, the patched file was simply in the wrong
path.
Yours,
Michael
p.s. Please see below the patched version of
mp_machdep.c I used for testing (should match yours):
...
#defineAP_BOOTPT_SZ(PAGE_SIZE * 3)
externstruct pcpu __pcpu[];
/* Temporary variables for init_secondary() */
char *doublefault_stack;
char *mce_stack;
char *nmi_stack;
char *dbg_stack;
/*
* Local data and functions.
*/
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) {
/*
* 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) && !is_kernel_paddr(end - 1)) {
allocated = true;
physmap[i] = start + AP_BOOTPT_SZ;
break;
}
/*
* Second, try to chomp at the end. Again, check
* against kernel.
*/
end = trunc_page(physmap[i + 1]);
start = end - AP_BOOTPT_SZ;
if (start >= physmap[i] && is_mpboot_good(start, end) &&
!is_kernel_paddr(start) && !is_kernel_paddr(end - 1)) {
allocated = true;
physmap[i + 1] = start;
break;
}
}
if (allocated) {
mptramp_pagetables = start;
if (physmap[i] == physmap[i + 1] && *physmap_idx != 0) {
memmove([i], [i + 2],
sizeof(*physmap) * (*physmap_idx - i + 2));
*physmap_idx -= 2;
}
} else {
mptramp_pagetables = trunc_page(boot_address) - AP_BOOTPT_SZ;
if (bootverbose)
printf(
"Cannot find enough space for the initial AP page tables, placing them at %#x",
mptramp_pagetables);
}
}
...
___
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
Hi Owen I'm truly sorry you feel this way about our work. At first I was thinking "I'm not going to feed the troll" but after giving what you're writing some more thought it seems maybe you have misunderstood some things that I want to clarify to make sure there's no misunderstanding by you or any one else reading this. There are almost 30,000 ports now in the ports tree. Many are ported from various operating systems. Many are from Linux, GPL'd and in most cases we depend on them for running the graphical desktop of our choice on FreeBSD. However, these ports are all optional. You don't have to install any of them if you don't want to, this includes the new generation GPU drivers and LinuxKPI. Linux is not "moving in to" the FreeBSD kernel. For those of you who want a "pure" BSD experience, running without X is just fine, or finding a pure BSD solution if one exists. For those who don't want Linux derived graphics drivers (which by the way the ones in sys/dev/drm2/ also are), nothing is forcing you to use them. Vesa of scfb works beautifully for a software rendered graphical user interface. Nvidia provides a native driver for FreeBSD if you have their hardware. CURRENT breaks sometimes, not only because of graphics. This is the nature of bleeding edge but we work hard to keep breakage to a minimal. For those of you who wish to run a more stable system, use a stable release. The graphics team at FreeBSD has new members and we're still trying to find our way regarding release schedule, support and other things. It's still a WIP and the road has been bumpy. There is still a lot to do for us to catch up and be able to provide a consistent experience for everyone. Again, we're doing the best we can with the resources we have. There's no way the few developers we have could develop and maintain native GPU drivers, spanning 20 years on three different hardware platforms. Especially considering how fast moving target the graphics hardware is. I know nothing I say matters to you, Owen, but your comments are quite extreme and contain false doomsday propaganda.. This mail is more to provide some information from the graphics team for anyone reading this so they don't fall for false propaganda. On Sat, Aug 25, 2018 at 12:45 PM blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen < > sh+freebsd-curr...@codevoid.de> > wrote: > > > blubee blubeeme wrote: > > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > >> 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) > > > > > > Please tell me more about you're modern hardware, Kris Vice President > > > of Engineering at iXsystems. > > > > > > Try asking a person who doesn't run server infrastructure software and > > > hardware to get that stuff up and running, would you? > > > > Do you want to ask me? I'm mostly a private individual and linux/debian > > user that got fed up with the Linux fragmentation and direction of > > development (from a user perspective). I found my new home in FreeBSD. > > I migrated my (hobby) root server and have a few jails up and running > > and doing random stuff on them for myself and friends. > > > > Key to this was that I was able to get FreeBSD up and running on my > > Laptop - with the drm-next kmod - and use it daily to get used to it and > > learn about it. Actually it was a pain in the ass because back then I > > had to learn how to make -current run and even worse, I had to use the > > drm-next graphics branch from a github repository which wasn't even > > on the main FreeBSD account. I was forced to update the kernel every > > once in a while because the pkg update would complain otherwise. It > > frequently broke and I had to deal with it and learn how to recover it. > > > > The alternative would have been to go back to Linux, which has a whole > > lot more to complain about. So I stayed. And I'm happy with it. > > > > I accepted all this trouble to have decent graphics support. In all > > the time I had to fight -current issues a lot more than anything > > drm/graphics related. This stuff was always stable for me. > > > > I saw a few people trying out FreeBSD. And the first thing after the > > Installation is always: Graphics and Wifi. That's what people need. > > > > These are "desktop needs", where supporting new hardware fast is more > > important than being rock
Re: priority of paths to kernel modules?
On 08/25, 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. Yes, of course X shouldn't load the driver - also because: - X is not the only display server people use (I use Weston) - the console (vt) should also run with the graphics driver! (e.g. efifb currently conflicts with radeon/amdgpu so you have to turn efifb off to get anything working on EFI + Radeon, also many ARM boards do not have any graphics support in U-Boot or whatever firmware) I'm surprised to hear anyone was relying on the X server to load the kernel module. I *always* used kld_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"
Re: drm / drm2 removal in 12
> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen > > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > >> 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. Ditto. I'd like to express my heartfelt thanks for all the people who have been working on the drm-next code for over 2 years now. It's fantastic and an incredible piece of effort to pull it all together. I bought a new laptop 2 years ago, started running the drm-next branch before it even landed in the main FreeBSD tree, and its been solid as a rock. It was my first foray into running current and I've not looked back since. Power mgmt is great, I have working suspend/resume, backlight, HDMI hot-plug output with video & sound as well. That's amazing. A+++ Dave ___ 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:47, Kristof Provost wrote: 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. I see this: Memory modified after free 0xf800623ab000(2040) val=0 @ 0xf800623ab398 panic: Most recently used by ifnet cpuid = 7 time = 1535199812 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe008c8e13c0 vpanic() at vpanic+0x1a3/frame 0xfe008c8e1420 panic() at panic+0x43/frame 0xfe008c8e1480 mtrash_ctor() at mtrash_ctor+0x81/frame 0xfe008c8e14a0 uma_zalloc_arg() at uma_zalloc_arg+0x72c/frame 0xfe008c8e1510 malloc() at malloc+0x9a/frame 0xfe008c8e1560 if_alloc() at if_alloc+0x23/frame 0xfe008c8e1590 epair_clone_create() at epair_clone_create+0x239/frame 0xfe008c8e1610 if_clone_createif() at if_clone_createif+0x4a/frame 0xfe008c8e1660 ifioctl() at ifioctl+0x852/frame 0xfe008c8e1750 kern_ioctl() at kern_ioctl+0x2ba/frame 0xfe008c8e17b0 sys_ioctl() at sys_ioctl+0x15e/frame 0xfe008c8e1880 amd64_syscall() at amd64_syscall+0x28c/frame 0xfe008c8e19b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe008c8e19b0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80047b74a, rsp = 0x7fffe208, rbp = 0x7fffe250 --- KDB: enter: panic [ thread pid 1426 tid 100466 ] Stopped at kdb_enter+0x3b: movq$0,kdb_why db> It does require a couple of bug fixes in pfsync to trigger. You can get them from the pfsync_vnet branch in https://github.com/kprovost/freebsd/tree/pfsync_vnet After that: kldload pfsync pkg install scapy cd /usr/tests/sys/netpfil/pf kyua test It should panic reliably. 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: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen wrote: > blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > >> 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) > > > > Please tell me more about you're modern hardware, Kris Vice President > > of Engineering at iXsystems. > > > > Try asking a person who doesn't run server infrastructure software and > > hardware to get that stuff up and running, would you? > > Do you want to ask me? I'm mostly a private individual and linux/debian > user that got fed up with the Linux fragmentation and direction of > development (from a user perspective). I found my new home in FreeBSD. > I migrated my (hobby) root server and have a few jails up and running > and doing random stuff on them for myself and friends. > > Key to this was that I was able to get FreeBSD up and running on my > Laptop - with the drm-next kmod - and use it daily to get used to it and > learn about it. Actually it was a pain in the ass because back then I > had to learn how to make -current run and even worse, I had to use the > drm-next graphics branch from a github repository which wasn't even > on the main FreeBSD account. I was forced to update the kernel every > once in a while because the pkg update would complain otherwise. It > frequently broke and I had to deal with it and learn how to recover it. > > The alternative would have been to go back to Linux, which has a whole > lot more to complain about. So I stayed. And I'm happy with it. > > I accepted all this trouble to have decent graphics support. In all > the time I had to fight -current issues a lot more than anything > drm/graphics related. This stuff was always stable for me. > > I saw a few people trying out FreeBSD. And the first thing after the > Installation is always: Graphics and Wifi. That's what people need. > > These are "desktop needs", where supporting new hardware fast is more > important than being rock stable and feature complete. > > Just my 2 cents, > Stefan > > -- > Stefan Hagen > Mail: s...@codevoid.de | encryption key in header. > gopher://codevoid.de | https://codevoid.de > ___ > 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" > Like you said you're doing hobby work, that's fine. Take the time to test that bleeding edge stuff on a branch somewhere. You guys cannot expect reasonable people who have machines running production code to have to deal with that type of nonsense that you just described. You left Linux because it's an unorganized mess, FreeBSD is not Linux. There are clear rules and restrictions if you guys cannot understand this then this is just a waste of time. FreeBSD is server first and while that may suck for hobbyist at first, once you understand that people who run servers do not care about graphics as much as hobbyist do they need a reliable core. The linuxkpi stuff the total antithesis of what I understand to be the FreeBSD philosophy. Try reading it again: https://www.freebsd.org/doc/handbook/nutshell.html You guys can't expect to destroy the stability for everyone because a few hobbyist who volunteer in their free time want to wreck the system. Work on your code to improve the quality instead of trying to turn the FreeBSD kernel into a thin wrapper around Linux kernel. Solve the engineering problems instead of asking for quick fix solutions. Any of you linuxkpi guys who are pushing this, what will be enough? Haven't you guys gotten enough leeway from the core team? How many breaking changes do you want to introduce to the FreeBSD kernel vs engineering your software to work well within the existing infrastructure? Which one of you guys dare to stand up and define a goal? ___ 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: pkg-base: how to avoid FreeBSD-$PACKAGE-{profile|development} when using FreeBSD pkg-base
On Sat, Aug 25, 2018 at 11:30:41AM +0200, O. Hartmann wrote: > > For some experiments on PINE64 we build packages from FreeBSD's base system. > The > individual package seems to comprise always from several flavours, the > "regular/production" one, profile/profiling one and development, for instance > for package > FreeBSD-libxo: > > FreeBSD-libxo: 12.0.s20180825090036 [FreeBSD-base] > FreeBSD-libxo-development: 12.0.s20180825090036 [FreeBSD-base] > FreeBSD-libxo-profile: 12.0.s20180825090036 [FreeBSD-base] > > When installing packages as recommended on the FreeBSD pkg-base Wiki > (https://wiki.freebsd.org/PkgBase) via > > pkg install -g 'FreeBSD-*' > > it is implicit that I also get those unwanted "profiling" and "development" > packages as > well as the supposed to be the "production" ones. Fiddling around whith the > pattern left > me with some problems, as it seems to me to make the efforts to high to > target all wanted > packages or avoid development packages. I haven't found a proper way to > exclude all the > unwanted packages (development, prifile) by the global pattern. Have you checked the content of the development packages? I guess you have to install them! To disable profile-packages set WITHOUT_PROFILE in /etc/src.conf. -- Herbert ___ 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: [CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA
On 25 Aug 2018, at 9:06, O. Hartmann wrote:
I'm using ezjail-admin from ports (most recent tree, up to date as of
today, at Revision:
478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25
07:10:45 CEST 2018 amd64,
the jails sources are at revision 338309).
Updates of the jail's base is taken from /usr/src or another path (in
case of another
path, ezjail-admin update -i requires the setting of evn
MAKEOBJDIRPREFIX= some/place).
Updating jails and creating new jails has worked for a while, but
recently, newly created
jails fail to start because the initial start routine bringing up the
jail dumps an error
about /bin/sh /etc/rc missing!
Investigating a complete fresh ezajil setup (on ZFS) reveals, that
neither in fulljail,
newjail or basejail any of the initial rc-srcipts rc or rc.subr is
present any more! I
stopped looking for other missing scripts since rc and rc.subr are
crucial and essential
to the system, so I guess there has been introduced a sort of bug
recently in the way
FreeBSD 12 is going to handle/keep/store rc scripts in the source tree
or their
installation and ezjai didn't catch up so far.
I already filed a PR (see Bug 230822), but I'm unsure whether this is
a "real" bug or I
did just miss some important changes and I didn't catch up.
Yep, it’s a real problem. I ran into it myself a few weeks ago.
Many of the scripts and files in sys/etc have been moved, for pkg base.
This, combined with ezjail doing the install wrong breaks your jails.
Brad posted a patch to the ezjail mailing list. I can’t immediately
find an archive linke, but this should fix it:
--- ezjail-admin2018-08-12 09:41:46.750946000 +0200
+++ /usr/local/bin/ezjail-admin 2018-08-12 09:42:42.86318 +0200
@@ -1053,7 +1053,7 @@
# make and setup our world, then split basejail and newjail
cd "${ezjail_sourcetree}" && env DESTDIR="${ezjail_jailfull}" make
${ezjail_installaction} || exerr "Error: The command 'make
${ezjail_installaction}' failed.\n Refer to the error report(s) above."
-cd "${ezjail_sourcetree}/etc" && env DESTDIR="${ezjail_jailfull}"
make distribution || exerr "Error: The command 'make distribution'
failed.\n Refer to the error report(s) above."
+cd "${ezjail_sourcetree}" && env DESTDIR="${ezjail_jailfull}" make
distribution || exerr "Error: The command 'make distribution' failed.\n
Refer to the error report(s) above."
ezjail_splitworld
fi # installaction="none"
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"
pkg-base: how to avoid FreeBSD-$PACKAGE-{profile|development} when using FreeBSD pkg-base
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 For some experiments on PINE64 we build packages from FreeBSD's base system. The individual package seems to comprise always from several flavours, the "regular/production" one, profile/profiling one and development, for instance for package FreeBSD-libxo: FreeBSD-libxo: 12.0.s20180825090036 [FreeBSD-base] FreeBSD-libxo-development: 12.0.s20180825090036 [FreeBSD-base] FreeBSD-libxo-profile: 12.0.s20180825090036 [FreeBSD-base] When installing packages as recommended on the FreeBSD pkg-base Wiki (https://wiki.freebsd.org/PkgBase) via pkg install -g 'FreeBSD-*' it is implicit that I also get those unwanted "profiling" and "development" packages as well as the supposed to be the "production" ones. Fiddling around whith the pattern left me with some problems, as it seems to me to make the efforts to high to target all wanted packages or avoid development packages. I haven't found a proper way to exclude all the unwanted packages (development, prifile) by the global pattern. I was thinking that the build box also has to take some load when packaging/building all the profiling/development stuff, so is there a way to avoid building those unwanted packages in the first place? At the end my PINE64 wnats to install 313 packages. This seems 2/3 unnecessary. Kind regards, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4Eh3AAKCRDS528fyFhY lLavAgCmjKuhajNCNmO53kU7gBdQmTdKnk9rDKFMVOy4WT8mxP6R9YMKJ2MdfVlZ nM2/J4zktZRhTEIrVtCIBsF/XD7EAgCJfhf+zl7uM4gDod+bEenIDRYdyywNuHW2 Ek0itMr7nMbJCsVQ8BIMm9SorftD4luu7laNIgMUmXUkQe+FxWTc =4r25 -END PGP SIGNATURE- ___ 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
blubee blubeeme wrote: > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: >> 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) > > Please tell me more about you're modern hardware, Kris Vice President > of Engineering at iXsystems. > > Try asking a person who doesn't run server infrastructure software and > hardware to get that stuff up and running, would you? Do you want to ask me? I'm mostly a private individual and linux/debian user that got fed up with the Linux fragmentation and direction of development (from a user perspective). I found my new home in FreeBSD. I migrated my (hobby) root server and have a few jails up and running and doing random stuff on them for myself and friends. Key to this was that I was able to get FreeBSD up and running on my Laptop - with the drm-next kmod - and use it daily to get used to it and learn about it. Actually it was a pain in the ass because back then I had to learn how to make -current run and even worse, I had to use the drm-next graphics branch from a github repository which wasn't even on the main FreeBSD account. I was forced to update the kernel every once in a while because the pkg update would complain otherwise. It frequently broke and I had to deal with it and learn how to recover it. The alternative would have been to go back to Linux, which has a whole lot more to complain about. So I stayed. And I'm happy with it. I accepted all this trouble to have decent graphics support. In all the time I had to fight -current issues a lot more than anything drm/graphics related. This stuff was always stable for me. I saw a few people trying out FreeBSD. And the first thing after the Installation is always: Graphics and Wifi. That's what people need. These are "desktop needs", where supporting new hardware fast is more important than being rock stable and feature complete. Just my 2 cents, Stefan -- Stefan Hagen Mail: s...@codevoid.de | encryption key in header. gopher://codevoid.de | https://codevoid.de ___ 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 4:27 PM Matthew Macy wrote: > Hi Owen - > I understand that you're enthusiastic and you just want what's best for > the project. However, there's a couple of points I hope you'll take to > heart. First, please read what you sent and think about the tone and word > choice. It's extremely negative and critical - you're actively alienating > people on the list. You're not going to be successful engaging any open > source community or workplace if you choose to communicate like this. > Second, this is a volunteer project. One needs to establish a track record > of producing patches and working with developers to get them committed. > Regardless of how sound your technical position is - you're going to have a > hard time being acknowledged if there is no contribution to match. > > Best wishes. > -M > True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. How far will core FreeBSD bend over backwards to accommodate these devs. Their project is half baked at best and sure it works; sorta if the moon is just right. This is the beauty of an open source project, we bring the best to the table, not rip off two legs only to glue them back on later just slightly askew. This isn't a world where everyone gets a gold star, people fail even if they work very hard, failure is still an option. I guess the most important question to ask is what's the standards that the FreeBSD Foundation want to represent, uphold, and maintain? > > > On Fri, Aug 24, 2018 at 4: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
Re: drm / drm2 removal in 12
Isn't Intel supposed to be working on a native drm driver for FreeBSD? https://bwidawsk.net/blog/index.php/2018/06/i965-compiler-architecture-from-2015/ On Sat, Aug 25, 2018 at 12:19 AM, 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. 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: drm / drm2 removal in 12
Hi Owen - I understand that you're enthusiastic and you just want what's best for the project. However, there's a couple of points I hope you'll take to heart. First, please read what you sent and think about the tone and word choice. It's extremely negative and critical - you're actively alienating people on the list. You're not going to be successful engaging any open source community or workplace if you choose to communicate like this. Second, this is a volunteer project. One needs to establish a track record of producing patches and working with developers to get them committed. Regardless of how sound your technical position is - you're going to have a hard time being acknowledged if there is no contribution to match. Best wishes. -M On Fri, Aug 24, 2018 at 4: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"
watchdog broken with r338290
Hi, I get an immediate reset/reboot of the system with an enabled watchdog on r338290. If I disable it no reset. With r336767 the enabled watchdog doesn't cause an immediate reset. Can someone test? rc.conf: ---snip--- watchdogd_enable="YES" watchdogd_flags="-e /root/bin/wd_check.sh -s 5 -t 60" ---snip--- wd_check.sh: ---snip--- #!/bin/sh exec ls / /space/jails >/dev/null 2>&1 CPU: Intel(R) Xeon(R) CPU E5620 @ 2.40GHz (2133.36-MHz K8-class CPU) Most recent microcode from ports installed (but r336767 with the same microcode works). pciconv -l: ---snip--- hostb0@pci0:0:0:0: class=0x06 card=0x34dc8086 chip=0x34068086 rev=0x22 hdr=0x00 pcib1@pci0:0:1:0: class=0x060400 card=0x34dc8086 chip=0x34088086 rev=0x22 hdr=0x01 pcib2@pci0:0:3:0: class=0x060400 card=0x34dc8086 chip=0x340a8086 rev=0x22 hdr=0x01 pcib3@pci0:0:5:0: class=0x060400 card=0x34dc8086 chip=0x340c8086 rev=0x22 hdr=0x01 pcib4@pci0:0:7:0: class=0x060400 card=0x34dc8086 chip=0x340e8086 rev=0x22 hdr=0x01 pcib5@pci0:0:9:0: class=0x060400 card=0x34dc8086 chip=0x34108086 rev=0x22 hdr=0x01 none0@pci0:0:16:0: class=0x08 card=0x00dc0086 chip=0x34258086 rev=0x22 hdr=0x00 none1@pci0:0:16:1: class=0x08 card=0x00dc0086 chip=0x34268086 rev=0x22 hdr=0x00 none2@pci0:0:17:0: class=0x08 card=0x00dc0086 chip=0x34278086 rev=0x22 hdr=0x00 none3@pci0:0:17:1: class=0x08 card=0x00dc0086 chip=0x34288086 rev=0x22 hdr=0x00 ioapic0@pci0:0:19:0:class=0x080020 card=0x00dc0086 chip=0x342d8086 rev=0x22 hdr=0x00 none4@pci0:0:20:0: class=0x08 card=0x00dc0086 chip=0x342e8086 rev=0x22 hdr=0x00 none5@pci0:0:20:1: class=0x08 card=0x00dc0086 chip=0x34228086 rev=0x22 hdr=0x00 none6@pci0:0:20:2: class=0x08 card=0x00dc0086 chip=0x34238086 rev=0x22 hdr=0x00 none7@pci0:0:20:3: class=0x08 card=0x00dc0086 chip=0x34388086 rev=0x22 hdr=0x00 none8@pci0:0:21:0: class=0x080020 card=0x00dc0086 chip=0x342f8086 rev=0x22 hdr=0x00 ioat0@pci0:0:22:0: class=0x088000 card=0x34dc8086 chip=0x34308086 rev=0x22 hdr=0x00 ioat1@pci0:0:22:1: class=0x088000 card=0x34dc8086 chip=0x34318086 rev=0x22 hdr=0x00 ioat2@pci0:0:22:2: class=0x088000 card=0x34dc8086 chip=0x34328086 rev=0x22 hdr=0x00 ioat3@pci0:0:22:3: class=0x088000 card=0x34dc8086 chip=0x34338086 rev=0x22 hdr=0x00 ioat4@pci0:0:22:4: class=0x088000 card=0x34dc8086 chip=0x34298086 rev=0x22 hdr=0x00 ioat5@pci0:0:22:5: class=0x088000 card=0x34dc8086 chip=0x342a8086 rev=0x22 hdr=0x00 ioat6@pci0:0:22:6: class=0x088000 card=0x34dc8086 chip=0x342b8086 rev=0x22 hdr=0x00 ioat7@pci0:0:22:7: class=0x088000 card=0x34dc8086 chip=0x342c8086 rev=0x22 hdr=0x00 uhci0@pci0:0:26:0: class=0x0c0300 card=0x34dc8086 chip=0x3a378086 rev=0x00 hdr=0x00 uhci1@pci0:0:26:1: class=0x0c0300 card=0x34dc8086 chip=0x3a388086 rev=0x00 hdr=0x00 uhci2@pci0:0:26:2: class=0x0c0300 card=0x34dc8086 chip=0x3a398086 rev=0x00 hdr=0x00 ehci0@pci0:0:26:7: class=0x0c0320 card=0x34dc8086 chip=0x3a3c8086 rev=0x00 hdr=0x00 pcib6@pci0:0:28:0: class=0x060400 card=0x34dc8086 chip=0x3a408086 rev=0x00 hdr=0x01 pcib7@pci0:0:28:4: class=0x060400 card=0x34dc8086 chip=0x3a488086 rev=0x00 hdr=0x01 uhci3@pci0:0:29:0: class=0x0c0300 card=0x34dc8086 chip=0x3a348086 rev=0x00 hdr=0x00 uhci4@pci0:0:29:1: class=0x0c0300 card=0x34dc8086 chip=0x3a358086 rev=0x00 hdr=0x00 uhci5@pci0:0:29:2: class=0x0c0300 card=0x34dc8086 chip=0x3a368086 rev=0x00 hdr=0x00 ehci1@pci0:0:29:7: class=0x0c0320 card=0x34dc8086 chip=0x3a3a8086 rev=0x00 hdr=0x00 pcib8@pci0:0:30:0: class=0x060401 card=0x34dc8086 chip=0x244e8086 rev=0x90 hdr=0x01 isab0@pci0:0:31:0: class=0x060100 card=0x34dc8086 chip=0x3a168086 rev=0x00 hdr=0x00 ahci0@pci0:0:31:2: class=0x010601 card=0x34dc8086 chip=0x3a228086 rev=0x00 hdr=0x00 ichsmb0@pci0:0:31:3:class=0x0c0500 card=0x34dc8086 chip=0x3a308086 rev=0x00 hdr=0x00 igb0@pci0:1:0:0:class=0x02 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00 igb1@pci0:1:0:1:class=0x02 card=0x34dc8086 chip=0x10a78086 rev=0x02 hdr=0x00 vgapci0@pci0:2:0:0: class=0x03 card=0x83a01043 chip=0x104010de rev=0xa1 hdr=0x00 none9@pci0:2:0:1: class=0x040300 card=0x83a01043 chip=0x0e0810de rev=0xa1 hdr=0x00 xhci0@pci0:5:0:0: class=0x0c0330 card=0x34831106 chip=0x34831106 rev=0x01 hdr=0x00 ---snip--- Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF ___ 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 10:04 AM Mark Linimon wrote: > 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 > Your opinion has been noted but this issue isn't about me. It's about the Graphics devs coding themselves into a corner and looking for an easy button so they can continue to feel good about their toy. There's a reason the changes they tried to force down the FreeBSD source tree was reverted; It does not meet any standards of quality. I have no inside knowledge other than my ability to think clearly and it's obvious that The FreeBSD team wanted to hint at them that their code doesn't pass the sniff test. Instead of being whiny brats improve your code and have it work without breaking compatibility with what has been working for quite a long time. Here's the play by play; You guys push this mess contaminating the FreeBSD source tree, some long standing user tries to update their machines and it blows up; 1) Most will just leave 2) Some will complain 2a) You guys will say; Read UPDATING. bleh bleh blen They'll get aggravated, thereby aggravating people who came to this platform for Stability. Users who actually use FreeBSD to get things done do not time to trawl these mailing lists, they have real world problems to solve with real world constraints. There are OS with kqueue and all those things it's called Linux; You can go there and play w/ that stuff to your hearts content. If you want your code to get merged, make sure it follows the guidelines and not break the systems for people who are already using the platform. Now, I understand hearing harsh criticism about your work might hurt your feelings and all but here's the antidote; work harder, improve your code, try again when your code quality improves. You guys cannot expect people to accept these kludges in their systems that they run everyday. It's an open source project, you can't get mad because your code isn't accepted, it's your jobs and engineers to do better not expect users to jump through hoops to accommodate your subpar attempts at coding. This isn't about me, it's about the quality of code that you guys are trying to submit. 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"
[CURRENT, ezjail] rc, rc.subr and other rc. scripts gone: ezjail fails on 12-ALPHA
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I'm using ezjail-admin from ports (most recent tree, up to date as of today, at Revision: 478001, FreeBSD is FreeBSD 12.0-ALPHA3 #455 r338309: Sat Aug 25 07:10:45 CEST 2018 amd64, the jails sources are at revision 338309). Updates of the jail's base is taken from /usr/src or another path (in case of another path, ezjail-admin update -i requires the setting of evn MAKEOBJDIRPREFIX= some/place). Updating jails and creating new jails has worked for a while, but recently, newly created jails fail to start because the initial start routine bringing up the jail dumps an error about /bin/sh /etc/rc missing! Investigating a complete fresh ezajil setup (on ZFS) reveals, that neither in fulljail, newjail or basejail any of the initial rc-srcipts rc or rc.subr is present any more! I stopped looking for other missing scripts since rc and rc.subr are crucial and essential to the system, so I guess there has been introduced a sort of bug recently in the way FreeBSD 12 is going to handle/keep/store rc scripts in the source tree or their installation and ezjai didn't catch up so far. I already filed a PR (see Bug 230822), but I'm unsure whether this is a "real" bug or I did just miss some important changes and I didn't catch up. Thanks in advance, oh - -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). -BEGIN PGP SIGNATURE- iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW4EAGAAKCRDS528fyFhY lLVGAf95kEF2FnVtuDs4XYZs3qDlzlEMNkNtXoHnLYNdIp0Fmvl4a8+GwwswQogD DdFcBbToJ2ER+mU0i9luAxI6zJ+pAfwLz24/BiZfMaJHz8O015E568w7Ut1YZ5Vf JyiHLCJnnc7B/ST0f49txNGVXvxfLiRbrrNicHYFxw/DiYtDWLFk =vabb -END PGP SIGNATURE- ___ 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"
