Re: What is evdev and autoloading?
motivated me to do this: 1) my observation that many developers at conferences and online were using macOS as their primary desktop environment. when comparing this to the OpenBSD and Linux community I felt pretty embarrassed, but it did explain the stagnant nature of our graphics subsystem. people seemed afraid to touch things due the brittle nature of its hardware support. 2) i was in need to an *affordable* machine with a warranty. fortunately there are many affordable laptops at staples, best-buy and amazon - but they were all post haswell systems, rendering them basically useless from a FreeBSD perspective. I've bought recently (like half year ago) cheapest laptop available. Everything supported with FreeBSD out of the box, except little problem with sound but dev.hdac.0.polling=1 made it work. What a problem? Even lowest end today computer is really high end for normal programs. ___ 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: Runtime loader issue
just another - out of thousands - example that shared libraries are one of the worst thing invented in computing. Maybe except of single system wide shared library with constant interface. On Thu, 10 May 2018, Gleb Popov wrote: On Thu, May 10, 2018 at 2:45 AM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: In review PR 228007, it came to my attention some individuals are mis-characterizing a FreeBSD loader issue as "gfortran's FreeBSD issue". See https://lists.freebsd.org/pipermail/freebsd-fortran/2018-May/000124.html The problem can be summarized by the following % gfortran7 -o z h.f90 % ./z /lib/libgcc_s.so.1: version GCC_4.8.0 required by \ /usr/local/lib/gcc7/libgfortran.so.4 not found gfortran7 is installed from ports/lang/gcc7. This is not a "gfortran's FreeBSD issue". This is a FreeBSD loader issue. Specifically, there is a shared library name clash. % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 % ldd z z: libgfortran.so.4 => /usr/local/lib/gcc7/libgfortran.so.4 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x200a17000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x200a4b000) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200a63000) libc.so.7 => /lib/libc.so.7 (0x200ca3000) So, the runtime loader finds 6 instead of 716, tries to link, fails, and issues an error message. There are a number ways to fix this issue. 1) By far, the best solution would be to stop hijacking the libgcc name in libraries installed on FreeBSD that are not related to actual GCC software. % ls -l /lib/libgcc* /usr/lib/libgcc* (trimming lines) /lib/libgcc_s.so.1 /usr/lib/libgcc.a@ -> libcompiler_rt.a /usr/lib/libgcc_eh.a /usr/lib/libgcc_eh_p.a /usr/lib/libgcc_p.a@ -> libcompiler_rt_p.a /usr/lib/libgcc_s.so@ -> ../../lib/libgcc_s.so.1 Why not use libcompiler_rt_s.so.1 (or libclang_s.so.1)? Yes, I'm aware that clang does not work on all archs and the ancient gcc lives on. 2) Given the expected push back againt solution 1), this solution proposes bumping the library version for /lib/libgcc_s.so.1 from 1 to some larger value, say, 10. It is unlikely that GCC will bump its shared library number anytime soon. GCC bumped it from 0 to 1 some 16 years ago. https://gcc.gnu.org/viewcvs/gcc?view=revision=43316 This solution, however, papers over the general problem with name clashes. 3) This solution is to actually fix the runtime loader. If an error occurs with loading a shared library, then iterate over the entries in the hints file to check to see if another hint would satisfy the linking. Here, instead of issuing the above error, the loader would find entry 716, and load the correct libgcc_s.so.1. Admittedly, I haven't looked to see how difficult this solution would be. 4) Bump the shared library number of the individual ports. As a proof of concept, I've done this with ports/lang/gcc6. % cat /usr/ports/lang/gcc6/files/patch-t-slibgcc --- libgcc/config/t-slibgcc.orig2018-05-08 12:47:42.334495000 -0700 +++ libgcc/config/t-slibgcc 2018-05-08 12:45:26.872312000 -0700 @@ -20,7 +20,7 @@ SHLIB_EXT = .so SHLIB_SOLINK = @shlib_base_name@.so -SHLIB_SOVERSION = 1 +SHLIB_SOVERSION = 2 SHLIB_SONAME = @shlib_base_name@.so.$(SHLIB_SOVERSION) SHLIB_MAP = @shlib_map_file@ SHLIB_OBJS = @shlib_objs@ % ldconfig -r | grep gcc_ 6:-lgcc_s.1 => /lib/libgcc_s.so.1 716:-lgcc_s.1 => /usr/local/lib/gcc7/libgcc_s.so.1 766:-lgcc_s.2 => /usr/local/lib/gcc6/libgcc_s.so.2 % gfortran6 -o z h.f90 % ./z hello % ldd z z: libgfortran.so.3 => /usr/local/lib/gcc6/libgfortran.so.3 (0x200645000) libm.so.5 => /lib/libm.so.5 (0x20096c000) libgcc_s.so.2 => /usr/local/lib/gcc6/libgcc_s.so.2 (0x2009a) libquadmath.so.0 => /usr/local/lib/gcc7/libquadmath.so.0 (0x200bb7000) libc.so.7 => /lib/libc.so.7 (0x200df7000) This works for this particular name conflict. Hopefully, FreeBSD never needs to bump /lib/libgcc_s.so.1 to /lib/libgcc_s.so.2. This, however, introduces an incompatibility with what is actually distributed by GCC. Finally, can people stop referring to the above error as "gfortran's FreeBSD issue". This is a FreeBSD runtime loader issue. Our libgcc also lacks some functionality compared to the original one: https://reviews.freebsd.org/D11482 -- Steve ___ freebsd-hack...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org" ___ freebsd-po...@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to "freebsd-ports-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list
Re: Kern.hz= +1 hertz at anything 2500 and above.
improved with a higher kern.hz rating. Unless the future holds an emu20k2, there will be RAM used from the motherboard. 1. I will need a real-time or a faster kernel- hence the high rate wanted- because the devices to be built will be used in an active environment: art, music, audio control. 2. Any system with limited memory and a low CPU hertz rate benefits from the higher kern.hz setting. rather opposite. more kern.hz=more interrupts. 3. Why not? If it works for PowerPC, SPARC64, AMD64, and i386 then it may work for other architectures. 4. Some applications may be ran from within a jail. On Wed, Jul 24, 2013 at 8:16 PM, Adrian Chadd adr...@freebsd.org wrote: Well, why is it reducing latency? That's the thing you should investigate. Is it because processes aren't getting enough time? or too much time? Or the audio device isn't getting enough time to run? etc. -adrian On 24 July 2013 15:35, Super Bisquit superbisq...@gmail.com wrote: http://lists.freebsd.org/pipermail/freebsd-stable/2009-September/051789.html This is the thread that I was referring to earlier. Since the patch is for 2009, what are the chances it would work with 10.x or 9.x? On PowerPC machines with a low MHz rate- or any machine with a CPU rate of 800 MHz or less- increasing the kern.hz improves performance and cuts down on latency. I am building audio applications and suites that are used in different projects. A G3 based machine should be able to run a kernel with kern.hz=5000 with no problem. Unfortunately, this cannot be done. @PowerPC: some of you may find that performance does increase at a higher kern.hz rate. @Hackers Current: What's the chance that the default rate limit can be raised to 5k? ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ppc To unsubscribe, send any mail to freebsd-ppc-unsubscr...@freebsd.org ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ 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: On cooperative work [Was: Re: newbus' ivar's limitation..]
Yep. In 18+ years of being subscribed to various freebsd lists, Arnaud has the honor of being only the 2nd person to earn a killfile entry. He's now sitting next to Jesus Monroy, Jr. it is not a proud from you to talk about who you are blocking. ___ 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: [CFC/CFT] large changes in the loader(8) code
Just modify GEOM classes that keep state at the end of a partition to leave some spare area *behind* the GEOM data. I.e.: what is really a problem aat all? just leave as is. If someone want's use gpart and mirror then mirroring every partition is simpler. usually not every partition needs to be mirrored. or mirror a whole and make gpart in it, it should still boot fine. even better - update bsdlabel to work with 2TB devices. MUCH better. ___ 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: sysctl filesystem ?
as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. /proc/sysctl might be useful. Just because Linux uses it doesn't make it a bad idea. actually - i don't know since over 5 years what linux do. ___ 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: sysctl filesystem ?
as well as we don't depend of /proc for normal operation we shouldn't for say /proc/sysctl improvements are welcome, better documentation is welcome, changes to what is OK - isn't. ___ 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: sysctl filesystem ?
and/or get it wrong. sysctl has some file-system like properties, but on the whole, it's not a file system -- it's much more like an SNMP MIB. While you can map anything into anything (including Turing machines), I think the sysctl command line tool and API, despite its limitations, is a better me too. i REALLY appreciate the way FreeBSD do this. pseudo-filesystems are sometimes good but making them default method is bad. Current way is simple. Or actually - less complicated as i think for example - XML in system output is not. ___ 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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
and hardware in the lab on last week. I reformatted the USB drive with extFAT and standard block size on Windows 7. The USB drive is now seen again on FreeBSD and recognized as this points that the pendrive's controller is not just flaky but horrid. The communiation with OS, and how/whether it is configured properly should not depend on what data is written to it - in your case exFAT metadata. It seems that controller manufacturer just did something to run on windows and linux instead of something that conform to USB mass storage interface standard :( Sorry but it may be hopeless case. ___ 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: USB system: FreeBSD 9-STABLE and 10-CURRENT do not recognize 64GB USB drive while Linux and Windows do
incapable of handling the 64GB drive. I do not have issues with USB it's not about capacity. But seems some quirks for that pendrive (which have buggy firmware) has to be added, as it doesn't respond for inquiry command. sorry i am not USB expert. umass1: Lexar USB Flash Drive, class 0/0, rev 2.00/11.00, addr 6 on usbus7 (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Retrying command (probe0:umass-sim1:1:0:0): INQUIRY. CDB: 12 0 0 0 24 0 (probe0:umass-sim1:1:0:0): CAM status: CCB request completed with an error (probe0:umass-sim1:1:0:0): Error 5, Retries exhausted ___ 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
