"D. Hugh Redelmeier" <hugh@xxxxxxxxxx> writes: > Could you dd an equivallent volume from /dev/zero to see if it also > causes a problem? That eliminates one more variable from the problem. I'll try. I have only seen it happen with a dvd as source. Disk to disk copies such as "cp -ax / /mnt/backup" didn't seem to cause problems. > Why do you call it "streaming conditions"? Do you think that the fact > that the DVD delivers bytes more slowly than the hard drive would accept > them is important? I had assumed that the bug required a high sustained data rate that would dump a large number of consecutive blocks into the disk's on-disk cache, but was still slow enough to allow the on-disk cache to drain. But then again, it was just a stab at explaining why it only seemed to happen when reading from dvd. > Or is there some other aspect that you think is relevant? Hard to say. I'd only really had 3 or 4 lockups and each time it was the morning after I'd added a new video. > NCQ has been around long enough that I'd expect/hope that the nits > have been picked. Of course I could be wrong. Well, I've seen the bug described as a on-disk cache flushing bug and/or NCQ bug. In any case, Seagate support got me some SD3B firmware to load onto the disk. Strangely my disk now identifies itself as ST31500341AS instead of ST31500343AS (with a "1" instead of a "3"). That also explains why I couldn't find other folks with bug reports -- only a few drives went out with the trailing "3" model number. Lets see how the drive holds up. I'm beating on it right now. -wolfgang -- Wolfgang S. Rupprecht http://www.full-steam.org/ (ipv6-only) You may need to config 6to4 to see the above pages. -- fedora-list mailing list fedora-list@xxxxxxxxxx To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list Guidelines: http://fedoraproject.org/wiki/Communicate/MailingListGuidelines
