Re: Lenovo Legion 5 Intel speakers working ok!
On 22. 8. 25., Nuno Teixeira wrote: Hi! `pciconf -l | grep ^hdac`: --- hdac1@pci0:0:31:3: class=0x040380 rev=0x00 hdr=0x00 vendor=0x8086 device=0x06c8 subvendor=0x17aa subdevice=0x380f ^ hdac0@pci0:1:0:1: class=0x040300 rev=0xa1 hdr=0x00 vendor=0x10de device=0x10fa subvendor=0x17aa subdevice=0x3ffb --- I think hdac1 is what I'm looking for: --- hdac1@pci0:0:31:3: class=0x040380 rev=0x00 hdr=0x00 vendor=0x8086 device=0x06c8 subvendor=0x17aa subdevice=0x380f vendor = 'Intel Corporation' device = 'Comet Lake PCH cAVS' class = multimedia subclass = HDA --- (LENOVO_VENDORID 0x17aa) maybe: #define LENOVO_L5INTEL_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x380f) ? I guess. :-) JK Jung-uk Kim mailto:j...@freebsd.org>> escreveu no dia quinta, 25/08/2022 à(s) 20:15: On 22. 8. 25., Nuno Teixeira wrote: > ** Same config were imported from D30333 > <https://reviews.freebsd.org/D30333 <https://reviews.freebsd.org/D30333>>for Legion 5 AMD, PR 265632 > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>>for Intel version > > Nuno Teixeira mailto:edua...@freebsd.org> <mailto:edua...@freebsd.org <mailto:edua...@freebsd.org>>> > escreveu no dia quinta, 25/08/2022 à(s) 19:59: > > Hello, > > I have Lenovo Legion 5 Intel speakers working ok with device.hints: > --- > hint.hdaa.1.nid20.config="as=1 seq=0" > hint.hdaa.1.nid33.config="as=1 seq=15" > --- > > Same config were imported from D30333 > <https://reviews.freebsd.org/D30333 <https://reviews.freebsd.org/D30333>>and PR 265632 > <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632 <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265632>> for > Legion 5 AMD: > (sys/dev/sound/pci/hda/hdac.h) > --- > #define LENOVO_L5AMD_SUBVENDOR HDA_MODEL_CONSTRUCT(LENOVO, 0x381b) > --- > How do I found id for Intel version so I can submit a patch? Try "pciconf -l | grep ^hdac". You'll see subvendor and subdevice. OpenPGP_signature Description: OpenPGP digital signature
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 FYI, I removed the message. https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 Jung-uk Kim
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 Jung-uk Kim OpenPGP_signature Description: OpenPGP digital signature
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. Jung-uk Kim OpenPGP_signature Description: OpenPGP digital signature
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues Jung-uk Kim
Re: /usr/share/mk/bsd.sanitizer.mk not found
On 21. 8. 3., FreeBSD User wrote: > Hallo, > > running latest CURRENT as of FreeBSD 14.0-CURRENT #147 > main-n248437-600745f1e226: Mon Aug 2 > 18:34:54 CEST 2021 amd64, while compiling x11/nividia-driver, I get an error, > stating > /usr/share/mk/bsd.sanitizer.mk is missing. This file ist existent in > /usr/src/share/mk/, but > does not get installed. > > devel/libsysinfo is another port (requisite for firefox) failing due to the > same error. > > What's wrong here? It should be fixed with the following commit. https://cgit.freebsd.org/src/commit/?id=428a32edba4c3bf3cfc0e4cf240c1b29397ecdbb Jung-uk Kim
Re: Problem building x11/nvidia-driver; ref. n245494-6827435548d2
On 21. 3. 17., David Wolfskill wrote:
> My laptop is currently running main-n245489-15b82e00a164; after updating
> sources to n245498-096a84721670, I am performing a source-based update.
>
> A simialr update on my build machine (which is headless, and thus does
> not use anything related to X11) was successful.
>
> The laptop is set up to rebuild x11/nvidia-driver when the kernel
> is updated.
>
> The buildkernel step on it fails with:
>
> ...
> awk -f /usr/src/sys/conf/kmod_syms.awk nvidia-modeset.ko export_syms | xargs
> -J% objcopy % nvidia-modeset.ko
> ===> lib (all)
> ===> lib/libglvnd (all)
> ...
> ===> x11/driver (all)
> ===> x11/extension (all)
> ===> doc (all)
> make[6]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional
> (${MK_MANSPLITPKG} == "no")
> make[6]: Fatal errors encountered -- cannot continue
> make[6]: stopped in
> /common/S4/obj/usr/src/amd64.amd64/sys/CANARY/common/ports/x11/nvidia-driver/work/NVIDIA-FreeBSD-x86_64-460.56/doc
> *** Error code 1
>
> Stop.
>
>
> On reviewing the list of files changed in 15b82e00a164..096a84721670, I
> note a couple of promising-looking candidates:
>
> share/mk/bsd.opts.mk| 1 +
> share/mk/src.opts.mk| 1 -
>
> Reviewing the commit log for share/mk/bsd.opts.mk, I see that the most
> recent entry is:
>
> | commit 6827435548d257c672f934db5c6ff01012d96995
> | Author: Jung-uk Kim
> | Date: Tue Mar 16 14:16:10 2021 -0400
> |
> | pkgbase: Fix building out-of-tree manual pages
> |
> | c7e6cb9e08d6 introduced MK_MANSPLITPKG but it was not available for
> | building out-of-tree manual pages. For example, x11/nvidia-driver fails
> | with the following error:
> |
> | ===> doc (all)
> | make[3]: "/usr/share/mk/bsd.man.mk" line 53: Malformed conditional
> (${MK_MANSPLITPKG} == "no")
> | make[3]: Fatal errors encountered -- cannot continue
> |
> | Move the definition from src.opts.mk to bsd.opts.mk to make it visible.
>
> which looks ... apropos.
>
> Indeed, it appears that the n245494-6827435548d2 change was intended to
> fix the issue that I am now just seeing.
>
> But I readily confess that I have neither familairity nor expertise
> with share/mk/* (and that delving into it reminds me of "You are
> in a mazy twist of passages, all different")
>
> So... help? What do I need to do to be able to build the kernel now?
>
> (E.g., if I need to just skip building x11/nvidia-driver once, get
> everything installed, then build "normally" (with x11/nvidia-driver)
> -- that's fine; I just need a clue.)
cd /usr/src/share/mk && make install
Jung-uk Kim
OpenPGP_signature
Description: OpenPGP digital signature
Re: /etc/rc: ERROR: /etc/rc: no interface specified
On 21. 2. 24., Paul Mather wrote: > I have two systems on which I run -CURRENT. I updated them yesterday to the > following: FreeBSD 14.0-CURRENT #1 main-n245033-6ab923cbca87: Tue Feb 23 > 21:29:31 EST 2021. Both use the stock GENERIC-NODEBUG kernel. > > Since the update, the systems do not boot up correctly. I get this late in > the boot sequence: > > = > Enabling pf. > Updating /var/run/os-release done. > Creating and/or trimming log files. > Clearing /tmp (X related). > Updating motd:. > Starting syslogd. > Security policy loaded: MAC/ntpd (mac_ntpd) > Starting ntpd. > Starting powerd. > Mounting late filesystems:. > Configuring vt: blanktime. > Performing sanity check on sshd configuration. > Starting sshd. > Starting cron. > Starting background file system checks in 60 seconds. > /etc/rc: ERROR: /etc/rc: no interface specified > Usage: /etc/rc [0x00|0x01] > WARNING: attempt to domain_add(bluetooth) after domainfinalize() > /etc/rc: ERROR: Unsupported device: > = > > The last line is the final console output prior to the console login prompt. > > As well as the error during boot, none of the local services (installed via > pkg with startup scripts under /usr/local/etc/rc.d) start up. > > Also, I can't be certain this is new, but I just noticed it: I get a bunch of > extra KLDs loaded: > > = > 324 0x82e95000 25a8 ng_bluetooth.ko > 331 0x82e98000 a238 ng_hci.ko > 343 0x82ea3000 aac8 netgraph.ko > 351 0x82eae000 e250 ng_l2cap.ko > 361 0x82ebd0001be48 ng_btsocket.ko > = > > I don't know why it's loading bluetooth-related kernel modules as both > systems are rack-mounted servers with no bluetooth hardware in them to my > knowledge. > > I've looked in /usr/src/UPDATING for any recent note related to this but > can't find anything. My last update (circa 5th February 2021) worked fine. The following commit fixed the problem for me. https://cgit.freebsd.org/src/commit/?id=6e822e99570fdf4c564be04840a054bccc070222 Jung-uk Kim ___ 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: FreeBSD Friday
On 19. 11. 22., Thomas The Tank Engine wrote: > Hello all, > > Apologies if this is going to the wrong list, but I would like to make > FreeBSD my every day operating system. After researching, I became aware I > need a commit that was made only 2 days ago. It is suppose to be merged to > 12-STABLE soon, but I'd like to install today. > > The commit I need is referenced here: > https://github.com/wjguo/freebsd/pull/1#issuecomment-556060040 > > I haven't used FreeBSD since 4.4-RELEASE, and I think 12-stable would > probably be a better option ... I am willing to try out 13-CURRENT though. You need r354927 or later for stable/12. https://svnweb.freebsd.org/changeset/base/354927 Unfortunately, the last snapshot release was r354923 for 12-stable. http://docs.freebsd.org/cgi/mid.cgi?20191121172240.GB28849 > Does anyone have advice? Could someone point me to snapshot of 13-CURRENT > that'd include the commit I need? http://docs.freebsd.org/cgi/mid.cgi?20191121172230.GA28849 Jung-uk Kim ___ 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-current-kmod is still a problem at r353339
On 19. 10. 10., Mateusz Guzik wrote: > Probably whitespace issues from copypasting. I used dpaste since > people.freebsd.org was down. > > It's up, so: > https://people.freebsd.org/~mjg/pmap-fict3.diff This patch fixed a similar problem for me. FYI, I am using drm-devel-kmod for "AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx" (aka. Vega 8). Jung-uk Kim > On 10/10/19, Thomas Laus wrote: >> On 2019-10-10 12:21, Mateusz Guzik wrote: >>> Try this: >>> >>> http://dpaste.com/0P2MXF6 >>> >>> if it still fails, provide the panic info + the first debug line(the >>> one with "pv_table"). >>> >> This patch did not apply cleanly to my source tree checked out today. >> My pmap.c version is r353311. I saved the file to filename pmap.diff >> and ran the patch utility with the command "patch -i pmap.diff" from the >> /sys/amd64/amd64 directory. Should I be using a different utility to >> patch this file? The FreeBSD patch utility has always worked for me in >> the past. >> >> Tom >> >> -- >> Public Keys: >> PGP KeyID = 0x5F22FDC1 >> GnuPG KeyID = 0x620836CF signature.asc Description: OpenPGP digital signature
Re: Is the LSI/AVAGO/Broadcom 9280-16i4e supported?
On 19. 9. 1., Chris wrote: > Hello all, > I recently picked up an LSI/AVAGO/Broadcom 9280-16i4e card with > the intent of flashing it to IT mode (pass through). So as to > use it in one of my (FreeBSD) servers. > However; looking through the Hardware (support) section of the > release notes for 12; the closest I found was the 9260. > Does anyone have any experience with the 9280-16i4e on FreeBSD? > Does it work? Well? If not, anytime soon? I have one of these. % uname -rs FreeBSD 13.0-CURRENT % mfiutil show adapter mfi0 Adapter: Product Name: LSI MegaRAID SAS 9280-16i4e Serial Number: XX Firmware: 12.15.0-0239 RAID Levels: JBOD, RAID0, RAID1, RAID5, RAID6, RAID10, RAID50 Battery Backup: present NVRAM: 32K Onboard Memory: 512M Minimum Stripe: 8K Maximum Stripe: 1M % mfiutil show volumes mfi0 Volumes: Id SizeLevel Stripe State Cache Name mfid0 ( 36T) RAID-6 64K OPTIMAL Disabled FYI, it's been working fine for 7 years. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: r351066 lib/libc/tests/hash (install) … don't know how to make _testsDATA_FILESINS1_data/md5test-in
On 19. 8. 15., Graham Perrin wrote:
> Whilst running
> make installworld && etcupdate
>
> …
> ===> lib/libc/tests/hash (install)
> install -o root -g wheel -m 555 hash_test
> /usr/tests/lib/libc/hash/hash_test
> make[7]: don't know how to make _testsDATA_FILESINS1_data/md5test-in. Stop
> …
>
> Photo: <https://s.put.re/SgiyMLk1.png>
>
> make.conf:
>
> PORTS_MODULES= graphics/gpu-firmware-kmod graphics/drm-legacy-kmod
> emulators/virtualbox-ose-kmod
> DEFAULT_VERSIONS+=samba=4.8
> #
> <https://forums.freebsd.org/threads/share-your-make-conf-and-src-conf.63544/#post-402964>
>
> # WITHOUT_LLVM_TARGET_AARCH64=
> # WITHOUT_LLVM_TARGET_ARM=
> # WITHOUT_LLVM_TARGET_MIPS=
> # WITHOUT_LLVM_TARGET_POWERPC=
> # WITHOUT_LLVM_TARGET_SPARC=
> # WITHOUT_LLVM_TARGET_X86=
> #
> <https://forums.freebsd.org/threads/share-your-make-conf-and-src-conf.63544/#post-430516>
>
> WITHOUT_LLVM_TARGET_ALL=
> # ... mesa-dri doesn't use LLVM_DEFAULT. Set
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235215#c14>
> # in your make.conf if you want it to use LLVM_DEFAULT at your own risk.
> MESA_LLVM_VER=${LLVM_DEFAULT}
> <https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239682#c0>
> DEFAULT_VERSIONS+=llvm=90
I believe r351055 was the culprit.
https://svnweb.freebsd.org/changeset/base/351055
Note r351067 reverted it.
https://svnweb.freebsd.org/changeset/base/351067
Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
Re: CURRENT >r349150: boot failure in rc.conf.local
On 19. 6. 18., O. Hartmann wrote: > On all CURRENT boxes running CURRENT > r349150 we face the very same boot > failure, if /etc/rc.conf.local is present (i.e. on CURRENT, 13.0-CURRENT #7 > r349169: Tue Jun 18 10:34:13 CEST 2019 amd64): > > The box boots and thentries to start services denominated > in /etc/rc.conf.local, like net/openldap-server (slapd). The box is then stuck > at "startingt slapd", hitting Ctrl-T shows state "running", but Ctrl-C does > not > show any effect, except Ctrl-Alt-Del (if enabled) is effectively rebooting the > box. First I thought it might by a out-of-sync binary, but this phenomenon > spreads even over recently via make installed systems. Disabling OpenLDAP's > slapd at boot time gives my like rolling a dice the next service, named > (dns/bind914) or net/samba48 (samba_server) - you name it. The box gets stuck > forever and doesn't even start sshd to provide access. All boxes have IPv6 > enabled as well as IPFW. > > Another server running CURRENT (r349169, also amd64) without > utilizing /etc/rc.conf.local but with a bunch of jails is booting as usual! > > What happened here? Does anyone do have a hint or might know the cause? I had the same problem and reverting r349154 fixed the problem for me. https://svnweb.freebsd.org/changeset/base/349154 FYI... Jung-uk Kim ___ 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: Whine: "Could not open /dev/crypto: No such file or directory"
On 18. 12. 13., Yuri Pankov wrote: > David Wolfskill wrote: >> After update from r341844 to r342042, I see the above-cited "whine" when >> I attempt to use an SSH client on the upgraded machine. SSH client >> function seems OK, so the message is (apparently) merely annoying: >> >> freebeast(13.0-C)[2] uname -a >> FreeBSD freebeast.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT >> #403 r342042M/342042: Thu Dec 13 04:50:25 PST 2018 >> r...@freebeast.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/GENERIC >> amd64 >> freebeast(13.0-C)[3] ssh albert hostname >> Could not open /dev/crypto: No such file or directory >> albert.catwhisker.org >> freebeast(13.0-C)[4] echo $? >> 0 >> freebeast(13.0-C)[5] > > It's r342009, and I followed up on that commit. r342057 should shut up the error message. https://svnweb.freebsd.org/changeset/base/342057 Jung-uk Kim ___ 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: Linux is considering dropping x32.
On 18. 12. 11., Alexandre C. Guimarães wrote: > Hi. > > This is just informative. > > Apparently Linux is considering deprecate x32 support: > > https://lkml.org/lkml/2018/12/10/1151 x32 != i386 https://en.wikipedia.org/wiki/X32_ABI FYI, FreeBSD never supported x32 ABI. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 18. 11. 20., Charlie Li wrote: > Somewhere between r340491 and r340650, probably starting from r340595, > my ThinkPad W550s started spewing these messages repeatedly in the > system log since boot: > > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > (ID=3) has no handler (20181031/exfldio-428) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > As a result, I am now unable to query battery information at the very > least. r340490 is my last built revision with this working. I am pretty sure r340644 caused the regression. https://svnweb.freebsd.org/changeset/base/340644 Jung-uk Kim ___ 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: UEFI boot hangs after loader
On 18. 10. 24., Warner Losh wrote: > On Wed, Oct 24, 2018 at 10:33 AM Harry Newton wrote: > >> gryphon# efivar -N --hex $(efivar | grep Boot0002) >> : 01 00 00 00 98 00 55 00 45 00 46 00 49 00 3a 00 >> 0010: 20 00 4b 00 69 00 6e 00 67 00 73 00 74 00 6f 00 >> 0020: 6e 00 44 00 61 00 74 00 61 00 54 00 72 00 61 00 >> 0030: 76 00 65 00 6c 00 65 00 72 00 20 00 32 00 2e 00 >> 0040: 30 00 31 00 2e 00 30 00 30 00 00 00 02 01 0c 00 >> 0050: d0 41 03 0a 00 00 00 00 01 01 06 00 00 14 03 05 >> 0060: 06 00 03 00 04 01 2a 00 01 00 00 00 01 00 00 00 >> 0070: 00 00 00 00 40 06 00 00 00 00 00 00 90 90 90 90 >> 0080: 00 00 00 00 00 00 00 00 00 00 00 00 01 01 7f ff >> 0090: 04 00 01 04 4e 00 ef 47 64 2d c9 3b a0 41 ac 19 >> 00a0: 4d 51 d0 1b 4c e6 4b 00 69 00 6e 00 67 00 73 00 >> 00b0: 74 00 6f 00 6e 00 44 00 61 00 74 00 61 00 54 00 >> 00c0: 72 00 61 00 76 00 65 00 6c 00 65 00 72 00 20 00 >> 00d0: 32 00 2e 00 30 00 31 00 2e 00 30 00 30 00 00 00 >> 00e0: 7f ff 04 00 00 00 42 4f >> gryphon# >> > > Perfect. I'll decode this and see if I can figure out where we're going AFU. It looks familiar. http://docs.freebsd.org/cgi/mid.cgi?eadf5d63-a65a-338e-a3e0-f91b410052fa Jung-uk Kim >> On 24 October 2018 at 15:09, Warner Losh wrote: >> >>> >>> >>> On Wed, Oct 24, 2018 at 7:05 AM Harry Newton wrote: >>> >>>> Booted with the installer image makes efibootmgr to work as you said: >>>> >>>> gryphon# efibootmgr -v >>>> BootCurrent: 0002 >>>> Timeout : 2 seconds >>>> BootOrder : 0001, 0002 >>>> Boot0001* UEFI OS >>>> >>>> HD(1,GPT,b19ccd5d-7c6a-11e7-ae3e-28b2bde107e4,0x28,0x640)/File(\EFI\BOOT\BOOTX64.EFI) >>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null) >>>> >>>> However it (efibootmgr) hangs and doesn't return to the shell, though it >>>> is >>>> interruptible with ^C. >>>> >>>> The partition listed against Boot0001 is my efi partition. >>>> >>> >>> Can you do something like: >>> >>> sudo efivar -N --hex `sudo efivar | grep Boot0002` >>> >>> so I can have an example of a naughty boot variable? That's almost >>> certainly causing the heart-burn. >>> >>> Warner >>> >>> >>> >>>> /H >>>> >>>> On 23 October 2018 at 22:51, Kyle Evans wrote: >>>> >>>>> Hi, >>>>> >>>>> I suspect 4th vs. lua has no impact here, given the output shown -- >>>>> can you throw one of the installer images [0] on some removable media >>>>> and give that a shot for booting? If that works, we can explore UEFI >>>>> variables from there. >>>>> >>>>> efibootmgr will only work on a successful UEFI boot, unfortunately- if >>>>> we didn't make uefi loader -> kernel transition, then we don't have >>>>> access to runtime services. >>>>> >>>>> Thanks, >>>>> >>>>> Kyle Evans >>>>> >>>>> [0] >>>> https://download.freebsd.org/ftp/releases/amd64/amd64/ISO-IMAGES/12.0/ >>>>> >>>>> On Tue, Oct 23, 2018 at 4:23 PM Harry Newton wrote: >>>>>> >>>>>> I set LOADER_DEFAULT_INTERP=4th and went in /usr/src/stand and >>>> re-made >>>>> the >>>>>> binaries in /boot but this doesn't solve the problem. It did copy >>>>>> /boot/loader_4th.efi to /boot/loader.efi which is (according to >>>> uefi(8) >>>>>> which is what is called from /boot/boot1.efi and which contains the >>>>> strings >>>>>> I see on the console before the hang. But it must then call / read >>>>>> something else and I don't think it can find it. Not sure why it >>>> doesn't >>>>>> produce an error message. I *think* it may be something to do with >>>> EFI >>>>>> variables, but as efibootmgr doesn't work I can't explore this, >>>> despite >>>>>> efirt being in the kernel. >>>>>> >>>>>> Suggestions received welcomed, and new suggestions / leads to follow >>>> also >>>>>> very much welcomed. >>>>>> >>>>>> /H >>>>>> >>>>>> >>>>>> On 23 October 2018 at 21:33, Harry Newton wrote: >>>>>
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 12., Harry Schmalzbauer wrote:
> Am 12.10.2018 um 07:41 schrieb Dag-Erling Smørgrav:
>> Jung-uk Kim writes:
>>> I forgot to patch one more file, i.e., Makefile.inc1. Please try the
>>> attached patch instead.
>> Thanks, I missed that too.
>>
>> DES
>
> Even with 339326 (adjusting Makefile.inc1) I get the foollowing build
> error (compiling 339326-amd64 on stable/11-amd64):
> building shared library libprivateldns.so.5
> cc -target x86_64-unknown-freebsd12.0
> --sysroot=/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src
>
> /amd64.amd64/tmp
> -B/usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin
> -f
> stack-protector-strong -shared -Wl,-x -Wl,--fatal-warnings
> -Wl,--warn-shared-textrel -o libprivateldns.so.5.full -Wl,-soname,libp
> rivateldns.so.5 `NM='nm' NMFLAGS='' lorder buffer.pico dane.pico
> dname.pico dnssec.pico dnssec_sign.pico dnssec_verify.pico dnsse
> c_zone.pico duration.pico error.pico higher.pico host2str.pico
> host2wire.pico keys.pico net.pico packet.pico parse.pico radix.pico
> rbtree.pico rdata.pico resolver.pico rr.pico rr_functions.pico
> sha1.pico sha2.pico str2host.pico tsig.pico update.pico util.pico
> wire2host.pico zone.pico b64_ntop.pico b64_pton.pico | tsort -q` -lssl
> -lcrypto
> /usr/local/share/deploy-tools/obj/HEAD-S12RP/usr/local/share/deploy-tools/HEAD/src/amd64.amd64/tmp/usr/bin/ld:
> error: unable to fi
> nd library -lssl
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> *** [libprivateldns.so.5.full] Error code 1
https://docs.freebsd.org/cgi/mid.cgi?d218a9de-bfac-3a66-6197-4b58d5a78a94
The remaining patch is attached.
Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 339326)
+++ Makefile.inc1 (working copy)
@@ -2631,9 +2631,10 @@ lib/librtld_db__L: lib/libprocstat__L
_secure_lib_libcrypto= secure/lib/libcrypto
_secure_lib_libssl= secure/lib/libssl
lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L
+secure/lib/libcrypto__L: lib/libthr__L
.if ${MK_LDNS} != "no"
_lib_libldns= lib/libldns
-lib/libldns__L: secure/lib/libcrypto__L
+lib/libldns__L: secure/lib/libssl__L
.endif
.if ${MK_OPENSSH} != "no"
_secure_lib_libssh= secure/lib/libssh
signature.asc
Description: OpenPGP digital signature
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 12., Jung-uk Kim wrote:
> On 18. 10. 11., Glen Barber wrote:
>> On Thu, Oct 11, 2018 at 10:55:46PM +, Glen Barber wrote:
>>> On Thu, Oct 11, 2018 at 10:32:34PM +, Glen Barber wrote:
>>>> I still see a failure with this applied.
>>>>
>>>> ===> lib/libldns (obj,all,install)
>>>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lssl
>>>> --- libprivateldns.so.5.full ---
>>>> *** [libprivateldns.so.5.full] Error code 1
>>>>
>>>> I'll prune .OBJDIR and re-run without -jN to eliminate the possibility
>>>> of a build race.
>>>>
>>>
>>> It does not appear to be a build race.
>>>
>>> ===> secure/lib/libcrypto (obj,all,install)
>>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lpthread
>>> *** Error code 1
>>>
>>> Stop.
>>> make[4]: stopped in /usr/src/secure/lib/libcrypto
>>> *** Error code 1
>>>
>>
>> In fact, on closer inspection, this patch breaks every architecture.
>
> I forgot to patch one more file, i.e., Makefile.inc1. Please try the
> attached patch instead.
Darn, I attached an incomplete patch. This should be final.
Sorry about the brain farts. I need some sleep. :-(
Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 339324)
+++ Makefile.inc1 (working copy)
@@ -2534,8 +2534,8 @@ _prebuild_libs= ${_kerberos5_lib_libasn1} \
${_cddl_lib_libctf} \
lib/libufs \
lib/libutil lib/libpjdlog ${_lib_libypclnt} lib/libz lib/msun \
- ${_secure_lib_libcrypto} ${_lib_libldns} \
- ${_secure_lib_libssh} ${_secure_lib_libssl}
+ ${_secure_lib_libcrypto} ${_secure_lib_libssl} \
+ ${_lib_libldns} ${_secure_lib_libssh}
.if ${MK_GNUCXX} != "no"
_prebuild_libs+= gnu/lib/libstdc++ gnu/lib/libsupc++
@@ -2631,9 +2631,10 @@ lib/librtld_db__L: lib/libprocstat__L
_secure_lib_libcrypto= secure/lib/libcrypto
_secure_lib_libssl= secure/lib/libssl
lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L
+secure/lib/libcrypto__L: lib/libthr__L
.if ${MK_LDNS} != "no"
_lib_libldns= lib/libldns
-lib/libldns__L: secure/lib/libcrypto__L
+lib/libldns__L: secure/lib/libssl__L
.endif
.if ${MK_OPENSSH} != "no"
_secure_lib_libssh= secure/lib/libssh
Index: lib/libldns/Makefile
===
--- lib/libldns/Makefile (revision 339324)
+++ lib/libldns/Makefile (working copy)
@@ -19,7 +19,7 @@ SRCS= buffer.c dane.c dname.c dnssec.c dnssec_sign
SRCS+= b64_ntop.c b64_pton.c
-LIBADD= crypto
+LIBADD= ssl crypto
WARNS ?= 3
Index: share/mk/src.libnames.mk
===
--- share/mk/src.libnames.mk (revision 339324)
+++ share/mk/src.libnames.mk (working copy)
@@ -273,7 +273,7 @@ _DP_mp= crypto
_DP_memstat= kvm
_DP_magic= z
_DP_mt= sbuf bsdxml
-_DP_ldns= crypto
+_DP_ldns= ssl crypto
.if ${MK_OPENSSL} != "no"
_DP_fetch= ssl crypto
.else
signature.asc
Description: OpenPGP digital signature
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 12., Jung-uk Kim wrote:
> On 18. 10. 11., Glen Barber wrote:
>> On Thu, Oct 11, 2018 at 10:55:46PM +, Glen Barber wrote:
>>> On Thu, Oct 11, 2018 at 10:32:34PM +, Glen Barber wrote:
>>>> I still see a failure with this applied.
>>>>
>>>> ===> lib/libldns (obj,all,install)
>>>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lssl
>>>> --- libprivateldns.so.5.full ---
>>>> *** [libprivateldns.so.5.full] Error code 1
>>>>
>>>> I'll prune .OBJDIR and re-run without -jN to eliminate the possibility
>>>> of a build race.
>>>>
>>>
>>> It does not appear to be a build race.
>>>
>>> ===> secure/lib/libcrypto (obj,all,install)
>>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lpthread
>>> *** Error code 1
>>>
>>> Stop.
>>> make[4]: stopped in /usr/src/secure/lib/libcrypto
>>> *** Error code 1
>>>
>>
>> In fact, on closer inspection, this patch breaks every architecture.
>
> I forgot to patch one more file, i.e., Makefile.inc1. Please try the
> attached patch instead.
Darn, I attached an incomplete patch. This should be final.
Sorry about the brain farts. I need some sleep. :-(
Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 339324)
+++ Makefile.inc1 (working copy)
@@ -2534,8 +2534,8 @@ _prebuild_libs= ${_kerberos5_lib_libasn1} \
${_cddl_lib_libctf} \
lib/libufs \
lib/libutil lib/libpjdlog ${_lib_libypclnt} lib/libz lib/msun \
- ${_secure_lib_libcrypto} ${_lib_libldns} \
- ${_secure_lib_libssh} ${_secure_lib_libssl}
+ ${_secure_lib_libcrypto} ${_secure_lib_libssl} \
+ ${_lib_libldns} ${_secure_lib_libssh}
.if ${MK_GNUCXX} != "no"
_prebuild_libs+= gnu/lib/libstdc++ gnu/lib/libsupc++
@@ -2631,9 +2631,10 @@ lib/librtld_db__L: lib/libprocstat__L
_secure_lib_libcrypto= secure/lib/libcrypto
_secure_lib_libssl= secure/lib/libssl
lib/libradius__L secure/lib/libssl__L: secure/lib/libcrypto__L
+secure/lib/libcrypto__L: lib/libthr__L
.if ${MK_LDNS} != "no"
_lib_libldns= lib/libldns
-lib/libldns__L: secure/lib/libcrypto__L
+lib/libldns__L: secure/lib/libssl__L
.endif
.if ${MK_OPENSSH} != "no"
_secure_lib_libssh= secure/lib/libssh
Index: lib/libldns/Makefile
===
--- lib/libldns/Makefile (revision 339324)
+++ lib/libldns/Makefile (working copy)
@@ -19,7 +19,7 @@ SRCS= buffer.c dane.c dname.c dnssec.c dnssec_sign
SRCS+= b64_ntop.c b64_pton.c
-LIBADD= crypto
+LIBADD= ssl crypto
WARNS ?= 3
Index: share/mk/src.libnames.mk
===
--- share/mk/src.libnames.mk (revision 339324)
+++ share/mk/src.libnames.mk (working copy)
@@ -273,7 +273,7 @@ _DP_mp= crypto
_DP_memstat= kvm
_DP_magic= z
_DP_mt= sbuf bsdxml
-_DP_ldns= crypto
+_DP_ldns= ssl crypto
.if ${MK_OPENSSL} != "no"
_DP_fetch= ssl crypto
.else
signature.asc
Description: OpenPGP digital signature
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 11., Glen Barber wrote:
> On Thu, Oct 11, 2018 at 10:55:46PM +, Glen Barber wrote:
>> On Thu, Oct 11, 2018 at 10:32:34PM +, Glen Barber wrote:
>>> I still see a failure with this applied.
>>>
>>> ===> lib/libldns (obj,all,install)
>>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lssl
>>> --- libprivateldns.so.5.full ---
>>> *** [libprivateldns.so.5.full] Error code 1
>>>
>>> I'll prune .OBJDIR and re-run without -jN to eliminate the possibility
>>> of a build race.
>>>
>>
>> It does not appear to be a build race.
>>
>> ===> secure/lib/libcrypto (obj,all,install)
>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>> /usr/src/crypto/openssl/crypto/err/err.c: In function 'err_load_strings':
>> /usr/src/crypto/openssl/crypto/err/err.c:311: warning: passing argument 2
>> of 'lh_ERR_STRING_DATA_insert' discards qualifiers from pointer target type
>> /usr/obj/usr/src/powerpc.powerpc/tmp/usr/bin/ld: cannot find -lpthread
>> *** Error code 1
>>
>> Stop.
>> make[4]: stopped in /usr/src/secure/lib/libcrypto
>> *** Error code 1
>>
>
> In fact, on closer inspection, this patch breaks every architecture.
I forgot to patch one more file, i.e., Makefile.inc1. Please try the
attached patch instead.
Jung-uk Kim
Index: Makefile.inc1
===
--- Makefile.inc1 (revision 339324)
+++ Makefile.inc1 (working copy)
@@ -2534,8 +2534,8 @@ _prebuild_libs= ${_kerberos5_lib_libasn1} \
${_cddl_lib_libctf} \
lib/libufs \
lib/libutil lib/libpjdlog ${_lib_libypclnt} lib/libz lib/msun \
- ${_secure_lib_libcrypto} ${_lib_libldns} \
- ${_secure_lib_libssh} ${_secure_lib_libssl}
+ ${_secure_lib_libcrypto} ${_secure_lib_libssl} \
+ ${_lib_libldns} ${_secure_lib_libssh}
.if ${MK_GNUCXX} != "no"
_prebuild_libs+= gnu/lib/libstdc++ gnu/lib/libsupc++
Index: lib/libldns/Makefile
===
--- lib/libldns/Makefile (revision 339324)
+++ lib/libldns/Makefile (working copy)
@@ -19,7 +19,7 @@ SRCS= buffer.c dane.c dname.c dnssec.c dnssec_sign
SRCS+= b64_ntop.c b64_pton.c
-LIBADD= crypto
+LIBADD= ssl crypto
WARNS ?= 3
Index: share/mk/src.libnames.mk
===
--- share/mk/src.libnames.mk (revision 339324)
+++ share/mk/src.libnames.mk (working copy)
@@ -273,7 +273,7 @@ _DP_mp= crypto
_DP_memstat= kvm
_DP_magic= z
_DP_mt= sbuf bsdxml
-_DP_ldns= crypto
+_DP_ldns= ssl crypto
.if ${MK_OPENSSL} != "no"
_DP_fetch= ssl crypto
.else
signature.asc
Description: OpenPGP digital signature
Re: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 18. 10. 11., Jung-uk Kim wrote:
> On 18. 10. 11., Justin Hibbits wrote:
>> On Thu, 11 Oct 2018 19:07:45 + Glen Barber
>> wrote:
>>
>>> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote:
>>>> Maybe related to recent Glen's Heads-UP?
>>>>
>>>> https://lists.freebsd.org/pipermail/freebsd-current/2018-October/07
1581.html
>>>>
>>>>
>>>
>>> No, this is different, and more recent than the heads-up. I
>>> now see failures on powerpc, powerpc64, powerpcspe, sparc64,
>>> and arm.
>>>
>>> I'm trying to track down what commit introduced this, but it
>>> was not the final merge from the projects/openssl111 branch.
>>>
>>> Glen
>>>
>>
>> Seems r339303 is the cuplrit. Reverting this gets my build
>> completing.
>
> It seems ldns now requires libssl.so to support DANE-TA. Please
> try the attached patch.
I forgot to update share/mk/src.libnames.mk. Please ignore the
previous patch and use the attached one instead.
Sorry,
Jung-uk Kim
-BEGIN PGP SIGNATURE-
iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAlu/w9cACgkQfJ+WJvzb
8Uahywf9EkFSt4r6d7wdW5i0zU9VBxIyZ6xSuKq0zTJMKifXndzcpEQgyhQfyvkg
0c3eH+974kR61Y+DnycoUe8Q8XAHfaMe5CuPZ2OJTiu3RLGaBxAkfYgfydJn70/J
amQMsDhD9bKSo4YaoydqzMtGDU3C6CwLSZA3Ww8IwzIAElkI9Orx02hShYr8GQvK
EoR5wOyvl+XqrGHbbuzusROCVrHHGgFpwhSvcDOBvPB0xEsmEJkv+scZNNArgjF4
YjTQW77Jv0l5VO3Fa0rRw/YOMs4VVlycDrov3RL4/ILAzjig6nE6bomjiFYbmKjQ
m4/KyaMCeCfDPn9d3mc5jZqDaOUE7A==
=VBUK
-END PGP SIGNATURE-
Index: lib/libldns/Makefile
===
--- lib/libldns/Makefile (revision 339318)
+++ lib/libldns/Makefile (working copy)
@@ -19,7 +19,7 @@ SRCS= buffer.c dane.c dname.c dnssec.c dnssec_sign
SRCS+= b64_ntop.c b64_pton.c
-LIBADD= crypto
+LIBADD= ssl crypto
WARNS ?= 3
Index: share/mk/src.libnames.mk
===
--- share/mk/src.libnames.mk (revision 339318)
+++ share/mk/src.libnames.mk (working copy)
@@ -273,7 +273,7 @@ _DP_mp= crypto
_DP_memstat= kvm
_DP_magic= z
_DP_mt= sbuf bsdxml
-_DP_ldns= crypto
+_DP_ldns= ssl crypto
.if ${MK_OPENSSL} != "no"
_DP_fetch= ssl crypto
.else
___
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: r339289 buildworld stopped in /usr/src/secure/lib/libcrypto
On 18. 10. 11., Justin Hibbits wrote: > On Thu, 11 Oct 2018 19:07:45 + > Glen Barber wrote: > >> On Thu, Oct 11, 2018 at 09:05:52AM +0200, Raúl wrote: >>> Maybe related to recent Glen's Heads-UP? >>> >>> https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071581.html >>> >> >> No, this is different, and more recent than the heads-up. I now see >> failures on powerpc, powerpc64, powerpcspe, sparc64, and arm. >> >> I'm trying to track down what commit introduced this, but it was not >> the final merge from the projects/openssl111 branch. >> >> Glen >> > > Seems r339303 is the cuplrit. Reverting this gets my build completing. It seems ldns now requires libssl.so to support DANE-TA. Please try the attached patch. Jung-uk Kim Index: lib/libldns/Makefile === --- lib/libldns/Makefile (revision 339318) +++ lib/libldns/Makefile (working copy) @@ -19,7 +19,7 @@ SRCS= buffer.c dane.c dname.c dnssec.c dnssec_sign SRCS+= b64_ntop.c b64_pton.c -LIBADD= crypto +LIBADD= ssl crypto WARNS ?= 3 signature.asc Description: OpenPGP digital signature
Re: EFI issues
On 18. 8. 3., Warner Losh wrote:
> On Sun, Jul 29, 2018 at 6:35 AM, O. Hartmann wrote:
>>>>> 'efibootmgr -v' output:
>>>>>
>>>>> BootCurrent: 0004
>>>>> Timeout: 1 seconds
>>>>> BootOrder : 0001, 0002, 0003, 0004
>>>>> Boot0001* Hard Drive BBS(HD,,0x0)
>>>>> Boot0002* Network Card BBS(Network,,0x0)
>>>>> Boot0003* UEFI OS
>>>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
>>>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>>>> Path(0,0,ae84b11df581724e85442bab0c2cac5c0202) +Boot0004*
>> UEFI: SanDisk
>>>>> PciRoot(0x0)/Pci(0x1d,0x0)/USB(0x1,0x0)/USB(0x4,0x0)/HD(
>> 1,MBR,0x90909090,0x1,0x640)
>>>>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
>> 530061006e004400690073006b00)
>>
> ...
>
>>> I've updated BIOS (which alone didn't change anything) and executed
>>> commands you suggested, and it helped! Thanks!
>>>
>>> Now 'efibootmgr -v' output looks like this:
>>>
>>> BootCurrent:
>>> Timeout: 1 seconds
>>> BootOrder : , 0004, 0006, 0003, 0007
>>> +Boot* FreeBSD
>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\efi\boot\BOOTx64.efi)
>>> ada0p1:/efi/boot/BOOTx64.efi (null) Boot0004* Hard Drive BBS(HD,,0x0)
>>> Boot0006* Network Card BBS(Network,,0x0)
>>> Boot0003* UEFI OS
>>> HD(1,GPT,78459ec0-9303-11e8-97e6-98ded0009b1c,0x28,
>> 0x64000)/File(\EFI\BOOT\BOOTX64.EFI)
>>> ada0p1:/EFI/BOOT/BOOTX64.EFI (null)
>>> Path(0,0,ef47642dc93ba041ac194d51d01b4ce65200650061006c00740065006b00
>> 200042006f006f00740020004100670065006e007400)
>>> Boot0007* UEFI: SanDisk
>>> PciRoot(0x0)/Pci(0x14,0x0)/USB(0x9,0x0)/HD(1,MBR,0x90909090,0x1,0x640)
>>> VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,
>> 340043003500330031003000300031003500340031003000310035003100
>> 30003900300039003500)
>>>
>>>
>>> Unreferenced Variables:
>>>
>>> This is strange, because the only difference I see is that Boot has
>>> lowercase filenames ('/efi/boot/BOOTx64.efi' vs
>>> '/EFI/BOOT/BOOTX64.EFI'). I'm wondering if that's the only reason it
>>> wasn't working before?
>>>
>>>> - --
>>>> O. Hartmann
>> [...]
>>
>>>
>>> Roman Bogorodskiy
>>
>> I'm glad to be of help. But it was a "wild guess", not experience or
>> decend knowledge.
>> Maybe there is an issue with recent UEFI/boot/stand implementation since
>> this portion of
>> FreeBSD is under heavy development or has been under such ...
>>
>> Ypu shpuld consider contacting Warner Losh or Toomas Soome (on the current@
>> list, there
>> is a thread entitelt "[UEFI] Boot issues on some UEFI implementations"
>> started by myself
>> targetting some weird FreeBSD/UEFI issues. Toomas Soome gave me the hint
>> with
>> efibootmgr(8) and I figured out by learning from the definitions, that on
>> specific UEFI
>> implementations, the boot path "/efi/boot/bootx64.efi" is considered the
>> default for
>> changeable media (like USB flash drives) and not necessaryly the default
>> for SATA/SAS
>> devices.
>
>
> Case shouldn't matter. If it does, I've done something wrong. Internally,
> we convert to lower case and the filesystem is case insensitive in this
> case.
>
> The whole default file thing is something I thought I understood really,
> really well, but it's becoming clear that there's issues that are clear as
> mud. We should be coping with this junk in the installer...
I had a similar problem with one of my boxes and the workaround, i.e.,
adding a duplicate entry with efibootmgr(8), fixed it for me, too.
It seems the BIOS adds bogus data at the end.
Bad variable added by BIOS:
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0009
: 01 00 00 00 62 00 55 00 45 00 46 00 49 00 20 00
0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68
0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29
0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02
0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
0050: 4f 00 4f 00 54 00 5c 00 42 00 4f 00 4f 00 54 00
0060: 58 00 36 00 34 00 2e 00 45 00 46 00 49 00 00 00
0070: 7f ff 04 00 aa 55 00 00
Good variable added by efibootmgr:
8be4df61-93ca-11d2-aa0d-00e098032b8c-Boot0003
: 01 00 00 00 5e 00 55 00 45 00 46 00 49 00 20 00
0010: 4f 00 53 00 00 00 04 01 2a 00 02 00 00 00 00 68
0020: 09 00 00 00 00 00 00 18 03 00 00 00 00 00 d9 29
0030: 2b 57 b4 37 24 48 b0 a1 0a d8 23 6b 38 db 02 02
0040: 04 04 30 00 5c 00 45 00 46 00 49 00 5c 00 42 00
0050: 6f 00 6f 00 74 00 5c 00 62 00 6f 00 6f 00 74 00
0060: 78 00 36 00 34 00 2e 00 65 00 66 00 69 00 00 00
0070: 7f ff 04 00
Actually, "efibootmgr -v" hangs or crashes depending on current boot
order. My guess is device path printing is not robust enough to ignore
the bogus data.
Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
Re: atomic changes break drm-next-kmod?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 07/03/2018 15:23, Jung-uk Kim wrote: > On 07/03/2018 15:02, John Baldwin wrote: >> On 7/3/18 11:28 AM, Niclas Zeising wrote: >>> On 07/03/18 17:02, O. Hartmann wrote: >>>> -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 >>>> >>>> Am Tue, 3 Jul 2018 10:19:57 -0400 Michael Butler >>>> schrieb: >>>> >>>>> It seems recent changes (SVN r335873?) may have broken >>>>> drm-next-kmod .. >>>>> >>>>> --- i915_drv.o --- In file included from i915_drv.c:30: In >>>>> file included from >>>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gp lv2/include/linux/acpi.h:26: >>>>> >>>>> >>>>> In file included from >>>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gp lv2/include/linux/device.h:4: >>>>> >>>>> >>>>> In file included from >>>>> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35: >>>>> >>>>> >>>>> In file included from >>>>> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37: >>>>> >>>>> >>>>> In file included from /usr/src/sys/sys/systm.h:44: >>>>> ./machine/atomic.h:450:29: error: invalid operand for >>>>> instruction ATOMIC_ASM(clear,long, "andq %1,%0", "ir", >>>>> ~v); ^ :1:7: note: instantiated into assembly >>>>> here andq $9223372036854775807,40672(%r14) >>>>> ^ 1 error generated. *** [i915_drv.o] >>>>> Error code 1 >>>>> >>>>> make[3]: stopped in >>>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915 >>>>> >>>>> >>>>> - --- i915_gem.o --- >>>>> In file included from i915_gem.c:28: In file included from >>>>> >>>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm /drmP.h:38: >>>>> >>>>> >>>>> In file included from /usr/src/sys/sys/malloc.h:42: >>>>> In file included from /usr/src/sys/sys/systm.h:44: >>>>> ./machine/atomic.h:449:29: error: invalid operand for >>>>> instruction ATOMIC_ASM(set, long, "orq %1,%0", "ir", >>>>> v); ^ :1:6: note: instantiated into assembly >>>>> here orq $-9223372036854775808,40672(%r14) >>>>> ^~ 1 error generated. *** [i915_gem.o] >>>>> Error code 1 >>>>> >>>>> ___ >>>>> 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" >>>> >>>> >>>> It breaks also graphics/drm-stable-kmod (see PR 229484, >>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, >>>> same error as you described above) and also >>>> emulators/virtualbox-ose-kmod. As long as CURRENT revision >>>> is < r335873, those kmod compile well. >>> >>> We are looking into why both the drm ports fail. Regards >>> >> >> I haven't yet tested an amd64 kernel with this, but I think this >> change to sys/amd64/include/atomic.h might fix it: >> >> Index: atomic.h >> ======= >> >> >> - --- atomic.h (revision 335896) >> +++ atomic.h (working copy) @@ -446,10 +446,10 @@ >> ATOMIC_ASM(clear,int, "andl %1,%0", "ir", ~ >> ATOMIC_ASM(add, int, "addl %1,%0", "ir", v); >> ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v); >> >> -ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); >> -ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v); >> -ATOMIC_ASM(add, long, "addq %1,%0", "ir", v); >> -ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v); >> +ATOMIC_ASM(set, long, "orq %1,%0", "er", v); >> +ATOMIC_ASM(clear,long, "andq %1,%0", "er", ~v); >> +ATOMIC_ASM(add, long, "addq %1,%0", "er", v); >> +ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v); >> >> #define ATOMIC_LOADSTORE(TYPE) \ >> ATOMIC_LOAD(TYPE);\ > > Isn't "Z" better than "e" in this case? Never mind, brain fart. These instructions are sign-extended. Sorry for the noise. Jung-uk Kim -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAls7zy8ACgkQfJ+WJvzb 8UYiOgf+PSb+Mv7UGCTUlftCiRmYYOW6ElMZSdr4tPinMocn4b/V9KJDqKOgO1SX B2KCQHgSYt4Y+STiSrcCdhIkqCeIxdqJGHdTNpnpiUm7C+B50MrKgZo6n1xnlcCM d4thqf0T/ZMaVaVEkZ42FTnmdXFo0L3jHNCHHYrpnXXXfRLJF6j5Q5Uetr1GEUJX rpV2NIXMdk308qy4EvagLd0DEtT85QAjuG124nKh5FoSFD+5wBGFVrQWk4v4LVyd rzBNM55JbTlEIFASlFjpiWJVhGvDzNVwN9XRxacYVgfEv23AMEibqhK12V48Lto/ X1/qHA0T9HC+gu/Eol+53AtU/P8ZyQ== =cHxX -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: atomic changes break drm-next-kmod?
On 07/03/2018 15:02, John Baldwin wrote: > On 7/3/18 11:28 AM, Niclas Zeising wrote: >> On 07/03/18 17:02, O. Hartmann wrote: >>> -BEGIN PGP SIGNED MESSAGE- >>> Hash: SHA512 >>> >>> Am Tue, 3 Jul 2018 10:19:57 -0400 >>> Michael Butler schrieb: >>> >>>> It seems recent changes (SVN r335873?) may have broken drm-next-kmod .. >>>> >>>> --- i915_drv.o --- >>>> In file included from i915_drv.c:30: >>>> In file included from >>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26: >>>> In file included from >>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4: >>>> In file included from >>>> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35: >>>> In file included from >>>> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37: >>>> In file included from /usr/src/sys/sys/systm.h:44: >>>> ./machine/atomic.h:450:29: error: invalid operand for instruction >>>> ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v); >>>> ^ >>>> :1:7: note: instantiated into assembly here >>>> andq $9223372036854775807,40672(%r14) >>>> ^ >>>> 1 error generated. >>>> *** [i915_drv.o] Error code 1 >>>> >>>> make[3]: stopped in >>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915 >>>> --- i915_gem.o --- >>>> In file included from i915_gem.c:28: >>>> In file included from >>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38: >>>> In file included from /usr/src/sys/sys/malloc.h:42: >>>> In file included from /usr/src/sys/sys/systm.h:44: >>>> ./machine/atomic.h:449:29: error: invalid operand for instruction >>>> ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); >>>> ^ >>>> :1:6: note: instantiated into assembly here >>>> orq $-9223372036854775808,40672(%r14) >>>> ^~ >>>> 1 error generated. >>>> *** [i915_gem.o] Error code 1 >>>> >>>> ___ >>>> 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" >>> >>> >>> It breaks also graphics/drm-stable-kmod (see PR 229484, >>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you >>> described >>> above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision >>> is < r335873, >>> those kmod compile well. >> >> We are looking into why both the drm ports fail. >> Regards >> > > I haven't yet tested an amd64 kernel with this, but I think this change to > sys/amd64/include/atomic.h > might fix it: > > Index: atomic.h > === > --- atomic.h (revision 335896) > +++ atomic.h (working copy) > @@ -446,10 +446,10 @@ ATOMIC_ASM(clear,int, "andl %1,%0", "ir", ~ > ATOMIC_ASM(add, int, "addl %1,%0", "ir", v); > ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v); > > -ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); > -ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v); > -ATOMIC_ASM(add, long, "addq %1,%0", "ir", v); > -ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v); > +ATOMIC_ASM(set, long, "orq %1,%0", "er", v); > +ATOMIC_ASM(clear,long, "andq %1,%0", "er", ~v); > +ATOMIC_ASM(add, long, "addq %1,%0", "er", v); > +ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v); > > #define ATOMIC_LOADSTORE(TYPE) \ > ATOMIC_LOAD(TYPE); \ Isn't "Z" better than "e" in this case? Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: TSC calibration in virtual machines
On 06/27/2018 13:05, Rodney W. Grimes wrote: > There are several white papers, including one from VMWare about what > they have done to help with the time keeping problems. https://www.vmware.com/files/pdf/techpaper/Timekeeping-In-VirtualMachines.pdf Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: TSC calibration in virtual machines
On 06/27/2018 13:01, Ryan Stone wrote: > I would guess that the calibration can fail because when running under > the hypervisor, the FreeBSD guest code can be descheduled at the wrong > time. As I recall, the current algorithm looks like: > > 1. Sample rdtsc > 2. Use a fixed-frequency timer to busy-wait for exactly 1 second > 3. Sample rdtsc again > 4. tsc_freq = sample2 - sample1; > > If we are descheduled between 2 and 3, the time we spend off-cpu will > not be accounted for at step 4. On bare-metal this is not possible as > neither the scheduler nor interrupts are not running yet. > > Although, come to think of it, I seem to recall something about SMI > interrupts mucking this up long in the past, for exactly the same > reason. I think it was legacy USB device emulation for certain Intel chipset-based motherboards. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: TSC calibration in virtual machines
On 06/27/2018 12:47, Alan Somers wrote: > On Wed, Jun 27, 2018 at 10:36 AM, Jung-uk Kim <mailto:j...@freebsd.org>> wrote: > > On 06/27/2018 03:14, Andriy Gapon wrote: > > > > It seems that TSC calibration in virtual machines sometimes can do more > harm > > than good. Should we default to trusting the information provided by a > hypervisor? > > > > Specifically, I am observing a problem on GCE instances where > calibrated TSC > > frequency is about 10% lower than advertised frequency. And apparently > the > > advertised frequency is the right one. > > > > I found this thread with similar reports and a variety of workarounds > from > > administratively disabling the calibration to switching to a different > timecounter: > > > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/80.html > > <https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/80.html> > > We already do that for VMware hosts since r221214. > > https://svnweb.freebsd.org/changeset/base/221214 > <https://svnweb.freebsd.org/changeset/base/221214> > > We should do the same for each hypervisor. > > We probably should. But why does calibration fail in the first place? Because multiple guests are sharing same physical CPUs and guest OS has no control, timing cannot be 100% accurate. > If it can fail in a VM, then it can probably fail on bare metal too. It > would be worth investigating. It does not "fail" in bare metal because we have almost complete control. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: TSC calibration in virtual machines
On 06/27/2018 03:14, Andriy Gapon wrote: > > It seems that TSC calibration in virtual machines sometimes can do more harm > than good. Should we default to trusting the information provided by a > hypervisor? > > Specifically, I am observing a problem on GCE instances where calibrated TSC > frequency is about 10% lower than advertised frequency. And apparently the > advertised frequency is the right one. > > I found this thread with similar reports and a variety of workarounds from > administratively disabling the calibration to switching to a different > timecounter: > https://lists.freebsd.org/pipermail/freebsd-cloud/2017-January/80.html We already do that for VMware hosts since r221214. https://svnweb.freebsd.org/changeset/base/221214 We should do the same for each hypervisor. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: New ACPI Errors
On 02/13/2018 17:34, Claude Buisson wrote: > On 02/13/2018 22:49, Pete Wright wrote: >> Hello, >> I have started seeing a lot of these messages spam my system log: >> >> ACPI Error: No pointer back to namespace node in package >> 0xf8000f79a080 (20180209/dsargs-472) >> ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, >> AE_AML_INTERNAL (20180209/psparse-677) >> ACPI Error: Method parse/execution failed \134_SB.AC._PSR, >> AE_AML_INTERNAL (20180209/psparse-677) >> >> I noticed this starting from a CURRENT build i installed two weeks >> ago, and still see it from a world/kernel i built last night. two >> questions: >> 1) has anyone else noticed this? >> 2) is this something to worry about? >> >> i can help debug the issue but am not sure where to start poking. >> >> thanks! >> -pete >> > Here I have > > ACPI Error: No pointer back to namespace node in package > 0xf8000171f700 (20180209/dsargs-472) > ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName > unavailable] (20180209/dswexec-606) > ACPI Error: Method parse/execution failed > \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677) > > with svn 329142 on a Lenovo ThinkCentre M83 > ACPI APIC Table: > > Claude Buisson This problem should be fixed now (r80). Sorry for the delay. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: New ACPI Errors
On 02/13/2018 17:34, Claude Buisson wrote: > On 02/13/2018 22:49, Pete Wright wrote: >> Hello, >> I have started seeing a lot of these messages spam my system log: >> >> ACPI Error: No pointer back to namespace node in package >> 0xf8000f79a080 (20180209/dsargs-472) >> ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, >> AE_AML_INTERNAL (20180209/psparse-677) >> ACPI Error: Method parse/execution failed \134_SB.AC._PSR, >> AE_AML_INTERNAL (20180209/psparse-677) >> >> I noticed this starting from a CURRENT build i installed two weeks >> ago, and still see it from a world/kernel i built last night. two >> questions: >> 1) has anyone else noticed this? >> 2) is this something to worry about? >> >> i can help debug the issue but am not sure where to start poking. >> >> thanks! >> -pete >> > Here I have > > ACPI Error: No pointer back to namespace node in package > 0xf8000171f700 (20180209/dsargs-472) > ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName > unavailable] (20180209/dswexec-606) > ACPI Error: Method parse/execution failed > \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677) > > with svn 329142 on a Lenovo ThinkCentre M83 > ACPI APIC Table: > > Claude Buisson I believe you can silence the errors with the attached patch. Please try it and let me know. Jung-uk Kim Index: sys/contrib/dev/acpica/include/platform/acfreebsd.h === --- sys/contrib/dev/acpica/include/platform/acfreebsd.h (revision 329340) +++ sys/contrib/dev/acpica/include/platform/acfreebsd.h (working copy) @@ -166,6 +166,7 @@ #define ACPI_UINTPTR_T uintptr_t +#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS #define ACPI_USE_DO_WHILE_0 #define ACPI_USE_LOCAL_CACHE #define ACPI_USE_NATIVE_DIVIDE signature.asc Description: OpenPGP digital signature
Re: openssl in base should install c_rehash
On 02/08/2018 19:43, Ian Lepore wrote: > It's not clear if openssl 1.1.0 installs a link or wrapper for c_rehash > or not. That manpage seems to imply that "openssl rehash" and > "c_rehash" are equivelent. "openssl rehash" is not a wrapper for "c_rehash". This command is available for all Unix-like platforms. https://github.com/openssl/openssl/blob/master/apps/rehash.c "c_rehash" is not a wrapper for "openssl rehash", either. For Unix-like platforms, it is only provided as a backup. https://github.com/openssl/openssl/blob/master/tools/c_rehash.in I guess they just forgot to add "functionally" in front of "equivalent". ;-) Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: openssl in base should install c_rehash
On 02/08/2018 18:51, Ian Lepore wrote: > On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote: >> On 02/08/2018 17:31, Chris H wrote: >>> >>> [...] >>> Couldn't this be in $base? I'd like to vote yes. :-) >> From OpenSSL 1.1.0, openssl(1) added "rehash" command. >> >> https://www.openssl.org/docs/man1.1.0/apps/rehash.html >> >> I don't think we need yet another implementation in the base. > > But on a machine I just set up last weekend using -current I get: > > ian@th > openssl rehash > openssl:Error: 'rehash' is an invalid command. > ian@th > openssl version > OpenSSL 1.0.2n-freebsd 7 Dec 2017 > > Are we going to update to 1.1.0 soon? When I find some free time. I don't know how "soon", however. > If not, how does it help that a version we don't use has rehash > built in? We will have the feature when we import OpenSSL 1.1.0. Knowing that it is obsoleted by the upstream, I don't want to add an equivalent script in the base. If it is really necessary, you can always install the c_rehash script (security/openssl), openssl with rehash command (security/openssl-devel), openssl with certhash command (security/libressl), etc. from the ports tree. BTW, we never had it in the base and it was removed from head src tree more than 5 years ago. Why is it so important now? :-( Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: openssl in base should install c_rehash
On 02/08/2018 17:31, Chris H wrote: > On Thu, 08 Feb 2018 13:25:13 -0700 "Ian Lepore" <i...@freebsd.org> said >> On Thu, 2018-02-08 at 21:15 +0100, Ulrich Spörlein wrote: >> > 2018-02-08 21:00 GMT+01:00 Jung-uk Kim <j...@freebsd.org>: >> > > > > > On 02/08/2018 08:52, Jan Bramkamp wrote: >> > > > > > > On 08.02.18 14:24, Ulrich Spörlein wrote: >> > > > > > > > > Hey, >> > > > > > > > > c_rehash has somehow disappeared from the base system. >> We still >> > > > > install the >> > > > > manpage it seems, but the tool itself is missing. Can we have >> > > > > that back? >> > > > > > > > > > > > > root@acme:/etc/ssl# locate c_rehash >> > > > > ... >> > > > > /usr/share/openssl/man/man1/c_rehash.1.gz >> > > > > /usr/src/crypto/openssl/doc/apps/c_rehash.pod >> > > > > /usr/src/secure/usr.bin/openssl/man/c_rehash.1 >> > > > > > > > > > > > > The port seems to install it just fine: >> > > > > > > > > root@acme:/etc/ssl# grep -r c_rehash /usr/ports/ >> > > > > /usr/ports/security/openssl/pkg-plist:bin/c_rehash >> > > > > /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz >> > > > > > > > > It looks like the merge of OpenSSL 1.0.1c got rid of >> it (if I'm >> > > > > reading the >> > > > > history with git pickaxe right). >> > > > The LibreSSL port lacks a c_rehash script as well. Putting >> > > > c_rehash back >> > > > into base wouldn't solve the problem because it requires Perl 5. >> > > Correct. I just removed the manual page to not confuse users. >> > > > > https://svnweb.freebsd.org/changeset/base/329024 >> > > > > Thanks for letting me know! >> > > > > Jung-uk Kim >> > > > > > I would rather that c_rehash is brought back. I can install >> perl just >> > fine >> > (or have it anyway installed), that's not the case with openssl from >> > ports, >> > as that will mess up many things. >> > > Guess I'll download my own version ... :( >> > > Uli >> >> >> Maybe we should just replace ours in base with a non-perl version, >> something like this one? >> >> https://opensource.apple.com/source/OpenSSL/OpenSSL-5/openssl/tools/c_rehash.in.auto.html >> >> >> -- Ian > Excellent link, Ian. Thanks! > Couldn't this be in $base? I'd like to vote yes. :-) From OpenSSL 1.1.0, openssl(1) added "rehash" command. https://www.openssl.org/docs/man1.1.0/apps/rehash.html I don't think we need yet another implementation in the base. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: openssl in base should install c_rehash
On 02/08/2018 15:15, Ulrich Spörlein wrote: > > 2018-02-08 21:00 GMT+01:00 Jung-uk Kim <j...@freebsd.org > <mailto:j...@freebsd.org>>: > > On 02/08/2018 08:52, Jan Bramkamp wrote: > > On 08.02.18 14:24, Ulrich Spörlein wrote: > >> Hey, > >> > >> c_rehash has somehow disappeared from the base system. We still > >> install the > >> manpage it seems, but the tool itself is missing. Can we have that > back? > >> > >> > >> root@acme:/etc/ssl# locate c_rehash > >> ... > >> /usr/share/openssl/man/man1/c_rehash.1.gz > >> /usr/src/crypto/openssl/doc/apps/c_rehash.pod > >> /usr/src/secure/usr.bin/openssl/man/c_rehash.1 > >> > >> > >> The port seems to install it just fine: > >> > >> root@acme:/etc/ssl# grep -r c_rehash /usr/ports/ > >> /usr/ports/security/openssl/pkg-plist:bin/c_rehash > >> /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz > >> > >> It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm > >> reading the > >> history with git pickaxe right). > > > > The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back > > into base wouldn't solve the problem because it requires Perl 5. > > Correct. I just removed the manual page to not confuse users. > > https://svnweb.freebsd.org/changeset/base/329024 > <https://svnweb.freebsd.org/changeset/base/329024> > > Thanks for letting me know! > > Jung-uk Kim > > > I would rather that c_rehash is brought back. I can install perl just > fine (or have it anyway installed), that's not the case with openssl > from ports, as that will mess up many things. Although c_rehash was available from src/crypto/openssl/tools, we have never installed it in the base, AFAIK. Actually, it does not use proper perl binary (i.e., /usr/bin/perl vs. /usr/local/bin/perl) and certs directory (i.e., /usr/local/ssl/certs vs. /etc/ssl/certs). https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist-0.9.8/tools/c_rehash?revision=247942=co Jung-uk Kim > Guess I'll download my own version ... :( signature.asc Description: OpenPGP digital signature
Re: openssl in base should install c_rehash
On 02/08/2018 08:52, Jan Bramkamp wrote: > On 08.02.18 14:24, Ulrich Spörlein wrote: >> Hey, >> >> c_rehash has somehow disappeared from the base system. We still >> install the >> manpage it seems, but the tool itself is missing. Can we have that back? >> >> >> root@acme:/etc/ssl# locate c_rehash >> ... >> /usr/share/openssl/man/man1/c_rehash.1.gz >> /usr/src/crypto/openssl/doc/apps/c_rehash.pod >> /usr/src/secure/usr.bin/openssl/man/c_rehash.1 >> >> >> The port seems to install it just fine: >> >> root@acme:/etc/ssl# grep -r c_rehash /usr/ports/ >> /usr/ports/security/openssl/pkg-plist:bin/c_rehash >> /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz >> >> It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm >> reading the >> history with git pickaxe right). > > The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back > into base wouldn't solve the problem because it requires Perl 5. Correct. I just removed the manual page to not confuse users. https://svnweb.freebsd.org/changeset/base/329024 Thanks for letting me know! Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Panic: @r323525: iflib
On 09/13/2017 11:21, Sean Bruno wrote: >> Previous successful build was: >> FreeBSD g1-252.catwhisker.org 12.0-CURRENT FreeBSD 12.0-CURRENT #398 >> r323483M/323489:1200044: Tue Sep 12 04:31:08 PDT 2017 >> r...@g1-252.catwhisker.org:/common/S4/obj/usr/src/sys/CANARY amd64 >> >> The usual historical information, including a verbose-boot dmesg.boot >> from the above-cited build, may be found at >> <http://www.catwhisker.org/~david/FreeBSD/history/>. >> >> I will try hand-transcribing some of the lock & backtrace info: >> >> ... >> em0: allocated for 1 rx_queues >> Kernel page fault with the following non-sleepable locks held: >> exclusive sleep mutex taskqgroup (taskqgroup) r = 0 (0xfe07be2e4800) >> locked @ /usr/src/sys/kern/subr_gtaskqueue.c:803 >> stack backtrace: [which I am abbreviating at this point -- dhw] >> #0 ... at witness_debugger+0x73 >> #1 ... at witness_warn+0x43f >> #2 ... at trap_pfault+0x53 >> #3 ... at trap+0x2c5 >> #4 ... at calltrap+0x8 >> #5 ... at iflib_device_register+0x2a61 >> #6 ... at iflib_device_attach+0xb7 >> #7 ... at device_attach+0x3ee >> #8 ... at bus_generic_attach+0x5a >> #9 ... at pci_attach+0xd5 >> #10 ... at device_attach+0x3ee >> #11 ... at bus_generic_attach+0x5a >> #12 ... at acpi_pcib_acpi_attach+0x3bc >> #13 ... at device_attach+0x3ee >> #14 ... at bus_generic_attach+0x5a >> #15 ... at acpi_attach+0xe85 >> #16 ... at device_attach+0x3ee >> #17 ... at bus_generic_attach+0x5a >> >> Fatal trap 12: page fault while in kernel mode >> cpuid = 2; apic id = 02 >> fault virtual address = 0x8b530c20 >> fault code = supervisor write data, page not present >> ... >> [ thread pid 0 tid 10 ] >> Stopped at 0x80a743b0 = taskqgroup_attach+0x230:orq >> %rax,-0x 58(%rbp,%xrx,8) >> >> I can provide more specific excerpts, but I need to focus on some >> other activities for a while. >> >> Peace, >> david >> > > > When you get a chance, let me know what em(4) device is in your machine > (pciconf -lvbc). I'll see if I have one around here to test. FYI, I have very similar panics after the commit. Reverting the commit from today's head, i.e., r323566 - (r323516 & r323517), fixed the problem for me. em0@pci0:7:0:0: class=0x02 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xd0ca, size 131072, enabled bar [14] = type Memory, range 32, base 0xd0c8, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2020, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS link x4(x4) speed 2.5(2.5) ASPM disabled(L0s) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 00151751bcba em1@pci0:7:0:1: class=0x02 card=0x115e8086 chip=0x105e8086 rev=0x06 hdr=0x00 vendor = 'Intel Corporation' device = '82571EB Gigabit Ethernet Controller' class = network subclass = ethernet bar [10] = type Memory, range 32, base 0xd0c4, size 131072, enabled bar [14] = type Memory, range 32, base 0xd0c2, size 131072, enabled bar [18] = type I/O Port, range 32, base 0x2000, size 32, enabled cap 01[c8] = powerspec 2 supports D0 D3 current D0 cap 05[d0] = MSI supports 1 message, 64 bit enabled with 1 message cap 10[e0] = PCI-Express 1 endpoint max data 256(256) NS link x4(x4) speed 2.5(2.5) ASPM disabled(L0s) ecap 0001[100] = AER 1 0 fatal 1 non-fatal 0 corrected ecap 0003[140] = Serial 1 00151751bcba > I'm assuming you do *not* have any iflib or em(4) tuning options set either. Nope. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: r322076 breaks vtnet connectivity
On 08/10/2017 21:27, Ian FREISLICH wrote: > I have a host on Digital Ocean (qemu) and the change in r322076 breaks > my vtnet0 interface. The interface still comes up but does not pass > traffic any more. It's not obvious to my why the changes from r322075 > to r322076 affect the vtnet interface. Can you please try r322323 or later? Basically, r322076 was incomplete and r322323 corrected the stupid mistake. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: dchlient does not autostart anymore?
On 03/24/2017 11:20, Kirill Ponomarev wrote: > On 03/24, Vladimir Zakharov wrote: >> Hello! >> >> After upgrading from r315544 to r315880 network interface doesn't get IP >> address using DHCP on boot anymore. >> >> $ grep re0 /etc/rc.conf | grep -v "^#" >> ifconfig_re0="DHCP" >> >> "service netif restart" doesn't help either. Only manual dhclient >> starting. > > Same issues here with today CURRENT, r315896. FYI, r315901 fixed the issue for me. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Revision 312827 fatal error: 'opt_printf.h' file not found
On 01/26/2017 19:17, Alex Deiter wrote: Hello, patch: Index: sys/cam/cam_xpt.h === --- sys/cam/cam_xpt.h (revision 312851) +++ sys/cam/cam_xpt.h (working copy) @@ -33,7 +33,10 @@ #define _CAM_CAM_XPT_H 1 #include + +#ifdef _KERNEL #include "opt_printf.h" +#endif /* _KERNEL */ Please take a look at the rev 312827: --- scsi_da.o --- cc -target x86_64-unknown-freebsd12.0 --sysroot=/export/freebsd/obj/export/freebsd/src/tmp -B/export/freebsd/obj/export/freebsd/src/tmp/usr/bin -O2 -pipe -I/export/freebsd/src/lib/libcam -I/export/freebsd/src/sys -DNDEBUG -MD -MF.depend.scsi_da.o -MTscsi_da.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Wall -Wno-format-y2k -Wno-uninitialized -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-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -c /export/freebsd/src/sys/cam/scsi/scsi_da.c -o scsi_da.o --- scsi_all.o --- In file included from /export/freebsd/src/sys/cam/scsi/scsi_all.c:59: /export/freebsd/src/sys/cam/cam_xpt.h:36:10: fatal error: 'opt_printf.h' file not found #include "opt_printf.h" I committed a fix already (r312852). Jung-uk Kim ___ 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: ACPI Error on HP ProBook 430 G2
On 01/03/2017 11:22, Hans Petter Selasky wrote: > On 01/03/17 16:26, Moore, Robert wrote: >> Not sure I understand. The fix has been committed, and is part of >> version 20161222. >> >> > > Hi Robert, > > From what I can see that patches have been pushed to the following > branch, vendor-sys/acpica/20161222/, see: > > https://svnweb.freebsd.org/changeset/base/310451 > > But not yet to "master" (12-current) ? > > Is that correct? > > My console has been filling up with messages like this: > >> ACPI Exception: AE_AML_OPERAND_TYPE, While resolving operands for >> [OpcodeName unavailable] (20161117/dswexec-498) >> ACPI Error: Method parse/execution failed >> [\134_SB.PCI0.LPCB.H_EC._Q50] (Node 0xf800047fce40), >> AE_AML_OPERAND_TYPE (20161117/psparse-560) >> acpi_ec0: evaluation of query method _Q50 failed: AE_AML_OPERAND_TYPE > > over the holidays, so I assume that means the previous version of ACPI, > 20161117 which the 20161222 version is supposed to fix. I was AFK for two weeks. I will merge ACPICA 20161222 to FreeBSD head this week when I find some free time. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: kernel panic caused by virtualbox(?)
On 08/09/16 05:12 AM, Konstantin Belousov wrote: > On Mon, Aug 08, 2016 at 04:44:20PM -0700, Don Lewis wrote: >> On 8 Aug, Konstantin Belousov wrote: >>> On Mon, Aug 08, 2016 at 10:22:44AM -0700, John Baldwin wrote: >>>> On Thursday, August 04, 2016 05:10:29 PM Don Lewis wrote: >>>>> Reposted to -current to get some more eyes on this ... >>>>> >>>>> I just got a kernel panic when I started up a CentOS 7 VM in virtualbox. >>>>> The host is: >>>>> FreeBSD 12.0-CURRENT #17 r302500 GENERIC amd64 >>>>> The virtualbox version is: >>>>> virtualbox-ose-5.0.26 >>>>> virtualbox-ose-kmod-5.0.26_1 >>>>> >>>>> The panic message is: >>>>> >>>>> panic: Unregistered use of FPU in kernel >>>>> cpuid = 1 >>>>> KDB: stack backtrace: >>>>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame >>>>> 0xfe085a55d030 >>>>> vpanic() at vpanic+0x182/frame 0xfe085a55d0b0 >>>>> kassert_panic() at kassert_panic+0x126/frame 0xfe085a55d120 >>>>> trap() at trap+0x7ae/frame 0xfe085a55d330 >>>>> calltrap() at calltrap+0x8/frame 0xfe085a55d330 >>>>> --- trap 0x16, rip = 0x827dd3a9, rsp = 0xfe085a55d408, rbp = >>>>> 0xfe085a55d430 --- >>>>> g_pLogger() at 0x827dd3a9/frame 0xfe085a55d430 >>>>> g_pLogger() at 0x8274e5c7/frame 0x3 >>>>> KDB: enter: panic >>>>> >>>>> Since g_pLogger is a symbol in vboxdrv.ko, it looks like virtualbox is >>>>> the trigger. >>>>> >>>>> There are no symbols for the virtualbox kmods, possibly because I >>>>> installed them as an upgrade using packages (built with the same source >>>>> tree version) instead of by using PORTS_MODULES in make.conf, so ports >>>>> kgdb didn't have anything useful to say about what happened before the >>>>> trap. >>>>> >>>>> This panic is very repeatable. I just got another one when starting the >>>>> same VM., but this time the two calls before the trap were >>>>> null_bug_bypass(). Hmn, that symbol is in nullfs ... >>>>> >>>>> I don't see this with a Windows 7 VM. >>>>> >>>>> All of the virtualbox kmod files are compiled with -mno-mmx -mno-sse >>>>> -msoft-float -mno-aes -mno-avx >>> Your disassemble listed fxrstor instruction that failing, or did I >>> mis-remembered ? This is most likely some context switch code, either >>> by virtual machine or erronously executed guest code. It is not a >>> spontaneous use of FPU, but more likely something different. Can you >>> confirm ? >>> >>> In either case, I do not remember any KBI changes around PCB layout or >>> fpu_enter() KPI recently. >>> >>>> >>>> I suspect head packages are quite likely built against the a "wrong" KBI >>>> and are too fragile to use for kmods vs compiling from ports. :-/ I would >>>> try a built-from-ports kmod to see if the panics go away. >>> >>> FWIW, I will commit the following change shortly. Since third-party >>> modules break the invariant, either due to bugs (ndis wrappers) or >>> possibly due to KBI breakage, it is worth to have the detection enabled >>> for production kernels. >> >> Interesting ... I tried running virtualbox on recent 10.3-STABLE with a >> GENERIC kernel and the guest seemed to operate properly. Then I enabled >> INVARIANTS and got the panic. I suspect that is why nobody has stumbled >> across this before. >> > This is yet another reason to promote KASSERT to the full panic. > I expect that the vbox source lacks fpu_kern_enter() calls around the > FPU state restoration. Unfortunately, the code is in MI source as it is unnecessary for supported OSes (read: FreeBSD is not supported) and it's not easy to inject fpu_kern_enter()/fpu_kern_leave() calls there. :-( Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Panic when loading vboxdrv module
On 07/25/16 03:27 PM, Jung-uk Kim wrote: > On 07/25/16 03:13 PM, Randy Westlund wrote: >> I'm running 12-CURRENT r303286 and virtualbox-ose-kmod-5.0.26. I just >> rebuilt the module, so I know they're in sync. When I boot with >> vboxdrv_load="YES" in /etc/loader.conf, I get this panic during boot: >> >>> panic: mutex Giant owned at /usr/src/sys/kern/kern_sync.c:406 >>> cpuid = 0 >>> KDB: stack backtrace: >>> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b >>> vpanic() at vpanic+0x182 >>> panic() at panic+0x43 >>> __mtx_assert() at __mtx_assert+0xd1 >>> mi_switch() at mi_switch+0x7b >>> sleepq_switch() at sleepq_switch+0x7e >>> sleepq_timedwait() at sleepq_timedwait+0x43 >>> rtR0SemEventWait() at rtR0SemEventWait+0x267 >>> supdrvGipCreate() at supdrvGipCreate+0x7f6 >>> supdrvInitDexExt() at supdrvInitDexExt+0x18f >>> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x49 >>> module_register_init() at module_register_init+0xb0 >>> mi_startup() at mi_startup+0x118 >>> btext() at btext+0x2c >>> KDB: enter: panic >>> [ thread pid 0 tid 10 ] >>> Stopped at kdb_enter+0x3b: movq$0,kdb_why >> >> I'm not sure whether this is a problem with the base system or the port, >> but this happens every time I boot with the module enabled. > > emulators/virtualbox-ose-kmod is causing the trouble and this problem is > well known. To work around it, remove WITNESS option from kernel > configuration for now. Oops, I meant INVARIANTS. Anyway, it should be fixed in r419083. I understand you have a panic with aio(4) but that's a separate issue. Jung-uk Kim ___ 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: Panic when loading vboxdrv module
On 07/25/16 03:13 PM, Randy Westlund wrote: > I'm running 12-CURRENT r303286 and virtualbox-ose-kmod-5.0.26. I just > rebuilt the module, so I know they're in sync. When I boot with > vboxdrv_load="YES" in /etc/loader.conf, I get this panic during boot: > >> panic: mutex Giant owned at /usr/src/sys/kern/kern_sync.c:406 >> cpuid = 0 >> KDB: stack backtrace: >> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b >> vpanic() at vpanic+0x182 >> panic() at panic+0x43 >> __mtx_assert() at __mtx_assert+0xd1 >> mi_switch() at mi_switch+0x7b >> sleepq_switch() at sleepq_switch+0x7e >> sleepq_timedwait() at sleepq_timedwait+0x43 >> rtR0SemEventWait() at rtR0SemEventWait+0x267 >> supdrvGipCreate() at supdrvGipCreate+0x7f6 >> supdrvInitDexExt() at supdrvInitDexExt+0x18f >> VBoxDrvFreeBSDModuleEvent() at VBoxDrvFreeBSDModuleEvent+0x49 >> module_register_init() at module_register_init+0xb0 >> mi_startup() at mi_startup+0x118 >> btext() at btext+0x2c >> KDB: enter: panic >> [ thread pid 0 tid 10 ] >> Stopped at kdb_enter+0x3b: movq$0,kdb_why > > I'm not sure whether this is a problem with the base system or the port, > but this happens every time I boot with the module enabled. emulators/virtualbox-ose-kmod is causing the trouble and this problem is well known. To work around it, remove WITNESS option from kernel configuration for now. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: UTF-8 by default?
On 07/20/16 04:36 PM, Herbert J. Skuhra wrote: > Baptiste Daroussin skrev: >> >> On Wed, Jul 20, 2016 at 10:47:45AM -0230, Jonathan Anderson wrote: >>> On 20 Jul 2016, at 9:13, Tim Čas wrote: >>> >>>> So, without further ado: >>>> 1) What are the reasons that UTF-8 isn't the default yet? >>>> 2) Would it be possible to make this the default in 11.0? What about >>>> 12.0? >>>> 3) Assuming an effort is started towards making UTF-8 the default, >>>> what changes would be required? >>> >>> At least according to one of my students (who makes more extensive use of >>> i18n than I do), enabling UTF-8 by default is pretty straightforward: >>> >>> https://github.com/musec/freebsd/wiki/Common-setup#utf-8-support >> >> the LC_COLLATE=C is not needed anymore with freebsd 11+ > > Weird, when I set LC_ALL or LC_COLLATE to nb_NO.UTF-8 I can no longer > run ls in $HOME. It hangs until I kill it. Same happens with > da_DK.UTF-8; no problem with sv_SE.UTF-8 or en_GB.UTF-8. > > I am running FreeBSD 11.0-BETA1 i386 (r302984) and I think someone > else reported a similiar issue earlier. FYI, this bug was introduced in r302324, which is between ALPHA6 and BETA1. It should be fixed in r302916 (head) and r303112 (stable/11). Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: GOST in OPENSSL_BASE
On 07/18/16 08:12 AM, Mathieu Arnold wrote:
> Hi,
>
> +--On 11 juillet 2016 22:56:00 +0300 Slawa Olhovchenkov <s...@zxy.spb.ru>
> wrote:
> | On Mon, Jul 11, 2016 at 03:00:39PM -0400, Jung-uk Kim wrote:
> |> > .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) &&
> |> > ${SSL_DEFAULT} == base BROKEN= OpenSSL from the base system does not
> |> > support GOST, add \ DEFAULT_VERSIONS+=ssl=openssl to your
> |> > /etc/make.conf and rebuild everything \ that needs SSL.
> |> > .endif
> |>
> |> FreeBSD 9.3 is still supported but GOST is not available there. It
> |
> | Thanks for clarifications.
> |
> |> seems the ports maintainer didn't want to break it on 9.3 (CC added).
> |> Version check may be needed there.
> |
> | Thanks!
>
>
> The idea is that you can't have mixed openssl usage. If you link half your
> ports with openssl from base, and half with openssl from ports, you are
> going to have dragons attacks, and core dumps. Also, if you are using
> openssl from ports, you cannot use GSSAPI from base, for the same reasons.
Exactly. That's why we should *allow* using base OpenSSL for 10.x and
later because many packages are already linked against base OpenSSL by
default.
Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
Re: GOST in OPENSSL_BASE
On 07/11/16 02:41 PM, Slawa Olhovchenkov wrote:
> On Mon, Jul 11, 2016 at 02:28:45PM -0400, Jung-uk Kim wrote:
>
>> On 07/10/16 10:10 AM, Andrey Chernov wrote:
>>> On 10.07.2016 16:30, Slawa Olhovchenkov wrote:
>>>> I am surprised lack of support GOST in openssl-base.
>>>> Can be this enabled before 11.0 released?
>>>
>>> AFAIK openssl maintainers says something like they can't support this
>>> code and it will become rotten shortly with new changes, so they drop it.
>>
>> [OpenSSL-maintainer-for-the-base hat on]
>>
>> GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on
>> these branches unless secteam explicitly ask us to do so. However, we
>> *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch.
>>
>> [OpenSSL-maintainer-for-the-base hat off]
>>
>> Jung-uk Kim
>>
>
> Thanks!
>
> May be need file PR for dns/bind910?
>
> # grep -3 BROK /poudriere/ports/default/dns/bind910/Makefile
> .include
>
> .if ( ${PORT_OPTIONS:MGOST} || ${PORT_OPTIONS:MGOST_ASN1} ) && ${SSL_DEFAULT}
> == base
> BROKEN= OpenSSL from the base system does not support GOST, add \
> DEFAULT_VERSIONS+=ssl=openssl to your /etc/make.conf and rebuild
> everything \
> that needs SSL.
> .endif
FreeBSD 9.3 is still supported but GOST is not available there. It
seems the ports maintainer didn't want to break it on 9.3 (CC added).
Version check may be needed there.
Jung-uk Kim
signature.asc
Description: OpenPGP digital signature
Re: GOST in OPENSSL_BASE
On 07/10/16 10:10 AM, Andrey Chernov wrote: > On 10.07.2016 16:30, Slawa Olhovchenkov wrote: >> I am surprised lack of support GOST in openssl-base. >> Can be this enabled before 11.0 released? > > AFAIK openssl maintainers says something like they can't support this > code and it will become rotten shortly with new changes, so they drop it. [OpenSSL-maintainer-for-the-base hat on] GOST is supported on FreeBSD 10.x and 11.x. We will not drop it on these branches unless secteam explicitly ask us to do so. However, we *may* drop it from 12.0 *iff* we import OpenSSL 1.1.0 branch. [OpenSSL-maintainer-for-the-base hat off] Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: GOST in OPENSSL_BASE
On 07/10/16 09:30 AM, Slawa Olhovchenkov wrote: > I am surprised lack of support GOST in openssl-base. > Can be this enabled before 11.0 released? It works for me, I think. The following change was all I need to enable the engine: --- /etc/ssl/openssl.cnf.orig +++ /etc/ssl/openssl.cnf @@ -13,6 +13,21 @@ #oid_file = $ENV::HOME/.oid oid_section= new_oids +# GOST +openssl_conf = openssl_def + +[openssl_def] +engines= engine_section + +[engine_section] +gost = gost_section + +[gost_section] +engine_id = gost +dynamic_path = /usr/lib/engines/libgost.so +default_algorithms = ALL +CRYPT_PARAMS = id-Gost28147-89-CryptoPro-A-ParamSet + # To use this configuration file with the "-extfile" option of the # "openssl x509" utility, name here the section containing the # X.509v3 extensions to use: Please see the README file for more info: https://svnweb.freebsd.org/base/head/crypto/openssl/engines/ccgost/README.gost?revision=238405=co Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Bug 209222 -r298793 automatic shutdown for "kernel: ACPI Error: No installed handler for fixed event - PM_Timer (0), disabling (20160422/evevent-323)" and more under virtual box
On 05/ 3/16 03:55 PM, John Baldwin wrote: > On Tuesday, May 03, 2016 12:18:22 AM Mark Millard wrote: >> On 2016-May-2, at 11:04 PM, Mark Millard <mar...@dsl-only.net> wrote: >> >>> I just upgraded my amd64 11.0-CURRENT that runs under virtual box on Mac OS >>> X to -r298793. This was via buildworld buildkernel then installing them, >>> like normal for me. >>> >>> The result is about 10-11 minutes after starting to boot FreeBSD shuts down >>> with (for example): >>> (the root login line is just to give an idea of the time frame after the >>> login prompt) >>> >>>> May 2 21:52:18 FreeBSDx64 login: ROOT LOGIN (root) ON ttyv0 >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for >>>> fixed event - PM_Timer (0), disabling (20160422/evevent-323) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No installed handler for >>>> fixed event - RealTimeClock (4), disabling (20160422/evevent-323) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 01, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 03, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 04, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 05, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 06, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: ACPI Error: No handler or method for >>>> GPE 07, disabling event (20160422/evgpe-834) >>>> May 2 22:01:45 FreeBSDx64 kernel: . >>>> May 2 22:01:45 FreeBSDx64 afpd[652]: AFP Server shutting down >>>> May 2 22:01:45 FreeBSDx64 cnid_metad[654]: shutting down on SIGTERM >>>> May 2 22:01:45 FreeBSDx64 netatalk[639]: Netatalk AFP server exiting >>>> May 2 22:01:46 FreeBSDx64 kernel: . >>>> May 2 22:01:47 FreeBSDx64 kernel: , 576. >>>> May 2 22:01:47 FreeBSDx64 syslogd: exiting on signal 15 >>> >>> >>> === >>> Mark Millard >>> markmi at dsl-only.net >> >> I had duplicated the directory tree that held the virtual machine on Mac OS >> X before booting FreeBSD in VirtualBox to install the kernel and world. This >> was running -r297769. >> >> When I boot the -r297769 11.0 virtual machine instead of the -r298793 one >> the problem does not occur. >> >> Both -r297769 and -r298793 11.0-'s have /usr/ports -r414369 and the ports >> were built before the -r298793 buildworld/buildkernel was done. And both >> -r297769 and -r298793 11.0's are running under the same vintage of Virtual >> Box (5.0.20 r106931). >> >> So what is different is just the FreeBSD vintage. >> >> 11.0's -r297769 virtual machine does contain the buildworld/buildkernel >> /usr/obj material for -r298793, it is just not installed. > > This was already covered in an earlier thread. r298838 has the fix / > workaround. FYI, the upstream was notified and a patch is available from here: https://github.com/acpica/acpica/pull/138 Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Build failed in Jenkins: FreeBSD_HEAD #220
On 04/29/16 05:46 PM, Jung-uk Kim wrote: > On 04/29/16 05:17 PM, John Baldwin wrote: >> You'll have to talk to the Intel guy who broke this to find out how he'd >> like to fix it (not hardcode 32, or fix the AccessWidth). > > I notified Intel guys and they will take care of it. Once they patch > the bug, I'll merge the fix ASAP. It seems it is taking longer than I expected. I reverted the commits from our tree for now (r298838) until we have a proper fix. Sorry for the breakage. Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Build failed in Jenkins: FreeBSD_HEAD #220
On 04/29/16 05:17 PM, John Baldwin wrote: > You'll have to talk to the Intel guy who broke this to find out how he'd > like to fix it (not hardcode 32, or fix the AccessWidth). I notified Intel guys and they will take care of it. Once they patch the bug, I'll merge the fix ASAP. Thanks for analysing the issue quickly! Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: Build failed in Jenkins: FreeBSD_HEAD #220
On 04/29/16 04:02 PM, John Baldwin wrote: > On Friday, April 29, 2016 06:58:41 PM jenkins-ad...@freebsd.org wrote: >> See <https://jenkins.FreeBSD.org/job/FreeBSD_HEAD/220/> ... >> Unhandled inl 0x0402 at 0x8039c2bd > > This is a read of the PM1 enable register. In bhyve this is treated as a > 16-bit > register, so only inw/outw is permitted. > > Hmm, PM1a is defined as 16-bits in the spec, so this seems to be an error in > the recent ACPICA import. I note that the bitwidth calculations changed in > hwregs.c in the most recent import. Perhaps those are incorrect? > > I suspect that this might also explain the issue Kurt Lidl reported of a VM > shutting down after spewing errors related to FixedEvents and GPEs. Unfortunately, there were too many recent upstream commits to this file. :-( At least, we should take a closer look at the following commits: https://github.com/acpica/acpica/commit/6cb97888 https://github.com/acpica/acpica/commit/3d8583a0 https://github.com/acpica/acpica/commit/48eea5e7 https://github.com/acpica/acpica/commit/41f6aefa https://github.com/acpica/acpica/commit/c23034a3 https://github.com/acpica/acpica/commit/c49a751b Jung-uk Kim signature.asc Description: OpenPGP digital signature
Re: xo_config.h missing?
On 03/16/16 09:28 PM, Larry Rosenman wrote:
> ll_subdir_usr.bin/xo ---
> /usr/src/contrib/libxo/xo/xo.c:16:10: fatal error: 'xo_config.h' file not
> found
> #include "xo_config.h"
>
>
>
> Path: /usr/src
> Working Copy Root Path: /usr/src
> URL: https://svn.freebsd.org/base/head
> Relative URL: ^/head
> Repository Root: https://svn.freebsd.org/base
> Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f
> Revision: 296976
> Node Kind: directory
> Schedule: normal
> Last Changed Author: np
> Last Changed Rev: 296975
> Last Changed Date: 2016-03-16 20:15:16 -0500 (Wed, 16 Mar 2016)
It seems r296967 is the culprit:
https://svnweb.freebsd.org/changeset/base/296967
The attached patch fixed the build issues for me.
Jung-uk Kim
Index: lib/libxo/tests/Makefile
===
--- lib/libxo/tests/Makefile (revision 296976)
+++ lib/libxo/tests/Makefile (working copy)
@@ -241,6 +241,7 @@ PROGS+= test_10
PROGS+= test_11
CFLAGS+= -I${LIBXOSRC}/libxo
+CFLAGS+= -I${SRCTOP}/lib/libxo
LIBADD= xo util
Index: usr.bin/xo/Makefile
===
--- usr.bin/xo/Makefile (revision 296976)
+++ usr.bin/xo/Makefile (working copy)
@@ -12,6 +12,9 @@ MAN= xo.1
# XXX For xoversion.h
CFLAGS+=-I${LIBXOSRC}/libxo
+# XXX For xo_config.h
+CFLAGS+=-I${SRCTOP}/lib/libxo
+
LIBADD= xo
.if ${MK_TESTS} != "no"
signature.asc
Description: OpenPGP digital signature
Re: SVN r296272 breaks virtualbox
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/ 1/16 05:29 PM, Michael Butler wrote: > The removal of "taskqueue_enqueue_fast" breaks the virtualbox > kmods: > > Mar 1 16:54:36 toshi kernel: vboxdrv: fAsync=0 offMin=0x914 > offMax=0x151c Mar 1 16:54:36 toshi kernel: link_elf_obj: symbol > taskqueue_enqueue_fast undefined Mar 1 16:54:36 toshi kernel: > linker_load_file: Unsupported file type Mar 1 16:54:36 toshi > kernel: link_elf_obj: symbol taskqueue_enqueue_fast undefined Mar > 1 16:54:36 toshi kernel: linker_load_file: Unsupported file type > Mar 1 16:54:36 toshi kernel: KLD vboxnetadp.ko: depends on > vboxnetflt - not available or version mismatch Mar 1 16:54:36 > toshi kernel: linker_load_file: Unsupported file type It should be fixed now (r409965). Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJW12mUAAoJEHyflib82/FGjCoIAI7SgVEn4KsODrF4/y/Aifp1 vw9jDQ9oGo7z3zRKk7C14/tLeS6Z+GjrfZldKOJBZHKoWLlzs9+WCpXmESez10Kj 0nR3dbk2RHAE0iHFqwz7jzzANGu/eZohsgQ44a7ZhZcnrlUchGLCIz3eZMQWctYz KFUHLewYbr0/nBn/HB5G/5LI/DEBvhlxgplfjOFyvjZXXeYWot3q2cUvhNUjWQMf B3iqXmeMQmQ4lHPA/GkIDpIUwhi0sSn8FoaaV+dF13MU023lBE//klcUn5GbYd4Y 4DkLzZJKy4gpfdKelkSU8GUAVERRKonxkROtRRvt9eioE8IpEcT2KDMkshEmXFU= =Fj+q -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: Shared library version bump?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/19/16 06:05 PM, Dimitry Andric wrote:
> On 19 Jan 2016, at 23:32, Thomas Mueller
> <mueller6...@bellsouth.net> wrote:
>>
>> Has there recently been a version bump in the shared libraries?
>> I saw no warning on this in the src or ports UPDATING files.
>
> This was already answered in reply to your previous post on this
> same issue. As mentioned in the reply, OpenSSL has been upgraded,
> and both of its shared libraries have been bumped, e.g. they are
> now named libcrypto.so.8 and libssl.so.8.
>
> (Apparently you deleted the old libcrypto.so.7 and libssl.so.7,
> even though you should never do so until your ports are upgraded.)
>
>
>> I can no longer startx and can no longer run many other ports,
>> getting errors like
>>
>> Shared object "libcrypto.so.7" not found, required by "X" xinit:
>> giving up xinit: unable to connect to X server: Connection
>> refused xinit: server error
>>
>> and
>>
>> root@amelia:~ # pkg info -f xserver Shared object "libssl.so.7"
>> not found, required by "pkg"
>>
>> Is this due to a version bump,
>
> Yes.
>
>
>> or is it related to the messages I got in yesterday's kernel
>> installation like "unknown metadata record 4 ..."?
>
> No, that is something entirely different. It is mainly cosmetic,
> and you can ignore it, it will go away at the next kernel update,
> if your kldxref executable is new enough.
>
>
>> What do I do? Make buildworld and kernel again, or rebuild all
>> ports? How do I find which ports need updating, or rebuild all
>> except portmaster and pkg which I rebuilt after getting the
>> errors?
>
> It is easiest to use pkg-static to reinstall your ports, e.g.:
>
> pkg-static update pkg-static upgrade
>
> Alternatively, rebuild all ports depending on OpenSSL.
A crude way to find almost all the ports depending on old OpenSSL is:
find /usr/local -type f -exec file '{}' ';' | \
awk -F: '{ if ($2~/ELF/) print $1 }' | \
xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \
xargs pkg-static which -oq | sort -u
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWnstwAAoJEHyflib82/FGXboH+wdNOXZ7i5z140BEbMlFeAH9
OCKq7fgwqyEzWjw73yiTcyTHir8nIuaFKkljMJFahEWR2/HMdFmBEoUheCWiscjx
cN+Ek2ICTD/ghgz1LGLVQtXw9EAGvAfqCSz+iGaSgSu1AHxwuirk3GMORRXoBWNv
eSrWfcP0bFDfb9p9zVNiMTnsMX4yKvuvDuXUxPsZSJyqb5vcctedIgwgV/L3Tq/X
vY/Nx+xvX/nJMRzePje9/9IziWlGZCK0ZI+aBnYcFb4y8OWg5gYvkr/XdBXSb+Ke
sgZrMAfdmyxDHv7AxDyVRgykHP00UIs3q5tvIDNxp47BEhu++niejX7+UsNHjNU=
=8Jb1
-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: Shared library version bump?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 01/19/16 06:49 PM, Jung-uk Kim wrote:
> On 01/19/16 06:05 PM, Dimitry Andric wrote:
>> On 19 Jan 2016, at 23:32, Thomas Mueller
>> <mueller6...@bellsouth.net> wrote:
>>>
>>> Has there recently been a version bump in the shared
>>> libraries? I saw no warning on this in the src or ports
>>> UPDATING files.
>
>> This was already answered in reply to your previous post on this
>> same issue. As mentioned in the reply, OpenSSL has been
>> upgraded, and both of its shared libraries have been bumped, e.g.
>> they are now named libcrypto.so.8 and libssl.so.8.
>
>> (Apparently you deleted the old libcrypto.so.7 and libssl.so.7,
>> even though you should never do so until your ports are
>> upgraded.)
>
>
>>> I can no longer startx and can no longer run many other ports,
>>> getting errors like
>>>
>>> Shared object "libcrypto.so.7" not found, required by "X"
>>> xinit: giving up xinit: unable to connect to X server:
>>> Connection refused xinit: server error
>>>
>>> and
>>>
>>> root@amelia:~ # pkg info -f xserver Shared object
>>> "libssl.so.7" not found, required by "pkg"
>>>
>>> Is this due to a version bump,
>
>> Yes.
>
>
>>> or is it related to the messages I got in yesterday's kernel
>>> installation like "unknown metadata record 4 ..."?
>
>> No, that is something entirely different. It is mainly
>> cosmetic, and you can ignore it, it will go away at the next
>> kernel update, if your kldxref executable is new enough.
>
>
>>> What do I do? Make buildworld and kernel again, or rebuild
>>> all ports? How do I find which ports need updating, or rebuild
>>> all except portmaster and pkg which I rebuilt after getting
>>> the errors?
>
>> It is easiest to use pkg-static to reinstall your ports, e.g.:
>
>> pkg-static update pkg-static upgrade
>
>> Alternatively, rebuild all ports depending on OpenSSL.
>
> A crude way to find almost all the ports depending on old OpenSSL
> is:
>
> find /usr/local -type f -exec file '{}' ';' | \ awk -F: '{ if
> ($2~/ELF/) print $1 }' | \ xargs egrep -l 'lib(crypto|ssl)\.so\.7'
> | \ xargs pkg-static which -oq | sort -u
A slightly improved version (to exclude non-native ELF binaries):
find /usr/local -type f -exec file -e elf '{}' ';' | \
awk -F: '{ if ($2~/ELF.*FreeBSD/) print $1 }' | \
xargs egrep -l 'lib(crypto|ssl)\.so\.7' | \
xargs pkg-static which -oq | sort -u
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJWns9cAAoJEHyflib82/FGgqgIAJGZ/pP+hW6if0OI1bsCuvc8
yAGtNe1ODOlryysqqc/hXh0kxNFz2jZgvf/wxJeRrV1FXsnvi6eyrmSxKJp/uVPp
Ichrmyh46C7Rj2XPCzmuNrWM4oTjCy1flOMk9JubpAyL8OH+TKT6icooj8hXUvBp
razc6crsqNlfcPVeo+8XLvM6zz+hCQDDYd2ScvYBfMeuUJAHbBZ3PN6uyD+L2bag
LR4DU/6twvR/KozxjtLqNSQ/k42TMt4wKgRZa6V1uyWdWNVWiWlbu/fM6vNfHjxZ
4nug6SIm8Vt9y0479MW19yrNIoNwWONYL5uYW4pDSpMABnqtkH9qgGYzVymWTpQ=
=So35
-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"
[HEADSUP] OpenSSL updated to 1.0.2d
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 OpenSSL on head has been updated to 1.0.2d. Please make sure to recompile all binaries depending on libcrypto.so.7 or libssl.so.7. Cheers! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWM9nDAAoJEHyflib82/FGuV8H+gKZRDJ/FvPQ/D5wCTBddfgJ 0i8ptgdzWtSABOSOUeKYBceHhiHUOjlnl2UdMv3JWq6virqCx1YXlJTIHACeZL7D SSqyuMT3qfZFLwi8fw/dnzgIZx1N86wQlIZOU/3807SN0+h0uCcOq1/Dj/j/wsQx XpM/tLgnQfqiRSl8pZPUleyOKqqhrFv+pJv7uybAQzTwdQ03pzhd694dy4futsg2 wxFLUK8BbXWv1ZW37wDysyMyaem02nqCMYUXPoGfjMEwN6DFsx3WVUyKpZxMYQ8x fNtV3l61tXRczQWzh/rnslSxjbbjMlS4/DKt2x+mzHELUFiOoPqc3/z0CgFUoNk= =Wa/Z -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: Wrong temperature with AMD and amdtemp.ko
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/02/2015 16:49, Willem Jan Withagen wrote: > > Hi > > 10.2-STABLE FreeBSD 10.2-STABLE #0 r287102: Mon Aug 24 > > Processor: Opteron 6812, in Supermicro H8SGL > > dev.cpu.7.temperature: 11.1C dev.cpu.6.temperature: 11.1C > dev.cpu.5.temperature: 11.1C dev.cpu.4.temperature: 11.1C > dev.cpu.3.temperature: 11.1C dev.cpu.2.temperature: 11.1C > dev.cpu.1.temperature: 11.1C dev.cpu.0.temperature: 11.1C > > But I'm pretty sure it is not 11.1C in the datacenter > > Or should I not use amdtemp.ko for this? amdtemp(4): For Family 10h and later processors, “(the reported temperature) is a non-physical temperature measured on an arbitrary scale and it does not represent an actual physical temperature like die or case temperature. Instead, it specifies the processor temperature relative to the point at which the system must supply the maximum cooling for the processor's specified maximum case temperature and maximum thermal power dissipation” according to BIOS and Kernel Developer's Guide (BKDG) for AMD Processors, http://developer.amd.com/documentation/guides/Pages/default.aspx. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJWDvHaAAoJEHyflib82/FGrvwIAIHhM5bDxODIycXkuqoNWutC MUO7KsFcQuU+pGpV+Ip70ZehRbbdjbo/3sD4oqispWKwKuUgihPBiRn7v/Ad2fxN crvZ4MJXalQmr7+ipELWVtD8/TkzIX6npLMvjRr/adnkzDleGuEErG45z77w/6uj SdJVkvAp15Ji1qu2UWXCipg8mWpPvZjgNwDeeK3ryo5ZsE9YaeWOKJG9eP9sjTcx zoYC7LR/aVFFDZTlx6EY6SLHTZNs/jBsFkr6iF6xeIa9dsnwrI7ebNat8ApGQTX2 sydzIECiElqKiYNwk9XEn+e3aNgryoBhGx2Ax+fWxHHBB+kojhnFBHVQ1Qg2WaE= =ixlS -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: acpi suspend debugging techniques?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 09/03/2015 13:50, Andriy Gapon wrote:
> On 31/08/2015 11:53, Adrian Chadd wrote:
>> Try disabling hardware one at a time. Ie, unload usb; unload
>> wifi; leave kms loaded for mostly obvious reasons.
>
> Adrian, Garrett,
>
> thank you very much for your tips. Turned out that it was radeonkms
> that was causing the problem :-)
>
> BTW, here is another tool for the toolkit: on sufficiently recent
> system devctl suspend and devctl resume can be used to test
> individual drivers.
>
> So, I noticed that I could suspend/resume drmn0 device just fine
> but with vgapci0 I had a trouble suspending. One thing led to
> another and here is a patch that seems to fix the problem for me:
> --
- -
>
>
commit fecb5e8a90631f06600d87165cc8b6de3e035dfc
> Author: Andriy Gapon <a...@icyb.net.ua> Date: Thu Sep 3 17:24:23
> 2015 +0300
>
> radeon_suspend_kms: don't mess with pci state that's managed by the
> bus
>
> The pci bus driver handles the power state and configuration state
> saving and restoring for its child devices.
>
> diff --git a/sys/dev/drm2/radeon/radeon_device.c
> b/sys/dev/drm2/radeon/radeon_device.c index
> e5c676b11ed47..73b2f4c51ada2 100644 ---
> a/sys/dev/drm2/radeon/radeon_device.c +++
> b/sys/dev/drm2/radeon/radeon_device.c @@ -1342,14 +1342,10 @@ int
> radeon_suspend_kms(struct drm_device *dev)
>
> radeon_agp_suspend(rdev);
>
> - pci_save_state(device_get_parent(dev->dev)); #ifdef FREEBSD_WIP
> if (state.event == PM_EVENT_SUSPEND) { /* Shut down the device */
> pci_disable_device(dev->pdev); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(dev->dev, PCI_POWERSTATE_D3); -#ifdef
> FREEBSD_WIP } console_lock(); #endif /* FREEBSD_WIP */ @@ -1380,10
> +1376,6 @@ int radeon_resume_kms(struct drm_device *dev)
>
> #ifdef FREEBSD_WIP console_lock(); -#endif /* FREEBSD_WIP */ -
> pci_set_powerstate(device_get_parent(dev->dev),
> PCI_POWERSTATE_D0); -
> pci_restore_state(device_get_parent(dev->dev)); -#ifdef
> FREEBSD_WIP if (pci_enable_device(dev->pdev)) { console_unlock();
> return -1;
> --
- -
>
> However, I am not sure about an exact mechanism of the hard system
> hang that I experienced without the patch.
>
> BTW, I noticed that only very few drivers make explicit calls to
> pci_set_powerstate and pci_save_state/pci_restore_state.
> sys/dev/usb/controller/ohci_pci.c looks like a good use of
> pci_set_powerstate. sys/dev/ixgbe/if_ix.c looks like an incorrect /
> redundant use of the functions.
AFAICT, the whole suspend/resume code looks incomplete and very messy.
In fact, I'll be very surprised if it ever worked. :-(
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJV6MdGAAoJEHyflib82/FGJ68H/2W6IfhDrtciL2LmA67T0VHU
Nagp1Oghp+JDw/iVB28Sxf/EXptsZKUeKvSYYilIFHsl/d/+uPvhbaxLVWUSyhGe
C5vVCbSkyRwnz3I5iiMab9Ou+VFTVqHhNLgrCFfDvjeHssbIkD7+bEuldWyqOIFH
rvvvZ8qGebVV7jcfU3lVVUz3tNwLwgdtVPuZIohxc8M7n1pE185hnUa1b37pytC9
btrCYLstGRNBbaD530iMN0bXM02aWgUTbf9cVH31nYduQaYOPYe/JgNKLzbmJ0gL
JIhGh4eubyR4W2SonRsg1ahHHzSr1pe1o7TVuU+2G1fycz4GSLoFWzYnSTxDMc4=
=IAfV
-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: acpi suspend debugging techniques?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/03/2015 18:30, David Wolfskill wrote: > [Much trimming, both of older content and recipient addresses -- > dhw] > > On Thu, Sep 03, 2015 at 06:18:52PM -0400, Jung-uk Kim wrote: >> ... AFAICT, the whole suspend/resume code looks incomplete and >> very messy. In fact, I'll be very surprised if it ever worked. >> :-( >> >> Jung-uk Kim ... > > While I bow to your expertise in the area, I point out that I > routinely suspend my laptop before putting it in my backpack, then > cycling between the shuttle stop and my house during my daily > commutes to & from work -- usually running stable/10, but I'm > sometimes running head at the time. > > And I track both stable/10 and head daily on that laptop (in > different slices). > > While I do encounter "issues" from time to time, those are rare > enough that I'd call them "unusual." (To quantify that, I think > I've had 3 - 5 such incidents since November 2014, while generally > commuting 5 days/week.) > > I'll be happy to test. :-) I am not saying the patch is wrong. Actually, it is in the right direction. If you can, please test the following patch, too. - --- sys/dev/drm2/radeon/radeon_drv.c (revision 287437) +++ sys/dev/drm2/radeon/radeon_drv.c(working copy) @@ -327,14 +327,14 @@ radeon_suspend(device_t kdev) struct drm_device *dev; int ret; + ret = bus_generic_suspend(kdev); + if (ret) + return (ret); + dev = device_get_softc(kdev); ret = radeon_suspend_kms(dev); - - if (ret) - - return (-ret); - - ret = bus_generic_suspend(kdev); - - - - return (ret); + return (-ret); } static int Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJV6M6cAAoJEHyflib82/FGX1UH/0BaQl+/e7Cqc2+3jdcmuusd P8gJBGIFu89+6KsA2J1btQQYO2wwA9tJkpkZx4oi/pT+L+pIqZGx7/w7klsfXvXd gfI0looWxzB5ZALCrzYq50Nk67E9s6iXymRMJ95oyZ2GLkbwLqY6gOStqld7vBuE Z4iEBYHMrDtojd33w/9SRa8zNSpvwXZJliNjhpFd680ApkSO2xN/dIxI/z1JjlEw oquRpvFlR4urqCdhYmKyjoXuR7rYdl0K2imfA7EjL2RFzlFyacS+ny4BqnbvMqzC tMNxYFUOEvxMW+336DKZjiRWgAyfmJiOuoFxRoDiCq42zzjcLF+2gnLlcd4/j+4= =/r95 -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: ntpd errors after upgrade on current amd64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/02/2015 21:26, Cy Schubert wrote: In message 551da257.6060...@freebsd.org, Jung-uk Kim writes: This is a multi-part message in MIME format. --090800070300040107060309 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/01/2015 11:32, Manfred Antar wrote: After build install world on current ntpd doesn't work. Here is error: FreeBSD/amd64 (pozo.com) (ttyu0) login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax error ntp_crypto.c was not properly merged. Basically, the fix for SA-14:31.ntp was applied twice. Please try the attached patch. Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0 for fe80::1%2 fails: Can't assign requested address A separate issue, I think. Jung-uk Kim * Note: ntp_parser.y is redundant and it was the root cause of inconsistent builds and build failures, i.e., ntp_parser.c and ntp_parser.h may be regenerated on the *source* directory depending on phase of the moon. Although we can re-gen them after r280915, upstream does not support BSD yacc. Ntp_parser.y is not redundant. It is redundant because ntp_parser.c and ntp_parser.h are generated from ntp_parser.y. Once it is done, it can be safely removed. Remove it and see for yourself. It is referenced by ntp_parser.c. Nope. # grep ntp_parser.y /usr/src/contrib/ntp/ntpd/ntp_parser.c #line 14 ntp_parser.y /* yacc.c:339 */ #line 54 ntp_parser.y /* yacc.c:355 */ #line 371 ntp_parser.y /* yacc.c:1646 */ ... # grep ntp_parser.y /usr/src/contrib/ntp/ntpd/ntp_parser.h #line 54 ntp_parser.y /* yacc.c:1909 */ These are inserted for debugging purpose only. See yacc(1) for -l optio n. I put that fix in two days ago. Your fix is just to make ntp_parser.y compilable with our yacc(1). Now ntp_parser.c and ntp_parser.h may be regenerated and *overwritten* depending upon timestamps of these files. # svn revert /usr/src/contrib/ntp/ntpd/ntp_parser.[chy] # touch /usr/src/contrib/ntp/ntpd/ntp_parser.y # cd /usr/src/usr.sbin/ntp/ntpd # make depend yacc -d /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_parser. y mv y.tab.c /usr/src/usr.sbin/ntp/ntpd/../../../contrib/ntp/ntpd/ntp_parser.c ... # svn stat /usr/src/contrib/ntp/ntpd/ntp_parser.? M /usr/src/contrib/ntp/ntpd/ntp_parser.c Unfortunately, bundled ntp_parser.c and ntp_parser.h were originally generated with GNU Bison and the new ntp_parser.c is totally different. # svn diff /usr/src/contrib/ntp/ntpd/ntp_parser.c | grep ^+ | wc -l 1918 # svn diff /usr/src/contrib/ntp/ntpd/ntp_parser.c | grep ^- | wc -l 3214. If you really want to keep ntp_parser.y for some reason, ntp_parser.c and ntp_parser.h must be removed from source tree instead. Also, you have to patch /usr/src/usr.sbin/ntp/ntpd/Makefile a little (hint: replace ntp_parser.c with ntp_parser.y for SRCS and add -I. to CFLAGS) . Basically, you have to remove either ntp_parser.y or ntp_parser.[ch]. You just can't keep them all. I'll re-merge based on your second patch/the posted fix. I'll try it first in the port though. Okay. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJVHkDoAAoJEHyflib82/FGTVQIAJ6wEudATveKaYSTok9Q5T5K xwE3Ym6XdZqEXprKCSfeIea+EqeWNLmf7uDOsPqr2k0KwwN//sHhXAWR/9ze4+em auypHxM3LTUEYZnoBvy17dOJ1gde/3jXZt9q8ZLnz3M91W439j5jWGGU6LXY97wy Vlv97eqISEMPvI21pA3EI3xC3f56xM6fjruDMAq6VLarAfTaLmhn5fbMpP5XEBBF hybSde+YVf36i/ojKPUYz2mSyJ1y7j+zR0n+S+ccLnGfoS/sXePdoDzjm0lNWVDa bRpkZYbWrVQiGyw+equs6WORKBh0ZIICBaQa0IPGycrD0UKt37wx0YzN7xRDsQo= =tkma -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ntpd errors after upgrade on current amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/01/2015 11:32, Manfred Antar wrote:
After build install world on current ntpd doesn't work. Here is
error:
FreeBSD/amd64 (pozo.com) (ttyu0)
login: Apr 1 08:29:19 pozo ntpd[49825]: line 22 column 1 syntax
error
ntp_crypto.c was not properly merged. Basically, the fix for
SA-14:31.ntp was applied twice. Please try the attached patch.
Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0
for fe80::1%2 fails: Can't assign requested address
A separate issue, I think.
Jung-uk Kim
* Note: ntp_parser.y is redundant and it was the root cause of
inconsistent builds and build failures, i.e., ntp_parser.c and
ntp_parser.h may be regenerated on the *source* directory depending on
phase of the moon. Although we can re-gen them after r280915,
upstream does not support BSD yacc.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVHaJXAAoJEHyflib82/FGla0H/i7cQunatuUUhGYPGGenmy1X
DEo7zL/LYNWX7XY392dIDKFGZguvErehVy7KNiVXZzrlsz0JRVpQp/r8OT6xPrFF
lGFaOgGB9tfIYKZl+Bn2gE40mwtfp7UX3B2nIswwF2SFBhyuJPiIZ5Y+j3YDyIHS
/BGUs0D+CaKq9RgU66QrowMOtA/uElWix44VHVSNJ2knAL+x6cZF4VzNTC+6wG2c
DVODrTMSqMAwiIkPYJCndbxH7C9ZaQEHVq19pTmYRb1V7x2VO0/3NrBJJYSP9GGe
PQS/HiU9lkIi/JSj3AN9+ntyzKpne/DJz6/AAe/JpCGj/o1Ke+ageA6m7yoqHL8=
=wNw9
-END PGP SIGNATURE-
Index: contrib/ntp/ntpd/ntp_crypto.c
===
--- contrib/ntp/ntpd/ntp_crypto.c (revision 280991)
+++ contrib/ntp/ntpd/ntp_crypto.c (working copy)
@@ -826,10 +826,10 @@ crypto_recv(
* Decrypt the cookie, hunting all the time for
* errors.
*/
- if (vallen == (u_int) EVP_PKEY_size(host_pkey)) {
+ if (vallen == (u_int)EVP_PKEY_size(host_pkey)) {
u_int32 *cookiebuf = malloc(
RSA_size(host_pkey-pkey.rsa));
-if (cookiebuf == NULL) {
+if (!cookiebuf) {
rval = XEVNT_CKY;
break;
}
@@ -3817,7 +3817,7 @@ crypto_setup(void)
randfile);
exit (-1);
}
- get_systime(seed);
+ arc4random_buf(seed, sizeof(l_fp));
RAND_seed(seed, sizeof(l_fp));
RAND_write_file(randfile);
#ifdef DEBUG
@@ -3850,36 +3850,6 @@ crypto_setup(void)
pinfo = crypto_key(filename, passwd, NULL);
if (pinfo == NULL) {
msyslog(LOG_ERR,
- crypto_setup: random seed file not specified);
- exit (-1);
- }
- if ((bytes = RAND_load_file(rand_file, -1)) == 0) {
- msyslog(LOG_ERR,
- crypto_setup: random seed file %s not found\n,
- rand_file);
- exit (-1);
- }
- arc4random_buf(seed, sizeof(l_fp));
- RAND_seed(seed, sizeof(l_fp));
- RAND_write_file(rand_file);
- OpenSSL_add_all_algorithms();
-#ifdef DEBUG
- if (debug)
- printf(
- crypto_setup: OpenSSL version %lx random seed file %s bytes read %d\n,
- SSLeay(), rand_file, bytes);
-#endif
-
- /*
- * Load required host key from file ntpkey_host_hostname. If
- * no host key file is not found or has invalid password, life
- * as we know it ends. The host key also becomes the default
- * sign key.
- */
- snprintf(filename, sizeof(filename), ntpkey_host_%s, hostname);
- pinfo = crypto_key(filename, passwd, NULL);
- if (pinfo == NULL) {
- msyslog(LOG_ERR,
crypto_setup: host key file %s not found or corrupt,
filename);
exit (-1);
Index: contrib/ntp/ntpd/ntp_parser.y
===
--- contrib/ntp/ntpd/ntp_parser.y (revision 280991)
+++ contrib/ntp/ntpd/ntp_parser.y (working copy)
@@ -1,1641 +0,0 @@
-/* ntp_parser.y
- *
- * The parser for the NTP configuration file.
- *
- * Written By: Sachin Kamboj
- * University of Delaware
- * Newark, DE 19711
- * Copyright (c) 2006
- */
-
-%parse-param { struct FILE_INFO *ip_file }
-%lex-param { struct FILE_INFO *ip_file }
-
-%{
- #ifdef HAVE_CONFIG_H
- # include config.h
- #endif
-
- #include ntp.h
- #include ntpd.h
- #include ntp_machine.h
- #include ntp_stdlib.h
- #include ntp_filegen.h
- #include ntp_scanner.h
- #include ntp_config.h
- #include ntp_crypto.h
-
- #include ntpsim.h /* HMS: Do we really want this all the time? */
-/* SK: It might be a good idea to always
- include the simulator code. That way
- someone can use the same configuration file
- for both the simulator and the daemon
-*/
-
- #define YYMALLOC emalloc
- #define YYFREE free
- #define YYERROR_VERBOSE
- #define YYMAXDEPTH 1000 /* stop the madness sooner */
- void yyerror(struct FILE_INFO *ip_file, const char *msg);
-
- #ifdef SIM
- # define ONLY_SIM(a) (a)
- #else
- # define ONLY_SIM(a) NULL
- #endif
-%}
-
-/*
- * Enable generation of token names array even without YYDEBUG.
- * We access via token_name() defined below.
- */
-%token-table
-
-%union {
- char * String;
- double Double;
- int Integer;
- unsigned U_int;
- gen_fifo * Generic_fifo;
- attr_val * Attr_val;
- attr_val_fifo * Attr_val_fifo;
- int_fifo * Int_fifo;
- string_fifo * String_fifo;
- address_node * Address_node;
- address_fifo
Re: ntpd errors after upgrade on current amd64
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/02/2015 16:11, Jung-uk Kim wrote:
On 04/01/2015 11:32, Manfred Antar wrote:
Apr 1 08:29:19 pozo ntpd[49825]: setsockopt IPV6_MULTICAST_IF 0
for fe80::1%2 fails: Can't assign requested address
A separate issue, I think.
This issue will be fixed in the next release, it seems.
http://lists.ntp.org/pipermail/bk-ntp-stable-send/2015-March/000594.html
Please try the updated patch. It fixed the problem for me. Note this
patch supersedes the previous patch.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJVHbTRAAoJEHyflib82/FGPP0H/iZpzPxGokR1CD16K4i/dH/F
qSfefNpW20dnl3ozIv3P0e1yC/xxMUJJNF4HQ8fwjr1bTI3efZ8gTPR2Zk3k5r7i
2OcQfrQma3cSkzoks6tjobor/yGpQEHJkwFwSSEsUKgA/rI0FpvviHQsQOi/6BnA
KbWQWLt5ZTe/V/27Zc2AU38evJxRFiYiJTycutQzMZ1NHle8DWqQ7vMKOe+CilAW
MX/16AW2tp2yrBs9XQKmkh0Yd2dTLJuBxAV7Rl8cVUZgdELqyE2FNSEL7L7TKKbs
QjJj6+7oee/c22Fc11CA7fBRFkK6m8fzmL/2CuTvf0JLefisCvMMcymvxH/edoM=
=UPrE
-END PGP SIGNATURE-
Index: contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c
===
--- contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (revision 281003)
+++ contrib/ntp/lib/isc/unix/ifiter_getifaddrs.c (working copy)
@@ -212,6 +212,9 @@ internal_current(isc_interfaceiter_t *iter) {
get_addr(family, iter-current.broadcast, ifa-ifa_broadaddr,
ifa-ifa_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter-current.ifindex = if_nametoindex(iter-current.name);
+#endif
return (ISC_R_SUCCESS);
}
Index: contrib/ntp/lib/isc/unix/ifiter_ioctl.c
===
--- contrib/ntp/lib/isc/unix/ifiter_ioctl.c (revision 281003)
+++ contrib/ntp/lib/isc/unix/ifiter_ioctl.c (working copy)
@@ -588,6 +588,9 @@ internal_current4(isc_interfaceiter_t *iter) {
}
iter-current.netmask.type.in6.s6_addr[i] = (~0 bits) 0xff;
}
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter-current.ifindex = if_nametoindex(iter-current.name);
+#endif
return (ISC_R_SUCCESS);
inet:
@@ -664,6 +667,9 @@ internal_current4(isc_interfaceiter_t *iter) {
}
get_addr(family, iter-current.netmask,
(struct sockaddr *)ifreq.ifr_addr, ifreq.ifr_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter-current.ifindex = if_nametoindex(iter-current.name);
+#endif
return (ISC_R_SUCCESS);
}
@@ -704,7 +710,6 @@ internal_current6(isc_interfaceiter_t *iter) {
get_addr(family, iter-current.address,
(struct sockaddr *)lifreq.lifr_addr, lifreq.lifr_name);
- iter-current.ifindex = lifreq.lifr_index;
if (isc_netaddr_islinklocal(iter-current.address))
isc_netaddr_setzone(iter-current.address,
(isc_uint32_t)lifreq.lifr_index);
@@ -844,7 +849,9 @@ internal_current6(isc_interfaceiter_t *iter) {
iter-current.netmask.type.in6.s6_addr[i / 8] =
(~0 bits) 0xff;
}
-
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter-current.ifindex = if_nametoindex(iter-current.name);
+#endif
return (ISC_R_SUCCESS);
}
#endif
@@ -867,6 +874,9 @@ internal_current6(isc_interfaceiter_t *iter) {
get_addr(family, iter-current.netmask,
(struct sockaddr *)lifreq.lifr_addr, lifreq.lifr_name);
+#ifdef ISC_PLATFORM_HAVEIFNAMETOINDEX
+ iter-current.ifindex = if_nametoindex(iter-current.name);
+#endif
return (ISC_R_SUCCESS);
}
#endif
Index: contrib/ntp/ntpd/ntp_crypto.c
===
--- contrib/ntp/ntpd/ntp_crypto.c (revision 281003)
+++ contrib/ntp/ntpd/ntp_crypto.c (working copy)
@@ -826,10 +826,10 @@ crypto_recv(
* Decrypt the cookie, hunting all the time for
* errors.
*/
- if (vallen == (u_int) EVP_PKEY_size(host_pkey)) {
+ if (vallen == (u_int)EVP_PKEY_size(host_pkey)) {
u_int32 *cookiebuf = malloc(
RSA_size(host_pkey-pkey.rsa));
-if (cookiebuf == NULL) {
+if (!cookiebuf) {
rval = XEVNT_CKY;
break;
}
@@ -3817,7 +3817,7 @@ crypto_setup(void)
randfile);
exit (-1);
}
- get_systime(seed);
+ arc4random_buf(seed, sizeof(l_fp));
RAND_seed(seed, sizeof(l_fp));
RAND_write_file(randfile);
#ifdef DEBUG
@@ -3850,36 +3850,6 @@ crypto_setup(void)
pinfo = crypto_key(filename, passwd, NULL);
if (pinfo == NULL) {
msyslog(LOG_ERR,
- crypto_setup: random seed file not specified);
- exit (-1);
- }
- if ((bytes = RAND_load_file(rand_file, -1)) == 0) {
- msyslog(LOG_ERR,
- crypto_setup: random seed file %s not found\n,
- rand_file);
- exit (-1);
- }
- arc4random_buf(seed, sizeof(l_fp));
- RAND_seed(seed, sizeof(l_fp));
- RAND_write_file(rand_file);
- OpenSSL_add_all_algorithms();
-#ifdef DEBUG
- if (debug)
- printf(
- crypto_setup: OpenSSL version %lx random seed file %s bytes read %d\n,
- SSLeay(), rand_file, bytes);
-#endif
-
- /*
- * Load required host key from file ntpkey_host_hostname. If
- * no host key file is not found or has invalid password, life
- * as we know it ends. The host key also becomes
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 03/05/2015 10:44, Craig Rodrigues wrote: Hi, I ran into this problem when doing a src upgrade of a HEAD system compiled on Oct. 21, 2014 to HEAD on March 4, 2015: yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y maximum table size exceeded *** [aslcompilerparse.c] Error code 2 make[5]: stopped in /usr/src/usr.sbin/acpi/iasl 1 error Does your fix address the problem in HEAD or just STABLE? Just stable. http://docs.freebsd.org/cgi/mid.cgi?54EE05EA.3030509 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJU+I9/AAoJEHyflib82/FG8XwH/3cYegfWMB0fl2Hsa+Z+VlrB SYIS/opP4NpmhXYbwwwhfA8/QHxhTASGxXqrKKtw3zyD8VTox1/t45Bf6tieN3I0 a3tIsQ9Rjbpm9FbOKy+fTGaC1FVl8pBkO/Sp0o3dXVCP2X7ljiyDSpasMMolz9Od TFD2Rrz1wVNRJeCYod9vxQ3SVUEqX2MKk29JOHWZ4BBxCp4nnvXVowM8Pyz58ene LuBEBW9tNhYp7+GBiUntZYYQ0iFIYlWYzGIyku5dHJxntV56ALVsENoWamsQ3Fwc 6pkxZl8KVCRx9MWhQIU5r6mJhTK3UZBjBEYJpUSKN9CSpH+SuMJXEK/9omKZZ9w= =Z0Gm -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/25/2015 11:22, Ivan Klymenko wrote: В Wed, 25 Feb 2015 15:43:27 + Glen Barber g...@freebsd.org пишет: On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin wrote: I have clean svn tree with base/head branch. I try to build world, but I have some mysterious bugs. The latest is yacc failed to make c file on phase 4.3: === usr.sbin/acpi/iasl (depend) m4 -P -I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y aslcompiler.y yacc -d -pAslCompiler -oaslcompilerparse.c aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f - maximum table size exceeded *** Error code 2 /etc/make.conf is /dev/null. I've also tried empty /etc/src.conf with no luck. Out of curiosity, is your src tree mounted via NFS? Glen I have a similar problem on revision /usr/src # svn info Path: . Working Copy Root Path: /usr/src URL: svn://svn.freebsd.org/base/head Relative URL: ^/head Repository Root: svn://svn.freebsd.org/base Repository UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213 Node Kind: directory Schedule: normal Last Changed Author: glebius Last Changed Rev: 279213 Last Changed Date: 2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015) http://pastebin.com/FuAUkBmX Source tree is on the zfs /usr/src # zfs list zroot/usr/src NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G 408G 1.35G /usr/src what is most surprising, the same revision successfully building for the other 2 computers, including amd64|zfs and i386|ufs. Your installed yacc(1) is too old, i.e., your world was built from head before r274460. FYI, this commit fixes the above problem for building from stable: https://svnweb.freebsd.org/changeset/base/278975 For building from old head (pre-r274460), you have to manually bootstrap yacc first, e.g., something like this: cd /usr/src/usr.bin/yacc make clean cleandepend make all make install make clean cleandepend cd /usr/src make buildworld Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJU7gXkAAoJEHyflib82/FGAsMH/iw2oNbyOPY7t/GIm+7QpqKS 4jOZisFY9WD8UCpziqwnp5Ia1A4YC4rn7W5G6wKALHMTuo3kT8lFEWV5sIVhc0dm 7to624zTVsNZqBhCFODRMZSXSlpMNCkjWtixGT1spEmyUAeKSEq5dPLaj3JyOOUw XvZbY6l4f/jFr+68z/uIHRJi3NbP5SODIYuUanO7X0nVuxI0PQNE45o3p2dj7lRJ 9eV0G5/SJUT8uWSuXy2kOY+TZWAk8VTTz/nb+krKPtwBdsv+nhSu3NDuaTJQk4gm KaA+FaOgP/vhyxrF61qBOVq+MDy66/XuU4s/9IKrRoeUrZX0j5X4JoGC1p2+cgU= =lpVt -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:59, Arseny Nasokin wrote:
On 25 February 2015 at 22:14, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org wrote:
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
mailto:j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was
built from head before r274460. FYI, this commit fixes the
above problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to
manually bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap
build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes
only!!! _yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10
and __FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
Jung,
I have FreeBSD 11.0-CURRENT r265265 with OSRELDATE 1100020 and
invalid YACC. So This conditional expression must be fixed to check
if this 11.x and yacc is not changed.
Wow, that's more than 9-month old now.
In my hypothetical patch I set OSRELDATE to invalid abstract
future version, because it's only concept and I have no time to fix
it correctly now.
If you insist, you can try this:
- --- Makefile.inc1
+++ Makefile.inc1
@@ -1274,7 +1274,8 @@
_awk= usr.bin/awk
.endif
- -.if ${BOOTSTRAPPING} 1001506
+.if ${BOOTSTRAPPING} 1001506 || \
+(${BOOTSTRAPPING} = 110 ${BOOTSTRAPPING} 1100046)
_yacc= lib/liby \
usr.bin/yacc
(but I won't commit it.)
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7i1kAAoJEHyflib82/FGh9kH/07QOQ+xlPQVApJD+x1u/c4b
G1g4mmOhEKKOjVK9dJFKY1hvTiLYkOB3UDwJH8rmzbglInY+eepbD9Ac15Dtl90b
RFvNEB3B7Rwzt9ljg2zH/OQ6HnPCHgreF31ggkmKLszQ/Rrv62KTmN9ML4dkx897
7jAPwwtMb2XfLzyAc2fMNne3xl/zmdzafcqA+87UOUJ3Jb4rv35/x3kSrOqsMzvj
A3ufAepzG2J0+fH62ZP2L/FfuXoaKP0hlIpXZwNYAciSf+GAa7McYyu1aaRZQedF
1DSphDtSFnJKR+ltIvDL5WH98Zi0iOu5FHb9bLfW/s+bV+oxs4/ZQHtxsIejLN4=
=3xA9
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 14:05, Glen Barber wrote:
On Wed, Feb 25, 2015 at 10:51:31PM +0400, Arseny Nasokin wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
Your installed yacc(1) is too old, i.e., your world was built
from head before r274460. FYI, this commit fixes the above
problem for building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all
make install make clean cleandepend cd /usr/src make
buildworld
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
This can be set to 1001507 now; __FreeBSD_version was bumped
earlier today.
Nope, 1001506 is correct, i.e., the change was MFC'ed to stable/10 and
__FreeBSD_version was bumped to reflect it.
https://svnweb.freebsd.org/changeset/base/277087
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7h8dAAoJEHyflib82/FGL9cH/A3wsEEjtUNGcmOfYHN2+l50
K9xCxRwLvioxOjFygnHoNTvxhSMxjMCvX7UtyLR3CWD/31FJEsGgv7uFoavAMUPq
hk5vAUJgoAbue4FwF6Ow7Lmm59dl+4ukVqEawepYFlYn6njLgJt1itF74VD9aufi
D1oRk72KhhPXe66DYJsXzybgq5ba2/eJy0/YLsheRnsb2zB7fEcHGGca1icAVgjm
794BQdk0kOG7+EkQcafIElY4HJb+mJCE4iFg3NCrhrs7wEYZZQXlqDUVKRd0R5kN
U4u4EiXckiyDVPrzicnpVCtQD5vdxH5BBfWC1FQIFnzTJgLZuRihLpfmDZOeHS8=
=+AsC
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: r279278 failed to build (yacc: maximum table size exceeded)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 02/25/2015 13:55, Garrett Cooper wrote:
On Feb 25, 2015, at 10:51, Arseny Nasokin eir...@gmail.com
wrote:
On 25 February 2015 at 20:27, Jung-uk Kim j...@freebsd.org
wrote:
On 02/25/2015 11:22, Ivan Klymenko wrote:
В Wed, 25 Feb 2015 15:43:27 + Glen Barber
g...@freebsd.org пишет:
On Wed, Feb 25, 2015 at 07:32:45PM +0400, Arseny Nasokin
wrote:
I have clean svn tree with base/head branch. I try to
build world, but I have some mysterious bugs. The
latest is yacc failed to make c file on phase 4.3:
=== usr.sbin/acpi/iasl (depend) m4 -P
-I/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler
/usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/compiler/aslparser.y
aslcompiler.y
yacc -d -pAslCompiler -oaslcompilerparse.c
aslcompiler.y yacc: 89 shift/reduce conflicts. yacc: f
- maximum table size exceeded *** Error code 2
/etc/make.conf is /dev/null. I've also tried empty
/etc/src.conf with no luck.
Out of curiosity, is your src tree mounted via NFS?
Glen
I have a similar problem on revision /usr/src # svn info
Path: . Working Copy Root Path: /usr/src URL:
svn://svn.freebsd.org/base/head Relative URL: ^/head
Repository Root: svn://svn.freebsd.org/base Repository
UUID: ccf9f872-aa2e-dd11-9fc8-001c23d0bc1f Revision: 279213
Node Kind: directory Schedule: normal Last Changed Author:
glebius Last Changed Rev: 279213 Last Changed Date:
2015-02-23 20:57:09 +0200 (Mon, 23 Feb 2015)
http://pastebin.com/FuAUkBmX
Source tree is on the zfs /usr/src # zfs list zroot/usr/src
NAME USED AVAIL REFER MOUNTPOINT zroot/usr/src 1.35G
408G 1.35G /usr/src
what is most surprising, the same revision successfully
building for the other 2 computers, including amd64|zfs and
i386|ufs.
Your installed yacc(1) is too old, i.e., your world was built from
head before r274460. FYI, this commit fixes the above problem for
building from stable:
https://svnweb.freebsd.org/changeset/base/278975
For building from old head (pre-r274460), you have to manually
bootstrap yacc first, e.g., something like this:
cd /usr/src/usr.bin/yacc make clean cleandepend make all make
install make clean cleandepend cd /usr/src make buildworld
Jung-uk Kim
Hi, guys,
I've found the fix by forcing to add yacc(1) to bootstrap build.
Makefile.inc1, line 1277:
if ${BOOTSTRAPPING} 1001506 _yacc= lib/liby \
change to:
if ${BOOTSTRAPPING} 1201506 ## It is for test purposes only!!!
_yacc= lib/liby \
It takes a few seconds to build this on my laptop — can we just
explicitly turn this on to be sure we’re using the right thing?
% (cd lib/liby; time sh -c 'make obj; make depend; make all')
real0m0.326s user0m0.031s sys 0m0.111s
% (cd usr.bin/yacc/; time sh -c 'make obj; make depend; make all')
real0m3.431s user0m2.631s sys 0m0.363s
With me parallelizing bootstrap-tools on HEAD it should be less of
an issue stacking on items like this.
Then, this argument also applies to other conditional bootstrap-tools,
e.g., bin/cat.
I know we have long tradition of painting bikesheds with different
colors and it will probably never end. However, I will not
participate in this one, sorry.
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2
iQEcBAEBCAAGBQJU7h4zAAoJEHyflib82/FGEPkH/0SoSYzFfCifBUS14JiSn6hC
0O544JmeJE4giPAfk6h/vbKzJ43Q/NTvPRrayj2XZHNLJzzwH4fZsInFlqdfirna
Yqv0WTXHt2ZycsaP8ZxANF020eG8MV9L9q4r6xo1piiiWZMC9NlgbI8SQGC56Rbd
nTSL4sKIcCBdfImpUMLnVBvIMFrP4FbxBdqAYNbc6JlwxWtIWPesJMdgpHJgg/5F
tBJIHq3SgChOQjxxmIwwdiv/m25jx9b4247gxjdITpxUfaaUephsMa7qZ35RlURU
AMsUWeINzZmvWbOORSnxHKCClxkDav+kPGVk105tzNv4P6FnyhWgoGm+cb1hlNI=
=dSyP
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/05/2015 07:56, Lev Serebryakov wrote: Is here any possibility to add virtualbox driver to vt? Now console of -CURRENT guest in VirtualBox (using vga driver) is almost unusable slow! Sorry, we do not have KMS for VirtualBox guest yet. I'm not sure, that VirtualBox has API for paravirtualized screen output, though (guest addons?). Someone with copious free time and enough knowledge should be able to port Linux KMS/DRM2 driver for us. https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux It shouldn't be too hard. ;-) Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUqsXNAAoJEHyflib82/FGni4H/RJrYLCNoYKdny70LJ0O6+o0 Mh5sf/fdfUkmfynrbyDAgCFfXdzD2/3p2NIX4WGgysUxOTgtWGFTLW67VNnQupwK pBSwz7Ute4LrSmXgHiKeNsduYtiIsOTY6744iFnEeELRgcY+g/ZDGxa6+zH2YxVW 82wWvbkgQA6wWtJw9sPOTYn2SjXRC+TUUcZcIqhcFxSdnJwpMzJ0QFEzrWxwV7hy ip3fi5XLlGqiPrv6C67m0L+YgZPRfMe2vA1/nDvOqzdVari+72TnffcKx/xvVgEO ZqQRG2P61Itut8b8LDS2bLEQQRpBILFbe7mpdlcAaYoLhdHFGfjjEYvrYcAn9cI= =o1su -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/05/2015 12:27, Lev Serebryakov wrote: On 05.01.2015 20:11, Jung-uk Kim wrote: Someone with copious free time and enough knowledge should be able to port Linux KMS/DRM2 driver for us. https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux It shouldn't be too hard. ;-) This driver looks empty to me :) I meant: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm On the other hand here is https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/freebsd/drm/ This driver is UMS/DRM1. vt(4) cannot use this driver. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUqsrIAAoJEHyflib82/FGSWIH/3pS+JUOsVCJTV/jWle+3a0Y QXrCBOZCjL/dMH3r0ZRe3OvQWMwab396lMT+sSsQW59LjeVq7jf7H+nocIxHxoQr 82zkFUZazELkcjEwkguaYiGiIPgM6/HKq3wQQvGFA1Y/t8Hjs/LtEEcEjAksBeE3 bIYfLa5BWoNv+3WfVJeelbinACgp6W9V8oLZRnWzK1f6yiMfMaFwSbgGnEQuHRMz YWfL5RGlVA9Z9B7IxXN+HWvctP0cCXTpQ3uyQJ+/TFWnlFlVQs4DBYcqsJ+B1QPV MZAlVTTQgiHF7tn6LIm5E6Su7647szDF3fNCnvc/8g4bHqVDl4JMEGLWH4W/dxU= =X78W -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: vt and VirtualBox?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/05/2015 12:33, Jung-uk Kim wrote: On 01/05/2015 12:27, Lev Serebryakov wrote: On 05.01.2015 20:11, Jung-uk Kim wrote: Someone with copious free time and enough knowledge should be able to port Linux KMS/DRM2 driver for us. https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux It shouldn't be too hard. ;-) This driver looks empty to me :) I meant: https://www.virtualbox.org/browser/vbox/trunk/src/VBox/Additions/linux/drm I realized Linux KMS driver was removed by this commit. https://www.virtualbox.org/changeset/48364 Sorry, Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Upgrade to Unbound 1.5.1 incomplete?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 01/03/2015 02:45, Rainer Hurling wrote: It seems, that r276605 is missing a file 'dnstap/dnstap_config.h'. At least, I get this output, when I try to build world now: --- depend_subdir_libunbound --- In file included from /usr/src/lib/libunbound/../../contrib/unbound/util/netevent.c:48: /usr/src/lib/libunbound/../../contrib/unbound/dnstap/dnstap.h:38:10: fatal error: 'dnstap/dnstap_config.h' file not found #include dnstap/dnstap_config.h A file seems missing. I worked around it like this: sed -e 's/@ENABLE_DNSTAP@/0/' \ /usr/src/contrib/unbound/dnstap/dnstap_config.h.in \ /usr/src/contrib/unbound/dnstap/dnstap_config.h Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUp6FaAAoJEHyflib82/FGcVgH/1g+wgA+HHL0gnEIdVZnG25T ic2fcmFd2VJnkZepZ8ANW4o4Fk8FEweHXKrLaO6pADwkpF+3FMy9TookVCa5kuvZ qQOudul+mdM3e1N6AE7kYGnjjT3avWihnCLUVz/eyfHRcKZzjmYem+/OCyN2J6aE q0wL2udYrMJ3X2NMRhPWf5eGWr0vRIufIfFBaublcrIb1QwY49vHHmtaXO5CyHu1 GrM/fXtGN4SahYcDvkovhXPfsPKqIdVFROHPnM4jnzG5ycakE/boSU2bNVmYr6/d uMgU4CsiSWkpAQ7f+GZNmBlyNz6w2Ox6ym3+kgqk5UNA9HegqccjKDsUVkEEfEU= =7GN7 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: RFT: Please help testing the llvm/clang 3.5.0 import
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/16/2014 14:36, Dimitry Andric wrote: * The second exp-run had much better results: the failure with the highest number of dependencies is devel/mingw32-gcc, but this seems to be due to a problem with makeinfo, not clang. The next highest on the list is java/openjdk6, for which ports r374780 [4] was very recently committed. Unfortunately, r374780 was not enough. Instead, I just turned off -Werror for now (r374824). https://svnweb.freebsd.org/changeset/ports/374824 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJUkKgGAAoJEHyflib82/FGGtAH/jyK3fVhWeXlgID5MKov0+vq 34BwE98ppJWreu4LdkXGqCUZeciyMmcw4ROfEPo6IthIxcHsRleh+O+BnmA5wFce gMczWBO1R+uEzcSH75UhyaVJVMKy8BJ2vRU2s90GANUnMhcMvNjN0Y89+8PdCHWF zaR8oy/GlVpJ13RTbyeaMf8K0T6MyQp58VQYP1gmlhjafEjVOLO9IVZyLWVx/nsI +DtjLj1DdNrPKrV1jrVRmZ+bJqOLaLgL4FUV/vruSduA1U8E1BZgnklXqRPowXqN jmFbLYE4kiygcEmUnpVbLQeB2EWXbQq7g4pijh90qDrhCSX1rUN3gz2DxY/Mub4= =reYk -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: panic: make_dev_credv when lindev module is loaded on the recent revision
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-05-02 01:17:10 -0400, ?? wrote: Hi, Current problem has arisen in the last four days in FreeBSD head. When load lindev modules began to emerge follow panic: Unread portion of the kernel message buffer: panic: make_dev_credv: bad si_name (error=17, si_name=full) ... FYI, lindev(4) was removed in r265212. http://svnweb.freebsd.org/changeset/base/265212 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTY9GXAAoJEHyflib82/FGKPsH/3mpNaAgbC8kQuJifcXpLSux aydDOXmdvGRzpdld+4NNPPVQA6Fq8sCpUY7Z95N4e958tHrMWqEXFhzHuaOuVg0v zcRC5LyVF349US8MCx4LrDVdHT4D7YmdVd3TcVKX8nnzWTD6fPjWzHzWUqnkek7N z7SbCQB8Ect9tRXBQ5e0IwqDJUkJxOR1lBq6Phn2RUhp5VOdgnQHn0Pbm2Dd7rhd B291zuQbsRwConzzj7shsrKHhvI1AG/Qz6fv7M7d2LVkM0saLfwuyELHPPhSUt6V eUfl1whOXzKA9mtv66m4qZE3BU5HgLifSMaMvUg0pqiwV+1UWCzK7B+g7Lo15BQ= =ndxN -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make delete-old/delete-old-libs issue after r264673 build
On 2014-04-19 02:14:58 -0400, Thomas Hoffmann wrote: On Sat, Apr 19, 2014 at 1:05 AM, Jung-uk Kim j...@freebsd.org mailto:j...@freebsd.org wrote: On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim With r264674, I no longer see those errors reported at delete-old or delete-old-libs, however, I now see those errors reported at the beginning of buildworld, buildkernel, installkernel, and installworld. With r264673 I only saw the errors at delete-old and delete-old-libs. I can't reproduce it. Do you have the bsd.mkopt.mk in /usr/share/mk, i.e., did you do installworld? Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: make delete-old/delete-old-libs issue after r264673 build
On 2014-04-18 23:46:46 -0400, Thomas Hoffmann wrote: After building at -CURRENT amd64 r264673, I got the following errors running 'make delete-old' and 'make delete-old-libs': ... This should be fixed in r264674. Jung-uk Kim ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: signal 8 (floating point exception) upon resume
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2014-03-04 11:24:04 -0500, John Baldwin wrote: On Monday, March 03, 2014 6:49:08 pm Adrian Chadd wrote: I'll try this soon. I had it fail back to newcons, rather than Xorg normally dying without restoring state. It wouldn't let me spawn a shell. Logging in worked fine, but normal shell exec would eventually and quickly lead to failure, dropping me back to the login prompt. If you have set CPUTYPE in /etc/src.conf such that your userland binaries are built with SSE, etc. then I expect most things to break because the FPU is in a funky state without this patch. I suspect if you don't set CPUTYPE so that your userland binaries do not use the FPU, you can probably resume just fine without this fix. -a On 3 March 2014 11:11, John Baldwin j...@freebsd.org wrote: On Friday, February 28, 2014 9:00:57 pm Adrian Chadd wrote: On 28 February 2014 15:35, Adrian Chadd adr...@freebsd.org wrote: ... how'd this ever work in the past then? .. and I've submitted it as a PR: kern/187152 Complete stab in the dark (not compile tested) here: http://www.FreeBSD.org/~jhb/patches/i386_fpu_suspend.patch The patch for sys/amd64/amd64/cpu_switch.S is committed: http://svnweb.freebsd.org/changeset/base/262746 i386 patches may be reviewed by the original author (CC'ed). Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.22 (FreeBSD) iQEcBAEBAgAGBQJTFi3RAAoJEHyflib82/FGnboH/3qrAp+Eq/0eebEP/9wU0Ke/ y4y4yvw9nDVexKZ+c5VuTxyWvK9O0w2b+r3f5kuHWferOm22NaJCctt3E/OA5Ly2 1p3ZPvqD5cRZfkdh68AwEeJv93lg84VMSUqNUfS9rsrIU+WpHpPR46sdLpq5KxSP cY2522npmoPrwk+PaTJS4uBQeaX/3vnj5996zxavwVqwlYyR+Zqgi6FhGj+F2RJ1 Ry+9icyNx/8lUfRTLCPsCBRjlUKUk/p/8bfbQK4mSef5Gd8ZAiqdyKqgdMBUYhNA ZplkpijJjvlIIc0dYSwg8gMKmaB6amgw/LJGQit9nTkBU2bOd6L05f1dCpYAxDE= =x0sS -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 12:39:46 -0400, David Chisnall wrote: On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). Ah, I see. Now I wrote a proper fix and it looks very promising. :-) Thanks, guys! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOeDZAAoJECXpabHZMqHOL58IALyk+dvTnWqga4RQJIXA2bUC JFxqyK1CPsJSLk/IKhxGP0TFxll/oJhmCuPU9hwxqhlzrUBc+mvCE4ms0pLF/g3u DZccKQKB20xGmLRSjRIF0ErfM6vL/mpRcSGQK3kztTwTpquk9PcImLDIxs4Q8Jw8 76fvj83TYleRNNyQy6L0nrfmIRlAPcJlGc7mcbWghx0AqttVpmDTmbyXihDwlOJf fe05PNTJv6IJqMPvzf/3gr7D9MmLsZlZbOpwJgPIMCGXHbLZSVMixMs/WvzzdaSp nuCF+JDt1I9sG2eCQSkmvgQe71l1/IMW5b7sPxiOGfE6EgiUFWDtBUsAwIeAHmo= =WgDa -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 14:51:20 -0400, David Chisnall wrote: On 18 Sep 2013, at 19:49, David Chisnall thera...@freebsd.org wrote: These are not part of the public API. Oh. Yes it is. Ho hum... It seems it's removed from GCC because it broke OpenOffice.org. 8-) http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38732 http://gcc.gnu.org/viewcvs/gcc?view=revisionrevision=143170 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOgkeAAoJECXpabHZMqHOlcwIALxc3r7H3Ocj7TPOG41itms6 +pmquUmLCb6f5OR6vgbgMTdAiL2olOyKrMgOUAt/+yWtpmbgZ0pgN5iOEf4Jdh5c u31q+YtxSMlYOVDjRnj30IGaYMrUXb+mU7Fq/+SHdSeI+obYn6JLZX9aECdBtKmM tI9Jfvx6KLgq4YQyFpWsBZEMeXhH8HBpcZZUtlOE4g4V7SumkZe9TbK7N+vIQYpO NJBGRlHn6RKQ25xU0Ar5FlB+nTcSIMRn/Moc/g9C3oKDk4jeVdsj8ZWsVTZvzgoL Jo7kTPSpNnDNW68PTLm3h4xd+30zs0n4qFtW5cSbeai9IfPt9MpzzqxCmbb1DtU= =eDVE -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-18 13:20:27 -0400, Jung-uk Kim wrote: 2013년 9월 18일 13:20, Jung-uk Kim 쓴 글: On 2013-09-18 12:39:46 - -0400, David Chisnall wrote: On 18 Sep 2013, at 16:26, Tijl Coosemans t...@freebsd.org wrote: On Tue, 17 Sep 2013 21:04:14 -0400 Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote: I am still working on libc++ issues but it is much more complicated. :-( I fixed almost everything except for exception handling issues. Unfortunately, libc++/libcxxrt's exception handling is not 100% compatible with libstdc++'s and I couldn't find a proper fix. :-( Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever hacks, somewhat similar to the example on this blog page: http://zbigg.blogspot.com/2009/03/catch-on-g.html The definition of struct __cxa_exception doesn't match the one in /usr/include/c++/v1/cxxabi.h. There's an extra field at the start in the __LP64__ case: uintptr_t referenceCount. This field is present in newer versions of the ABI spec and is also there in new versions of libsupc++. It's required for implementing C++11 dependent exceptions. It shouldn't matter for code that doesn't allocate the structure (and nothing outside of libsupc++ / libcxxrt should be allocating them), because these structures are always passed around by pointers to their ends (where the _Unwind_Exception structure lives). Ah, I see. Now I wrote a proper fix and it looks very promising. :-) Committed: http://svnweb.freebsd.org/changeset/ports/327589 Thanks! Jung-uk Kim * PS: IMHO, the ABI compatibility issue must be fixed before 10.0. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.21 (FreeBSD) iQEcBAEBAgAGBQJSOj6JAAoJECXpabHZMqHOlhgIAJg0fAXSLdqR+otyUrvgcfDg fuyYMfbcaVk1yGdPuUwppFb8/hZCP0YDKRCf8JmCpisz5yEcUTQYCVmvWCfjBMTa 2Caelx2Cof2ao6o4IAaDd+qVP16Mdio3e8iAb2Kh8tbj08eLIpn5GvmEOOkNGnVN HYAONN8e5x3PJN7N+vWcNR1uYw1PZHww44KImZeQ7ejbWQwE28NBbkCwLeddB4he bafcFPXJccngoW2c9RUIm81sRycZP5vP9dwhJicBHUEK46/x0TW0SQRavH5d0Wnx E4FxksUen9lQOYtbwFPEfDTH4NnHB+zlwA7SwQgqGFXHqOBn81r3+YTzNmH4rd0= =t0tP -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-09-17 11:52:45 -0400, Baptiste Daroussin wrote:
On Tue, Sep 17, 2013 at 11:51:41AM -0400, Shawn Webb wrote:
I'm getting a build error as well, but on 9-STABLE under
Poudriere. Relevant part of the logfile:
In file included from
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:34:
In file included from /usr/local/include/mdds/multi_type_matrix.hpp:31:
/usr/local/include/mdds/multi_type_vector.hpp:85:46: error:
cannot initialize a parameter of type
'mdds::mtv::base_element_block *' with an lvalue of type 'const
element_block_type *' (aka 'const mdds::mtv::base_element_block
*') element_block_func::delete_block(p); ^
/usr/local/include/boost/interprocess/smart_ptr/unique_ptr.hpp:312:13:
note: in instantiation of member function
'mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::operator()'
requested here
ptr_.second()(ptr_.first()); ^
/usr/local/include/boost/interprocess/smart_ptr/unique_ptr.hpp:196:7:
note: in instantiation of member function
'boost::interprocess::unique_ptrmdds::mtv::base_element_block,
mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::reset'
requested here
{ reset(); } ^
/usr/local/include/mdds/compat/unique_ptr.hpp:38:7: note: in
instantiation of member function
'boost::interprocess::unique_ptrmdds::mtv::base_element_block,
mdds::multi_type_vectorcustom_string_trait::element_block_func::element_block_deleter::~unique_ptr'
requested here
class unique_ptr : public boost::interprocess::unique_ptr_T,
_Deleter ^
/usr/local/include/mdds/multi_type_vector_def.inl:2376:16: note:
in instantiation of function template specialization
'mdds::multi_type_vectorcustom_string_trait::element_block_func::set_cells_to_single_blockconst
double *' requested here
return set_cells_to_single_block(row, end_row, block_index1,
start_row1, it_begin, it_end); ^
/usr/local/include/mdds/multi_type_vector_def.inl:406:12: note:
in instantiation of function template specialization
'mdds::multi_type_vectorcustom_string_trait::element_block_func::set_cells_implconst
double *' requested here
return set_cells_impl(pos, end_pos, start_row1, block_index1,
it_begin, it_end); ^
/usr/local/include/mdds/multi_type_matrix_def.inl:239:13: note:
in instantiation of function template specialization
'mdds::multi_type_vectorcustom_string_trait::element_block_func::setconst
double *' requested here
m_store.set(get_pos(row,col), it_begin, it_end); ^
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:502:15:
note: in instantiation of function template specialization
'mdds::multi_type_matrixcustom_string_trait::setconst double
*' requested here maMat.set(nR, nC, pArray, pArray + nLen); ^
/wrkdirs/usr/ports/editors/libreoffice/work/libreoffice-4.0.5.2/sc/source/core/tool/scmatrix.cxx:92:65:
note: passing argument to parameter 'p' here
static void delete_block(mdds::mtv::base_element_block* p) ^ 1
error generated. gmake[2]: ***
[/wrkdirs/usr/ports/editors/libreoffice/work/workdir/unxfbsd.pro/CxxObject/sc/source/core/tool/scmatrix.o]
Error 1
That is the mdds error I was speaking about.
The mdds issue should be fixed by r327493. I am still working on
libc++ issues but it is much more complicated. :-(
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)
iQEcBAEBAgAGBQJSOJBZAAoJECXpabHZMqHOuroH/RckD3Ui2dbce2YwIi2iLps6
X4+vaZ0Nhn6eGts46OywoFxUKdHg7F8A8V5mgK3aWYPlO7OtzC1kRZDNpcysAWa6
6v8E8+GjCGlVvVfto9VOKbLKugkChsNm5u0ZZjahDX1aD9T6wH81kfU4JelYgif3
o+SmZA4gCYpiifDXxy6a5ShGqjVMdjZpTFGXRzlcYncfiNP+aaPX+Cg1yRooZMeX
HKrYyPUsIePLPjZrZr5bj89BuqAgyruLA4m9FYH1YDDeJkl5XiJBmNT2oa/grbKs
pWwqAD/d8gSpAyfG6pWYyGf4ObbHnzR4HiZths+xx6vT0EGrXrhrMrRjUu864kY=
=YQox
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: libreoffice build error
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-09-17 13:24:41 -0400, Jung-uk Kim wrote:
I am still working on libc++ issues but it is much more
complicated. :-(
I fixed almost everything except for exception handling issues.
Unfortunately, libc++/libcxxrt's exception handling is not 100%
compatible with libstdc++'s and I couldn't find a proper fix. :-(
Basically, C++/UNO bridge for LibreOffice/OpenOffice does some clever
hacks, somewhat similar to the example on this blog page:
http://zbigg.blogspot.com/2009/03/catch-on-g.html
libstdc++ works as expected:
$ g++ -g eh.cc
$ ./a.out
exception caught int(321)
exception caught std::string(akuku)
$ clang++ -g eh.cc
$ ./a.out
exception caught int(321)
exception caught std::string(akuku)
libc++/libcxxrt does not:
$ clang++ -stdlib=libc++ -g eh.cc
$ ./a.out
Segmentation fault (core dumped)
$ gdb -c a.out.core a.out
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and
you are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for
details.
This GDB was configured as amd64-marcel-freebsd...
Core was generated by `a.out'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/lib/libc++.so.1...done.
Loaded symbols for /usr/lib/libc++.so.1
Reading symbols from /lib/libcxxrt.so.1...done.
Loaded symbols for /lib/libcxxrt.so.1
Reading symbols from /lib/libm.so.5...done.
Loaded symbols for /lib/libm.so.5
Reading symbols from /lib/libgcc_s.so.1...done.
Loaded symbols for /lib/libgcc_s.so.1
Reading symbols from /lib/libc.so.7...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /libexec/ld-elf.so.1...done.
Loaded symbols for /libexec/ld-elf.so.1
#0 executevoid (*)() (c=0x402240 akuku(),
exc_handlers=@0x7fffd948)
at typeinfo:86
86 const char* name() const _NOEXCEPT {return __type_name;}
(Note: I intentionally used a slightly old head to demonstrate the
problem but the symptom is exactly same on a latest libc++-only machine.)
Please let me know if you have any clue for me to fix this issue.
Thanks!
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.21 (FreeBSD)
iQEcBAEBAgAGBQJSOPwNAAoJECXpabHZMqHO2ycH/3RgOcWXLQtD9pjlAN+KjQ4k
BHAssNp2mPYl/KJDb4QzpvtX+wjGU9y1tg0JGlhRU8LiuoZgbJXhvMCU1wJmJvc4
wxiKtW5c3Z37M3Oz5isoB4gIzt8xuNtwkfKEwQHS4N9MRX77lNpLYx1trjo0ly3s
MdcUvL15iqqnZ9E9A8fSIqrS9s1m6PNNNh29uHQejfN6iOy1f/EsZiLbFXNSoudj
vF9JhGpMME+OLq6ub7abMC1HIuNm0NJyrcwBuQluP10coC7ZRkPzKVuKf2NDLCz5
9gr75gGqydPUF5fXPeF+8tt54Sh8xOKdU3EOMa6+jkjwcXP67lTOD/8G8kUBXb4=
=NsKB
-END PGP SIGNATURE-
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: building i386 world on amd64 host: failed @svn
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-08-15 15:30:49 -0400, Konstantin Belousov wrote: On Thu, Aug 15, 2013 at 09:12:52PM +0200, Dimitry Andric wrote: On Aug 15, 2013, at 20:36, Konstantin Belousov kostik...@gmail.com wrote: Does the linux box defaults to pentium or higher for -march ? 64 bit atomics cannot be implemented in usermode on i386 on processors which do not have cmpxchg8b instruction. Ah yes, you are totally right, with -v it gives: COLLECT_GCC_OPTIONS='-O2' '-S' '-v' '-mtune=generic' '-march=i586' So we should really disable atomics for i486 and lower? Though I have understood that there also some pentiums without cmpxchg8b... I do not think that there was any Pentium-branded CPU which did not implemented cmpxchg8b. Some late 486 did provided cpuid, but I am almost certain that they did not have cmpxchg8b (cannot check anyway). It is actually little complicated. http://www.geoffchappell.com/studies/windows/km/cpu/cx8.htm Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJSDS5AAAoJECXpabHZMqHOGkMIAKEXxd9G0cTwjnMuQFt6D0VP ba2ZLJa2wXWzYVeelXnRxYtt2BRU8xUzc7YUC86E7pW1AdN1geR0EOt1ggTAVpX4 t1W9k2PsBCfURW+6560m3ze0xfyH66SwLuadyeyQJ0G11XWbAigTRx56j2BLZRth ghmcOqQS4tfjyDd3uKnU4JTGzRo2irmKlzsoHWuAJJ5R2qoUsr/3cxnRUU2lSBXv UHx6Ml6VM1OQgEzZkLuLD30JLAYJoCK1n7IKXdUx1cRAs1ZO8uZuMBddp8sLaymB zdn0bSjBB+vutm4/lhQA38BVZlls1O287rhwb51/3RS3Db1zTDXKw1BYf2Q5YNE= =wwyz -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Cannot startx on FreeBSD10 Current
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-06-14 10:42:23 -0400, Walter Hurry wrote: I'm running FreeBSD 10.0-CURRENT (r251572) amd64 in a VirtualBox VM. Everything seems to work properly, except that I cannot 'startx'. All I get is a blank screen and an apparently hung box. The only way out of it is Machine - Close - Send the shutdown signal. The following appears in /var/log/Xorg.0.log: -- everything looks normal up to this point (II) VBoxVideo(0): Using default gamma of (1.0, 1.0, 1.0) unless otherwise stated. (II) VBoxVideo(0): RandR 1.2 enabled, ignore the following RandR disabled message. Fatal server error: AddScreen/ScreenInit failed for driver 0 Please consult the The X.Org Foundation support at http://wiki.x.org for help. Please also check the log file at /var/log/Xorg.0.log for additional information. Segmentation fault at address 0x290 -- I don't know how to investigate this further. Any ideas? I had a similar problem a week ago. Basically, that Clang version mis-compiles xorg-server. You may want to try the latest Clang on - -CURRENT or build it with make USE_GCC=any. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRu186AAoJECXpabHZMqHOKTEH/jBqWoDWAL9JbMhdLE//fb8/ 2RXV+gqqdxqnRCD7gMDtZN9RtMBCyqvJPXYxfM45u4HprvWBKlVkAWsG6qB6MSN8 N5kmkfQyfVPB0AZhKBu2Z39Wbv/zJnjfXKWjCQfVsOYq4qHNFTMKjXZSOKcKNcuB yRxeJMQsH3q6Goj2vYe02ZLPiBz10UaDaLYJOWBbmEFymvZs4WGDirH+NnHHoeMZ 5a7jKGxPfUp1xRL6KcXCiBOGowpqq7BQCE1tsAQF2MJTHtyQyM9cQFHVGzM2FpM/ TuXz6D5/94zPwNB27TxkBAkYuXzUYR+gjzf4QKSV+KkC2zXSYGOXJgGthmjt9XM= =zFrZ -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-05-22 12:24:45 -0400, Sergey Kandaurov wrote: On 22 May 2013 00:03, Jung-uk Kim j...@freebsd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. It looks like it broke tinderbox. Note that it runs 8.3-PRERELEASE. The list of broken targets matches those with gcc set as the default compiler. Cut off from mips64 build: ... Yes, I know and I am working on it. Thanks for the reminder and sorry for the breakage. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRnPHkAAoJECXpabHZMqHOK1IH/1Jf53aAorbgKjWwVJU6cVeo diW+k5Rtd8ZVv19jSqJAXhXi8SG+Q8kIgVsqBMCunPrdnujuQijRRC743e/H5Hb3 CKxE3QXVsJgp9zJryzgasdZcSgDa28iGPi/9olRtRvBCVc1HxM//up1n+IXhnHjb vjUklvZVXkE+cjag6Zv6VXzAlqJqVNUghBdZJuCWKqg2tm7JYSUfaLcNolR3Wzpe pturNm8b9ObkFdEvX7r9uevtf1T7tEkW4ElxwqsaBwc91o65oBO6yO2yIOaJWEj6 Ha9bwJJrJHaVKroW0XmFYqLPNzVba6q+e3M1TjpDgMAtr9SQzTgCB9gnuN4FcZU= =Z84t -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
[HEADSUP] flex/lex updated to 2.5.37 (from flex.sourceforge.net)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Please note flex/lex was updated to 2.5.37 from flex.sourceforge.net and __FreeBSD_version was bumped to 133. FYI, I added couple of compatibility shims (just enough to build the previous source trees) but it is not 100% compatible with the old version. OTOH, this version is far more popular and third-party sources often require this version. Most importantly, NetBSD, DragonFly BSD, and Mac OS X already adopted it for the same reason. Cheers! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRm9MgAAoJECXpabHZMqHOhZAH/i8lZJofJNGuUOzRGZSspbYY TWwsno5S4VJDDIljO8ORAnu0oXPAbVZ1366f7TTYi258sQ0xSoUDnOoibJXQRnTI 8JaXDf3U33rGVuGNBe2Ge78TzMS895z9B+lW9UPrV3IIg0OPgCoS+SE77jb24vP0 J9vqkJgUUOWVOX9VLIH3ZRIJeSQk0PyrXpaV8v/dlw2G15gbvSZ1n99CGnVL53uZ kbHq+4F6Sre+YL/+5ZFwQk81itGdhIDPYhk5eytt9nvB/LKp+AQyiJO/+pOSF/C/ +TU9QAQ4cecIevORczygFtBD3HR41LLF9YpCd3s2vvUJtrSJX+KN4b+4cZf3SrI= =bH9U -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: openjdk6 broken on current
it by doing a bisection-search in SVN like git bisect would do. Regards Damjan Jovanovic interestingly, I set both DEBUG and FASTDEBUG, and it compiles cleanly now. Thanks for this hint! The port java/openjdk6 fails compiling for me with the above specified error (Segmentation fault) for a couple of weeks now. With the DEBUG flags set in the port's configuration, it compiles well. It is very intersting that it seems to depend on the hardware/CPU in conjunction with LLVMCLANG 3.3, whether this port compiles or not. In my case, I have two FreeBSD 10.0-CURRENT boxes running Core2Duo CPUs (E8400, Q6600) on which the port compiles. On an Ivy-Bridge i3-3220, the port also compiles well, even with -march=native -O3 flags set to the compiler. But it fails on the Sandy-Bridge-E machine (i7-3930K) with either -O3 or -O2 (but both ways -march=native set). How recent is your -CURRENT? FYI, recently we fixed couple of auto-vectorization bugs, i.e., http://svnweb.freebsd.org/base?view=revisionrevision=249817 http://svnweb.freebsd.org/base?view=revisionrevision=250593 I have feeling that one of these might fix your problem. BTW, please note adding custom compiler/linker flags are not supported. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.20 (FreeBSD) iQEcBAEBAgAGBQJRkS79AAoJECXpabHZMqHO4NkIAMt0TZ7RK0z6uCOnXOHxv4va fYRoy3om/Xkw8Rzmix9QSgSPIApOlXUjHGhtoUlxdavAItKjZEaPOaDDErw8gbzs F4JIJJwdLJTcmwbUZJNQP/j06Rldlh2KjhA8nrXPgcuwR2laK66JPtObudkdlGHq L47L+ag/b8vuLDiLrwN8fa+LZfslN919RYYdo9nGMaPDaJV1BVRbCq+0haUaVKEx 9GDrrSxHqzJpx4ACYAAoAoDSAgBniL6e2W34Y+AxRO8fWjKhMjVo6nX4XolA3rGc +fqmGdymZndjixFKy9nFTP47oUeOVmhMARMpR32Vw8UU0kg9nEJzHmgaRJgwpHU= =Th80 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT (r249438): (devel/libiconv)./unistd.h:686:5: error: invalid token at start of a preprocessor expression : #if @GNULIB_EUIDACCESS@
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-17 06:07:47 -0400, Dimitry Andric wrote: On Apr 17, 2013, at 07:31, Jan Beich jbe...@tormail.org wrote: Dimitry Andric d...@freebsd.org writes: On Apr 16, 2013, at 00:42, Jan Beich jbe...@tormail.org wrote: ... Maybe -O3 overoptimizes regex in libc e.g., $ echo '#if @GNULIB_EUIDACCESS@' | sed 's/@GNULIB_EUIDACCESS@/0/' #if @GNULIB_EUIDACCESS@ $ echo 'xxx' | sed 's/xxx//' xxx How did you arrive at this result? 1/ chroot into poudriere jail for /head amd64 2/ echo CFLAGS+=-O3 /etc/make.conf 3/ make -j2 (in /usr/src/lib/libc) 4/ prepend LD_LIBRARY_PATH=. before sed(1) 5/ rebuild regcomp.o, regcomp.So with -O2 to confirm I have been able to reproduce this on amd64, with -O3, but not on i386. It seems regcomp() is either miscompiled at -O3, or it contains some bug triggered only by the vectorizer. I am still investigating. ... With -fno-vectorize, this problem doesn't seem to happen. FYI, Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbvUHAAoJECXpabHZMqHOekEIAIml2te9436LzTFsr794y82E Vmytl95H+vW9Nj0qK5X/DkB/0MSepL5FZqKF5CSNTXFoNJoVFewYRIH/H5oICSpZ jfS4evF9i2mEDOScTyC/XaucvcVWupLE9Kf7FHEk5YIhDMs4r4nzwMFGkzffEqPK yLkV/Cpc8xjvi28OuXd1KaPIcX3S8Z9vEmWPyljtseRv9WlC5gT44fSz18hmqYmv fWSiML4YKKkDRAPOCy/Shpf5QUcygOul7Jz8RiDBx3O4R5goGW8Ee8Napn7UulSL nAXTHy8dcSbiAqqPKeXhmZGPCotj++P9s3jEvunOxL7lvrdjfy3WtGedcp02ia8= =jwYS -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ipfilter(4) needs maintainer
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-04-15 15:27:55 -0400, Cy Schubert wrote: In message a2450361-d9e9-498f-ad44-846563ef0...@yahoo.com, Scott Long writes: On Apr 15, 2013, at 11:48 AM, Cy Schubert cy.schub...@komquats.com wrote: In message 18df99b0-6e66-4906-a233-7778451b8...@felyko.com, Rui Paulo writes: 2013/04/15 9:55$B!(BCy Schubert cy.schub...@komquats.com $B$N%a%C%;!%8 (B: I've been planning on taking on IP Filter for quite some time. Unfortunately I've left my src commit bit lapse (my ports commit bit is alive and well though) thus I'm looking for a mentor. In addition I'm working on an ACER WMI/ACPI kld. One mentor would be preferred but two would be fine too. What are your plans regarding ipfilter? I remain unconvinced that it shoul d b e in the base system. Perhaps you can work on it as a port? The initial plan was to import IP Filter 5.1.2 into HEAD. darrenr@ hadn't done much with IPF while employed with Sun. Since then there has been some development that is long overdue for HEAD. I'm not sure if I'd MFC it into 9 or not. I did consider a port but given it would has to touch bits and pieces of the source tree (/usr/src), a port would be messy and the decision was made to work on importing it into base. Why do you want to work on something that people have been trying to remov e s ince 2005? I and others have been using it in FreeBSD for over decade. For the longest of time we'd use a common set of rules across a FreeBSD and Solaris farm (using ipfmeta, makefiles, rsync, rdist, and a local CVS repo). Interoperability with other systems which use IP Filter is a plus. If there's a maintainer, it only makes FreeBSD richer. Losing IP Filter would be a loss. If you're committed to maintaining IPFilter, that's great. However, it can't be left to stagger along in a zombie state with nothing more than good intentio ns from well meaning people. What is your timeline for getting it back into sha pe and re-integrating yourself into the committer community? I would think this would be my top priority right now. I'd like to see it at the latest level in HEAD. I would like to MFC to 9-STABLE at some point. Given that IPF already lives in src/contrib and src/sys/contrib, would the change in License from Darren Reed's own not so BSD friendly IPF license to GPLv2 be of concern. I recall there was a lot of concern over IPF's license change at the time. (FreeBSD moved it to contrib while OpenBSD removed it completely and wrote PF -- I'm not sure what NetBSD did). FYI, NetBSD has PF from OpenBSD: http://www.netbsd.org/docs/network/pf.html Also, they upgraded it to the latest GPL'ed sources recently (and moved to a different directory): http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/external/bsd/ipf/netinet/?only_with_tag=MAIN Now they have their own packet filter, called NPF: http://mail-index.netbsd.org/netbsd-announce/2012/10/17/msg000161.html They have more choices now. :-) Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRbFjtAAoJECXpabHZMqHOSFkIAK72iLtzb1py01/A+SbX8ejn hi5eh8ri6QQ2Kh4K96b/R5oHk5PoGNpc7xX7Kbp1wyJ2OrdNvAPnElwMDpPCjnRC rKPXiS25Km9D1e18E2pLB4iTweb/AOf87bGRz6skm3Rq0D4XOX9dwRndj1vqRxmH V/Rrdlzprx4EvDmgmfAfSZwGTGit6fVXqHHj5LtONURNKe4qAliVIdxB1vQFQBqB BnHF1gN7tIJVCrn+4yKSVsv6vqRSXp5LOIRBw2ooURKEkkKqVIapboEU+pGitN4g dbVZkoBol7V+LfqBBpsG7JH+OboUvdvWJ7hqeNtAV4YerBBBbePvx9D5iehmRUk= =/mAG -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -CURRENT userland regression
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-02-21 10:31:31 -0500, John Baldwin wrote: On Wednesday, February 20, 2013 5:21:50 pm Navdeep Parhar wrote: On 02/20/13 14:14, Xin Li wrote: Hi, It seems that fresh -HEAD would give an unusable kernel that overwrites screen buffer in a way making it impossible to debug. Using an old world source to do 'make buildworld buildkernel' results in a (mostly: I have some strange USB issue right now and still looking for the cause) usable kernel. For now my known good combination is world 246858 with kernel 247057. I'm still trying to find out which revision have broke the stuff. I ran into this earlier today. Selecting safe mode in the boot loader menu seems to work around the problem on my system. Now I will not reboot until I see a fix for this in head :-) safe mode toggles a few different things IIRC, can you narrow it down to a single setting? kern.smp.disabled=1 Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRJl45AAoJECXpabHZMqHO/I0IALhqfW2uSY+IoCOvtSN7eQGM IRmzRiFtoz7sXb5OiNlHjwZdRcQR4t6656EUyItDjr3XbXvnGaNL/nk+B9moSgSi NmHpEWQ4yNTJKYUAnvw4NGHKkiOpmNsrAA5i8EEQQesQGuwke0eYaeHMb5R5Wvsu lyWTB0ZH1XV8VehvTir3vo7MWaGjYYp8l09YpaDUYTpn364Fx+jBgsG5qKWdrHMn l/TwMLmWB6Mij2K8+FeS9PIijFKhaTh2s5xa1/xX3vFuR0mhMfNm7OfadXy1KKsL YcTm4Q0QYDkfoxwoS6+AWKVk1LMrF8vah8kHalKp5JCtNv3p1jr5RupalYI9zgo= =1D9R -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-26 11:58:16 -0500, Pawel Jakub Dawidek wrote: On Fri, Jan 25, 2013 at 04:19:44PM -0500, Jung-uk Kim wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote: On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek wrote: One is when I leave laptop idle for some time (few hours?): http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg Small update. This panic doesn't happen when the system is idle, it happens we I close the lid to the point when display is turned off (which is almost closed, but not entirely closed). Closing lid doesn't trigger suspend or anything like that. It just turns off the display. Please try the attached patch (with my previous patch). Also, available from here: http://people.freebsd.org/~jkim/acpi_exit.diff Your patch fixes panic triggered by unplugging power cable as well the one triggered by closing the lid. I haven't tried booting from battery and connecting power cable, but I expect happy end there as well. Committed, thanks! Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRButnAAoJECXpabHZMqHO+C4IAJVcT97/ZBylUajuBpY/s+rb uiBLHALbXpKiHqRDiaTmkGdROdfMKc8IhnOB97N7YlLMzYhEFKXCL4JCMxGtxT8K sQ3FzKsbdNaEVZl0k1Ql7ogLSMaCLS9Gjbd4/4Rm7oQUf+k90x9aSavsDBPfszgD uPrhBNgAvWVP9rHjMgW7mYsM73j33cbNYE5XBBV6R6RqDF4CjbhpwD4gIIQDsx3y 0ff3lc1RFed9syjlg6suL3jL+2Cnv+JkSVon5KA77n+g1zLkI6TifnWFYJnNt48r P7mhrmknazkoEdIEpDDFJEJTt4QE0qm0VRjCfzUPhsNdR1dJy85Hrijem9HmEWg= =vdbF -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-25 04:26:02 -0500, Pawel Jakub Dawidek wrote:
On Thu, Jan 24, 2013 at 05:18:48PM +0100, Pawel Jakub Dawidek
wrote:
One is when I leave laptop idle for some time (few hours?):
http://people.freebsd.org/~pjd/misc/acpi_idle_panic_0.jpg
http://people.freebsd.org/~pjd/misc/acpi_idle_panic_1.jpg
Small update. This panic doesn't happen when the system is idle,
it happens we I close the lid to the point when display is turned
off (which is almost closed, but not entirely closed).
Closing lid doesn't trigger suspend or anything like that. It just
turns off the display.
Please try the attached patch (with my previous patch). Also,
available from here:
http://people.freebsd.org/~jkim/acpi_exit.diff
Thanks,
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJRAvbwAAoJECXpabHZMqHOhkwIALmKk6ylgFwrvgTCWUZKrJXM
X41gMBhbNnMoa+g/lBwxIsTxb17zXRAN2T8K6xOQZoB66vjW+ykq38SU0qQTaTLt
ldihTV7xZawmMz/t5meshDZCbXUTtwOd6ChdFrjgc8+FUq+siL3mRi5UpoIk8o0k
wblQ2werCGESIReW57cfGTnF+Sbfz1fBbobos+04gvs9d72FEfrsGRwSZv/wsBYP
RKv2zGGWFzXSgPwYHbA+Nz1Tt36zl1npLV7mx/nijA6CNtYvL/RX4QDUTxFw2G5h
Bjr3kVXTqz2ITM/K6Oajel6HE1utYDEMgBUL3kaEKdmxK2cguZmcP3p04f1XzRw=
=AUMk
-END PGP SIGNATURE-
Index: sys/contrib/dev/acpica/include/acoutput.h
===
--- sys/contrib/dev/acpica/include/acoutput.h (revision 245916)
+++ sys/contrib/dev/acpica/include/acoutput.h (working copy)
@@ -329,9 +329,9 @@
/* Helper macro */
-#define ACPI_TRACE_ENTRY(Name, Function, Cast, Param) \
+#define ACPI_TRACE_ENTRY(Name, Function, Type, Param) \
ACPI_FUNCTION_NAME (Name) \
-Function (ACPI_DEBUG_PARAMETERS, Cast (Param))
+Function (ACPI_DEBUG_PARAMETERS, (Type) (Param))
/* The actual entry trace macros */
@@ -340,13 +340,13 @@
AcpiUtTrace (ACPI_DEBUG_PARAMETERS)
#define ACPI_FUNCTION_TRACE_PTR(Name, Pointer) \
-ACPI_TRACE_ENTRY (Name, AcpiUtTracePtr, (void *), Pointer)
+ACPI_TRACE_ENTRY (Name, AcpiUtTracePtr, void *, Pointer)
#define ACPI_FUNCTION_TRACE_U32(Name, Value) \
-ACPI_TRACE_ENTRY (Name, AcpiUtTraceU32, (UINT32), Value)
+ACPI_TRACE_ENTRY (Name, AcpiUtTraceU32, UINT32, Value)
#define ACPI_FUNCTION_TRACE_STR(Name, String) \
-ACPI_TRACE_ENTRY (Name, AcpiUtTraceStr, (char *), String)
+ACPI_TRACE_ENTRY (Name, AcpiUtTraceStr, char *, String)
#define ACPI_FUNCTION_ENTRY() \
AcpiUtTrackStackPtr()
@@ -361,16 +361,37 @@
*
* One of the FUNCTION_TRACE macros above must be used in conjunction
* with these macros so that _AcpiFunctionName is defined.
+ *
+ * There are two versions of most of the return macros. The default version is
+ * safer, since it avoids side-effects by guaranteeing that the argument will
+ * not be evaluated twice.
+ *
+ * A less-safe version of the macros is provided for optional use if the
+ * compiler uses excessive CPU stack (for example, this may happen in the
+ * debug case if code optimzation is disabled.)
*/
/* Exit trace helper macro */
-#define ACPI_TRACE_EXIT(Function, Cast, Param) \
+#ifndef ACPI_SIMPLE_RETURN_MACROS
+
+#define ACPI_TRACE_EXIT(Function, Type, Param) \
ACPI_DO_WHILE0 ({ \
-Function (ACPI_DEBUG_PARAMETERS, Cast (Param)); \
-return ((Param)); \
+register Type _Param = (Type) (Param); \
+Function (ACPI_DEBUG_PARAMETERS, _Param); \
+return (_Param); \
})
+#else /* Use original less-safe macros */
+
+#define ACPI_TRACE_EXIT(Function, Type, Param) \
+ACPI_DO_WHILE0 ({ \
+Function (ACPI_DEBUG_PARAMETERS, (Type) (Param)); \
+return (Param); \
+})
+
+#endif /* ACPI_SIMPLE_RETURN_MACROS */
+
/* The actual exit macros */
#define return_VOID \
@@ -380,13 +401,13 @@
})
#define return_ACPI_STATUS(Status) \
-ACPI_TRACE_EXIT (AcpiUtStatusExit, (ACPI_STATUS), Status)
+ACPI_TRACE_EXIT (AcpiUtStatusExit, ACPI_STATUS, Status)
#define return_PTR(Pointer) \
-ACPI_TRACE_EXIT (AcpiUtPtrExit, (UINT8 *), Pointer)
+ACPI_TRACE_EXIT (AcpiUtPtrExit, void *, Pointer)
#define return_VALUE(Value) \
-ACPI_TRACE_EXIT (AcpiUtValueExit, (UINT64), Value)
+ACPI_TRACE_EXIT (AcpiUtValueExit, UINT64, Value)
/* Conditional execution */
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-24 04:41:08 -0500, Andriy Gapon wrote: on 24/01/2013 02:54 Jung-uk Kim said the following: Can you please try the attached patch? It is also available from here: http://people.freebsd.org/~jkim/utcache.diff Jung-uk, I think that I have a much better patch for all potential ACPI object cache problems :-) http://people.freebsd.org/~avg/acpi-uma-cache.diff What do you think? We have to fix this bug because local cache is always used for userland applications, e.g., iasl. BTW, I tried something like that long ago. In fact, the first attempt goes all the way back to this patch (warning: it's naive, broken, and overly complicated): http://people.freebsd.org/~jkim/acpica/OsdCache.diff I have more up-to-date and correct patch to use UMA but I'm still not 100% convinced whether we want to do it or not. When utcache.c works, it works fairly well, actually. :-) Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJRAX15AAoJECXpabHZMqHOyoAH/i1eccONiETE+LiHlApmL+zy Y1h1D+R/S8hJ55fQ7i/2CkqAhNdHFI+TCrt2YIPNXS79VP9xyNRa+gPGHNqYUTF4 nv34ZpSi5MMERg7r+mOitNjPZfy+aiyDHI/PQFZ4lQR+by3c1HogKAwNPhLn0rxF NiA+X11lkcbBCxb4HzH8kSI5wFW/e5tEAHgGTrxJLzS1IGTbRBYLV6lA+ITBR0wu EzGw3FEU2pO2jDL3WxsM0vg/4VMCZvsnezxvRQ1XPbdJe4UU0ri3VgqzFX6N5ThI AeDuehji9lZiZc6Hjn35jSxq5KpzMiOj6bjLTEeO5zIdjmeGUWiMex+aoRrFOGU= =/bG6 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: ACPI panic on unplugging the power cord.
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2013-01-22 12:56:29 -0500, Pawel Jakub Dawidek wrote:
I just upgraded to HEAD today and was wondering what will explode.
Now I know.
When I unplug power cord from my laptop, ACPI panics. Pictures
here:
http://people.freebsd.org/~pjd/misc/acpi_panic_0.jpg
http://people.freebsd.org/~pjd/misc/acpi_panic_1.jpg
Let me know if you need more info.
Can you please try the attached patch? It is also available from here:
http://people.freebsd.org/~jkim/utcache.diff
Please note the patch may or may not fix the problem but I think I
found an ancient bug. :-(
Thanks,
Jung-uk Kim
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.19 (FreeBSD)
iQEcBAEBAgAGBQJRAIZhAAoJECXpabHZMqHOWl8H/3pUGshUkzCNbEOQHoZOYXMW
TtLaUqdV3/zYGEYDYl5Tbxv2JUz4tWDU5KlWhnZk+MjNnR1+g0fgzQu3mK056NU+
rpZucEnoaEeKriLpd+Hsw3Y28eXiY8/9T8/SnFMUW7AS6HZk8G7itdu9cx9A+IY6
A2tQBIpDXes4a5BLNZzyP/2dSMrcKVeS28+fZlxGdWWakFs5/FWYguK5kR2PIkCS
3yh8vEv7XH8WJz+sK/v/jcpcxt+heCG+j8XIwJieqk1CDXaCtH6g+4mlKQogsZY1
1YSYaGE+/szNvnR9UjW1+x/mhA5atFa9ysCq96zvVOs/Ih7X9Id4fZ6laetSDIs=
=rUXs
-END PGP SIGNATURE-
Index: sys/contrib/dev/acpica/components/utilities/utcache.c
===
--- sys/contrib/dev/acpica/components/utilities/utcache.c (revision 245848)
+++ sys/contrib/dev/acpica/components/utilities/utcache.c (working copy)
@@ -95,7 +95,6 @@ AcpiOsCreateCache (
/* Populate the cache object and return it */
ACPI_MEMSET (Cache, 0, sizeof (ACPI_MEMORY_LIST));
-Cache-LinkOffset = 8;
Cache-ListName = CacheName;
Cache-ObjectSize = ObjectSize;
Cache-MaxDepth = MaxDepth;
@@ -121,7 +120,7 @@ ACPI_STATUS
AcpiOsPurgeCache (
ACPI_MEMORY_LIST*Cache)
{
-char*Next;
+void*Next;
ACPI_STATUS Status;
@@ -145,8 +144,7 @@ AcpiOsPurgeCache (
{
/* Delete and unlink one cached state object */
-Next = *(ACPI_CAST_INDIRECT_PTR (char,
-(((char *) Cache-ListHead)[Cache-LinkOffset])));
+Next = ((ACPI_OBJECT_COMMON *) Cache-ListHead)-NextObject;
ACPI_FREE (Cache-ListHead);
Cache-ListHead = Next;
@@ -251,8 +249,7 @@ AcpiOsReleaseObject (
/* Put the object at the head of the cache list */
-* (ACPI_CAST_INDIRECT_PTR (char,
-(((char *) Object)[Cache-LinkOffset]))) = Cache-ListHead;
+((ACPI_OBJECT_COMMON *) Object)-NextObject = Cache-ListHead;
Cache-ListHead = Object;
Cache-CurrentDepth++;
@@ -307,8 +304,7 @@ AcpiOsAcquireObject (
/* There is an object available, use it */
Object = Cache-ListHead;
-Cache-ListHead = *(ACPI_CAST_INDIRECT_PTR (char,
-(((char *) Object)[Cache-LinkOffset])));
+Cache-ListHead = ((ACPI_OBJECT_COMMON *) Object)-NextObject;
Cache-CurrentDepth--;
Index: sys/contrib/dev/acpica/include/actypes.h
===
--- sys/contrib/dev/acpica/include/actypes.h (revision 245848)
+++ sys/contrib/dev/acpica/include/actypes.h (working copy)
@@ -1226,7 +1226,6 @@ typedef struct acpi_memory_list
UINT16 ObjectSize;
UINT16 MaxDepth;
UINT16 CurrentDepth;
-UINT16 LinkOffset;
#ifdef ACPI_DBG_TRACK_ALLOCATIONS
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [head tinderbox] failure on ia64/ia64
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-21 15:22:58 -0500, FreeBSD Tinderbox wrote: TB --- 2013-01-21 18:24:06 - tinderbox 2.10 running on freebsd-current.sentex.ca TB --- 2013-01-21 18:24:06 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2013-01-21 18:24:06 - starting HEAD tinderbox run for ia64/ia64 TB --- 2013-01-21 18:24:06 - cleaning the object tree TB --- 2013-01-21 18:26:05 - /usr/local/bin/svn stat /src TB --- 2013-01-21 18:26:09 - At svn revision 245742 TB --- 2013-01-21 18:26:10 - building world TB --- 2013-01-21 18:26:10 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 18:26:10 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 18:26:10 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 18:26:10 - SRCCONF=/dev/null TB --- 2013-01-21 18:26:10 - TARGET=ia64 TB --- 2013-01-21 18:26:10 - TARGET_ARCH=ia64 TB --- 2013-01-21 18:26:10 - TZ=UTC TB --- 2013-01-21 18:26:10 - __MAKE_CONF=/dev/null TB --- 2013-01-21 18:26:10 - cd /src TB --- 2013-01-21 18:26:10 - /usr/bin/make -B buildworld Building an up-to-date make(1) World build started on Mon Jan 21 18:26:15 UTC 2013 Rebuilding the temporary build tree stage 1.1: legacy release compatibility shims stage 1.2: bootstrap tools stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3: cross tools stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Mon Jan 21 20:02:02 UTC 2013 TB --- 2013-01-21 20:02:02 - generating LINT kernel config TB --- 2013-01-21 20:02:02 - cd /src/sys/ia64/conf TB --- 2013-01-21 20:02:02 - /usr/bin/make -B LINT TB --- 2013-01-21 20:02:02 - cd /src/sys/ia64/conf TB --- 2013-01-21 20:02:02 - /usr/sbin/config -m LINT TB --- 2013-01-21 20:02:02 - building LINT kernel TB --- 2013-01-21 20:02:02 - CROSS_BUILD_TESTING=YES TB --- 2013-01-21 20:02:02 - MAKEOBJDIRPREFIX=/obj TB --- 2013-01-21 20:02:02 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2013-01-21 20:02:02 - SRCCONF=/dev/null TB --- 2013-01-21 20:02:02 - TARGET=ia64 TB --- 2013-01-21 20:02:02 - TARGET_ARCH=ia64 TB --- 2013-01-21 20:02:02 - TZ=UTC TB --- 2013-01-21 20:02:02 - __MAKE_CONF=/dev/null TB --- 2013-01-21 20:02:02 - cd /src TB --- 2013-01-21 20:02:02 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Mon Jan 21 20:02:02 UTC 2013 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] acpi_powerres.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_resource.o:(.sbss+0x0): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_thermal.o:(.sbss+0x20): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here acpi_timer.o:(.sbss+0x28): multiple definition of `AcpiGbl_IgnoreNoopOperator' dbcmds.o:(.sbss+0x0): first defined here *** [kernel] Error code 1 Stop in /obj/ia64.ia64/src/sys/LINT. *** [buildkernel] Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2013-01-21 20:22:58 - WARNING: /usr/bin/make returned exit code 1 TB --- 2013-01-21 20:22:58 - ERROR: failed to build LINT kernel TB --- 2013-01-21 20:22:58 - 5462.62 user 1225.88 system 7131.85 real http://tinderbox.freebsd.org/tinderbox-head-ss-build-HEAD-ia64-ia64.full It should be fixed now (r245748, make universe tested). Sorry for the breakage, again. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ/bMgAAoJECXpabHZMqHOtbcH/jNd3nq5/nKaWXP4kdbmi1bj sVPeNi1+C3nYTAxfzIn1UzIlObiyg3u3b2xKuTp2/YNN/k3s9jhloWwzoTCS0YcR qVWGfJ+3zRsMQQ1gMMnzkoZdqnkoznMQNZvCt0Uti0lwk1mASLU7VKxGHsmnyqO8 hnZaa8XgwnZDiQW5ac6utpFpGvQyCQEBJIbsZ/yg2FXz8bHi9QOXRGJs22KiASZB RjQFmv7U4TpeRzQT11UsjopfIZ3RssI7g8pA5+iIbzjZ9nsGaf21itvJSiRfFqlg sFYRy00rm1rMdlgPc+ToTNTtzTc0M/2QULhhEkZjP0S8O/U+w69+qSdpkqcsrdA= =GyLm -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken in acpi/iasl
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2013-01-18 13:39:01 -0500, John-Mark Gurney wrote: Sergey V. Dyatko wrote this message on Fri, Jan 18, 2013 at 21:34 +0300: On Fri, 18 Jan 2013 22:17:27 +0400 Andrey Chernov a...@freebsd.org wrote: === usr.sbin/acpi/iasl (all) cc -O2 -pipe -march=core2 -DACPI_ASL_COMPILER -I. -I/usr/src/usr.sbin/acpi/iasl/../../../sys -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -c /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c cc1: warnings being treated as errors /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c: In function 'AcpiDmIsResourceTemplate': /usr/src/usr.sbin/acpi/iasl/../../../sys/contrib/dev/acpica/components/disassembler/dmresrc.c:419: warning: dereferencing type-punned pointer will break strict-aliasing rules *** [dmresrc.o] Error code 1 Stop in /usr/src/usr.sbin/acpi/iasl. *** [all] Error code 1 according to rumors buildworld done successfully with the clang. But I didn't test it. Look at buildworld is broken ? thread Looks like this broken when jkim imported the latest ACPICA code base: https://svnweb.freebsd.org/base?view=revisionrevision=245582 I've forward the tinderbox failure to him, so hopefully he'll fix it shortly... It should be fixed now (r245636). Sorry for the breakage. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) iQEcBAEBAgAGBQJQ+esDAAoJECXpabHZMqHOypgIAILl0S2cvEdTQWXJ4PWase07 yKA+DPHYAUx09JHbnLfEeA+KLFUz2jnX7dYR9ohSMcsnkI1/AH/z8dkFc3NLPUQw TXh1edQyXaYr0WK+3sW81Tl5thka5VwjznoJj1r/Og8Nrx/xYUYCEtpPsjDU1hW0 8T897m6MqOSZokWs4dyOt1ZWoncGRTHgC5tCzjcmAuiOTIkZ7hdLNXKu1nm+cgcy LNEvJf/d1bz6UzQ9xxCxG+HttZhi4YL8uAAYMHZtydM+Zp5yZskajyNmDkThSMhu LrUohDfMLk84DkyoAfzojr90o8tk6TujfHR+osF3oj9NkDi6o6VK0AVs1yKPg5c= =poDO -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: detecting clang from source code?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-11-06 17:37:41 -0500, Larry Rosenman wrote: Are there any defines that code can use in #ifdef/#if et al to tell it's being compiled with clang? Vic Abell (lsof author) is cleaning up lsof to compile cleanly with clang and would like to know, since the default is now clang on -CURRENT. #ifdef __clang__ /* clang-specific stuff */ #else /* Something else */ #endif Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://www.enigmail.net/ iEYEARECAAYFAlCZks8ACgkQmlay1b9qnVPIagCfXtDRXzUkPI5PowyCjFFxp6HU bHQAn3yAddLwonekcrkl8O9/0BSRVHR2 =CUn6 -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] OpenSSL 1.0.1c merge in progress
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2012-07-13 05:55:04 -0400, Doug Barton wrote: On 07/12/2012 05:03 PM, Jung-uk Kim wrote: FYI, OpenSSL 1.0.1c import is complete now. Please let me know if you have any problem. Sorry if I missed it, but did you bump OSVERSION for this change? If not, could you? It would be helpful for dealing with ports stuff, especially USE_OPENSSL. Yes, it was bumped with the commit. Jung-uk Kim -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.19 (FreeBSD) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlAAREwACgkQmlay1b9qnVNpkgCffS1dK8lvKRBXpxeebRGcx/kE UYIAoMxzzJUcx2JvTY996Vm4eHHriXVt =NvEB -END PGP SIGNATURE- ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
