Different behavior of make(1) between command line argument and .MAKEFLAGS special target
Hi listers, Recently I found that there's different behavior of specifying -j1 in command line argument and special target ".MAKEFLAGS". According to section "SPECIAL TARGETS" in manpage of make(1): .MAKEFLAGS This target provides a way to specify flags for make when the makefile is used. The flags are as if typed to the shell, though the -f option will have no effect. Flags (except for -f) and variable assignments specified as the source for this target are also appended to the .MAKEFLAGS internal variable. Please note the difference between this target and the .MAKEFLAGS internal variable: specifying an option or variable assignment as the source for this target will affect both the current makefile and all processes that make executes. The behavior should be same while specifying flags in Makefile and typed to the shell. But when I try to set "-j" in Makefile, the behavior is different. I have filed a PR and send a patch (http://www.freebsd.org/cgi/query-pr.cgi?pr=144388). Any suggestion is welcomed. Sincerely, Jui-Nan Eric Lin ___ 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"
interrupts may not be functioning with adaptec AHA-2940 on 8-Stable
Hello world, I am getting this error ahc0: Timedout SCBs already complete. Interrupts may not be functioning. on a 8-stable system on amd64. This card used to work in a 32bit 8.0. From previous posts I found that this might be connected to interrupt code, but I am not sure this really is the same error. I tried to gather relevant information below, please let me know if I forgot anything and how I can help to get this fixed. I got this while trying to access my scsi scanner which is hooked up to the adaptec controller in question. Regards Christof uname -a = FreeBSD eri 8.0-STABLE FreeBSD 8.0-STABLE #1: Thu Feb 25 04:01:40 CET 2010 r...@eri:/usr/obj/usr/src/sys/GENERIC amd64 camcontrol -devlist = at scbus0 target 6 lun 0 (pass0) at scbus1 target 0 lun 0 (pass1,ada0) at scbus2 target 0 lun 0 (pass2,ada1) at scbus3 target 0 lun 0 (pass3,ada2) at scbus4 target 0 lun 0 (pass4,ada3) at scbus7 target 0 lun 0 (pass5,da0) relevant part of pciclonf -lv = a...@pci0:4:2:0:class=0x01 card=0x chip=0x71789004 rev=0x00 hdr=0x00 vendor = 'Adaptec Inc' device = 'Fast/Fast-Wide SCSI Ctrlr (AHA-2940/2940W)' class = mass storage subclass = SCSI dmesg = 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 #1: Thu Feb 25 04:01:40 CET 2010 r...@eri:/usr/obj/usr/src/sys/GENERIC amd64 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Core(TM) i5 CPU 660 @ 3.33GHz (3325.02-MHz K8-class CPU) Origin = "GenuineIntel" Id = 0x20652 Stepping = 2 Features=0xbfebfbff Features2=0x298e3ff,DTES64,MON,DS_CPL,VMX,SMX,EST,TM2,SSSE3,CX16,xTPR,PDCM,SSE4.1,SSE4.2,POPCNT,> AMD Features=0x28100800 AMD Features2=0x1 TSC: P-state invariant real memory = 8589934592 (8192 MB) avail memory = 8184041472 (7804 MB) ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 4 CPUs FreeBSD/SMP: 1 package(s) x 2 core(s) x 2 SMT threads cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 cpu2 (AP): APIC ID: 4 cpu3 (AP): APIC ID: 5 ACPI Warning: 32/64X FACS address mismatch in FADT - DF626E40/ 0DF626D40, using 32 (20100121/tbfadt-586) ioapic0 irqs 0-23 on motherboard kbd1 at kbdmux0 acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) Timecounter "ACPI-safe" frequency 3579545 Hz quality 850 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x408-0x40b on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 16 at device 1.0 on pci0 pci1: on pcib1 vgapci0: port 0xe000-0xe0ff mem 0xf000-0xf7ff,0xfe63-0xfe63 irq 16 at device 0.0 on pci1 vgapci1: mem 0xfe62-0xfe62 at device 0.1 on pci1 pci0: at device 22.0 (no driver attached) atapci0: port 0xf0f0-0xf0f7,0xf0e0-0xf0e3,0xf0d0-0xf0d7,0xf0c0-0xf0c3,0xf0b0-0xf0bf irq 18 at device 22.2 on pci0 atapci0: [ITHREAD] ata2: on atapci0 ata2: [ITHREAD] ata3: on atapci0 ata3: [ITHREAD] pci0: at device 22.3 (no driver attached) em0: port 0xf040-0xf05f mem 0xfe70-0xfe71,0xfe728000-0xfe728fff irq 20 at device 25.0 on pci0 em0: Using MSI interrupt em0: [FILTER] em0: Ethernet address: 00:27:0e:05:b8:cc ehci0: mem 0xfe727000-0xfe7273ff irq 16 at device 26.0 on pci0 ehci0: [ITHREAD] usbus0: EHCI version 1.0 usbus0: on ehci0 hdac0: mem 0xfe72-0xfe723fff irq 22 at device 27.0 on pci0 hdac0: HDA Driver Revision: 20100122_0141 hdac0: [ITHREAD] pcib2: irq 17 at device 28.0 on pci0 pci2: on pcib2 pcib3: irq 17 at device 28.4 on pci0 pci3: on pcib3 ehci1: mem 0xfe726000-0xfe7263ff irq 23 at device 29.0 on pci0 ehci1: [ITHREAD] usbus1: EHCI version 1.0 usbus1: on ehci1 pcib4: at device 30.0 on pci0 pci4: on pcib4 ahc0: port 0xd000-0xd0ff mem 0xfe508000-0xfe508fff irq 18 at device 2.0 on pci4 ahc0: [ITHREAD] aic7870: Single Channel A, SCSI Id=7, 16/253 SCBs isab0: at device 31.0 on pci0 isa0: on isab0 ahci0: port 0xf090-0xf097,0xf080-0xf083,0xf070-0xf077,0xf060-0xf063,0xf020-0xf03f mem 0xfe725000-0xfe7257ff irq 19 at device 31.2 on pci0 ahci0: [ITHREAD] ahci0: AHCI v1.30 with 6 3Gbps ports, Port Multiplier not supported ahcich0: at channel 0 on ahci0 ahcich0: [ITHREAD] ahcich1: at channel 1 on ahci0 ahcich1: [ITHREAD] ahcich2: at channel 2 on ahci0 ahcich2: [ITHREAD] ahcich3: at channel 3 on ahci0 ahcich3: [ITHREAD] ahcich4: at channel 4 on ahci0 ahcich4: [ITHREAD] ahcich5: at channel 5 on ahci0 ahcich5: [ITHREAD] pci0: at device 31.3 (no driver attached) acpi_button0: on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 a
Please give me Chromium ...
Few days ago, i touched for a while Google Chrome web-browser in my friend desktop -- he runs WindowsXP. The Chrome was very great program at that time. Really i want it chromium on FreeBSD desktop, too. Sombody should take to FreeBSD ports tree! That's really Big Guns ... -- 소여물 황병희(黃炳熙) | .. 출항 15분전.. "Did he really kill six men?" "That's what the newspapers claimed. Nobody ever proved it." -- Kay Adams and Michael Corleone, "Chapter 1", page 24 ___ 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"
Possible crashing bug in RELENG_8 for Realtek NICs
I have possibly found a bug in FreeBSD RELENG_8 where the system would randomly grind to a halt between 1 hour and 8 hours uptime. This did not occur in 7.2 on the same hardware. I see lots of re0: watchdog timeout messages on the console and then suddenly everything freezes - the keybaord input does not work, I cannot ssh or open any new TCP connections. Existing connections seem to work fine and still passes on traffic through the system. I posted a bug report here: http://forum.pfsense.org/index.php/topic,24158.msg124878.html It seems like it is the Realtek onboard adapter in my system. The moment I disable it in the BIOS (it is an onboard NIC) then the system does not crash anymore. I added an Intel Pro/1000 NIC and since doing that the machine is stable again. But if I re-enable the Realtek the system crashes within 8 hours. Here is some debug output that might help: # dmesg 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 #1: Mon Apr 5 12:40:40 EDT 2010 er...@freebsd_8.0_pfsense_2.0-snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense_SMP.8 i386 Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: Intel(R) Celeron(R) CPU 430 @ 1.80GHz (1795.51-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x10661 Family = 6 Model = 16 Stepping = 1 Features=0xafebfbff Features2=0xe31d AMD Features=0x2000 AMD Features2=0x1 TSC: P-state invariant real memory = 1073741824 (1024 MB) avail memory = 1023414272 (976 MB) ACPI APIC Table: ioapic0 irqs 0-23 on motherboard ipw_bss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_bss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_bss_fw, 0xc0728b70, 0) error 1 ipw_ibss: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_ibss: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_ibss_fw, 0xc0728c30, 0) error 1 ipw_monitor: You need to read the LICENSE file in /usr/share/doc/legal/intel_ipw/. ipw_monitor: If you agree with the license, set legal.intel_ipw.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (ipw_monitor_fw, 0xc0728cf0, 0) error 1 wpi: You need to read the LICENSE file in /usr/share/doc/legal/intel_wpi/. wpi: If you agree with the license, set legal.intel_wpi.license_ack=1 in /boot/loader.conf. module_register_init: MOD_LOAD (wpi_fw, 0xc08f7640, 0) error 1 wlan: mac acl policy registered kbd1 at kbdmux0 cryptosoft0: on motherboard padlock0: No ACE support. acpi0: on motherboard acpi0: [ITHREAD] acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3f70 (3) failed Timecounter "ACPI-fast" frequency 3579545 Hz quality 1000 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x808-0x80b on acpi0 cpu0: on acpi0 acpi_hpet0: iomem 0xfed0-0xfed003ff on acpi0 Timecounter "HPET" frequency 14318180 Hz quality 900 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 vgapci0: port 0xcc00-0xcc07 mem 0xfe98-0xfe9f,0xd000-0xdfff,0xfe94-0xfe97 irq 16 at device 2.0 on pci0 agp0: on vgapci0 agp0: detected 7932k stolen memory agp0: aperture size is 256M pci0: at device 27.0 (no driver attached) pcib1: irq 16 at device 28.0 on pci0 pci1: on pcib1 em0: port 0xdc00-0xdc1f mem 0xfeae-0xfeaf,0xfea0-0xfea7,0xfeadc000-0xfead irq 16 at device 0.0 on pci1 em0: Using MSIX interrupts em0: [ITHREAD] em0: [ITHREAD] em0: [ITHREAD] pcib2: irq 19 at device 28.3 on pci0 pci2: on pcib2 uhci0: port 0xc880-0xc89f irq 23 at device 29.0 on pci0 uhci0: [ITHREAD] uhci0: LegSup = 0x2f00 usbus0: on uhci0 uhci1: port 0xc800-0xc81f irq 19 at device 29.1 on pci0 uhci1: [ITHREAD] uhci1: LegSup = 0x2f00 usbus1: on uhci1 uhci2: port 0xc480-0xc49f irq 18 at device 29.2 on pci0 uhci2: [ITHREAD] uhci2: LegSup = 0x2f00 usbus2: on uhci2 uhci3: port 0xc400-0xc41f irq 16 at device 29.3 on pci0 uhci3: [ITHREAD] uhci3: LegSup = 0x2f00 usbus3: on uhci3 ehci0: mem 0xfe937c00-0xfe937fff irq 23 at device 29.7 on pci0 ehci0: [ITHREAD] usbus4: EHCI version 1.0 usbus4: on ehci0 pcib3: at device 30.0 on pci0 pci3: on pcib3 vr0: port 0xe800-0xe8ff mem 0xfebffc00-0xfebffcff irq 18 at device 1.0 on pci3 vr0: Quirks: 0x0 vr0: Revision: 0x86 miibus0: on vr0 ukphy0: PHY 1 on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr0: [ITHREAD] vr1: port 0xe400-0xe4ff mem 0xfebff800-0xfebff8ff irq 19 at device 2.0 on pci3 vr1: Quirks: 0x0 vr1: Revision: 0x86 miibus1: on vr1 ukphy1: PHY 1 on miibus1 ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto vr1: [ITHREAD] isab0: at devic
Re: em driver regression
Hi, On Thu, 8 Apr 2010 14:52:07 -0500 Brandon Gooch wrote: > On Thu, Apr 8, 2010 at 2:17 PM, Jack Vogel wrote: >> Try the code I just checked in, it puts in the CRC stripping, but also >> tweaks the >> TX code, this may resolve the watchdogs. Let me know. >> >> Cheers, >> >> Jack >> > > Yes, this is indeed the fix for both the dhclient and VirtualBox issue > (at least with my setup). There appear to be no ill effects either. Today I have upgraded the kernel in my VirtualBox (3.1.51.r27187) to the latest current and have "em0: Watchdog timeout -- resetting" issue. My previous kernel was for Mar 12. Tracking the revision where the problem appeared I see that the issue is not observed for r203834 and starts to observe after r205869. Interestingly, if I enter ddb and then exit (sometimes I needed to do this twice) the errors stop and network starts working. -- 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: Please give me Chromium ...
Byung-Hee HWANG wrote: > > Few days ago, i touched for a while Google Chrome web-browser in my > friend desktop -- he runs WindowsXP. The Chrome was very great program > at that time. Really i want it chromium on FreeBSD desktop, too. > http://chromium.jaggeri.com/ http://chromium.jaggeri.com/subscriptions -- View this message in context: http://old.nabble.com/Please-give-me-Chromium-...-tp28210936p28212019.html Sent from the freebsd-stable mailing list archive at Nabble.com. ___ 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"
Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
Hi FreeBSD developers, [the original article in Japanese can be found at http://blog.goo.ne.jp/nakatamaho/e/b5f6fbc3cc6e1ac4947463eb1ca4eb0a ] *Abstract* I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd64 using dgemm (a linear algebra routine, matrix-matrix multiplication). I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 and almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed. *Introduction* I'm a friend of Gotoh Kazushige, the principal developers of GotoBLAS. He told me that FreeBSD is not suitable OS for scientific computing or high performance computing. He says (in Japanese and my translation): > I guess FreeBSD does page coloring, but I don't think FreeBSD considers very > large cache > size which recent CPU has. Support of a very large cache on Linux is still > not very will > sophisticated, but on *BSDs, its worst; they uses too fine memory allocation > method, > so we cannot expect large continuous physical memory allocation. > Moreover, process scheduling is not so nice as *BSD employs an algorithm that > changes physical CPUs in turn instead of allocating one core for such kind of > jobs. > Take your own benchmark, and you'll see.. *Result* Machine: Core i7 920 (42.56-44.8Gflops) / DDR3 1066 OS: FreeBSD 8.0/amd64 and Ubuntu 9.10 GotoBLAS2: 1.13 dgemm result OS : FLOPS : percent in peak FreeBSD : 32.0 GFlops : 71% Ubuntu : 42.0-42.7GFlops : 93.8%-95.3% 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: Only 70% of theoretical peak performance on FreeBSD 8/amd64, Corei7 920
On Sun, Apr 11, 2010 at 9:12 PM, Maho NAKATA wrote: > Hi FreeBSD developers, > [the original article in Japanese can be found at > http://blog.goo.ne.jp/nakatamaho/e/b5f6fbc3cc6e1ac4947463eb1ca4eb0a ] > > *Abstract* > I compared the peak performance of FreeBSD 8.0/amd64 and Ubuntu 9.10 amd64 > using dgemm > (a linear algebra routine, matrix-matrix multiplication). > I obtained only 70% of theoretical peak performance on FreeBSD 8/amd64 and > almost 95% on Ubuntu 9.10 /amd64. I'm really disappointed. > > *Introduction* > I'm a friend of Gotoh Kazushige, the principal developers of GotoBLAS. He > told me that > FreeBSD is not suitable OS for scientific computing or high performance > computing. He says > (in Japanese and my translation): > >> I guess FreeBSD does page coloring, but I don't think FreeBSD considers very >> large cache >> size which recent CPU has. Support of a very large cache on Linux is still >> not very will >> sophisticated, but on *BSDs, its worst; they uses too fine memory allocation >> method, >> so we cannot expect large continuous physical memory allocation. >> Moreover, process scheduling is not so nice as *BSD employs an algorithm that >> changes physical CPUs in turn instead of allocating one core for such kind >> of jobs. >> Take your own benchmark, and you'll see.. > > *Result* > Machine: Core i7 920 (42.56-44.8Gflops) / DDR3 1066 > OS: FreeBSD 8.0/amd64 and Ubuntu 9.10 > GotoBLAS2: 1.13 > > dgemm result > OS : FLOPS : percent in peak > FreeBSD : 32.0 GFlops : 71% > Ubuntu : 42.0-42.7GFlops : 93.8%-95.3% I'm not sure if this is the exact issue, but it might be a point of reference worth investigating: http://lists.freebsd.org/pipermail/freebsd-hackers/2010-March/031004.html 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"
