Re: [Request for review] Profiling the FreeBSD kernel boot
On Fri, Dec 22, 2017 at 5:44 PM, Colin Percival wrote: > Hi everyone, > > For the past few months I've been working on code for profiling the FreeBSD > "kernel boot", i.e., everything between when kernel code starts running and > when we first enter userland as init(8). This is not trivial since it's > impossible to use tools like dtrace to monitor things prior to when said > tools are running. The goal of this exercise is to help me track down the > places where we're wasting time during the boot, and then to fix them. > > The approach I've taken is to add some macros -- most notably TSENTER() and > TSEXIT() -- which by default compile to nothing, but if the TSLOG kernel > option is enabled they compile to code which logs the cycle count (e.g., on > x86 the value from the RDTSC instruction) along with some other data (in > the > case of TSENTER and TSEXIT, the fact that we're entering/exiting a > function). > This can then be dumped via a sysctl (debug.tslog) and processed in > userland > to convert function entries/exits into stacks and to visualize the time > spent > in the boot process. > > Two examples: > > A flame chart of my laptop booting HEAD: > http://www.daemonology.net/timestamping/tslog-laptop.svg > > A flame chart of an EC2 c5.4xlarge instance booting 11.1-RELEASE: > http://www.daemonology.net/timestamping/tslog-c5.4xlarge.svg > > The patches (10 of them, to be applied in order), userland scripts, and > very > brief usage instructions are at: > http://www.daemonology.net/timestamping/tslog.tgz > > I hope to commit the patches in the next week, since I'm planning on > writing > a paper to submit to AsiaBSDCon (which has a deadline of December 31st); so > if anyone has interest/time to look at this in the near future (I mean, > it's > not like anyone is going to be busy this weekend, right?) I'd love to have > some feedback before it goes into the tree. > > -- > Colin Percival > Security Officer Emeritus, FreeBSD | The power to serve > Founder, Tarsnap | www.tarsnap.com | Online backups for the truly paranoid > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I've gotta say nice work with the tracing. Hopefully your talk gets accepted, i'd love to hear it. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Programmatically cache line
Is there some way to programmatically get the CPU cache line sizes on FreeBSD? ___ 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: Programmatically cache line
On Tue, Jan 2, 2018 at 12:26 AM, Ian Lepore wrote: > On Mon, 2018-01-01 at 12:36 +0200, Konstantin Belousov wrote: > > On Mon, Jan 01, 2018 at 06:52:37AM +, David Chisnall wrote: > > > > > > On 1 Jan 2018, at 05:09, Adrian Chadd wrote: > > > > > > > > > > > > On 30 December 2017 at 00:28, Konstantin Belousov wrote: > > > > > > > > > > On Sat, Dec 30, 2017 at 07:50:19AM +, blubee blubeeme wrote: > > > > > > > > > > > > Is there some way to programmatically get the CPU cache line > sizes on > > > > > > FreeBSD? > > > > > There are, all of them are MD. > > > > > > > > > > On x86, the CPUID instruction leaf 0x1 returns the information in > > > > > %ebx register. > > > > Hm, weird. Why don't we extend sysctl to include this info? > > For the same reason we do not provide a sysctl to add two integers. > > > > > > > > > > > It would be nice to expose this kind of information via VDSO or > similar. There are a lot of similar bits of info that people want to use > for ifunc and, SVE is going to have a bunch of similar requirements. > > > > > Is VDSO a new trendy word ? > > > > ifunc resolvers in usermode on FreeBSD/x86 get four arguments which > > are essentially cpu_features / cpu_features2 / cpu_stdext_features / > > cpu_stdext_features2. I suspect that only FreeBSD/x86 arches have the > > ifunc support, in rtld and coming shortly in kernel. > > > > Recently HW_CAP/HW_CAP2 were added to the ELF auxv, and elf_aux_info(3) > > interface exported from libc. > > > > ARM* did not implemented yet the ifunc stubs in rtld. I believe this is > > considered a low priority because there is no ready to use toolchain > > which allow to utilize ifuncs on FreeBSD, except if you use recent bfd > > ld externally. > > Linux exports this info using getauxval(). I think we should support > getauxval() and as many of the AT_* values that linux defines as makes > sense for us to do. > > I think it was a mistake to give our version of the function a > different name and different semantics, but this is something that > affects mainly ports, and I don't yet have enough info to make the case > that being linux-compatible will ease porting rather than complicate it > (in some cases, patches will be needed either way). > > -- Ian > FreeBSD implements hardware specific atomic instructions [man atomic] or look at: #include but implementing something that returns size of cache lines is somehow out of the question? If you're working with atomic data structures and want to ensure there's no false sharing the simplest method I know is to put some padding that's sizeof(cache_line) - sizeof(data_members) so that you can try to get them to live on different cache line. Do we have to go in and write inline assembly to grab the size of the cache line or wouldn't it be simpler to have atomic.h return this info? ___ 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"
USB stack
Does FreeBSD current USB stack support usb >= 2.0 devices? Testing out the USB devices support I get about 7.2-7.8 megabytes per second which seems odd. ___ 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: USB stack
On Wed, Jan 3, 2018 at 6:41 PM, O'Connor, Daniel wrote: > > > > On 3 Jan 2018, at 11:31, blubee blubeeme wrote: > > Does FreeBSD current USB stack support usb >= 2.0 devices? > > Absolutely. > > > Testing out the USB devices support I get about 7.2-7.8 megabytes per > > second which seems odd. > > What sort of test? What sort of device? What sort of port? > > What is the output of dmesg and usbconfig? > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > I transferred about 30GB of audio from laptop to Samsung usb class 10 usb device connected to LG v30. current usbconfig shows this: ugen0.1: <0x8086 XHCI root HUB> at usbus0, cfg=0 md=HOST spd=SUPER (5.0Gbps) pwr=SAVE (0mA) ugen0.3: at usbus0, cfg=0 md=HOST spd=HIGH (480Mbps) pwr=ON (500mA) ugen0.2: at usbus0, cfg=0 md=HOST spd=FULL (12Mbps) pwr=ON (100mA) ___ 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: Intel CPU design flaw - FreeBSD affected?
On Thu, Jan 4, 2018 at 8:51 AM, Mark Heily wrote: > On Jan 2, 2018 19:05, "Warner Losh" wrote: > > The register article says the specifics are under embargo still. That would > make it hard for anybody working with Intel to comment publicly on the flaw > and any mitigations that may be underway. It would be unwise to assume that > all the details are out until the embargo lifts. > > > Details of the flaws are now published at: > > https://meltdownattack.com > > > Warner > > On Jan 2, 2018 4:13 PM, "Michael Butler" > wrote: > > > Has any impact assessment been made as to FreeBSD's exposure or > > mitigation strategies? > > > > 'Kernel memory leaking' Intel processor design flaw forces Linux, > > Windows redesign - The Register > > > > Other OSes will need an update, performance hits loom A fundamental > > design flaw in Intel's processor chips has forced a significant redesign > > of the Linux and Windows kernels to defang the chip-level security bug.… > > Programmers are scrambling to overhaul the open-source Linux kernel's > > virtual memory system. Meanwhile, Microsoft is expected to publicly > > introduce necessary changes to its Windows operating system in this > > month's Patch Tuesday ... > > > > https://www.theregister.co.uk/2018/01/02/intel_cpu_design_flaw/ > > > > imb > > > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org" > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ > 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" > This is insane... And to think a few months ago people were complaining that Ryzen processors and specifically Threadripper might be insecure in data centers, ha. This is a massive clusterfk ___ 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: Intel CPU design flaw - FreeBSD affected? // disabling _R_DTSC
On Fri, Jan 5, 2018 at 2:25 AM, Klaus P. Ohrhallinger wrote: > On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote: > > Hello, > > > > I disabled the ldtsc and ldtscp instructions for usermode on one of my > > production servers: > > > > Oops, RDTSC of course. > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I'd love to see if RISC-V is vulnerable to this? I think they are in the best position to capitalize on this clusterfk... ___ 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: Programmatically cache line
On Fri, Jan 5, 2018 at 2:29 AM, Konstantin Belousov wrote: > On Thu, Jan 04, 2018 at 10:03:32AM +, David Chisnall wrote: > > On 3 Jan 2018, at 22:12, Nathan Whitehorn > wrote: > > > > > > On 01/03/18 13:37, Ed Schouten wrote: > > >> 2018-01-01 11:36 GMT+01:00 Konstantin Belousov : > > >> On x86, the CPUID instruction leaf 0x1 returns the information in > > >> %ebx register. > > > Hm, weird. Why don't we extend sysctl to include this info? > > >>> For the same reason we do not provide a sysctl to add two integers. > > >> I strongly agree with Kostik on this one. Why add stuff to the kernel, > > >> if userspace is already capable of extracting this? Adding that stuff > > >> to sysctl has the downside that it will effectively introduce yet > > >> another FreeBSDism, whereas something generic already exists. > > >> > > > > > > Well, kind of. The userspace version is platform-dependent and not > always available: for example, on PPC, you can't do this from userland and > we provide a sysctl machdep.cacheline_size to userland. It would be nice to > have an MI API. > > > > On ARMv8, similarly, sometimes the kernel needs to advertise the wrong > size. A few big.LITTLE cores have 64-byte cache lines on one cluster and > 32-byte on the other. If you query the size from userspace while running > on a 64-byte cluster, then issue the zero-cache-line instruction while > migrated to the 32-byte cluster, you only clear half the size. Linux works > around this by trapping and emulating the instruction to query the cache > size and always reporting the size for the smallest cache lines. ARM tells > people not to build systems like this, but it doesn???t always stop them. > Trapping and emulating is much slower than just providing the information > in a shared page, elf aux args vector, or even (often) a system call. > > Of course MD way is the best way to get such information, just because the > meaning of the 'cache line size' exists only in context of the given CPU > (micro)architecture. For instance, on PowerPC and ARM you are often > concerned > with the granularity of the instruction cache flush, but also you might be > concerned with the DMA, and these are different concepts of cache. > > Even on x86, you may care about alignment to avoid false sharing or > about CLFLUSH granularity, and these can be different legitimately. > Which one to report as 'cache line' ? > > And you cannot bail out with the max among all constants, because sometimes > you really need the min size (for CLFLUSH), and sometime max size (for > false sharing). > > > > > To give another example, Linux provides a very cheap way for a userspace > process to enquire which core it???s running on. Some more recent > high-performance mallocs use this to have a second-layer per-core cache > after the per-thread cache for free blocks. Unlike the per-thread cache, > the per-core cache does need a lock, but it???s very unlikely to be > contended (it will only be contended if either a thread is migrated in > between checking and locking, so acquires the wrong CPU???s lock, or if a > thread is preempted in the middle of middle of the very brief fill > operation). The author of the SuperMalloc paper tried doing this with > CPUID and found that it was slower by a sufficient margin to almost > entirely offset the benefits of the extra layer of caching. > > There, RDTSCP is the intended way to get cpu id in userspace, but the use > of this instruction requires some minimal OS support. It should be faster > than CPUID, since it is not fully serializing. We do not support it only > because nobody asked so far. > > > > > Just because userspace can get at the information directly from the > hardware doesn???t mean that this is the most efficient or best way for > userspace to get at it. > > > It depends, but single instruction (!) vs syscall comparision makes this > discussion silly. > > > Oh, and some of these things are useful in portable code, so having to > write some assembly for every target to get information that the kernel > already knows is wasteful. > > > Required work is to provide the definitions of these interfaces, then they > can be implemented in the best way for each architecture. But nobody did > that. > Initially I was "asking" to see if these facilities were available so that I didn't have to go do some hack job that would be brittle or reinvent the wheel. My use case for getting the cache lines was to prevent false sharing. I should've been more clear about that in my initial email but, I didn't know all these other people were interested in this issue as well. since I'd like the cache line sizes to prevent false sharing that's my use case. Does anyone else have any use cases that they would like to propose? Once we have come to some agreement on what features they need, then we can work out the interfaces and get the work done on implementation? > ___ > freebsd-curren
Re: USB stack
I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater and the topic gets derailed...? Are you guys saying that 7-8MB/s is USB speeds? On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel wrote: > > > > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: > >> What is an "LG v30"? > >> > > It's a smartphone from LG and only supports USB2 speed. The reported > > transfer rate is no big surprise. > > OK thanks. > > -- > Daniel O'Connor > "The nice thing about standards is that there > are so many of them to choose from." > -- Andrew Tanenbaum > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > > ___ 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: USB stack
On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme wrote: > I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater > and the topic gets derailed...? > > Are you guys saying that 7-8MB/s is USB speeds? > > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > wrote: > >> >> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: >> >> What is an "LG v30"? >> >> >> > It's a smartphone from LG and only supports USB2 speed. The reported >> > transfer rate is no big surprise. >> >> OK thanks. >> >> -- >> Daniel O'Connor >> "The nice thing about standards is that there >> are so many of them to choose from." >> -- Andrew Tanenbaum >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> > Actually, this post: https://forums.freebsd.org/threads/41041/ on the forum from 2013 pretty well describes what I am experiencing when moving data over USB. I have no problems hitting very high read/ write speeds using dd or downloading something but copying by USB is excruciatingly slow. Why is that? ___ 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: USB stack
On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme > wrote: > >> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme >> wrote: >> >> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater >> > and the topic gets derailed...? >> > >> > Are you guys saying that 7-8MB/s is USB speeds? >> > >> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >> > wrote: >> > >> >> >> >> >> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn >> wrote: >> >> >> What is an "LG v30"? >> >> >> >> >> > It's a smartphone from LG and only supports USB2 speed. The reported >> >> > transfer rate is no big surprise. >> >> >> >> OK thanks. >> >> >> >> -- >> >> Daniel O'Connor >> >> "The nice thing about standards is that there >> >> are so many of them to choose from." >> >> -- Andrew Tanenbaum >> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> >> >> >> >> > Actually, this post: https://forums.freebsd.org/threads/41041/ >> >> on the forum from 2013 pretty well describes what I am experiencing when >> moving data over USB. >> >> I have no problems hitting very high read/ write speeds using dd or >> downloading something but copying by USB is excruciatingly slow. >> >> Why is that? > > > If you are copying a boatload of tiny files to USB there's two issues. > Both our UFS and MSDOS don't do well in this case. Second, for flash based > USB thumbdrives, most of them have horrible write performance unless you > buy quality drives... > > Warner > I would consider this： https://www.samsung.com/us/computing/memory-storage/memory-cards/micro-sd-evo-256gb-memory-card-w-adapter-mb-mc256da-am/ 256GB Samsung microsd card quality. ___ 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: USB stack
On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: >> >>> >>> >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme >>> wrote: >>> >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater >>>> and the topic gets derailed...? >>>> >>> >>> Yes, it does. >>> >>> >>>> Are you guys saying that 7-8MB/s is USB speeds? >>>> >>> >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at about >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've >>> not tried USB3 with an SSD that can do more >>> >>> Warner >>> >>> >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>>> wrote: >>>> >>>> > >>>> > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn >>>> wrote: >>>> > >> What is an "LG v30"? >>>> > >> >>>> > > It's a smartphone from LG and only supports USB2 speed. The >>>> reported >>>> > > transfer rate is no big surprise. >>>> > >>>> > OK thanks. >>>> > >>>> > -- >>>> > Daniel O'Connor >>>> > "The nice thing about standards is that there >>>> > are so many of them to choose from." >>>> > -- Andrew Tanenbaum >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> > >>>> > >>>> ___ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>>> reebsd.org" >>>> >>> >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone >> --- >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 >> Jan 7 11:56:56 blubee kernel: umass0: > Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = >> 0x0100 >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 >> lun 0 >> Jan 7 11:56:56 blubee kernel: da0: Fixed Direct >> Access SPC-4 SCSI device >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 >> Jan 7 12:06:08 blubee kernel: lock order reversal: >> Jan 7 12:06:08 blubee kernel: 1st 0xfe07c26336c0 bufwait (bufwait) >> @ /usr/src/sys/vm/vm_pager.c:374 >> Jan 7 12:06:08 blubee kernel: 2nd 0xf80148c425f0 zfs (zfs) @ >> /usr/src/sys/dev/md/md.c:952 >> Jan 7 12:06:08 blubee kernel: stack backtrace: >> Jan 7 12:06:08 blubee kernel: #0 0x80acfa03 at >> witness_debugger+0x73 >> Jan 7 12:06:08 blubee kernel: #1 0x80acf882 at >> witness_checkorder+0xe02 >> Jan 7 12:06:08 blubee kernel: #2 0x80a41b8e at >> lockmgr_lock_fast_path+0x1ae >> Jan 7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9 >> Jan 7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66 >> Jan 7 12:06:08 blubee kernel: #5 0x80611d32 at >> mdstart_vnode+0x442 >> Jan 7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe >> Jan 7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84 >> Jan 7 12:06:08 blubee kernel: #8 0x80ef5e0e at >> fork_trampoline+0xe >> Jan 7 12:06:15 blubee kernel: lock order reversal: >> Jan 7 12:06:15 blubee kernel: 1st 0xfe07c41d5dc0 bufwait (bufwait) >> @ /usr/src/sys/kern/vfs_bio.c:3562 >> Jan 7 12:06:15 blubee kernel: 2nd 0xf8002bb31a00 dirhash (dirhash) >> @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 >> Jan 7 12:06:15 blubee kernel: stack backtrace: >> Jan 7 12:06:15 blubee kernel: #0 0x80acfa03 at >> witness_debugger+0x73 >>
Re: USB stack
On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > wrote: > >> I ask does FreeBSD usb stack actually implements USB spec 2.0 or greater >> and the topic gets derailed...? >> > > Yes, it does. > > >> Are you guys saying that 7-8MB/s is USB speeds? >> > > I've gotten up to 24MB/s for maybe a decade. That's not possible with USB > 1.x. More recently, I've maxed out the writes on a USB stick at about > 75MB/s (the fastest it will do), which isn't possible with USB 2.0... I've > not tried USB3 with an SSD that can do more > > Warner > > >> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >> wrote: >> >> > >> > >> > > On 4 Jan 2018, at 09:23, Gary Jennejohn wrote: >> > >> What is an "LG v30"? >> > >> >> > > It's a smartphone from LG and only supports USB2 speed. The reported >> > > transfer rate is no big surprise. >> > >> > OK thanks. >> > >> > -- >> > Daniel O'Connor >> > "The nice thing about standards is that there >> > are so many of them to choose from." >> > -- Andrew Tanenbaum >> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >> > >> > >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > > I just connected a Transcend StorageJet 1TB hdd not a mobile phone --- Jan 7 11:56:56 blubee kernel: umass0 on uhub0 Jan 7 11:56:56 blubee kernel: umass0: on usbus0 Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = 0x0100 Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun 0 Jan 7 11:56:56 blubee kernel: da0: Fixed Direct Access SPC-4 SCSI device Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 Jan 7 12:06:08 blubee kernel: lock order reversal: Jan 7 12:06:08 blubee kernel: 1st 0xfe07c26336c0 bufwait (bufwait) @ /usr/src/sys/vm/vm_pager.c:374 Jan 7 12:06:08 blubee kernel: 2nd 0xf80148c425f0 zfs (zfs) @ /usr/src/sys/dev/md/md.c:952 Jan 7 12:06:08 blubee kernel: stack backtrace: Jan 7 12:06:08 blubee kernel: #0 0x80acfa03 at witness_debugger+0x73 Jan 7 12:06:08 blubee kernel: #1 0x80acf882 at witness_checkorder+0xe02 Jan 7 12:06:08 blubee kernel: #2 0x80a41b8e at lockmgr_lock_fast_path+0x1ae Jan 7 12:06:08 blubee kernel: #3 0x81094309 at VOP_LOCK1_APV+0xd9 Jan 7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66 Jan 7 12:06:08 blubee kernel: #5 0x80611d32 at mdstart_vnode+0x442 Jan 7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe Jan 7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84 Jan 7 12:06:08 blubee kernel: #8 0x80ef5e0e at fork_trampoline+0xe Jan 7 12:06:15 blubee kernel: lock order reversal: Jan 7 12:06:15 blubee kernel: 1st 0xfe07c41d5dc0 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3562 Jan 7 12:06:15 blubee kernel: 2nd 0xf8002bb31a00 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:281 Jan 7 12:06:15 blubee kernel: stack backtrace: Jan 7 12:06:15 blubee kernel: #0 0x80acfa03 at witness_debugger+0x73 Jan 7 12:06:15 blubee kernel: #1 0x80acf882 at witness_checkorder+0xe02 Jan 7 12:06:15 blubee kernel: #2 0x80a748a8 at _sx_xlock+0x68 Jan 7 12:06:15 blubee kernel: #3 0x80d6a28d at ufsdirhash_add+0x3d Jan 7 12:06:15 blubee kernel: #4 0x80d6d119 at ufs_direnter+0x459 Jan 7 12:06:15 blubee kernel: #5 0x80d76313 at ufs_makeinode+0x613 Jan 7 12:06:15 blubee kernel: #6 0x80d71ff4 at ufs_create+0x34 Jan 7 12:06:15 blubee kernel: #7 0x810919e3 at VOP_CREATE_APV+0xd3 Jan 7 12:06:15 blubee kernel: #8 0x80b4a53d at vn_open_cred+0x2ad Jan 7 12:06:15 blubee kernel: #9 0x80b42e92 at kern_openat+0x212 Jan 7 12:06:15 blubee kernel: #10 0x80f16d2b at amd64_syscall+0x79b Jan 7 12:06:15 blubee kernel: #11 0x80ef5b7b at Xfast_syscall+0xfb Is the slow transfers user error? ___ 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: USB stack
On Sun, Jan 7, 2018 at 12:25 PM, Warner Losh wrote: > > > On Sat, Jan 6, 2018 at 9:20 PM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 7, 2018 at 12:17 PM, Warner Losh wrote: >> >>> >>> >>> On Sat, Jan 6, 2018 at 9:08 PM, blubee blubeeme >>> wrote: >>> >>>> On Sun, Jan 7, 2018 at 11:56 AM, blubee blubeeme >>>> wrote: >>>> >>>> > I ask does FreeBSD usb stack actually implements USB spec 2.0 or >>>> greater >>>> > and the topic gets derailed...? >>>> > >>>> > Are you guys saying that 7-8MB/s is USB speeds? >>>> > >>>> > On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel >>>> > wrote: >>>> > >>>> >> >>>> >> >>>> >> > On 4 Jan 2018, at 09:23, Gary Jennejohn >>>> wrote: >>>> >> >> What is an "LG v30"? >>>> >> >> >>>> >> > It's a smartphone from LG and only supports USB2 speed. The >>>> reported >>>> >> > transfer rate is no big surprise. >>>> >> >>>> >> OK thanks. >>>> >> >>>> >> -- >>>> >> Daniel O'Connor >>>> >> "The nice thing about standards is that there >>>> >> are so many of them to choose from." >>>> >> -- Andrew Tanenbaum >>>> >> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C >>>> >> >>>> >> >>>> > Actually, this post: https://forums.freebsd.org/threads/41041/ >>>> >>>> on the forum from 2013 pretty well describes what I am experiencing when >>>> moving data over USB. >>>> >>>> I have no problems hitting very high read/ write speeds using dd or >>>> downloading something but copying by USB is excruciatingly slow. >>>> >>>> Why is that? >>> >>> >>> If you are copying a boatload of tiny files to USB there's two issues. >>> Both our UFS and MSDOS don't do well in this case. Second, for flash based >>> USB thumbdrives, most of them have horrible write performance unless you >>> buy quality drives... >>> >>> Warner >>> >> I would consider this： https://www.samsung.com/ >> us/computing/memory-storage/memory-cards/micro-sd-evo-256gb- >> memory-card-w-adapter-mb-mc256da-am/ >> 256GB Samsung microsd card quality. >> > > At most, you can get 90MB/s read/write on this card. What are you seeing? > And how are you copying? > > Warner > I use the phone, LG V30 to record basically ungraded RAW video files to the microsd card; they are large files. I transfer them to my computer copy a backup to the 1TB driver; then do edits/ color grading, etc in blender, then I transfer the finished to another 1TB hdd for backup as well. ___ 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: USB stack
On Sun, Jan 7, 2018 at 1:32 PM, Tomoaki AOKI wrote: > On Sun, 7 Jan 2018 12:25:17 +0800 > blubee blubeeme wrote: > > > On Sun, Jan 7, 2018 at 12:20 PM, Warner Losh wrote: > > > > > > > > > > > On Sat, Jan 6, 2018 at 9:18 PM, blubee blubeeme > > > wrote: > > > > > >> > > >> > > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > > >> > > >>> > > >>> > > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > > > >>> wrote: > > >>> > > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or > greater > > >>>> and the topic gets derailed...? > > >>>> > > >>> > > >>> Yes, it does. > > >>> > > >>> > > >>>> Are you guys saying that 7-8MB/s is USB speeds? > > >>>> > > >>> > > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > > >>> USB 1.x. More recently, I've maxed out the writes on a USB stick at > about > > >>> 75MB/s (the fastest it will do), which isn't possible with USB > 2.0... I've > > >>> not tried USB3 with an SSD that can do more > > >>> > > >>> Warner > > >>> > > >>> > > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel < > dar...@dons.net.au> > > >>>> wrote: > > >>>> > > >>>> > > > >>>> > > > >>>> > > On 4 Jan 2018, at 09:23, Gary Jennejohn > > >>>> wrote: > > >>>> > >> What is an "LG v30"? > > >>>> > >> > > >>>> > > It's a smartphone from LG and only supports USB2 speed. The > > >>>> reported > > >>>> > > transfer rate is no big surprise. > > >>>> > > > >>>> > OK thanks. > > >>>> > > > >>>> > -- > > >>>> > Daniel O'Connor > > >>>> > "The nice thing about standards is that there > > >>>> > are so many of them to choose from." > > >>>> > -- Andrew Tanenbaum > > >>>> > GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F > CE8C > > >>>> > > > >>>> > > > >>>> ___ > > >>>> freebsd-current@freebsd.org mailing list > > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f > > >>>> reebsd.org" > > >>>> > > >>> > > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > > >> --- > > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > > >> Jan 7 11:56:56 blubee kernel: umass0: > >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > > >> 0x0100 > > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > > >> lun 0 > > >> Jan 7 11:56:56 blubee kernel: da0: Fixed > Direct > > >> Access SPC-4 SCSI device > > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > sectors) > > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > > >> Jan 7 12:06:08 blubee kernel: 1st 0xfe07c26336c0 bufwait > (bufwait) > > >> @ /usr/src/sys/vm/vm_pager.c:374 > > >> Jan 7 12:06:08 blubee kernel: 2nd 0xf80148c425f0 zfs (zfs) @ > > >> /usr/src/sys/dev/md/md.c:952 > > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > > >> Jan 7 12:06:08 blubee kernel: #0 0x80acfa03 at > > >> witness_debugger+0x73 > > >> Jan 7 12:06:08 blubee kernel: #1 0x80acf882 at > > >> witness_checkorde
Re: Re: USB stack
On Sun, Jan 7, 2018 at 4:27 PM, Freddie Cash wrote: > Forgot to include the list. Resending. > > -- Forwarded message -- > From: "Freddie Cash" > Date: Jan 7, 2018 12:26 AM > Subject: Re: USB stack > To: "blubee blubeeme" > Cc: > > On Jan 6, 2018 8:30 PM, "blubee blubeeme" wrote: > > > I just connected a Transcend StorageJet 1TB hdd not a mobile phone > --- > Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > Jan 7 11:56:56 blubee kernel: umass0: Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > 0x0100 > Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 lun > 0 > Jan 7 11:56:56 blubee kernel: da0: Fixed Direct > Access SPC-4 SCSI device > Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte sectors) > Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > > > Is the slow transfers user error? > > > You'll need to post /var/run/dmesg.boot somewhere so we can see how your > USB controllers are being detected and the different buses are being > configured, and which bus/controller the USB devices are attaching too. You > haven't shown enough information yet to be able to help you. > > Cheers, > Freddie > ___ > 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" > Here's the latest unmodified GENERIC kernel boot log. FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 14:54:55 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 pastebin: https://pastebin.com/66NZEFtp Anything else that I can provide? ___ 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: USB stack
On Sun, Jan 7, 2018 at 5:35 PM, Mark Millard wrote: > blubee blubeeme gurenchan at gmail.com wrote on > Wed Jan 3 10:31:56 UTC 2018 : > > > Does FreeBSD current USB stack support usb >= 2.0 devices? > > > > Testing out the USB devices support I get about 7.2-7.8 megabytes per > > second which seems odd. > > > FreeBSD machine: Pine64+ 2GB? Ryzen Threadripper 1950X? . . .? > > It would help to specify the type of system and its > relevant properties (not just the processor). > > What independent channels are in use? Any? Or are > the source and destination on the same channel at > some stage? > > > I transferred about 30GB of audio from laptop > > The 30GB was on what type of device? Plugged in to what? > What file system? > ZFS file system on the main machine and the 1TB Transcend drive. I am not 100% sure what format android device is; I can look into this further but I've been testing on the Transcend device linked above in this list. > > > to Samsung usb class 10 usb > > device connected to LG v30. > > What file system? > Android 7.1 > > And in another message (indicating the other direction > of transfer compared to the above?): > I transfer from the phone to the computer. > > > I use the phone, LG V30 to record basically ungraded RAW video files to > the > > microsd card; they are large files. > > I transfer them to my computer copy a backup to the 1TB driver; then do > > edits/ color grading, etc in blender, > > then I transfer the finished to another 1TB hdd for backup as well. > > So the LG v30 was plugged in as a USB device, effectively > acting as a media reader/writer? What file system? > (It seems unlikely that the LG v30 would use a FreeBSD > native file system to record RAW video files.) > > > Going the other direction of providing some examples > of files copies for UFS. . . > > Note: These are based on head -r327485 with > non-debug kernel builds. > > > Example performance copying /usr/src/ : > (lots of small files on a fairly low-end FreeBSD > machine) > > RPi2B V1.1 (with USB 2.0) > One USB 3.0 powered hub (USB 2.0 compatible) with both: > > A) USB 3.0 SSD stick (USB 2.0 compatible) with the root file system > > B) 64 GB eMMC on a usdcard adapter, plugged into a USB 3.0 media >reader/writer (USB 2.0 compatible). > > mount -o noatime in use for (A) and (B). UFS file systems. > soft-updates enabled. > > cp -ax /usr/src/ /mnt/root/srccpy_test > > gstat -pd outputs, a few examples: > > dT: 1.007s w: 1.000s > L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps > ms/d %busy Name > 0255255 55011.9 0 00.0 0 0 > 0.0 48.0| da0 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da1 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da2 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da3 >64426 1 32 221.4425 6287 140.4 0 0 > 0.0 62.9| da4 > > Note that the read kBps + write kBps means around 11MiByte/s for r+w. > (There is only one USB connection at the RPi2B V1.1 here, > not multiple, independent channels.) > This is an example copying [multiple small files] to the 1TB drive. -- L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps ms/d %busy Name 0547290 352392.0 4 16 73.1249 44291 93.7 48.8| nvd0 0 0 0 00.0 0 00.0 0 0 0.00.0| md99 21333 0 00.0333 36040 16.2 0 0 0.0 76.2| da1 -- > > dT: 1.007s w: 1.000s > L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps > ms/d %busy Name > 0393393 52951.3 0 00.0 0 0 > 0.0 50.7| da0 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da1 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da2 > 0 0 0 00.0 0 00.0 0 0 > 0.00.0| da3 >46102 2 642.9100 2101 116.9 0 0 > 0.0 19.5| da4 > > The above last shows a period with around 7 MiBytes/s for r+w. > > dT: 1.007s w: 1.000s > L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps > ms/d %busy Name >16245245 9761 3
Re: USB stack
On Sun, Jan 7, 2018 at 8:13 PM, Mark Millard wrote: > [I add an example of a none-USB to USB2 copy and > a USB2 to non-USB copy. They do not show any > < 8 MiByte/s bottlenecks.] > > On 2018-Jan-7, at 3:42 AM, Mark Millard wrote: > > > [The other numbers show lots of delete activity on nvd0, > > not just primarily reads. Also: Can you test a different > > USB device, such as a USB SSD stick?] > > > > On 2018-Jan-7, at 2:44 AM, Mark Millard wrote: > > > >> [The following notes a problem with how a test was done. > >> I omit the rest of the material.] > >> > >> On 2018-Jan-7, at 2:09 AM, blubee blubeeme > wrote: > >> > >> . . . > >>> This is a larger file, not the largest but hey > >>> > >>> L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps > ms/d %busy Name > >>> 0 4 0 00.0 2 80.0 0 0 > 0.00.1| nvd0 > >>> 0 0 0 00.0 0 00.0 0 0 > 0.00.0| md99 > >>> 128982 1 32 58.8981 125428 110.5 0 0 > 0.0 100.0| da1 > >> . . . > >> > >> Note that almost complete lack of kBps near r/s but the large > >> kBps near w/s. > >> > >> It appears that the file has been cached in RAM and is not > >> being read from media at all. So this test is of a RAM to > >> disk transfer, not disk to disk, as far as I can tell. > >> > >> You need to avoid re-reading the same file unless you > >> dismount and remount between tests or some such. Or > >> just use a different file not copied since booting (that > >> file may or may not be a previous copy of the same file > >> by content). > >> > >> See if you can get gstat -pd results that show both > >> read kBps and write kBps figures. > > > > Can you test another USB device, such as a USB SSD > > stick, sometime known to be reliably fast and not > > involving reading from the LG v30? > > > > From what I read Android has many file systems supported > > or used at one time: ext4, f2fs, yaffs, yaffs2, > > vfat, msdos being in the list. Normal SD and SDHC files > > systems are FAT32 and SDXC is exFAT. > > > > So "Android 7.1" does not answer my question about which > > file system is actually on the usdcard being used. I'd > > guess FAT32 or exFAT, depending on SD/SDHC vs. SDXC, but > > I do not really know. > > > > > > My results show that getting above 8 MiBytes/s over > > USB 2.0 is supported for other than the rather low end > > of the FreeBSD range of systems. Beyond that is something > > more specific to your context and not involved in mine. > > The file system might be involved. > > > > So far, from the tables and what you have written, the > > LG v30 is required to be involved for the slowdown > > to sub 8 MiBytes/s. This is part of why I ask about > > testing an alternative USB device that is fast: it > > tests USB without involving the LG v30 or the usdcard. > > > > If USB ends up faster, then it is not USB's "stack" that > > is the primary source of the current bottleneck for your > > context: something else is also involved, such as the > > file system may be. > > > > Can you show gstat -pd output for copying from the > > LG v30? Copying to the 1TB USB backup device? The > > %busy figures might be interesting. > > > > > > In your other table: > > > > This is an example copying [multiple small files] to the 1TB drive. > > > -- > > L(q) ops/sr/s kBps ms/rw/s kBps ms/wd/s kBps > ms/d %busy Name > >0547290 352392.0 4 16 73.1249 44291 > 93.7 48.8| nvd0 > >0 0 0 00.0 0 00.0 0 0 > 0.00.0| md99 > > 21333 0 00.0333 36040 16.2 0 0 > 0.0 76.2| da1 > > > -- > > > > This shows lots of deletes per second for some reason. > > > > Did you move instead of copy? After each file was copied, > > was it then deleted? > > > > It is possible that the deletes slowed this down, > > whatever they were from. > > > Here are "gstat -pd" samples from during
Re: USB stack
On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard wrote: > > On 2018-Jan-7, at 7:50 AM, blubee blubeeme wrote: > > > I ran this test and here's some results. > > gstat -pd images: > > > > 18GB file from laptop to phone: https://imgur.com/a/7iHwv > > 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > > multiple small files from laptop to phone: https://imgur.com/a/B4v4y > > multiple small files from laptop to ssd: https://imgur.com/a/mDiMu > > > > The files are missing timestamps but the originals were taken with scrot > and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > > > > as far as why there's such high deletions? I can't say I'm only using cp. > > I assume that md99 is for a file-based swap-space, such as > via /var/swap0 file. (As a side note I warn about bugzilla > 206048 for such contexts.) Otherwise please describe how > md99 is created. (Below I assume the swap-space usage of > md99.) > > The only other device that your pictures show is your > NVMe device nvd0. > > No picture shows a device for the LG v30 when it is mentioned > above as being copied to or from. How is it that there is no > mounted device shown for the LG v30? > > No picture shows a device for the SSD when it is mentioned > above as being copied to or from. How is it that there > is no mounted device shown for the SSD? > > Without a device displayed for the LG-v30/SSD there is nothing > displayed for its reads or writes. This makes the gstat -pd > useless. > > May be the p needs to be omitted for some reason? gstat -d > > === > Mark Millard > markmi at dsl-only.net > > You are correct that md99 is a file backed swap disk, I am aware of the issues but I had to test some things out. Those tests earlier was a huge time sink. Here's the dmesg output from earlier: Jan 7 19:13:17 blubee kernel: Copyright (c) 1992-2017 The FreeBSD Project. Jan 7 19:13:17 blubee kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 Jan 7 19:13:17 blubee kernel: The Regents of the University of California. All rights reserved. Jan 7 19:13:17 blubee kernel: FreeBSD is a registered trademark of The FreeBSD Foundation. Jan 7 19:13:17 blubee kernel: FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 14:54:55 UTC 2017 Jan 7 19:13:17 blubee kernel: r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 Jan 7 19:13:17 blubee kernel: FreeBSD clang version 5.0.0 (tags/RELEASE_500/final 312559) (based on LLVM 5.0.0svn) Jan 7 19:13:17 blubee kernel: WARNING: WITNESS option enabled, expect reduced performance. Jan 7 19:13:17 blubee kernel: VT(efifb): resolution 3840x2160 Jan 7 19:13:17 blubee kernel: CPU: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz (2592.11-MHz K8-class CPU) Jan 7 19:13:17 blubee kernel: Origin="GenuineIntel" Id=0x506e3 Family=0x6 Model=0x5e Stepping=3 Jan 7 19:13:17 blubee kernel: Features=0xbfebfbff Jan 7 19:13:17 blubee kernel: Features2=0x7ffafbbf Jan 7 19:13:17 blubee kernel: AMD Features=0x2c100800 Jan 7 19:13:17 blubee kernel: AMD Features2=0x121 Jan 7 19:13:17 blubee kernel: Structured Extended Features=0x29c6fbf Jan 7 19:13:17 blubee kernel: XSAVE Features=0xf Jan 7 19:13:17 blubee kernel: VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID Jan 7 19:13:17 blubee kernel: TSC: P-state invariant, performance statistics Jan 7 19:13:17 blubee kernel: real memory = 34359738368 (32768 MB) Jan 7 19:13:17 blubee kernel: avail memory = 33147957248 (31612 MB) Jan 7 19:13:17 blubee kernel: Event timer "LAPIC" quality 600 Jan 7 19:13:17 blubee kernel: ACPI APIC Table: Jan 7 19:13:17 blubee kernel: FreeBSD/SMP: Multiprocessor System Detected: 8 CPUs Jan 7 19:13:17 blubee kernel: FreeBSD/SMP: 1 package(s) x 4 core(s) x 2 hardware threads Jan 7 19:13:17 blubee kernel: random: unblocking device. Jan 7 19:13:17 blubee kernel: ioapic0 irqs 0-119 on motherboard Jan 7 19:13:17 blubee kernel: SMP: AP CPU #1 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #4 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #2 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #3 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #6 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #5 Launched! Jan 7 19:13:17 blubee kernel: SMP: AP CPU #7 Launched! Jan 7 19:13:17 blubee kernel: Timecounter "TSC-low" frequency 1296054319 Hz quality 1000 Jan 7 19:13:17 blubee kernel: random: entropy device external interface Jan 7 19:13:17 blubee kernel: netmap: loaded module Jan 7 19:13:17 blubee kernel: [ath_hal] loaded Jan 7 19:13:17 blubee kernel: module_register_init: MOD_LOAD (vesa, 0x80f95c20, 0) error 19 Jan 7 19:13:17 blubee kernel: random: registering fast source Intel Secure Key RNG Jan 7 19:13:1
newcons vs syscons
I'm curious why the new console driver vt doesn't have a vesa driver when the traditional syscons driver did. https://wiki.freebsd.org/Newcons Is there any specific reason why vesa driver wasn't implemented? ___ 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: USB stack
On Mon, Jan 8, 2018 at 8:03 AM, Jon Brawn wrote: > > > > On Jan 7, 2018, at 5:44 PM, Jon Brawn wrote: > > > > > >> On Jan 6, 2018, at 10:18 PM, blubee blubeeme > wrote: > >> > >> On Sun, Jan 7, 2018 at 12:11 PM, Warner Losh wrote: > >> > >>> > >>> > >>> On Sat, Jan 6, 2018 at 8:56 PM, blubee blubeeme > >>> wrote: > >>> > >>>> I ask does FreeBSD usb stack actually implements USB spec 2.0 or > greater > >>>> and the topic gets derailed...? > >>>> > >>> > >>> Yes, it does. > >>> > >>> > >>>> Are you guys saying that 7-8MB/s is USB speeds? > >>>> > >>> > >>> I've gotten up to 24MB/s for maybe a decade. That's not possible with > USB > >>> 1.x. More recently, I've maxed out the writes on a USB stick at about > >>> 75MB/s (the fastest it will do), which isn't possible with USB 2.0... > I've > >>> not tried USB3 with an SSD that can do more > >>> > >>> Warner > >>> > >>> > >>>> On Thu, Jan 4, 2018 at 6:44 PM, O'Connor, Daniel > >>>> wrote: > >>>> > >>>>> > >>>>> > >>>>>> On 4 Jan 2018, at 09:23, Gary Jennejohn > wrote: > >>>>>>> What is an "LG v30"? > >>>>>>> > >>>>>> It's a smartphone from LG and only supports USB2 speed. The > reported > >>>>>> transfer rate is no big surprise. > >>>>> > >>>>> OK thanks. > >>>>> > >>>>> -- > >>>>> Daniel O'Connor > >>>>> "The nice thing about standards is that there > >>>>> are so many of them to choose from." > >>>>> -- Andrew Tanenbaum > >>>>> GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C > >>>>> > >>>>> > >>>> ___ > >>>> freebsd-current@freebsd.org mailing list > >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > freebsd.org > >>>> " > >>>> > >>> > >>> I just connected a Transcend StorageJet 1TB hdd not a mobile phone > >> --- > >> Jan 7 11:56:56 blubee kernel: umass0 on uhub0 > >> Jan 7 11:56:56 blubee kernel: umass0: >> Transcend, class 0/0, rev 3.00/80.00, addr 4> on usbus0 > >> Jan 7 11:56:56 blubee kernel: umass0: SCSI over Bulk-Only; quirks = > 0x0100 > >> Jan 7 11:56:56 blubee kernel: umass0:3:0: Attached to scbus3 > >> Jan 7 11:56:56 blubee kernel: da0 at umass-sim0 bus 0 scbus3 target 0 > lun 0 > >> Jan 7 11:56:56 blubee kernel: da0: Fixed Direct > >> Access SPC-4 SCSI device > >> Jan 7 11:56:56 blubee kernel: da0: Serial Number W9328YZN > >> Jan 7 11:56:56 blubee kernel: da0: 400.000MB/s transfers > >> Jan 7 11:56:56 blubee kernel: da0: 953869MB (1953525168 512 byte > sectors) > >> Jan 7 11:56:56 blubee kernel: da0: quirks=0x2 > >> Jan 7 12:06:08 blubee kernel: lock order reversal: > >> Jan 7 12:06:08 blubee kernel: 1st 0xfe07c26336c0 bufwait > (bufwait) @ > >> /usr/src/sys/vm/vm_pager.c:374 > >> Jan 7 12:06:08 blubee kernel: 2nd 0xf80148c425f0 zfs (zfs) @ > >> /usr/src/sys/dev/md/md.c:952 > >> Jan 7 12:06:08 blubee kernel: stack backtrace: > >> Jan 7 12:06:08 blubee kernel: #0 0x80acfa03 at > >> witness_debugger+0x73 > >> Jan 7 12:06:08 blubee kernel: #1 0x80acf882 at > >> witness_checkorder+0xe02 > >> Jan 7 12:06:08 blubee kernel: #2 0x80a41b8e at > >> lockmgr_lock_fast_path+0x1ae > >> Jan 7 12:06:08 blubee kernel: #3 0x81094309 at > VOP_LOCK1_APV+0xd9 > >> Jan 7 12:06:08 blubee kernel: #4 0x80b4ac36 at _vn_lock+0x66 > >> Jan 7 12:06:08 blubee kernel: #5 0x80611d32 at > mdstart_vnode+0x442 > >> Jan 7 12:06:08 blubee kernel: #6 0x806102ce at md_kthread+0x1fe > >> Jan 7 12:06:08 blubee kernel: #7 0x80a2d654 at fork_exit+0x84 > >> Jan 7 12:06:08 blubee kernel: #8 0x80ef5e0e at > fork_trampoline+0xe > >>
Re: USB stack
On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard wrote: > [The involvement of sysutils/fusefs-simple-mtpfs > and sysutils/fusefs-libs and multimedia/libmtp > in order to use the Media Transfer Protocol (MTP) > against the LG v30 likely explains much of the > performance difference vs. local UFS file > systems. I provide some related notes.] > > blubee blubeeme gurenchan at gmail.com wrote on > Mon Jan 8 05:17:24 UTC 2018 : > > [Note: the original was in a reply to a Jon Brawn > post. I've merged it back with my post.] > > > On 2018-Jan-7, at 11:46 AM, Mark Millard wrote: > > > >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme > wrote: > >> > >> > >> > >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard > wrote: > >>> > >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme > wrote: > >>>> > >>>>> I ran this test and here's some results. > >>>>> gstat -pd images: > >>>>> > >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >>>>> multiple small files from laptop to phone: https://imgur.com/a/B4v4y > >>>>> multiple small files from laptop to ssd: https://imgur.com/a/mDiMu > >>>>> > >>>>> The files are missing timestamps but the originals were taken with > scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >>>>> > >>>>> as far as why there's such high deletions? I can't say I'm only > using cp. > >>>> > >>>> I assume that md99 is for a file-based swap-space, such as > >>>> via /var/swap0 file. (As a side note I warn about bugzilla > >>>> 206048 for such contexts.) Otherwise please describe how > >>>> md99 is created. (Below I assume the swap-space usage of > >>>> md99.) > >>>> > >>>> The only other device that your pictures show is your > >>>> NVMe device nvd0. > >>>> > >>>> No picture shows a device for the LG v30 when it is mentioned > >>>> above as being copied to or from. How is it that there is no > >>>> mounted device shown for the LG v30? > >>>> > >>>> No picture shows a device for the SSD when it is mentioned > >>>> above as being copied to or from. How is it that there > >>>> is no mounted device shown for the SSD? > >>>> > >>>> Without a device displayed for the LG-v30/SSD there is nothing > >>>> displayed for its reads or writes. This makes the gstat -pd > >>>> useless. > >>>> > >>>> May be the p needs to be omitted for some reason? gstat -d > >>>> > >>>> === > >>>> Mark Millard > >>>> markmi at dsl-only.net > >>> > >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >>> > >>> Those tests earlier was a huge time sink. > >>> Here's the dmesg output from earlier: > >>> . . . > >>> -- > >>> > >>> I don't know why gstat isn't showing the info u are looking for. > >>> > >>> You said earlier that something was getting deleted, > >>> I don't know what could be causing that. > >> > >> Those "deletes" are more commonly called TRIM on SSD's. > >> FreeBSD called them, BIO_DELETE as I remember. > >> > >> Those deletes have nothing to do with umounting, deleteing > >> devices, etc. > >> > >>> I've provided tons of debug out, logs, pciconf, dmesg, etc... > >>> Even say forget the mobile device and go from > >>> zpool > >> > >> From which I've not been able to figure out the kind of > >> information that I'm looking for. > >> > >> Just because a device is present, does not mean that it > >> is available as a file system. I'm more interested in > >> how the file systems are made available --or if some > >> non-file system way of working is involved. > >> > >>> Are you saying that there's something misconfigured on my end? > >>> What other info do you need me to provide to try to figure out > >>> what's going on
Re: USB stack
On Tue, Jan 9, 2018 at 10:09 AM, Mark Millard wrote: > > On 2018-Jan-8, at 1:15 AM, blubee blubeeme wrote: > > > On Mon, Jan 8, 2018 at 3:20 PM, Mark Millard > wrote: > >> [The involvement of sysutils/fusefs-simple-mtpfs > >> and sysutils/fusefs-libs and multimedia/libmtp > >> in order to use the Media Transfer Protocol (MTP) > >> against the LG v30 likely explains much of the > >> performance difference vs. local UFS file > >> systems. I provide some related notes.] > >> > >> blubee blubeeme gurenchan at gmail.com wrote on > >> Mon Jan 8 05:17:24 UTC 2018 : > >> > >> [Note: the original was in a reply to a Jon Brawn > >> post. I've merged it back with my post.] > >> > >> > On 2018-Jan-7, at 11:46 AM, Mark Millard > wrote: > >> > > >> >> On 2018-Jan-7, at 10:23 AM, blubee blubeeme > wrote: > >> >> > >> >> > >> >> > >> >>> On Mon, Jan 8, 2018 at 1:41 AM, Mark Millard dsl-only.net> wrote: > >> >>> > >> >>>> On 2018-Jan-7, at 7:50 AM, blubee blubeeme > wrote: > >> >>>> > >> >>>>> I ran this test and here's some results. > >> >>>>> gstat -pd images: > >> >>>>> > >> >>>>> 18GB file from laptop to phone: https://imgur.com/a/7iHwv > >> >>>>> 18GB file from laptop to ssd: https://imgur.com/a/40Q6V > >> >>>>> multiple small files from laptop to phone: > https://imgur.com/a/B4v4y > >> >>>>> multiple small files from laptop to ssd: > https://imgur.com/a/mDiMu > >> >>>>> > >> >>>>> The files are missing timestamps but the originals were taken > with scrot and have timestamps available here: https://nofile.io/f/ > mzKnkpM9CyC/stats.tar.gz2 > >> >>>>> > >> >>>>> as far as why there's such high deletions? I can't say I'm only > using cp. > >> >>>> > >> >>>> I assume that md99 is for a file-based swap-space, such as > >> >>>> via /var/swap0 file. (As a side note I warn about bugzilla > >> >>>> 206048 for such contexts.) Otherwise please describe how > >> >>>> md99 is created. (Below I assume the swap-space usage of > >> >>>> md99.) > >> >>>> > >> >>>> The only other device that your pictures show is your > >> >>>> NVMe device nvd0. > >> >>>> > >> >>>> No picture shows a device for the LG v30 when it is mentioned > >> >>>> above as being copied to or from. How is it that there is no > >> >>>> mounted device shown for the LG v30? > >> >>>> > >> >>>> No picture shows a device for the SSD when it is mentioned > >> >>>> above as being copied to or from. How is it that there > >> >>>> is no mounted device shown for the SSD? > >> >>>> > >> >>>> Without a device displayed for the LG-v30/SSD there is nothing > >> >>>> displayed for its reads or writes. This makes the gstat -pd > >> >>>> useless. > >> >>>> > >> >>>> May be the p needs to be omitted for some reason? gstat -d > >> >>>> > >> >>>> === > >> >>>> Mark Millard > >> >>>> markmi at dsl-only.net > >> >>> > >> >>> You are correct that md99 is a file backed swap disk, I am aware of > the issues but I had to test some things out. > >> >>> > >> >>> Those tests earlier was a huge time sink. > >> >>> Here's the dmesg output from earlier: > >> >>> . . . > >> >>> -- > >> >>> > >> >>> I don't know why gstat isn't showing the info u are looking for. > >> >>> > >> >>> You said earlier that something was getting deleted, > >> >>> I don't know what could be causing that. > >> >> > >> >> Those "deletes" are more commonly called TRIM on SSD's. > >> >> FreeBSD called them, BIO_DELETE as I remember. > >> >> > >> >> Those deletes have nothing to do with umounting, deletein
msdosfs_iconv
This is a repost from freebsd-question; Hoping to get more exposure and help here. I am trying to run mount_msdosfs with the option to set locale like this: mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb This returns operation not permitted. usrmount is set to 1 and everything mounts as expected w/o root if I remove the locale option. The problem here is that my document filenames are garbled and I can't actually open the files. kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool is said to work but it does not, after installing it I still get the exact same error. Is there a way to set locale when using mount_msdosfs without sudo? ___ 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: msdosfs_iconv
On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu wrote: > > > On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme > wrote: > >> This is a repost from freebsd-question; Hoping to get more exposure and >> help here. >> >> I am trying to run mount_msdosfs with the option to set locale like this: >> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb >> >> This returns operation not permitted. >> >> usrmount is set to 1 and everything mounts as expected w/o root if I >> remove >> the locale option. The problem here is that my document filenames are >> garbled and I can't actually open the files. >> >> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool >> is said to work but it does not, after installing it I still get the exact >> same error. >> >> Have you tried to kldload msdosfs_iconv first? > > Is there a way to set locale when using mount_msdosfs without sudo? >> ___ >> 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 >> " >> > > > > -- > Cheers, > Henry > Yes, /etc/rc.conf has this line: kld_list="nvidia-modeset msdosfs_iconv" ___ 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: msdosfs_iconv
On Sun, Jan 14, 2018 at 12:16 PM, Henry Hu wrote: > > > On Sat, Jan 13, 2018 at 10:56 PM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu wrote: >> >>> >>> >>> On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme >>> wrote: >>> >>>> This is a repost from freebsd-question; Hoping to get more exposure and >>>> help here. >>>> >>>> I am trying to run mount_msdosfs with the option to set locale like >>>> this: >>>> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb >>>> >>>> This returns operation not permitted. >>>> >>>> usrmount is set to 1 and everything mounts as expected w/o root if I >>>> remove >>>> the locale option. The problem here is that my document filenames are >>>> garbled and I can't actually open the files. >>>> >>>> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool >>>> is said to work but it does not, after installing it I still get the >>>> exact >>>> same error. >>>> >>>> Have you tried to kldload msdosfs_iconv first? >>> >>> Is there a way to set locale when using mount_msdosfs without sudo? >>>> ___ >>>> freebsd-current@freebsd.org mailing list >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>>> reebsd.org" >>>> >>> >>> >>> >>> -- >>> Cheers, >>> Henry >>> >> Yes, /etc/rc.conf has this line: >> kld_list="nvidia-modeset msdosfs_iconv" >> >> > I just tried that and it works. I can create filenames in Chinese on the > mounted drive. > The command I used: > > > mount_msdosfs -L zh_CN.UTF-8 /dev/da1p1 /tmp/y > > kernel modules: > > > kldstat | grep iconv > 303 0x8506e000 458f libiconv.ko > 331 0x8507a000 801 msdosfs_iconv.ko > > But I'm using 11.1-STABLE. Maybe something changed? > > -- > Cheers, > Henry > I am running: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 14:54:55 UTC 2017 r...@releng3.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 kldstats 101 0x85e89000 806 msdosfs_iconv.ko 111 0x85e8a000 4633 libiconv.ko Can you list out the steps that you followed? I know that if I first run the mount command as root; I can then mount and unmount as regular user. If I try to mount with that -L flag msdosfs_iconv complains at me. ___ 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: msdosfs_iconv
On Sun, Jan 14, 2018 at 1:39 PM, Henry Hu wrote: > > > On Sun, Jan 14, 2018 at 12:20 AM, blubee blubeeme > wrote: > >> >> >> On Sun, Jan 14, 2018 at 12:16 PM, Henry Hu wrote: >> >>> >>> >>> On Sat, Jan 13, 2018 at 10:56 PM, blubee blubeeme >>> wrote: >>> >>>> >>>> >>>> On Sun, Jan 14, 2018 at 11:53 AM, Henry Hu >>>> wrote: >>>> >>>>> >>>>> >>>>> On Sat, Jan 13, 2018 at 9:10 PM, blubee blubeeme >>>>> wrote: >>>>> >>>>>> This is a repost from freebsd-question; Hoping to get more exposure >>>>>> and >>>>>> help here. >>>>>> >>>>>> I am trying to run mount_msdosfs with the option to set locale like >>>>>> this: >>>>>> mount_msdosfs -L en_US.UTF-8 /dev/da0s1 $HOME/usb >>>>>> >>>>>> This returns operation not permitted. >>>>>> >>>>>> usrmount is set to 1 and everything mounts as expected w/o root if I >>>>>> remove >>>>>> the locale option. The problem here is that my document filenames are >>>>>> garbled and I can't actually open the files. >>>>>> >>>>>> kiconvtool: https://wiki.freebsd.org/DmitryMarakasov/kiconvtool >>>>>> is said to work but it does not, after installing it I still get the >>>>>> exact >>>>>> same error. >>>>>> >>>>>> Have you tried to kldload msdosfs_iconv first? >>>>> >>>>> Is there a way to set locale when using mount_msdosfs without sudo? >>>>>> ___ >>>>>> freebsd-current@freebsd.org mailing list >>>>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>>>>> reebsd.org" >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Cheers, >>>>> Henry >>>>> >>>> Yes, /etc/rc.conf has this line: >>>> kld_list="nvidia-modeset msdosfs_iconv" >>>> >>>> >>> I just tried that and it works. I can create filenames in Chinese on the >>> mounted drive. >>> The command I used: >>> >>> > mount_msdosfs -L zh_CN.UTF-8 /dev/da1p1 /tmp/y >>> >>> kernel modules: >>> >>> > kldstat | grep iconv >>> 303 0x8506e000 458f libiconv.ko >>> 331 0x8507a000 801 msdosfs_iconv.ko >>> >>> But I'm using 11.1-STABLE. Maybe something changed? >>> >>> -- >>> Cheers, >>> Henry >>> >> I am running: >> FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r326056: Tue Nov 21 >> 14:54:55 UTC 2017 r...@releng3.nyi.freebsd.org: >> /usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 >> >> kldstats >> 101 0x85e89000 806 msdosfs_iconv.ko >> 111 0x85e8a000 4633 libiconv.ko >> >> Can you list out the steps that you followed? >> >> I know that if I first run the mount command as root; I can then mount >> and unmount as regular user. >> >> If I try to mount with that -L flag >> msdosfs_iconv complains at me. >> > > I just inserted a USB drive, and created /tmp/y for testing, which is > owned by my user. I can access /dev/da1p1 as my user. > > Do you mean that if you have mounted & unmounted as root once, you can > mount as regular user? > Maybe that changes something, like loaded a kernel module? Maybe you can > compare kldstat output? > > -- > Cheers, > Henry > if you first run the mount_msdosfs command as root, it'll load the locale settings just fine. If you logout or reboot and try to call mount_msdosfs -L [locale] as a regular user; The command will fail. ___ 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: Periodical interrupt storm when playing game with USB keyboard
On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd wrote: > Hi > > Yeah the timers eventually get coalesced unless someone's asking for a > ridciulously accurate timer value. > > So is some driver asking for hyper-accurate callout timer that isn't > being coalesced? hps, is there any useful debugging to try and find > callouts that are requesting stupidly accurate timers? Maybe a dtrace > probe on the callout schedule entry point? > > > > -adrian > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I'd say dtrace might be able to get you in the right direction very quickly. I used SDL in the past for android apps and the code is very Linux specific. I am sure there's some Linux related timers in there somewhere that FreeBSD is returning nothing from and that's what's killing the performance. I can almost guarantee that none of the SDL designers and or programmers use any *BSD systems. The easiest solution would be to go look at the timer code and implement something that FreeBSD can work with and try to get that upstream. These are just a few of the issues that will crop up when devs try to just use shims to hook into the Linux kernel. Do the design work up front and implement things in a native way or enjoy the jank. DTrace should be able to point you in the right direction relatively quickly. The DTraceBook: https://www.amazon.com/DTrace-Dynamic-Tracing-Solaris-FreeBSD/dp/0132091518 Best ___ 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: Periodical interrupt storm when playing game with USB keyboard
78 > kernel`bcopy 90 > i915kms.ko`fw_domains_get 228 > kernel`spinlock_exit284 > kernel`cpu_idle4698 > kernel`acpi_cpu_idle 36288 > > > I also tried rebuilding linux-c6_sdl-1.2 using get time functions in librt > vs libc but no difference. > Will dig deeper next time I have free time to spare. > > > > On Tue, Jan 23, 2018 at 2:33 AM, blubee blubeeme > wrote: > >> >> >> On Tue, Jan 23, 2018 at 9:48 AM, Adrian Chadd >> wrote: >> >>> Hi >>> >>> Yeah the timers eventually get coalesced unless someone's asking for a >>> ridciulously accurate timer value. >>> >>> So is some driver asking for hyper-accurate callout timer that isn't >>> being coalesced? hps, is there any useful debugging to try and find >>> callouts that are requesting stupidly accurate timers? Maybe a dtrace >>> probe on the callout schedule entry point? >>> >>> >>> >>> -adrian >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>> reebsd.org" >>> >> I'd say dtrace might be able to get you in the right direction very >> quickly. >> >> I used SDL in the past for android apps and the code is very Linux >> specific. I am sure there's some Linux related timers in there somewhere >> that FreeBSD is returning nothing from and that's what's killing the >> performance. >> >> I can almost guarantee that none of the SDL designers and or programmers >> use any *BSD systems. >> >> The easiest solution would be to go look at the timer code and implement >> something that FreeBSD can work with and try to get that upstream. >> >> These are just a few of the issues that will crop up when devs try to >> just use shims to hook into the Linux kernel. Do the design work up front >> and implement things in a native way or enjoy the jank. >> >> DTrace should be able to point you in the right direction relatively >> quickly. >> The DTraceBook: https://www.amazon.com/DTrace-Dynamic-Tracing- >> Solaris-FreeBSD/dp/0132091518 >> >> Best >> > > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Fatal trap 12
On Sat, May 26, 2018, 19:52 Manuel Stühn wrote: > Since upgrading my Lenovo T450 from r333740 to r334167 I'm experiencing > several "Fatal traps 12". Before the update i did not have any of those. > In all cases the traps occured some time after resume. > > Below there is some output found in /var/crash/core.txt > > __curthread () at ./machine/pcpu.h:231 > 231 ./machine/pcpu.h: No such file or directory. > (kgdb) #0 __curthread () at ./machine/pcpu.h:231 > #1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:366 > #2 0x80b9a6f0 in kern_reboot (howto=260) > at /usr/src/sys/kern/kern_shutdown.c:446 > #3 0x80b9ab83 in vpanic (fmt=, > ap=0xfe0056507e50) > at /usr/src/sys/kern/kern_shutdown.c:863 > #4 0x80b9a973 in panic (fmt=) > at /usr/src/sys/kern/kern_shutdown.c:790 > #5 0x80ba5c3b in kdb_switch () at > /usr/src/sys/kern/kern_synch.c:377 > #6 0x80ba5bb9 in mi_switch (flags=, newtd=0x0) > at /usr/src/sys/kern/kern_synch.c:406 > #7 0x80bf3f5f in sleepq_timedwait (wchan=, > pri=) at /usr/src/sys/kern/subr_sleepqueue.c:727 > #8 0x833c7bed in linux_add_to_sleepqueue > (wchan=0xf8000bf6ad80, task=0xf8000bf6ad80, wmesg= out>, timeout=50, state=) > at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:70 > #9 0x833c7a58 in linux_wait_event_common (wqh=, > wq=, timeout=50, state=2, lock=0x0) > at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:270 > #10 0x83458de6 in ?? () > #11 0x00061d026200 in ?? () > #12 0x0006 in ?? () > #13 0xf8000bf6ad80 in ?? () > #14 0x833c7540 in ?? () > at /usr/src/sys/compat/linuxkpi/common/src/linux_schedule.c:167 >from /boot/kernel/linuxkpi.ko > #15 0xf80007804828 in ?? () > #16 0xf80007804828 in ?? () > #17 0x0030 in ?? () > #18 0x in ?? () > (kgdb) > > > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x3 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80cc60cb > stack pointer = 0x28:0xfe0056508560 > frame pointer = 0x28:0xfe0056508760 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 10218 (nextcloud) > -- > Fatal trap 12: page fault while in kernel mode > cpuid = 1; apic id = 01 > fault virtual address = 0x30011 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80cc60cb > stack pointer = 0x28:0xfe005e4d1560 > frame pointer = 0x28:0xfe005e4d1760 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 17918 (DNS Resolver #16) > -- > Fatal trap 12: page fault while in kernel mode > cpuid = 3; apic id = 03 > fault virtual address = 0x3 > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x80cc60cb > stack pointer = 0x28:0xfe0056508560 > frame pointer = 0x28:0xfe0056508760 > code segment= base 0x0, limit 0xf, type 0x1b > = DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags= interrupt enabled, resume, IOPL = 0 > current process = 10218 (nextcloud) > > If there is any other information i can provide for solving this, please > let me know. > > -- > Manuel > ___ > 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" > Aren't you the guy using the drm-kmod if yes, your custom complied kernel and not the default kernel causing those issues. Best, Owen > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
OSS loopback device
Cross post; FreeBSD-[questions | current | ultimedia] Where's the midi loopback device in the FreeBSD OSS implementation? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Fri, Jun 1, 2018, 07:42 Oliver Pinter wrote: > On Friday, June 1, 2018, Pete Wright wrote: > > > > > > > On 05/31/2018 15:34, Oliver Pinter wrote: > > > >> On Thursday, May 31, 2018, Johannes Lundberg > wrote: > >> > >> On Thu, May 31, 2018 at 4:34 PM Joe Maloney > >>> wrote: > >>> > >>> I personally wish that more drivers, and firmware were separated from > base. > > > I'm not a committer > >>> > >> > >> > >>> If you are not a committer, how and why want to remove drm2 from the > >> base > >> system? > >> > > Johannes did not start this threat. A committer, Niclas Zeising, did. > > Johannes has stepped up and done a ton of work (along with many others, > > some committers and some not) to get modern intel and amd GPU's working > > under freebsd. > > > > > True. Yes I agree that their work is hard and it's a very big step forward > for supporting modern hardwares. And it's required modern desktops, but > please don't break the existing ones. Agreed This is my only request, probably it > was expressed in a harsh way, sorry. > > > > > > > > > this was something that was a gaping hole in freebsd when this work > > started a bit over a year ago, and i'm not sure why more committers > weren't > > embarrassed by this gap nor motivated to chip in. > > > > regardless - not sure why you'd take his comment out of context :/ the > > full quote was: > > "I'm not a committer but as I understand there's not pre-commit > > integration tests.. If one had that, plus that it would test build kmod > > ports against the pre-commit state of head as well, then maybe this would > > work." > > > > not really sure what's controversial about that statement which would > > prompt your reply - but i guess people dedicating their spare time to > help > > create useful things for others shouldn't go unpunished. > > > > well i guess i broke my promise to ignore this bikeshed :( > > > > -p > > > > -- > > Pete Wright > > p...@nomadlogic.org > > @nomadlogicLA > > > > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Proper way to remove never used ioctls
On Sun, Jun 3, 2018, 02:34 Vladimir Kondratyev wrote: > On 2018-06-02 20:36, Allan Jude wrote: > > On 2018-06-02 11:03, Warner Losh wrote: > >> On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev > >> > >> wrote: > >> > >>> Hi, > >>> > >>> Our sys/mouse.h header has a definition of MOUSE_GETVARS and > >>> MOUSE_SETVARS > >>> ioctls which are not documented and only stubbed in a few drivers: > >>> mse(4), > >>> psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS > >>> implemented in psm(4) > >>> > >>> Given the fact that they were introduced 20 years ago, implementation > >>> was > >>> never completed and googling on them shows no traces of usage in > >>> indexed > >>> universe, is it acceptable to just drop both defines and > >>> implementation > >>> w.o. leaving any COMPAT_FREEBSD shims? > >> > >> > >> I'd prepare a patch just removing them. I'd then send that patch to > >> the > >> ports mgr team and request a exp-run. Details for that can be found in > >> > https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ports.html > >> > >> Once that's done, submit a Phabricator review and send me email. I'll > >> make > >> sure it gets pushed in if there's no objections. > >> > >> Warner > > > > This indeed seems to be the correct approach. The exp-run will compile > > the entire ports tree against the patched base system, and identify any > > 3rd party software that fails to compile because of the change. > > Thank you, Allan and Warner! I'll follow yours advice. > > -- > WBR > Vladimir Kondratyev > ___ > 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" > This was great information. > ___ 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: RiscV tinderbox fails
It seems to be that the FreeBSD implementation of the RISC-V has stalled and development is only proceeding on Linux with GCC. In my opinion FreeBSD forget GCC and work on implementing RISC-V backend for the llvm project. On Sat, Jun 30, 2018, 08:18 Dimitry Andric wrote: > On 29 Jun 2018, at 13:33, hartmut.bra...@dlr.de wrote: > > > > is it supposed not to fail? I get: > > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__gedf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:101: multiple > definition > > of `__gedf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gedf2.o):/usr/src/lib/libc/s > > oftfloat/gedf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__eqdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__eqdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(eqdf2.o):/usr/src/lib/libc/s > > oftfloat/eqdf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__ltdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__ltdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(ltdf2.o):/usr/src/lib/libc/s > > oftfloat/ltdf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__nedf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:127: multiple > definition > > of `__nedf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(nedf2.o):/usr/src/lib/libc/s > > oftfloat/nedf2.c:18: first defined here > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libgcc.a(comparedf2.o): In > function > > `__gtdf2': > > /usr/src/contrib/compiler-rt/lib/builtins/comparedf2.c:142: multiple > definition > > of `__gtdf2' > > > /usr/obj/usr/src/riscv.riscv64sf/tmp/usr/lib/libc.a(gtdf2.o):/usr/src/lib/libc/s > > oftfloat/gtdf2.c:18: first defined here > > collect2: error: ld returned 1 exit status > > *** [nologin.full] Error code 1 > > As far as I know, it has been broken for quite some time. I guess for > riscv those functions need to be defined either in libc, or in > compiler-rt, but not both... > > -Dimitry > > ___ 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"
Make buildworld fails
Why am I getting these errors? error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] -- In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:477: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:796:29: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:802:32: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const wchar_t *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:808:33: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char16_t *__str, size_t __len) _NOEXCEPT ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string_view:814:33: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string_view operator "" sv(const char32_t *__str, size_t __len) _NOEXCEPT ^ In file included from /usr/src/usr.sbin/pmc/cmd_pmc_filter.cc:71: /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4046:24: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4052:27: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const wchar_t *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4058:28: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char16_t *__str, size_t __len ) ^ /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/string:4064:28: error: user-defined literal suffixes not starting with '_' are reserved [-Werror,-Wuser-defined-literals] basic_string operator "" s( const char32_t *__str, size_t __len ) ^ 8 errors generated. *** 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"
automake-wrapper conflicts
I am getting some build errors around automake-wrapper. I tried deinstalling automake-wrapper and then installing automake but then during the installation of automake I get this error: install-info: warning: no info dir entry in `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info' /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1' install -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1 doc/automake-1.16.1 '/usr/ports/devel/automake/work/stage/usr/local/man/man1' /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' install -m 0644 lib/Automake/Config.pm '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' /usr/bin/make install-data-hook chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver' chmod +x '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh' find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: No such file or directory > Compressing man pages (compress-man) ===> Installing for automake-1.16.1 ===> Checking if automake already installed ===> Registering installation for automake-1.16.1 Installing automake-1.16.1... pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 (installs files into the same place). Problematic file: /usr/local/bin/aclocal *** Error code 70 Is this just me or a bug? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: automake-wrapper conflicts
On Sat, Jul 28, 2018 at 10:41 AM blubee blubeeme wrote: > I am getting some build errors around automake-wrapper. > > I tried deinstalling automake-wrapper and then installing automake but > then during the installation of automake I get this error: > > install-info: warning: no info dir entry in > `/usr/ports/devel/automake/work/stage/usr/local/info/automake-history.info > ' > /bin/mkdir -p '/usr/ports/devel/automake/work/stage/usr/local/man/man1' > install -m 0644 doc/aclocal.1 doc/automake.1 doc/aclocal-1.16.1 > doc/automake-1.16.1 > '/usr/ports/devel/automake/work/stage/usr/local/man/man1' > /bin/mkdir -p > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' > install -m 0644 lib/Automake/Config.pm > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/Automake' > /usr/bin/make install-data-hook > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.guess' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/config.sub' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/install-sh' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mdate-sh' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/missing' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/mkinstalldirs' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ylwrap' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/depcomp' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/compile' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/py-compile' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/ar-lib' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/test-driver' > chmod +x > '/usr/ports/devel/automake/work/stage/usr/local/share/automake-1.16/tap-driver.sh' > find: /usr/ports/devel/automake/work/stage/usr/local/lib/perl5/site_perl: > No such file or directory > > Compressing man pages (compress-man) > ===> Installing for automake-1.16.1 > ===> Checking if automake already installed > ===> Registering installation for automake-1.16.1 > Installing automake-1.16.1... > pkg-static: automake-1.16.1 conflicts with automake-wrapper-20131203 > (installs files into the same place). Problematic file: > /usr/local/bin/aclocal > *** Error code 70 > > > Is this just me or a bug? > > Best, > Owen > Okay, seems that UPDATING addresses this issue! Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
SVN down or slow
Has anyone else noticed that svn is getting this type of error trying to run svn: svn: E65: Error running context: No route to host ___ 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"
#includes and #defined
What's the proper way to define and include FreeBSD amd64 in GNU Makefiles Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, FreeBSD__, or __FreeBSD I've seen all of the above looking through different projects. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: #includes and #defined
On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < freebsd.ed.li...@sumeritec.com> wrote: > Hi, > > On Fri, 10 Aug 2018 08:01:42 +0800 > blubee blubeeme wrote: > > > What's the proper way to define and include FreeBSD amd64 in GNU > > Makefiles > > > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, > > FreeBSD__, or __FreeBSD > > > > I've seen all of the above looking through different projects. > > clang defines '__FreeBSD__' > > Erich > What about the architecture name is it recommended to use x86_64 or amd64? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: #includes and #defined
On Fri, Aug 10, 2018 at 9:53 PM Warner Losh wrote: > > > On Thu, Aug 9, 2018 at 11:51 PM, Erich Dollansky < > freebsd.ed.li...@sumeritec.com> wrote: > >> Hi, >> >> On Fri, 10 Aug 2018 12:40:48 +0800 >> blubee blubeeme wrote: >> >> > On Fri, Aug 10, 2018 at 8:28 AM Erich Dollansky < >> > freebsd.ed.li...@sumeritec.com> wrote: >> > >> > > Hi, >> > > >> > > On Fri, 10 Aug 2018 08:01:42 +0800 >> > > blubee blubeeme wrote: >> > > >> > > > What's the proper way to define and include FreeBSD amd64 in GNU >> > > > Makefiles >> > > > >> > > > Do we define FreeBSD as x86_64 or amd64 also is it __FreeBSD__, >> > > > FreeBSD__, or __FreeBSD >> > > > >> > > > I've seen all of the above looking through different projects. >> > > >> > > clang defines '__FreeBSD__' >> > > >> > > Erich >> > > >> > >> > What about the architecture name is it recommended to use x86_64 or >> > amd64? >> >> my clang reports on an Intel CPU: >> >> #define __amd64 1 >> #define __amd64__ 1 >> #define __x86_64 1 >> #define __x86_64__ 1 >> >> as defined. >> >> It reports >> >> #define __aarch64__ 1 >> >> on an 64 bit ARM CPU. >> > > 'man 7 arch' will tell you these things: > >amd64 __amd64__, __x86_64__ > This is what I was looking for, thank you for the man page and it's good to see that these things are starting to get documented. > > it contains the preferred list of macros to use. Ideally, you'd use the > first one listed, though all the ones listed are supported. Others might > not be. > > Warner > Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
FreeBSD elf_machine_id
What's the elf_machine_id for FreeBSD amd64 systems? How can I find this info? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD elf_machine_id
On Sun, Aug 12, 2018 at 7:43 PM Dimitry Andric wrote: > On 12 Aug 2018, at 13:21, blubee blubeeme wrote: > > > > What's the elf_machine_id for FreeBSD amd64 systems? > > > > How can I find this info? > > There isn't any FreeBSD-specific machine ID, just a machine ID for > x86-64 (aka amd64) in general: > > $ grep x86-64 /usr/include/sys/elf_common.h > #define EM_X86_64 62 /* Advanced Micro Devices x86-64 */ > #define EM_AMD64EM_X86_64 /* Advanced Micro Devices x86-64 > (compat) */ > > -Dimitry > > Thank you for the clarification. I think in this case I was looking for 62. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: FreeBSD elf_machine_id
On Sun, Aug 12, 2018 at 9:59 PM blubee blubeeme wrote: > > > On Sun, Aug 12, 2018 at 7:43 PM Dimitry Andric wrote: > >> On 12 Aug 2018, at 13:21, blubee blubeeme wrote: >> > >> > What's the elf_machine_id for FreeBSD amd64 systems? >> > >> > How can I find this info? >> >> There isn't any FreeBSD-specific machine ID, just a machine ID for >> x86-64 (aka amd64) in general: >> >> $ grep x86-64 /usr/include/sys/elf_common.h >> #define EM_X86_64 62 /* Advanced Micro Devices x86-64 */ >> #define EM_AMD64EM_X86_64 /* Advanced Micro Devices x86-64 >> (compat) */ >> >> -Dimitry >> >> Thank you for the clarification. > > I think in this case I was looking for 62. > > Best, > Owen > Actually I had another quick question along these lines. if x86_64 is already defined should I bother changing those to amd64 or just use x86_64 and make FreeBSD modifications where Linux specifics are defined? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Executables with [ -def __linux__ ]
This is going out to both current and ports in hopes someone can offer some guidance on this issue. I'm porting some code that seems to want to have -def __linux__ when I run the executable with verbose output, take a look below -- -opt 0 -terse 1 -inform warn -nohpf -nostatic -inform warn -x 19 0x40 -quad -x 68 0x1 -x 59 4 -x 15 2 -x 49 0x44 -x 51 0x20 -x 57 0x4c -x 58 0x1 -x 124 0x1000 -tp px -x 57 0xfb -x 58 0x78031040 -x 47 0x08 -x 48 4608 -x 49 0x100 -def unix -def __unix -def __unix__ -def linux -def __linux -def __linux__ -def __NO_MATH_INLINES -def __LP64__ -def __x86_64 -def __x86_64__ -def __LONG_MAX__=9223372036854775807L -def __SIZE_TYPE__=unsigned long int -def __PTRDIFF_TYPE__=long int -def __THROW= -def __extension__= -def __amd_64__amd64__ -def __k8 -def __k8__ -def __PGLLVM__ -freeform -vect 48 -y 54 1 -x 70 0x4000 -y 163 0xc000 -x 189 0x10 -stbfile test-276576.stb -modexport test-276576.cmod -modindex test-276576.cmdx -output test-276576.ilm As you can see from above there's some -def linux, def __linux, etc.. FreeBSD isn't Linux and I'd like to better understand where these things are being set, it's a cmake project and I've grepped through a lot of the sources and can't really find where these flags are coming from. Any tips on finding where they are coming from and fixing them to reflect the correct platform information? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Sharing compiled builds between multiple 12-CURRENT boxes.
On Sun, Aug 19, 2018 at 6:30 PM O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sun, 19 Aug 2018 00:34:20 +0200 > Dhananjay Balan schrieb: > > > Hi, > > > > I run 12-CURRENT on few machines, some more powerful that other (all > > of them x86_64, march varies). > > > > Is there is a way to avoid building CURRENT on all machines? Rather > > than building everywhere, can I just build it on the big server that I > > have and copy and update my laptop? > > > > - > > Dhananjay Balan > [...] > > Yes, you can. > We do this via a custom build and creating packages as this is introduced > at > > https://wiki.freebsd.org/PkgBase > > But beware! As many others have already stated, take care about to use the > least common > denominator of achitectural specifications amongst your pools! This means > to not use any > kind of optimizations for a specific CPU type for pkg-base distributed > builds! > > Because we build the local OS for fast/server machines always(!) with > optimisations, the > pkg-base builds are done in a separate way - which is very easy if you've > once understood > the really neat and great build framework of FreeBSD's! > > Instead of building the traditional (probably optimised) system from > /usr/src > and /usr/obj, now you've to consider a separate path like > /pool/sources/CURRENT/src (our > way, since we also try to build packages and object trees for 11.X), then > setup a small > build script that essentially sets > > MAKEOBJDIRPREFIX > KERNCONFDIR > KERNCONF > > and especially > > __MAKE_CONF > SRCCONF > SRC_ENV_CONF > > if you use usually optimisations for the native target build on the > building host and > more generic binaries for the Intel x86 crap for redistribution. > > Doing so, we also perform builds for some ARM64 based experimental boxes. > > The next step is then up to you how to distribute. We copy all the pkg > stuff coming out > of the build cycle to a folder which is accessible by pkg via HTTP(S) - so > www/apache24 > is our platform to redistribute the binaries over the network and even to > remote sites > (beware of the security implications!). You also can distribute the > obj-folder (/usr/obj, > or, if using another approach, like /pool/sources/CURRENT/obj) via NFS. > > Once you've understood the (easy to learn) concept of building the source > tree, creating > the packages for pkg-base and having dealt with the more labor for the > setting of a > distribution server, you can use the most potent server/box on you network > for building > dedicated distributions > > Even a "Release" build is possible as long as there are not pitfalls like > they occured > during the transition from 11.X to more 12-CURRENT spcific development > (i.e. LINT). > > If you use pkg-base as mentioned above, be aware to setup a proper > pkg.conf file as > introduced on the Wiki and please be also aware of the fact, that there is > at the moment > no sharp separation between pkg-base and oridnary pkg for packages - so > take the > warinig serious, that pkg delete -a will not only kill all packages, it > also will kill > all packages installed for the base system! > > Once installed you'll see how fast compared to source build the pkg-base > installation > is (although I still prefer source build, optimised builds ...). > > And by the way: depending on the sophistication of your build script for > dedicated > tree builds as mentioned, via manipulations of __MAKE_CONF, SRCCONF you're > able to also > build optimised binary trees for different CPU types, but you have to deal > yourself > with the fact that you've to put the binaries into a proper place and then > delegate the > URI in pkg.conf to the correct branch of your tree. The ABI environmental > variable > doesn't take care of the "set" you may have used to optimise. But this is > something > you're able to deal with easily yourself after having setup your basic > build > environment. > > Regards, > > oh > > - -- > O. Hartmann > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > -BEGIN PGP SIGNATURE- > > iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCW3lGDwAKCRDS528fyFhY > lMBeAf4nVIFEAgegbZyKDZvTQQD/9Q8mN+IY8aJ7Fzza23KgWQsM3ZP59Orh0mi2 > PA94ywn5hOjfTgzdYcp1lq3MCE84AgCBGAWAMTag87ru89JHm75NLsgDvEjPpYgG > 9hW1Vrdoj9EeiR2HTv2ncTc/AkFPNhdyhe+EJqUg01rtAd9sdmdM > =/rzO > -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" > I would say setup a poudriere build bot on your most powerful machine to build and test all the applications and tools that your weaker machines need, then setup a custom pkg repo so once poudriere builds all the ports and create packages from them. Then you use the custom pkg url to update your oth
What's this gregset_t gregs thing
Linux has gregset_t gregs; https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h Defined above, I also see it in the RISC-V glibc stuff as well. FreeBSD doesn't seem to have this field defined, I see FreeBSD uses /usr/include/x86/ucontext.h but there's no gregs; If I wanted to return mcontext.gregs How could I implement that on FreeBSD? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
building LLVM threads gets killed
I am running current compiling LLVM60 and when it comes to linking basically all the processes on my computer gets killed; Chrome, Firefox and some of the LLVM threads as well I am using ninja which is a little better but gmake or make are a lot worse. uname -a: FreeBSD blubee 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r336196: Wed Jul 11 21:52:50 CST 2018 root@blubee:/usr/obj/usr/src/amd64.amd64/sys/GENERIC amd64 me@blubee:~ % uname -K 1200072 me@blubee:~ % uname -U 1200072 building with -j1 still crashes and burns. Basically everything on my machine gets killed. This machine has sysctl hw.physmem hw.physmem: 34246332416 last pid: 20965; load averages: 0.64, 5.79, 7.73 up 12+01:35:46 11:00:36 76 processes: 1 running, 75 sleeping CPU: 0.8% user, 0.5% nice, 1.0% system, 0.0% interrupt, 98.1% idle Mem: 10G Active, 3G Inact, 100M Laundry, 13G Wired, 6G Free ARC: 4G Total, 942M MFU, 1G MRU, 1M Anon, 43M Header, 2G Other 630M Compressed, 2G Uncompressed, 2.74:1 Ratio Swap: 2G Total, 1G Used, 739M Free, 63% Inuse llvm/build % ninja -j8 [2408/2473] Building CXX object lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes -I../lib/Passes -Iinclude -I../include -isystem /usr/local/include -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g-fno-exceptions -fno-rtti -MD -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c ../lib/Passes/PassBuilder.cpp c++: error: unable to execute command: Killed c++: error: clang frontend command failed due to signal (use -v to see invocation) FreeBSD clang version 6.0.1 (tags/RELEASE_601/final 335540) (based on LLVM 6.0.1) Target: x86_64-unknown-freebsd12.0 Thread model: posix InstalledDir: /usr/bin c++: note: diagnostic msg: PLEASE submit a bug report to https://bugs.freebsd.org/submit/ and include the crash backtrace, preprocessed source, and associated run script. c++: note: diagnostic msg: PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT: Preprocessed source(s) and associated run script(s) are located at: c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.cpp c++: note: diagnostic msg: /tmp/PassBuilder-1bff7b.sh c++: note: diagnostic msg: --- llvm/build % ninja -j8 [54/59] Linking CXX executable bin/opt FAILED: bin/opt : && /usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Werror=date-time -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -g -Wl,--color-diagnostics -Wl,-allow-shlib-undefined -Wl,--export-dynamic -Wl,-z,origin tools/opt/CMakeFiles/opt.dir/AnalysisWrappers.cpp.o tools/opt/CMakeFiles/opt.dir/BreakpointPrinter.cpp.o tools/opt/CMakeFiles/opt.dir/Debugify.cpp.o tools/opt/CMakeFiles/opt.dir/GraphPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/NewPMDriver.cpp.o tools/opt/CMakeFiles/opt.dir/PassPrinters.cpp.o tools/opt/CMakeFiles/opt.dir/PrintSCC.cpp.o tools/opt/CMakeFiles/opt.dir/opt.cpp.o -o bin/opt -L/usr/local/lib -Wl,-rpath,"\$ORIGIN/../lib" lib/libLLVMAArch64CodeGen.a lib/libLLVMAArch64AsmParser.a lib/libLLVMAArch64AsmPrinter.a lib/libLLVMAArch64Desc.a lib/libLLVMAArch64Disassembler.a lib/libLLVMAArch64Info.a lib/libLLVMAArch64Utils.a lib/libLLVMAMDGPUCodeGen.a lib/libLLVMAMDGPUAsmParser.a lib/libLLVMAMDGPUAsmPrinter.a lib/libLLVMAMDGPUDesc.a lib/libLLVMAMDGPUDisassembler.a lib/libLLVMAMDGPUInfo.a lib/libLLVMAMDGPUUtils.a lib/libLLVMARMCodeGen.a lib/libLLVMARMAsmParser.a lib/libLLVMARMAsmPrinter.a lib/libLLVMARMDesc.a lib/libLLVMARMDisassembler.a lib/libLLVMARMInfo.a lib/libLLVMARMUtils.a lib/libLLVMBPFCodeGen.a lib/libLLVMBPFAsmParser.a lib/libLLVMBPFAsmPrinter.a lib/libLLVMBPFDesc.a lib/libLLVMBPFDisassembler.a lib/libLLVMBPFInfo.a lib/libLLVMHexagonCodeGen.a lib/libLLVMHexagonAsmParser.a lib/libLLVMHexagonDesc.a lib/libLLVMHexagonDisassembler.a lib/libLLVMHexagonInfo.a lib/libLLVMLanaiCodeGen.a lib/libLLVMLanaiAsmParser.a lib/libLLVMLanaiAsmPrinter.a lib/libLLVMLanaiDesc.a lib/libLLVMLanaiDisassembler.a lib/libLLVMLanaiInfo.a lib/libLLVMMipsCodeGen.a lib/libLLVMMipsAsmParser.a lib/libLLVMMipsAsmPrinter.a lib/libLLVMMipsDesc.a lib/libLLVMMipsDisassembler.a lib/libLLVMMipsInfo.a lib/libLLVMMSP430CodeGen.a lib/libLLVMMSP430AsmPrinter.a
Re: building LLVM threads gets killed
On Mon, Aug 20, 2018 at 10:26 PM Rodney W. Grimes < freebsd-...@pdx.rh.cn85.dnsmgr.net> wrote: > > On 20 Aug 2018, at 05:01, blubee blubeeme wrote: > > > > > > I am running current compiling LLVM60 and when it comes to linking > > > basically all the processes on my computer gets killed; Chrome, > Firefox and > > > some of the LLVM threads as well > > ... > > > llvm/build % ninja -j8 > > > [2408/2473] Building CXX object > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes > -I../lib/Passes > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > -fvisibility-inlines-hidden -Werror=date-time > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > > -Wstring-conversion -fdiagnostics-color -g-fno-exceptions > -fno-rtti -MD > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > ../lib/Passes/PassBuilder.cpp > > > c++: error: unable to execute command: Killed > > > > It is running out of RAM while running multiple parallel link jobs. If > > you are building using WITH_DEBUG, turn that off, it consumes large > > amounts of memory. If you must have debug info, try adding the > > following flag to the CMake command line: > > > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > > > That will limit the amount of parallel link jobs to 1, even if you > > specify -j 8 to gmake or ninja. > > > > Brooks, it would not be a bad idea to always use this CMake flag in the > > llvm ports. :) > > And this may also fix the issues that all the small > memory (aka, RPI*) buliders are facing when trying > to do -j4? > > > -- > Rod Grimes > rgri...@freebsd.org Someone mentioned earlier that debug builds cause a lot of memory usage and it's true that I am building with debug. I couldn't grab the relevant text from top but the posted was after everything settled down. The memory situation got so bad that xserver died and I was booted to terminal. I saw ld.lld using up to 12GB of ram for each process, that will definitely use up 32GB of ram. I can't avoid building w/ debug symbols since I have to debug the program are there any other options other than building with only 1 thread? Reason being even when I set gmake -j1 the problem comes just a lot later during linking stage. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: What's this gregset_t gregs thing
On Mon, Aug 20, 2018 at 9:49 PM Shawn Webb wrote: > On Mon, Aug 20, 2018 at 08:33:04AM +0800, blubee blubeeme wrote: > > Linux has gregset_t gregs; > > > https://github.com/lattera/glibc/blob/master/sysdeps/unix/sysv/linux/x86/sys/ucontext.h > > Please note that that repo is hopelessly old and out-of-date. I > created it as a mirror of the official glibc repo because I was doing > some offensive research against GNU's RTLD way back in 2011-2012. The > repo hasn't been updated since. > > Thanks, > > -- > Shawn Webb > Cofounder and Security Engineer > HardenedBSD > > Tor-ified Signal:+1 443-546-8752 > Tor+XMPP+OTR:latt...@is.a.hacker.sx > GPG Key ID: 0x6A84658F52456EEE > GPG Key Fingerprint: 2ABA B6BD EF6A F486 BE89 3D9E 6A84 658F 5245 6EEE > Thanks for all the replies, I think OSX also lacks this gregs_t thing as well I was able to lock it up behind some ifdefs and all is well. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
soundcard.h expose device block size
I'm looking at FreeBSD's soundcard.h and it doesn't seem to expose the hardware block size, this seems like a limitation stemming from FreeBSD's soundcard.h being an extension of OSS. Since we've already implemented a lot of additional features on top of the OSS API, is it possible to also expose the hardware block size for applications that might need access to that information? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: building LLVM threads gets killed
On Mon, Aug 20, 2018 at 11:04 PM Mark Millard wrote: > Rodney W. Grimes freebsd-rwg at pdx.rh.CN85.dnsmgr.net wrote on > Mon Aug 20 14:26:55 UTC 2018 : > > > > On 20 Aug 2018, at 05:01, blubee blubeeme > wrote: > > > > > > > > I am running current compiling LLVM60 and when it comes to linking > > > > basically all the processes on my computer gets killed; Chrome, > Firefox and > > > > some of the LLVM threads as well > > > ... > > > > llvm/build % ninja -j8 > > > > [2408/2473] Building CXX object > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > FAILED: lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o > > > > /usr/bin/c++ -DGTEST_HAS_RTTI=0 -D_DEBUG -D__STDC_CONSTANT_MACROS > > > > -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Ilib/Passes > -I../lib/Passes > > > > -Iinclude -I../include -isystem /usr/local/include -fPIC > > > > -fvisibility-inlines-hidden -Werror=date-time > > > > -Werror=unguarded-availability-new -std=c++11 -Wall -Wextra > > > > -Wno-unused-parameter -Wwrite-strings -Wcast-qual > > > > -Wmissing-field-initializers -pedantic -Wno-long-long > > > > -Wcovered-switch-default -Wnon-virtual-dtor -Wdelete-non-virtual-dtor > > > > -Wstring-conversion -fdiagnostics-color -g-fno-exceptions > -fno-rtti -MD > > > > -MT lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -MF > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o.d -o > > > > lib/Passes/CMakeFiles/LLVMPasses.dir/PassBuilder.cpp.o -c > > > > ../lib/Passes/PassBuilder.cpp > > > > c++: error: unable to execute command: Killed > > > > > > It is running out of RAM while running multiple parallel link jobs. If > > > you are building using WITH_DEBUG, turn that off, it consumes large > > > amounts of memory. If you must have debug info, try adding the > > > following flag to the CMake command line: > > > > > > -D LLVM_PARALLEL_LINK_JOBS:STRING="1" > > > > > > That will limit the amount of parallel link jobs to 1, even if you > > > specify -j 8 to gmake or ninja. > > > > > > Brooks, it would not be a bad idea to always use this CMake flag in the > > > llvm ports. :) > > > > And this may also fix the issues that all the small > > memory (aka, RPI*) buliders are facing when trying > > to do -j4? > > It may help, but: > > Even just compiles with no links running can get the kills > in such small system contexts. > > And going for a simpler context that can demonstrate > the behavior . . . > > Taking a Pine64+ 2GB as an example (4 cores with 1 > HW-thread per core, 2 GiBytes of RAM, USB device for > root file system and swap partition): > > In another login: > # stress -d 2 -m 4 --vm-keep --vm-bytes 536870912 > > That "4" and "536870912" total to the 2 GiBytes so > swapping is induced for the context in question. > (Scale --vm-bytes appropriately to context.) > [Note: I had 3 GiBytes of swap space in a partition > for the below.] > > [stress is from the port sysutils/stress .] > > I had left the default vm.pageout_oom_seq=12 in place for this, > making the kills easier to get than the 120 figure would. It > does not take very long generally for some sort of message to > show up. Sometimes kills happen: > > My test environment has Mark Johnston patches to report > things not normally reported: > > waited 9s for async swap write > waited 9s for swap buffer > waited 9s for async swap write > waited 9s for async swap write > waited 9s for async swap write > v_free_count: 1357, v_inactive_count: 1 > Aug 20 06:04:27 pine64 kernel: pid 1010 (stress), uid 0, was killed: out > of swap space > waited 5s for async swap write > waited 5s for swap buffer > waited 5s for async swap write > waited 5s for async swap write > waited 5s for async swap write > waited 13s for async swap write > waited 12s for swap buffer > waited 13s for async swap write > waited 12s for async swap write > waited 12s for async swap write > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 161177, size: 131072 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164766, size: 65536 > swap_pager: indefinite wait buffer: bufobj: 0, blkno: 164064, size: 12288 > . . . > > (I made multiple runs, most manually stopped. None run for > all that long.) > > (Warning: the swap space part of "killed: out of swap space" > can be a misnomer. Killing is driven by having low free RAM > for
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > > > On Fri, Aug 24, 2018 at 14:53 Ali wrote: > > > > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > > > > Just in case anyone misses the change to UPDATING: > > > > > > > > 20180821: > > > > drm and drm2 have been removed. Users on powerpc, 32-bit > > > hardware, > > > > or with GPUs predating Radeon and i915 will need to install > the > > > > graphics/drm-legacy-kmod. All other users should be able to > use > > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. > > > > Note that this applies only to 12. > > > > > > I see that The removal of drm and drm2 has been reverted on svn. Could > > > you please kindly share the reasons behind the re-inclusion? > > > > > > > > > I can’t really give the blow by blow of internal project drama, but the > > gist of it is that “best practices” (which are not yet actually > documented > > anywhere that I’ve seen) were not followed with regards to the > deprecation > > process. Warner and others believe that we can address the objectives of > > the drm removal (improving the user experience and communicating that > > drm/drm2 are _completely_ unsupported apart from continuing to compile) > > through less disruptive means. > > > > Just so. > > Our only continued frustration is that we were never given any guidance by > > RE or core on said “best practices” when the discussion was taking place > in > > May and then those groups behaved as if this were a surprise when the > > removal happened. I’m cautiously optimistic that this well expedite > > improving communications on those matters. > > > > All the problems that are exposed by this aren't technical. This one is > social, but no less important. > > Warner > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I've been watching this debacle for quite some time now and I'd just like to ask why the rush? The graphics team is working very hard to destroy the stability of FreeBSD just so that they can force their uncooked work down users throats. The Linuxkpi is unstable at best, alpha level software that's constantly in need of someone to go and fix something on FreeBSD because Linux devs decided to make some changes or implement a new feature. This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. Are these guys insane and please avoid the nonsense about you're doing this in your spare time. If you cannot devote the resources to do something right then don't do it at all. Keep that stuff in to yourself or anyone crazy enough to follow those steps to get it up and running, you guys cannot expect to contaminate the entire FreeBSD project for this mess. This is nonsense and I hope that more people who see it as such would say so and stop having these guys forcing this crap; it's maintenance hell who will maintain it if they decide to leave? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > On 8/24/18 7:07 PM, blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: > > > >> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: > >> > >>> On Fri, Aug 24, 2018 at 14:53 Ali wrote: > >>> > >>>> On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: > >>>>> Just in case anyone misses the change to UPDATING: > >>>>> > >>>>> 20180821: > >>>>> drm and drm2 have been removed. Users on powerpc, 32-bit > >>>> hardware, > >>>>> or with GPUs predating Radeon and i915 will need to install > >> the > >>>>> graphics/drm-legacy-kmod. All other users should be able to > >> use > >>>>> one of the LinuxKPI-based ports: graphics/drm-stable-kmod, > >>>>> graphics/drm-next-kmod, graphics/drm-devel-kmod. > >>>>> Note that this applies only to 12. > >>>> I see that The removal of drm and drm2 has been reverted on svn. Could > >>>> you please kindly share the reasons behind the re-inclusion? > >>>> > >>> > >>> I can’t really give the blow by blow of internal project drama, but the > >>> gist of it is that “best practices” (which are not yet actually > >> documented > >>> anywhere that I’ve seen) were not followed with regards to the > >> deprecation > >>> process. Warner and others believe that we can address the objectives > of > >>> the drm removal (improving the user experience and communicating that > >>> drm/drm2 are _completely_ unsupported apart from continuing to compile) > >>> through less disruptive means. > >>> > >> Just so. > >> > >> Our only continued frustration is that we were never given any guidance > by > >>> RE or core on said “best practices” when the discussion was taking > place > >> in > >>> May and then those groups behaved as if this were a surprise when the > >>> removal happened. I’m cautiously optimistic that this well expedite > >>> improving communications on those matters. > >>> > >> All the problems that are exposed by this aren't technical. This one is > >> social, but no less important. > >> > >> Warner > >> ___ > >> freebsd-current@freebsd.org mailing list > >> https://lists.freebsd.org/mailman/listinfo/freebsd-current > >> To unsubscribe, send any mail to " > freebsd-current-unsubscr...@freebsd.org" > >> > > I've been watching this debacle for quite some time now and I'd just like > > to ask why the rush? > > > > The graphics team is working very hard to destroy the stability of > FreeBSD > > just so that they can force their uncooked work down users throats. > > > > The Linuxkpi is unstable at best, alpha level software that's constantly > in > > need of someone to go and fix something on FreeBSD because Linux devs > > decided to make some changes or implement a new feature. > > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > >- Move DRM headers to a similar location as Linux > >- > > > >Use kmalloc() instead of malloc(9) > >- Use kref > >- > > > >Use idr and get rid of drm_gem_names.c > >- Use PCI API > >- Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > > > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > > > If you cannot devote the resources to do something right then don't do it > > at all. > > > > Keep that stuff in to yourself or anyone crazy enough to follow those > steps > > to get it up and running, you guys cannot expect to contaminate the > entire > > FreeBSD project for this mess. > > > > This is nonsense and I hope that more people who see it as such would say > > so and stop having these guys forcing this crap; it's maintenance hell > who > > will maintain it if they decide to leave? > > > > Best, > > Owen > > ___ > > freebsd-current@freebsd.org mailing list > > https://lists.freebsd.org
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 8:40 AM Pete Wright wrote: > > > On 8/24/18 4:07 PM, blubee blubeeme wrote: > > > This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM > > Goals > > > > - Move DRM headers to a similar location as Linux > > - > > > > Use kmalloc() instead of malloc(9) > > - Use kref > > - > > > > Use idr and get rid of drm_gem_names.c > > - Use PCI API > > - Use Linux locking primitives > > > > is garbage, if you want to use develop Linux code and use Linux then go > do > > that on Linux. > having a hard time not feeding the troll here...but what specifically is > garbage. as in, what implementation of all this work do you have > available that has been developed independently which also enables > support for modern desktop and portable systems that you can buy today? > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > The idea that FreeBSD relax it's standards just so that some devs have an easier time bringing up a half baked idea is nonsense. Let's take power management, after you guys do all this work to get the graphics card working how much of devd will you need to implement to get that working properly? I don't understand why this concept seems so hard to grasp but FreeBSD is not Linux why are some people continually trying to turn it into some Frankenstein thing. If you guys consider yourself developers then do what developers do and solve problems with constraints, if you cannot accomplish that stop pushing these breaking changes. None of these kmod guys seems to have put any thought into long term maintenance of this project. Look at the mailing list, every few days there's some breaking changes waiting for patches because something changed in Linux-land... If you can't solve the problem in a maintainable way, you will just create bigger problems for developers down the line. Until you guys have something that's at least as stable as what's available now, keep working on it. Some people take pride in their work and deliver a working product, they don't need to twist peoples arms into getting their way. speaking as someone who's been working on this from pretty much the day > of the initial CFT (maybe before?) - i don't know anyone who's getting > paid for this specific work. at least when it comes to GPU support. > but, if you have the means, I'd love to work on this full time and am > open to any serious offers :) > > -pete > I'd hope you have something more compelling than [http://nomadlogic.org] as your calling card. -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 10:04 AM Mark Linimon wrote: > On Sat, Aug 25, 2018 at 07:07:24AM +0800, blubee blubeeme wrote: > > Are these guys insane and please avoid the nonsense about you're doing > this > > in your spare time. > > Let us know how whatever OS you wind up using instead works for you. > I suggest you look for one that will put up with your constant harangues. > > There are very few people on the mailing lists as nasty and rude as > yourself. It is tiresome, demotivating, and childish. Please go > elsewhere. > > mcl > Your opinion has been noted but this issue isn't about me. It's about the Graphics devs coding themselves into a corner and looking for an easy button so they can continue to feel good about their toy. There's a reason the changes they tried to force down the FreeBSD source tree was reverted; It does not meet any standards of quality. I have no inside knowledge other than my ability to think clearly and it's obvious that The FreeBSD team wanted to hint at them that their code doesn't pass the sniff test. Instead of being whiny brats improve your code and have it work without breaking compatibility with what has been working for quite a long time. Here's the play by play; You guys push this mess contaminating the FreeBSD source tree, some long standing user tries to update their machines and it blows up; 1) Most will just leave 2) Some will complain 2a) You guys will say; Read UPDATING. bleh bleh blen They'll get aggravated, thereby aggravating people who came to this platform for Stability. Users who actually use FreeBSD to get things done do not time to trawl these mailing lists, they have real world problems to solve with real world constraints. There are OS with kqueue and all those things it's called Linux; You can go there and play w/ that stuff to your hearts content. If you want your code to get merged, make sure it follows the guidelines and not break the systems for people who are already using the platform. Now, I understand hearing harsh criticism about your work might hurt your feelings and all but here's the antidote; work harder, improve your code, try again when your code quality improves. You guys cannot expect people to accept these kludges in their systems that they run everyday. It's an open source project, you can't get mad because your code isn't accepted, it's your jobs and engineers to do better not expect users to jump through hoops to accommodate your subpar attempts at coding. This isn't about me, it's about the quality of code that you guys are trying to submit. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 4:27 PM Matthew Macy wrote: > Hi Owen - > I understand that you're enthusiastic and you just want what's best for > the project. However, there's a couple of points I hope you'll take to > heart. First, please read what you sent and think about the tone and word > choice. It's extremely negative and critical - you're actively alienating > people on the list. You're not going to be successful engaging any open > source community or workplace if you choose to communicate like this. > Second, this is a volunteer project. One needs to establish a track record > of producing patches and working with developers to get them committed. > Regardless of how sound your technical position is - you're going to have a > hard time being acknowledged if there is no contribution to match. > > Best wishes. > -M > True on both points my tone is just a reflection of attitudes of the individuals that I am currently addressing. Some people enjoy making contributions w/o waving a banner constantly wanting acknowledgement, a pat on the head and good job from everyone. How far will core FreeBSD bend over backwards to accommodate these devs. Their project is half baked at best and sure it works; sorta if the moon is just right. This is the beauty of an open source project, we bring the best to the table, not rip off two legs only to glue them back on later just slightly askew. This isn't a world where everyone gets a gold star, people fail even if they work very hard, failure is still an option. I guess the most important question to ask is what's the standards that the FreeBSD Foundation want to represent, uphold, and maintain? > > > On Fri, Aug 24, 2018 at 4:07 PM blubee blubeeme > wrote: > >> >> >> On Sat, Aug 25, 2018 at 6:26 AM Warner Losh wrote: >> >>> On Fri, Aug 24, 2018 at 4:20 PM Matthew Macy wrote: >>> >>> > On Fri, Aug 24, 2018 at 14:53 Ali wrote: >>> > >>> > > On Tue, Aug 21, 2018 at 06:54:54PM -0700, Matthew Macy wrote: >>> > > > Just in case anyone misses the change to UPDATING: >>> > > > >>> > > > 20180821: >>> > > > drm and drm2 have been removed. Users on powerpc, 32-bit >>> > > hardware, >>> > > > or with GPUs predating Radeon and i915 will need to >>> install the >>> > > > graphics/drm-legacy-kmod. All other users should be able >>> to use >>> > > > one of the LinuxKPI-based ports: graphics/drm-stable-kmod, >>> > > > graphics/drm-next-kmod, graphics/drm-devel-kmod. >>> > > > Note that this applies only to 12. >>> > > >>> > > I see that The removal of drm and drm2 has been reverted on svn. >>> Could >>> > > you please kindly share the reasons behind the re-inclusion? >>> > > >>> > >>> > >>> > I can’t really give the blow by blow of internal project drama, but the >>> > gist of it is that “best practices” (which are not yet actually >>> documented >>> > anywhere that I’ve seen) were not followed with regards to the >>> deprecation >>> > process. Warner and others believe that we can address the objectives >>> of >>> > the drm removal (improving the user experience and communicating that >>> > drm/drm2 are _completely_ unsupported apart from continuing to compile) >>> > through less disruptive means. >>> > >>> >>> Just so. >>> >>> Our only continued frustration is that we were never given any guidance >>> by >>> > RE or core on said “best practices” when the discussion was taking >>> place in >>> > May and then those groups behaved as if this were a surprise when the >>> > removal happened. I’m cautiously optimistic that this well expedite >>> > improving communications on those matters. >>> > >>> >>> All the problems that are exposed by this aren't technical. This one is >>> social, but no less important. >>> >>> Warner >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to " >>> freebsd-current-unsubscr...@freebsd.org" >>> >> >> I've been watching this debacle for quite some time now and I'd just like >> to ask why the rush? >> >> The graphics t
Re: drm / drm2 removal in 12
On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen wrote: > blubee blubeeme wrote: > > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > >> I've been personally using the new DRM bits since almost day one. I > >> haven't found it to be unstable in the slightest. Compared to not > >> having it and being forced to run 5+ year old hardware, it's been a > >> huge blessing for those of us who care about running FreeBSD as a > >> modern desktop / laptop. > >> > >> FreeBSD being an open source project, you are welcome to contribute > >> back your work anytime. But since I don't imagine we'll see that > >> patch coming anytime soon, I'll stick with this new LinuxKPI-powered, > >> Plasma-desktop running awesomeness. > >> > >> (Written from my brand new Lenovo P71 which worked flawlessly out of > >> box) > > > > Please tell me more about you're modern hardware, Kris Vice President > > of Engineering at iXsystems. > > > > Try asking a person who doesn't run server infrastructure software and > > hardware to get that stuff up and running, would you? > > Do you want to ask me? I'm mostly a private individual and linux/debian > user that got fed up with the Linux fragmentation and direction of > development (from a user perspective). I found my new home in FreeBSD. > I migrated my (hobby) root server and have a few jails up and running > and doing random stuff on them for myself and friends. > > Key to this was that I was able to get FreeBSD up and running on my > Laptop - with the drm-next kmod - and use it daily to get used to it and > learn about it. Actually it was a pain in the ass because back then I > had to learn how to make -current run and even worse, I had to use the > drm-next graphics branch from a github repository which wasn't even > on the main FreeBSD account. I was forced to update the kernel every > once in a while because the pkg update would complain otherwise. It > frequently broke and I had to deal with it and learn how to recover it. > > The alternative would have been to go back to Linux, which has a whole > lot more to complain about. So I stayed. And I'm happy with it. > > I accepted all this trouble to have decent graphics support. In all > the time I had to fight -current issues a lot more than anything > drm/graphics related. This stuff was always stable for me. > > I saw a few people trying out FreeBSD. And the first thing after the > Installation is always: Graphics and Wifi. That's what people need. > > These are "desktop needs", where supporting new hardware fast is more > important than being rock stable and feature complete. > > Just my 2 cents, > Stefan > > -- > Stefan Hagen > Mail: s...@codevoid.de | encryption key in header. > gopher://codevoid.de | https://codevoid.de > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > Like you said you're doing hobby work, that's fine. Take the time to test that bleeding edge stuff on a branch somewhere. You guys cannot expect reasonable people who have machines running production code to have to deal with that type of nonsense that you just described. You left Linux because it's an unorganized mess, FreeBSD is not Linux. There are clear rules and restrictions if you guys cannot understand this then this is just a waste of time. FreeBSD is server first and while that may suck for hobbyist at first, once you understand that people who run servers do not care about graphics as much as hobbyist do they need a reliable core. The linuxkpi stuff the total antithesis of what I understand to be the FreeBSD philosophy. Try reading it again: https://www.freebsd.org/doc/handbook/nutshell.html You guys can't expect to destroy the stability for everyone because a few hobbyist who volunteer in their free time want to wreck the system. Work on your code to improve the quality instead of trying to turn the FreeBSD kernel into a thin wrapper around Linux kernel. Solve the engineering problems instead of asking for quick fix solutions. Any of you linuxkpi guys who are pushing this, what will be enough? Haven't you guys gotten enough leeway from the core team? How many breaking changes do you want to introduce to the FreeBSD kernel vs engineering your software to work well within the existing infrastructure? Which one of you guys dare to stand up and define a goal? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: > blubee blubeeme writes: > > True on both points my tone is just a reflection of attitudes of the > > individuals that I am currently addressing. > > Well, congratulations on alienating absolutely everybody you have > interacted with on this topic. > > > Some people enjoy making contributions w/o waving a banner constantly > > wanting acknowledgement, a pat on the head and good job from everyone. > > The only person I see constantly craving attention and validation from > others here is you. > > > How far will core FreeBSD bend over backwards to accommodate these > > devs. > > The core team does not decide what goes into the tree or not. The > developers do. > > > This is the beauty of an open source project, we bring the best to the > > table, [...] > > Who exactly is “we” here? You are not a member of the project, you do > not speak for the project, and after seeing how you treat our fellow > developers, our friends, most of us want nothing to do with you. If > can't live with that, I'm sure you can figure out how to install Linux. > > DES > -- > Dag-Erling Smørgrav - d...@des.no Some on here want to attack my personality because they think that I am abrasive, fine but that's not the issue. Some claim that they run the code and it works wonderful for them with no issues, again that's lovely keep on running the code. Nevertheless let me restate the point that you guys are all seeming to miss; If you can go out and build custom kernels with custom options and out of mainline tree that's fine, keep doing that until you have something that's production ready and as easy to install as the rest of FreeBSD system. The graphics stack on FreeBSD is pretty bad as it stands but all the documentation currently out there is about using it as it stands now. Why do you need to rip out the current graphics drivers which will break systems for the vast majority of silent users who will not complain and just leave? A little background Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update their phones to the latest android version? It's because the Linux kernel is such a mess they know it's a waste of resources to try. You should not have to ask how or why I know this but if it's unclear I was in the field. --- Now you guys who claim to only be hobbyist doing this in their free time expect to maintain this when those companies with all their resources cannot? Those 30,000 ports many of them bring bugs with them because of this Linuxkpi stuff. Just recently there was a user who said google earth doesn't work the answer was it doesn't work and that's that. They get ported and then get dropped so while the ports tree is large, if you actually try to use some of those programs they are broken, maintenance hell for the developers and confusion for the users. Johannes Lundberg I know that you are one of the main working on this linuxkpi stuff but anyone else is free to answer as well. Let's have an open discussion why do you need to remove the current graphics stack to continue with your work? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg wrote: > > > On Sun, Aug 26, 2018 at 00:25 blubee blubeeme wrote: > >> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav wrote: >> >> > blubee blubeeme writes: >> > > True on both points my tone is just a reflection of attitudes of the >> > > individuals that I am currently addressing. >> > >> > Well, congratulations on alienating absolutely everybody you have >> > interacted with on this topic. >> > >> > > Some people enjoy making contributions w/o waving a banner constantly >> > > wanting acknowledgement, a pat on the head and good job from everyone. >> > >> > The only person I see constantly craving attention and validation from >> > others here is you. >> > >> > > How far will core FreeBSD bend over backwards to accommodate these >> > > devs. >> > >> > The core team does not decide what goes into the tree or not. The >> > developers do. >> > >> > > This is the beauty of an open source project, we bring the best to the >> > > table, [...] >> > >> > Who exactly is “we” here? You are not a member of the project, you do >> > not speak for the project, and after seeing how you treat our fellow >> > developers, our friends, most of us want nothing to do with you. If >> > can't live with that, I'm sure you can figure out how to install Linux. >> > >> > DES >> > -- >> > Dag-Erling Smørgrav - d...@des.no >> >> >> Some on here want to attack my personality because they think that I am >> abrasive, fine but that's not the issue. >> >> Some claim that they run the code and it works wonderful for them with no >> issues, again that's lovely keep on running the code. >> >> Nevertheless let me restate the point that you guys are all seeming to >> miss; If you can go out and build custom kernels with custom options and >> out of mainline tree that's fine, keep doing that until you have something >> that's production ready and as easy to install as the rest of FreeBSD >> system. >> >> The graphics stack on FreeBSD is pretty bad as it stands but all the >> documentation currently out there is about using it as it stands now. >> >> Why do you need to rip out the current graphics drivers which will break >> systems for the vast majority of silent users who will not complain and >> just leave? >> >> A little background >> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update >> their phones to the latest android version? >> >> It's because the Linux kernel is such a mess they know it's a waste of >> resources to try. You should not have to ask how or why I know this but if >> it's unclear I was in the field. >> --- >> >> Now you guys who claim to only be hobbyist doing this in their free time >> expect to maintain this when those companies with all their resources >> cannot? >> >> Those 30,000 ports many of them bring bugs with them because of this >> Linuxkpi stuff. Just recently there was a user who said google earth >> doesn't work the answer was it doesn't work and that's that. >> >> They get ported and then get dropped so while the ports tree is large, if >> you actually try to use some of those programs they are broken, >> maintenance >> hell for the developers and confusion for the users. >> >> Johannes Lundberg I know that you are one of the main working on this >> linuxkpi stuff but anyone else is free to answer as well. >> >> Let's have an open discussion why do you need to remove the current >> graphics stack to continue with your work? > > > This has been discussed over and over on the mailing list and I don’t > think anyone wants to do it over again so please feel free to search the > archives. > > You’re misinformed. We are not removing anything for anyone. We are moving > it to ports. > “pkg install drm-legacy-kmod” will install those drivers for you that were > earlier in base. I thought we have been clear about this but maybe we > haven’t been clear enough. > > > >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > Have you or anyone working
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 9:08 AM Paul McNary wrote: > I think you can pay XinuOS to support FreeBSD in a LTS situation. > It is just like linux where you have to pay Red Hat, Suse, etc. > They break things even with point releases. Suse majorly > screwed with video drivers back in the 9.x series. Totally > broke major release. Their answer then was pay us or > re-install bare metal and figure it out on your own. > Other wise linux has always been, you get what you get for free. > BSD is the same. If you are lucky some one like red hat, suse, XinuOS > will be supporting and make their notes public, otherwise the > OSS model doesn't include anything more than community support > for what ever that is worth. > I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and > several incremental upgrades sometimes to multiple point releases > with in a major release. There is nothing really for free. > > > On 8/25/2018 7:47 PM, blubee blubeeme wrote: > > On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg > > wrote: > > > >> > >> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme > wrote: > >> > >>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav > wrote: > >>> > >>>> blubee blubeeme writes: > >>>>> True on both points my tone is just a reflection of attitudes of the > >>>>> individuals that I am currently addressing. > >>>> Well, congratulations on alienating absolutely everybody you have > >>>> interacted with on this topic. > >>>> > >>>>> Some people enjoy making contributions w/o waving a banner constantly > >>>>> wanting acknowledgement, a pat on the head and good job from > everyone. > >>>> The only person I see constantly craving attention and validation from > >>>> others here is you. > >>>> > >>>>> How far will core FreeBSD bend over backwards to accommodate these > >>>>> devs. > >>>> The core team does not decide what goes into the tree or not. The > >>>> developers do. > >>>> > >>>>> This is the beauty of an open source project, we bring the best to > the > >>>>> table, [...] > >>>> Who exactly is “we” here? You are not a member of the project, you do > >>>> not speak for the project, and after seeing how you treat our fellow > >>>> developers, our friends, most of us want nothing to do with you. If > >>>> can't live with that, I'm sure you can figure out how to install > Linux. > >>>> > >>>> DES > >>>> -- > >>>> Dag-Erling Smørgrav - d...@des.no > >>> > >>> Some on here want to attack my personality because they think that I am > >>> abrasive, fine but that's not the issue. > >>> > >>> Some claim that they run the code and it works wonderful for them with > no > >>> issues, again that's lovely keep on running the code. > >>> > >>> Nevertheless let me restate the point that you guys are all seeming > to > >>> miss; If you can go out and build custom kernels with custom options > and > >>> out of mainline tree that's fine, keep doing that until you have > something > >>> that's production ready and as easy to install as the rest of FreeBSD > >>> system. > >>> > >>> The graphics stack on FreeBSD is pretty bad as it stands but all the > >>> documentation currently out there is about using it as it stands now. > >>> > >>> Why do you need to rip out the current graphics drivers which will > break > >>> systems for the vast majority of silent users who will not complain and > >>> just leave? > >>> > >>> A little background > >>> Do you know why Samsung, Motorola, Sony, LG, Nokia, etc... never update > >>> their phones to the latest android version? > >>> > >>> It's because the Linux kernel is such a mess they know it's a waste of > >>> resources to try. You should not have to ask how or why I know this > but if > >>> it's unclear I was in the field. > >>> --- > >>> > >>> Now you guys who claim to only be hobbyist doing this in their free > time > >>> expect to maintain this when those companies with all their resources > >>> cannot? > >>> > >&
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 10:05 AM Allan Jude wrote: > On 2018-08-25 21:20, blubee blubeeme wrote: > > On Sun, Aug 26, 2018 at 9:08 AM Paul McNary wrote: > > > >> I think you can pay XinuOS to support FreeBSD in a LTS situation. > >> It is just like linux where you have to pay Red Hat, Suse, etc. > >> They break things even with point releases. Suse majorly > >> screwed with video drivers back in the 9.x series. Totally > >> broke major release. Their answer then was pay us or > >> re-install bare metal and figure it out on your own. > >> Other wise linux has always been, you get what you get for free. > >> BSD is the same. If you are lucky some one like red hat, suse, XinuOS > >> will be supporting and make their notes public, otherwise the > >> OSS model doesn't include anything more than community support > >> for what ever that is worth. > >> I just upgraded a system from FreeBSD 9.x to 12.x, it took 2 weeks and > >> several incremental upgrades sometimes to multiple point releases > >> with in a major release. There is nothing really for free. > >> > >> > >> On 8/25/2018 7:47 PM, blubee blubeeme wrote: > >>> On Sun, Aug 26, 2018 at 8:16 AM Johannes Lundberg > >>> wrote: > >>> > >>>> > >>>> On Sun, Aug 26, 2018 at 00:25 blubee blubeeme > >> wrote: > >>>> > >>>>> On Sun, Aug 26, 2018 at 2:08 AM Dag-Erling Smørgrav > >> wrote: > >>>>> > >>>>>> blubee blubeeme writes: > >>>>>>> True on both points my tone is just a reflection of attitudes of > the > >>>>>>> individuals that I am currently addressing. > >>>>>> Well, congratulations on alienating absolutely everybody you have > >>>>>> interacted with on this topic. > >>>>>> > >>>>>>> Some people enjoy making contributions w/o waving a banner > constantly > >>>>>>> wanting acknowledgement, a pat on the head and good job from > >> everyone. > >>>>>> The only person I see constantly craving attention and validation > from > >>>>>> others here is you. > >>>>>> > >>>>>>> How far will core FreeBSD bend over backwards to accommodate these > >>>>>>> devs. > >>>>>> The core team does not decide what goes into the tree or not. The > >>>>>> developers do. > >>>>>> > >>>>>>> This is the beauty of an open source project, we bring the best to > >> the > >>>>>>> table, [...] > >>>>>> Who exactly is “we” here? You are not a member of the project, you > do > >>>>>> not speak for the project, and after seeing how you treat our fellow > >>>>>> developers, our friends, most of us want nothing to do with you. If > >>>>>> can't live with that, I'm sure you can figure out how to install > >> Linux. > >>>>>> > >>>>>> DES > >>>>>> -- > >>>>>> Dag-Erling Smørgrav - d...@des.no > >>>>> > >>>>> Some on here want to attack my personality because they think that I > am > >>>>> abrasive, fine but that's not the issue. > >>>>> > >>>>> Some claim that they run the code and it works wonderful for them > with > >> no > >>>>> issues, again that's lovely keep on running the code. > >>>>> > >>>>> Nevertheless let me restate the point that you guys are all seeming > >> to > >>>>> miss; If you can go out and build custom kernels with custom options > >> and > >>>>> out of mainline tree that's fine, keep doing that until you have > >> something > >>>>> that's production ready and as easy to install as the rest of FreeBSD > >>>>> system. > >>>>> > >>>>> The graphics stack on FreeBSD is pretty bad as it stands but all the > >>>>> documentation currently out there is about using it as it stands now. > >>>>> > >>>>> Why do you need to rip out the current graphics drivers which will > >> break > >>>>> systems for the vast majority of silent users who will not complain > and > >>&
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 10:51 AM cpghost wrote: > On 8/25/18 5:34 PM, Dave Cottlehuber wrote: > >> On Sat, Aug 25, 2018 at 5:09 PM Stefan Hagen < > sh+freebsd-curr...@codevoid.de> > On Sat, Aug 25, 2018 at 7:43 AM Kris Moore wrote: > > I've been personally using the new DRM bits since almost day one. I > > haven't found it to be unstable in the slightest. Compared to not > > having it and being forced to run 5+ year old hardware, it's been a > > huge blessing for those of us who care about running FreeBSD as a > > modern desktop / laptop. > > > > Ditto. I'd like to express my heartfelt thanks for all the people who > have been > > working on the drm-next code for over 2 years now. It's fantastic and an > > incredible piece of effort to pull it all together. > > Same here. A big THANK YOU to the Graphics Team for drm-next. > I've been running it on STABLE with amdgpu driver on an RX 580 > at 4K res, and had ZERO issues with it so far... except for broken > opencl on drm-stable-kmod, but I can live with that until its fixed. > > > A+++ > > Dave > > -cpghost. > > > > There's a whole lot of cheerleading and that's wonderful keep it up. Enjoy building and applying your patches no one will take that away from you guys. Although the way you guys continually dodge, deflect and run away from 3 simple questions is astonishing, see below. You guys can keep on cheerleading but that still doesn't answer the questions that I have asked numerous time. Cheerleading does not solve engineering problems, it's just noise. I'll post this again to keep the focus on the issue at hand. If The Graphics team has already done these tests, show us. If The Graphics team has not, then maybe they should take some time to do the work required get the code submitted upstream. === 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base to create a port 3) update the working [test] system after applying your changes How does your changes affect a [test] system that is already up and running? Have any of you guys tried that? Do you have any documentation on how it'll affect users. You guys want to remove things from the current system but you come with; it works for us hobbyists. Where do users go to get steps to do all of this stuff? You've repeatedly said what you want to do sure, but have you tested it? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Sun, Aug 26, 2018 at 4:32 PM Hans Petter Selasky wrote: > On 8/26/18 3:20 AM, blubee blubeeme wrote: > > Have you or anyone working on this drm-legacy-kmod stuff done any > testings > > of how this will affect current users? > > Hi Blubee, > > Are you here to try to stir a conflict? > If so that is not appreciated. > > --HPS > Hans, you of all people should know that's not true. I would think that trying to sneak in code during a code freeze that would break the release. Forcing the core devs to revert those changes and having to dust off old policies to try to keep you guys in check is what's stirring up conflicts, but hey; what do I know? It's really sad state when capable engineers are so obsessed with something that they cannot see the forest for the trees. Try to step away from the canvas and look at the big picture. If you don't mind me asking, Hans care to answer these questions below? 1) Take a [test] system with the current graphics stack installed and working. 2) Apply your patches to remove the drm from base to create a port 3) update the working [test] system after applying your changes How does your changes affect a [test] system that is already up and running? Have any of you guys tried that? Do you have any documentation on how it'll affect users. You guys want to remove things from the current system but you come with; it works for us hobbyists. Where do users go to get steps to do all of this stuff? You've repeatedly said what you want to do sure, but have you tested it? ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: drm / drm2 removal in 12
On Mon, Aug 27, 2018 at 2:39 AM Dag-Erling Smørgrav wrote: > blubee blubeeme writes: > > Hans Petter Selasky writes: > > > Are you here to try to stir a conflict? If so that is not > > > appreciated. > > Hans, you of all people should know that's not true. > > And yet here we are. > > You have made it perfectly clear that you are not interested in an > honest discussion. Your entire strategy is to wear people down until > they either leave or agree with you just to shut you up. Like Hans > Petter says, it is not appreciated. > > You clearly believe that you know better than anyone else how this > should be handled, so instead of telling us, I suggest you just go do > it. It only takes seconds to fork the FreeBSD mirror on Github, and a > few minutes to clone it onto your machine. We look forward to hearing > from you again when you have everything working perfectly and seamlessly > out of the box for everybody on any equipment. I'm sure that Johannes, > Niclas, Warner and others with a century of combined experience will be > thrilled to see you succeed where they, by your account, have failed. > > DES > -- > Dag-Erling Smørgrav - d...@des.no You seem to miss the point where the you avoid breaking the system for any users not on the bleeding edge. You technically adept guys can keep on hacking away, jumping through hoops and building your stuff as you see fit. Nobody will come take your steal your code away in the night. Feel free to keep on working on it, until implementing it doesn't break "old users" do the engineering work and improve your implementation. There are so many seemingly dead code projects around this linuxkpi stuff that you guys just pump out code and abandon inconsistent lack of documentation, lack of testing, it's just a huge mess. Work on cleaning all that stuff up and bring something sensible to the table, you cannot put onus on the core team to maintain that mess going forward because you're not capable of doing it yourselves. ___ 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: Good motherboard for Ryzen (first-gen)
On Sat, Sep 22, 2018 at 10:56 AM Eric van Gyzen wrote: > I would like to build a Ryzen desktop. Can anyone recommend a good > motherboard? > > I'm planning on a first-gen, because the second-gen has similar > stability problems as the first-gen had, and AMD hasn't released errata > for the second-gen yet (as far as I know...I would love to be wrong). > > I would like to be a cool kid with a Threadripper, but I can't justify > the cost, so I'm thinking maybe a Ryzen 7 with /only/ 8 cores. :) > > Ideally, I want an Intel NIC, ECC memory support, and a 3-year warranty. > > Thanks in advance, > > Eric > > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > I purchased MSI B350 Gaming Pro with a Ryzen 2600 it's been great but if you plan to run FreeBSD you'll need a graphics card that's supported by the current graphics drivers. I found something quite old, it works with the drm2 drivers and there's no issues. There's list of supported cards here: https://wiki.freebsd.org/Graphics There's work being done on improving the graphics drivers, soon you won't need to get such old GPU. As for ECC I don't think you'll find many 1st gen ryzen motherboards that support that but I could be wrong, spec and datasheet here: https://www.msi.com/Motherboard/B350M-GAMING-PRO/Specification ___ 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"
error: undefined symbol: main in poudriere jail
This issue seemed to have come up in the past: https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html Jail name: amd64_cur Jail version: 12.0-ALPHA7 1200084 Jail vcs version: r338898 Jail arch: amd64 Jail method: svn Jail mount:/usr/local/poudriere/jails/amd64_cur Jail fs: zroot/poudriere/jails/amd64_cur Jail updated: 2018-09-24 03:39:31 Tree name: default Tree method: portsnap Status: error /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: lib/libged.so.20.0.1 lib/librtuif_multispectral.a lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread -ldl && : FAILED: bin/rttherm : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib: lib/libged.so.20.0.1 lib/librtuif_multispectral.a lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1 /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5 /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1 lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0 lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1 lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245 lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread -ldl && : /usr/bin/ld: error: undefined symbol: main >>> referenced by crt1.c:74 (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74) >>> /usr/lib/crt1.o:(_start) cc: error: linker command failed with exit code 1 (use -v to see invocation) ninja: build stopped: subcommand failed. *** 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"
Re: error: undefined symbol: main in poudriere jail
On Mon, Sep 24, 2018 at 7:31 AM blubee blubeeme wrote:
> This issue seemed to have come up in the past:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-March/068870.html
>
>
> Jail name: amd64_cur
> Jail version: 12.0-ALPHA7 1200084
> Jail vcs version: r338898
> Jail arch: amd64
> Jail method: svn
> Jail mount:/usr/local/poudriere/jails/amd64_cur
> Jail fs: zroot/poudriere/jails/amd64_cur
> Jail updated: 2018-09-24 03:39:31
> Tree name: default
> Tree method: portsnap
> Status:
>
> error
> /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions -std=gnu99
> -m64 -Qunused-arguments -O3 -march=native -finline-functions -flto
> -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> FAILED: bin/rttherm
> : && /usr/bin/cc -pipe -fno-strict-aliasing -fno-common -fexceptions
> -std=gnu99 -m64 -Qunused-arguments -O3 -march=native -finline-functions
> -flto -fomit-frame-pointer -pedantic -pedantic-errors -Wall -Wextra -Wundef
> -Wfloat-equal -Wshadow -Wbad-function-cast -Wdeclaration-after-statement
> -Wc++-compat -Winline -Wno-long-long -Wno-variadic-macros -Wdocumentation
> -m64 src/rttherm/CMakeFiles/rttherm.dir/spectrum.c.o
> src/rttherm/CMakeFiles/rttherm.dir/viewtherm.c.o -o bin/rttherm
> -Wl,-rpath,/wrkdirs/usr/ports/cad/brlcad/work/.build/lib:/usr/local/lib:
> lib/libged.so.20.0.1 lib/librtuif_multispectral.a
> lib/libmultispectral.so.20.0.1 lib/libfb.so.20.0.1 lib/libpkg.so.20.0.1
> /usr/local/lib/libSM.so /usr/local/lib/libICE.so /usr/local/lib/libGLU.so
> /usr/local/lib/libGL.so /usr/local/lib/libSM.so /usr/local/lib/libICE.so
> /usr/local/lib/libGLU.so /usr/local/lib/libGL.so lib/libtk.so.8.5
> /usr/local/lib/libX11.so /usr/local/lib/libXext.so lib/libtkstub.a
> lib/libtclstub.a /usr/local/lib/libXrender.so lib/libwdb.so.20.0.1
> lib/libicv.so.20.0.1 lib/libpng16.so.16.29.0 lib/libnetpbm.so
> lib/libanalyze.so.20.0.1 lib/libtcl.so.8.5.19 lib/libclipper.so.4.6.0
> lib/librt.so.20.0.1 lib/libnmg.so lib/libgdiam.so lib/libvds.so.1.0.1
> lib/libbrep.so.20.0.1 lib/libbg.so.20.0.1 lib/libopenNURBS.so.2012.10.245
> lib/libp2t.so.1.0.1 lib/libz.so.1.2.11 lib/libtinycthread.so lib/liblz4.so
> lib/libbn.so.20.0.1 lib/libbu.so.20.0.1 lib/libregex.so.1.0.4 -lm -pthread
> -ldl && :
> /usr/bin/ld: error: undefined symbol: main
> >>> referenced by crt1.c:74
> (/usr/local/poudriere/jails/amd64_cur/usr/src/lib/csu/amd64/crt1.c:74)
> >>> /usr/lib/crt1.o:(_start)
> cc: error: linker command failed with exit code 1 (use -v to see
> invocation)
> ninja: build stopped: subcommand failed.
> *** Error code 1
>
> I though that it could be an issue with portsnap so I created a new jail
using svn
poudriere jails -j amd64HD -i
Jail name: amd64HD
Jail version: 12.0-ALPHA7 1200084
Jail vcs version: r338899
Jail arch: amd64
Jail method: svn
Jail mount:/usr/local/poudriere/jails/amd64HD
Jail fs: zroot/poudriere/jails/amd64HD
Jail updated: 2018-09-24 07:34:06
Tree name: default
Tree method: portsnap
Status:
error
#include
__FBSDID("$FreeBSD: head/lib/csu/amd64/crt1.c 326219 2017-11-26 02:00:33Z
pfg $");
#include
#include "libc_private.h"
#include "crtbrand.c"
#include "ignore_init.c"
typedef void (*fptr)(void);
#ifdef GCRT
extern void _mcleanup(void);
extern void monstartup(void *, void *);
exter
Re: linux-c7 and opengl apps?
On Wed, Oct 3, 2018 at 5:40 PM Johannes Lundberg wrote: > Hi > > Have anyone successfully run opengl apps with linux-c7? > > Linux opengl apps works great with linux-c6 on gpu < kabylake but > linux-c6-dri does not include support for kabylake gpus. > Linux glxinfo in c7 show support for hardware rendering on kabylake but any > attempt to run an opengl app results in application seg fault or other > crash (I believe this is also the case with skylake gpus on linux-c7). > > Is there any way to run gdb on linux apps/core dumps? > > /Johannes > ___ > 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" > Highly unlikely since the Linux kernel memory model is pretty different than FreeBSD especially concerning graphics. Linux kernel graphics will have to use dma regions or the low kernel memory while most other stuff hangs out in the high kernel memory. Since the graphics drivers have to have contiguous memory regions that should not be swapped out, if linuxkpi doesn't manage these complexities you'll continue to random failures especially around sleep to wake, context switching and power management. It can be fixed though, you'll just need to port the entire Linux memory architecture to FreeBSD and that's as it stands right now. Don't look into rma, numa, hhm, huge pages and all the other lovely memory features that is currently mainline or about to get merged into mainline. Good luck with that though. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: linux-c7 and opengl apps?
On Fri, Oct 5, 2018 at 11:50 PM Greg V wrote: > > > On Wed, Oct 3, 2018 at 12:36 PM, Johannes Lundberg > wrote: > > Hi > > > > Have anyone successfully run opengl apps with linux-c7? > > > > Linux opengl apps works great with linux-c6 on gpu < kabylake but > > linux-c6-dri does not include support for kabylake gpus. > > Linux glxinfo in c7 show support for hardware rendering on kabylake > > but any > > attempt to run an opengl app results in application seg fault or other > > crash (I believe this is also the case with skylake gpus on linux-c7). > > On AMD Polaris: everything used to work in an ubuntu 16.04 chroot > (currently having "can't open display :0" with that, probably > forgetting something). > > Trying Unigine Heaven with c7, segfaults right now. glxinfo shows > everything correctly though. > > > Is there any way to run gdb on linux apps/core dumps? > > There was a BSDCan talk that mentioned some gdb solutions: > > https://www.youtube.com/watch?v=9N3NrPeCJpk > > https://www.bsdcan.org/2018/schedule/attachments/473_linuxulator-notes-bsdcan2018.txt > > ___ > 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" > In the video, you guys run into issues w/ debugging core dumps. While this doesn't make any sense, you guys are free to write your own Linux core dump disassembler. Core dumps are created this way: https://github.com/torvalds/linux/blob/master/fs/binfmt_elf.c#L97 The elf format is documented online. Once that's done you have all the registers, heap, stack, data and you can play from there. Writing a disassembler should be childs play, shouldn't it? Best ___ 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: Page fault in midi/sequencer.c
On Sun, Oct 21, 2018 at 12:59 AM Peter Holm wrote: > I can trigger this on 13.0-CURRENT r339445 with a non-root test program: > > Calling uiomove() with the following non-sleepable locks held: > exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ > dev/sound/midi/sequencer.c:952 > stack backtrace: > #0 0x80bfe263 at witness_debugger+0x73 > #1 0x80bff1b8 at witness_warn+0x448 > #2 0x80bf6a91 at uiomove_faultflag+0x71 > #3 0x809439e6 at mseq_write+0x4c6 > #4 0x80a4f725 at devfs_write_f+0x185 > #5 0x80c02a87 at dofilewrite+0x97 > #6 0x80c0287f at kern_pwritev+0x5f > #7 0x80c0277d at sys_pwrite+0x8d > #8 0x81070af7 at amd64_syscall+0x2a7 > #9 0x8104a4ad at fast_syscall_common+0x101 > Kernel page fault with the following non-sleepable locks held: > exclusive sleep mutex seqflq (seqflq) r = 0 (0xf80003860c08) locked @ > dev/sound/midi/sequencer.c:952 > stack backtrace: > #0 0x80bfe263 at witness_debugger+0x73 > #1 0x80bff1b8 at witness_warn+0x448 > #2 0x810700d3 at trap_pfault+0x53 > #3 0x8106f70a at trap+0x2ba > #4 0x81049bc5 at calltrap+0x8 > #5 0x80bf6b42 at uiomove_faultflag+0x122 > #6 0x809439e6 at mseq_write+0x4c6 > #7 0x80a4f725 at devfs_write_f+0x185 > #8 0x80c02a87 at dofilewrite+0x97 > #9 0x80c0287f at kern_pwritev+0x5f > #10 0x80c0277d at sys_pwrite+0x8d > #11 0x81070af7 at amd64_syscall+0x2a7 > #12 0x8104a4ad at fast_syscall_common+0x101 > > > Fatal trap 12: page fault while in kernel mode > cpuid = 4; apic id = 04 > fault virtual address = 0x20ea6b > fault code = supervisor read data, page not present > instruction pointer = 0x20:0x8106d32d > stack pointer = 0x28:0xfe00a844a660 > frame pointer = 0x28:0xfe00a844a660 > code segment = base 0x0, limit 0xf, type 0x1b >= DPL 0, pres 1, long 1, def32 0, gran 1 > processor eflags = interrupt enabled, resume, IOPL = 0 > current process = 2356 (xxx) > [ thread pid 2356 tid 100278 ] > Stopped at copyin_nosmap_erms+0xdd:movl(%rsi),%edx > db> > > -- > Peter > ___ > 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's a known fault in the oss implementation midi parsing code. The easiest route is to use something else to parse midi for the time being. OSS was ported over and many outstanding bugs are still laying around. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
A quick question
Hi I am on a Macbook pro 11,3 and I wanted to start trying to help sort out some problems that might be too small for the overall team but might help others in the future. Anyways I am on 12-CURRENT but when I installed from the USB stick I didn't check the docs and 32 bit binaries. svn checkout svn://svn.freebsd.org/base/head /usr/src svn checkout svn://svn.freebsd.org/ports/head /usr/ports svn checkout svn://svn.freebsd.org/doc/head /usr/doc once I do the above steps, do I have to rebuild the entire world? Currently all I am missing is the 32 bit binaries, could I just rebuild those instead of building the entire system? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: A quick question
Can I bump this issue one more time? On Sun, Dec 18, 2016, 18:38 Dave Cottlehuber wrote: > On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote: > > Hi > > > > I am on a Macbook pro 11,3 and I wanted to start trying to help sort out > > some problems that might be too small for the overall team but might help > > others in the future. > > \o/ there are a few of us about, I'm using a MacBookPro 11,2. > > > Anyways I am on 12-CURRENT but when I installed from the USB stick I > > didn't > > check the docs and 32 bit binaries. > > > > svn checkout svn://svn.freebsd.org/base/head /usr/src > > svn checkout svn://svn.freebsd.org/ports/head /usr/ports > > svn checkout svn://svn.freebsd.org/doc/head /usr/doc > > > > once I do the above steps, do I have to rebuild the entire world? > > Currently > > all I am missing is the 32 bit binaries, could I just rebuild those > > instead > > of building the entire system? > > > > > > Best, > > Owen > > Hi Owen > > You probably only need to unpack > http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/*.txz ; > I'm assuming this snapshot is still from the same date as your > installer. If your USB stick has the txz on it, then you can extract > them from there as well. Something like > > tar -xf docs.txz -C / > > is probably all you need. NB not tested, viz xkcd.com/1168 > > A+ > Dave > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ 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: A quick question
Thanks for the follow-up. On Sat, Dec 24, 2016, 17:08 Dave Cottlehuber wrote: > On Wed, 21 Dec 2016, at 06:39, blubee blubeeme wrote: > > Can I bump this issue one more time? > > > > On Sun, Dec 18, 2016, 18:38 Dave Cottlehuber wrote: > > > > > On Sun, 18 Dec 2016, at 10:07, blubee blubeeme wrote: > > > > Hi > > > > > > > > I am on a Macbook pro 11,3 and I wanted to start trying to help sort > out > > > > some problems that might be too small for the overall team but might > help > > > > others in the future. > > > > > > \o/ there are a few of us about, I'm using a MacBookPro 11,2. > > > > > > > Anyways I am on 12-CURRENT but when I installed from the USB stick I > > > > didn't > > > > check the docs and 32 bit binaries. > > > > > > > > svn checkout svn://svn.freebsd.org/base/head /usr/src > > > > svn checkout svn://svn.freebsd.org/ports/head /usr/ports > > > > svn checkout svn://svn.freebsd.org/doc/head /usr/doc > > > > > > > > once I do the above steps, do I have to rebuild the entire world? > > > > Currently > > > > all I am missing is the 32 bit binaries, could I just rebuild those > > > > instead > > > > of building the entire system? > > > > > > > > > > > > Best, > > > > Owen > > > > > > Hi Owen > > > > > > You probably only need to unpack > > > http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/*.txz > ; > > > I'm assuming this snapshot is still from the same date as your > > > installer. If your USB stick has the txz on it, then you can extract > > > them from there as well. Something like > > > > > > tar -xf docs.txz -C / > > > > > > is probably all you need. NB not tested, viz xkcd.com/1168 > > > > > > A+ > > > Dave > > another question to make sure. > > > > looking at the url: > http://ftp.freebsd.org/pub/FreeBSD/snapshots/amd64/12.0-CURRENT/ > > > > I see the MANIFEST along with > > > > base-dbg.txz > > base.. > > doc.. > > kernel-dbg... > > etc. > > > > so when I install FreeBSD based on the installation items that I select, > it just unpacks > > one of the above listed file right into the / directory on the hdd? > > Sorry Christmas got in the way of emails. > > Yes, you can see here in pc-sysinstall: > > > https://svnweb.freebsd.org/base/release/11.0.0/usr.sbin/pc-sysinstall/backend/functions-extractimage.sh?view=markup#l57 > > the excellent 3rd party mfsbsd tool does the same thing to install > FreeBSD: > > https://github.com/mmatuska/mfsbsd/blob/master/tools/zfsinstall#L354-L356 > > A+ > Dave > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
A question about updating src & ports
Howdy I went through the process of building world for the first time, that was interesting but I got it. svn clean up prior object files, build world, kernel, etc. Okay that part is fine I have a question about keeping ports up to date, in the past I did portsnap fetch update to update the ports but since I totally deleted all the ports and used svn checkout to get the latest ports. Can I mix portsnap fetch update or should I just continue to use svn update /usr/ports Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
current freebsd graphics stack
Howdy Is there anyone on this list that works on the graphics stack for FreeBSD? Watching this video: https://www.youtube.com/watch?v=dZI4pAvK_RY&spfreload=5 from a few years ago and what I've gathered so far the new x is getting a major redesign and a lot of code is moving into the kernel. You can take a look at the attached images to get the tl;dr of the talk. http://imgur.com/a/Ek4fq My question, is anyone here whose doing graphics stack work done any work on implementing GEM, KMS, DRM in the FreeBSD kernel. Even a port of the linux version would be somewhere to start. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: current freebsd graphics stack
Hi Johannes I was asking about the current state of those three main items. I just looked at the linuxkpi thing and it's a wrapper around the linux version of DRM but isn't DRM a open standard, if we keep chasing down linux the more they move their stuff into their kernel the harder it will become to maintain these things on FreeBSD even though it might be more work upfront? It seems like evdev is the same story, xorg was moving to libinput, I believe. Is there a reason why we have to wrap the linux things and why couldn't we just write our own that can then be tied closely to the BSD kernel while still sticking to the standards. To be honest I don't have the slightest idea how massive GEM, KMS and DRM are just yet but it seems like adding a wrapper around another OS kernel into that mix can only go bad. How many people are working on the project with you at the moment? Best, Owen On Tue, Jan 3, 2017 at 5:42 PM, Johannes Lundberg wrote: > Hi Owen > > I've been helping out with drm, i915, linuxkpi and evdev in the kernel. > > For userland I'm working on Wayland-related stuff. > > You can check my twitter (@johalun) or this mailing list for my earlier > posts about how to use this work. > > Sorry for asking but exactly what is your question now again? > > > On Tue, Jan 3, 2017 at 16:58 blubee blubeeme wrote: > >> Howdy >> >> >> >> Is there anyone on this list that works on the graphics stack for FreeBSD? >> >> >> >> Watching this video: https://www.youtube.com/watch? >> v=dZI4pAvK_RY&spfreload=5 >> >> >> >> from a few years ago and what I've gathered so far the new x is getting a >> >> major redesign and a lot of code is moving into the kernel. >> >> >> >> You can take a look at the attached images to get the tl;dr of the talk. >> >> >> >> http://imgur.com/a/Ek4fq >> >> >> >> My question, is anyone here whose doing graphics stack work done any work >> >> on implementing GEM, KMS, DRM in the FreeBSD kernel. >> >> >> >> Even a port of the linux version would be somewhere to start. >> >> >> >> Best, >> >> Owen >> >> ___ >> >> freebsd-current@freebsd.org mailing list >> >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> >> ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: current freebsd graphics stack
It's understandable and I actually came across your twitter account a long time ago before I joined this list. I did look at intels open source gpu drivers. I will be attempting after a smaller project to get it up and running on BSD without using the linux wrappers. Crazy, I know but nothing tried nothing done and I'm stubborn enough to do the work now to have an easier time later. This is a pretty complex subject and it does touch so many different things that are all trying to change, the complexity is pretty high. We'll see if we can sort that out. Best, Owen On Tue, Jan 3, 2017 at 6:45 PM, Johannes Lundberg wrote: > Hi > > Not sure about the other graphics drivers but porting a driver like > drm/i915 for Intel graphics is a massive undertaking (look at the source > code from Intel!). Intel develops their open source driver for Linux and > having linuxkpi reduces porting efforts for us from a full time job to a > few weekends / year. Remember how we had to wait 5 years for Haswell > support? That's the only reason I had to run Linux for several years > instead of FreeBSD (and a lot of development time went into Linux just > because of that, wasted). linuxkpi and friends will be optional, you don't > have to use if you don't want to. > > I'm all for a BSDish system with X & Wayland compositors and GUIs and the > whole package. But, who's gonna have the time to develop/maintain it? What > happens when we no longer can run Qt/GTK applications and only a small > subset of BSD-friendly apps? > > I agree with what your saying, but we have to be realistic. Adding > optional wrapper/support in the kernel plus a thin userland layer like udev > or epoll etc, does not "taint" FreeBSD in anyway, rather it allows us to > use newer hardware and a larger set of software with minimal porting > efforts. > > On this project? Not many, we need a lot more. > > > On Tue, Jan 3, 2017 at 6:15 PM, blubee blubeeme > wrote: > >> Hi Johannes >> >> I was asking about the current state of those three main items. >> >> I just looked at the linuxkpi thing and it's a wrapper around the linux >> version of DRM but isn't DRM a open standard, if we keep chasing down linux >> the more they move their stuff into their kernel the harder it will become >> to maintain these things on FreeBSD even though it might be more work >> upfront? >> >> It seems like evdev is the same story, xorg was moving to libinput, I >> believe. >> >> Is there a reason why we have to wrap the linux things and why couldn't >> we just write our own that can then be tied closely to the BSD kernel while >> still sticking to the standards. >> >> To be honest I don't have the slightest idea how massive GEM, KMS and DRM >> are just yet but it seems like adding a wrapper around another OS kernel >> into that mix can only go bad. >> >> How many people are working on the project with you at the moment? >> >> Best, >> Owen >> >> On Tue, Jan 3, 2017 at 5:42 PM, Johannes Lundberg >> wrote: >> >>> Hi Owen >>> >>> I've been helping out with drm, i915, linuxkpi and evdev in the kernel. >>> >>> For userland I'm working on Wayland-related stuff. >>> >>> You can check my twitter (@johalun) or this mailing list for my earlier >>> posts about how to use this work. >>> >>> Sorry for asking but exactly what is your question now again? >>> >>> >>> On Tue, Jan 3, 2017 at 16:58 blubee blubeeme >>> wrote: >>> >>>> Howdy >>>> >>>> >>>> >>>> Is there anyone on this list that works on the graphics stack for >>>> FreeBSD? >>>> >>>> >>>> >>>> Watching this video: https://www.youtube.com/watch? >>>> v=dZI4pAvK_RY&spfreload=5 >>>> >>>> >>>> >>>> from a few years ago and what I've gathered so far the new x is getting >>>> a >>>> >>>> major redesign and a lot of code is moving into the kernel. >>>> >>>> >>>> >>>> You can take a look at the attached images to get the tl;dr of the talk. >>>> >>>> >>>> >>>> http://imgur.com/a/Ek4fq >>>> >>>> >>>> >>>> My question, is anyone here whose doing graphics stack work done any >>>> work >>>> >>>> on implementing GEM, KMS, DRM in the FreeBSD kernel. >>>> >>>> >>>> >>>> Even a port of the linux version would be somewhere to start. >>>> >>>> >>>> >>>> Best, >>>> >>>> Owen >>>> >>>> ___ >>>> >>>> freebsd-current@freebsd.org mailing list >>>> >>>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>>> >>>> To unsubscribe, send any mail to "freebsd-current-unsubscribe@f >>>> reebsd.org" >>>> >>>> >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: current freebsd graphics stack
I haven't looked at dragonfly I saw a few talks from the FreeBSD guys and it seemed like the main reason for dragonfly was misguided. I am interested in solving the problem within the constraints set fourth by FreeBSD so I won't be forking anything. I might look at that project though. I think the correct way to say it is that if Gallium and AMD conform to the open standard they should work with KMS and the likes. It'll be hard to go and try to talk to them with nothing to show them and hoping they'll support; that'll only happen in a perfect world. You came back to BSD after some work was done, I doubt you are the only person out there who would like to return. Companies follow the money, let's make FreeBSD attractable so that the customers come and that will bring the support from the big players. Right now we are paupers begging and picking up scraps from linux table. Not only that, since they are the loudest voice in the room right now, they will try and push these things in ways that might not be beneficial for BSD. I cam to BSD because I got tired of debian being too outdated, opensuse doesn't let me not have a DM and fedora w/o gnome might as well be a brick. All of that started because of sysemd so I have no choice but to do what I can to improve things over here. Best, Owen On Tue, Jan 3, 2017 at 6:55 PM, Johannes Lundberg wrote: > Isn't that the way it was done before and is done on DragonFly? > > Don't forget, linuxkpi also supports AMD and Gallium drivers > > It is a complex subject.. in a perfect world we'd have unlimited time and > resources and FreeBSD would be in every man's hand :) > > Good luck! > > On Tue, Jan 3, 2017 at 18:50 blubee blubeeme wrote: > >> It's understandable and I actually came across your twitter account a >> long time ago before I joined this list. >> >> I did look at intels open source gpu drivers. I will be attempting after >> a smaller project to get it up and running on BSD without using the linux >> wrappers. Crazy, I know but nothing tried nothing done and I'm stubborn >> enough to do the work now to have an easier time later. >> >> This is a pretty complex subject and it does touch so many different >> things that are all trying to change, the complexity is pretty high. >> >> We'll see if we can sort that out. >> >> Best, >> Owen >> >> On Tue, Jan 3, 2017 at 6:45 PM, Johannes Lundberg >> wrote: >> >> Hi >> >> Not sure about the other graphics drivers but porting a driver like >> drm/i915 for Intel graphics is a massive undertaking (look at the source >> code from Intel!). Intel develops their open source driver for Linux and >> having linuxkpi reduces porting efforts for us from a full time job to a >> few weekends / year. Remember how we had to wait 5 years for Haswell >> support? That's the only reason I had to run Linux for several years >> instead of FreeBSD (and a lot of development time went into Linux just >> because of that, wasted). linuxkpi and friends will be optional, you don't >> have to use if you don't want to. >> >> I'm all for a BSDish system with X & Wayland compositors and GUIs and the >> whole package. But, who's gonna have the time to develop/maintain it? What >> happens when we no longer can run Qt/GTK applications and only a small >> subset of BSD-friendly apps? >> >> I agree with what your saying, but we have to be realistic. Adding >> optional wrapper/support in the kernel plus a thin userland layer like udev >> or epoll etc, does not "taint" FreeBSD in anyway, rather it allows us to >> use newer hardware and a larger set of software with minimal porting >> efforts. >> >> On this project? Not many, we need a lot more. >> >> >> On Tue, Jan 3, 2017 at 6:15 PM, blubee blubeeme >> wrote: >> >> Hi Johannes >> >> I was asking about the current state of those three main items. >> >> I just looked at the linuxkpi thing and it's a wrapper around the linux >> version of DRM but isn't DRM a open standard, if we keep chasing down linux >> the more they move their stuff into their kernel the harder it will become >> to maintain these things on FreeBSD even though it might be more work >> upfront? >> >> It seems like evdev is the same story, xorg was moving to libinput, I >> believe. >> >> Is there a reason why we have to wrap the linux things and why couldn't >> we just write our own that can then be tied closely to the BSD kernel while >> still sticking to the standards. >> >> To be hon
linuxkpi
I was looking at the linuxkpi source code in /sys/compat/linuxkpi and I had a question. A lot of those files just look like linux files brought over to FreeBSD, is there any reason why those files couldn't be implemented in BSD w/o the dependencies on the other Linux headers? For example this header file: sys/compat/linuxkpi/common/include/linux/workqueue.h the workqueue.h, there doesn't seem to be anything special in there that couldn't be implemented in BSD without relying on the Linux import statements. Maybe I'm missing something but why can't these files and functions be implemented directly with their BSD equivalents? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
firefox/ rust failed to install on FreeBSD 12-CURRENT
I'm trying to install firefox on FreeBSD FreeBSD 12.0-CURRENT FreeBSD 12.0-CURRENT #0 r318998: Sun May 28 04:38:22 CST 2017 /usr/obj/usr/src/sys/GENERIC amd64 ===> firefox-i18n-53.0.3 depends on file: /usr/local/lib/firefox/firefox - not found ===> firefox-53.0.3_1,1 depends on package: nspr>=4.13.1 - found ===> firefox-53.0.3_1,1 depends on package: nss>=3.29.5 - found ===> firefox-53.0.3_1,1 depends on package: libevent>=2.0.21_2 - found ===> firefox-53.0.3_1,1 depends on package: harfbuzz>=1.4.1 - found ===> firefox-53.0.3_1,1 depends on package: graphite2>=1.3.8 - found ===> firefox-53.0.3_1,1 depends on package: png>=1.6.28 - found ===> firefox-53.0.3_1,1 depends on package: libvorbis>=1.3.5,3 - found ===> firefox-53.0.3_1,1 depends on package: libvpx>=1.5.0 - found ===> firefox-53.0.3_1,1 depends on package: sqlite3>=3.17.0 - found ===> firefox-53.0.3_1,1 depends on package: py27-sqlite3>0 - found ===> firefox-53.0.3_1,1 depends on package: v4l_compat>0 - found ===> firefox-53.0.3_1,1 depends on executable: autoconf-2.13 - found ===> firefox-53.0.3_1,1 depends on executable: yasm - found ===> firefox-53.0.3_1,1 depends on executable: zip - found ===> firefox-53.0.3_1,1 depends on package: gtk3>=3.14.6 - found ===> firefox-53.0.3_1,1 depends on package: libnotify>0 - found ===> firefox-53.0.3_1,1 depends on executable: rustc - not found ===> Building for rust-1.17.0 gmake[7]: Entering directory '/usr/ports/lang/rust/work/rustc-1.17.0-src' "/usr/local/bin/python2.7" /usr/ports/lang/rust/work/rustc-1.17.0-src/src/bootstrap/bootstrap.py build -v info: looks like you are running this command under `sudo` and so in order to preserve your $HOME this will now use vendored sources by default. Note that if this does not work you should run a normal build first before running a command like `sudo make install` extracting /usr/ports/lang/rust/work/rustc-1.17.0-src/build/cache/2017-03-11/rust-std-1.16.0-x86_64-unknown-freebsd.tar.gz extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/ manifest.in extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib extracting rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/librustc_llvm-74a1be1110b5d4d0.so gmake[7]: Leaving directory '/usr/ports/lang/rust/work/rustc-1.17.0-src' *** Error code 1 Stop. make[6]: stopped in /usr/ports/lang/rust *** Error code 1 Stop. make[5]: stopped in /usr/ports/lang/rust *** Error code 1 Stop. make[4]: stopped in /usr/ports/www/firefox *** Error code 1 Stop. make[3]: stopped in /usr/ports/www/firefox *** Error code 1 Stop. make[2]: stopped in /usr/ports/www/firefox-i18n *** Error code 1 Stop. make[1]: stopped in /usr/ports/www/firefox-i18n *** Error code 1 Stop. make: stopped in /usr/ports/www/firefox-i18n I am getting build failures with or without make_build_unsafe flags. I am building from source and ports tree is updated to revision 441919. Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
nvidia drivers mutex lock
I'm running nvidia-drivers 375.66 with a GTX 1070 on FreeBSD-Current This problem just started happening recently but, every so often my laptop screen will just blank out and then I have to power cycle to get the machine up and running again. It seems to be a problem with nvidia drivers acquiring duplicate lock. Any info on this? Jun 2 02:29:41 blubee kernel: acquiring duplicate lock of same type: "os.lock_mtx" Jun 2 02:29:41 blubee kernel: 1st os.lock_mtx @ nvidia_os.c:841 Jun 2 02:29:41 blubee kernel: 2nd os.lock_mtx @ nvidia_os.c:841 Jun 2 02:29:41 blubee kernel: stack backtrace: Jun 2 02:29:41 blubee kernel: #0 0x80ab7770 at witness_debugger+0x70 Jun 2 02:29:41 blubee kernel: #1 0x80ab7663 at witness_checkorder+0xe23 Jun 2 02:29:41 blubee kernel: #2 0x80a35b93 at __mtx_lock_flags+0x93 Jun 2 02:29:41 blubee kernel: #3 0x82f4397b at os_acquire_spinlock+0x1b Jun 2 02:29:41 blubee kernel: #4 0x82c48b15 at _nv012002rm+0x185 Jun 2 02:29:41 blubee kernel: ACPI Warning: \_SB.PCI0.PEG0.PEGP._DSM: Argument #4 type mismatch - Found [Buffer], ACPI requires [Package] (20170303/nsarguments-205) Jun 2 02:29:42 blubee kernel: nvidia-modeset: Allocated GPU:0 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0 Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvidia drivers mutex lock
Hi @tomoaki Is that version of nvidia drivers currently in the ports tree? I just checked but it seems not to be. @jeffrey I just generated a new xorg based on the force composition setting. I merged it with my previous xorg I'll reboot, see if it gives better performance. It seems like my system is locking up more frequently now. Sometimes right after a reboot the system, the screen locks and it's reboot and pray. Best, Owen On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet wrote: > SOME LINES BOTTOM POSTED, SEE... > > On Fri, 6/2/17, Tomoaki AOKI wrote: > > Subject: Re: nvidia drivers mutex lock > To: freebsd-current@freebsd.org > Cc: "Jeffrey Bouquet" , "blubee blubeeme" < > gurenc...@gmail.com> > Date: Friday, June 2, 2017, 11:25 PM > > Hi. > Version > 381.22 (5 days newer than 375.66) of the driver states... > [1] > > Fixed hangs and > crashes that could occur when an OpenGL context is > created while the system is out of available > memory. > > Can this be related > with your hang? > > IMHO, > possibly allocating new resource (using os.lock_mtx > guard) > without checking the lock first while > previous request is waiting for > another can > cause the duplicated lock situation. And high memory > pressure would easily cause the situation. > > [1] http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > Hope it helps. > > > On Thu, 1 Jun > 2017 22:35:46 + (UTC) > Jeffrey Bouquet > > wrote: > > > I see the same > message, upon load, ... > > > > > On Thu, 6/1/17, blubee blubeeme > wrote: > > > > Subject: > nvidia drivers mutex lock > > To: freebsd-po...@freebsd.org, > freebsd-current@freebsd.org > > Date: Thursday, June 1, 2017, 11:35 > AM > > > > I'm > running nvidia-drivers 375.66 with a GTX > > 1070 on FreeBSD-Current > > > > This problem > just started happening > > recently but, > every so often my laptop > > screen will > just blank out and then I > > have to > power cycle to get the > > machine up and > running again. > > > > It seems to be a problem with nvidia > > drivers acquiring duplicate lock. Any > > info on this? > > > > Jun〓 2 02:29:41 blubee kernel: > > acquiring duplicate lock of same > type: > > "os.lock_mtx" > > Jun〓 2 02:29:41 blubee kernel: 1st > > os.lock_mtx @ nvidia_os.c:841 > > Jun〓 2 02:29:41 blubee kernel: 2nd > > os.lock_mtx @ nvidia_os.c:841 > > Jun〓 2 02:29:41 blubee kernel: > > stack backtrace: > > > Jun〓 2 02:29:41 blubee kernel: #0 > > > 0x80ab7770 at > > > witness_debugger+0x70 > > Jun〓 2 > 02:29:41 blubee kernel: #1 > > > 0x80ab7663 at > > > witness_checkorder+0xe23 > > Jun〓 2 > 02:29:41 blubee kernel: #2 > > > 0x80a35b93 at > > > __mtx_lock_flags+0x93 > > Jun〓 2 > 02:29:41 blubee kernel: #3 > > > 0x82f4397b at > > > os_acquire_spinlock+0x1b > > Jun〓 2 > 02:29:41 blubee kernel: #4 > > > 0x82c48b15 at _nv012002rm+0x185 > > Jun〓 2 02:29:41 blubee kernel: > > ACPI Warning: > \_SB.PCI0.PEG0.PEGP._DSM: > > Argument #4 > type mismatch - Found > > [Buffer], ACPI > requires [Package] > > > (20170303/nsarguments-205) > > Jun〓 2 > 02:29:42 blubee kernel: > > > nvidia-modeset: Allocated GPU:0 > > > (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ > > PCI::01:00.0 > > > > > Best, > > Owen > > > ___ > > 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" > > > > > > > > ... then Xorg will > run happily twelve hours or so. The lockups here happen > usually > > when too large or too many of > number of tabs/ large web pages with complex CSS etc > > are opened at a time. > > So no help, just a 'me > too'. > > > ___ > > freebsd-current@freebsd.org > mailing list > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > To unsubscribe, send any mail to "freebsd-curren
Re: firefox/ rust failed to install on FreeBSD 12-CURRENT
thanks for the two great pieces of advice.
Best,
Owen
On Sat, Jun 3, 2017 at 2:26 PM, Tim Kientzle wrote:
>
> > On Jun 1, 2017, at 11:37 PM, Jean-Sébastien Pédron
> wrote:
> >
> > On 28.05.2017 19:21, blubee blubeeme wrote:
> >> ===> Building for rust-1.17.0
> >> ...
> >> extracting
> >> rust-std-1.16.0-x86_64-unknown-freebsd/rust-std-x86_
> 64-unknown-freebsd/lib/rustlib/x86_64-unknown-freebsd/lib/GNUSparseFile.0/
> librustc_llvm-74a1be1110b5d4d0.so
> >> gmake[7]: Leaving directory '/usr/ports/lang/rust/work/
> rustc-1.17.0-src'
> >> *** Error code 1
> >
> > Hi!
> >
> > This failure is caused by Python 2's tarfile module not supporting
> > sparse files in archives. Python 3 supports them but the configure
> > script insists on using Python 2.
> >
> > Before a proper fix is committed, you can change the following line in
> > lang/rust/Makefile:
> > https://github.com/freebsd/freebsd-ports/blob/master/
> lang/rust/Makefile#L159
> >
> > to say (this is a single line):
> > gtar -c -C ${WRKSRC} -f -
> > rust-std-1.16.0-${RUST_ARCH_${ARCH}}-unknown-freebsd | gzip >
> > ${WRKSRC}/rustc.tbz
>
> You could add --format=ustar to the existing command line; that would
> force bsdtar to use the older "ustar" format (without any extensions that
> might confuse Python's tar file module).
>
>
> > Then, change the following line:
> > https://github.com/freebsd/freebsd-ports/blob/master/
> lang/rust/Makefile#L34
> >
> > to say:
> > BUILD_DEPENDS= cmake:devel/cmake \
> > gtar:archivers/gtar
> >
> > This will use GNU tar instead of BSD tar to recreate the bootstrap and
> > GNU tar doesn't seem to produce sparse file entries in the archive.
>
> How ironic; using GNU tar in order to avoid having GNU sparse file
> entries. ;-)
>
> Tim
>
>
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvidia drivers mutex lock
Thanks a lot! I'll give it a shot in a bit. Best, Owen On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote: > Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. > > But beware! Sometimes upstream changes make any of FreeBSD patches not > applicable (incorporating any of these, incompatible modifies, ...). > > For 381.22, current patchset applies and builds fine for me. > > > On Sun, 04 Jun 2017 08:04:50 + > blubee blubeeme wrote: > > > I'm running with svn and I build by make. > > If in use these steps, the BSD related patches will be applied, etc? > > > > Best, > > Owen > > > > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI > wrote: > > > > > Hi. > > > > > > Not in ports tree, but easily overridden by adding > > > > > > DISTVERSION=381.22 -DNO_CHECKSUM > > > > > > on make command line. Makefile of x11/nvidia-driver has a mechanism > > > to do so for someone requires newer version (newer GPU support, etc.). > > > > > > If you're using portupgrade, > > > > > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f > x11/nvidia-driver > > > > > > would do the same. > > > > > > If you installed it via pkg, there's no way to try. :-( > > > (As it's pre-built.) > > > > > > > > > On Sun, 04 Jun 2017 07:04:01 + > > > blubee blubeeme wrote: > > > > > > > Hi @tomoaki > > > > Is that version of nvidia drivers currently in the ports tree? I just > > > > checked but it seems not to be. > > > > > > > > @jeffrey > > > > I just generated a new xorg based on the force composition setting. I > > > > merged it with my previous xorg I'll reboot, see if it gives better > > > > performance. > > > > > > > > It seems like my system is locking up more frequently now. Sometimes > > > right > > > > after a reboot the system, the screen locks and it's reboot and pray. > > > > > > > > Best, > > > > Owen > > > > > > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet > > > > wrote: > > > > > > > > > SOME LINES BOTTOM POSTED, SEE... > > > > > > > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: > > > > > > > > > > Subject: Re: nvidia drivers mutex lock > > > > > To: freebsd-current@freebsd.org > > > > > Cc: "Jeffrey Bouquet" , "blubee > blubeeme" < > > > > > gurenc...@gmail.com> > > > > > Date: Friday, June 2, 2017, 11:25 PM > > > > > > > > > > Hi. > > > > > Version > > > > > 381.22 (5 days newer than 375.66) of the driver states... > > > > > [1] > > > > > > > > > > Fixed hangs and > > > > > crashes that could occur when an OpenGL context is > > > > > created while the system is out of available > > > > > memory. > > > > > > > > > > Can this be related > > > > > with your hang? > > > > > > > > > > IMHO, > > > > > possibly allocating new resource (using os.lock_mtx > > > > > guard) > > > > > without checking the lock first while > > > > > previous request is waiting for > > > > > another can > > > > > cause the duplicated lock situation. And high memory > > > > > pressure would easily cause the situation. > > > > > > > > > > [1] > http://www.nvidia.com/Download/driverResults.aspx/118527/en-us > > > > > > > > > > Hope it helps. > > > > > > > > > > > > > > > On Thu, 1 Jun > > > > > 2017 22:35:46 + (UTC) > > > > > Jeffrey Bouquet > > > > > > > > > > wrote: > > > > > > > > > > > I see the same > > > > > message, upon load, ... > > > > > > > > > > > > > > > > > On Thu, 6/1/17, blubee blubeeme > > > > > wrote: > > > > > > > > > > > > Subject: > > > > > nvidia drivers mutex lock > > > > > > To: freebsd-po...@freebsd.
[Help] Linux low level data structures < - > FreeBSD low level data structures
Hello Is there anyone on either of these lists that have experience with both linux low level data structures and their equivalents on FreeBSD? For instance the linux header file: which includes the header file: Then looking at that file: I'll be doing a lot of work trying to find these FreeBSD equivalent of these types of files to port some code. Does anyone here have experience with something like this? Is there any other projects that maps these low level data structures from Linux <-> FreeBSD, etc? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [Help] Linux low level data structures < - > FreeBSD low level data structures
Hi Julian My goals are to port the Linux graphics stack over to FreeBSD w/o relying too heavily on the linuxkpi stuff. That's cool for a lot of use cases but it just seems a bit too brittle. It is a very large I understand the task will not be easy but I am willing to do the work, even from scratch if necessary although some help would be appreciated. I've been watching the Linux DRM project grow and while the top levels has changed, it's been a very long time since the actual low level stuff has been changed. Most of the diffs have shown changes in the [linux/driver/gpu/drm] layer which relies heavily on the [linux/include/drm] that does a lot of the heavy lifting here's a link to the latest version files: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/drm?h=v4.12-rc3 here's a diff of the latest version of the [linux/driver/gpu/drm] : https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 The diffs in the drivers change constantly but the lower level stuff hasn't changed as much. Doing some of the lower level translation to native FreeBSD style data structures then the upper part could be easily migrated, even with something as using AST to translate the headers to their FreeBSD equivalent without worrying about inadvertently breaking something or having major diffs that needs people to actively look at maintaining. That's a high level overview of my plan and what I'd like to achieve. Will it be easy, most likely not but once it's done FreeBSD will be just fine. Hope that helps clarify things for anyone who is interested. Any assistance would be greatly appreciated. Best, Owen On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer wrote: > On 4/6/17 7:07 pm, blubee blubeeme wrote: > >> Hello >> >> Is there anyone on either of these lists that have experience with both >> linux low level data structures and their equivalents on FreeBSD? >> >> For instance the linux header file: >> >> >> which includes the header file: >> >> >> Then looking at that file: >> >> >> >> >> >> > > You are going to have to be a lot more specific about this. > I have worked in several places where they use s shim layer to make Linux > basic services work on freeBSD. > usually a mix of functions, macros and inlines. > However you need to narrow down your questions a bit as the POSSIBLE scope > of your question is too large for anyone to attempt an answer. > > Remember that both systems are POSIX inspired so outside the kernel there > are many more simlarities than one might be led to expect, > but you need to be way more specific. > It's even possible to write kernel code to run on both, but it is usually > domain specific. > > > >> I'll be doing a lot of work trying to find these FreeBSD equivalent of >> these types of files to port some code. >> >> Does anyone here have experience with something like this? Is there any >> other projects that maps these low level data structures from >> Linux <-> FreeBSD, etc? >> >> Best, >> Owen >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > > > ___ 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: [Help] Linux low level data structures < - > FreeBSD low level data structures
＠Hans I've noticed these things about Linux. A lot of stuff relies on knowing the internals of the data structures instead of working with the API but I don't want to start all that stuff up. The goal is to lift up FreeBSD w/o tearing down Linux and as u know needing to be glued to the Linux data structures, while they always seem to be in flux is one reason why I want to steer clear from the linuxkpi stuff. I cam across the webcamd thing a while ago, it was written when Linux was not moving so fast if I remember correctly. This is a big challenge but I think once it's up and running it will bring some additional resources to FreeBSD that can bring the desktop world up to snuff with it's server acumen. Thanks for the tips though! Best, Owen On Mon, Jun 5, 2017 at 12:07 AM, Hans Petter Selasky wrote: > Hi Owen, > > The most comprehensive open-source wrappers for Linux kernel APIs in the > FreeBSD kernel is found at: > > https://github.com/FreeBSDDesktop/freebsd-base-graphics/ > tree/drm-next/sys/compat/linuxkpi > > The most comprehensive open-source wrappers for Linux kernel APIs in > FreeBSD user-space is found at: > > http://www.freshports.org/multimedia/webcamd > > I recommend you start with webcamd. Download the source code and look at > the sources. See if there is something you think you can improve. It is > much easier to debug using GDB and if something goes wrong it can easily be > restarted. > > When you have a working solution for webcamd, try to use the same solution > with the kernel. > > There is no simple 1:1 mapping for Linux APIs to FreeBSD APIs. Take for > example linux/list.h . You might think that a list can be re-implemented > and mapped to our sys/queue.h. But oh-no. Linux kernel code depends on all > the characteristics of list.h, how the structure members are stored and > named, and how foreach() macros complete with NULL or non-NULL in the > iterator. Further you'll find resistance among the Linux kernel developers > to support compilers different from GCC. I recently found a piece of code > in a header file, which works with GCC and causes a panic() when compiled > with clang. I reported it to one of the Linux kernel team members and they > didn't care about it. Even if you get everything compiling it doesn't it > will work :-( > > --HPS > > > On 06/04/17 16:35, blubee blubeeme wrote: > >> Hi Julian >> >> My goals are to port the Linux graphics stack over to FreeBSD w/o relying >> too heavily on the linuxkpi stuff. That's cool for a lot of use cases but >> it just seems a bit too brittle. >> >> It is a very large I understand the task will not be easy but I am willing >> to do the work, even from scratch if necessary although some help would be >> appreciated. >> >> I've been watching the Linux DRM project grow and while the top levels has >> changed, it's been a very long time since the actual low level stuff has >> been changed. Most of the diffs have shown changes in the >> [linux/driver/gpu/drm] layer which relies heavily on the >> [linux/include/drm] that does a lot of the heavy lifting here's a link to >> the latest version files: >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/tree/include/drm?h=v4.12-rc3 >> >> here's a diff of the latest version of the [linux/driver/gpu/drm] : >> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/lin >> ux.git/diff/?id=v4.12-rc3&id2=v4.12-rc2&dt=2 >> >> The diffs in the drivers change constantly but the lower level stuff >> hasn't >> changed as much. >> >> Doing some of the lower level translation to native FreeBSD style data >> structures then the upper part could be easily migrated, even with >> something as using AST to translate the headers to their FreeBSD >> equivalent >> without worrying about inadvertently breaking something or having major >> diffs that needs people to actively look at maintaining. >> >> That's a high level overview of my plan and what I'd like to achieve. Will >> it be easy, most likely not but once it's done FreeBSD will be just fine. >> >> Hope that helps clarify things for anyone who is interested. Any >> assistance >> would be greatly appreciated. >> >> Best, >> Owen >> >> On Sun, Jun 4, 2017 at 9:26 PM, Julian Elischer >> wrote: >> >> On 4/6/17 7:07 pm, blubee blubeeme wrote: >>> >>> Hello >>>> >>>> Is there anyone on either of these lists that have experience with both >>>> linux low level data structures and their equivalents on Fre
Re: freebsd-current Digest, Vol 711, Issue 2
I was able to sort this out by installing rust from pkg. The pkg and ports version was the same when I did it a lil while ago. Try that, then running the Firefox build again. Best, Owen On Tue, Jun 6, 2017, 20:18 Brandon Kastning wrote: > FreeBSD 12-Current Community and Developers, > > Regarding Issue #8; I too am having issues. I removed Firefox because it > was randomly closing. And upon reinstall, I was receiving the python rust > build error. > > What is the proper syntax for a build with the "--format=ustar" ? > > I apologize if I am participating incorrectly. As I am new to the > community and unix. > > Best Regards, > > Brandon Kastning > AKA. StreetDancer (IRC & Forums) > > Sent with [ProtonMail](https://protonmail.com) Secure Email. > > Original Message > Subject: freebsd-current Digest, Vol 711, Issue 2 > Local Time: June 6, 2017 5:00 AM > UTC Time: June 6, 2017 12:00 PM > From: freebsd-current-requ...@freebsd.org > To: freebsd-current@freebsd.org > > Send freebsd-current mailing list submissions to > freebsd-current@freebsd.org > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.freebsd.org/mailman/listinfo/freebsd-current > or, via email, send a message with subject or body 'help' to > freebsd-current-requ...@freebsd.org > > You can reach the person managing the list at > freebsd-current-ow...@freebsd.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of freebsd-current digest..." > > Today's Topics: > > 1. Re: old syslog (jail) and new kernel = 100% CPU (Bryan Drewery) > 2. Re: old syslog (jail) and new kernel = 100% CPU > (Ngie Cooper (yaneurabeya)) > 3. Re: Time to increase MAXPHYS? (Kenneth D. Merry) > 4. Boot CURRENT without efi (Andy Neustadter) > 5. Re: Boot CURRENT without efi (Allan Jude) > 6. Re: Time to increase MAXPHYS? (Edward Tomasz Napiera?a) > 7. Re: Boot CURRENT without efi (Toomas Soome) > 8. Re: firefox/ rust failed to install on FreeBSD 12-CURRENT > (Jean-S?bastien P?dron) > > -- > > Message: 1 > Date: Mon, 5 Jun 2017 08:20:47 -0700 > From: Bryan Drewery > To: Alexander Leidinger > Cc: curr...@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: > Content-Type: text/plain; charset="utf-8" > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > > > > Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > > -0700): > > > >> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > >>> Hi, > >>> > >>> new kernel (surely r318877 and later) and old syslog in a jail = NOK. > >>> > >> > >> What branch and revision is the syslogd? From my understanding the bug > >> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >> not released. If it was MFC'd we need to fix it before the 11.1 release. > > > > This was a syslogd from head for sure. > > > > So the issue was that for an intermediate period of time a bug was in > > syslogd in head which was causing this, and if I would have upgraded a > > system were the jail would have been head from before the or after the > > bug, then I wouldn't have noticed it? > > > > Yes, that's my understanding. So it's ultimately a non-issue for > releases since it is just a temporary issue on head. > > -- > Regards, > Bryan Drewery > > -- next part -- > A non-text attachment was scrubbed... > Name: signature.asc > Type: application/pgp-signature > Size: 473 bytes > Desc: OpenPGP digital signature > URL: < > http://lists.freebsd.org/pipermail/freebsd-current/attachments/20170605/6435eaef/attachment-0001.sig > > > > -- > > Message: 2 > Date: Mon, 5 Jun 2017 08:53:50 -0700 > From: "Ngie Cooper (yaneurabeya)" > To: Bryan Drewery > Cc: Alexander Leidinger , curr...@freebsd.org > Subject: Re: old syslog (jail) and new kernel = 100% CPU > Message-ID: <55114361-9212-49ae-a3ff-7691cadb2...@gmail.com> > Content-Type: text/plain; charset="utf-8" > > > On Jun 5, 2017, at 08:20, Bryan Drewery wrote: > > > > On 6/5/2017 2:34 AM, Alexander Leidinger wrote: > >> > >> Quoting Bryan Drewery (from Sun, 4 Jun 2017 14:38:07 > >> -0700): > >> > >>> On 6/4/17 5:09 AM, Alexander Leidinger wrote: > Hi, > > new kernel (surely r318877 and later) and old syslog in a jail = NOK. > > >>> > >>> What branch and revision is the syslogd? From my understanding the bug > >>> exists in a head version of syslogd only, maybe MFC'd to stable/11, but > >>> not released. If it was MFC'd we need to fix it before the 11.1 > release. > >> > >> This was a syslogd from head for sure. > >> > >> So the issue was that for an intermediate period of time a bug was in > >> syslogd in head which was causing this, and if I would have upgraded a > >> system were the jail would have been head from before the or after the > >> bug, then I wouldn't have noticed it? > >> > > > > Yes, that's my understanding. So it's ultimately a non
Re: nvidia drivers mutex lock
This is getting out of hand. I can't even keep x going for ten minutes sometimes. I've tested all the suggestions in this thread and they just don't work. I have put out a print of sysctl hw. here : https://paste2.org/ With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz The bios on this laptop I can either set graphics to discrete or mshybrid. I've tried in the past to disable discrete and run mshybrid but that always comes up with 0 screens found. Even just doing Xorg -configure. Anyone have some tips on disabling nvidia drivers, running this cpu with igpu for a while? Best, Owen On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > Thanks a lot! I'll give it a shot in a bit. > > Best, > Owen > > On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI wrote: > >> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. >> >> But beware! Sometimes upstream changes make any of FreeBSD patches not >> applicable (incorporating any of these, incompatible modifies, ...). >> >> For 381.22, current patchset applies and builds fine for me. >> >> >> On Sun, 04 Jun 2017 08:04:50 + >> blubee blubeeme wrote: >> >> > I'm running with svn and I build by make. >> > If in use these steps, the BSD related patches will be applied, etc? >> > >> > Best, >> > Owen >> > >> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI >> wrote: >> > >> > > Hi. >> > > >> > > Not in ports tree, but easily overridden by adding >> > > >> > > DISTVERSION=381.22 -DNO_CHECKSUM >> > > >> > > on make command line. Makefile of x11/nvidia-driver has a mechanism >> > > to do so for someone requires newer version (newer GPU support, etc.). >> > > >> > > If you're using portupgrade, >> > > >> > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f >> x11/nvidia-driver >> > > >> > > would do the same. >> > > >> > > If you installed it via pkg, there's no way to try. :-( >> > > (As it's pre-built.) >> > > >> > > >> > > On Sun, 04 Jun 2017 07:04:01 + >> > > blubee blubeeme wrote: >> > > >> > > > Hi @tomoaki >> > > > Is that version of nvidia drivers currently in the ports tree? I >> just >> > > > checked but it seems not to be. >> > > > >> > > > @jeffrey >> > > > I just generated a new xorg based on the force composition setting. >> I >> > > > merged it with my previous xorg I'll reboot, see if it gives better >> > > > performance. >> > > > >> > > > It seems like my system is locking up more frequently now. Sometimes >> > > right >> > > > after a reboot the system, the screen locks and it's reboot and >> pray. >> > > > >> > > > Best, >> > > > Owen >> > > > >> > > > On Sat, Jun 3, 2017, 21:59 Jeffrey Bouquet < >> jeffreybouq...@yahoo.com> >> > > wrote: >> > > > >> > > > > SOME LINES BOTTOM POSTED, SEE... >> > > > > >> > > > > On Fri, 6/2/17, Tomoaki AOKI wrote: >> > > > > >> > > > > Subject: Re: nvidia drivers mutex lock >> > > > > To: freebsd-current@freebsd.org >> > > > > Cc: "Jeffrey Bouquet" , "blubee >> blubeeme" < >> > > > > gurenc...@gmail.com> >> > > > > Date: Friday, June 2, 2017, 11:25 PM >> > > > > >> > > > > Hi. >> > > > > Version >> > > > > 381.22 (5 days newer than 375.66) of the driver states... >> > > > > [1] >> > > > > >> > > > > Fixed hangs and >> > > > > crashes that could occur when an OpenGL context is >> > > > > created while the system is out of available >> > > > > memory. >> > > > > >> > > > > Can this be related >> > > > > with your hang? >> > > > > >> > > > > IMHO, >> > > > > possibly allocating new resource (using os.lock_mtx >> > > > > guard) >> > > > > without checking the lock first while >> > > > >
[sed] command failure? Porting a project to FreeBSD
Hello
I am trying to bring these updated print drivers to FreeBSD:
https://github.com/utsushi/utsushi.git
There's the automake scripts in there that's sorta helpful but I seem to
have gotten stuck with something.
I made sure that my environmental variables are set
LDFLAGS -L/usr/local/lib
CPPFLAGS -I/usr/local/include
i run autoreconf -fmi
that does it's thing and everything goes smoothly
./configure also seems to run just fine
when I run make there's a problem; sed command just hangs, it's been there
for hours now and no change.
the line in the makefile looks like this:
$(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \
$(srcdir)/lib/tag.xsl
format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \
sed -n \
-e "/^/{ /-->/d; s|^$$|//|p; s|^|//|p; }' $< > $@; \
xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@
sed -i 's/SEC_N_("%1%")/"%1%"/' $@
I am not the best with sed but I feel like there might be some issues; I am
running tcsh shell, it could be it or that command is malformed.
Trying to run the same make file with gmake, I get this output.
format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
sed -n \
-e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
lib/tag.cpp; \
xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
lib/tag.cpp
sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
sed: 1: "lib/tag.cpp": extra characters at the end of l command
gmake: *** [Makefile:1042: lib/tag.cpp] Error 1
extra character at the end of | command. It's a bit unclear to me.
There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be a
sed issue.
Any assistance would be appreciated.
Best,
Owen
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [sed] command failure? Porting a project to FreeBSD
Ahhh, that was it. Doing a find and ask to replace all instances of sed
with gsed passed that part.
By the way, is knowledge like this written down somewhere centralized or is
it just floating in the ether?
Thank you,
Owen
On Wed, Jun 7, 2017, 14:26 Jov wrote:
> The default sed on FreeBSD is different from GNU sed,there is some limit
> for bsd sed.You can try to patch the makefile to using gsed.
>
> 2017-06-07 14:10 GMT+08:00 blubee blubeeme :
>
>> Hello
>>
>> I am trying to bring these updated print drivers to FreeBSD:
>> https://github.com/utsushi/utsushi.git
>>
>>
>> There's the automake scripts in there that's sorta helpful but I seem to
>> have gotten stuck with something.
>>
>> I made sure that my environmental variables are set
>> LDFLAGS -L/usr/local/lib
>> CPPFLAGS -I/usr/local/include
>>
>> i run autoreconf -fmi
>> that does it's thing and everything goes smoothly
>>
>> ./configure also seems to run just fine
>>
>> when I run make there's a problem; sed command just hangs, it's been there
>> for hours now and no change.
>>
>> the line in the makefile looks like this:
>> $(srcdir)/utsushi/tag.hpp $(srcdir)/lib/tag.cpp: $(srcdir)/lib/tag.xml \
>> $(srcdir)/lib/tag.xsl
>> format=`echo $@ | sed 's|.*\.\([^.]*\)$$|\1|'`; \
>> sed -n \
>>-e "/^/{ /-->/d; s|^$$|//|p; s|^|//|p; }' $< > $@; \
>> xsltproc --stringparam format $$format $(srcdir)/lib/tag.xsl $< >> $@
>> sed -i 's/SEC_N_("%1%")/"%1%"/' $@
>>
>> I am not the best with sed but I feel like there might be some issues; I
>> am
>> running tcsh shell, it could be it or that command is malformed.
>>
>> Trying to run the same make file with gmake, I get this output.
>>
>> format=`echo lib/tag.cpp | sed 's|.*\.\([^.]*\)$|\1|'`; \
>> sed -n \
>> -e "/^/{ /-->/d; s|^$|//|p; s|^|//|p; }' lib/tag.xml >
>> lib/tag.cpp; \
>> xsltproc --stringparam format $format ./lib/tag.xsl lib/tag.xml >>
>> lib/tag.cpp
>> sed -i 's/SEC_N_("%1%")/"%1%"/' lib/tag.cpp
>> sed: 1: "lib/tag.cpp": extra characters at the end of l command
>> gmake: *** [Makefile:1042: lib/tag.cpp] Error 1
>>
>> extra character at the end of | command. It's a bit unclear to me.
>>
>> There's a tags.xml and tags.xsl in the ./lib/ directory so it seems to be
>> a
>> sed issue.
>>
>> Any assistance would be appreciated.
>>
>> Best,
>> Owen
>>
> ___
>> freebsd-current@freebsd.org mailing list
>> https://lists.freebsd.org/mailman/listinfo/freebsd-current
>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org
>> "
>>
>
>
___
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"
[libltdl] removal from gnu ports
Hi I'm sure I was reading yesterday on a different machine about the linker flag -ld which has something to do with gnu dlopen and how it's ok to remove those from your Makefile since FreeBSD handles dlopen and a few other things from that header in the standard libc. Is that correct? I'm seeing some errors when running make because of #include LT_CONFIG_H Those files in this instance also handles dlopen and related system calls. It should also be safe up remove those "ltdl" headers from the Makefile as well? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: nvidia drivers mutex lock
I was just looking through dmesg and noticed these: Jun 6 21:40:52 blubee kernel: nvidia-modeset: Allocated GPU:0 (GPU-54a7b304-c99d-efee-0117-0ce119063cd6) @ PCI::01:00.0 Jun 6 21:41:05 blubee kernel: NVRM: GPU at PCI::01:00: GPU-54a7b304-c99d-efee-0117-0ce119063cd6 Jun 6 21:41:05 blubee kernel: NVRM: GPU Board Serial Number: Jun 6 21:41:05 blubee kernel: NVRM: Xid (PCI::01:00): 79, GPU has fallen off the bus. Jun 6 21:41:05 blubee kernel: Jun 6 21:41:05 blubee kernel: NVRM: GPU at :01:00.0 has fallen off the bus. Jun 6 21:41:05 blubee kernel: NVRM: GPU is on Board . Jun 6 21:41:05 blubee kernel: NVRM: A GPU crash dump has been created. If possible, please run Jun 6 21:41:05 blubee kernel: NVRM: nvidia-bug-report.sh as root to collect this data before Jun 6 21:41:05 blubee kernel: NVRM: the NVIDIA kernel module is unloaded. Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x927c:0:0:0x000f Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x927c:0:0:0x000f Jun 6 21:41:05 blubee kernel: vgapci0: child nvidia0 requested pci_enable_io Jun 6 21:41:05 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x927c:0:0:0x000f Jun 6 21:41:06 blubee kernel: nvidia-modeset: ERROR: GPU:0: Failed to query display engine channel state: 0x927c:0:0:0x000f Jun 6 21:41:22 blubee kernel: . then that lead me to this nvidia forum thread: https://devtalk.nvidia.com/default/topic/985037/gtx-1070-quot-gpu-has-fallen-off-the-bus-quot-running-3d-games-in-arch-linux-/ maybe it could help somehow? Best, Owen On Tue, Jun 6, 2017 at 10:08 PM, blubee blubeeme wrote: > This is getting out of hand. I can't even keep x going for ten minutes > sometimes. > I've tested all the suggestions in this thread and they just don't work. > > I have put out a print of sysctl hw. here : https://paste2.org/ > > With this CPU: hw.model: Intel(R) Core(TM) i7-6700HQ CPU @ 2.60GHz > The bios on this laptop I can either set graphics to discrete or mshybrid. > > I've tried in the past to disable discrete and run mshybrid but that > always comes up with 0 screens found. Even just doing Xorg -configure. > > Anyone have some tips on disabling nvidia drivers, running this cpu with > igpu for a while? > > Best, > Owen > > On Sun, Jun 4, 2017, 18:11 blubee blubeeme wrote: > >> Thanks a lot! I'll give it a shot in a bit. >> >> Best, >> Owen >> >> On Sun, Jun 4, 2017, 16:59 Tomoaki AOKI >> wrote: >> >>> Yes. FreeBSD patches in x11/nvidia-drivers/files are applied as usual. >>> >>> But beware! Sometimes upstream changes make any of FreeBSD patches not >>> applicable (incorporating any of these, incompatible modifies, ...). >>> >>> For 381.22, current patchset applies and builds fine for me. >>> >>> >>> On Sun, 04 Jun 2017 08:04:50 + >>> blubee blubeeme wrote: >>> >>> > I'm running with svn and I build by make. >>> > If in use these steps, the BSD related patches will be applied, etc? >>> > >>> > Best, >>> > Owen >>> > >>> > On Sun, Jun 4, 2017, 15:53 Tomoaki AOKI >>> wrote: >>> > >>> > > Hi. >>> > > >>> > > Not in ports tree, but easily overridden by adding >>> > > >>> > > DISTVERSION=381.22 -DNO_CHECKSUM >>> > > >>> > > on make command line. Makefile of x11/nvidia-driver has a mechanism >>> > > to do so for someone requires newer version (newer GPU support, >>> etc.). >>> > > >>> > > If you're using portupgrade, >>> > > >>> > > portupgrade -m 'DISTVERSION=381.22 -DNO_CHECKSUM' -f >>> x11/nvidia-driver >>> > > >>> > > would do the same. >>> > > >>> > > If you installed it via pkg, there's no way to try. :-( >>> > > (As it's pre-built.) >>> > > >>> > > >>> > > On Sun, 04 Jun 2017 07:04:01 + >>> > > blubee blubeeme wrote: >>> > > >>> > > > Hi @tomoaki >>> > > > Is that version of nvidia drivers currently in the ports tree? I >>> just >>> > > > checked but it seems not to be. >>> > > > >>> > > > @jeffrey >>> > > > I just generated a new xorg based on the force composition >>> setting. I >>> &g
autoreconf missing boost?
Hi I'm running a autoreconf trying to port a project; some printer code. Having a bit of trouble. I ran autoreconf -fi then I do: ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld --with-libintl-prefix=/usr/local that goes straight forward. Then when I run gmake, it seems to fail at linking boost or something like that. Here's the output of gmake, i've tried both make and gmake: me@blubee:~/Downloads/Epson/ut % gmake gmake all-recursive gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' Making all in . gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' Making all in lib gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' Making all in . gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' CXX connexion.lo In file included from connexion.cpp:32:0: /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a type typedef __vm_ooffset_t vm_ooffset_t; ^ /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a type typedef __vm_pindex_t vm_pindex_t; ^ In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, from /usr/local/include/boost/core/demangle.hpp:39, from /usr/local/include/boost/core/typeinfo.hpp:119, from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, from /usr/local/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, from /usr/local/include/boost/smart_ptr/detail/sp_counted_base.hpp:54, from /usr/local/include/boost/smart_ptr/detail/shared_count.hpp:29, from /usr/local/include/boost/smart_ptr/shared_ptr.hpp:28, from /usr/local/include/boost/shared_ptr.hpp:17, from /usr/local/include/boost/filesystem/path.hpp:29, from /usr/local/include/boost/filesystem.hpp:16, from connexion.cpp:40: /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: error: expected initializer before '__nonnull' int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ ^ In file included from /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, from /usr/local/lib/gcc49/include/c++/ios:42, from /usr/local/lib/gcc49/include/c++/ostream:38, from /usr/local/lib/gcc49/include/c++/iostream:39, from connexion.cpp:38: /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_once) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_getspecific) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_setspecific) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* (*)(void*), void*)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_create) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:106:1: error: 'int __gthrw_pthread_join(pthread_t, void**)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_join) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:107:1: error: 'int __gthrw_pthread_equal(pthread_t, pthread_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_equal) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:108:1: error: 'pthread* __gthrw_pthread_self()' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_self) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:109:1: error: 'int __gthrw_pthread_detach(pthread_t)' declared 'static' but never defined [-Werror=unused-function] __gthrw(pthread_detach) ^ /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:111:1: error: 'int __gthrw_pthread_cancel(pthread_t)' declared 'static' but never defined [-Werror=unused-func
Re: autoreconf missing boost?
I forgot to add this in my last email, here's the boost packages that I have installed. me@blubee:~ % pkg info | grep boost boost-jam-1.64.0 Build tool from the boost.org boost-libs-1.64.0 Free portable C++ libraries (without Boost.Python) boost-python-libs-1.62.0 Framework for interfacing Python and C++ boost_build-2.0.m12_4 Extensible cross-platform build tool suite On Thu, Jun 8, 2017 at 11:56 PM, blubee blubeeme wrote: > Hi > > I'm running a autoreconf trying to port a project; some printer code. > Having a bit of trouble. > > I ran autoreconf -fi > > then I do: > ./configure --with-ltdl-include=/usr/local/share/libtool --with-gnu-ld > --with-libintl-prefix=/usr/local > > that goes straight forward. > > Then when I run gmake, it seems to fail at linking boost or something like > that. Here's the output of gmake, i've tried both make and gmake: > me@blubee:~/Downloads/Epson/ut % gmake > gmake all-recursive > gmake[1]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' > Making all in . > gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut' > gmake[2]: Leaving directory '/usr/home/blubee/Downloads/Epson/ut' > Making all in lib > gmake[2]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' > Making all in . > gmake[3]: Entering directory '/usr/home/blubee/Downloads/Epson/ut/lib' > CXX connexion.lo > In file included from connexion.cpp:32:0: > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ > include-fixed/sys/types.h:266:9: error: '__vm_ooffset_t' does not name a > type > typedef __vm_ooffset_t vm_ooffset_t; > ^ > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/ > include-fixed/sys/types.h:268:9: error: '__vm_pindex_t' does not name a > type > typedef __vm_pindex_t vm_pindex_t; > ^ > In file included from /usr/local/lib/gcc49/include/c++/cstdlib:72:0, > from /usr/local/include/boost/core/demangle.hpp:39, > from /usr/local/include/boost/core/typeinfo.hpp:119, > from /usr/local/include/boost/detail/sp_typeinfo.hpp:20, > from /usr/local/include/boost/ > smart_ptr/detail/sp_counted_base_gcc_x86.hpp:27, > from /usr/local/include/boost/ > smart_ptr/detail/sp_counted_base.hpp:54, > from /usr/local/include/boost/ > smart_ptr/detail/shared_count.hpp:29, > from /usr/local/include/boost/ > smart_ptr/shared_ptr.hpp:28, > from /usr/local/include/boost/shared_ptr.hpp:17, > from /usr/local/include/boost/filesystem/path.hpp:29, > from /usr/local/include/boost/filesystem.hpp:16, > from connexion.cpp:40: > /usr/local/lib/gcc49/gcc/x86_64-portbld-freebsd12.0/4.9.4/include-fixed/stdlib.h:192:46: > error: expected initializer before '__nonnull' > int posix_memalign(void **, size_t, size_t) __nonnull(1); /* (ADV) */ > ^ > In file included from /usr/local/lib/gcc49/include/ > c++/x86_64-portbld-freebsd12.0/bits/gthr.h:148:0, > from /usr/local/lib/gcc49/include/c++/ext/atomicity.h:35, > from /usr/local/lib/gcc49/include/c++/bits/ios_base.h:39, > from /usr/local/lib/gcc49/include/c++/ios:42, > from /usr/local/lib/gcc49/include/c++/ostream:38, > from /usr/local/lib/gcc49/include/c++/iostream:39, > from connexion.cpp:38: > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:101:1: > error: 'int __gthrw_pthread_once(pthread_once_t*, void (*)())' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_once) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:102:1: > error: 'void* __gthrw_pthread_getspecific(pthread_key_t)' declared > 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_getspecific) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:103:1: > error: 'int __gthrw_pthread_setspecific(pthread_key_t, const void*)' > declared 'static' but never defined [-Werror=unused-function] > __gthrw(pthread_setspecific) > ^ > /usr/local/lib/gcc49/include/c++/x86_64-portbld-freebsd12.0/bits/gthr-default.h:105:1: > error: 'int __gthrw_pthread_create(pthread**, pthread_attr* const*, void* > (*)(void*), void*)' declared 'static' but never defined > [-Werror=unused-function] > __gthrw(pthread_create) > ^ &
xsltproc outputting nothing
I tried sending this email to the gnome mailing list but no responses. Can possibly get some help with this here: === Hi I am trying to convert a .xsl file to a hpp file but the output is only a blank file. Here's the commands that I am running: xsltproc --verbose --stringparam format hpp ./lib/tag.xsl > TAGS.hpp creating dictionary for stylesheet reusing dictionary from ./lib/tag.xsl for stylesheet xsltParseStylesheetProcess : found stylesheet xsltPrecomputeStylesheet: removing ignorable blank node xsltParseTemplateContent: removing text xsltCompilePattern : parsing 'tags' xsltCompilePattern : parsed tags, default priority 0.00 added pattern : 'tags' priority 0.00 parsed 1 templates Resolving attribute sets references freeing dictionary from stylesheet here's the tags.xsl file: http://www.w3.org/1999/XSL/Transform";> // Automatically generated from lib/tag.xml using lib/tag.xsl. #ifndef utsushi_tag_hpp_ #define utsushi_tag_hpp_ #include#include #include "key.hpp" #include "string.hpp" namespace utsushi { struct tag { //! Collect options and groups by the aspects they affect /*! A %tag::symbol is a string-like key that can be used to indicate * which aspects are affected by an option or group. An option may * specify zero or more %tag symbols. * * Similar to a descriptor, every %tag::symbol provides name() and * text() accessors describing its purpose. A user interface may * use this information to provide a more human-oriented and mostly * self-documenting view of tags. * * \note The UI is responsible for the translation of name() and * text() as well as any formatting of the text(). * * \sa descriptor::name(), descriptor::text() */ class symbol : boost::totally_ordered< symbol > { public: symbol (const key& key, const string& name, const string& text); //! \copybrief descriptor::name const string& name () const; //! \copybrief descriptor::text const string& text () const; bool operator== (const symbol& ts) const; bool operator< (const symbol& ts) const; operator key () const; private: key key_; string name_; string text_; }; static const symbol none; static const symbol ; }; class tags { private: typedef std::set< tag::symbol > container_type; static container_type set_; static void initialize (); public: typedef container_type::size_type size_type; typedef container_type::const_iterator const_iterator; static size_type count (); static const_iterator begin (); static const_iterator end (); }; } // namespace utsushi #endif /* utsushi_tag_hpp_ */ // Automatically generated from tag.xml using tag.xsl. #ifdef HAVE_CONFIG_H #include #endif #include "utsushi/i18n.hpp" #include "utsushi/tag.hpp" namespace utsushi { tag::symbol::symbol (const key& key, const string& name, const string& text) : key_(key), name_(name), text_(text) {} const string& tag::symbol::name () const { return name_; } const string& tag::symbol::text () const { return text_; } bool tag::symbol::operator== (const symbol& ts) const { return key_ == ts.key_; } bool tag::symbol::operator< (const tag::symbol& ts) const { return key_ < ts.key_; } tag::symbol::operator key () const { return key_; } const tag::symbol tag:: ( "_", SEC_N_(""), CCB_N_("") ); tags::container_type tags::set_; void tags::initialize () { container_type::iterator hint = set_.begin (); hint = set_.insert (hint, tag::); } tags::size_type tags::count () { if (set_.empty ()) { initialize (); } return set_.size (); } tags::const_iterator tags::begin () { if (set_.empty ()) { initialize (); } return set_.begin (); } tags::const_iterator tags::end () { if (set_.empty ()) { initialize (); } return set_.end (); } } // namespace utsushi Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
autotools failing
Hi I just started to run into this problem with autotools. I am getting this error running autoreconf -fi here's the end of the output before unsuccessful exit: --- configure.ac:54: error: possibly undefined macro: AS_IF If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:56: error: possibly undefined macro: AC_MSG_NOTICE configure.ac:221: error: possibly undefined macro: AC_MSG_ERROR autoreconf-2.69: /usr/local/bin/autoconf-2.69 failed with exit status: 1 --- = installed packages = Coin-3.1.3_11 = FreeCAD-0.17.g20170310_4 = ORBit2-2.14.19_2 = SoQt-1.5.0_6 = adwaita-icon-theme-3.22.0 = alsa-lib-1.1.2 = alsa-plugins-1.1.1_1 = apiextractor-0.10.10_3 = appres-1.0.4 = apr-1.5.2.1.5.4_2 = arandr-0.1.9 = argyllcms-1.9.2_1 = at-spi2-atk-2.24.0 = at-spi2-core-2.24.0= atk-2.24.0 = autoconf-2.69_1= autoconf-wrapper-20131203 = autoconf213-2.13.000227_6 = automake-1.15_1= automake-wrapper-20131203 = autotools-20130627 = avahi-app-0.6.31_5 = bash-4.4.12_2 = binutils-2.28,1= bison-3.0.4,1 = bitmap-1.0.8 = blas-3.5.0_3 = boost-all-1.64.0 = boost-docs-1.64.0 = boost-jam-1.64.0 = boost-libs-1.64.0 = boost-python-libs-1.64.0 = ca_root_nss-3.31 = cairo-1.14.8_1,2 = cargo-0.17.0 = cblas-1.0_6= chromium-58.0.3029.110_2 = cmake-3.8.2= cmake-modules-3.8.2= colord-1.2.12 = compositeproto-0.4.2 = compton-20160907_2 = cups-2.2.3 = curl-7.54.0< cvsps-2.1_2= damageproto-1.2.1 = db5-5.3.28_6 = dbus-1.10.16_1 = dbus-glib-0.108= dconf-0.24.0_1 = dejavu-2.37= desktop-file-utils-0.23= dialog4ports-0.1.6 = dmenu-4.7 = dmxproto-2.3.1 = dotconf-1.3_1 = dri2proto-2.8 = dri3proto-1.0 = droid-fonts-ttf-20131024_3 = dunst-1.1.0= encodings-1.0.4_3,1= espeak-1.48.04_2 = expat-2.2.0_1 = feh-2.18 = ffmpeg-3.3.2,1 = firefox-54.0,1 = firefox-i18n-54.0 = fixesproto-5.0 = flac-1.3.2 = font-adobe-100dpi-1.0.3_3 = font-adobe-75dpi-1.0.3_3 = font-adobe-utopia-100dpi-1.0.4_3 = font-adobe-utopia-75dpi-1.0.4_3= font-adobe-utopia-type1-1.0.4_3= font-alias-1.0.3_3 = font-arabic-misc-1.0.3_3 = font-bh-100dpi-1.0.3_3 = font-bh-75dpi-1.0.3_3 = font-bh-lucidatypewriter-100dpi-1.0.3_3 = font-bh-lucidatypewriter-75dpi-1.0.3_3 = font-bh-ttf-1.0.3_3= font-bh-type1-1.0.3_3 = font-bitstream-100dpi-1.0.3_3 = font-bitstream-75dpi-1.0.3_3 = font-bitstream-type1-1.0.3_3 = font-cronyx-cyrillic-1.0.3_3 = font-cursor-misc-1.0.3_3 = font-daewoo-misc-1.0.3_3 = font-dec-misc-1.0.3_3 = font-ibm-type1-1.0.3_3 = font-isas-misc-1.0.3_3 = font-jis-misc-1.0.3_3 = font-micro-misc-1.0.3_3= font-misc-cyrillic-1.0.3_3 = font-misc-ethiopic-1.0.3_3 = font-misc-meltho-1.0.3_3 = font-misc-misc-1.1.2_3 = font-mutt-misc-1.0.3_3 = font-schumacher-misc-1.1.2_3 = font-screen-cyrillic-1.0.4_3 = font-sony-misc-1.0.3_3 = font-sun-misc-1.0.3_3 = font-util-1.3.1= font-winitzki-cyrillic-1.0.3_3 = font-xfree86-type1-1.0.4_3 = fontcacheproto-0.1.3 = fontconfig-2.12.1,1= fontsproto-2.1.3,1 = fr-med-3.2.0_2 = freeimage-3.16.0_2 = freetype2-2.8 = ftgl-2.1.3.r5_6,1 = gcc-ecj-4.5= gcc5-5.4.0_2 = gconf2-3.2.6_5
.configure && make fails to find ld [dlopen]
I am porting some software and it's getting tripped up with dlopen. I run autoreconf -fi and it asks me to add AC_CONFIG_MACRO_DIRS([m4]) to my configure.ac file, which I do. It creates a ./m4 directory and proceeds. After running .configure --prefix=/tmp [for testing] that' also goes fine, except .configure cannot find dlopen checking for dlopen in -ldl... no make also fails when it comes time to link because of the dlopen although it's a part of FreeBSD libc manually running ld -ld I get this output: https://pastebin.com/Rzfajnk0 The relevant parts of my env looks like this: https://pastebin.com/uJJ7BqDg Is there anything that I am missing why configure can't find ld? Best, Owen ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: .configure && make fails to find ld [dlopen]
Thanks for the reply, I haven't set any -static in my env variables or
anything like that. Here's a brief output of my env
1. OSTYPE=FreeBSD
2. MACHTYPE=x86_64
3. CC=clang
4. PATH=/sbin:/bin:/usr/sbin:/usr/bin:/usr/local/sbin:/usr/local/bin
5. EDITOR=vi
6. LDFLAGS=-L/usr/local/lib
7. LD_LIBRARY_PATH=/usr/local/llvm38/lib
8. CPPFLAGS=-I/usr/local/include
9. CXX=clang++
10. SHELL=/bin/tcsh
11. HOSTTYPE=FreeBSD
12. CFLAGS=-I/usr/local/include
the linking to ldl is being done automatically since I call autoreconf -fi
and that sets up an m4 directory. grep -rn "\-ldl" in the root of the
source folder shows that the built in configure script and the scripts in
the m4 directory sets up those dlopen link example
# if libdl is installed we need to link against it
{ $as_echo "$as_me:${as_lineno-$LINENO}: checking for dlopen in -ldl"
>&5
$as_echo_n "checking for dlopen in -ldl... " >&6; }
if ${ac_cv_lib_dl_dlopen+:} false; then :
$as_echo_n "(cached) " >&6
else
ac_check_lib_save_LIBS=$LIBS
LIBS="-ldl $LIBS"
cat confdefs.h - <<_ACEOF >conftest.$ac_ext
those are sprinkled all over the place, how do I avoid that and use libc
instead?
Best,
Owen
On Thu, Jul 6, 2017 at 8:14 AM, Simon J. Gerraty wrote:
> blubee blubeeme wrote:
> > I run autoreconf -fi and it asks me to add AC_CONFIG_MACRO_DIRS([m4]) to
> my
> > configure.ac file, which I do. It creates a ./m4 directory and proceeds.
> >
> > After running .configure --prefix=/tmp [for testing] that' also goes
> fine,
> > except .configure cannot find dlopen
> > checking for dlopen in -ldl... no
>
> dlopen is actually implemeted in the rtld - so you need to link at least
> one shared lib (usually libc) to get it.
>
> > make also fails when it comes time to link because of the dlopen although
> > it's a part of FreeBSD libc
>
> Check that you don't have -static or equivalent in CFLAGS/LDFLAGS.
>
___
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"
