New irst for download on Intel site, not sure if that will update the smart data or not. Both of mine do this as well, but I don't really see it s much of a problem. If all the drives are doing it and it seems that may be the case for the 520 then I would think an update along the way will address this.
I can confirm mine does the same ( SMART codes :unexpected power loss AE & Unsafe shutdown count CO), although wouldnt have noticed this unless I saw your post. 520, 120GB, SATA 2.
Everything seems to working fine, in fact exceeded expectations, from an HDD to an Intel SSD
Be nice to know why this is occuring though.
Yes, my 520 does this too. The only concern I would have is if this field was used as a warranty voiding criteria, but I highly doubt that would happen, and is not mentioned in the warranty information. It is a rather silly bug, but as a programmer, I can tell you that many times the "little stuff" gets ignored.
We should file support tickets or however Intel does that, just to make them aware that we are aware of this.
Do you have a concern about this that I am missing?
I can confirm this (bug?) too. , but it happens only in Windows (in GNU/Linux it works correctly).
I'm almost sure that it happens also after booting/turning off GNU/Linux.
Message was edited by: wsirko
Very interesting, thank for the info. What are you using to check SMART values in GNU/Linux?
I'm using smartmontools: smartctl -A /dev/sdb, but there's also an app with gui called gsmartcontrol.
wsirko, Great, thanks. I also used smartmontools (on Windows 7), specifically smartctl, and the values it returned matched those shown in the Toolbox. This indicates (well, only two examples) that the Toolbox and smartctl, on the two different OSs, are reading (interpreting ?) the SMART data in the same way, so hopefully we can trust those results in trying to determine (in general) why these seemingly odd shutdown counts are happening.
All this info is important IMO, since it seems to show that it occurs with Windows 7, but not on Linux.
wsirko, just to review and be clear, you're saying that the Unsafe Shutdown and Unexpected Power Loss attributes on your 520's SMART data, are NOT incremented after a normal OS shutdown and reboot on Linux, correct?
Heh, this is strange. When I initially tested this I was sure that those counters where incremented only after booting/turning off Windows, but not GNU/Linux (did a couple of reboots). But I noticed today that the counters increased by 1 since yesterday and the only OS I booted/turned off was a GNU/Linux distribution.
So the answer is: No, I can't confirm - I think it happens also in GNU/Linux...
That's Ok, much better for us to know what's actually happening than not. Thanks for posting that. Feel free to update that info if something changes, or you discover what happened, etc.
I've got one more interesting bit to add to this. When I first installed my new 520, I let it run for a few days, and just fooled around with it to check if it was fine. Before installing Win 7 on it, I deleted it's volume and Secure Erased it in the Toolbox. During the SE, a message appeared that the 520 was Security Locked, and needed to be power cycled before the SE could be done. That is normal and happened when I SE my 510 SSD, so I was prepared by having the side of the PC case off. I removed the SATA power plug from the 520, and put it back and clicked to continue. The SE completed fine, no need to reboot, etc. I then shutdown the PC and set up the PC and the 520 to install Win 7. The installation went fine, not a single glitch, and the 520 became an OS drive.
Later, I checked the 520's SMART data in the Toolbox. I noticed that the Power Cycle Count was now one greater than the Unexpected Power Loss and Unsafe Shutdown counts! You might think that power cycling the 520 like that would count as an Unexpected Power Loss or Unsafe Shutdown, but who knows what actually happens.
I read in the 520 spec document that Unexpected Power Loss and Unsafe Shutdown counts are incremented whenever the 520 loses power without the last command it receives being the SATA Standby Immediate command. So does that imply that the Toolbox sends the SI command to the 520 during the SE process, but when the PC is shutdown, Windows, IRST (the driver I use), or whatever is not sending the SI command to the 520?
Speculation is worthless since I really have no idea what is happening during any of these processes, but I think it's interesting.
Parsec, I did much the same when I got my two 520's. Played with them before installing OS. I did one secure erase on both to setup install.
My counts are off by 1 also, like it did not count the SE. Werid.
Thanks DRules, nice to confirm what I saw with my 520. I'm not worried about it
IMO, the question remains, do we really understand what this data means and how it is created? Does the SF2281 controller's base firmware create this data (most likely) and do the users of the controllers (SSD manufactures) have control of that data?
I find myself once again at what I call the knowledge climb. I've reached the limit of my knowledge and before me is a mountain of learning that I need to conquer before I can get the answers. Most of the time, the answers are not as important as what I learn finding the answers.