SATA II causes system freeze

Bill Davidsen davidsen at
Thu Nov 13 23:07:02 UTC 2014

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.

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