NAS4Free to FreeNAS Transition and hardware upgrade

[mnemonic]

So I finally upgraded my NAS Hardware and moved back to FREENAS 9.1.1 RC2 x64. In most parts everything went smoothly but I got some issues:

1. I would like to see the fanspeed and even more important the temps. I got an AMD FX 5700. Yes, I support the underdog, no Intel here. Could it be that amdtemp does not work on freebsd with newer Bulldozers? I read something like it in a freebsd forum. What's that all about?

sysctl - a | grep -i temp


[root@freenas ~]# sysctl -a | grep -i temp
device amdtemp
device coretemp
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c
losed
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray c
losed
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: 0

2. Isn't freenas using geli for encryption? Isn't geli working below the filesystem? So why no ufs support? Without encryption I can't use it.

3. What does

+hwpstate0: set freq failed, err 6

mean? I've got that in my security output.

4. There seems something wrong with my ada1 but I'm sure what it is. If it's the HDD I'll replace it but I've read it could be something with the cable or sata port too. If I would change the port on my mainboard what steps would be required to get the pool working again? Or is freenas so clever to recognize what happened? Smartctl outputs below:

[root@freenas] ~# smartctl -a -q noserial /dev/ada1
smartctl 6.1 2013-03-16 r3800 [FreeBSD 9.1-STABLE amd64] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Family: Western Digital Red (AF)
Device Model: WDC WD30EFRX-68AX9N0
Firmware Version: 80.00A80
User Capacity: 3,000,592,982,016 bytes [3.00 TB]
Sector Sizes: 512 bytes logical, 4096 bytes physical
Device is: In smartctl database [for details use: -P show]
ATA Version is: ACS-2 (minor revision not indicated)
SATA Version is: SATA 3.0, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Aug 23 17:07:57 2013 CEST
SMART support is: Available - device has SMART capability.
SMART support is: Enabled

=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

General SMART Values:
Offline data collection status: (0x00) Offline data collection activity
was never started.
Auto Offline Data Collection: Disabled.
Self-test execution status: ( 0) The previous self-test routine completed
without error or no self-test has ever
been run.
Total time to complete Offline
data collection: (38580) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 387) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x70bd) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.

SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 0
3 Spin_Up_Time 0x0027 187 182 021 Pre-fail Always - 5616
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 9
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 100 100 000 Old_age Always - 143
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 9
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 3
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 5
194 Temperature_Celsius 0x0022 122 116 000 Old_age Always - 28
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 0
198 Offline_Uncorrectable 0x0030 100 253 000 Old_age Offline - 0
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 0

SMART Error Log Version: 1
No Errors Logged

SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed without error 00% 101 -
# 2 Short offline Completed without error 00% 94 -

SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
Checking for uids of 0:
root 0

Checking for passwordless accounts:

Checking login.conf permissions:

Checking for ports with mismatched checksums:

freenas.local kernel log messages:
+++ /tmp/security.fTqJ3w0e2013-08-23 03:01:01.000000000 +0200
+(ada0:ahcich0:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 48 d8 d5 40 84 00 00 00 00 00
+(ada0:ahcich0:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada0:ahcich0:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 18 e4 37 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 c8 e4 37 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 78 e5 37 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 28 e6 37 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 d8 e6 37 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 48 2e ea 40 84 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 e8 48 2f ea 40 84 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 b0 c8 e8 82 40 ea 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): READ_FPDMA_QUEUED. ACB: 60 b0 78 e9 82 40 ea 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 90 2c ea 40 84 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b8 90 2d ea 40 84 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 00 d3 64 40 19 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b8 00 d4 64 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 b8 d4 64 40 19 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b8 b8 d5 64 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 70 d6 64 40 19 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 70 2e ad 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 20 2f ad 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 d0 2f ad 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 98 84 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 48 85 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 f8 85 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 a8 86 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 58 87 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 08 88 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 b8 88 82 40 85 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b0 d0 2c d9 40 19 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 b8 70 38 03 40 1a 00 00 00 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command
+(ada1:ahcich1:0:0:0): WRITE_FPDMA_QUEUED. ACB: 61 00 28 39 03 40 1a 00 00 01 00 00
+(ada1:ahcich1:0:0:0): CAM status: Uncorrectable parity/CRC error
+(ada1:ahcich1:0:0:0): Retrying command

freenas.local login failures:

freenas.local refused connections:

-- End of security output --

5. If I do a gui Upgrade, why does freenas show all files in the file selector? Wouldn't .txz be enough? I could locate the file easier then. Additionally why do I have to open the sha 256 txt file and manually copy the value? How about a .txt file upload for the hash and the file is read by freenas? That would it make it less a hassle.

 

[DarkPower]

Hello,

Here the file to put in /boot/kernel/. You need to mount / in rw.
It works only for 9.x on x64 system.

Value to put on /etc/loader.conf via System -> Tunables -> add Tunable on the GUI

Code:

amdtemp_load="YES"                        # AMD K8, K10, K11 cpu thermal sensors
hint.acpi_throttle.0.disabled="YES"      # Cool'n'quiet feature  --> facultatif

To correct the value of the sensor (on /etc/sysctl.conf), add this to System -> Tunables -> Sysctls

Code:

dev.amdtemp.0.sensor_offset="-6"          # Temp cpu correction

Code:

$ sysctl -a | grep -i temp
device  amdtemp
device  coretemp
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: 0
dev.cpu.0.temperature: 74.2C
dev.cpu.1.temperature: 74.2C
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%parent: hostb4
dev.amdtemp.0.sensor_offset: -6
dev.amdtemp.0.core0.sensor0: 74.2C

 

[mnemonic]

Hello Darkpower,
your answer looked good. Tried the steps, but my temp output stayed the same. Maybe I'm too stupid. I used winscp to copy the file and changed the permissons. I mounted the filesystem readwrite first. Later I added the tunables and the sysctl via gui. Please have a look at the pics.

Best regards,
mnemonic

@Freenas Team: "Why u no default amdtemp?!"

 

[DarkPower]

Hi,

You miss to gunzip the file ;)
I forgot to mention that...

 

[mnemonic]

Hello DarkPower,

dammit! I did. Well, but fixing that wasn't good enough. I deleted the gz file using WinSCP. Then upload the unziped file and set the excutable permissions. Now I get the errors below.

[root@freenas] ~# sysctl -a | grep -i temp
device amdtemp
device coretemp
module_register: module hostb/amdtemp already exists!
Module hostb/amdtemp failed to register: 17
cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed
<118>sysctl: unknown oid 'dev.amdtemp.0.sensor_offset'
net.inet6.ip6.use_tempaddr: 0
net.inet6.ip6.temppltime: 86400
net.inet6.ip6.tempvltime: 604800
net.inet6.ip6.prefer_tempaddr: 0
hw.usb.template: 0
[root@freenas] ~#

Best regards,
mnemonic

 

[DarkPower]

Dis you reboot ?

 

[mnemonic]

yes

 

[DarkPower]

Hum it seems there is a conflit with another driver :/. I've no idea tonight...tomorrow maybe ?

 

[cyberjock]

Yes, that module is already included in FreeNAS. If you want to use your custom module you have to recompile FreeNAS without the module and then add your own.

 

[mnemonic]

Hello Cyberjock,

is adding support for new AMD cpu in freenas amdtemp.ko a problem? I just don't get why AMD is so badly supported, also in other projects. If AMD kills the x86 desktop cpu production because of too low sale volume, the reinstated Intel monopoly will result in increased priced and slowmo development.

Best regards
mnemonic

 

[Whattteva]

Yeah, I agree with you. The only reason we went through the GigaHertz war and got to multi-cores and 64-bit so fast was really because AMD turned up the heat on Intel. If they reclaimed their monopoly crown, we shall welcome another era of stagnation and still expensive prices.

 

[cyberjock]

Hello Cyberjock,

is adding support for new AMD cpu in freenas amdtemp.ko a problem? I just don't get why AMD is so badly supported, also in other projects. If AMD kills the x86 desktop cpu production because of too low sale volume, the reinstated Intel monopoly will result in increased priced and slowmo development.

Best regards
mnemonic

It is when AMD provides little support for open source projects like FreeBSD/Linux. AMD has always been slow to adopt. Just look at Linux on the desktop. If you want 3D gaming you are buying Nvidia. Period. There are no reasonable options by AMD/ATI at any price. And AMD laid off 1/2 of their open source developers a few months back.

So to answer your question: "Yes, it is a problem."

Yeah, I agree with you. The only reason we went through the GigaHertz war and got to multi-cores and 64-bit so fast was really because AMD turned up the heat on Intel. If they reclaimed their monopoly crown, we shall welcome another era of stagnation and still expensive prices.

Naa, Intel stepped into the gigahertz war with their great technology called NetBurst(hint: it wasn't that great). It allowed for amazingly high frequencies for its time, but didn't provide the anticipated performance or allow the scaling up of frequencies as expected(Pentium 4s were expected to scale to almost 10Ghz). If Netburst had scaled to 10Ghz, AMD would have been in trouble. Shows how close the game is between the two companies.

The 64 bit thing was pretty much right as expected(at least for the x86 instruction computing). If you look at the natural progression from 4bit to 8bit to 16bit to 32bit to 64bit it came a little earlier than was actually expected. About a year later, but well within the expected timeframe that engineers had predicted in the 1980s. 128bit x86 CPUs are expected something like 2045 now if I remember correctly.

Think of it like this:

8-bit 1972 (8008) (4 years for next "step")
16-bit 1976 (8088) (9 years for next "step")
32-bit 1985 (80386) (20 years for next step was predicted, actual was 18 years for AMD and 19 years for Intel)
64-bit (AMD in 2003, but Intel in 2004 with the announcement of Windows XP x64), So Intel was "early" and AMD was technically "very early". But who really cared about anything that came "early" if there wasn't an OS that really used it? Even now plenty of applications still don't use 64 bit almost 10 years later.

128-bit ??? (but predicted for 42 years from 64-bit, or approximately 2046).

 

[mnemonic]

Cyberjock,

tell me, if adding support for current AMD cpus is a problem, why are there alternative amdtemp.ko modules available which prodvide it? Even more important; why is amdtemp.ko "baked" into freenas instead of loading it as a module. It undermines the point of kernel modules, doesn't it? Recompiling the whole freenas is out of the practical scope of "Joe Average" like myself.

First you mock about AMD and then you recommend Nvidia? You must be joking. You might google "Linus Tovalds nvidia" to learn about the great nvidia history with OpenSource. Well, to my knowledge AMD is not so struggling in the 3dcard business like they do in the x86 desktop cpu business. Buying stuff is not always a question if something is pricely reasonable. You have got to see the big picture, asking about the consequences. If more people would do this jobs and waste wouldn't go "the cheap way" down the road with all the bad consequences.

Pentium4 @ 10GHz? Lol, it comes with an atomic reactor cooling system. AMD would have been in real trouble. Well in any case without AMD cpu developement would have taken the bus lane. That's for sure.

64-bit (AMD in 2003, but Intel in 2004 with the announcement of Windows XP x64), So Intel was "early" and AMD was technically "very early". But who really cared about anything that came "early" if there wasn't an OS that really used it? Even now plenty of applications still don't use 64 bit almost 10 years later.

IIRC, intel licensed the x64 instruction set by the cross licensing agreement they have with AMD. Chicken and egg. Something had to come first, and in this case it HAD to be the hardware because you can't install an 64bit os on a 32bit cpu. Well 64bit is for most apps not so important. The 32bit emu seems to me quite good. Important is that the OS is 64bit so you can use the memory beyond 3,5GB for your apps alltogether. But this transistion had another very good effect: Until 64bit OSes, third party companies updated their old driver and they were o.k., even if they were crappy drivers. 64bit forced them to develop new drivers and in my experience, most crappy drivers were left behind. Crappy drivers were one of the main reasons for crashes, at least on winblows.

Well I'll wait some time, maybe better AMD support will find it's way into freenas at a later date.

Kind regards,
mnemonic

 

[cyberjock]

Cyberjock,

tell me, if adding support for current AMD cpus is a problem, why are there alternative amdtemp.ko modules available which prodvide it? Even more important; why is amdtemp.ko "baked" into freenas instead of loading it as a module. It undermines the point of kernel modules, doesn't it? Recompiling the whole freenas is out of the practical scope of "Joe Average" like myself.

It is a problem, as I said above. Did you read my comment? Let me quote myself for you...

It is when AMD provides little support for open source projects like FreeBSD/Linux. AMD has always been slow to adopt. Just look at Linux on the desktop. If you want 3D gaming you are buying Nvidia. Period. There are no reasonable options by AMD/ATI at any price. And AMD laid off 1/2 of their open source developers a few months back.

So to answer your question: "Yes, it is a problem."

As for why precisely, I don't know. Not an AMD owner and my Intel(just like every single other Intel CPU I've owned, the temps just worked). You know why Intel's "just work" when AMD's "just don't"? And this goes back years and years and across every OS that uses x86. Because Intel provided their own spec and their own code to the FreeBSD community(along with Linux and Windows). AMD instead made the motherboard manufacturer responsible for maintaining compliance, and then the motherboard manufacturers totally butchered that all to hell. So who is responsible for fixing the problem that has been created? AMD doesn't want to fix what they didn't break and motherboard manufacturer's don't have the resources or experience(or want to spend the money) to go providing code for OSes, so it goes unfixed. Unfortunately AMD hasn't made the realization that if they were to instead do what Intel does and make the spec entire CPU bound then the problem would be gone. There could be legal reasons(patents, etc.) but you and I will probably never know.

First you mock about AMD and then you recommend Nvidia? You must be joking. You might google "Linus Tovalds nvidia" to learn about the great nvidia history with OpenSource. Well, to my knowledge AMD is not so struggling in the 3dcard business like they do in the x86 desktop cpu business. Buying stuff is not always a question if something is pricely reasonable. You have got to see the big picture, asking about the consequences. If more people would do this jobs and waste wouldn't go "the cheap way" down the road with all the bad consequences.

Yeah, he's upset because Nvidia won't make their driver open source for the world to see. When stuff changes Nvidia's driver may break, and then everyone has to wait for Nvidia to provide the driver fix. Performance in linux hasn't been as good as some other OSes, like Windows. But something is much better than nothing, which is about what you get about AMD. Linus Torvalds hates the fact that Nvidia provides a binary blob only. You really should understand the argument before you try to defend it. His biggest problem isn't that Nvidia's driver sucks, its that its a binary blob and he doesn't like that. When it breaks everything grinds to a halt until they fix it. Lots of people have theorized that because the driver has proprietary support with things such as Dolby Digital Surroundsound in the driver that it can't be released as source code. After all, if Nvidia has a confidentiality agreement with DD(or whatever else you want) they may not be able to release the driver as source code even if they want to. This was a problem with Creative Labs when Vista came out. Allegedly the licensing was for XP only, so your shiny Creative Labs hardware wasn't compatible(officially) with Vista without buying new hardware(that had the new license agreements between Creative Labs and other companies for allowing newer drivers).

And you are really going to argue with me about this stuff in a FreeBSD forum? Let's stay on topic. I really don't care if you want to brand me an Intel fanboy, Anti-AMD gamer, or whatever. I like what I like and that's that. Both companies have had their ups and downs, and anyone that wants to argue for or against one of the companies is way too emotional about a company and needs to realize these are companies. Nothing more. They compete, just like all other companies out there. Intel has done way more for the computing industry than AMD has(and possibly ever will). But AMD has had their share of inventions that helped and AMD deserves credit for their successes, and rightfully so.

IIRC, intel licensed the x64 instruction set by the cross licensing agreement they have with AMD. Chicken and egg. Something had to come first, and in this case it HAD to be the hardware because you can't install an 64bit os on a 32bit cpu. Well 64bit is for most apps not so important. The 32bit emu seems to me quite good. Important is that the OS is 64bit so you can use the memory beyond 3,5GB for your apps alltogether. But this transistion had another very good effect: Until 64bit OSes, third party companies updated their old driver and they were o.k., even if they were crappy drivers. 64bit forced them to develop new drivers and in my experience, most crappy drivers were left behind. Crappy drivers were one of the main reasons for crashes, at least on winblows.

Actually, Microsoft did NOT do any of their official inhouse testing on AMD CPUs. None. They simply followed the spec for the x64 design(which Intel actually had a hand in because it affected Intel patents more then AMD's patents but AMD slapped their name on it when they released their version first(and that's what we the consumer saw). If you knew the background you'd also know that both Intel and AMD worked with various other vendors to develop the "x86_64" instruction set. AMD created their own slightly modified version of AMD64 while Intel used their own slightly modified EM64T set. Guess which one is more widely used despite having the AMD64 name on it? You guessed it, Intel's. But props to AMD for their development costs. I've always wondered what would have been different with the 64 bit implementation if it had been solely Intel or solely AMD since they have two very different "theory of operation" of CPUs. Intel has always heavily relied on their on-CPU cache to provide performance while AMD has relied on a heavily optimized CPU.

But guess what AMD hasn't been doing the last few CPU generations... optimizing their CPUs. So color me shocked when the one thing AMD has regularly done to try to keep up with Intel is suddenly not being done and AMD is only falling farther and farther behind. The solution to the problem according to AMD executives? Lay off more of those engineers that get paid to optimize the CPU. Yeah, that's gonna work out great both now and in the future. And everyone is wondering how AMD is going to survive with Intel beating them so badly right now. I don't want AMD to fold, they are at least some competition for Intel, but its not looking good for them both in the present as well as the future if they can't get back to doing the stuff that they know worked for them before.

But Microsoft had made their plans for the 64 bit version of XP available to AMD and Intel for quite some time before XP64 was released. AMD wanted to be first to market because their marketing team could eat that up and many people would blindly buy a new 64 bit CPU despite the fact that it did nothing for gaming or anything else until the OS was 64 bit. And I laughed at my friends that ran out to buy a new shiny 64 bit CPU and drooled on their keyboards every day while they waited for XP64. Then waited for almost 5 years before 64 bit would be widespread in desktop applications/games in any definition of the term. Because I knew that by the time 64 bit was adopted to the point that their first gen 64 bit CPU was actually ready to be used to its full potential the CPU would be so painfully slow nobody in their right mind would use it for gaming. And guess what? None of my friends ever did use it for 64 bit gaming. They all upgraded their CPU 2 or more times before they played a single 64 bit game on it. But they bought their CPUs (and the marketing hype) lock, stock, and barrel.

 

[mnemonic]

I read your comment, still I have no idea why it is a problem. I just can assume it is much work to do.

That AMD is doing just about nothing for OpenSource seems exaggerated to me, at least from an outside perspective. I often read about AMD releasing this or that regarding the 3dcards on linux. And also here you wouldn't want AMD to leave the market if you want low prices and a relevant development pace.

Thanks for the detailed info on Intel/AMD and MS. I skipped XP64, mainly because of the missing third party drivers. A lot of companies released their 64bit drivers with the release of Vista, which was not half as bad as everyone said. Linux was a lot quicker on the 64bit train.

Well, and what do I got at the end of the day? A new AMD system for the bin? I should have taken the freenas hardware recommendations more serious.

Best regards,
mnemonic

 

[Whattteva]

Why would it go to the bin just cause of lack of temp monitoring?
Unless you plan on using the box to do loads of gaming and on-the-fly transcoding, I highly doubt temperature would ever be an issue...
Majority of users' use-case is for a file server to a home LAN, which consists of 1-10 clients... hardly a taxing load for any modern processor.

 

[titan_rw]

If loading a stock clocked CPU causes it to overheat, there's something wrong with the system. A factory clocked CPU with the factory cooler should be able to handle 100% load indefinitely.

If it's overclocked, I would remove the OC before using the machine for freenas. Simply not worth it.

With that said, who cares how hot the CPU is? It wont be hot enough to be a problem. Hard drive temperature monitoring is way more important; and at least there's a standard on how to do it: S.M.A.R.T.

 

[Whattteva]

titan_rw nailed it. Factory-clocked CPU with the factory cooler is plenty enough to handle full load indefinitely unless it's overclocked and servers should never ever run overclocked anyway.

CPU vendors already have their QA test their CPU's pretty thoroughly to ensure that they don't operate outside of their TDP envelope and the shipped cooler is designed to dissipate that much heat with room to spare, provided you run it at factory settings.

CPU's in general are pretty reliable already. As titan_rw mentioned, what you should be more worried about is your hard drives. Those have a much higher rate of failure than CPU's do due to having mechanical moving parts in them. Especially, in a NAS environment where you're cramming 4+ drives that are constantly vibrating relatively close to each other.

If after all that, you still insist on tossing it to the bin just cause of lack of cpu temp monitoring... then by all means ship them to me. I'd be glad to "dispose" of them. ;)

 

[cyberjock]

From my personal experience with multiple FreeNAS servers, you will almost certainly overheat your hard drives(40C is the max recommended) before your CPU gets so hot that it causes problems. Even in a case where your CPU overheats because of a failed CPU fan, if you are purchasing recommended hardware you will probably pay the extra few dollars for IPMI. (Who wants to lug over a keyboard/mouse/monitor when FreeNAS is having problems?) That usually means that you can monitor CPU temps of the hardware itself from IPMI so that CPU monitoring is not forced to be supported in the OS.

 

[Whattteva]

Don't modern CPU's just simply throttle down these days even in the event of a failed fan? So you'd just be slow-crawling, but never going down in smokes.