Processes getting stuck waiting for disk I/O with SSD in old Core2Duo PC

I recently moved the 120 GB Mushkin Chronos SSD from my main system to replace the HD in my Core2Duo test system (Fujitsu Esprimo P7935, which only has a SATA-2 controller).

In my main system I never had any performance issues with that drive, yet in the older machine it causes software updates to spend a lot of time in “disk sleep” state, with the process waiting for disk I/O to complete while doing nothing.

This happens virtually every time I install or update a large piece of software via apt, for example.
This of course is putting a significant dent in overall performance, which at this point is so inconsistent that it’s not really that much of an improvement to the old harddisk.
Any ideas on how to solve this?

Maybe you should try something from here: http://askubuntu.com/questions/1400/how-do-i-optimize-the-os-for-ssds

I am not pro at all, but something I can think is that if you have a swap file/partition then maybe the old system uses it a lot since it probably has limited RAM. Then it could help to really reduce swappiness. Run cat /proc/sys/vm/swappiness to see the current swappiness (it would probably be 60) and then edit (as superuser) the file /etc/sysctl.conf and add at the end (or change if it’s already there) the line:

vm.swappiness = 5

Finally reboot. Some people suggest not to use swap at all with SSD (I have no idea how this can be done).

I had already reduced swappiness to 1, and swap really isn’t the issue. The problem occurs even with plenty of free RAM and no swapping at all.

I also came across this thread on the OpenSUSE forums, yet the possible solution mentioned there of disabling read-ahead did not really help.

Most SSDs are not that good in I/O opertions that occurs at the same. In other words; reading an SSD is fast; writing to an SSD is fast; reading and writing to/from an SSD is slow.
On your case, I guess that SATA 2 is not as fast to get good results from that drive or maybe the BIOS doesn’t know exactly how to handle that model. You might try to update the BIOS of that machine and see if that works out.
Are you using LUKS or anther enryption?

ps: revert the swappiness. Is not that good idea to follow those tutorials. Swappiness doesn’t work as people were told.

No encryption is used, it’s a bog-standard install that worked just fine on a harddisk, but somehow gets severely hampered on that SSD (and the SSD had no issues running off a SATA 3 controller).
I’ll check if there is any BIOS update but I somehow have a feeling that the SSD might indeed simply be much too new for that system as it’s from the SATA 3 era.

Edit: it already has the most recent available BIOS.

I switched back to the harddisk and ran a large batch of updates with the same behavior as on the SSD.
I guess I probably mis-remembered it, also it turns out I had the detailed settings of the htop cpu graphs enabled only on the SSD, making it appear to have different behavior than with the HD (the gray bar for I/O only shows in detailed mode).
Sorry for the confusion.

Notice that the data cable or the power cable (the that goes to the drive) or the power supply might be the problem. If not my bet would be the motherboard.