Re: pkg does not recognize correct kernel version
On Wednesday, February 28, 2018 09:45:47 PM Konstantin Belousov wrote: > On Wed, Feb 28, 2018 at 10:57:53AM -0800, John Baldwin wrote: > > On Tuesday, February 20, 2018 10:19:02 AM Conrad Meyer wrote: > > > On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote: > > > > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov > > > > wrote: > > > > > > > >> Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > > > > > > > > > > > > Which man page? I can't find it in pkg help update or pkg help upgrade > > > > or > > > > man pkg. > > > > > > I had to dig for quite a while to find a reference (pkg.conf(5)): > > > > > > ABI: string The ABI of the package you want to install. > > > Default: > > > derived from the ABI of the /bin/sh binary. > > > > > > >> version note: > > > >> orion% file /bin/ls > > > >> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > > > >> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 > > > >> (1101506), FreeBSD-style, stripped > > > >> > > > >> Update world past the __FreeBSD_version which is reported for the > > > >> repository. > > > > > > > > > > > > Does this mean I always have to do a *clean* buildworld after every > > > > version > > > > bump? This takes ages. > > > > > > You could also do a -DNO_CLEAN buildworld. > > > > > > Or you can continue to override with "-o OSVERSION=foo", although that > > > may eventually result in broken packages. In general the OSVERSION is > > > bumped conservatively (more often than will actually result in > > > breakage), so you can get away with the easy workaround for a while > > > between buildworlds. > > > > NO_CLEAN=yes doesn't work. A clean buildworld is required. The reason is > > that > > the __FreeBSD_version embedded in binaries is stored in /usr/lib/crt*.o, but > > that the dependency rules in lib/csu/Makefile do not rebuild these .o files > > everytime changes (so a NO_CLEAN=yes buildworld won't rebuild > > them > > leaving them with a stale version). Furthermore, when binaries and shared > > libraries are built, our Makefiles do not specify that the relevant > > /usr/lib/crt*.o files are dependencies, so even if we fixed the missing > > dependency, no binaries would relink to pick up the updated > > __FreeBSD_version file unless some other input to the binary changed. This > > one could perhaps be mostly mitigated by forcing libc to depend on the > > relevant crt*.o files explicitly (or even having it depend on > > to force relinking of everything when changes). > libc already depends on sys/param.h. Hmm, even when I removed /usr/obj/usr/src/lib/csu entirely and then did a buildworld NO_CLEAN=yes recently /bin/sh was not relinked, though perhaps at that point libc already thought it was up-to-date relative to from the previous build. > I think it would be enough to specify that crt1.o depends on sys/param.h > as well. Although it is also strange, because e.g. for amd64 the dep > thread is csu/amd64/crt1.c->csu/common/crtbrand.c->sys/param.h, which should > be detected by the include file calculation. I think the detour via assembly + sed is what breaks the dependency chain. FWIW, I found that on at least MIPS with clang I did not need the SED_FIX_NOTE hack. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 2:47 PM, Hadi Rezaee wrote: > Thanks Pete, i’ll try your solution. But just wanted to report back > the system current revision: r329639 > > sounds great, let me know how it looks. i suggest we move the rest of this discussion to the freebsd-...@freebsd.org list so we don't SPAM the -current list. cheers! -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
Thanks Pete, i’ll try your solution. But just wanted to report back the system current revision: r329639 On Wed, Feb 28, 2018 at 11:42 PM Pete Wright wrote: > > > On 2/28/18 2:30 PM, Hadi Rezaee wrote: > > Hello Pete, sorry I’m on trip so i cannot output the logs in proper > > way. About i915 kernel module please refer to screen shot. > > > > I can confirm that i915 module is not getting loaded normaly at system > > startup, so kldstat shows nothing. > > > > Yes, the user is already in video group. (Generally didnt changed > > anything on system config, just updated pkg and this happend) > > thanks for posting the screen shot - it looks like your kernel and world > may not be recent enough to load the kld. i'd suggest pulling the > latest code from svn or git for 12-CURRENT then removing and > reinstalling the drm-next-kmod pkg after you have booted into this fresh > checkout. > > that's the first thing that comes to my mind when seeing that your > kernel is unable to handle these modules. you also may want to remove > the drm-next-kmod package and ensure there are no artifacts left behind > in /boot/modules/ that were installed via the pkg, then re-install from > the upstream pkg servers. > > hope this helps, > -pete > > -- > Pete Wright > p...@nomadlogic.org > 310.309.9298 > > ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 2:30 PM, Hadi Rezaee wrote: > Hello Pete, sorry I’m on trip so i cannot output the logs in proper > way. About i915 kernel module please refer to screen shot. > > I can confirm that i915 module is not getting loaded normaly at system > startup, so kldstat shows nothing. > > Yes, the user is already in video group. (Generally didnt changed > anything on system config, just updated pkg and this happend) thanks for posting the screen shot - it looks like your kernel and world may not be recent enough to load the kld. i'd suggest pulling the latest code from svn or git for 12-CURRENT then removing and reinstalling the drm-next-kmod pkg after you have booted into this fresh checkout. that's the first thing that comes to my mind when seeing that your kernel is unable to handle these modules. you also may want to remove the drm-next-kmod package and ensure there are no artifacts left behind in /boot/modules/ that were installed via the pkg, then re-install from the upstream pkg servers. hope this helps, -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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 does not recognize correct kernel version
On Wed, Feb 28, 2018 at 10:57:53AM -0800, John Baldwin wrote: > On Tuesday, February 20, 2018 10:19:02 AM Conrad Meyer wrote: > > On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote: > > > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov > > > wrote: > > > > > >> Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > > > > > > > > > Which man page? I can't find it in pkg help update or pkg help upgrade or > > > man pkg. > > > > I had to dig for quite a while to find a reference (pkg.conf(5)): > > > > ABI: string The ABI of the package you want to install. Default: > > derived from the ABI of the /bin/sh binary. > > > > >> version note: > > >> orion% file /bin/ls > > >> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > > >> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 > > >> (1101506), FreeBSD-style, stripped > > >> > > >> Update world past the __FreeBSD_version which is reported for the > > >> repository. > > > > > > > > > Does this mean I always have to do a *clean* buildworld after every > > > version > > > bump? This takes ages. > > > > You could also do a -DNO_CLEAN buildworld. > > > > Or you can continue to override with "-o OSVERSION=foo", although that > > may eventually result in broken packages. In general the OSVERSION is > > bumped conservatively (more often than will actually result in > > breakage), so you can get away with the easy workaround for a while > > between buildworlds. > > NO_CLEAN=yes doesn't work. A clean buildworld is required. The reason is > that > the __FreeBSD_version embedded in binaries is stored in /usr/lib/crt*.o, but > that the dependency rules in lib/csu/Makefile do not rebuild these .o files > everytime changes (so a NO_CLEAN=yes buildworld won't rebuild > them > leaving them with a stale version). Furthermore, when binaries and shared > libraries are built, our Makefiles do not specify that the relevant > /usr/lib/crt*.o files are dependencies, so even if we fixed the missing > dependency, no binaries would relink to pick up the updated > __FreeBSD_version file unless some other input to the binary changed. This > one could perhaps be mostly mitigated by forcing libc to depend on the > relevant crt*.o files explicitly (or even having it depend on > to force relinking of everything when changes). libc already depends on sys/param.h. I think it would be enough to specify that crt1.o depends on sys/param.h as well. Although it is also strange, because e.g. for amd64 the dep thread is csu/amd64/crt1.c->csu/common/crtbrand.c->sys/param.h, which should be detected by the include file calculation. > > This matters for more than just pkg as the kernel also looks at the embedded > __FreeBSD_version in binaries to make decisions about compat shims to enable > (grep for P_OSREL in sys/). > > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: pkg does not recognize correct kernel version
On Tuesday, February 20, 2018 10:19:02 AM Conrad Meyer wrote: > On Mon, Feb 19, 2018 at 2:38 PM, Ronald Klop wrote: > > On Mon, 19 Feb 2018 22:05:51 +0100, Konstantin Belousov > > wrote: > > > >> Look at the man page. pkg reads version from the /bin/sh ELF FreeBSD > > > > > > Which man page? I can't find it in pkg help update or pkg help upgrade or > > man pkg. > > I had to dig for quite a while to find a reference (pkg.conf(5)): > > ABI: string The ABI of the package you want to install. Default: > derived from the ABI of the /bin/sh binary. > > >> version note: > >> orion% file /bin/ls > >> /bin/ls: ELF 64-bit LSB executable, x86-64, version 1 (FreeBSD), > >> dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 11.1 > >> (1101506), FreeBSD-style, stripped > >> > >> Update world past the __FreeBSD_version which is reported for the > >> repository. > > > > > > Does this mean I always have to do a *clean* buildworld after every version > > bump? This takes ages. > > You could also do a -DNO_CLEAN buildworld. > > Or you can continue to override with "-o OSVERSION=foo", although that > may eventually result in broken packages. In general the OSVERSION is > bumped conservatively (more often than will actually result in > breakage), so you can get away with the easy workaround for a while > between buildworlds. NO_CLEAN=yes doesn't work. A clean buildworld is required. The reason is that the __FreeBSD_version embedded in binaries is stored in /usr/lib/crt*.o, but that the dependency rules in lib/csu/Makefile do not rebuild these .o files everytime changes (so a NO_CLEAN=yes buildworld won't rebuild them leaving them with a stale version). Furthermore, when binaries and shared libraries are built, our Makefiles do not specify that the relevant /usr/lib/crt*.o files are dependencies, so even if we fixed the missing dependency, no binaries would relink to pick up the updated __FreeBSD_version file unless some other input to the binary changed. This one could perhaps be mostly mitigated by forcing libc to depend on the relevant crt*.o files explicitly (or even having it depend on to force relinking of everything when changes). This matters for more than just pkg as the kernel also looks at the embedded __FreeBSD_version in binaries to make decisions about compat shims to enable (grep for P_OSREL in sys/). -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 9:03 AM, Hadi Rezaee wrote: > Hello there, > My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my > graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But now > it getting failed. Tried to build from source, but same result. > Laptop model: Lenovo E470 > (removing stable since this is a potential issue on CURRENT) we'll need more details to help triage and hopefully fix this issue. what errors are you seeing? are you having problems loading the driver, or is Xorg having issues? -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 8:53 AM, Jan Bramkamp wrote: > On 25.02.18 16:48, Johannes M Dieterich wrote: >> Dear all, >> >> Please CC me as I am not subscribed. >> >> On behalf of the FreeBSDDesktop team and thanks to the tireless efforts >> of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to >> report that the graphics/drm-next-kmod port just received an update to >> Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent >> CURRENT and 11-STABLE. >> >> We have tested this on a range of hardware ourselves: >> * Haswell >> * Broadwell >> * Skylake >> * Evergreen >> * Kaveri (both radeon and amgpu KMS) >> * Carrizo >> * Polaris >> >> Needless to say, the possible space of hardware this could run on is >> significantly larger. Hence, if you find issues and/or want to propose >> patches, please do so at our development github: >> >> https://github.com/FreeBSDDesktop/kms-drm >> >> We absolutely do welcome contributions! >> >> Johannes > > Thx for your hard work. The drm-next-kmod port enabled me to finally > replace my ageing Thinkpad X220 with newer hardware. > > The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod > port introduced a regression which causes Xorg on my T470s running > 12-current from a few days ago to fail at startup stating that it > didn't find any screen. (removing freebsd-stable@ from this reply since this is a current system) interesting, so Xorg complains about no displays being present if i understand correctly? can you verify that the i915 module is being loaded at boot, kld stat should show something like this: $ kldstat |grep i915 7 1 0x82f38000 11f615 i915kms.ko If it is present, can you also verify that you are a member of the "video" group? And failing that it will be helpful to post your dmesg and Xorg.log.0 to help triage this. Cheers, -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
Hello there, My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But now it getting failed. Tried to build from source, but same result. Laptop model: Lenovo E470 On Wed, Feb 28, 2018 at 5:56 PM Jan Bramkamp wrote: > On 25.02.18 16:48, Johannes M Dieterich wrote: > > Dear all, > > > > Please CC me as I am not subscribed. > > > > On behalf of the FreeBSDDesktop team and thanks to the tireless efforts > > of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to > > report that the graphics/drm-next-kmod port just received an update to > > Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent > > CURRENT and 11-STABLE. > > > > We have tested this on a range of hardware ourselves: > > * Haswell > > * Broadwell > > * Skylake > > * Evergreen > > * Kaveri (both radeon and amgpu KMS) > > * Carrizo > > * Polaris > > > > Needless to say, the possible space of hardware this could run on is > > significantly larger. Hence, if you find issues and/or want to propose > > patches, please do so at our development github: > > > > https://github.com/FreeBSDDesktop/kms-drm > > > > We absolutely do welcome contributions! > > > > Johannes > > Thx for your hard work. The drm-next-kmod port enabled me to finally > replace my ageing Thinkpad X220 with newer hardware. > > The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod > port introduced a regression which causes Xorg on my T470s running > 12-current from a few days ago to fail at startup stating that it didn't > find any screen. > ___ > 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 25.02.18 16:48, Johannes M Dieterich wrote: Dear all, Please CC me as I am not subscribed. On behalf of the FreeBSDDesktop team and thanks to the tireless efforts of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to report that the graphics/drm-next-kmod port just received an update to Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent CURRENT and 11-STABLE. We have tested this on a range of hardware ourselves: * Haswell * Broadwell * Skylake * Evergreen * Kaveri (both radeon and amgpu KMS) * Carrizo * Polaris Needless to say, the possible space of hardware this could run on is significantly larger. Hence, if you find issues and/or want to propose patches, please do so at our development github: https://github.com/FreeBSDDesktop/kms-drm We absolutely do welcome contributions! Johannes Thx for your hard work. The drm-next-kmod port enabled me to finally replace my ageing Thinkpad X220 with newer hardware. The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod port introduced a regression which causes Xorg on my T470s running 12-current from a few days ago to fail at startup stating that it didn't find any screen. ___ 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: md: g_handleattr: md0 bio_length 24 len 31 -> EFAULT
While writing out a md based disk image (NanoBSD) onto a ZFS based filesystem, the console is flooded on CURRENT host (FreeBSD 12.0-CURRENT #78 r330019: Mon Feb 26 16:23:09 CET 2018 amd64) with the message: g_handleattr: md0 bio_length 24 len 31 -> EFAULT Writing out the md image of a size of ~ 2,5 GB to ZFS filesystem takes more than 20 minutes, which is a pain in the arse. ZFS hasn't any neat features enabled or disabled, so deduplication is disabled, atime is off, checksum is sha256 and compression is disabled. The box in question is a Haswell XEON, 6 cores, 3,4 GHz clock and 32 GB RAM - so insufficient performance should not be the issue. What am I doing wrong? Kind regards and thanks in advance, Oliver ___ 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"
