Re: Recent -CURRENT unable to build numerous ports
On, Fri Oct 21, 2016, Dimitry Andric wrote: > On 21 Oct 2016, at 20:47, Marcus von Appen <m...@freebsd.org> wrote: > > > > -CURRENT as of r307731 seems to have some serious flaw with its build > > tool environment. Many ports fail to build with some error similar to > > the following (devel/apr1): > > > > cc -emit-llvm -fno-strict-aliasing -pipe -march=native -DLIBICONV_PLUG > > -fstack-protector -c -o .c.bco > > cc: error: no input files > > *** [.c.bco] Error code 1 > > [...] > > > > Since not all ports are affected, I assume some auto[conf|tool|make] > > issue to be triggered. Hints for getting this one solved are highly > > appreciated. > > This was a side-effect of r307676, which added transformation rules for > .bco and .llo files (LLVM bytecode in binary and text representation). > > Because .SUFFIXES was not updated to match, bmake was actually trying to > build a ".c.bco" file in the above case... > > I committed a fix in r307754. Thanks, everything seems to be back to normal for me now! Cheers Marcus signature.asc Description: PGP signature
Re: Recent -CURRENT unable to build numerous ports
On, Fri Oct 21, 2016, Marcus von Appen wrote: > Hi, > > -CURRENT as of r307731 seems to have some serious flaw with its build > tool environment. Many ports fail to build with some error similar to > the following (devel/apr1): > > cc -emit-llvm -fno-strict-aliasing -pipe -march=native -DLIBICONV_PLUG > -fstack-protector -c -o .c.bco > cc: error: no input files > *** [.c.bco] Error code 1 > [...] > > Since not all ports are affected, I assume some auto[conf|tool|make] > issue to be triggered. Hints for getting this one solved are highly > appreciated. > After some more testing, it seems to relate to our default make. Switching MAKE to gmake seems to resolve the issue. A simple test case: 1. create an empty Makefile 2. run make Cheers Marcus signature.asc Description: PGP signature
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote: > Hi everyone, > > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged > into a > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is > available on https://github.com/s3erios/rtwn repository. Among bugfixes / > code deduplication, there some new features too: [...] It took a while to test both, the github version as well as the most recent version on -CURRENT (r307731) with my RTL8188CE (PCI). The github version worked well until 2016-09-05 (commit 580cef). Throughput was limited to around 400 kbit/s. The next test from 2016-09-16 (commit a018e741) caused a better throughput, mostly up to around 1.2 Mbit/s. Its stability was bad, though. Kernel panics as well as random lockups of the interface struck often. The version as of r307731 in -CURRENT is just as bad. It feels as if the stability improvements from r302035 have been reverted. What can I do to help you to improve the situation? Cheers Marcus signature.asc Description: PGP signature
Recent -CURRENT unable to build numerous ports
Hi, -CURRENT as of r307731 seems to have some serious flaw with its build tool environment. Many ports fail to build with some error similar to the following (devel/apr1): cc -emit-llvm -fno-strict-aliasing -pipe -march=native -DLIBICONV_PLUG -fstack-protector -c -o .c.bco cc: error: no input files *** [.c.bco] Error code 1 [...] Since not all ports are affected, I assume some auto[conf|tool|make] issue to be triggered. Hints for getting this one solved are highly appreciated. Cheers Marcus signature.asc Description: PGP signature
Re: urtwn(4) / rtwn(4) drivers are merged - call for testing (Was: RTL8812AU / RTL8821AU driver)
On, Thu Sep 01, 2016, Andriy Voskoboinyk wrote: > Hi everyone, > > rtwn(4), urtwn(4) and urtwm (from previous emails) drivers were merged > into a > single rtwn driver (plus rtwn_usb / rtwn_pci device glue); the code is > available on https://github.com/s3erios/rtwn repository. Among bugfixes / > code deduplication, there some new features too: > > 1) multi-vap support (one any wireless interface + one STA interface + > any number of monitor mode interfaces). > 2) few new sysctls: > * dev.rtwn.#.crypto - controls how to use hardware crypto acceleration > * dev.rtwn.#.ratectl_selected > * dev.rtwn.#.ratectl - selects current 'rate control' algorithm > (currently only 'none' and 'net80211' are supported; RTL8192CE needs > testing > with the last). I got a RTL8192CE - what should I look for, when using net80211? Cheers Marcus signature.asc Description: PGP signature
Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035
On, Mon Jun 27, 2016, Andriy Voskoboinyk wrote: > Mon, 27 Jun 2016 20:06:20 +0300 було написано Marcus von Appen > <m...@freebsd.org>: > > Hi, > > the attached patch may fix this issue (probably) I'm getting downstream rates of around 300 to 500 kbit/s, so it's not much more than before, although the downstream rates seem to be a bit more stable now. [...] > > > > Let me know, what information is necessary to isolate and correct > > that issue. I'll gladly test it. :-) > > You can check number of input errors (netstat -I wlan0); it should be > relatively small (or even zero). It's zero with your patch; I do not have values from before at hand right now, but can provide them later on, should they be of interest. Cheers Marcus signature.asc Description: PGP signature
Re: Restarting rtwn(0)-based interface causes reproducible kernel panics
On, Mon Jun 27, 2016, Otacílio wrote: [...] > What is the revision that you are using? I have faced a similar problem > on APLHA4, but now, on ALPHA5 it is working fine. FreeBSD 11.0-ALPHA5 #3 r302191M: Sat Jun 25 14:21:12 CEST 2016 Note that rtwn and urtwn are using different firmware and a slightly different driver implementations. Cheers Marcus signature.asc Description: PGP signature
Re: Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035
On, Mon Jun 27, 2016, Adrian Chadd wrote: > Heh, there isn't any 11n support in rtwn (and won't be until I unify > rtwn and urtwn post-11.) I do not know about that. My experience from pre-r302035 were 1-2 Mbit/s downstream from some servers, but often enough just for a minute or two before everything stopped working. > > I'll go find the rtwn NIC and see if I can figure out what's going on. Let me know, if and how I can assist with it. Cheers Marcus signature.asc Description: PGP signature
Restarting rtwn(0)-based interface causes reproducible kernel panics
Hi, restarting the network interface for my rtwn(0)-based RTL8188CE card causes a reproducible kernel panic: # service netif restart [...] panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 0xf80005c22800 [...] Unread portion of the kernel message buffer: panic: Memory modified after free 0xf80005c22800(2048) val=8018 @ 0xf80005c22800 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe045362b670 vpanic() at vpanic+0x186/frame 0xfe045362b6f0 panic() at panic+0x43/frame 0xfe045362b750 trash_ctor() at trash_ctor+0x4b/frame 0xfe045362b760 mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe045362b7a0 uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe045362b800 ieee80211_getmgtframe() at ieee80211_getmgtframe+0x120/frame 0xfe045362b840 ieee80211_send_probereq() at ieee80211_send_probereq+0x104/frame 0xfe045362b8e0 ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 0xfe045362b920 scan_curchan() at scan_curchan+0x68/frame 0xfe045362b960 scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe045362b9e0 taskqueue_run_locked() at taskqueue_run_locked+0x13c/frame 0xfe045362ba40 taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe045362ba70 fork_exit() at fork_exit+0x84/frame 0xfe045362bab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe045362bab0 [...] and (probably) a variant: # service netif restart [...] panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 0xf80005c07800 [...] Unread portion of the kernel message buffer: panic: Memory modified after free 0xf80005c07800(2048) val=19 @ 0xf80005c07800 cpuid = 3 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0455213540 vpanic() at vpanic+0x186/frame 0xfe04552135c0 panic() at panic+0x43/frame 0xfe0455213620 trash_ctor() at trash_ctor+0x4b/frame 0xfe0455213630 mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe0455213670 uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe04552136d0 m_getm2() at m_getm2+0x12d/frame 0xfe0455213740 m_uiotombuf() at m_uiotombuf+0x62/frame 0xfe0455213790 sosend_generic() at sosend_generic+0x356/frame 0xfe0455213850 kern_sendit() at kern_sendit+0x244/frame 0xfe0455213900 sendit() at sendit+0x1af/frame 0xfe0455213950 sys_sendto() at sys_sendto+0x4d/frame 0xfe04552139a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfe0455213ab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe0455213ab0 [...] Let me know how to help on getting this fixed. Cheers Marcus signature.asc Description: PGP signature
Bad rtwn(0) performance with RTL8188CE on -CURRENT after r302035
Hi, thanks to previous efforts, the rtwn(0) connection for my RTL8188CE wireless card is far more stable. It seems to come at the price of relatively bad performance, though. After r302035 from avos@, I can't get more than 500 kbit/s downstream from anywhere. Let me know, what information is necessary to isolate and correct that issue. I'll gladly test it. :-) Cheers Marcus signature.asc Description: PGP signature
Re: rtwn connection stops working on CURRENT
Hi Andriy, On, Tue Jun 14, 2016, Andriy Voskoboinyk wrote: > Tue, 14 Jun 2016 08:24:01 +0300 було написано Marcus von Appen > <m...@freebsd.org>: > > Hi! > > Try attached patch (adds some busdma synchronization, > unloads data instead of descriptor in rtwn_tx_done() and improves > watchdog logic for a bit). thanks a lot, the connection is far more reliable now and does not seem to stop working anymore. Cheers Marcus ___ 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"
rtwn connection stops working on CURRENT
Hi, I'm running into a somewhat weird issue with the rtwn driver on CURRENT. It usually works for a couple of minutes (if there's not too much of troughput happening) before the downstream and upstream rates just "dry up" and the interface stops working. It happens faster, if there are multiple connections open at the same time, e.g. having a browser open or fetching mail and doing a portsnap update. Once the connection stopped working, dhclient will report the following: Jun 11 12:22:22 athena dhclient[474]: send_packet: no buffer space available Jun 11 12:24:08 athena last message repeated 4 times ... wpa_supplicant reports: Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: CTRL-EVENT-DISCONNECTED bssid=... reason=3 locally_generated=1 Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: WPA: 4-Way Handshake failed - pre-shared key may be incorrect Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=8 duration=100 reason=WRONG_KEY Jun 11 12:22:20 athena wpa_supplicant[335]: wlan0: CTRL-EVENT-SSID-TEMP-DISABLED id=0 ssid="..." auth_failures=9 duration=152 reason=CONN_FAILED pciconf -lv: rtwn0@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8188CE 802.11b/g/n WiFi Adapter' class = network An pointers on tracking this issue down and getting it fixed are highly appreciated. Cheers Marcus ___ 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: rtwn(0) panics with RTL8188CE
On, Mon May 16, 2016, Marcus von Appen wrote: [...] this one seems to provide some more information. I have no idea, if both crash types are related or not. Unread portion of the kernel message buffer: rtwn0: can't map mbuf (error 12) panic: Duplicate free of 0xf800c94c1300 from zone 0xf800056c4900(mbuf_packet) slab 0xf800c94c1f90(3) cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe04535f5660 vpanic() at vpanic+0x186/frame 0xfe04535f56e0 panic() at panic+0x43/frame 0xfe04535f5740 uma_dbg_free() at uma_dbg_free+0xee/frame 0xfe04535f5770 uma_zfree_arg() at uma_zfree_arg+0x64/frame 0xfe04535f57c0 mb_free_ext() at mb_free_ext+0x155/frame 0xfe04535f57f0 m_freem() at m_freem+0x38/frame 0xfe04535f5810 rtwn_raw_xmit() at rtwn_raw_xmit+0x7b/frame 0xfe04535f5840 ieee80211_send_probereq() at ieee80211_send_probereq+0x514/frame 0xfe04535f58e0 ieee80211_swscan_probe_curchan() at ieee80211_swscan_probe_curchan+0x5a/frame 0xfe04535f5920 scan_curchan() at scan_curchan+0x68/frame 0xfe04535f5960 scan_curchan_task() at scan_curchan_task+0x247/frame 0xfe04535f59e0 taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfe04535f5a40 taskqueue_thread_loop() at taskqueue_thread_loop+0x88/frame 0xfe04535f5a70 fork_exit() at fork_exit+0x84/frame 0xfe04535f5ab0 fork_trampoline() at fork_trampoline+0xe/frame 0xfe04535f5ab0 --- trap 0, rip = 0, rsp = 0, rbp = 0 --- ___ 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"
rtwn(0) panics with RTL8188CE
Dear all, thankfully -CURRENT supports the RTL8188CE wifi chipset via rtwn(0) on the Thinkpad X230. Unfortunately the connection to the AP drops nine times out of ten after transmitting a few kb. Trying to reconnect via service netif restart will cause a panic: panic: Memory modified after free 0xf80005c50800(2048) val=19 @ 0xf80005c50800 cpuid = 0 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe04552ae540 vpanic() at vpanic+0x186/frame 0xfe04552ae5c0 panic() at panic+0x43/frame 0xfe04552ae620 trash_ctor() at trash_ctor+0x4b/frame 0xfe04552ae630 mb_ctor_pack() at mb_ctor_pack+0x3c/frame 0xfe04552ae670 uma_zalloc_arg() at uma_zalloc_arg+0x504/frame 0xfe04552ae6d0 m_getm2() at m_getm2+0x12d/frame 0xfe04552ae740 m_uiotombuf() at m_uiotombuf+0x62/frame 0xfe04552ae790 sosend_generic() at sosend_generic+0x356/frame 0xfe04552ae850 kern_sendit() at kern_sendit+0x244/frame 0xfe04552ae900 sendit() at sendit+0x126/frame 0xfe04552ae950 sys_sendto() at sys_sendto+0x4d/frame 0xfe04552ae9a0 amd64_syscall() at amd64_syscall+0x2db/frame 0xfe04552aeab0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe04552aeab0 --- syscall (133, FreeBSD ELF64, sys_sendto), rip = 0x8015aac6a, rsp = 0x7fffd6a8, rbp = 0 x7fffe3b0 --- pciconf -lv: [...] rtwn0@pci0:3:0:0: class=0x028000 card=0x819510ec chip=0x817610ec rev=0x01 hdr=0x00 vendor = 'Realtek Semiconductor Co., Ltd.' device = 'RTL8188CE 802.11b/g/n WiFi Adapter' class = network Any help on getting this fixed is highly appreciated. Cheers Marcus ___ 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: junior kernel tasks
On, Wed Oct 29, 2014, Eitan Adler wrote: On 28 October 2014 15:14, Baptiste Daroussin b...@freebsd.org wrote: On Tue, Oct 28, 2014 at 09:35:26PM +0100, Marcus von Appen wrote: Quoting John Baldwin j...@freebsd.org: On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return: - your own code in FreeBSD tree - eternal glory [1] - fun [2] If you are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a no Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. Speaking not strictly with the bugmeister hat, but from experience, please do not let us go down the road of (ab)using a bug tracking solution as task and idea management system. I think that using the tasks feature of phabricator (our reviews instance) would provide better workflow support for those things, starting out from sketching out rough ideas, discussing them, breaking them up in seperate tasks (linked to and dependent on each other) and collaborating on them (take a look at https://developer.blender.org/T42339 for a brief example). Having said this, let's keep the bug tracker a bug tracker. Cheers Marcus ___ freebsd-hack...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org I disabled the tasks on phabricator to avoid having it a duplicate of bugzilla, but if we have a use for it I can activate it! Actually I do like the idea of the bug tracker aka bugzilla being only for bugs and uxe phabricator for tracking the tasks having disparate trackers for wishlist and bugs is quite harmful and splits the conversations. It makes people learn multiple systems and search multiple places - especially if the feature ends up being submitted as a patch to the bug tracker. We have this situation right now with reviews and the bug tracker. reviews is used by the committers only right now, and both loosely interact with each other. Opening reviews to the public won't improve the situation of having two disparate systems to look into. Same goes for the Wiki and bug tracker, mailing lists, etc. The more relevant question thus would be: how do we point people to the correct location and at which point of time? This will call for a more tight integration in the foresesable future (e.g. search abilities for reviews, that can be triggered from the bug tracker and vice versa). I'd rather keep wishlist items in the bug tracker than split them into two. (also, fwiw, I'd rather keep the tasks number space clean should we ever decide to import from bugzilla - phabricator) Fair enough. If we are going to do that, the area however should be separate from typical bugs, so people do not confuse wishes with bugs and vice versa. Also, to avoid long and misleading comment trails, we would need the ability to hide/remove errornous (bug-related) comments in the wishlist (a feature wished for independent of this, but a necessary prerequisite [probably coming soon]). Wishlist items thus should not belong to a currently existing product or component, but should be clearly classified in an own product and/or component category. Except from that, what else would be required and desired to have a suitable wishlist? The bug tracker right now features: - tags - keywords - links to internal bugs/items (dependencies and blockers) - links to external systems - links to svn commits and reviews - attachments - flags to request/confirm/deny things Cheers Marcus pgpPGRbV_Fn1c.pgp Description: PGP signature
Re: junior kernel tasks
Quoting John Baldwin j...@freebsd.org: On Saturday, October 25, 2014 4:45:36 pm Mateusz Guzik wrote: Hello, In short, nice kernel tasks people with C language skills can do in few evenings. https://wiki.freebsd.org/JuniorJobs It is assumed you know how to obtain sources and build the kernel. What you can get in return: - your own code in FreeBSD tree - eternal glory [1] - fun [2] If you are not interested, but know someone who does, please pass it down. [1] - not really, no [2] - well, I guess that's subjective, so that's not a no Even though our bugmeisters have decided that we should not have wishlist items in our bug tracker, I really wish we could store the various idea lists (we have several) in an issue tracker instead. This would allow for folks to comment on ideas, vote for them, etc. It would also make it easier for more people to submit new ideas. Speaking not strictly with the bugmeister hat, but from experience, please do not let us go down the road of (ab)using a bug tracking solution as task and idea management system. I think that using the tasks feature of phabricator (our reviews instance) would provide better workflow support for those things, starting out from sketching out rough ideas, discussing them, breaking them up in seperate tasks (linked to and dependent on each other) and collaborating on them (take a look at https://developer.blender.org/T42339 for a brief example). Having said this, let's keep the bug tracker a bug tracker. Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] pkg(8) is now the only package management tool
Alban Hertroys haram...@gmail.com: On 2 September 2014 11:08, Julian Elischer jul...@freebsd.org wrote: On 9/1/14, 8:03 PM, Andrew Berg wrote: On 2014.09.01 21:39, Julian Elischer wrote: sigh.. when are we as a project, all going to learn that reality in business is that you often need to install stuff that is old. Its not always your choice. The custommers require it.. You should try arguing with someone like Bank of Americas security and operations department some day about whether they want to suddenly upgrade 300 machines for no real reason (from their perspective). FreeBSD minor version upgrades are meant to be non-disruptive. However, I will admit that I have not performed any such upgrades in a critical environment, so if you think they are disruptive, please enlighten me with the details. Also, there are options out there for getting support for extended periods if you need it. Some companies are built around providing support for things that the original developers have long abandoned because some businesses need it. It's not how disruptive they are technically. it's how many months of shakedown testing you have to go through before they allow you to put new software on any production system. Just adding here, in commercial environments things don't change quickly or easily. Whether this applies to the current issue with pkg is not for me to say. For example, certain commercial upstream software vendors require to go through a certification process before they even consider supporting the new software you intend to use with theirs. Admittedly we haven't run into this issue in relation to FreeBSD, but we certainly have with Firefox. As an example, the last version of Firefox that Information Builders' WebFOCUS 7.7 supports is 3.6.7 (currently available versions are 31 or 32!) and for Internet Explorer that's 7 (currently at 11). If you run into any kind of problem, the standard answer is to use a browser that they support. Good luck with that! Firefox 3.6.7 was released on July 20, 2010; over 4 years ago. In such cases you're more or less required to keep an old system around that still has such old packages, if only to see if you can reproduce any issues you encounter (with modern versions of your software) on those old versions. With the deprecation of the old pkg_* tools you run into a conflict; You can either update packages that are _not_ under certification for such a vendor and get security updates and fixes using the new pkg, or you have to stick with the certified software and _not_ get any security updates or fixes. It gets more interesting if you have to deal with manufacturing processes (something we're looking to use FreeBSD for to replace our current OpenVMS systems before they go out of support), as often automatons write data to external databases and such software resides in PLC's. Manufacturing equipment tends to age and the kind of external databases they support is limited to what was available when they were new and the capabilities of the PLC involved. I can totally understand that at some point it starts to get impossible to maintain two separate packaging systems and I understand that you think 2 years is enough time to shake things out, but software vendors aren't that quick. For many, 2 years is a short time. It also should be noted that everyone had enough time to raise those issues in the time between tthe announcement and now. No one did. Now that it is gone, they are brought up, while they should have been long time ago instead. It can't work that way. My 2 cents in this discussion :-). Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADSUP] pkg(8) is now the only package management tool
Brandon Allbery allber...@gmail.com: On Tue, Sep 2, 2014 at 6:52 AM, Marcus von Appen m...@freebsd.org wrote: It also should be noted that everyone had enough time to raise those issues in the time between tthe announcement and now If this is an issue that needed to be brought up, then FreeBSD has apparently never before been used in an enterprise??? I'm tempted to ask, if the enterprise has SLAs to ensure continuity, even after the official support has ended? ;-) Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
libc++ vs. libstdc++ usage in the ports tree (was: Re: Are clang++ and libc++ compatible?)
Steve Kargl s...@troutmask.apl.washington.edu: [...] Sigh. Adding USE_GCC isn't the solution. % pan Segmentation fault (core dumped) % ldd /usr/local/bin/pan | grep ++ libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x3c52bf000) libc++.so.1 = /usr/lib/libc++.so.1 (0x3c81ea000) This can't be good. And, unfortunately, testing math/octave shows no better :( % octave Segmentation fault (core dumped) % ldd /usr/local/bin/octave-3.6.4 | grep ++ libstdc++.so.6 = /usr/local/lib/gcc46/libstdc++.so.6 (0x3c92ec000) libc++.so.1 = /usr/lib/libc++.so.1 (0x3c9801000) This brings up another point into which I am running with the previously discussed blender issue. Let's assume port A_defcompiler does not specify a compiler and c++ lib, it will default to libc++ and clang++ on 10.x or newer, correct? If now a port B_gnuish depends on port A_defcompiler, but at the same defines GCC + libstdc++, the resulting binary might link against libc++ and libstdc++ at the same time. This in turn makes the port unusable. The same applies to the other way around. Right now we do not have mechanism to detect and handle those flaws. Maintainers might be even less aware of those issues. Does anyone know a proper way to deal with this at the moment on 10.x+ or is this something that was missed until now? Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Light humour
Joshua Isom jri...@gmail.com: [...] BSD: If you love something, set it free. If it comes back to you, it was meant to be. GPL: If you love something, set if free, but put a chain around it's neck to make sure it doesn't get out of sight. One of the best to-the-point explanations, brilliant! Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: [HEADS-UP] BSD sort is the default sort in -CURRENT
Daniel Gerzo dan...@freebsd.org: On 27.06.2012 10:43, Doug Barton wrote: On 06/27/2012 02:09 AM, Oleg Moskalenko wrote: Doug, I'll post some performance figures, probably tomorrow. That's great, thanks. But I do not agree with you that we have to reproduce the old sort bugs. It makes no sense and I am not going to do that. Absolutely not. That isn't what I said. What I asked is for you to *test* the existing sort vs. the new one, and to report where the behavior is different. That's a very basic part of any sort of replace a core utility project such as this one. [ snip ] Doug, are you implying that if we were about to import a new version of GNU sort, you would be asking for the same data? I believe we do not make this kind of work with any vendor code that is being updated in the base; I do not really understand why should Oleg or anyone else do this work when the bsdsort is compatible with a recent version of GNU sort. Seconded for -CURRENT. I think, we should at least provide some brief document, whatsoever on incompatibilities with the sort implementation that is currently active in RELENG_9, no matter how buggy it is. This allows adopters and people, who have to migrate their production systems to identify and quantify the areas to change and perform some risk management. This also allows them to move more quickly to the new release, since they can start with the necessary changes earlier and plan ahead. We provide such changes usually in the release notes for various tools, we updated and I think that giving out such a document earlier will be extremely benefitial for companies, which have to deal with more than one or two servers running FreeBSD, especially if we know that the currently shipped implementation is buggy and people most likely will have their own workarounds for that. Cheers Marcus ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
uhid(4) and report structures
Hi, I wonder, if I am correct with my assumption that the usb_ctl_report* structures mentioned in uhid(4) have to be defined and created by the code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(), ... calls. In FreeBSD 800063 we defined them in the header files of the USB subsystem. After the rewrite those struct definitions vanished. Will the USB_ macros mentioned in uhid(4) just return a byte sequence (that's what I understand from the UHID specification) so that code, which uses those calls, can implement its own struct container for the information retrieved? Thanks for shedding some light on this. In case i am correct with what I wrote above, it might make sense to mention it in uhid(4). Best regards Marcus pgpJsCrM03DjF.pgp Description: PGP signature
Re: uhid(4) and report structures
On, Tue Nov 15, 2011, Alexander Motin wrote:
On 15.11.2011 21:29, Marcus von Appen wrote:
I wonder, if I am correct with my assumption that the usb_ctl_report*
structures mentioned in uhid(4) have to be defined and created by the
code portion that uses the USB_GET_REPORT(), USB_SET_REPORT(),
... calls.
In FreeBSD 800063 we defined them in the header files of the USB
subsystem. After the rewrite those struct definitions vanished. Will
the USB_ macros mentioned in uhid(4) just return a byte sequence
(that's what I understand from the UHID specification) so that code,
which uses those calls, can implement its own struct container for the
information retrieved?
Thanks for shedding some light on this. In case i am correct with what I
wrote above, it might make sense to mention it in uhid(4).
In new USB stack these calls use struct usb_gen_descriptor argument.
Difficult to say why it was done, but it was. To hide that I've recently
added two wrapper functions to the libusbhid in HEAD: hid_get_report()
and hid_set_report().
So the man page is currently not up to date and can - at least for now -
be assumed to be wrong?
To get the mappings correct, which fields would I have to use from
usb_gen_descriptor? Earlier we had:
struct usb_ctl_report {
int ucr_report;
u_char ucr_data[1024];
};
The mapping might be:
usb_gen_descriptor.ugd_data == usb_ctl_report.ucr_data
usb_gen_descriptor.ugd_report_type == usb_ctl_report.ucr_report
Is that correct? Also, ugd_data is of variable size with ugd_actlen
indicating the size of the ugd_data buffer?
Best regards
Marcus
pgpWVPJ1tOWqP.pgp
Description: PGP signature
