SATA II causes system freeze

Bill Davidsen davidsen at
Thu Nov 13 23:12:36 UTC 2014

Bill Davidsen wrote:
> David A. De Graaf wrote:
>> On Fri, Oct 03, 2014 at 02:19:55PM -0400, David A. De Graaf wrote:
>>> On Fri, Oct 03, 2014 at 04:01:30AM +0930, Tim wrote:
>>>> Allegedly, on or about 02 October 2014, Chris Murphy sent:
>>>>> Cables are often the source of weird problems. Specifically it's the
>>>>> connectors that are flakey, not the cable portion itself.
>>>> Though, if you savagely bend SATA leads, the way some of them are
>>>> supplied in a flattened up zig-zag style, with a rubber band around
>>>> them, you can mess up the data transmission.
>>> Some quick feedback:  It's now apparent that the cables or SATA
>>> sockets have nothing to do with my problem.  The finger of guilt
>>> now seems to point to the RAM sticks.  However, experiments are
>>> slow.  More later.
>> After weeks of experimentation it's clear that my machine crashes have
>> nothing to do with the SATA connections or the harddrives.
>> They are caused by a too-small swap space!
>> Zero is OK; large is OK; but small is NG.
>> For reasons I can't recall, the system is set up with only a 2 GB swap
>> partition, and for a long while it had a single 4 GB RAM memory stick.
>> This was OK.
>> Then I added a second 4 GB memory stick, identical to the first.
>> With 8 GB RAM and 2 GB swap the system crashed - froze - after a
>> random few hours.
>> This was maddening.  Not knowing the real cause, I bought a different
>> motherboard, changed power supply, tried different SATA and ATA
>> harddrive
>> connections, changed the SATA cable, removed the extra data drive,
>> removed the ATA CD drive, used one or the other RAM stick,
>> disconnected
>> everything and ran with only a Live F20 Xfce USB stick.  I ran
>> memtest86
>> for days without error.  The only thing that worked was to revert to
>> only a single memory stick - 4 GB.  Either stick was OK.
>> I put everything back together, using an ATA/SATA converter for the
>> 350 GB primary disk, the SATA 1TB data harddrive, and the ATA CD.
>> Then I noticed the size of the swap partition was 2 GB and, having
>> nothing else to try, added an 8 GB swap file.
>> Eureka!  It ran.
>> I have a matrix of test cases which I won't bore you with.
>> They can be summarized as follows:
>> 1 - with 4 GB RAM, either 0 or 2 GB swap space is OK.
>> 2 - with 8 GB RAM, 0 swap space is OK.
>> 3 - with 8 GB RAM, 2 GB swap space will reliably freeze the system
>> 4 - with 8 GB RAM, 4 GB swap file is OK.
>> 5 - with 8 GB RAM, 2 GB swap partition + 8 GB swap file is OK,
>>        even if the priority of the smaller one is forced higher.
>> At no time during these experiments was swap space actually used
>> according to the gkrellm display;  the RAM usage remained well
>> below what was available.
>> This is clearly a bug.  No rational design would work like this.
>> Is it a kernel bug?  Some other component?
>> Which one gets the Bugzilla?
> It's probably too late to check now, but did you try taking the 2GB swap offline
> and running mkswap on it to check for a glitch somewhere? Yes, I know that's
> nominally a "can't happen" thing, but having had success with that, I mention
> it. My sample size (one) is pretty small.
And to reply to my own suggestion, my notes on that also say you may want to 
change to deadline scheduler on the swap device.

Bill Davidsen <davidsen at>
   "We have more to fear from the bungling of the incompetent than from
the machinations of the wicked."  - from Slashdot

More information about the users mailing list