Re: HEADSUP: /etc/malloc.conf format change
On Wed, Apr 25, 2012 at 09:37:36PM -0700, Tim Kientzle wrote: > The Ports maintainers will run "experimental" ports builds on the > port build clusters to help verify potentially disruptive changes > like this before they are committed. Well, actually, portmgr@. Send a PR with [exp-run] in the Synopsis and assign it to portmgr. We are slowly trying to get caught up, now that we have new hardware. mcl ___ 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: /etc/malloc.conf format change
On Apr 25, 2012, at 10:43 AM, Jason Evans wrote: > > On a related note, is there any way to find all ports that refer to > _malloc_options without extracting source for all of them? I considered > being proactive about finding software that depends on _malloc_options, but > no tractable approaches came to mind. Yes, there actually is. The Ports maintainers will run "experimental" ports builds on the port build clusters to help verify potentially disruptive changes like this before they are committed. Ask on ports@ for more details. Tim ___ 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: Status on X220
On (23/04/2012 08:16), Ganael LAPLANCHE wrote: > On Fri, 20 Apr 2012 08:14:17 +0200, Lars Engels wrote > > Hi everyone, > > > This is the same for my x200, but you can make it work: > > On 9.0-RELEASE you have to configure through device.hints(5), > > in CURRENT you can configure it on thy fly. See snd_hda(4) > > how to do this. > > FYI, this is what I had to put in /boot/devices.hint to have headset > working properly on my x220 (on 10-CURRENT) : > > # Out : speaker + headphones > # hint.hdac.0.cad0.nid31.config="as=1" > hint.hdac.0.cad0.nid25.config="as=1 seq=15" > # In : mic + external mic > hint.hdac.0.cad0.nid35.config="as=2" > hint.hdac.0.cad0.nid27.config="as=2 seq=15" Just for the record, it also works for ThinkPad T520. I've always been too lazy to read man page myself ;) Thanks! ___ 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: Status on X220
On Mon, Apr 23, 2012 at 1:16 AM, Ganael LAPLANCHE wrote: > On Fri, 20 Apr 2012 08:14:17 +0200, Lars Engels wrote > > Hi everyone, > >> This is the same for my x200, but you can make it work: >> On 9.0-RELEASE you have to configure through device.hints(5), >> in CURRENT you can configure it on thy fly. See snd_hda(4) >> how to do this. > > FYI, this is what I had to put in /boot/devices.hint to have headset > working properly on my x220 (on 10-CURRENT) : > > # Out : speaker + headphones > # hint.hdac.0.cad0.nid31.config="as=1" > hint.hdac.0.cad0.nid25.config="as=1 seq=15" > # In : mic + external mic > hint.hdac.0.cad0.nid35.config="as=2" > hint.hdac.0.cad0.nid27.config="as=2 seq=15" After reading the man page I came up with exactly the same "fix". I tried setting it up with sysctl, but that left sound in a strange state with no speakers working at all and the headphones working badly. After a re-boot, it works as it should. Finally! Now to install the KMS patches and see if I can get full resolution video. Thanks! -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ 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: Complete hang on 9.0-RELEASE
Hi, On Sat, Apr 21, 2012 at 4:19 AM, Arnaud Lacombe wrote: > Hi, > > On Wed, Apr 18, 2012 at 2:22 AM, Arnaud Lacombe wrote: >> Hi, >> >> On Mon, Apr 16, 2012 at 5:50 PM, Arnaud Lacombe wrote: >>> [...] >>> I reproduced the previous problem on 10-CURRENT from r233917, on the >>> following platform (here running 8.2-RELEASE): >>> >>> FreeBSD is a registered trademark of The FreeBSD Foundation. >>> FreeBSD 8.2-RELEASE #0: Thu Feb 17 02:41:51 UTC 2011 >>> r...@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 >>> Timecounter "i8254" frequency 1193182 Hz quality 0 >>> CPU: Intel(R) Atom(TM) CPU D525 @ 1.80GHz (1800.01-MHz K8-class CPU) >>> Origin = "GenuineIntel" Id = 0x106ca Family = 6 Model = 1c Stepping = >>> 10 >>> Features=0xbfebfbff >>> Features2=0x40e31d >>> AMD Features=0x20100800 >>> AMD Features2=0x1 >>> TSC: P-state invariant >>> real memory = 2136539136 (2037 MB) >>> avail memory = 2043772928 (1949 MB) >>> ACPI APIC Table: <010312 APIC0947> >>> FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs >>> FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 HTT threads >>> cpu0 (BSP): APIC ID: 0 >>> cpu1 (AP/HT): APIC ID: 1 >>> cpu2 (AP): APIC ID: 2 >>> cpu3 (AP/HT): APIC ID: 3 >>> >>> Complete system freeze while running about 2400 threads. I had to >>> power cycle the system to get it back alive. I discussed a way to >>> debug this with attilio@ on freebsd-stable@, but still did not had >>> time to implement it. >>> >> 10-CURRENT from r233917 hanged again today while running 3600 threads. >> I enabled WITNESS and INVARIANTS on that specific kernel, secretly >> hoping that they would trigger some meaningful information, but they >> did not. I would guess my last attempt is to enable SW_WATCHDOG, and >> gather some state information out of DDB when the watchdog trigger, if >> it does... >> >> Btw, this issue seems to be specifically happening on Atom/ICH8M >> platform running amd64 kernel, as I've never seen it on other >> platforms, and yet ran extensive tests. I am not entirely sure it >> happens on i386. I would need to check. >> > For the record, 9.0-RELEASE i386 has been running the test for about 2 > days on the D510 platform without any hang so far. I'll keep it > running all week-end to give me a better idea. > ... or I have been too eager to expect an amd64 only issue. Thanks to some nasty virus which stuck me in my bed for two days, I finally got FreeBSD 9.0-RELEASE i386 stuck while running a single, 4000 threads, process. I guess it's time to play with SW_WATCHDOG and DDB. As a side note, the D510 platform seem to be much harder to hang than the D525... - Arnaud ___ 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: segfault in vfscanf(3): clang and __restrict usage
On 2012-04-25 21:13, Boris Samorodov wrote: > 25.04.2012 22:57, Dimitry Andric пишет: >> On 2012-04-24 21:49, Jean-Sébastien Pédron wrote: >>> Hi everyone, >>> >>> vfscanf(3) in HEAD (r234606) segfaults when compiled with clang. For >>> instance, here is a call made in cmake which crashes: >>> fscanf(f, "%*[^\n]\n"); >> >> Using r234549 here, everything compiled with clang, but I cannot make >> that statement crash, whatever I do. Do you have a specific input file >> which crashes it? > > - > % uname -a > FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r234635: Tue > Apr 24 11:41:32 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX > i386 > % sudo gdb smartd smartd.core > GNU gdb 6.1.1 [FreeBSD] > [...] > #0 0x33ebdc2e in vfscanf () from /lib/libc.so.7 > (gdb) > - > > I think that cupsd also suffer from the bug. > > BTW, I have the system and almost all ports compiled (tomorrow > and today) with clang. Looks like the __restricted keywords were introduced just two days ago, in r234585, which may be why I didn't see any crashes yet. I think the easiest solution for now is to #undef __restrict at the top of both lib/libc/stdio/vfscanf.c and lib/libc/stdio/vfwscanf.c, then recompile and reinstall libc. ___ 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: segfault in vfscanf(3): clang and __restrict usage
25.04.2012 22:57, Dimitry Andric пишет: > On 2012-04-24 21:49, Jean-Sébastien Pédron wrote: >> Hi everyone, >> >> vfscanf(3) in HEAD (r234606) segfaults when compiled with clang. For >> instance, here is a call made in cmake which crashes: >> fscanf(f, "%*[^\n]\n"); > > Using r234549 here, everything compiled with clang, but I cannot make > that statement crash, whatever I do. Do you have a specific input file > which crashes it? - % uname -a FreeBSD bsam.wart.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r234635: Tue Apr 24 11:41:32 SAMT 2012 b...@bsam.wart.ru:/usr/obj/usr/src/sys/BBX i386 % sudo gdb smartd smartd.core GNU gdb 6.1.1 [FreeBSD] [...] #0 0x33ebdc2e in vfscanf () from /lib/libc.so.7 (gdb) - I think that cupsd also suffer from the bug. BTW, I have the system and almost all ports compiled (tomorrow and today) with clang. -- WBR, Boris Samorodov (bsam) FreeBSD Committer, http://www.FreeBSD.org The Power To Serve ___ 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: segfault in vfscanf(3): clang and __restrict usage
On 2012-04-24 21:49, Jean-Sébastien Pédron wrote:
> Hi everyone,
>
> vfscanf(3) in HEAD (r234606) segfaults when compiled with clang. For
> instance, here is a call made in cmake which crashes:
> fscanf(f, "%*[^\n]\n");
Using r234549 here, everything compiled with clang, but I cannot make
that statement crash, whatever I do. Do you have a specific input file
which crashes it?
> The same libc, compiled with GCC, doesn't segfault.
>
> When it encounters a character class, __svfscanf() calls convert_ccl():
>
> static const int suppress;
> #define SUPPRESS_PTR((void *)&suppress)
>
> static __inline int
> convert_ccl(FILE *fp, char * __restrict p, [...])
> {
> [...]
>
> if (p == SUPPRESS_PTR) {
> [...]
> } else {
> [...]
> }
>
> [...]
> }
...
> From what I understand about __restrict, it indicates that the pointer
> is the only one pointing to a resource. In vfscanf.c, "suppress" may
> be pointed by several pointers at a time, so I think __restrict here
> is incorrect. But I'm really not sure I got it right. And I don't know
> either if clang behavior is expected.
Indeed, my first impression was the same, that the use of 'restrict' is
wrong here. Namely, if you tell the compiler that 'p' is the *only*
pointer pointing to a specific object, and you compare it with any other
pointer, the comparison will be unequal by definition.
However, after asking around a bit, it seems that clang is still wrong
in this particular case. Although this is probably language lawyer
area, so beware. :)
I have filed an LLVM PR for it here:
http://llvm.org/bugs/show_bug.cgi?id=12656
Meanwhile, I really wonder why the __restrict keyword was used in this
implementation. There are lots of cases in vfscanf.c, where a pointer
is declared __restrict, and then aliasing seems to be done anyway.
Besides, I'm not really sure about the potential optimization gains of
adding the keyword. With our base gcc, removing all the __restrict
keywords results in no binary change. With gcc 4.7, there are some very
minor changes, but they are extremely unlikely to gain any performance.
And with clang, there are quite some differences, but apparently it
optimizes too aggressively, so more testing is required to see if the
potential for bugs outweighs the performance gains.
___
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: Some performance measurements on the FreeBSD network stack
On 25. Apr 2012, at 15:45 , K. Macy wrote: > a) Where is the possible leak in the legacy path? It's been somewhere in ip_output() in one of the possible combinations go through the code flow. I'd probably need to apply a patch to a tree to get there again. It's been more than 6 months for me as well. I think it was related to the flowtable path but I could completely misremember. > b) Where were the panics in v6? Again completely quoting from memory. I think the problem was that the INVARIANTS check in what's currently nd6_output_lle() was hit given both the rtentry and llentry were passed in but no *chain. Fixing this seems trivial even when trying to keep the current invariants checked. However the bigger problem then was that the cached value was never updated as the *ro passed down had been lost on the way. Whatever came then, is again off my head without the patch in front of me. Btw. you don't need more than two machines connected, virtual or not, worst two vnet instances on a lab machine, to enable and do IPv6. No need for global connectivity at all, as would not be required for IPv4 either. If you can get the patch updated to apply to a modern HEAD and compile (even if as-is) I'll try to help solving those to my best (though limited) availability to help you to get that thing in. /bz -- Bjoern A. Zeeb You have to have visions! It does not matter how good you are. It matters what good you do! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: HEADSUP: LibUSB 1.0 API change
On Wed, Apr 25, 2012 at 08:03:24PM +0200, Hans Petter Selasky wrote: > Hi, > > Applications using ASYNC transfers needs to be re-compiled in 10-current > after > this change: > > http://svn.freebsd.org/changeset/base/234684 > > This change will _not_ be backported to 9-stable or 8-stable. You need to bump libusb .so version after the change. pgpo4a9zkpKXk.pgp Description: PGP signature
HEADSUP: LibUSB 1.0 API change
Hi, Applications using ASYNC transfers needs to be re-compiled in 10-current after this change: http://svn.freebsd.org/changeset/base/234684 This change will _not_ be backported to 9-stable or 8-stable. --HPS ___ 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: /etc/malloc.conf format change
On Apr 25, 2012, at 9:39 AM, Ruslan Ermilov wrote: > So you removed _malloc_options that was part of the documented > programming API, while some software made use of it. > > While removing part of the documented API was definitely a bad > idea, you didn't provide any mean to detect this change > programmatically, neither through a macro test, nor by bumping > __FreeBSD_version. The only way now is to try and see if it > compiles, which is far from perfect. > > The way how _malloc_options is handled for binary compatibility, > by simply ignoring its value, is (ahem) questionable. > > Why do I care? The developers of the nginx web server have > been notified today that it could not be built on FreeBSD > 10.0-CURRENT anymore, due to this change, when compiled with > "nginx malloc debugging". It's activated by the DEBUG option > of the www/nginx-devel port, if you care to try it out. > > Please explore the possibility to add backwards compatiblity for > the documented API, or at the very least provide a mean to > detect this otherwise disruptive and hard to detect change > for a programmer. A __FreeBSD_version bump seems like a good idea to me, but adding backward compatibility for _malloc_options is questionable at best. Of the 17 options that _malloc_options supported, only 6 have directly corresponding options in malloc_conf, plus another 3 that would present strange quirks (fragile and difficult to precisely document) if an attempt were made to provide compatibility. In past iterations I was always careful to provide as much option compatibility as possible over the lifetime of each release (e.g., 'H' in RELENG_7), but individual options came and went with major releases. _malloc_options could only be pushed so far, and when it hit its breaking point I replaced it. Creaky compatibility is IMO a liability rather than an asset. In the case of nginx, it looks like a __FreeBSD_version bump is exactly what it needs. I'll try to get that done today. On a related note, is there any way to find all ports that refer to _malloc_options without extracting source for all of them? I considered being proactive about finding software that depends on _malloc_options, but no tractable approaches came to mind. Thanks, Jason___ 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: /etc/malloc.conf format change
On Tue, Apr 17, 2012 at 12:34:20PM -0700, Jason Evans wrote: > As a result of the recent jemalloc update, the format for > /etc/malloc.conf has changed. If your system has an old-style > /etc/malloc.conf, you will want to delete it prior to > installworld, and optionally re-create it using the new format > after rebooting. See malloc.conf(5) for details (specifically > the TUNING section and the "opt.*" entries in the MALLCTL > NAMESPACE section). > > The MALLOC_OPTIONS environment variable and the _malloc_options > global do not pose the same headache, because their new > counterparts are named MALLOC_CONF and malloc_conf, > respectively. So you removed _malloc_options that was part of the documented programming API, while some software made use of it. While removing part of the documented API was definitely a bad idea, you didn't provide any mean to detect this change programmatically, neither through a macro test, nor by bumping __FreeBSD_version. The only way now is to try and see if it compiles, which is far from perfect. The way how _malloc_options is handled for binary compatibility, by simply ignoring its value, is (ahem) questionable. Why do I care? The developers of the nginx web server have been notified today that it could not be built on FreeBSD 10.0-CURRENT anymore, due to this change, when compiled with "nginx malloc debugging". It's activated by the DEBUG option of the www/nginx-devel port, if you care to try it out. Please explore the possibility to add backwards compatiblity for the documented API, or at the very least provide a mean to detect this otherwise disruptive and hard to detect change for a programmer. Cheers, -- Ruslan Ermilov r...@freebsd.org FreeBSD committer ___ 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: Some performance measurements on the FreeBSD network stack
> Because there were leaks, there were 100% panics for IPv6, ... at least on > the version I had seen in autumn last year. > > There is certainly no one more interested then me on these in, esp. for v6 > where the removal of route caching a long time ago made nd6_nud_hint() a NOP > with dst and rt being passed down as NULL only, and where we are doing up to > three route lookups in the output path if no cached rt is passed down along > from the ULP. > > If there is an updated patch, I'd love to see it. Ok, I'm following up as this seems to be getting some interest. This the relevant part of the last mail that I received from you. The final part having been dedicated to the narrow potential ABI changes that were to make it in to the release. From: Bjoern A. Zeeb Date: Mon, Sep 19, 2011 at 3:19 PM To: "K. Macy" Cc: Robert Watson , rysto32 , Qing Li Sorry it's taking me so long while I was travelling but also now being back home again. I would yet have to find a code path through IPv6 that will a) not panic on INVARIANTS and b) actually update the inp_lle cache. Once I stop finding the next hiccup going one step deeper into the stack (and I made it to if_ethersubr.c) I'll get to legacy IP and the beef and I'll hope that all you all will have reviewed and tested that thoroughly. Checking whether a similar problem would exist in v4 I however found a possible lle reference leak in the legacy IP path as well. There's also a missed place where we do not update the generation counter (even though kind of pointless place but still to do for completeness). I am also pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output). I wonder if we can provoke strange results say changing the default route from something connected on interface 1 to interface 2. <...> /bz -- Bjoern A. Zeeb You have to have visions! Stop bit received. Insert coin for new address family. === The only comment in here which was sufficiently specific to actually take action on was: "pondering why we are not always invalidating the ro_lle cache (when we update the ro_rt entry in the callgraph after tcp_output)." Which was subsequently addressed by ensuring that the LLE_VALID flag was actually meaningful by clearing it when the llentry is removed from the interface's hash table in an unrelated commit because of weird behaviour observed with the flow. a) Where is the possible leak in the legacy path? b) Where were the panics in v6? In light of the fact that I don't or at least didn't have any means of testing v6 (I can probably get a testbed set up at iX now) and the netinet6 specific portions of the patch consist of 4 lines of code which should really be entrusted to you given that your performance parity work for v6 has actively being funded, it was clearly a mistake to tie the fate of the patch as a whole to those narrow bits. Once I get a response to a) and b) I'll follow up with a patch against head. I'm sure whatever I had has bitrotted somewhat in the meantime. Thanks for your help, Kip ___ 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: Some performance measurements on the FreeBSD network stack
On Wed, Apr 25, 2012 at 01:22:06PM +0400, Maxim Konovalov wrote: > Hi, > > On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: > > > Yup, all good points. In fact we have considered all of these while doing > > the work. In case you haven't seen it already, we did write about these > > issues in our paper and how we tried to address those, flow-table was one > > of the solutions. > > > > http://dl.acm.org/citation.cfm?id=1592641 > > Is this article available for those without ACM subscription? Tip: get citation from abstract to google. 3'th link: http://conferences.sigcomm.org/sigcomm/2009/workshops/presto/papers/p37.pdf ___ 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: Some performance measurements on the FreeBSD network stack
Hi, On Tue, 24 Apr 2012, 17:40-, Li, Qing wrote: > Yup, all good points. In fact we have considered all of these while doing > the work. In case you haven't seen it already, we did write about these > issues in our paper and how we tried to address those, flow-table was one > of the solutions. > > http://dl.acm.org/citation.cfm?id=1592641 Is this article available for those without ACM subscription? -- Maxim Konovalov ___ 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"
