Hi, On Mon, 26.01.2009 at 17:08:51 +0000, Dieter <open...@sopwith.solgatos.com> wrote: > It is easy to set up a slashdot account. Or you can post as "anonymous > coward".
yes, but I don't want to set up a /. account right now, and posting as AC wouldn't likely solve the problem. > that he has another slashdot account that isn't anonymous. Problem I > have is I can't find a way to send him a PM (private message). Most web This is exactly the point. > forums have a facility for sending other users a PM. We can post a reply > to the thread, but he would have to read the thread again to see it. > Any slashdot wizards out there have an idea? Post to the thread and offer one's own email address (maybe time-limited or so), and hope for the best... not exactly a silver bullet, but maybe better than nothing. > It isn't even just FLOSS. Any non-x86 machine is out of luck. > Proprietary Unix is out of luck. Anything embedded is out of luck. > Even Mac is probably out of luck. And if the reboot to run the > firmware installer bricks the drive(s) even wintel is out of luck. Yes, and smartmontools claims to run on all platforms you mentioned (except MAC OS 9). Ie, they even run on Windows and/or together with Cygwin. Therefore, I think that this is a strategic point from where the problem could be solved for a really broad range of systems, and in one go. > I don't understand the common corporate policy of keeping everything > secret. All they are doing is hurting their previously loyal customers. > It didn't used to be this way. Oh... over here, we have a saying: "Sea gate, oder sie geht net." (meaning: "it works, or it doesn't" - it's a pun on the pronounciation of "Seagate"). Yes, many people, me included, thought they had reformed... > Supposedly there was a broken test machine that didn't zero out some > special area after writing a test pattern. So only drives that were > tested on that machine are at risk. I'd like to not speculate about the cause of the problem any longer, but instead devise a plan to acquire the required knowledge to beef up smartmontools to solve the problem. I could only believe such claims about the causes, but presently, Seagate destroyed about as much trust as they possibly could, at least with me. So, except for the hard-core technical data, they're out of the loop as far as I'm concerned. > If we can find out what area > this is (I assume it isn't in the normal space used for user storage) > and how to zero it (if not already zero) there is no need to update > the firmware. I'd rather say that the (ring) buffer has some external counter, also stored somewhere, which needs to be adjusted. I'd not bet that simply zeroing the area(s) will do. > Good question. Seagate has some web page that supposedly will tell you, > but of course it is broken and doesn't work with all browsers. At some time, they had a page where you could enter your model and serial number, but reportedly this page delivered a lot of false positives and false negatives. After deciding that the results were far too unreliable, the page was pulled. > Toni reports that ES and ES.2 may be affected. This I took from a Seagate web page. Stuart Henderson has posted the link, and I had the same link in my email which I received from Seagate, so, I'd say, the link is "genuine" (despite the contents of the page being almost worthless, imho). > From what I've read it sounds like the counter must be exactly 320 AND some > location must have a test pattern rather than zero when you init (power up > or reboot) the drive. From Maxtorman's description, the log is circular, > so it will eventually wrap around to 320 again. My dealer, who claimed that he also had information directly from Seagate, told me that the buffer was 256 entries long (makes a lot of sense, imho), but nevermind. "We" need hard facts, preferably in the form of photocopies of internal design papers or so, not speculations. > So keeping the counter away from 320 is an okay short term workaround, This would require to periodically check the log position and eg. reset it to zero at shutdown, to be on the safe side. > but long term we want to either zero out the magic location or update the > firmware. We want to have updated firmware and the ability to update firmware for "all" drives, also from other manufacturers. Updating firmware for a drive shouldn't be any more complicated or risky than updating the BIOS on the motherboard. > There is supposed to be some document that explains all this, > with enough details to create a fix. If anyone finds this > document I need a copy please. Me too! > If you have one or more of the suspect drives, if it running, > try to keep it running and don't reboot. If it is powered down > leave it powered down if possible until this all gets sorted out. Yes... but that still doesn't help you in the face of a system's crash. What to do then? No need to answer this one... -- Kind regards, --Toni++
