10-11-2012 02:12 AM
I just received my t430s with the intel ssd drive, and already I have a serious problem with the drive. Luckily I can reproduce it, although it's not a very orthodox testing procedure.
I am using the t430s as a development machine, running Debian 7 with kernel 3.5 on it, and ext4 filesystem. The problem happens in a very particular instance, with Solr (a Lucene-based index engine). When indexing a large number of documents (many writes to the disk), the indexer gets slower and slower (after about 2 minutes) until the kernel eventually reports an I/O error and the drive is no longer accessible. After this, a power cycle is required.
I have added a second drive to the system, an OCZ Vertex 2 120GB, and moved the Solr index to that drive. The drive has been formatted and mounted exactly the same as the Intel. Running the indexer with the same documents on this new drive works without a glitch, it doesn't even ever slow down.
I made sure that the intel drive's firmware is up-to-date, and I've tested the drive with intel's ssd testing suite in windows.
I've lost a lot of time with this issue and I will most likely replace the drive with a Samsung 830-series or anything else that has a 7mm height and doesn't use the SF-2281 controller. I just wanted to report on here in case others might be running into similar issues in Linux. I suppose in Windows, something like this would just cause a BSOD, and there are plenty of BSOD threads on the Internet relating to the SF-2281 controller.
10-25-2012 10:34 AM - edited 10-25-2012 10:40 AM
I too have the exact same issue as madi described. I've installed Debian Wheezy on a brand new ThinkPad T430s (N1RGCMZ) and my usual tools for work as a web developer (LAMP, Solr, node.js, etc.). I have to precise that Solr is installed but the bug also occures when the process is not running.
We're also both from Switzerland, maybe we even buy the computer from the same seller ? (brack.ch) This might give us some direction.. ^^
After launching a PHP CLI script that import thousands of database records into my local database (so there's probably a lot of disk writes), the computer begins to slow down, until the kernel output a "journal commit I/O error" and lock the filesystem as "read only". When this occurs, Gnome becomes (obviously) unuseable and almost no command can be used (I've had various error depending on the command I tried, like "Bus error", "ACPI: Unable to dock", "Unable to create a temp file", etc... all related, of course, to the readonly filesystem status). The only way out at this point is a hard-reboot.
The SSD disk looks perfectly fine (as a brand new one, we can hope so), according to the BIOS disk report and SMART tests, so the usual suspiscion that it might be broken is improbable.
I've therefore submitted a bug on the Debian kernel tracker. I've been able to reproduce the bug on the kernels 3.2.0-4 (3.2.23-1), 3.2.0-5 (3.2.32-1) and 3.5-trunk (3.5.5-1~experimental.1). The setup is an ext4 on / and /home on LVM.
I hope Lenovo's team will take a look at this bug soon, as it is a serious drawback for my everyday work and seems to happen to other people as well.
@jpou : it seems that both madi and I have the bug when creating a lot of write usage on the disk when Apache is involved. Maybe you can try to write a simple script that insert X thousands of records into a MySQL database and increase the number until this bug happens ? I unfortunately can't give you the CLI script I'm using, as it has been developed for a client (and has a lot of dependecies on frameworks etc). But don't hesitate to ask for help to write such a test script if you need some !
Thanks to anybody that will read all this and help us.
10-25-2012 11:43 AM
Just a quick update:
I'm glad I'm not the only one experiencing this issue!
Sorry for not posting a way to reproduce the problem, as I thought it would be pretty tough to do, but I guess now that someone else has experienced it, without Solr, it should be easier.
I have replaced my Intel HDD with a Samsung 830-series 256GB drive and the problems went away. In fact, it's running even faster than before. I'm using the original Intel SSD as a second drive in the ultrabay now, in place of the cd-rom drive, to store non-i/o-intensive stuff.
Although I am in Switzerland, my laptop is not from Brack, it's from ETH Projekt Neptun.
As for a solution - I would simply recommend shelling out ~190CHF for a Samsung 830 256GB drive (check toppreise.ch). You can clone the intel drive with dd, or whatever other tool you fancy. It's simply not worth the headaches in my opinion to try and get the intel to not crash, considering we don't really know what kind of mess it leaves behind during the crashes. At least I've done the tests on the Samsung and I can confirm that it works.
The reason for going with the Samsung is to avoid the sanforce sf-2281 controller, which I'm guessing is at the root of this problem.
a quick speed test (hdparm -t) on the 2 drives:
Samsung: Timing buffered disk reads: 1482 MB in 3.00 seconds = 493.35 MB/sec
Intel: Timing buffered disk reads: 1164 MB in 3.00 seconds = 387.59 MB/sec
Not that it means too much, but at least it's easier to justify buying this new drive.
10-31-2012 02:26 AM
After having the same bugs happening on other not-so-intense-writing-operation, I've decided to follow madi's lead and buy a new Samsung 830 256 Gb SSD. I just couldn't afford a broken computer any longer, and fortunately It solved the problem.
However, it's sad that it seems to be, for the moment, the only way out.
Thanks anyway for your advice !
10-31-2012 10:13 PM - edited 11-01-2012 05:13 AM
I think power management (which I enabled after running powertop) for AHCI was the culprit here.
Not doing really hardware intense tasks here (except from some DB testing from time to time) and setting read-only after errors happend here quite soon after login. I was able to "solve" this problem by simply not doing any of the smart power management setup (both in kernel and userspace/r.local) that was recommended by powertop.
I'm on Debian/unstable using self build kernels (3.6.* atm), so maybe updating's also worth a try.
11-04-2012 11:46 PM
I'm quite unsure about the power managment thing, as I've configured nothing about it (having a fresh Debian install).
I've started compiling the 3.6 kernel and stopped to get the 3.5 package available... maybe I shouldn't have. If anybody experience this bug again, try compiling the last kernel version, maybe it'll work well.
11-22-2012 08:03 AM
I have a very similar problem, and this seems to be the only thread about it...
Yesterday my Thinkpad t430s arrived and after a fresh Ubuntu install (the certified version), the following problem appeared: after 10-15 minutes of not-very-intensive use, apps started to freeze and "I/O errors dev sda, sector XXXXX" appeared until the filesystem became readonly and subsequently the machine was totally frozen.
I tried also with 12.10 and obtained the same behavior. Ubuntu cannot run for longer than 30 mins in a row... :-(
I did several fcsks and everything seems to be fine...
The problem seems to happen in Linux only, as I am currently using Windows for more than one hour and I had no problem until now... This is a serious issue, since I'm afraid that no refunding can be done if the problem is not reproducible under Windows... Any ideas?
seller : Bluelink.nl.Item No: N1RLNMH / Machine type/model: 2356LNG
ThinkPad T430s Intel Core i7-3520M-2C-2.9GHz 4GB 240GB
SSD FDE 14inch(1600x900 Intel HD Graphics)
DVD-Rec WiFi Bluetooth WWAN 3G Fingerprint 4-in-1 Cardreader 6-cell Cam
Backlit Keyboard Windows 7 Pro 64 (incl Windows 8 Pro)