Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
Mike Meyer wrote: In [EMAIL PROTECTED], Garrett Cooper [EMAIL PROTECTED] typed: Martin Turgeon wrote: Mike Meyer a écrit : In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo Thanks a lot for the precision, I will use nocona for my dual core Xeon. Cedar Mill: Last P4 processor. Followup to Prescott. Nocona: Xeon server processor code name -- first CPU with EMT64 (amd64) compatibility [and hence first non-IA64 bit Xeon processor to feature 64-bit compatibility; not sure if it was the first non-IA64 64-bit designed Intel processor]. Prescott: Single-core processor with HTT. Base CPU for [later generation] P4 processors, and the dual core Pentium D [basically the larger cousin of the Northwood CPUs]. Prescott was compacted into Cedar Mill -- from a 90nm (?) process to 65nm. From what I can tell, the Prescott went through a number of iterations; the first of them didn't have HTT, or had it but it was disabled. Later versions added that, EMT64, virtualization, and other things. If my information is correct, the nocona was the first version of the prescott core with em64t, and only used in Xeons. There was a big difference between the Prescott CPU core and the Nocona core though, in terms of technology (Pentium 4 vs Core/Core2). Apparently the pipelines for the CPU were similar for the desktop CPU though, some have claimed. I haven't looked at the RTL though, so I can't be sure for myself whether or not that's the case. And yes, I believe prescott and following were 90nm until Cedar Mill. Ok, that's what I thought (since fab screen size goes by 15nm each time nowadays). Intel suggests using -march=prescott (32-bit) and -march=nocona (64-bit) with gcc on Core2Duo processors and equivalent Xeons. Note that /usr/share/mk/sys.mk includes bsd.mk.cpu, which overrides CPUTYPE if it's set to prescott or nocona. It turns nocona into prescott if you're building for i386 and prescott into nocona if you're building for amd64. So the correct answer to the question Do I set CPUTYPE to nocona or prescott in /etc/make.conf? would seem to be It doesn't matter. Hmmm... interesting.. Seems like a bit ambitious for bsd.mk.cpu, if the user knows what they're doing. You can also find your CPU's type by going to this page: http://www.intel.com/products/server/processors/index.htm?iid=serv_body+proc, and searching for the appropriate model number. Your frequency and model should be reported in your BIOS, if not the first couple lines of dmesg in FreeBSD. I've never seen those report core names. Possibly you're referring specifically to the Xeon cpu model numbers? Yeah, that's exactly what I meant. -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
2007/6/26, Garrett Cooper [EMAIL PROTECTED]: Mike Meyer wrote: In [EMAIL PROTECTED], Garrett Cooper [EMAIL PROTECTED] typed: Martin Turgeon wrote: Mike Meyer a écrit : In [EMAIL PROTECTED], Roman Divacky [EMAIL PROTECTED] typed: For the record, I believe the nocona cores are: pentium 4/some prescott, prescott 2m, cedar mill pentium D/all core 2 duo/all All xeons with sse3 except the sossaman cored Xeon LV. The prescott cores are: pentium 4/some prescott xeon lv (sossaman core) core solo core duo Thanks a lot for the precision, I will use nocona for my dual core Xeon. Cedar Mill: Last P4 processor. Followup to Prescott. Nocona: Xeon server processor code name -- first CPU with EMT64 (amd64) compatibility [and hence first non-IA64 bit Xeon processor to feature 64-bit compatibility; not sure if it was the first non-IA64 64-bit designed Intel processor]. Prescott: Single-core processor with HTT. Base CPU for [later generation] P4 processors, and the dual core Pentium D [basically the larger cousin of the Northwood CPUs]. Prescott was compacted into Cedar Mill -- from a 90nm (?) process to 65nm. From what I can tell, the Prescott went through a number of iterations; the first of them didn't have HTT, or had it but it was disabled. Later versions added that, EMT64, virtualization, and other things. If my information is correct, the nocona was the first version of the prescott core with em64t, and only used in Xeons. There was a big difference between the Prescott CPU core and the Nocona core though, in terms of technology (Pentium 4 vs Core/Core2). Apparently the pipelines for the CPU were similar for the desktop CPU though, some have claimed. I haven't looked at the RTL though, so I can't be sure for myself whether or not that's the case. And yes, I believe prescott and following were 90nm until Cedar Mill. Ok, that's what I thought (since fab screen size goes by 15nm each time nowadays). Intel suggests using -march=prescott (32-bit) and -march=nocona (64-bit) with gcc on Core2Duo processors and equivalent Xeons. Note that /usr/share/mk/sys.mk includes bsd.mk.cpu, which overrides CPUTYPE if it's set to prescott or nocona. It turns nocona into prescott if you're building for i386 and prescott into nocona if you're building for amd64. So the correct answer to the question Do I set CPUTYPE to nocona or prescott in /etc/make.conf? would seem to be It doesn't matter. Hmmm... interesting.. Seems like a bit ambitious for bsd.mk.cpu, if the user knows what they're doing. You can also find your CPU's type by going to this page: http://www.intel.com/products/server/processors/index.htm?iid=serv_body+proc, and searching for the appropriate model number. Your frequency and model should be reported in your BIOS, if not the first couple lines of dmesg in FreeBSD. I've never seen those report core names. Possibly you're referring specifically to the Xeon cpu model numbers? Yeah, that's exactly what I meant. -Garrett please correct me if I'm wrong, but gcc(1) can help us a bit also; http://www.freebsd.org/cgi/man.cgi?query=gccsektion=1format=html z.B.: (...) prescott Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3 instruction set support. nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. (...) athlon-4, athlon-xp, athlon-mp Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE instruction set support. k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.) (...) -- Zavam, Vinícius ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Play with the VM
Hi, I have some questions about virtual memory and the freebsd implementation. I am trying to map in userland (with a syscall like mmap) some anonymous data (from sockets, files ...). What's the best way to do this ? There are callbacks in the VM when a user process tries to access a specific address ? Thanks in advance -- Nicolas Cormier ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: CPUTYPE in general - was Re: Which CPUTYPE for a dualcore Xeon on AMD64
In [EMAIL PROTECTED], Zavam, Vinícius [EMAIL PROTECTED] typed: 2007/6/26, Garrett Cooper [EMAIL PROTECTED]: Mike Meyer wrote: nowadays). Intel suggests using -march=prescott (32-bit) and -march=nocona (64-bit) with gcc on Core2Duo processors and equivalent Xeons. Note that /usr/share/mk/sys.mk includes bsd.mk.cpu, which overrides CPUTYPE if it's set to prescott or nocona. It turns nocona into prescott if you're building for i386 and prescott into nocona if you're building for amd64. So the correct answer to the question Do I set CPUTYPE to nocona or prescott in /etc/make.conf? would seem to be It doesn't matter. Hmmm... interesting.. Seems like a bit ambitious for bsd.mk.cpu, if the user knows what they're doing. please correct me if I'm wrong, but gcc(1) can help us a bit also; http://www.freebsd.org/cgi/man.cgi?query=gccsektion=1format=html Right. We actually discussed this, then wondered into the history of the CPU cores. You start with misc/cpuid to get a list of features your CPU has, then use the gcc man page to figure out which cputype will use the most features of your CPU without trying to use features which your CPU doesn't have. z.B.: (...) prescott Improved version of Intel Pentium4 CPU with MMX, SSE, SSE2 and SSE3 instruction set support. nocona Improved version of Intel Pentium4 CPU with 64-bit extensions, MMX, SSE, SSE2 and SSE3 instruction set support. (...) athlon-4, athlon-xp, athlon-mp Improved AMD Athlon CPU with MMX, 3dNOW!, enhanced 3dNOW! and full SSE instruction set support. k8, opteron, athlon64, athlon-fx AMD K8 core based CPUs with x86-64 instruction set support. (This supersets MMX, SSE, SSE2, 3dNOW!, enhanced 3dNOW! and 64-bit instruction set extensions.) (...) mike -- Mike Meyer [EMAIL PROTECTED] http://www.mired.org/consulting.html Independent Network/Unix/Perforce consultant, email for more information. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
strange wi driver things.
Hi.. Last kernel was build at Wed Jun 20 23:20:34 CEST 2007 from head. At first glance: 1) Channel number is +1. 2) Getting alot of wi0: record read mismatch, rid=fd44, got=8000 Where the got part changes randomly. 3) wi0: xmit failed 4) 'ifconfig wi0 list scan' returns nothing at first run, then on second go it looks right. http://people.freebsd.org/~xride/wi.txt There is some logs there. /Soeren -- Soeren Straarup | aka OZ2DAK aka Xride FreeBSD committer | FreeBSD since 2.2.6-R If a program is not working right, then send a patch ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0×0483 vendor and 0×2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? -- Patrick Tracanelli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
On Tue, 26 Jun 2007, 15:40-0300, Patrick Tracanelli wrote: Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0?0483 vendor and 0?2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? port 2 addr 2: full speed, power 100 mA, config 1, Biometric Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01 Controller /dev/usb4: ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
Maxim Konovalov wrote: On Tue, 26 Jun 2007, 15:40-0300, Patrick Tracanelli wrote: Maxim Konovalov wrote: On Fri, 22 Jun 2007, 17:42-0300, Patrick Tracanelli wrote: Hello all, I have used the mentioned devices on FreeBSD 5.4 in the past, and they worked just fine, but now I get problems with the same device, on top of 6.2-STABLE and also 7.0-CURRENT. [...] Just for the record: the above mentioned device works fine on lenovo x60s and 6.2-STABLE. Is it 0?0483 vendor and 0?2016 device? Which revision? Can you please send the relevant output from usbdevs -v and the ugen device from /var/run/dmesg.boot? port 2 addr 2: full speed, power 100 mA, config 1, Biometric Coprocessor(0x2016), STMicroelectronics(0x0483), rev 0.01 Controller /dev/usb4: ugen0: STMicroelectronics Biometric Coprocessor, rev 1.00/0.01, addr 2 Exactly the same. Did you do anything different from using securyt/bioapi, securiy/bsp_upektfmess and security/pam_bsdbioapi and creating birdb.conf? -- Patrick Tracanelli ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: UPEK/TouchChip Biometric Device problem
[...] Exactly the same. Did you do anything different from using securyt/bioapi, securiy/bsp_upektfmess and security/pam_bsdbioapi and creating birdb.conf? No, I didn't. It works out of the box. -- Maxim Konovalov ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: 6.1 - amd64 arch. Hangs twice a day, how can i debug problem
On 2007-Jun-23 11:01:49 +0300, zkan KIRIK [EMAIL PROTECTED] wrote: I have a FreeBSD 6.1 - STABLE 200609 gateway have 3 up interfaces. First one connected to 16Mbps Internet Connection, Next onet connected to DMZ Zone (192.168.0.0/24 network) The Last interface connected to Local network. this system hangs twice a day. Keyboard doesnt work, everything locks, no network reponse! For a quick solution i wrote a crontab that reboots system at 20.00 PM 06.00 AM. How can I find the problem which hangs system? Is there any method for this. This sort of thing is very difficult to debug. My suggestions would be: - Check for flaky hardware - maybe run memtest86 overnight. - Run one of the following: while sleep 5; do date; vmstat -m; done while sleep 5; do date; netstat -m; done top systat -v 2 on a VTY or a serial console and see when it's dying and what was happening shortly before. - Check if anything unusual (cron jobs or unusual external activity) happens at the time it dies. - You may be able to debug a frozen system via firewire Or any known bug reports at this release ? I don't recall this particuar problem being reported. That said, you appear to be running a 9 month old -stable - have you considered updating to either 6.2 or a more recent -stable? -- Peter Jeremy pgpsgXJnIDnMJ.pgp Description: PGP signature
Re: Which CPUTYPE for a dualcore Xeon on AMD64
Martin Turgeon wrote on Sun, Jun 24, 2007 at 07:32:22PM -0400: Hi, I recently installed AMD64 6.2 Release on 2 PowerEdge servers, both with dual core Xeon (3070 and 5110). I extensively benchmarked different compiler options on Xeon 5160 (3.0 GHz Core2) with gcc-4.1.2 and gcc-4.2. Apart from very minor differences the best was plain -O3 -finline-limit=xxx where xxx was different by code, some code ran faster with 400 and other code with 750 (both beating the 600 default). The inline limit made a bigger difference than most of the other options and I actually ended up compiling parts of my code with a differen inline-limit than others. The result was within a percent of all highly tuned CPU-specific options like -march=k8 -msse3 -mfpmath=sse -ffast-math, and I went through most iterations. This means that locking your code to one x86_64 implementation and locking out either AMD or Intel is not worth the trouble. Testing was done on gcc-4.2.1 and later partially verified with gcc-4.2. Gcc-4.2 was a little slower overall but the same options were about the same speed. I also tested with Intel's icc 9.0 which didn't even come close to either gcc, even if you were willing to wait 10 times as long for compilation to finish (for inter-object file optimizations). No inlining limit would bring Intel's icc code size down to close what gcc had and subsequently performance was bad. gcc-3.4 was blown out of the water by gcc-4, too. Martin -- %%% Martin Cracauer [EMAIL PROTECTED] http://www.cons.org/cracauer/ FreeBSD - where you want to go, today. http://www.freebsd.org/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
devfs symlink over device doesn't work
After deleting a device in devfs, any symlink placed over it results in ENOENT. # cd /dev # rm console # touch /var/log/console # ln -s /var/log/console console # ls -l console ls: console: No such file or directory I'd like to fix this behavior. Or is there a reason for it that I'm not seeing? Reasoning: I'm using devfs in jails, and I'd like anything written (by user space programs, syslogd, etc...) to /dev/console to go to a file in the jail. So at jail startup I'd like to put a symlink over /dev/console to a normal file. Cheers, Stef Walter ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Gigabit Ethernet w/Jumbo Frames
I'm having poor luck trying to use NFS over a gigabit ethernet using jumbo frames. By all indications, my switch (Netgear GS608) forwards jumbo frames with no difficulty, but my Realtek 8169-based cards seem unreceptive to the idea, giving many watchdog timeouts and other obscure log messages. One server is amd64 and my clients are i386, but I think I've ruled that out as the problem because I see errors evern with an i386 server. So I strongly suspect my network cards at the moment. What gigabit ethernet cards do you use for reliable performance with jumbo frames?-- George Mitchell ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gigabit Ethernet w/Jumbo Frames
On Tue, Jun 26, 2007 at 05:33:46PM -0700, [EMAIL PROTECTED] wrote: I'm having poor luck trying to use NFS over a gigabit ethernet using jumbo frames. By all indications, my switch (Netgear GS608) forwards jumbo frames with no difficulty, but my Realtek 8169-based cards seem unreceptive to the idea, giving many watchdog timeouts and other obscure log messages. One server is amd64 and my clients are i386, but I think I've ruled that out as the problem because I see errors evern with an i386 server. So I strongly suspect my network cards at the moment. What gigabit ethernet cards do you use for reliable performance with jumbo frames?-- George Mitchell Are you setting any sysctl tunables? There have been recent reports of watchdog timeout problems with xl, bge, and em devices. I've manage to work around the timeout on bge with net.inet.tcp.sendspace=131072 net.inet.tcp.recvspace=131072 net.inet.tcp.path_mtu_discovery=0 net.inet.udp.recvspace=65536 net.inet.raw.recvspace=16384 hw.pci.enable_msix=0 hw.pci.enable_msi=0 kern.ipc.nmbclusters=5 kern.timecounter.hardware=ACPI-fast -- Steve ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Gigabit Ethernet w/Jumbo Frames
On Tue, Jun 26, 2007 at 05:33:46PM -0700, [EMAIL PROTECTED] wrote: I'm having poor luck trying to use NFS over a gigabit ethernet using jumbo frames. By all indications, my switch (Netgear GS608) forwards jumbo frames with no difficulty, but my Realtek 8169-based cards seem unreceptive to the idea, giving many watchdog timeouts and other obscure log messages. One server is amd64 and my clients are i386, but I think I've ruled that out as the problem because I see errors evern with an i386 server. So I strongly suspect my network cards at the moment. What gigabit ethernet cards do you use for reliable performance with jumbo frames?-- George Mitchell See http://lists.freebsd.org/pipermail/freebsd-current/2007-May/072845.html -- Regards, Pyun YongHyeon ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
