Re: [ HEADS UP ] Ports unstable for the next 10 days
On Tue, 13 Apr 2010 16:03:22 -0700 Ted Faber fa...@isi.edu wrote: On Sun, Mar 28, 2010 at 04:38:28PM +0300, Ion-Mihai Tetcu wrote: Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. I didn't see any mial, but figured I'd check. Are ports still unstable? ATM no, as it's apparent from the message bellow. Update to that message: - Gnome and KDE are ready - Xorg is believed to be ready, an -exp run on pointy is beginning today. On Thu, 8 Apr 2010 13:23:08 -0700 Charlie Kester corky1...@comcast.net wrote: On Sun 28 Mar 2010 at 06:38:28 PDT Ion-Mihai Tetcu wrote: Hi, As announced before, a few big commits, that touch some thousands ports are being done: png, curl, x11, gnome, kde4. The target ETA is 6-7 April. The first one was done, update of graphics/png (including a shared lib version bump), with about 5000 ports affected. We do _NOT_ recommend updating ports until this commits are all done, and the problems are fixed, except if you want to help testing / fixing. Before reporting failures, please take a look at ports@ list, and http://qat.tecnik93.com/index.php?action=failed_buildportssort=last_built to find out if the problem hasn't already been reported or even fixed. We also have two incremental builds on Pointy to catch the problems. Thank you, With hat:portmgr@ Sorry if this seems like nagging, but since we're now past the original ETA can we get a current status report? Is the portstree considered stable again, and if not, what's the revised ETA? From: Ion-Mihai Tetcu ite...@freebsd.org To: Ion-Mihai Tetcu ite...@freebsd.org Cc: sta...@freebsd.org, questi...@freebsd.org, freebsd-po...@freebsd.org Subject: Re: [ HEADS UP ] Ports unstable for the next 10 days Date: Mon, 5 Apr 2010 21:31:33 +0300 Just a status update: PNG and cURL are in, and png fall-outs are believed to be fixed. Xorg update has gone through an -exp run on Pointy and our xorg team is working on fixing the approx. 60 ports with problems. still work to do I will begin -exp runs for Gnome and KDE updates tonight or tomorrow morning. Gnome -exp done, there's a showstopper on amd64 that we weren't aware of. about 40 fixesso far. An other -exp needed. KDE in progress. Packages status: - i386: - 6 after png and curl - 7 after png and curl - an 8 incremental build is in progress and should be shortly finished finished - 9 pacakges are from middle March from 9 Apr. - amd64: - 6 packages are post png and curl - 7 build is in progress and will be finished tomorrow - 8 last build was done in the middle of the png update/fixes; we won't run an other before Xorg, KDE and Gnome go in (for lack of resources). in progress, with ports from yesterday - 9 build in progress (with sources that are believed to fix the zlib problem). nope, still old packages. In other words, if you wish to update without waiting for Xorg, Gnome and KDE now it's a good moment. So no clear ETA yet, a few days more. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: Strange Swapping Issues(?)
Hi Jeremy, On Wed, Apr 14, 2010 at 7:26 AM, Jeremy Chadwick free...@jdc.parodius.com wrote: The swapinfo command you ran was not run at 05:26 in the morning. It was run a few minutes after. I accidentally got it live :) Well, I was expecting that because I have seen similar message previously in the logs. I think it is unlikely that things suddenly fall below 3% after the kernel has complained about the lack of swap space. Please, correct me, if I am wrong here. You should probably set up a small script, run via cronjob, that logs swapinfo -h output to a file somewhere (rotate it if you want via newsyslog.conf). Great idea, will do it. You may have something running on the system that spirals out of control, such as a web board script being pounded to death, or something that's forking excessively. It is called parallel nightly build of the Glasgow Haskell Compiler :D According to its official documentation, compilation and testing is very intensive, indeed. I am trying to launch the builders in different times in order to distribute the load. I'd also recommend having the script output top -b -o res 100, which will give you the top 100 processes on the machine sorted by RSS [..] So I'm making the assumption RSS will be large. We will see soon... Thanks for the quick help! :g ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
On Sun, 11 Apr 2010 23:40:03 +0300 Mikolaj Golub wrote: MG Hi, MG Today I have upgraded the kernel in my VirtualBox (3.1.51.r27187) to the MG latest current and have em0: Watchdog timeout -- resetting issue. My MG previous kernel was for Mar 12. MG Tracking the revision where the problem appeared I see that the issue is not MG observed for r203834 and starts to observe after r205869. MG Interestingly, if I enter ddb and then exit (sometimes I needed to do this MG twice) the errors stop and network starts working. Adding some prints I observed the following: Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 813, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 818, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: setting watchdog_check to TRUE in lem_mq_start_locked 1 (ticks 818, watchdog_ time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 818, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 823, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: setting watchdog_check to TRUE in lem_mq_start_locked 1 (ticks 828, watchdog_ time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 923, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 3 (ticks: 923, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 3 (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: Watchdog timeout -- resetting (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 1024, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 1028, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 1128, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 1 (ticks: 1128, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: Watchdog timeout -- resetting (ticks: 1128, watchdog_time: 0) ... So althogh adapter-watchdog_check was set TRUE, adapter-watchdog_time was never set. I see that before r205869 watchdog_time was set in em_xmit but lem_xmit does not contain this. After adding back this line to lem_xmit (see the first patch below) the problem has gone on my box. Also seeing that in the current em_mq_start_locked() both watchdog_check and watchdog_time are set I tried another patch adding watchdog_time setting in lem_mq_start_locked() too (see the second patch below). This has also fixed the issue for me but I don't know if this is a correct fix and if this is the only place where watchdog_time should be set (there are other places in the function and in the code where watchdog_check is set to TRUE but watchdog_time is not set). -- Mikolaj Golub Index: sys/dev/e1000/if_lem.c === --- sys/dev/e1000/if_lem.c (revision 206595) +++ sys/dev/e1000/if_lem.c (working copy) @@ -1880,6 +1880,7 @@ lem_xmit(struct adapter *adapter, struct mbuf **m_ */ tx_buffer = adapter-tx_buffer_area[first]; tx_buffer-next_eop = last; + adapter-watchdog_time = ticks; /* * Advance the Transmit Descriptor Tail (TDT), this tells the E1000 Index: sys/dev/e1000/if_lem.c === --- sys/dev/e1000/if_lem.c (revision 206595) +++ sys/dev/e1000/if_lem.c (working copy) @@ -873,6 +873,7 @@ lem_mq_start_locked(struct ifnet *ifp, struct mbuf */ ETHER_BPF_MTAP(ifp, m); adapter-watchdog_check = TRUE; + adapter-watchdog_time = ticks; } } else if ((error = drbr_enqueue(ifp, adapter-br, m)) != 0) return (error); ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Freeze on my laptop.
On Wed, Apr 14, 2010 at 3:31 AM, Demelier David demelier.da...@gmail.com wrote: Hi, I'm so sad because FreeBSD is the one which can runs almost perfectly on my laptop. But it freezes. Sometime I just do anything and I want to click on a link in firefox, or open a terminal and then freeze. There is no messages, no reboot nothing. Can't know where that come from. I'm running 8.0-STABLE on a hp probook 4510s. King regards, -- Demelier David ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org do u have dumpdev set in your rc.conf ? try setting it to AUTO, you might get a core dump on next reebot dumpdev=AUTO there is very little in your mail to infer anything, do you use wireless net access ? what graphics card you have ? these threads might be of help to you http://lists.freebsd.org/pipermail/freebsd-questions/2010-March/214339.html http://lists.freebsd.org/pipermail/freebsd-stable/2010-April/056096.html http://lists.freebsd.org/pipermail/freebsd-hackers/2006-April/016107.html ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
ath0: kernel panic when adhoc mode.
Hi! I install 8.0 FreeBSD, upgrade it to yesturday stable. I need to create wireless link in adhoc mode. Help me to do this. I put a wireless card into this box: a...@pci0:3:3:0:class=0x02 card=0xcc2114b9 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR5212)' class = network subclass = ethernet cap 01[44] = powerspec 2 supports D0 D3 current D0 when I do: # ifconfig wlan0 create wlandev ath0 wlanmode adhoc server reboot with kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor read, page not present instruction pointer = 0x20:0xc0791612 stack pointer = 0x28:0xd2f42ba4 frame pointer = 0x28:0xd2f42bac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (ath0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 3m35s Physical memory: 439 MB Dumping 80 MB: 65 49 33panic: bufwrite: buffer is not busy??? cpuid = 1 17 1 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc06b3497 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc06b3789 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc08b63bc in trap_fatal (frame=0xd2f42b64, eva=65535) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc08b6620 in trap_pfault (frame=0xd2f42b64, usermode=0, eva=65535) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc08b6f39 in trap (frame=0xd2f42b64) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0899b3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc0791612 in ieee80211_getcapinfo (vap=0xc2d5f000, chan=0x) at /usr/src/sys/net80211/ieee80211_output.c:1836 #8 0xc0793d17 in ieee80211_beacon_construct (m=0xc2edca00, frm=0xc2f0516e , bo=0xc2d5f884, ni=0xc2ceb000) at /usr/src/sys/net80211/ieee80211_output.c:2559 #9 0xc07946db in ieee80211_beacon_alloc (ni=0xc2ceb000, bo=0xc2d5f884) at /usr/src/sys/net80211/ieee80211_output.c:2756 #10 0xc050eaea in ath_newstate (vap=0xc2d5f000, nstate=IEEE80211_S_RUN, arg=-1) at /usr/src/sys/dev/ath/if_ath.c:2641 #11 0xc0798db1 in ieee80211_newstate_cb (xvap=0xc2d5f000, npending=3) at /usr/src/sys/net80211/ieee80211_proto.c:1654 #12 0xc06ebf92 in taskqueue_run (queue=0xc2a84c80) at /usr/src/sys/kern/subr_taskqueue.c:239 #13 0xc06ec19d in taskqueue_thread_loop (arg=0xc2ada074) at /usr/src/sys/kern/subr_taskqueue.c:360 #14 0xc068a331 in fork_exit (callout=0xc06ec0e0 taskqueue_thread_loop, arg=0xc2ada074, frame=0xd2f42d38) at /usr/src/sys/kern/kern_fork.c:843 #15 0xc0899bb0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) dmesg is: Copyright (c) 1992-2010 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 8.0-STABLE #0: Wed Apr 14 07:45:45 MSD 2010 r...@serv01:/usr/obj/usr/src/sys/serv01 i386 Timecounter i8254 frequency 1193182 Hz quality 0 CPU: AMD Athlon(tm) 64 X2 Dual Core Processor 4200+ (2194.76-MHz 686-class CPU) Origin = AuthenticAMD Id = 0x40fb2 Family = f Model = 4b Stepping = 2 Features=0x178bfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,MMX,FXSR,SSE,SSE2,HTT Features2=0x2001SSE3,CX16 AMD Features=0xea500800SYSCALL,NX,MMX+,FFXSR,RDTSCP,LM,3DNow!+,3DNow! AMD Features2=0x1fLAHF,CMP,SVM,ExtAPIC,CR8 real memory = 536870912 (512 MB) avail memory = 449187840 (428 MB) ACPI APIC Table: 050407 APIC1334 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 ioapic0 Version 2.1 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: 050407 RSDT1334 on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of fee0, 1000 (3) failed acpi0: reservation of ffb8, 8 (3) failed acpi0: reservation of fff8, 8 (3) failed acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 1bf0 (3) failed ACPI HPET table warning: Sequence is non-zero (2) Timecounter ACPI-safe frequency 3579545 Hz quality 850 acpi_timer0: 32-bit timer at 3.579545MHz port 0x808-0x80b on acpi0 cpu0: ACPI CPU on acpi0 cpu1: ACPI CPU on acpi0 acpi_hpet0: High Precision Event Timer iomem 0xfed0-0xfed003ff on acpi0 Timecounter HPET frequency 14318180 Hz quality 900 pcib0: ACPI Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 pcib1: ACPI PCI-PCI bridge at device 1.0 on pci0 pci1: ACPI PCI bus on pcib1 vgapci0:
Re: ath0: kernel panic when adhoc mode.
On Wednesday 14 April 2010 10:30:54 am Lystopad Olexandr wrote: Hi! I install 8.0 FreeBSD, upgrade it to yesturday stable. I need to create wireless link in adhoc mode. Help me to do this. I put a wireless card into this box: a...@pci0:3:3:0:class=0x02 card=0xcc2114b9 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR5212)' class = network subclass = ethernet cap 01[44] = powerspec 2 supports D0 D3 current D0 when I do: # ifconfig wlan0 create wlandev ath0 wlanmode adhoc I remember a colleague of mine having a similar problem. I think he eventually tried a workaround by doing it in two commands. Try to split it up to see if it works. #ifconfig wlan0 create wlandev ath0 #ifconfig wlan0 wlanmode adhoc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ath0: kernel panic when adhoc mode.
Hello, Johann Hugo! when I do: # ifconfig wlan0 create wlandev ath0 wlanmode adhoc I remember a colleague of mine having a similar problem. I think he eventually tried a workaround by doing it in two commands. Try to split it up to see if it works. #ifconfig wlan0 create wlandev ath0 #ifconfig wlan0 wlanmode adhoc Thanks for your reply! But no luck: # ifconfig wlan0 wlanmode adhoc ifconfig: wlanmode: bad value and: # ifconfig -m ath0|grep -c adhoc 80 -- Olexandr Lystopad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
on 14/04/2010 02:21 Maho NAKATA said the following: 2. install ports/math/gotoblas (manual download required) make install Do you know how gotoblas on Linux was obtained? Was it built from source? Has it come pre-packaged? If so, can you find out details of its build configuration? Thanks! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CPU problems after 8.0-STABLE update
On Wed, 14 Apr 2010 00:06:56 +0300 Andriy Gapon a...@icyb.net.ua wrote: That's pretty obvious: RTC was not used for stat clock in that version; later version did try to use RTC and now Attilio has reverted the logic back to not use RTC unless explicitly requested. What is not obvious is why your RTC doesn't work as expected. I have no answer to that. One thing that makes me suspicious is that HPET also doesn't seem to work on your system. One very very wild guess is that IRQ8 might be actually driven by HPET, not RTC. And our programming of HPET or RTC or both messes things up. It would be interesting to see if disabling HPET (acpi_hpet) changes anything: debug.acpi.disabled=hpet -- Andriy Gapon Anytime. Please tell me what options and source version (date) should I use. I'm currently on the revision from 8 April an have machdep.lapic_allclocks set to 1. -- Mihai ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CPU problems after 8.0-STABLE update
on 14/04/2010 16:28 Akephalos said the following: On Wed, 14 Apr 2010 00:06:56 +0300 Andriy Gapon a...@icyb.net.ua wrote: What is not obvious is why your RTC doesn't work as expected. I have no answer to that. One thing that makes me suspicious is that HPET also doesn't seem to work on your system. One very very wild guess is that IRQ8 might be actually driven by HPET, not RTC. And our programming of HPET or RTC or both messes things up. It would be interesting to see if disabling HPET (acpi_hpet) changes anything: debug.acpi.disabled=hpet -- Andriy Gapon Anytime. Please tell me what options and source version (date) should I use. I'm currently on the revision from 8 April an have machdep.lapic_allclocks set to 1. I think that any version of source should be good, just set machdep.lapic_allclocks to 0. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Any chance of someone commiting the patch in bin/131861 ?
http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131861 I've been using the patch now for a couple of months with no observable problems. It is very small, and does fix a real annoyance with using /usr/bin/mail as your primary mail reader. I realise this is probably a very small number of people, but it wudlbe nice to get it committed if possible... cheers, -pete. [resolutely sticking to the command line even in 2010! :-)] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Wednesday 14 April 2010 15:19:13 Andriy Gapon wrote: on 14/04/2010 02:21 Maho NAKATA said the following: 2. install ports/math/gotoblas (manual download required) make install Do you know how gotoblas on Linux was obtained? Was it built from source? Has it come pre-packaged? If so, can you find out details of its build configuration? Thanks! I think the best test would be to run a statically compiled linux binary on FreeBSD. That way the compiler settings are exactly the same. - Pieter ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ath0: kernel panic when adhoc mode.
On Wednesday 14 April 2010 02:57:35 pm Lystopad Olexandr wrote: But no luck: # ifconfig wlan0 wlanmode adhoc ifconfig: wlanmode: bad value Oops, should be: # ifconfig wlan0 mediaopt adhoc ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any chance of someone commiting the patch in bin/131861 ?
On Wed, 14.04.2010 at 14:45:55 +0100, Pete French wrote: http://www.freebsd.org/cgi/query-pr.cgi?pr=bin/131861 I've been using the patch now for a couple of months with no observable problems. It is very small, and does fix a real annoyance with using /usr/bin/mail as your primary mail reader. I realise this is probably a very small number of people, but it wudlbe nice to get it committed if possible... cheers, -pete. [resolutely sticking to the command line even in 2010! :-)] Sorry Pete, but the patch still seems incomplete. You merely catch the case when a comma is followed by space or quotation marks, but the email header might look like this: To: f...@domain.com,b...@otherdomain.com Regards, Uli ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any chance of someone commiting the patch in bin/131861 ?
Sorry Pete, but the patch still seems incomplete. You merely catch the case when a comma is followed by space or quotation marks, but the email header might look like this: To: f...@domain.com,b...@otherdomain.com I think the original code handles cases like that fine, my patch merely looks for an extra possibility. I've just tested it with the above, and it works. Can you give me an example of one which doesn't work for you ? Either in the original /usr/bin/mail or in my patched version ? cheers, -pete. PS: and thanks for taking an interest :-) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: ath0: kernel panic when adhoc mode.
Hello, Johann Hugo! On Wed, Apr 14, 2010 at 04:19:01PM +0200 jh...@meraka.csir.co.za wrote about Re: ath0: kernel panic when adhoc mode.: On Wednesday 14 April 2010 02:57:35 pm Lystopad Olexandr wrote: But no luck: # ifconfig wlan0 wlanmode adhoc ifconfig: wlanmode: bad value Oops, should be: # ifconfig wlan0 mediaopt adhoc # ifconfig wlan0 mediaopt adhoc ifconfig: SIOCSIFMEDIA (media): Device not configured :-( -- Olexandr Lystopad ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
on 14/04/2010 02:21 Maho NAKATA said the following: 4. run dgemm. % ./dgemm n: 3000 time : 134.648208 or 16.910525 Mflops : 31943.419695 n: 3100 time : 148.122279 or 18.615284 Mflops : 32017.357408 n: 3200 time : 162.45 or 20.430651 Mflops : 32087.318295 n: 3300 time : 178.497079 or 22.446093 Mflops : 32030.420499 n: 3400 time : 195.550715 or 24.586152 Mflops : 31981.873273 n: 3500 time : 213.403379 or 26.825058 Mflops : 31975.513363 n: 3600 ... above output is on Core i7 920 (2.66GHz; TurboBoost on) My results: $ ./dgemm n: 3000 time : 54.151302 or 28.189781 Mflops : 19162.263125 n: 3100 time : 60.157449 or 32.214141 Mflops : 18501.570537 n: 3200 time : 65.753191 or 34.114872 Mflops : 19216.393378 CPU: CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant ⋮ FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) FreeBSD: FreeBSD 8.0-STABLE r205070 amd64 Please note that the system was not dedicated to the test, I had Xorg+KDE3+thunderbird+skype+kopete+konsole(s) plus a bunch of daemons running. That probably explains irregularities in the results. I am not sure how exactly theoretical maximum should be calculated, I used 2 * 2.66G * 4 ≈ 21.3G. And so 19.2G / 21.3G ≈ 90%. Not as bad as what you get. Although not as good as what you report for Linux. But given the impurity and imprecision of my test… P.S. the machine is two-core obviously :-) Don't have anything with more cpus/cores handy. P.P.S. Having _only glimpsed_ at the source I think that there are some things that GotoBLAS doesn't try to do on FreeBSD that it tries to do on Linux. Like setting CPU-affinity for the threads, or avoiding HTT pseudo-cores. Those things are possible on FreeBSD. Perhaps, there are more things like that. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
Oh, didn't realize you were running the lem code :) Will make the changes shortly, thanks for your debugging efforts. Jack On Wed, Apr 14, 2010 at 2:29 AM, Mikolaj Golub to.my.troc...@gmail.comwrote: On Sun, 11 Apr 2010 23:40:03 +0300 Mikolaj Golub wrote: MG Hi, MG Today I have upgraded the kernel in my VirtualBox (3.1.51.r27187) to the MG latest current and have em0: Watchdog timeout -- resetting issue. My MG previous kernel was for Mar 12. MG Tracking the revision where the problem appeared I see that the issue is not MG observed for r203834 and starts to observe after r205869. MG Interestingly, if I enter ddb and then exit (sometimes I needed to do this MG twice) the errors stop and network starts working. Adding some prints I observed the following: Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 813, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 818, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: setting watchdog_check to TRUE in lem_mq_start_locked 1 (ticks 818, watchdog_ time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 818, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 823, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: setting watchdog_check to TRUE in lem_mq_start_locked 1 (ticks 828, watchdog_ time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 923, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 3 (ticks: 923, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 3 (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: Watchdog timeout -- resetting (ticks: 1023, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked started (ticks 1024, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_init_locked returned at 3 (ticks 1028, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof started (ticks: 1128, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: lem_txeof returned at 1 (ticks: 1128, watchdog_time: 0) Apr 14 07:14:08 hasta kernel: em0: Watchdog timeout -- resetting (ticks: 1128, watchdog_time: 0) ... So althogh adapter-watchdog_check was set TRUE, adapter-watchdog_time was never set. I see that before r205869 watchdog_time was set in em_xmit but lem_xmit does not contain this. After adding back this line to lem_xmit (see the first patch below) the problem has gone on my box. Also seeing that in the current em_mq_start_locked() both watchdog_check and watchdog_time are set I tried another patch adding watchdog_time setting in lem_mq_start_locked() too (see the second patch below). This has also fixed the issue for me but I don't know if this is a correct fix and if this is the only place where watchdog_time should be set (there are other places in the function and in the code where watchdog_check is set to TRUE but watchdog_time is not set). -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any chance of someone commiting the patch in bin/131861 ?
On Wed, 14.04.2010 at 15:38:21 +0100, Pete French wrote:
Sorry Pete, but the patch still seems incomplete. You merely catch the
case when a comma is followed by space or quotation marks, but the email
header might look like this:
To: f...@domain.com,b...@otherdomain.com
I think the original code handles cases like that fine, my patch merely
looks for an extra possibility. I've just tested it with the
above, and it works.
Can you give me an example of one which doesn't work for you ? Either
in the original /usr/bin/mail or in my patched version ?
Well, the following header didn't work:
Cc: a...@a.a,b...@b.b
Postfix will re-write this as part of sanitization, so I had to revert
to creating mbox files by hand. Anyway, could you please test the
following patch with a wider variety of mails?
commit 59a3e2a82bdeafb7bb46e8d5c39dcb2474d7f826
Author: Ulrich Spörlein u...@spoerlein.net
Date: Wed Apr 14 17:07:10 2010 +0200
bin/131861: [patch] mail(1) misses addresses when replying to all
There's a parsing error for fields where addresses are not separated by
space. This is often produced by MS Outlook, eg.:
Cc: f...@bar.com,Mr Foo f...@baz.com
The following line now splits into the right tokens:
Cc: f...@b.com,z...@y.de, a...@a.de,c...@c.de, foo foo,bar bar
diff --git a/usr.bin/mail/util.c b/usr.bin/mail/util.c
index df2d840..af962c8 100644
--- a/usr.bin/mail/util.c
+++ b/usr.bin/mail/util.c
@@ -496,10 +496,11 @@ skin(name)
*cp2++ = ' ';
}
*cp2++ = c;
- if (c == ',' *cp == ' ' !gotlt) {
+ if (c == ',' !gotlt
+ (*cp == ' ' || *cp == '' || *cp == '')) {
*cp2++ = ' ';
-while (*++cp == ' ')
- ;
+while (*cp == ' ')
+ cp++;
lastsp = 0;
bufend = cp2;
}
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Wed, Apr 14, 2010 at 10:26 AM, Andriy Gapon a...@freebsd.org wrote: on 14/04/2010 02:21 Maho NAKATA said the following: 4. run dgemm. % ./dgemm n: 3000 time : 134.648208 or 16.910525 Mflops : 31943.419695 n: 3100 time : 148.122279 or 18.615284 Mflops : 32017.357408 n: 3200 time : 162.45 or 20.430651 Mflops : 32087.318295 n: 3300 time : 178.497079 or 22.446093 Mflops : 32030.420499 n: 3400 time : 195.550715 or 24.586152 Mflops : 31981.873273 n: 3500 time : 213.403379 or 26.825058 Mflops : 31975.513363 n: 3600 ... above output is on Core i7 920 (2.66GHz; TurboBoost on) My results: $ ./dgemm n: 3000 time : 54.151302 or 28.189781 Mflops : 19162.263125 n: 3100 time : 60.157449 or 32.214141 Mflops : 18501.570537 n: 3200 time : 65.753191 or 34.114872 Mflops : 19216.393378 CPU: CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant ⋮ FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) FreeBSD: FreeBSD 8.0-STABLE r205070 amd64 Please note that the system was not dedicated to the test, I had Xorg+KDE3+thunderbird+skype+kopete+konsole(s) plus a bunch of daemons running. That probably explains irregularities in the results. I am not sure how exactly theoretical maximum should be calculated, I used 2 * 2.66G * 4 ≈ 21.3G. And so 19.2G / 21.3G ≈ 90%. Not as bad as what you get. Although not as good as what you report for Linux. But given the impurity and imprecision of my test… P.S. the machine is two-core obviously :-) Don't have anything with more cpus/cores handy. P.P.S. Having _only glimpsed_ at the source I think that there are some things that GotoBLAS doesn't try to do on FreeBSD that it tries to do on Linux. Like setting CPU-affinity for the threads, or avoiding HTT pseudo-cores. Those things are possible on FreeBSD. Perhaps, there are more things like that. Mine is also a live desktop enviro, kde4+ n: 3000 time : 116.377609 or 16.696066 Mflops : 32353.729042 n: 3100 time : 127.230336 or 17.274867 Mflops : 34501.695325 n: 3200 time : 139.018175 or 18.342056 Mflops : 35741.074976 n: 3300 time : 152.519365 or 20.154714 Mflops : 35671.942364 n: 3400 time : 166.248145 or 21.952426 Mflops : 35818.874941 n: 3500 time : 182.565385 or 24.492597 Mflops : 35020.581786 n: 3600 time : 198.551018 or 26.906992 Mflops : 34689.094992 n: 3700 time : 215.428919 or 28.574964 Mflops : 35462.294838 n: 3800 ^C CPU: Intel(R) Core(TM) i7 CPU 870 @ 2.93GHz (3313.71-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106e5 Family = 6 Model = 1e Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3fdSSE3,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant That's about 67% utilization, turning off HTT drops it more. HTT on the newer cores is good, not bad. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CPU problems after 8.0-STABLE update
On Wed, 14 Apr 2010 16:39:37 +0300 Andriy Gapon a...@icyb.net.ua wrote: Anytime. Please tell me what options and source version (date) should I use. I'm currently on the revision from 8 April an have machdep.lapic_allclocks set to 1. I think that any version of source should be good, just set machdep.lapic_allclocks to 0. -- Andriy Gapon You won't believe this, Andriy! It didn't work (top, top -P) after I rebooted my computer with that acpi option and machdep.lapic_allclocks explicitely set to zero. _However_, by reasons unknown, my computer time is offseting randomly and it happened that I saw my time showed as midnight, although it's seven in the evening. /etc/rc.d/ntpdate onerestart - and voila! Top shows correctly. Disabling all those options in loader.conf, the behavior is the same, top - and therefore powerd work after starting ntpdate. -- Mihai ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Wed, Apr 14, 2010 at 11:34 AM, Adam Vande More amvandem...@gmail.comwrote: That's about 67% utilization, turning off HTT drops it more. HTT on the newer cores is good, not bad. Well that was completely contrarty to some tests I'd run when I first got the cpu. With HTT off: n: 3000 time : 44.705516 or 11.760183 Mflops : 45932.959253 n: 3100 time : 50.598581 or 14.270123 Mflops : 41766.437458 n: 3200 time : 55.748192 or 15.780977 Mflops : 41541.458400 n: 3300 time : 62.072217 or 17.441431 Mflops : 41221.262070 n: 3400 so that's about 79% right there. also if I run cpuset on the dgemm then the utilization is basically at the theoretical max for one core so at least that part is working. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
on 14/04/2010 19:45 Adam Vande More said the following: also if I run cpuset on the dgemm then the utilization is basically at the theoretical max for one core so at least that part is working. You can also try procstat -t pid to find out thread IDs and cpuset -t to pin the threads to the cores. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: CPU problems after 8.0-STABLE update
on 14/04/2010 19:41 Akephalos said the following: You won't believe this, Andriy! It didn't work (top, top -P) after I rebooted my computer with that acpi option and machdep.lapic_allclocks explicitely set to zero. _However_, by reasons unknown, my computer time is offseting randomly and it happened that I saw my time showed as midnight, although it's seven in the evening. /etc/rc.d/ntpdate onerestart - and voila! Top shows correctly. Disabling all those options in loader.conf, the behavior is the same, top - and therefore powerd work after starting ntpdate. Indeed, that almost sounds too good to be true :-) Couple of questions: 1. Could you please check in dmesg if hpet attaches normally now or still has an error? 2. Do you have to run ntpdate after each power-off or is everything OK after the first run? 3. Have you ever set time on this machine before (in BIOS, other OS, etc)? 4. Can you please double-check that lapic_allclocks is zero in kernel? You can run 'kgdb /boot/kernel/kernel /dev/mem' and then 'print lapic_allclocks' Thanks! -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any chance of someone commiting the patch in bin/131861 ?
Well, the following header didn't work: Cc: a...@a.a,b...@b.b Ah, indeed - with the angle brackets on it does not work, either with my patch or in the original. Postfix will re-write this as part of sanitization, so I had to revert to creating mbox files by hand. Anyway, could you please test the following patch with a wider variety of mails? Sure... -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Wed, Apr 14, 2010 at 11:51 AM, Andriy Gapon a...@freebsd.org wrote: on 14/04/2010 19:45 Adam Vande More said the following: also if I run cpuset on the dgemm then the utilization is basically at the theoretical max for one core so at least that part is working. You can also try procstat -t pid to find out thread IDs and cpuset -t to pin the threads to the cores. it gets to around 90% doing that. time : 103.617271 or 27.140992 Mflops : 47172.925449 n: 4100 time : 113.910669 or 30.520677 Mflops : 45174.496186 n: 4200 time : 121.880695 or 32.068070 Mflops : 46217.711013 n: 4300 tried a couple of different thread orders but didn't seem to make a difference. galacticdominator% procstat -t 1922 PIDTID COMM TDNAME CPU PRI STATE WCHAN 1922 100092 dgemminitial thread 0 190 run - 1922 100268 dgemm- 1 190 run - 1922 100270 dgemm- 1 191 run - 1922 100272 dgemm- 3 190 run - 1922 100273 dgemm- 2 191 run - 1922 100274 dgemm- 2 191 run - 1922 100282 dgemm- 0 190 run - 1922 100283 dgemm- 3 190 run - galacticdominator% cpuset -t 100092 -l 0 galacticdominator% cpuset -t 100268 -l 1 galacticdominator% cpuset -t 100270 -l 2 galacticdominator% cpuset -t 100272 -l 3 galacticdominator% cpuset -t 100273 -l 0 galacticdominator% cpuset -t 100274 -l 1 galacticdominator% cpuset -t 100282 -l 2 galacticdominator% cpuset -t 100283 -l 3 galacticdominator% cpuset -t 100092 -l 0 galacticdominator% cpuset -t 100268 -l 0 galacticdominator% cpuset -t 100270 -l 1 galacticdominator% cpuset -t 100272 -l 1 galacticdominator% cpuset -t 100273 -l 2 galacticdominator% cpuset -t 100274 -l 2 galacticdominator% cpuset -t 100282 -l 3 galacticdominator% cpuset -t 100283 -l 3 This is from the second set: time : 150.348850 or 40.488350 Mflops : 45022.951141 n: 4600 time : 161.968982 or 43.589618 Mflops : 44669.884500 n: 4700 Since this is a full fledged desktop environment, 90% utilization seems pretty good. I'm no expert Andriy, but it seems like if gotoblas implemented some of the FreeBSD optimizations then we'd be in the same ballpark. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: em driver regression
On Wed, 14 Apr 2010 09:28:33 -0700 Jack Vogel wrote: Oh, didn't realize you were running the lem code :) Will make the changes shortly, r206614 works for me. Thanks :-) thanks for your debugging efforts. Jack -- Mikolaj Golub ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
From: Andriy Gapon a...@freebsd.org Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 16:19:13 +0300 on 14/04/2010 02:21 Maho NAKATA said the following: 2. install ports/math/gotoblas (manual download required) make install Do you know how gotoblas on Linux was obtained? Yes. Just download the archive. Was it built from source? Yes. Has it come pre-packaged? No. If so, can you find out details of its build configuration? I'm not sure I build like following on Ubuntu 9.10 amd64. $ tar xvfz GotoBLAS2-1.13.tar.gz $ cd GotoBLAS2 $ ./quickbuild.64bit ln -fs libgoto2_nehalemp-r1.13.a libgoto2.a for d in interface driver/level2 driver/level3 driver/others kernel lapack ; \ do if test -d $d; then \ make -j 8 -C $d libs || exit 1 ; \ fi; \ done make[1]: Entering directory `/home/maho/a/GotoBLAS2/interface' gcc -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DMAX_CPU_NUMBER=8 -DASMNAME=saxpy -DASMFNAME=saxpy_ -DNAME=saxpy_ -DCNAME=saxpy -DCHAR_NAME=\saxpy_\ -DCHAR_CNAME=\saxpy\ -I.. -I. -UDOUBLE -UCOMPLEX -c axpy.c -o saxpy.o gcc -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DMAX_CPU_NUMBER=8 -DASMNAME=sswap -DASMFNAME=sswap_ -DNAME=sswap_ -DCNAME=sswap -DCHAR_NAME=\sswap_\ -DCHAR_CNAME=\sswap\ -I.. -I. -UDOUBLE -UCOMPLEX -c swap.c -o sswap.o gcc -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DMAX_CPU_NUMBER=8 -DASMNAME=scopy -DASMFNAME=scopy_ -DNAME=scopy_ -DCNAME=scopy -DCHAR_NAME=\scopy_\ -DCHAR_CNAME=\scopy\ -I.. -I. -UDOUBLE -UCOMPLEX -c copy.c -o scopy.o gcc -O2 -DEXPRECISION -m128bit-long-double -Wall -m64 -DF_INTERFACE_GFORT -fPIC -DSMP_SERVER -DMAX_CPU_NUMBER=8 -DASMNAME=sscal -DASMFNAME=sscal_ -DNAME=sscal_ -DCNAME=sscal -DCHAR_NAME=\sscal_\ -DCHAR_CNAME=\sscal\ -I.. -I. -UDOUBLE -UCOMPLEX -c scal.c -o sscal.o -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
HyperThreading makes worse to me (was Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920)
Hi Andry and Adam My test again. No desktop, etc. I just run dgemm. Contrary to Adam's result, Hyper Threading makes the performance worse. all tests are done on Core i7 920 @ 2.67GHz. (TurboBoost @2.8GHz) Turbo Boost off, Hyper threading off: 82% (35GFlops)[1] Turbo Boost off, Hyper threading off: 72% (30.5GFlops) [2] Turbo Boost on, Hyper threading on: 71% (32GFlops)[3] Turbo Boost off, Hyper threading off: 84-89% (38-40GFlops) [4] ---my system--- CPU: Intel(R) Core(TM) i7 CPU 920 @ 2.67GHz (2683.44-MHz K8-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x98e3bdSSE3,DTES64,MON,DS_CPL,VMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT AMD Features=0x28100800SYSCALL,NX,RDTSCP,LM AMD Features2=0x1LAHF TSC: P-state invariant real memory = 12884901888 (12288 MB) avail memory = 12387717120 (11813 MB) ACPI APIC Table: 110909 APIC1026 FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 4 core(s) ---my system--- ---DETAILS--- [1] % ./dgemm n: 3000 time : 57.666717 or 16.339074 Mflops : 33060.624827 n: 3100 time : 61.502677 or 16.597376 Mflops : 35910.025544 n: 3200 time : 69.075401 or 19.199833 Mflops : 34144.297133 n: 3300 time : 73.699540 or 19.633594 Mflops : 36618.756539 n: 3400 time : 82.256194 or 22.373651 Mflops : 35144.518837 n: 3500 time : 88.975662 or 24.118761 Mflops : 35563.394249 n: 3600 time : 96.436652 or 26.027588 Mflops : 35861.148385 n: 3700 [2] % ./dgemm n: 3000 time : 139.622739 or 17.693806 Mflops : 30529.327312 n: 3100 time : 154.344971 or 19.566886 Mflops : 30460.247702 n: 3200 time : 169.507739 or 21.467100 Mflops : 30538.116602 n: 3300 time : 186.363773 or 23.615281 Mflops : 30444.600545 n: 3400 time : 203.798979 or 25.817667 Mflops : 30456.322788 n: 3500 ... [3] % ./dgemm n: 3000 time : 134.673079 or 16.958682 Mflops : 31852.711082 n: 3100 time : 148.410085 or 18.663248 Mflops : 31935.073574 n: 3200 time : 162.835473 or 20.468825 Mflops : 32027.475770 n: 3300 time : 179.025370 or 22.479189 Mflops : 31983.262501 n: 3400 time : 195.859710 or 24.663009 Mflops : 31882.208788 n: 3500 [4] % ./dgemm n: 3000 time : 54.259647 or 14.684309 Mflops : 36786.204907 n: 3100 time : 60.899147 or 17.124599 Mflops : 34804.447141 n: 3200 time : 64.295342 or 17.490787 Mflops : 37480.577569 n: 3300 time : 69.781247 or 18.288840 Mflops : 39311.284796 n: 3400 time : 79.234397 or 21.829736 Mflops : 36020.187858 n: 3500 time : 83.905419 or 22.381237 Mflops : 38324.289174 n: 3600 time : 92.195022 or 25.105942 Mflops : 37177.621122 n: 3700 time : 97.718841 or 25.434243 Mflops : 39841.319494 n: 3800 time : 105.740463 or 27.414029 Mflops : 40042.592613 n: 3900 time : 113.980157 or 29.678505 Mflops : 39984.635420 n: 4000 time : 122.941569 or 31.946174 Mflops : 40077.412531 n: 4100 ---DETAILS--- From: Adam Vande More amvandem...@gmail.com Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 11:34:45 -0500 time : 162.45 or 20.430651 Mflops : 32087.318295 n: 3300 time : 178.497079 or 22.446093 Mflops : 32030.420499 n: 3400 time : 195.550715 or 24.586152 Mflops : 31981.873273 n: 3500 time : 213.403379 or 26.825058 Mflops : 31975.513363 n: 3600 ... above output is on Core i7 920 (2.66GHz; TurboBoost on) My results: $ ./dgemm n: 3000 time : 54.151302 or 28.189781 Mflops : 19162.263125 n: 3100 time : 60.157449 or 32.214141 Mflops : 18501.570537 n: 3200 time : 65.753191 or 34.114872 Mflops : 19216.393378 CPU: CPU: Intel(R) Core(TM)2 Duo CPU E7300 @ 2.66GHz (2653.35-MHz K8-class CPU) Origin = GenuineIntel Id = 0x10676 Stepping = 6 Features=0xbfebfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE Features2=0x8e39dSSE3,DTES64,MON,DS_CPL,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1 AMD Features=0x20100800SYSCALL,NX,LM AMD Features2=0x1LAHF TSC: P-state invariant ⋮ FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) FreeBSD: FreeBSD 8.0-STABLE r205070 amd64 Please note that the system was not dedicated to the test, I had Xorg+KDE3+thunderbird+skype+kopete+konsole(s) plus a bunch of daemons running. That probably explains irregularities in the results. I am not sure how exactly theoretical maximum should be calculated, I used 2 * 2.66G * 4 ≈ 21.3G. And so 19.2G / 21.3G ≈ 90%. Not as bad as what you get. Although not as good as what you report for Linux. But given the impurity and imprecision of my test… P.S. the machine is two-core obviously :-) Don't have anything with more cpus/cores handy. ___ freebsd-stable@freebsd.org mailing list
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
opps I missed this e-mail... From: Adam Vande More amvandem...@gmail.com Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 11:45:04 -0500 On Wed, Apr 14, 2010 at 11:34 AM, Adam Vande More amvandem...@gmail.comwrote: That's about 67% utilization, turning off HTT drops it more. HTT on the newer cores is good, not bad. Well that was completely contrarty to some tests I'd run when I first got the cpu. With HTT off: n: 3000 time : 44.705516 or 11.760183 Mflops : 45932.959253 n: 3100 time : 50.598581 or 14.270123 Mflops : 41766.437458 n: 3200 time : 55.748192 or 15.780977 Mflops : 41541.458400 n: 3300 time : 62.072217 or 17.441431 Mflops : 41221.262070 n: 3400 so that's about 79% right there. also if I run cpuset on the dgemm then the utilization is basically at the theoretical max for one core so at least that part is working. -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Hi Andriy and Adam, I did also the same thing as suggested. my conclusion: on Core i7 920, 2.66GHz, TurboBoost on, HyperThreading off, My result of dgemm GotoBLAS performance was following. *summary of result 36-39GFlops 81-87% of peak performance without pinning 35-40GFlops 78-89% of peak performance with pinning my observation * performance is somewhat unstable like 35GFlops then next calculation is 40GFlops...and flips etc. jittering is observed. * pinning makes performance somewhat stabler, but we don't gain a bit more. Details. First I ran %./dgemm n: 3500 time : 84.431008 or 22.428125 Mflops : 38244.168629 n: 3600 time : 90.162220 or 23.440381 Mflops : 39819.284422 n: 3700 time : 101.427504 or 27.404345 Mflops : 36977.121646 Note: 36-39GFlops 81-87% of peak performance then, pinned to each core like following % procstat -t 1408 PIDTID COMM TDNAME CPU PRI STATE WCHAN 1408 100160 dgemm- 3 190 run - 1408 100161 dgemm- 2 190 run - 1408 100162 dgemm- 2 190 run - 1408 100163 dgemm- 1 189 run - 1408 100164 dgemm- 0 190 run - 1408 100165 dgemm- 3 189 run - 1408 100166 dgemm- 1 190 run - 1408 100167 dgemminitial thread 0 190 run - % cpuset -t 100160 -l 0 % cpuset -t 100161 -l 0 % cpuset -t 100162 -l 1 % cpuset -t 100163 -l 1 % cpuset -t 100164 -l 2 % cpuset -t 100165 -l 2 % cpuset -t 100166 -l 3 % cpuset -t 100167 -l 3 then, % procstat -t 1408 PIDTID COMM TDNAME CPU PRI STATE WCHAN 1408 100160 dgemm- 0 191 run - 1408 100161 dgemm- 0 191 run - 1408 100162 dgemm- 1 190 run - 1408 100163 dgemm- 1 190 run - 1408 100164 dgemm- 2 190 run - 1408 100165 dgemm- 2 190 run - 1408 100166 dgemm- 3 190 run - 1408 100167 dgemminitial thread 3 190 run - n: 4000 time : 121.907696 or 31.475052 Mflops : 40677.295630 n: 4100 time : 139.842701 or 38.702532 Mflops : 35624.444587 n: 4200 time : 143.622179 or 36.725949 Mflops : 40356.011158 n: 4300 time : 153.742976 or 39.465752 Mflops : 40301.013511 n: 4400 time : 164.919566 or 42.380653 Mflops : 40208.611317 n: 4500 time : 175.930335 or 45.422572 Mflops : 40132.139469 Thanks From: Adam Vande More amvandem...@gmail.com Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 12:47:31 -0500 On Wed, Apr 14, 2010 at 11:51 AM, Andriy Gapon a...@freebsd.org wrote: on 14/04/2010 19:45 Adam Vande More said the following: also if I run cpuset on the dgemm then the utilization is basically at the theoretical max for one core so at least that part is working. You can also try procstat -t pid to find out thread IDs and cpuset -t to pin the threads to the cores. it gets to around 90% doing that. time : 103.617271 or 27.140992 Mflops : 47172.925449 n: 4100 time : 113.910669 or 30.520677 Mflops : 45174.496186 n: 4200 time : 121.880695 or 32.068070 Mflops : 46217.711013 n: 4300 tried a couple of different thread orders but didn't seem to make a difference. galacticdominator% procstat -t 1922 PIDTID COMM TDNAME CPU PRI STATE WCHAN 1922 100092 dgemminitial thread 0 190 run - 1922 100268 dgemm- 1 190 run - 1922 100270 dgemm- 1 191 run - 1922 100272 dgemm- 3 190 run - 1922 100273 dgemm- 2 191 run - 1922 100274 dgemm- 2 191 run - 1922 100282 dgemm- 0 190 run - 1922 100283 dgemm- 3 190 run - galacticdominator% cpuset -t 100092 -l 0 galacticdominator% cpuset -t 100268 -l 1 galacticdominator% cpuset -t 100270 -l 2 galacticdominator% cpuset -t 100272 -l 3 galacticdominator% cpuset -t 100273 -l 0 galacticdominator% cpuset -t 100274 -l 1 galacticdominator% cpuset -t 100282 -l 2 galacticdominator% cpuset -t 100283 -l 3 galacticdominator% cpuset -t 100092 -l 0 galacticdominator% cpuset -t 100268 -l 0 galacticdominator% cpuset -t 100270 -l 1 galacticdominator% cpuset -t 100272 -l 1 galacticdominator% cpuset -t 100273 -l 2 galacticdominator% cpuset -t 100274 -l 2 galacticdominator% cpuset -t 100282 -l 3 galacticdominator% cpuset -t
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Hi Adam, From: Adam Vande More amvandem...@gmail.com Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 12:47:31 -0500 Since this is a full fledged desktop environment, 90% utilization seems pretty good. No, I don't think so. Even on Ubuntu, mine is running on a full desktop environment, GotoBLAS's performance is about 95% using dgemm. dgemm on Linux is lot more stabler than FreeBSD and clearly faster. on Ubuntu $ ./dgemm n: 3000 time : 51.18 or 12.795519 Mflops : 42216.341930 n: 3100 time : 56.28 or 14.261719 Mflops : 41791.049205 n: 3200 time : 61.35 or 15.631380 Mflops : 41939.023080 n: 3300 time : 67.79 or 17.247202 Mflops : 41685.474166 n: 3400 time : 73.80 or 18.471321 Mflops : 42569.300032 n: 3500 time : 81.48 or 20.781936 Mflops : 41273.585044 n: 3600 time : 88.17 or 22.816965 Mflops : 40907.246233 n: 3700 time : 95.21 or 23.864101 Mflops : 42462.684969 n: 3800 thanks -- Nakata Maho http://accc.riken.jp/maho/ , http://ja.openoffice.org/ Nakata Maho's PGP public keys: http://accc.riken.jp/maho/maho.pgp.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HyperThreading makes worse to me (was Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920)
On Wed, Apr 14, 2010 at 5:46 PM, Maho NAKATA cha...@mac.com wrote: Hi Andry and Adam My test again. No desktop, etc. I just run dgemm. Contrary to Adam's result, Hyper Threading makes the performance worse. all tests are done on Core i7 920 @ 2.67GHz. (TurboBoost @2.8GHz) Turbo Boost off, Hyper threading off: 82% (35GFlops) [1] Turbo Boost off, Hyper threading off: 72% (30.5GFlops) [2] Turbo Boost on, Hyper threading on: 71% (32GFlops) [3] Turbo Boost off, Hyper threading off: 84-89% (38-40GFlops) [4] Doesn't this make sense? Hyperthreaded cores in Intel procs still provide an incomplete set of registers as they're logical processors, so I would expect for things to be slower if they're automatically run on the SMT cores instead of the physical ones. Is there a weighting scheme to SCHED_ULE where logical processors (like the SMT variety) get a lower score than real processors do, and thus get scheduled for less intensive interrupting tasks, or maybe just don't get scheduled in high use scenarios like it would if it was a physical processor? Thanks, -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HyperThreading makes worse to me (was Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920)
On Wed, Apr 14, 2010 at 7:49 PM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Apr 14, 2010 at 5:46 PM, Maho NAKATA cha...@mac.com wrote: Hi Andry and Adam My test again. No desktop, etc. I just run dgemm. Contrary to Adam's result, Hyper Threading makes the performance worse. all tests are done on Core i7 920 @ 2.67GHz. (TurboBoost @2.8GHz) Turbo Boost off, Hyper threading off: 82% (35GFlops) [1] Turbo Boost off, Hyper threading off: 72% (30.5GFlops) [2] Turbo Boost on, Hyper threading on: 71% (32GFlops) [3] Turbo Boost off, Hyper threading off: 84-89% (38-40GFlops) [4] Doesn't this make sense? Hyperthreaded cores in Intel procs still provide an incomplete set of registers as they're logical processors, so I would expect for things to be slower if they're automatically run on the SMT cores instead of the physical ones. Is there a weighting scheme to SCHED_ULE where logical processors (like the SMT variety) get a lower score than real processors do, and thus get scheduled for less intensive interrupting tasks, or maybe just don't get scheduled in high use scenarios like it would if it was a physical processor? Err... wait. Didn't see that the turbo boost results didn't scale linearly or align with one another until just a sec ago. Nevermind my previous comment. -Garrett ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: Any chance of someone commiting the patch in bin/131861 ?
Pete French petefre...@ticketswitch.com wrote: ... using /usr/bin/mail as your primary mail reader ... -pete. [resolutely sticking to the command line even in 2010! :-)] You're not the only one :) Not to discourage any improvements in the base, but have you looked at ports/mail/heirloom-mailx (formerly known as Nail)? It's a descendant of /usr/bin/mail, but much more featureful :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HyperThreading makes worse to me (was Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920)
On Wed, 14 Apr 2010, Garrett Cooper wrote: On Wed, Apr 14, 2010 at 7:49 PM, Garrett Cooper yanef...@gmail.com wrote: On Wed, Apr 14, 2010 at 5:46 PM, Maho NAKATA cha...@mac.com wrote: Hi Andry and Adam My test again. No desktop, etc. I just run dgemm. Contrary to Adam's result, Hyper Threading makes the performance worse. all tests are done on Core i7 920 @ 2.67GHz. (TurboBoost @2.8GHz) Turbo Boost off, Hyper threading off: 82% (35GFlops) [1] Turbo Boost off, Hyper threading off: 72% (30.5GFlops) [2] Er, shouldn't one of those say HTT on? and/or Turbo boost on? Else they're both the same test as [4] but with different results? Turbo Boost on, Hyper threading on: 71% (32GFlops) [3] Turbo Boost off, Hyper threading off: 84-89% (38-40GFlops) [4] Clarification of all four possible test configs - 8 if you add pinning CPUs or not - might make this a bit clearer? Doesn't this make sense? Hyperthreaded cores in Intel procs still provide an incomplete set of registers as they're logical processors, so I would expect for things to be slower if they're automatically run on the SMT cores instead of the physical ones. Since we're talking FP, do HTT 'cores' share an FPU, or have their own? If contended, you'd have to expect worse (at least FP) performance, no? Is there a weighting scheme to SCHED_ULE where logical processors (like the SMT variety) get a lower score than real processors do, and thus get scheduled for less intensive interrupting tasks, or maybe just don't get scheduled in high use scenarios like it would if it was a physical processor? Err... wait. Didn't see that the turbo boost results didn't scale linearly or align with one another until just a sec ago. Nevermind my previous comment. Waiting for the fog to lift .. cheers, Ian___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HyperThreading makes worse to me
From: Ian Smith smi...@nimnet.asn.au Subject: Re: HyperThreading makes worse to me (was Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920) Date: Thu, 15 Apr 2010 14:21:30 +1000 (EST) Er, shouldn't one of those say HTT on? and/or Turbo boost on? Else they're both the same test as [4] but with different results? sorry, Turbo Boost off, Hyper threading off: 82% (35GFlops) [1] Turbo Boost off, Hyper threading on: 72% (30.5GFlops) [2] HTT on performs always worse. Clarification of all four possible test configs - 8 if you add pinning CPUs or not - might make this a bit clearer? right. Pinning might not be so important I guess. Core i7 is not NUMA. Thanks, -- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/ Blog: http://blog.goo.ne.jp/nakatamaho/ , GPG key: http://accc.riken.jp/maho/maho.pgp.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Linux static linked ver doesn't work on FBSD (Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920)
From: Pieter de Goeje pie...@degoeje.nl Subject: Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920 Date: Wed, 14 Apr 2010 16:05:18 +0200 I think the best test would be to run a statically compiled linux binary on FreeBSD. That way the compiler settings are exactly the same. It is not possible for Linux amd64 binary to run on FreeBSD amd64, ...and not i386 version neither. GotoBLAS uses special systeml call. % ./dgemm linux_sys_futex: unknown op 265 linux: pid 1264 (dgemm): syscall mbind not implemented n: 3000 ^C just halt. -- Nakata Maho http://accc.riken.jp/maho/ , JA OOO http://ja.openoffice.org/ Blog: http://blog.goo.ne.jp/nakatamaho/ , GPG key: http://accc.riken.jp/maho/maho.pgp.txt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: HyperThreading makes worse to me
on 15/04/2010 07:28 Maho NAKATA said the following: right. Pinning might not be so important I guess. Core i7 is not NUMA. It still should be beneficial from the point of view of core local caches. If a thread that works on the same data set (non shared) stays on the same core the chances are greater that the data stays in cache. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
Re: How to reproduce: Re: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
on 15/04/2010 04:20 Maho NAKATA said the following: Hi Andriy and Adam, I did also the same thing as suggested. my conclusion: on Core i7 920, 2.66GHz, TurboBoost on, HyperThreading off, So HyperThreading is off. then, pinned to each core like following % procstat -t 1408 PIDTID COMM TDNAME CPU PRI STATE WCHAN 1408 100160 dgemm- 3 190 run - 1408 100161 dgemm- 2 190 run - 1408 100162 dgemm- 2 190 run - 1408 100163 dgemm- 1 189 run - 1408 100164 dgemm- 0 190 run - 1408 100165 dgemm- 3 189 run - 1408 100166 dgemm- 1 190 run - 1408 100167 dgemminitial thread 0 190 run - But there are still 8 threads. Can you check how many threads you have on Linux with the same configuration? Is it possible to tell GotoBLAS to use 4 threads? If yes, can you also test that scenario? Also, would it be possible for you to test recent 8-STABLE? Just for the sake of experiment. -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to freebsd-stable-unsubscr...@freebsd.org
