1 |
On December 8, 2018 6:23:04 PM UTC, Dale <rdalek1967@×××××.com> wrote: |
2 |
>Alexander Puchmayr wrote: |
3 |
>> Am Donnerstag, 6. Dezember 2018, 10:27:31 CET schrieb Dale: |
4 |
>>> Howdy, |
5 |
>>> |
6 |
>>> I mentioned in other threads that I'm doing some upgrades to my |
7 |
>system. |
8 |
>>> My first question is about a CPU upgrade. I currently have this for |
9 |
>my |
10 |
>>> CPU, from cpuinfo: |
11 |
>>> |
12 |
>>> AMD Phenom(tm) II X4 955 Processor |
13 |
>>> |
14 |
>>> I've bought but not yet installed a FX-8350 CPU. I have this in my |
15 |
>>> make.conf file: |
16 |
>>> |
17 |
>>> CFLAGS="-march=native -O2 -pipe" |
18 |
>> Compiling the whole system with -march=native might lead to troubles, |
19 |
> |
20 |
>> especially when doing a CPU change. This option means that gcc is |
21 |
>determining |
22 |
>> the type of CPU automatically and adjusts the instruction set used to |
23 |
>exactly |
24 |
>> this CPU. Although, in your case, it is highly likely that your new |
25 |
>CPU |
26 |
>> understands all commands from the old, but I wouldn't bet on it. Its |
27 |
>possible |
28 |
>> that your existing software encounters problems like "illegal |
29 |
>instruction" or |
30 |
>> the like. Very bad if your compiler crashes after CPU replacement, |
31 |
>then you |
32 |
>> cannot emerge anything. I highly recommend using CFLAGS="-O2 -pipe" |
33 |
>and |
34 |
>> nothing more, the performance difference is, if measurable at all, |
35 |
>negligible. |
36 |
>> |
37 |
>>> USE_CPU="fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca |
38 |
>cmov |
39 |
>>> pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext fxsr_opt |
40 |
>>> pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl |
41 |
>nonstop_tsc |
42 |
>>> extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy svm extapic |
43 |
>>> cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs skinit wdt |
44 |
>>> nodeid_msr hw_pstate npt lbrv svm_lock nrip_save" |
45 |
>>> |
46 |
>> As someone else in this thread already mentioned, USE_CPU is not |
47 |
>used. What |
48 |
>> you're looking for is CPU_FLAGS_X86=..., which defines what |
49 |
>cpu-specific options |
50 |
>> will be enabled for packages supporting it and where it makes sense. |
51 |
>See |
52 |
>> package cpuid2cpuflags for details. |
53 |
>> |
54 |
>> Regards |
55 |
>> Alex |
56 |
>> |
57 |
> |
58 |
>It seems the holiday shopping is slowing down delivery. My fan was |
59 |
>supposed to be here today but didn't arrive. Since I got time, I'll |
60 |
>change the CFLAGS for at least the @system stuff, that should get me |
61 |
>booted for sure. While the native setting makes things easier for |
62 |
>normal use, I can see the point of not using it when changing CPUs. |
63 |
>That is one reason for this thread. The CPUs are different and may |
64 |
>require some changes during the swap. |
65 |
> |
66 |
>Is there a easy way to see what if any changes will be made? I did a |
67 |
>emerge -UDNa @system but it's not showing any change. Does it require |
68 |
>a |
69 |
>emerge -e @system to force the change? Or is it not changing anything? |
70 |
> |
71 |
>Thanks much. Better safe than sorry. ;-) |
72 |
> |
73 |
>Dale |
74 |
> |
75 |
>:-) :-) |
76 |
|
77 |
A CFLAGS change requires a rebuild of all packages done with gcc. I am not aware of a simple way of only doing those, so a "emerge --empty @world" will be needed. |
78 |
|
79 |
-- |
80 |
Joost |
81 |
-- |
82 |
Sent from my Android device with K-9 Mail. Please excuse my brevity. |