Re: Rangeley C2758: missed IOMMU support for Xen Dom0
On Fri, May 26, 2017 at 2:53 AM, Alex Deiter wrote: > > # pciconf -lv > none1@pci0:0:15:0: class=0x080600 card=0x082015d9 chip=0x1f168086 > rev=0x02 hdr=0x00 > vendor = 'Intel Corporation' > device = 'Atom processor C2000 RCEC' > class = base peripheral > subclass = IOMMU > Rangeley does not have IOMMU, or in Intel term VT-d. Device 15 is RCEC for PCIe error reporting. -Jia-Shiun. ___ 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"
adding -R to the skeleton file for the PAGER variable
I ran into an "interesting" issue today using the devel/awscli port. aws help generates almost unreadable output using the "standard" shell .profile, etc. The reason is it uses $PAGER or $MANPAGER if it's present, and the skeleton sets: PAGER=more which, using the .rst files that awscli has, just makes the output ESC sequences get printed and not acted upon. I'm wondering if there would be any objections to changing the "standard" skeleton PAGER environment to: PAGER="more -R" so the ESC sequences get passed through to the terminal unmolested and do the right thing. Comments? -- Larry Rosenman https://people.FreeBSD.org/~ler/ Phone: +1 214-642-9640 E-Mail: l...@freebsd.org US Mail: 17716 Limpia Crk, Round Rock, TX 78664-7281 signature.asc Description: PGP signature
Re: pkg weirdness [corrected]
Errata... on a part of the below... On Thu, 25 May 2017 17:19:05 -0700 (PDT), "Jeffrey Bouquet" wrote: > On a machine, pkg install xorg-server. > It wants to install the 1G llvm40 > downloads... errors out. Reboot > > boot up > use tty1 rather than tty0 > pkg install xorg-server > AGAIN downloads the metadata. > starts to AGAIN download llvm40, I cntl-C it. > I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg > Now pkg install xorg-server runs again, but RE downloading the smaller [... > xorg-server ] > . > It lists the packages it is going to download. > Then, not in the new install... upgrade... reinstall... Y/N? ... it starts ^^^ was in a later version of the list... > downloading seamonkey! I only asked it to 'install xorg-server!' > . > I think some more huge transparency [ pkg tells us in a verbose way what it > is doing, and why, and eventually have fine grained menu control before an > action... so that one can begin to make more sense of a post like this > >> eventual bugzilla if need be. > .. > Just curious more than anything this time, though... > . > Sounds like did not happen, but did. Sorry... > [ by the way on the desktop, if I build from ports it is v11, but if I use > pkg, it is v12. ] > So I build from ports, all is good, but next pkg [week] it wants to upgrade a > port > from v11 to v12. too many places to look, I don't see that setting [v11 on a > v12 machine] > anywhere.12.0-CURRENT by the way... > .. > ___ > 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" Sorry. seamonkey WAS in the 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"
pkg weirdness
On a machine, pkg install xorg-server. It wants to install the 1G llvm40 downloads... errors out. Reboot boot up use tty1 rather than tty0 pkg install xorg-server AGAIN downloads the metadata. starts to AGAIN download llvm40, I cntl-C it. I add 'pkg add ' the llvm40 that is ALREADY in /var/cache/pkg Now pkg install xorg-server runs again, but RE downloading the smaller [... xorg-server ] . It lists the packages it is going to download. Then, not in the new install... upgrade... reinstall... Y/N? ... it starts downloading seamonkey! I only asked it to 'install xorg-server!' . I think some more huge transparency [ pkg tells us in a verbose way what it is doing, and why, and eventually have fine grained menu control before an action... so that one can begin to make more sense of a post like this >> eventual bugzilla if need be. .. Just curious more than anything this time, though... . Sounds like did not happen, but did. Sorry... [ by the way on the desktop, if I build from ports it is v11, but if I use pkg, it is v12. ] So I build from ports, all is good, but next pkg [week] it wants to upgrade a port from v11 to v12. too many places to look, I don't see that setting [v11 on a v12 machine] anywhere.12.0-CURRENT by the way... .. ___ 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: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp
David Wolfskill wrote: > On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > > This is on my "build machine"; running GENERIC/amd64 built yesterday: > > > > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353 > > r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 > > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > > > > Well, the laptop, running: Compare the meta files for ARUBA_pfp.bin in the failure case it looks very much like a input file was not supplied (eg empty variable) A possibility is .OODATE being used; which will be empty if none of the srcs are out-of-date. A quick scan didn't identify where the target for that comes from so guessing... ___ 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"
Rangeley C2758: missed IOMMU support for Xen Dom0
Hello, Could you please help me understand what and were i did wrong? Running a FreeBSD 12.0-CURRENT-r318425 GENERIC-NODEBUG and trying to install Xen Dom0 (xen-4.7.0_2 from ports). HW setup: Supermicro A1SRM-2758F [Intel Rangeley Atom processor C2758] Motherboard spec: http://supermicro.com/products/motherboard/Atom/X10/A1SRM-2758F.cfm CPU spec: https://ark.intel.com/products/77988/Intel-Atom-Processor-C2758-4M-Cache-2_40-GHz loader.conf: hw.pci.mcfg=0 xen_kernel="/boot/xen" xen_cmdline="dom0_mem=2048M dom0_max_vcpus=4 dom0pvh=1 com1=115200,8n1 com2=115200,8n1 console=com2 guest_loglvl=all loglvl=all" Xen Dom0 boot failed with error Full boot log - https://cloud.deiter.ru/index.php/s/bg5lQSjPPSkiTAq ... (XEN) I/O virtualisation disabled ... (XEN) (XEN) Panic on CPU 0: (XEN) Presently, iommu must be enabled for PVH hardware domain (XEN) (XEN) Boot without Xen kernel is OK Full boot log - https://cloud.deiter.ru/index.php/s/lUXLPnPSTWqqQNO ... CPU: Intel(R) Atom(TM) CPU C2758 @ 2.40GHz (2400.06-MHz K8-class CPU) Origin="GenuineIntel" Id=0x406d8 Family=0x6 Model=0x4d Stepping=8 Features=0xbfebfbff Features2=0x43d8e3bf AMD Features=0x28100800 AMD Features2=0x101 Structured Extended Features=0x2282 VT-x: Basic Features=0xda0400 Pin-Based Controls=0x7f Primary Processor Controls=0xfff9fffe Secondary Processor Controls=0x28ef Exit Controls=0xda0400 Entry Controls=0xda0400 EPT Features=0x6114141 VPID Features=0xf01 ... pci0: at device 15.0 (no driver attached) pci0: at device 19.0 (no driver attached) ... # pciconf -lv none1@pci0:0:15:0: class=0x080600 card=0x082015d9 chip=0x1f168086 rev=0x02 hdr=0x00 vendor = 'Intel Corporation' device = 'Atom processor C2000 RCEC' class = base peripheral subclass = IOMMU Thank you! Alex Deiter alex.dei...@gmail.com ___ 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: Bug in make setting wrong MAKESYSPATH
Thomas Mueller wrote: > When I did those last examples, that last line was > env MAKESYSPATH=/usr/share/mk make all-depends-list ok, that makes sense. > > > and then it seems to work correctly with no syntax error in > > > /BETA1/usr/share/mk/bsd.compiler.mk > > > > > Maybe I need to file a bug. > > > For what? > > Bug occurs when building or configuring ports, syntax error in > /BETA1/usr/share/mk/bsd.compiler.mk line 52 This is of course specific to your particular arrangement if you'd mounted /BETA1/usr/ports on /usr/ports, it would function as you wish, or if /BETA1/usr/share/mk happend to match /usr/share/mk it would work fine. So, anoying in this case, but not a bug. > I don't know about other situations such as building doc. > > I could avoid this error either by setting (setenv or export, depending on > shell) MAKESYSPATH or > by null-mounting /BETA1/usr/ports at /usr/ports . Yes. ___ 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: ino64? r318606 -> r318739 OK; r318739 -> r318781 fails SIGSEGV
Simon J. Gerraty wrote: > Peter Jeremy wrote: > > In my case, I have "WITH_META_MODE=yes" in /etc/src-env.conf and was > > using "make buildworld" - which failed. The upgrade worked cleanly > > when I manually deleted all the .meta files. If I get a round tuit, > > sys.mk is setup such that missing .meta file makes the target > out-of-date. > > FWIW I just did a buildworld -DWITH_META_MODE followed by the same with > -DNO_CLEAN - but no change to the tree. > That at least worked fine (and quickly) tree was last updated to r318755 > > Wonder if it is safe to update... FWIW I updated to r318860 and again make -j12 -DWITHOUT_TESTS buildworld -DWITH_META_MODE -DNO_CLEAN completed happily. I guess need to update to/from the specific grns people had issue with to reproduce. ___ 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: ino64 package fallout
On Wed, May 24, 2017 at 05:49:04PM -0700, Don Lewis wrote: > On 24 May, Konstantin Belousov wrote: > > On Wed, May 24, 2017 at 10:05:22AM -0700, Don Lewis wrote: > >> I just upgraded by package build box and its poudriere jail to r318776 > >> and ran into some significant package build fallout. > > > > There are several reviews that fix ports with most significant fallouts, > >lang/llvm39 D10796 > >lang/llvm40 D10797 > >lang/ghc D10798 > >multimedia/webcamd D10800 > >devel/libgtopD10795 > >sysutils/py-psutil D1081 > >lang/rustD10799 > > > > I intend to commit this tomorrow, after the ino64 get some probation time, > > long enough to ensure that it does not get immediate revert. You may > > see the discussions and use the patches locally, meantime. > > devel/libgtop is also broken: > > procopenfiles.c:325:39: error: no member named 'kf_sa_local' in 'struct > kinfo_file' > sun = (struct sockaddr_un *)&kif->kf_sa_local; > ~~~ ^ > procopenfiles.c:330:37: error: no member named 'kf_sa_local' in 'struct > kinfo_file' > addrstr = > addr_to_string(&kif->kf_sa_local); > ~~~ ^ > procopenfiles.c:338:37: error: no member named 'kf_sa_peer' in 'struct > kinfo_file' > addrstr = > addr_to_string(&kif->kf_sa_peer); > ~~~ ^ > procopenfiles.c:352:36: error: no member named 'kf_sa_peer' in 'struct > kinfo_file' > addrstr = addr_to_string(&kif->kf_sa_peer); > ~~~ ^ > procopenfiles.c:357:52: error: no member named 'kf_sa_peer' in 'struct > kinfo_file' > entry.info.sock.dest_port = > addr_to_port(&kif->kf_sa_peer); > procwd.c:155:16: warning: comparison of integers of different signs: 'int' > and 'unsigned long' [-Wsign-compare] > for (i = 0; i < len / sizeof(*kif); i++, kif++) { > ~ ^ ~~ > ~~~ > ^ > procopenfiles.c:388:9: warning: cast from 'gchar *' (aka 'char *') to > 'glibtop_open_files_entry *' (aka 'struct _glibtop_open_files_entry *') > increases required alignment from 1 to 4 [-Wcast-align] > return (glibtop_open_files_entry*)g_array_free(entries, FALSE); >^~~ > procopenfiles.c:305:16: warning: comparison of integers of different signs: > 'ssize_t' (aka 'long') and 'unsigned long' [-Wsign-compare] > for (i = 0; i < len / sizeof(*kif); i++, kif++) { > ~ ^ ~~ > 2 warnings and 5 errors generated. This looks like errors from the unpatched port. For instance, in my working directory, content of the file devel/libgtop/work/libgtop-2.32.0/sysdeps/freebsd/procopenfiles.c around line 325 is: struct sockaddr_un *sun; entry.type = GLIBTOP_FILE_TYPE_LOCALSOCKET; sun = (struct sockaddr_un *)&kif->kf_un.kf_sock. kf_sa_local; which is not sun = (struct sockaddr_un *)&kif->kf_sa_local; as reported by compiler in your case. The patch is applied as extra-patch, might be you have OSVERSION set forcibly ? ___ 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: The futur of the roff toolchain
> > Fixed, and reuploaded. because there should be some caching on people.f.o you > cannot yet see the fixed version but I have fixed it. It is supposed to be a > monocolumn as far as I understand it. Yup, that renders fine for me now too. - [tj] ___ 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: The futur of the roff toolchain
On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote: > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote: > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: > > > No the problem left is documentations available in share/doc. > > > > > > I would like to push them elsewhere. Those documents are mostly useful for > > > historical reason (hence we want to keep them) but not really for daily > > > use of > > > modern FreeBSD. > > > Another issue with those documentation, they are installed as text/ascii > > > version > > > in base, which makes most of them not really readable (as the documents > > > has not > > > be written for a ascii/text target but more for a PDF/html view - using > > > pic(1) > > > for example) > > > > > > A plan was to push as sources in the svn doc repository and continue to > > > build > > > them. This approach also have an issue: over the time roff evolved a bit > > > and > > > while working on heirloom doctools import I had to fix a bunch of markup > > > to make > > > the rendering of those documents clean (also meaning almost noone should > > > read > > > them considering some were not really readable). > > > > > > What I want to propose now, it to render them as PDF (html?) once and > > > push them > > > somewhere (to be defined) as static document on our documentation website. > > > Please doceng@ provide me a location where to push them. > > > > > > > Unless anyone on doceng@ objects within the next three days, I will > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/. > > > > Thank you, > > For the record I have pushed the generated PDF: > https://people.freebsd.org/~bapt/pdfdocs/ > > The have been built with a modern groff and I forced the embedded fonts for > all > fonts used. > Multicolumn doesn't render correct in firefox for this: https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf but is fine for this: https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf - [tj] ___ 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: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > This is on my "build machine"; running GENERIC/amd64 built yesterday: > Nevermind. Replacing /usr/src with a fresh checkout resolved the issue. Peace, davdi -- David H. Wolfskill da...@catwhisker.org "[T]he president’s improper efforts to influence an ongoing investigation" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: The futur of the roff toolchain
On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote: > On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote: > > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote: > > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: > > > > No the problem left is documentations available in share/doc. > > > > > > > > I would like to push them elsewhere. Those documents are mostly useful > > > > for > > > > historical reason (hence we want to keep them) but not really for daily > > > > use of > > > > modern FreeBSD. > > > > Another issue with those documentation, they are installed as > > > > text/ascii version > > > > in base, which makes most of them not really readable (as the documents > > > > has not > > > > be written for a ascii/text target but more for a PDF/html view - using > > > > pic(1) > > > > for example) > > > > > > > > A plan was to push as sources in the svn doc repository and continue to > > > > build > > > > them. This approach also have an issue: over the time roff evolved a > > > > bit and > > > > while working on heirloom doctools import I had to fix a bunch of > > > > markup to make > > > > the rendering of those documents clean (also meaning almost noone > > > > should read > > > > them considering some were not really readable). > > > > > > > > What I want to propose now, it to render them as PDF (html?) once and > > > > push them > > > > somewhere (to be defined) as static document on our documentation > > > > website. > > > > Please doceng@ provide me a location where to push them. > > > > > > > > > > Unless anyone on doceng@ objects within the next three days, I will > > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/. > > > > > > > Thank you, > > > > For the record I have pushed the generated PDF: > > https://people.freebsd.org/~bapt/pdfdocs/ > > > > The have been built with a modern groff and I forced the embedded fonts for > > all > > fonts used. > > > > Multicolumn doesn't render correct in firefox for this: > > https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf > > but is fine for this: > > https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf > > - [tj] Fixed, and reuploaded. because there should be some caching on people.f.o you cannot yet see the fixed version but I have fixed it. It is supposed to be a monocolumn as far as I understand it. Bapt signature.asc Description: PGP signature
Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > This is on my "build machine"; running GENERIC/amd64 built yesterday: > > FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353 > r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 > r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 > Well, the laptop, running: FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #355 r318781M/318781:1200031: Wed May 24 19:23:41 PDT 2017 r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 failed to exhibit the failure. I'll poke a bit more at the build machine. Peace, david -- David H. Wolfskill da...@catwhisker.org "[T]he president’s improper efforts to influence an ongoing investigation" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: The futur of the roff toolchain
On Thu, May 25, 2017 at 01:12:51PM +0100, tj wrote: > On Thu, May 25, 2017 at 02:07:00PM +0200, Baptiste Daroussin wrote: > > On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote: > > > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: > > > > No the problem left is documentations available in share/doc. > > > > > > > > I would like to push them elsewhere. Those documents are mostly useful > > > > for > > > > historical reason (hence we want to keep them) but not really for daily > > > > use of > > > > modern FreeBSD. > > > > Another issue with those documentation, they are installed as > > > > text/ascii version > > > > in base, which makes most of them not really readable (as the documents > > > > has not > > > > be written for a ascii/text target but more for a PDF/html view - using > > > > pic(1) > > > > for example) > > > > > > > > A plan was to push as sources in the svn doc repository and continue to > > > > build > > > > them. This approach also have an issue: over the time roff evolved a > > > > bit and > > > > while working on heirloom doctools import I had to fix a bunch of > > > > markup to make > > > > the rendering of those documents clean (also meaning almost noone > > > > should read > > > > them considering some were not really readable). > > > > > > > > What I want to propose now, it to render them as PDF (html?) once and > > > > push them > > > > somewhere (to be defined) as static document on our documentation > > > > website. > > > > Please doceng@ provide me a location where to push them. > > > > > > > > > > Unless anyone on doceng@ objects within the next three days, I will > > > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/. > > > > > > > Thank you, > > > > For the record I have pushed the generated PDF: > > https://people.freebsd.org/~bapt/pdfdocs/ > > > > The have been built with a modern groff and I forced the embedded fonts for > > all > > fonts used. > > > > Multicolumn doesn't render correct in firefox for this: > > https://people.freebsd.org/~bapt/pdfdocs/papers/timecounter.pdf > > but is fine for this: > > https://people.freebsd.org/~bapt/pdfdocs/papers/devfs.pdf > Good catch thanks! I will see what I can do Bapt signature.asc Description: PGP signature
Re: Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp
On Thu, May 25, 2017 at 05:07:19AM -0700, David Wolfskill wrote: > ... > I have attached a copy of the meta file in question. > Bah. Really attaching this time. Peace, david -- David H. Wolfskill da...@catwhisker.org "[T]he president’s improper efforts to influence an ongoing investigation" See http://www.catwhisker.org/~david/publickey.gpg for my public key. # Meta data file /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta CMD uudecode -p > ARUBA_pfp.bin CWD /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp TARGET ARUBA_pfp.bin -- command output -- uudecode: stdin: missing or bad "begin" line *** Error code 1 -- filemon acquired metadata -- # filemon version 5 # Target pid 17403 # Start 1495712760.942230 V 5 E 17502 /bin/sh R 17502 /etc/libmap.conf R 17502 /var/run/ld-elf.so.hints R 17502 /lib/libedit.so.7 R 17502 /lib/libc.so.7 R 17502 /lib/libncursesw.so.8 R 17502 /usr/share/locale/en_US.UTF-8/LC_COLLATE R 17502 /usr/share/locale/en_US.UTF-8/LC_CTYPE R 17502 /usr/share/locale/en_US.UTF-8/LC_MONETARY R 17502 /usr/share/locale/en_US.UTF-8/LC_NUMERIC R 17502 /usr/share/locale/en_US.UTF-8/LC_TIME R 17502 /usr/share/locale/en_US.UTF-8/LC_MESSAGES F 17502 17505 W 17505 ARUBA_pfp.bin E 17505 /usr/bin/uudecode R 17505 /etc/libmap.conf R 17505 /var/run/ld-elf.so.hints R 17505 /lib/libc.so.7 X 17505 1 0 X 17502 1 0 # Stop 1495712760.979230 # Bye bye signature.asc Description: PGP signature
Build failure in sys/modules/drm2/radeonkmsfw/ARUBA_pfp
This is on my "build machine"; running GENERIC/amd64 built yesterday: FreeBSD freebeast.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #353 r318739M/318739:1200031: Wed May 24 10:00:20 PDT 2017 r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/sys/GENERIC amd64 after updating sources to r318863: >>> World build started on Thu May 25 03:59:04 PDT 2017 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools >>> stage 3.1: recording compiler metadata >>> stage 4.1: building includes >>> stage 4.2: building libraries >>> stage 4.3: building everything >>> stage 5.1: building lib32 shim libraries >>> World build completed on Thu May 25 04:45:02 PDT 2017 >>> Kernel build for GENERIC started on Thu May 25 04:45:02 PDT 2017 >>> stage 1: configuring the kernel >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3.1: building everything ... --- all_subdir_drm2/radeonkms --- Building /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkms/iicbus_if.h --- all_subdir_ctl --- Building /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko.debug --- all_subdir_drm2 --- --- all_subdir_drm2/radeonkmsfw --- --- ARUBA_pfp.bin --- uudecode: stdin: missing or bad "begin" line --- all_subdir_ctl --- Building /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/ctl/ctl.ko --- all_subdir_drm2 --- --- all_subdir_drm2/radeonkmsfw/ARUBA_me --- Building /common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_me/ARUBA_me.bin bmake[6]: stopped in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp .ERROR_TARGET='ARUBA_pfp.bin' .ERROR_META_FILE='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/ARUBA_pfp.bin.meta' .MAKE.LEVEL='6' MAKEFILE='' .MAKE.MODE='meta missing-filemon=yes missing-meta=yes silent=yes verbose' .CURDIR='/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp' .MAKE='/usr/obj/usr/src/make.amd64/bmake' .OBJDIR='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp' .TARGETS='all' DESTDIR='' LD_LIBRARY_PATH='' MACHINE='amd64' MACHINE_ARCH='amd64' MAKEOBJDIRPREFIX='/common/S4/obj/usr/src/sys/GENERIC/modules' MAKESYSPATH='/usr/src/share/mk' MAKE_VERSION='20160604' PATH='/usr/obj/usr/src/tmp/legacy/usr/sbin:/usr/obj/usr/src/tmp/legacy/usr/bin:/usr/obj/usr/src/tmp/legacy/bin:/usr/obj/usr/src/tmp/usr/sbin:/usr/obj/usr/src/tm p/usr/bin:/sbin:/bin:/usr/sbin:/usr/bin' SRCTOP='/usr/src' OBJTOP='/common/S4/obj/usr/src/sys/GENERIC/modules/usr/src' .MAKE.MAKEFILES='/usr/src/share/mk/sys.mk /usr/src/share/mk/local.sys.env.mk /usr/src/share/mk/src.sys.env.mk /etc/src-env.conf /usr/src/share/mk/bsd.mkopt.mk / usr/src/share/mk/bsd.suffixes.mk /etc/make.conf /usr/src/share/mk/local.sys.mk /usr/src/share/mk/src.sys.mk /etc/src.conf /usr/src/sys/modules/drm2/radeonkmsfw/ ARUBA_pfp/Makefile /usr/src/share/mk/bsd.kmod.mk /usr/src/sys/conf/kmod.mk /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/sys/modules/drm2/radeonkmsfw/ARUBA_pfp/../Makefile.inc /usr/src/share/mk/bsd.own.mk / usr/src/share/mk/bsd.compiler.mk /usr/src/sys/conf/kern.opts.mk /usr/src/sys/conf/config.mk /usr/src/share/mk/bsd.links.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/sys/conf/kern.mk' I have attached a copy of the meta file in question. The only file in /usr/src/sys/modules/drm2/radeonkmsfw/ARUBA_pfp is a Makefile ... last updated Oct 23 07:29:55 2014 (US/Pacific time). Peace, david -- David H. Wolfskill da...@catwhisker.org "[T]he president’s improper efforts to influence an ongoing investigation" See http://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: The futur of the roff toolchain
On Thu, May 25, 2017 at 11:45:19AM +, Glen Barber wrote: > On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: > > No the problem left is documentations available in share/doc. > > > > I would like to push them elsewhere. Those documents are mostly useful for > > historical reason (hence we want to keep them) but not really for daily use > > of > > modern FreeBSD. > > Another issue with those documentation, they are installed as text/ascii > > version > > in base, which makes most of them not really readable (as the documents has > > not > > be written for a ascii/text target but more for a PDF/html view - using > > pic(1) > > for example) > > > > A plan was to push as sources in the svn doc repository and continue to > > build > > them. This approach also have an issue: over the time roff evolved a bit and > > while working on heirloom doctools import I had to fix a bunch of markup to > > make > > the rendering of those documents clean (also meaning almost noone should > > read > > them considering some were not really readable). > > > > What I want to propose now, it to render them as PDF (html?) once and push > > them > > somewhere (to be defined) as static document on our documentation website. > > Please doceng@ provide me a location where to push them. > > > > Unless anyone on doceng@ objects within the next three days, I will > create a new directory for the PDFs under doc/head/en_US.ISO8859-1/. > Thank you, For the record I have pushed the generated PDF: https://people.freebsd.org/~bapt/pdfdocs/ The have been built with a modern groff and I forced the embedded fonts for all fonts used. Best regards, Bapt signature.asc Description: PGP signature
Re: The futur of the roff toolchain
On Sun, May 21, 2017 at 02:57:33PM +0200, Baptiste Daroussin wrote: > No the problem left is documentations available in share/doc. > > I would like to push them elsewhere. Those documents are mostly useful for > historical reason (hence we want to keep them) but not really for daily use of > modern FreeBSD. > Another issue with those documentation, they are installed as text/ascii > version > in base, which makes most of them not really readable (as the documents has > not > be written for a ascii/text target but more for a PDF/html view - using pic(1) > for example) > > A plan was to push as sources in the svn doc repository and continue to build > them. This approach also have an issue: over the time roff evolved a bit and > while working on heirloom doctools import I had to fix a bunch of markup to > make > the rendering of those documents clean (also meaning almost noone should read > them considering some were not really readable). > > What I want to propose now, it to render them as PDF (html?) once and push > them > somewhere (to be defined) as static document on our documentation website. > Please doceng@ provide me a location where to push them. > Unless anyone on doceng@ objects within the next three days, I will create a new directory for the PDFs under doc/head/en_US.ISO8859-1/. Glen Hat:doceng@ signature.asc Description: PGP signature
Re: NFS client performance degradation when SMP enabled
Nope, it's an alc and the driver has very few changes between the old and new kernel (a change in the DMA channel from 3 to 4, whatever that means?). rick From: Ryan Stone Sent: Wednesday, May 24, 2017 8:12:54 PM To: Rick Macklem Cc: freebsd-current@freebsd.org Subject: Re: NFS client performance degradation when SMP enabled What type of network interface do you have? The Intel 1G (em and igb) were switched over to the "iflib" framework a few months ago and that could be the cause. ___ 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: Bug in make setting wrong MAKESYSPATH
>From Simon J. Gerraty: > Thomas Mueller wrote: > > I go into /BETA1/usr/ports/ports-mgmt/synth , run > > env MAKESYSPATH make all-depends-list > I assume you mean MAKESYSPATH=something? otherwise env itself should > vomit When I did those last examples, that last line was env MAKESYSPATH=/usr/share/mk make all-depends-list > > and then it seems to work correctly with no syntax error in > > /BETA1/usr/share/mk/bsd.compiler.mk > > > Maybe I need to file a bug. > For what? Bug occurs when building or configuring ports, syntax error in /BETA1/usr/share/mk/bsd.compiler.mk line 52 I don't know about other situations such as building doc. I could avoid this error either by setting (setenv or export, depending on shell) MAKESYSPATH or by null-mounting /BETA1/usr/ports at /usr/ports . > > What happens if src, ports and doc trees are installed on an NFS > > share, where there would be no FreeBSD installation? > Not sure what you mean. make doesn't care what the filesystem is > if there is a share/mk found in . or somewhere above it, the default > MAKESYSPATH will find it. Tom ___ 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: ino64: desastrous update - recommendations not working!!!
Am Wed, 24 May 2017 08:40:17 -0600 Alan Somers schrieb: > On Wed, May 24, 2017 at 4:42 AM, Hartmann, O. wrote: > > On almost every CURRENT that has been updated according to UPDATING > > entry 2017-05-23 regarding ino64, the recommended update process ends > > up in a desaster or, if the old environemnt/kernel is intact, itr > > doesn't work. > > > > Procedure: > > > > make -jX buildworld buildkernel [successful] > > make installkernel [successful] > > reboot > > Booting single user mode as recommended withnthe newly installed kernel > > BUMMER! > > When it comes to the point to type in the full path of /bin/sh, /bin/sh > > immediately fails with SIGNAL 12 > > Did you use a custom kernel config file without COMPAT_FREEBSD11? > ___ YES :-( First, I wasn't aware of the fact since it hasn't been mentioned in UPDATING, secondly, after I've read it many times, I realised too late that I had COMPAT_FREEBSD10 instead of COMPAT_FREEBSD11 defined ... after a very stressful day mistake after mistake ... Now, after recompiling a proper kernel, on working systems which do have the "old" world but the "new" kernel the SIGSYS for /bin/sh vanished and the procedure of updating went as expected. On boxes, where I had a terrible mixture of both world and no proper kernel, I recompiled the kernel stuff on a working and compatible system and copied /boot/kernel to the wrecked system and proceeded as recommended. That made things working again. -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpfBiDw3KBBr.pgp Description: OpenPGP digital signature