Re: [solved] How to tell whether CPU supports x64?
The original system... I said (on 2011/03/17): CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2387.76-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 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=0x4400CNTX-ID,b14 Logical CPUs per core: 2 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 Adam Vande More amvandemore_gmail.com replied (on 2011/03/17): On Thu, Mar 17, 2011 at 5:14 PM, Ilya Kazakevich kazakevichilya_gmail.comwrote: Afaik there should be LM in AMD features output. Even for Intel. Grep your dmesg.boot for LM. yes that is correct, LM stands for Long Mode which indicates amd64 support. If your CPU doesn't list it, it's either a 32 bit only CPU, or it's a bug. Thanks everyone for the assistance. There is no LM feature in dmesg.boot for the system in question, although a different system reports: CPU: Intel(R) Xeon(R) CPU E5520 @ 2.27GHz (2261.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x106a5 Stepping = 5 Features=0x1781fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,MMX,FXSR,SSE,SSE2,HTT Features2=0x80182201SSE3,SSSE3,CX16,SSE4.1,SSE4.2,b31 AMD Features=0x2010NX,LM AMD Features2=0x1LAHF Cores per package: 16 Logical CPUs per core: 2 The Intel site does say the E5520 supports x64. It seems the lack of LM in the original system does in fact mean it's a 32-bit only processor. John Levine johnl_iecc.com replied (on 2011/03/17): Looking at the Intel web site, the only Xeon I see that runs at 2.4GHz and has two cores with two threads is the Xeon 3060, which does indeed provide the 64 bit instruction set. I looked at the ark.intel.com site hoping to find what processor would report Id = 0xf29 Stepping = 9. I had no luck. I think the dual processors is because of HyperThreading, as indicated by the HTT feature, and that it's actually only a single core. Devin Teske dteske_vicor.com replied (on 2011/03/17): I wrote this for the job (please, suggestions/comments very welcome): #include stdio.h/* printf(3) */ #include stdlib.h /* EXIT_SUCCESS exit(3) */ ... I tried the program, and it reports x86_64 support: NO on both the original system, and the one above that appears to be x64-capable (although it is running the i386 install, which may be why?). Again, thanks all for the help. ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
How to tell whether CPU supports x64?
I have a remote server, and I'd like to know if it will support 64-bit instructions. Is there some way I can tell? It's running 32-bit FreeBSD right now. From dmesg.boot: Timecounter i8254 frequency 1193182 Hz quality 0 CPU: Intel(R) Xeon(TM) CPU 2.40GHz (2387.76-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf29 Stepping = 9 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=0x4400CNTX-ID,b14 Logical CPUs per core: 2 real memory = 1073676288 (1023 MB) avail memory = 1041502208 (993 MB) ACPI APIC Table: DELL PE1750 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 1 I've had no luck trying to search for the id/stepping. Would the feature list show x64 support? ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Foiling MITM attacks on source and ports trees
Unless designed carefully, there will be substantial logistical problems to maintaining such lists of signatures. ... You can then verify the correctness of what's on your disk ... The idea is that one needs to get this public key only once ... IMHO, this could or should take place at the subversion server itself. This problem has already been solved in the form of Git*. Now whether FreeBSD can/will migrate to Git or an equivalent for version control is another question. The security benefits would result even if a trusted person (the FreeBSD security team, maybe?) maintained a git mirror of the CVS/Subversion/Whatever repository. Git avoids the issue of versioned lists of signatures by simply making the version history of the repository an unbroken chain. If any link in history is changed, the sha1 checksums no longer compute. By simply verifying a sha1 hash, you can be assured (at least, as assured as [that implementation of] sha1 can make you feel) that the files at that point in time and all their prior history are exactly the same on your computer as what's on the distribution server. No lengthy lists or checksum tuples are required. The checksums are built in to the version control itself. Git also provides a mechanism for cryptographic sign-off of tags, which would provide the public/private keyed infrastructure you're trying to (awkwardly) replicate with SSL and PKI. The combination of sha1-strength history integrity verification and cryptographic tags mean all the information necessary to validate your on-disk source tree (and its history) is widely available and easily verified even if obtained from an untrusted source. You will need a secure means of obtaining either a (single) sha1 hash or a public key, but everything else can e verified once you have that small bit of very public (and therefore difficult to forge) information. Even if Git isn't the answer, it's at least worth stealing some of their ideas. * http://git.or.cz ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: FreeBSD update warns about 7.0 end of life
When running freebsd-update on FreeBSD 7.0, I noticed this message: WARNING: FreeBSD 7.0-RELEASE is approaching its End-of-Life date. Key concept: RELEASE. Robert Huff I'm not trying to be dense, but what is that supposed to mean? I see this on http://www.freebsd.org/releases/7.0R/announce.html: The FreeBSD Security Team currently plans to support FreeBSD 7.0 until February 28th, 2009. As far as I can tell, 7.1 hasn't even undergone RC2 build yet, much yet the actual -RELEASE build. So what am I supposed to do about this warning and the impending cessation of security support? Will the Security Team actually support 7.0R longer than originally expected? If so, can freebsd-update be made to understand that and stop issuing worrisome warnings? If the Security Team will stop supporting 7.0R, what _will_ they be supporting come Feb? Assuming 7.1R makes it out the door soon, will I really only have seven or so weeks to upgrade? The Security Team is apparently supporting 6.4R well into 2010; should I downgrade to keep receiving security updates? Thanks, Tait ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to freebsd-questions-unsubscr...@freebsd.org
Re: Max. number of opened files, efficiency
How many files can I open under FreeBSD, at the same time? ... I tried to open 1000 temporary files and I could do so within one second. Another interesting (offtopic) question is that I could not open 10 000 files under Windows XP. Error was too many open file. How to overcome this? The maximum number of files is controlled by kern.maxfilesperproc in /etc/sysctl.conf. It appears (on my 7.0 system) that the default is 2599. The maximum number of files per process for Windows XP is controlled in stdio.h and is set to 512 (with three eaten by stdin/stdout/stderr). On earlier versions of Windows, this number was much lower. The way to overcome this is almost always to redesign your program. You're not spawning 1000 threads (I hope) to write to every file simultaneously, so you can probably move the open/write/close-file inside your 1-to-1000 for loop and only need one file open at once, which is much more reasonable. If the size of your temporary files is small, you might look at using in-memory variables instead of files. Tait ___ freebsd-questions@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-questions To unsubscribe, send any mail to [EMAIL PROTECTED]
