Re: Double free() in libc or gdb ?
On Tuesday 13 March 2012 20:44:43 you wrote: On 2012-03-13 11:08, Alexandre Martins wrote: On Monday 12 March 2012 18:55:55 Konstantin Belousov wrote: On Mon, Mar 12, 2012 at 05:50:33PM +0100, Alexandre Martins wrote: ... I have the libc compilled with MALLOC_DEBUG flag to detect double free. When i run this piece of code (attached file) thought GDB, i have this assertion : Assertion failed: ((run-regs_mask[elm] (1U bit)) == 0), function arena_run_reg_dalloc, file /usr/src/lib/libc/stdlib/malloc.c, line 2543. I have committed a fix for this assertion (actually a double free) in r232934. Can you please update to that revision, rebuild your gdb, and try again? Dear, The problem have disapear with an update to gdb 7.3. Thank you for your help ! Regards -- Alexandre Martins NETASQ -- We secure IT
CURRENT: make -jX buildworld doesn't work
This is no compalin, since make buildworld works with one thread. But I'd like to report a funny thing I witnessed. On two boxes equipted with Core2Dou CPUS (E8500, 2 cores/threads, Q6600, 4 cores/threads) a parallel make buildworld works fine with the most recent sources of FreeBSD 10.0-CURRENT/amd64 (both boxes have 8 GB RAM, both boxes use a very close/similar setup and configuration). I moved in my lab towards a brand new Sandy-Bridge-E box with 32GB RAM and the CPU is a Core i7-3930X with six cores/12 threads. On this box, even make buildworld with -j2 fails to build. It builds fine with a vanilla make buildworld. Also funny is, that even with only one thread, the 3 GHz Core2Duo methusalem systems outperform in compile time the 3,2 GHZ driven Intel youngster. Maybe there is an issue in FreeBSD 10 with the TURBO BOOST? I'm a bit time constraint now, but I'm willing to do some tests with advices from the experts. Lets give you some informations I think it could be valuable. Please request more, if this isn't sufficient. I realize/I'm aware that both hardware and OS are brandnew! But hopefully this is something important and could be fixed - if my observation is a real observation ... Regards, Oliver KERNEL: # CPU frequency control device cpufreq device cpuctl device nvram device coretemp /etc/rc.conf: performance_cx_lowest=HIGH# Online CPU idle state performance_cpu_freq=NONE # Online CPU frequency economy_cx_lowest=HIGH# Offline CPU idle state economy_cpu_freq=NONE # Offline CPU frequency # sysctl kern.timecounter kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 52702 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2109995661 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 3590445 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1510440780 kern.timecounter.tc.TSC-low.frequency: 12537463 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.stepwarnings: 0 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) kern.timecounter.tick: 5 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 0 # # dmesg | grep cpu cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 cpu8 (AP): APIC ID: 8 cpu9 (AP): APIC ID: 9 cpu10 (AP): APIC ID: 10 cpu11 (AP): APIC ID: 11 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 cpu6: ACPI CPU on acpi0 cpu7: ACPI CPU on acpi0 cpu8: ACPI CPU on acpi0 cpu9: ACPI CPU on acpi0 cpu10: ACPI CPU on acpi0 cpu11: ACPI CPU on acpi0 coretemp0: CPU On-Die Thermal Sensors on cpu0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 coretemp1: CPU On-Die Thermal Sensors on cpu1 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 coretemp2: CPU On-Die Thermal Sensors on cpu2 est2: Enhanced SpeedStep Frequency Control on cpu2 p4tcc2: CPU Frequency Thermal Control on cpu2 coretemp3: CPU On-Die Thermal Sensors on cpu3 est3: Enhanced SpeedStep Frequency Control on cpu3 p4tcc3: CPU Frequency Thermal Control on cpu3 coretemp4: CPU On-Die Thermal Sensors on cpu4 est4: Enhanced SpeedStep Frequency Control on cpu4 p4tcc4: CPU Frequency Thermal Control on cpu4 coretemp5: CPU On-Die Thermal Sensors on cpu5 est5: Enhanced SpeedStep Frequency Control on cpu5 p4tcc5: CPU Frequency Thermal Control on cpu5 coretemp6: CPU On-Die Thermal Sensors on cpu6 est6: Enhanced SpeedStep Frequency Control on cpu6 p4tcc6: CPU Frequency Thermal Control on cpu6 coretemp7: CPU On-Die Thermal Sensors on cpu7 est7: Enhanced SpeedStep Frequency Control on cpu7 p4tcc7: CPU Frequency Thermal Control on cpu7 coretemp8: CPU On-Die Thermal Sensors on cpu8 est8: Enhanced SpeedStep Frequency Control on cpu8 p4tcc8: CPU Frequency Thermal Control on cpu8 coretemp9: CPU On-Die Thermal Sensors on cpu9 est9: Enhanced SpeedStep Frequency Control on cpu9 p4tcc9: CPU Frequency Thermal Control on cpu9 coretemp10: CPU On-Die Thermal Sensors on cpu10 est10: Enhanced SpeedStep Frequency Control on cpu10 p4tcc10: CPU Frequency Thermal Control on cpu10 coretemp11: CPU On-Die Thermal Sensors on cpu11 est11: Enhanced SpeedStep Frequency Control on cpu11 p4tcc11: CPU Frequency Thermal Control on cpu11 # sysctl dev.cpu dev.cpu.0.%desc: ACPI CPU dev.cpu.0.%driver: cpu dev.cpu.0.%location: handle=\_SB_.P000
Re: CURRENT: make -jX buildworld doesn't work
On Wed, 2012-03-14 at 14:47 +0100, O. Hartmann wrote: This is no compalin, since make buildworld works with one thread. But I'd like to report a funny thing I witnessed. On two boxes equipted with Core2Dou CPUS (E8500, 2 cores/threads, Q6600, 4 cores/threads) a parallel make buildworld works fine with the most recent sources of FreeBSD 10.0-CURRENT/amd64 (both boxes have 8 GB RAM, both boxes use a very close/similar setup and configuration). I moved in my lab towards a brand new Sandy-Bridge-E box with 32GB RAM and the CPU is a Core i7-3930X with six cores/12 threads. On this box, even make buildworld with -j2 fails to build. It builds fine with a vanilla make buildworld. Also funny is, that even with only one thread, the 3 GHz Core2Duo methusalem systems outperform in compile time the 3,2 GHZ driven Intel youngster. Maybe there is an issue in FreeBSD 10 with the TURBO BOOST? I'm a bit time constraint now, but I'm willing to do some tests with advices from the experts. Lets give you some informations I think it could be valuable. Please request more, if this isn't sufficient. I realize/I'm aware that both hardware and OS are brandnew! But hopefully this is something important and could be fixed - if my observation is a real observation ... Regards, Oliver KERNEL: # CPU frequency control device cpufreq device cpuctl device nvram device coretemp /etc/rc.conf: performance_cx_lowest=HIGH# Online CPU idle state performance_cpu_freq=NONE # Online CPU frequency economy_cx_lowest=HIGH# Offline CPU idle state economy_cpu_freq=NONE # Offline CPU frequency # sysctl kern.timecounter kern.timecounter.tc.i8254.mask: 65535 kern.timecounter.tc.i8254.counter: 52702 kern.timecounter.tc.i8254.frequency: 1193182 kern.timecounter.tc.i8254.quality: 0 kern.timecounter.tc.HPET.mask: 4294967295 kern.timecounter.tc.HPET.counter: 2109995661 kern.timecounter.tc.HPET.frequency: 14318180 kern.timecounter.tc.HPET.quality: 950 kern.timecounter.tc.ACPI-fast.mask: 16777215 kern.timecounter.tc.ACPI-fast.counter: 3590445 kern.timecounter.tc.ACPI-fast.frequency: 3579545 kern.timecounter.tc.ACPI-fast.quality: 900 kern.timecounter.tc.TSC-low.mask: 4294967295 kern.timecounter.tc.TSC-low.counter: 1510440780 kern.timecounter.tc.TSC-low.frequency: 12537463 kern.timecounter.tc.TSC-low.quality: -100 kern.timecounter.stepwarnings: 0 kern.timecounter.hardware: HPET kern.timecounter.choice: TSC-low(-100) ACPI-fast(900) HPET(950) i8254(0) dummy(-100) kern.timecounter.tick: 5 kern.timecounter.invariant_tsc: 1 kern.timecounter.smp_tsc: 0 # # dmesg | grep cpu cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 2 cpu3 (AP): APIC ID: 3 cpu4 (AP): APIC ID: 4 cpu5 (AP): APIC ID: 5 cpu6 (AP): APIC ID: 6 cpu7 (AP): APIC ID: 7 cpu8 (AP): APIC ID: 8 cpu9 (AP): APIC ID: 9 cpu10 (AP): APIC ID: 10 cpu11 (AP): APIC ID: 11 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 cpu2: ACPI CPU on acpi0 cpu3: ACPI CPU on acpi0 cpu4: ACPI CPU on acpi0 cpu5: ACPI CPU on acpi0 cpu6: ACPI CPU on acpi0 cpu7: ACPI CPU on acpi0 cpu8: ACPI CPU on acpi0 cpu9: ACPI CPU on acpi0 cpu10: ACPI CPU on acpi0 cpu11: ACPI CPU on acpi0 coretemp0: CPU On-Die Thermal Sensors on cpu0 est0: Enhanced SpeedStep Frequency Control on cpu0 p4tcc0: CPU Frequency Thermal Control on cpu0 coretemp1: CPU On-Die Thermal Sensors on cpu1 est1: Enhanced SpeedStep Frequency Control on cpu1 p4tcc1: CPU Frequency Thermal Control on cpu1 coretemp2: CPU On-Die Thermal Sensors on cpu2 est2: Enhanced SpeedStep Frequency Control on cpu2 p4tcc2: CPU Frequency Thermal Control on cpu2 coretemp3: CPU On-Die Thermal Sensors on cpu3 est3: Enhanced SpeedStep Frequency Control on cpu3 p4tcc3: CPU Frequency Thermal Control on cpu3 coretemp4: CPU On-Die Thermal Sensors on cpu4 est4: Enhanced SpeedStep Frequency Control on cpu4 p4tcc4: CPU Frequency Thermal Control on cpu4 coretemp5: CPU On-Die Thermal Sensors on cpu5 est5: Enhanced SpeedStep Frequency Control on cpu5 p4tcc5: CPU Frequency Thermal Control on cpu5 coretemp6: CPU On-Die Thermal Sensors on cpu6 est6: Enhanced SpeedStep Frequency Control on cpu6 p4tcc6: CPU Frequency Thermal Control on cpu6 coretemp7: CPU On-Die Thermal Sensors on cpu7 est7: Enhanced SpeedStep Frequency Control on cpu7 p4tcc7: CPU Frequency Thermal Control on cpu7 coretemp8: CPU On-Die Thermal Sensors on cpu8 est8: Enhanced SpeedStep Frequency Control on cpu8 p4tcc8: CPU Frequency Thermal Control on cpu8 coretemp9: CPU On-Die Thermal Sensors on cpu9 est9: Enhanced SpeedStep Frequency Control on cpu9 p4tcc9: CPU Frequency Thermal Control on cpu9 coretemp10: CPU On-Die Thermal Sensors on cpu10 est10: Enhanced SpeedStep Frequency Control on cpu10 p4tcc10: CPU Frequency Thermal Control on cpu10 coretemp11: CPU On-Die Thermal Sensors on cpu11 est11: Enhanced SpeedStep
Re: Netgear WNA1000N USB wlan device
Hy, Any news about the development of this driver, is someone working on it? Thanks in advance, Coszmin -- View this message in context: http://freebsd.1045724.n5.nabble.com/Netgear-WNA1000N-USB-wlan-device-tp4980136p5565210.html Sent from the freebsd-current mailing list archive at Nabble.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
CFT: new BSD-licensed sort available
Hi Folks, some time ago I started writing a BSDL sort variant from scratch since the OpenBSD version did not support multibyte locales and was hard to modify. The development was a bit stalled but recently, Oleg Moskalenko oleg.moskale...@citrix.com showed interest in continuing this version and he has made a very good job on this BSD sort variant. Now it is compatible with the base version of GNU sort but the performance in most cases (string sort and -n) is quite behind GNU sort (although with -g it is about *4 times* faster). Oleg is still working on optimizing the code and the long-term plan is to drop GNU sort once this variant is good enough to replace it. For now, it is only available in Ports Collection as textproc/bsdsort but if there is no objection or any serious bug report I plan to add it to base installed as bsdsort, being GNU sort still the default sort until it proves that we can safely drop GNU sort. If you are interested in this sort utility, could you please try the port and report us any issue that you experience? Thanks in advance, Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: CURRENT: make -jX buildworld doesn't work
On 03/14/12 16:08, Ian Lepore wrote: On Wed, 2012-03-14 at 14:47 +0100, O. Hartmann wrote: This is no compalin, since make buildworld works with one thread. But I'd like to report a funny thing I witnessed. On two boxes equipted with Core2Dou CPUS (E8500, 2 cores/threads, Q6600, 4 cores/threads) a parallel make buildworld works fine with the most recent sources of FreeBSD 10.0-CURRENT/amd64 (both boxes have 8 GB RAM, both boxes use a very close/similar setup and configuration). I moved in my lab towards a brand new Sandy-Bridge-E box with 32GB RAM and the CPU is a Core i7-3930X with six cores/12 threads. On this box, even make buildworld with -j2 fails to build. It builds fine with a vanilla make buildworld. Also funny is, that even with only one thread, the 3 GHz Core2Duo methusalem systems outperform in compile time the 3,2 GHZ driven Intel youngster. Maybe there is an issue in FreeBSD 10 with the TURBO BOOST? I'm a bit time constraint now, but I'm willing to do some tests with advices from the experts. Lets give you some informations I think it could be valuable. Please request more, if this isn't sufficient. I realize/I'm aware that both hardware and OS are brandnew! But hopefully this is something important and could be fixed - if my observation is a real observation ... Regards, Oliver [SNIP] There was a change (r232793) a few days ago to make turbo boost work, more info in this thread: http://lists.freebsd.org/pipermail/freebsd-current/2012-March/032434.html I wasn't able to get it to work just by tweaking the rc.conf knobs, but I suspect the reason may be because I have non-standard devd.conf. I worked around it and haven't had time to look for the cause yet. In trying to explain the compile time differences between two systems, one of the first things I'd look at would be differences in the disks. In my experience, IO performance has as big an influence on build time as processor speed and number of cores. I just updated my -current sources and did a fresh buildworld and buildkernel using both -j2 and -j12 and had no problems on a 6-core Xeon. I know make xdev fails with -jN but I haven't seen failures on any other targets. There was a checkin recently that added some .ORDER stuff for -jN but it only affected building usr.sbin/acpi. -- Ian The change has already been used. But no change. The disks are on all systems the same, but the new box has SATA 6GB and the WD 640GB Caviar black disk claims also be SATA 6GB. You're right, disk I/O has a great impact. And I realized that FreeBSD 9/10 have a big problem with the Patsburg-based X79 chipset, as far as I can see - or it is simply a coincidence. Since the disks are attached to the X79 chipset's SATA 6GB port, I have sometimes strange elongated access times. When doing a simple diskper measurement, the raw performance of the disk reveals itself as slightly better than with SATA 3GB. By the way, my last buildworl took 1 hour. The buildworld before 3 hours. Same load, same box, same OS revision. funny. I stay tuned. At the time, it doesn't bother me much. I thought it is just worth to be mentioned ... Regards, Oliver signature.asc Description: OpenPGP digital signature
Re: CFT: new BSD-licensed sort available
Would it be appropriate to perhaps have a port option to OVERWRITE_BASE and then people could just install that port, build world and kernel... build a ton of ports. See if anything that might possibly use it breaks? ___ 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: x220 notes
On 03/13/12 21:38, matt wrote: On 03/13/12 17:43, matt wrote: On 03/12/12 17:00, Kevin Oberman wrote: On Fri, Mar 9, 2012 at 7:24 PM, mattsendtom...@gmail.com wrote: On 03/08/12 01:28, Ganael LAPLANCHE wrote: On Wed, 07 Mar 2012 20:29:16 +0200, Vrachnis Ilias-Dimitrios wrote Hi, 2. I've read bad reviews about webcam having poor quality on GNU/Linux, so I would assume it will be the same on FreeBSD with webcamd and not worth the $30? (which also frees up space for 3x3 antenna) Yep, the webcam works with webcamd but the quality is not great... 4. How far is the AMD64 kernel suspend/resume? What do you mean by video doesn't resume? I run 10-CURRENT : FreeBSD laptop.martymac.org 10.0-CURRENT FreeBSD 10.0-CURRENT #12 r231062M: Mon Feb 6 10:29:35 CET 2012 marty...@laptop.martymac.org:/usr/obj/files/Src/sys/GENERIC amd64 with all.13.1 patch (no more available) from : http://people.freebsd.org/~kib/drm/ 3D acceleration works well, as well as suspend/resume when Xorg has been started (black screen if on console). Best regards, -- Ganael LAPLANCHEganael.laplan...@martymac.org http://www.martymac.org | http://contribs.martymac.org FreeBSD: martymacmarty...@freebsd.org, http://www.FreeBSD.org ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org This is great news! I just finished some other stuff, so hopefully I can take a renewed look at brightness and the fan issue. Thanks for woking on this, Matt. I, for one, would be happy to have the volume and de-lighted to have brightness working on my T520! (Sorry or the weak pun.) So far it looks like acpi_video attaches, but the lcd0 device is not active. More interestingly, if you press brightness shortcuts, acpi_video can see the brightness value change while screen does not actually change. My conclusion based on bullshit and poking around in the acpidump, is that possibly either: 1) We need to call some ACPI handle to put ACPI in charge of brightness (google acpi brightness trapdoor) 2) acpi_video is attaching to the nvidia optimus hooks (yes, they're there, I know we don't have that option) and is missing the IGD video (VIGD/PEG etc) 3) Something else is wrong with either acpi, acpi_video, or bios that is preventing ACPI from working? I am going to take more of a look tonight. I think I can just hack in some ACPI calls straight to the ec if that will work, which might also include the correct ones to resume the display without KMS? Calling some _ON function or something perhaps Thanks! Matt I have brightness control through raw acpi...\_BCL and friends seem to do nothing. Most of the video methods differentiate between \VIGD (which seems to be a check for integrated graphics vs optimus, but that's still a guess) If \VIGD is true, brightness commands are sent to the EC, where they don't seem to do much yet. This is probably where we could enable something via EC/ibm-acpi? If \VIGD is false, brightness commands are handled in ACPI, although coarsely, via \VBRC. \VBRC seems to allow control over the backlight, at least, so those of you with sore eyes or the 3-cell battery may have some success using the acpi_call port (Danger!) kldload acpi_call acpi_call -p '\VBRC' -i n (where n is 0-10) Still hacking :)! Matt Can anyone verify that suspend/resume is now broken on x220 with latest HEAD and the KMS patches? Suspend bounce causes crash, resume beep makes modem sound and hangs, logs indicate only suspend. hw.pci.do_power_resume=0 causes no change. The acpi_call hack works on console as well, so at least we have some ability to control brightness for now. The next step is going to be figuring out why EC does nothing, or it would work out of the box I think. If that's a dead end, we can patch acpi_ibm to use \VBRC maybe. Also, once xorg xfce load, my power usage goes from 9W tuned to 24W...I'm sure that's because patch is still in development. Matt ___ 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
installworld and delete-old fighting a constant battle
hi there, while installing world with DESTDIR!=/ and running delete-old afterwards, i noticed the following entries. if i'm not mistaken delete-old should not need to delete anything, because DESTDIR was completely empty before running installworld: Removing old files (only deletes safe to delete libs) remove /usr/obj/TESTDIR/usr/share/man/man3/archive_entry_hardlink_w.3.gz? y remove /usr/obj/TESTDIR/usr/share/man/man3/archive_entry_symlink_w.3.gz? y Old files removed Removing old directories /usr/obj/TESTDIR/usr/include/fs/fifofs /usr/obj/TESTDIR/usr/include/lwres /usr/obj/TESTDIR/usr/share/doc/bind9/arm /usr/obj/TESTDIR/usr/share/doc/bind9/misc /usr/obj/TESTDIR/usr/share/doc/bind9 Old directories removed my src.conf contains the following entries: BOOT2_UFS=UFS2_ONLY # don't need UFS1 support anymore GPTBOOT_UFS=UFS2_ONLY # don't need UFS1 support anymore WITHOUT_ACCT=true WITHOUT_AMD=true WITHOUT_APM=true WITHOUT_AT=true WITHOUT_ATM=true WITHOUT_AUDIT=true WITHOUT_BIND=true WITHOUT_GPIO=true WITH_BSD_GREP=true WITHOUT_BSNMP=true WITHOUT_CALENDAR=true WITHOUT_CAPSICUM=true WITHOUT_CTM=true WITHOUT_CVS=true WITHOUT_FLOPPY=true WITHOUT_FREEBSD_UPDATE=true WITHOUT_GAMES=true WITHOUT_GPIB=true WITHOUT_HTML=true WITH_IDEA=true WITHOUT_INET6=true WITHOUT_IPFILTER=true WITHOUT_IPFW=true WITHOUT_IPX=true WITHOUT_JAIL=true WITHOUT_KERBEROS=true WITH_LIBCPLUSPLUS=true WITHOUT_LPR=true WITHOUT_NDIS=true WITHOUT_NETCAT=true WITHOUT_NIS=true WITHOUT_NLS=true WITHOUT_NLS_CATALOGS=true WITHOUT_NS_CACHING=true WITHOUT_PAM_SUPPORT=true WITHOUT_PF=true WITHOUT_PPP=true WITHOUT_PROFILE=true WITHOUT_QUOTAS=true WITHOUT_RCMDS=true WITHOUT_RCS=true WITHOUT_ROUTED=true WITHOUT_SHAREDOCS=true WITHOUT_SSP=true WITHOUT_SYSINSTALL=true WITHOUT_TCSH=true WITHOUT_TELNET=true WITHOUT_ZFS=true cheers. alex ___ 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: CFT: new BSD-licensed sort available
On 14 March 2012 08:59, Gabor Kovesdan ga...@freebsd.org wrote: some time ago I started writing a BSDL sort variant from scratch since the OpenBSD version did not support multibyte locales and was hard to modify. The development was a bit stalled but recently, Oleg Moskalenko oleg.moskale...@citrix.com showed interest in continuing this version and he has made a very good job on this BSD sort variant. Now it is compatible with the base version of GNU sort but the performance in most cases (string sort and -n) is quite behind GNU sort (although with -g it is about *4 times* faster). Oleg is still working on optimizing the code and the long-term plan is to drop GNU sort once this variant is good enough to replace it. For now, it is only available in Ports Collection as textproc/bsdsort but if there is no objection or any serious bug report I plan to add it to base installed as bsdsort, being GNU sort still the default sort until it proves that we can safely drop GNU sort. If you are interested in this sort utility, could you please try the port and report us any issue that you experience? Hi, This makes me think of the whole debian-y way of replacing the mailer programs using some magic alias program. So you could intall gnusort, bsdsort, and then some config file would determine which was used. 'sort' would then be a symlink to said magic program, that'd look at its argv[0], look at the contents of that file, and exec() the right one. Would that be helpful herE? Adrian ___ 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: x220 notes
Ciao, On 03/14/2012 00:38, matt wrote: I have brightness control through raw acpi...\_BCL and friends seem to do nothing. Most of the video methods differentiate between \VIGD (which seems to be a check for integrated graphics vs optimus, but that's still a guess) If \VIGD is true, brightness commands are sent to the EC, where they don't seem to do much yet. This is probably where we could enable something via EC/ibm-acpi? If \VIGD is false, brightness commands are handled in ACPI, although coarsely, via \VBRC. \VBRC seems to allow control over the backlight, at least, so those of you with sore eyes or the 3-cell battery may have some success using the acpi_call port (Danger!) kldload acpi_call acpi_call -p '\VBRC' -i n (where n is 0-10) Great news! Works for me. n is actually 0-16 (plus any other value which turns the backlight off (-1 or 17 eg). Thanks, Hannes ___ 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: CFT: new BSD-licensed sort available
I must be thinking of our mailer trick then? I know i've seen it somewhere before. Alternatives sounds fun though? ADrian ___ 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: CFT: new BSD-licensed sort available
On Wed, 14 Mar 2012 20:26:23 -0500, Adrian Chadd adr...@freebsd.org wrote: I must be thinking of our mailer trick then? I know i've seen it somewhere before. Alternatives sounds fun though? I've seen several discussions on the bsd lists with everyone against the debian alternatives way. I don't know the history but I don't think it has much support. I assume it has to do with binaries passing through /etc via symlinks. I don't personally have much of an opinion on this. ___ 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: CFT: new BSD-licensed sort available
On 14 Mar 2012, at 21:10, Adrian Chadd wrote: Hi, This makes me think of the whole debian-y way of replacing the mailer programs using some magic alias program. So you could intall gnusort, bsdsort, and then some config file would determine which was used. 'sort' would then be a symlink to said magic program, that'd look at its argv[0], look at the contents of that file, and exec() the right one. In fact, the runtime behaviour of the Debian alternatives system is simpler than that: http://segfault.in/2010/04/using-the-debian-alternatives-system/ The custom Perl script with a config file is used to set up symlinks, which at runtime are... well, just symlinks. For instance, /usr/bin/vim is a symlink to /etc/alternatives/vim, which is itself a symlink to a binary like vim.gtk (example shamelessly stolen from the linked page, since I no longer have any Debian boxes to check for myself on :). No magic binaries or argv[0] fu. In one way, it's an elegant solution. On the other, it's a classic example of Wheeler's Law in action. :) Jon -- Jonathan Anderson Research Student, Security Group Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.ander...@cl.cam.ac.uk___ 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: CFT: new BSD-licensed sort available
This is true, debians do the symlinks trick. In Ubuntu : /usr/bin/java - /etc/alternatives/java /etc/alternatives/java - /usr/lib/jvm/java-6-openjdk/jre/bin/java Oleg From: Jonathan Anderson [mailto:jonathan.ander...@cl.cam.ac.uk] Sent: Wednesday, March 14, 2012 3:14 PM To: Adrian Chadd Cc: Gabor Kovesdan; freebsd-current@freebsd.org; Oleg Moskalenko; freebsd-po...@freebsd.org Subject: Re: CFT: new BSD-licensed sort available On 14 Mar 2012, at 21:10, Adrian Chadd wrote: Hi, This makes me think of the whole debian-y way of replacing the mailer programs using some magic alias program. So you could intall gnusort, bsdsort, and then some config file would determine which was used. 'sort' would then be a symlink to said magic program, that'd look at its argv[0], look at the contents of that file, and exec() the right one. In fact, the runtime behaviour of the Debian alternatives system is simpler than that: http://segfault.in/2010/04/using-the-debian-alternatives-system/ The custom Perl script with a config file is used to set up symlinks, which at runtime are... well, just symlinks. For instance, /usr/bin/vim is a symlink to /etc/alternatives/vim, which is itself a symlink to a binary like vim.gtk (example shamelessly stolen from the linked page, since I no longer have any Debian boxes to check for myself on :). No magic binaries or argv[0] fu. In one way, it's an elegant solution. On the other, it's a classic example of Wheeler's Law in action. :) Jon -- Jonathan Anderson Research Student, Security Group Computer Laboratory University of Cambridge +44 (1223) 763747 jonathan.ander...@cl.cam.ac.ukmailto:jonathan.ander...@cl.cam.ac.uk ___ 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
