[Toshiba L840] Slow and sporadic hard drive write performance

[Aaron Johnson]

I have been troubleshooting an interesting bug on my Toshiba L840 laptop for a number of months now. This bug affects all versions of Ubuntu since (and including) 12.04 and other Linux distributions as well (so this is most likely an upstream bug). I have only ran the 32-bit version with PAE support because I choose application compatibility and efficient memory usage over what 64-bit Linux can provide.

WORKAROUND: 64-bit ubuntu raring (13.04).

Here is what I have experienced:

Every kernel version I have tried is affected by this bug since 3.2 in Precise (kernel 3.3 - 3.7 is affected). What happens is my hard drive write performance is greatly reduced (and over time it becomes so slow it is unusable) once I run a newer version of Linux kernel. The stock kernel of Precise does not have this bug but it has too many other bugs that cause hard lockups on ivy bridge so I cannot use it. I am happy to report that the hard lockups seem to have disappeared on 13.04 (Linux kernel 3.7) and the most stable experience I have had so far is with kernel version 3.7.0-5 on Raring 32-bit.

Even though I have found a relatively stable experience running Raring I am still haunted by this write performance issue. Once I boot I can get consistent write speeds at about 40MB/s (which is about half the speed of what my drive is able to write at) and read speed never really seems to be affected. Here is a test using dd to check write speed:

owner@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=50k; rm -f /tmp/output
51200+0 records in
51200+0 records out
419430400 bytes (419 MB) copied, 10.6863 s, 39.2 MB/s
owner@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=50k; rm -f /tmp/output
51200+0 records in
51200+0 records out
419430400 bytes (419 MB) copied, 10.4765 s, 40.0 MB/s
owner@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=50k; rm -f /tmp/output
51200+0 records in
51200+0 records out
419430400 bytes (419 MB) copied, 10.4648 s, 40.1 MB/s
owner@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=50k; rm -f /tmp/output
51200+0 records in
51200+0 records out
419430400 bytes (419 MB) copied, 11.2678 s, 37.2 MB/s

Even though 40MB/s write speed is completely unacceptable I would actually be okay with it if it didn't drop any lower than this but eventually it does.

I have experienced that over time eventually the write speed of the drive will drop to about 1-2MB/s and at that point the computer becomes unusable and has to be rebooted.

Strangely enough I have finally noticed that the significant drop from 40MB/s to 1-2MB/s seems to be triggered by certain applications, for instance when I have a torrent downloading using various torrent downloader programs, I have experienced this bug more frequently.

Even so, if I choose to not use the torrent downloading programs the bug will eventually crop back up (could be hours, could be several days...) but eventually it happens and I have to reboot.

Here are some more troubleshooting steps I have tried in a failed attempt to isolate the issue:
* I have ran memtest 86+ for over 24 hours on my laptop and it completed without error
* I have scanned my hard drive using mhdd and no bad sectors
* I have replaced my hard drive with a different size and different brand hard drive and same issue
* I have attempted a clean install of Precise and then updating to the latest packages and then install the Quantal kernel from the stable repositories and reboot. Immediately this bug affects my computer
* I have installed a clean install of 13.04 and bug still exists
* I have tried installing Ubuntu (12.04 and 13.04 32-bit) on a flash drive to see if the bug crops up eventually on the flash drive and it does. Eventually the write speed even to the USB bus will drop to 1-2MB/s !!!
* I have even tried installing other distributions as well (Fedora and Debian) and they both have the same issue.

One more thing worth noting: The very first kernel release that I tried in 13.04 was 3.7.0-2 and even now if I reboot and choose that kernel I get better write performance at first (70-80MB/s) but eventually the write speed drops down to 1-2 MB/s just like the others.

I have experienced many problems running Linux on this laptop but even so it is the fastest and best performing computer experience I have ever had. Now that the lockups are gone I feel so close to getting this computer working perfectly with Linux but I need help from someone with troubleshooting this issue further.

ProblemType: Bug
DistroRelease: Ubuntu 13.04
Package: linux-image 3.7.0.6.10
ProcVersionSignature: Ubuntu 3.7.0-5.13-generic 3.7.0-rc8
Uname: Linux 3.7.0-5-generic i686
ApportVersion: 2.7-0ubuntu2
Architecture: i386
AudioDevicesInUse:
 USER PID ACCESS COMMAND
 /dev/snd/controlC0: acjohnson 2197 F.... pulseaudio
Date: Sat Dec 15 07:13:04 2012
HibernationDevice: RESUME=UUID=9f7c92ad-121c-458f-8813-1cb8191180c2
InstallationDate: Installed on 2012-12-10 (5 days ago)
InstallationMedia: Ubuntu 13.04 "Raring Ringtail" - Alpha i386 (20121206)
MachineType: TOSHIBA Satellite L840
MarkForUpload: True
ProcEnviron:
 TERM=xterm
 PATH=(custom, no user)
 XDG_RUNTIME_DIR=<set>
 LANG=en_US.UTF-8
 SHELL=/bin/bash
ProcFB: 0 inteldrmfb
ProcKernelCmdLine: BOOT_IMAGE=/boot/vmlinuz-3.7.0-5-generic root=UUID=4836d385-16fc-47c0-8720-c369e39d0775 ro quiet splash i915.i915_enable_rc6=7 vt.handoff=7
RelatedPackageVersions:
 linux-restricted-modules-3.7.0-5-generic N/A
 linux-backports-modules-3.7.0-5-generic N/A
 linux-firmware 1.98
SourcePackage: linux
UpgradeStatus: No upgrade log present (probably fresh install)
dmi.bios.date: 06/26/2012
dmi.bios.vendor: Insyde Corp.
dmi.bios.version: 1.80
dmi.board.asset.tag: Type2 - Board Asset Tag
dmi.board.name: Type2 - Board Product Name1
dmi.board.vendor: Type2 - Board Vendor Name1
dmi.board.version: Type2 - Board Version
dmi.chassis.asset.tag: No Asset Tag
dmi.chassis.type: 10
dmi.chassis.vendor: OEM Chassis Manufacturer
dmi.chassis.version: OEM Chassis Version
dmi.modalias: dmi:bvnInsydeCorp.:bvr1.80:bd06/26/2012:svnTOSHIBA:pnSatelliteL840:pvrPSK8GU-08S00D:rvnType2-BoardVendorName1:rnType2-BoardProductName1:rvrType2-BoardVersion:cvnOEMChassisManufacturer:ct10:cvrOEMChassisVersion:
dmi.product.name: Satellite L840
dmi.product.version: PSK8GU-08S00D
dmi.sys.vendor: TOSHIBA

[Brad Figg (brad-figg)]

This change was made by a bot.

[Joseph Salisbury (jsalisbury)]

Would it be possible for you to test the latest upstream kernel? Refer to https://wiki.ubuntu.com/KernelMainlineBuilds . Please test the latest v3.7 kernel[0] (Not a kernel in the daily directory) and install both the linux-image and linux-image-extra .deb packages.

If this bug is fixed in the mainline kernel, please add the following tag 'kernel-fixed-upstream'.

If the mainline kernel does not fix this bug, please add the tag: 'kernel-bug-exists-upstream'.

If you are unable to test the mainline kernel, for example it will not boot, please add the tag: 'kernel-unable-to-test-upstream'.
Once testing of the upstream kernel is complete, please mark this bug as "Confirmed".

Thanks in advance.

[0] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/

[Aaron Johnson (acjohnson)]

Okay, I went ahead and installed the mainline kernel from the following location:
http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.7-raring/

I rebooted and now I am running the following kernel version:
acjohnson@Satellite-L840:~$ uname -a
Linux Satellite-L840 3.7.0-030700-generic #201212102335 SMP Tue Dec 11 04:47:31 UTC 2012 i686 i686 i686 GNU/Linux

I would say the bug still exists upstream:

acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 4.41778 s, 19.0 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 3.32685 s, 25.2 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 2.52144 s, 33.3 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 3.13614 s, 26.7 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 3.06433 s, 27.4 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 2.42921 s, 34.5 MB/s
acjohnson@Satellite-L840:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 2.74525 s, 30.6 MB/s
q

[Joseph Salisbury (jsalisbury)]

This issue appears to be an upstream bug, since you tested the latest upstream kernel. Would it be possible for you to open an upstream bug report[0]? That will allow the upstream Developers to examine the issue, and may provide a quicker resolution to the bug.

Please follow the instructions on the wiki page[0]. The first step is to email the appropriate mailing list. If no response is received, then a bug may be opened on bugzilla.kernel.org.

[0] https://wiki.ubuntu.com/Bugs/Upstream/kernel

[Aaron Johnson (acjohnson)]

Thank you. Upstream bug has now been posted:
https://bugzilla.kernel.org/show_bug.cgi?id=51771

[Aaron Johnson (acjohnson)]

Update-

So I never really got to the bottom of why this is happening on the 32-bit pae
3.7 kernel... I decided to install 64-bit ubuntu raring (13.04), and guess
what, it works flawlessly.

So apparently 32-bit kernels on new hardware is a bad idea, which I should have
known I suppose, but it's too bad because there are a few third party
applications that I am having a hard time with now because they don't properly
support 64-bit linux.

I am happy to report that ubuntu raring 64-bit runs exceptionally good on my
Toshiba L840 right out of the box, even with the stock kernel. No hard drive
performance issues, and no suspend lock-ups either ;)

[Aaron Johnson (acjohnson)]

Look at my speed tests now :

acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0583449 s, 1.4 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.056132 s, 1.5 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0531594 s, 1.6 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0499333 s, 1.7 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0529071 s, 1.6 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0537926 s, 1.6 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.055174 s, 1.5 GB/s
acjohnson@UbuntuRaringx64:~$ dd if=/dev/zero of=/tmp/output bs=8k count=10k; rm -f /tmp/output
10240+0 records in
10240+0 records out
83886080 bytes (84 MB) copied, 0.0580251 s, 1.4 GB/s

:)

[penalvch (penalvch)]

Aaron Johnson, could you please provide the full computer model as noted on the sticker?

[Aaron Johnson (acjohnson)]

Hello Christopher-

This laptop was ordered custom from Toshiba Direct so I beleive Satellite L840 is the entire model number. I am looking at the sticker right now and this is all I see...

btw, Ubuntu 13.04 and 13.10 64-bit work flawlessly on this laptop. I was never able to get the pae kernel to function properly...

[penalvch (penalvch)]

Aaron Johnson, is there anything stopping you from using the amd64 release going forward?

[Aaron Johnson (acjohnson)]

Christopher- I have been using the 64-bit version of Ubuntu 13.10 since its release and have had no issues whatsoever with this release as far as system stability and reliability is concerned. It seems that with mature Intel hardware support in the more recent kernel release and sticking with AMD64 arch I have an incredibly stable system and even power management features such as suspend and hibernate work flawlessly.

Thanks for the follow-up :)