Re: Fwd: Intel microcode update
On Fri, Mar 22, 2013 at 09:13:50AM +0100, Yamagi Burmeister wrote: > On Fri, 22 Mar 2013 09:09:22 +0100 > Yamagi Burmeister wrote: > > > Nevertheless attached is a small C program which does the > > same. It's not written by me, I just found it somewhere on the web. > > And it was eaten my the list. You can find it here: > http://deponie.yamagi.org/freebsd/misc/microdecode.c Thanks. It does decode the .dat-file . kaltheat ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bsdgrep status
On Sat, Mar 23, 2013 at 06:58:41PM +0900, Joerg Sonnenberger wrote: > On Sat, Mar 23, 2013 at 10:54:17AM +0100, Dominic Fandrey wrote: > > I'm tempted to conclude that bsdgrep is ready for deployment. > > There are still some issues. Are these issues documented somewhere? -- Joel ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: bsdgrep status
On Sat, Mar 23, 2013 at 10:54:17AM +0100, Dominic Fandrey wrote: > I'm tempted to conclude that bsdgrep is ready for deployment. There are still some issues. Joerg ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
bsdgrep status
In 2011 I substituted grep for bsdgrep in some of my more complex shell scripts and ran into some issues. Though there never was a reply to my e-mail these issues have evidently been fixed. I'm tempted to conclude that bsdgrep is ready for deployment. Apart from the performance standpoint. I repeated the following several times the result is always about the same: # time -h pkg_libchk.gnu eclipse-3.7.1_4: /usr/local/lib/eclipse/configuration/org.eclipse.osgi/bundles/119/1/.cp/libswt-awt-gtk-3738.so misses libjawt.so libreoffice-4.0.1: /usr/local/lib/libreoffice/program/xpdfimport misses libpoppler.so.18 18m7.13s real 4m49.19s user 20m54.07s sys # time -h pkg_libchk.bsd eclipse-3.7.1_4: /usr/local/lib/eclipse/configuration/org.eclipse.osgi/bundles/119/1/.cp/libswt-awt-gtk-3738.so misses libjawt.so libreoffice-4.0.1: /usr/local/lib/libreoffice/program/xpdfimport misses libpoppler.so.18 20m30.75s real 5m10.25s user 22m6.71s sys I cannot say how much of the runtime is caused by grep, but all the difference is certainly made by grep and I think the difference is significant. It's maybe not bad enough to stop the switch, however it violates the noble tradition of having command line tools that are faster than the GNU equivalents. E.g. my latest AWK script is 7 times faster using one-true-awk, compared to GNU AWK. Compare bash and ash and you'll end up with a factor around 3 for scripts that mostly use builtin commands. Regards, Kami -- A: Because it fouls the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing on usenet and in e-mail? ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: call suspend_cpus() under smp_ipi_mtx
Looks like this issue needs more thinking and discussing. The basic idea is that suspend_cpus() must be called with smp_ipi_mtx held (on SMP systems). This is for exactly the same reasons as to why we first take smp_ipi_mtx before calling stop_cpus() in the shutdown path. Essentially one CPU could be holding smp_ipi_mtx (and thus with interrupts disabled[*]) and waiting for an acknowledgement from other CPUs (e.g. in smp_rendezvous or in a TLB shootdown), while another CPU could be with interrupts disabled (explicitly - like in the shutdown or ACPI suspend paths) and trying to deliver an IPI to other CPUs. In my opinion, we must consistently use the same lock, smp_ipi_mtx, for all regular (non-NMI) synchronous IPI-based communication between CPUs. Otherwise a deadlock is quite possible. Some obstacles for just going ahead and making the suggested change: - acpi_sleep_machdep() calls intr_suspend() with interrupts disabled; currently witness(9) is not aware of that, but if smp_ipi_mtx spin-lock is used, then we would have to make intr_table_lock and msi_lock the spin-locks as well; - AcpiLeaveSleepStatePrep() (from ACPICA) is called with interrupts disabled and currently it performs an action that requires memory allocation; again, with interrupts disabled via intr_disable() this fact is not visible to witness, etc, but with smp_ipi_mtx it needs to be somehow handled. I talked to ACPICA guys about the last issue and they told me that what is currently done in AcpiLeaveSleepStatePrep does not need to be with interrupts disabled and can be moved to AcpiLeaveSleepState. This is after the _BFS and _GTS support was removed. What do you think? Thank you. -- Andriy Gapon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
