Slackware64 + OCZ Petrol 128GB problems

mysql_connect · 06-06-2012, 02:30 AM

Hello,

Setup:

- HP Probook 4530s, Intel i5 2430M, 8GB ram, latest BIOS update from HP
- OCZ Petrol 128GB, firmware 3.15 (latest)
- Slackware64 13.37 / Kernel 3.2.13 SMP updated from slackware-current
- sata controller:

Code:

bash-4.2# lspci -vvnn | grep -i sata
00:1f.2 SATA controller [0106]: Intel Corporation 6 Series Chipset Family 6 port SATA AHCI Controller [8086:1c03] (rev 04) (prog-if 01 [AHCI 1.0])
        Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004

- cheap 2nd HDD drive caddy bought from ebay, it replaces the optical disk offering you a 2nd hdd bay
- fstab entry (I know it's not optimized or anything, but I need it to work frst):

Code:

/dev/sdb1        /mnt/tmp         ext4        defaults         0   1

Problem:

The SSD appears to fail randomly but after a short period of time.

dmesg says:

Code:

bash-4.2# dmesg | grep sdb
[    5.802539] sd 1:0:0:0: [sdb] 250069680 512-byte logical blocks: (128 GB/119 GiB)
[    5.811790] sd 1:0:0:0: [sdb] Write Protect is off
[    5.820821] sd 1:0:0:0: [sdb] Mode Sense: 00 3a 00 00
[    5.820835] sd 1:0:0:0: [sdb] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[    5.830309]  sdb: sdb1 sdb2
[    5.839558] sd 1:0:0:0: [sdb] Attached SCSI disk
[   21.649850] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[   98.908073] EXT4-fs (sdb1): re-mounted. Opts: commit=0
[  514.269809] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
[  788.011675] sd 1:0:0:0: [sdb] Unhandled error code
[  788.011679] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
[  788.011687] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 02 54 29 80 00 00 20 00
[  788.011705] end_request: I/O error, dev sdb, sector 39070080
[  788.011715] Buffer I/O error on device sdb2, logical block 0
[  788.011735] Buffer I/O error on device sdb2, logical block 1
[  788.011740] Buffer I/O error on device sdb2, logical block 2
[  788.011745] Buffer I/O error on device sdb2, logical block 3
[ 1707.381442] sd 1:0:0:0: [sdb] Unhandled error code
[ 1707.381452] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
[ 1707.381460] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 01 04 06 5f 00 00 30 00
[ 1707.381479] end_request: I/O error, dev sdb, sector 17040991
[ 1707.381566] Aborting journal on device sdb1-8.
[ 1707.381626] sd 1:0:0:0: [sdb] Unhandled error code
[ 1707.381631] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
[ 1707.381639] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 01 04 00 3f 00 00 08 00
[ 1707.381656] end_request: I/O error, dev sdb, sector 17039423
[ 1707.381664] Buffer I/O error on device sdb1, logical block 2129920
[ 1707.381669] lost page write due to I/O error on sdb1
[ 1707.381686] JBD2: I/O error detected when updating journal superblock for sdb1-8.
[ 1713.502972] sd 1:0:0:0: [sdb] Unhandled error code
[ 1713.502981] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
[ 1713.502989] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 00 00 00 3f 00 00 08 00
[ 1713.503007] end_request: I/O error, dev sdb, sector 63
[ 1713.503015] Buffer I/O error on device sdb1, logical block 0
[ 1713.503019] lost page write due to I/O error on sdb1
[ 1713.503036] EXT4-fs error (device sdb1): ext4_journal_start_sb:327: Detected aborted journal
[ 1713.503044] EXT4-fs (sdb1): Remounting filesystem read-only
[ 1713.503065] EXT4-fs (sdb1): previous I/O error to superblock detected
[ 1713.503093] sd 1:0:0:0: [sdb] Unhandled error code
[ 1713.503099] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
[ 1713.503108] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 00 00 00 3f 00 00 08 00
[ 1713.503135] end_request: I/O error, dev sdb, sector 63
[ 1713.503142] Buffer I/O error on device sdb1, logical block 0
[ 1713.503148] lost page write due to I/O error on sdb1

/var/log/messages says:

Code:

Jun  6 08:50:12 darkstar kernel: [  514.269809] EXT4-fs (sdb1): mounted filesystem with ordered data mode. Opts: (null)
Jun  6 08:53:46 darkstar kernel: [  727.923611] ata2: hard resetting link
Jun  6 08:53:56 darkstar kernel: [  737.954145] ata2: hard resetting link
Jun  6 08:54:06 darkstar kernel: [  747.985221] ata2: hard resetting link
Jun  6 08:54:41 darkstar kernel: [  782.971167] ata2: hard resetting link
Jun  6 08:54:46 darkstar kernel: [  788.011634] ata2: EH complete
Jun  6 08:54:46 darkstar kernel: [  788.011675] sd 1:0:0:0: [sdb] Unhandled error code
Jun  6 08:54:46 darkstar kernel: [  788.011679] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
Jun  6 08:54:46 darkstar kernel: [  788.011687] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x28: 28 00 02 54 29 80 00 00 20 00
Jun  6 09:10:07 darkstar kernel: [ 1707.381442] sd 1:0:0:0: [sdb] Unhandled error code
Jun  6 09:10:07 darkstar kernel: [ 1707.381452] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
Jun  6 09:10:07 darkstar kernel: [ 1707.381460] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 01 04 06 5f 00 00 30 00
Jun  6 09:10:07 darkstar kernel: [ 1707.381626] sd 1:0:0:0: [sdb] Unhandled error code
Jun  6 09:10:07 darkstar kernel: [ 1707.381631] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
Jun  6 09:10:07 darkstar kernel: [ 1707.381639] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 01 04 00 3f 00 00 08 00
Jun  6 09:10:13 darkstar kernel: [ 1713.502972] sd 1:0:0:0: [sdb] Unhandled error code
Jun  6 09:10:13 darkstar kernel: [ 1713.502981] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
Jun  6 09:10:13 darkstar kernel: [ 1713.502989] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 00 00 00 3f 00 00 08 00
Jun  6 09:10:13 darkstar kernel: [ 1713.503093] sd 1:0:0:0: [sdb] Unhandled error code
Jun  6 09:10:13 darkstar kernel: [ 1713.503099] sd 1:0:0:0: [sdb]  Result: hostbyte=0x04 driverbyte=0x00
Jun  6 09:10:13 darkstar kernel: [ 1713.503108] sd 1:0:0:0: [sdb] CDB: cdb[0]=0x2a: 2a 00 00 00 00 3f 00 00 08 00

1st attempt

Partitioned with cfdisk, no problems.
Formatted ext4, no problems.
Copied the contents of the root partition to it (aprox 15GB), no problems.
Chrooted into it and started "mc", fail.

2nd attempt

Reboot for 1st attempt, unplug & plug the caddy again.
Chrooted, no problems.
Opened "mc", edited lilo.con, no problems.
Ran "lilo", fail.

3rd attempt

Reboot for 2nd attempt, unplug & plug the caddy again.
Created and deleted files and folders on the mounted ssd, failed after several minutes.

The above are from today's fiddling with it, what else I did:
- plugged the SSD into my windows machine, all fine
- bought a 2nd caddy from a different vendor, same errors
- tried to boot directly from it, same errors
- upgraded laptop BIOS, same errors
- updated SSD firmware, same errors
- plugged a spare laptop hdd into the caddy , all fine

Now I'm really frustrated as I spent counteless hours and roughly 150 euros on drive and caddys trying to improve my work laptop and now I'm facing the daunting prospect of plugging it into the windows machine

.

ponce · 06-06-2012, 02:42 AM

You can't use a -current kernel package on stable, you have to rebuild it.

Have you considered also the possibility that the caddies aren't working?
Maybe you can try installing the ssd in place of the original hard drive in your notebook.

mysql_connect · 06-06-2012, 02:58 AM

Quote:

Originally Posted by ponce

You can't use a -current kernel package on stable, you have to rebuild it.

Have you considered also the possibility that the caddies aren't working?
Maybe you can try installing the ssd in place of the original hard drive in your notebook.

I updated everything to slackware-current a while back and was only pointing out that it's not a kernel I built myself.
The caddies ARE working as I said in my original post: "- plugged a spare laptop hdd into the caddy , all fine" .

ponce · 06-06-2012, 04:49 AM

sorry about the stable/current misunderstanding, I seem to have read another thing.

you can test it if the bay works with that OCZ drive (it can be also that it works with the other spare one you tested and not with the OCZ SSD) booting from a livecd, the latest ubuntu one, for example.

do your tests from the live distro, and if the problem persists, maybe you can eliminate the operating system as the cause of fault and conclude that the bays you are trying to use in your laptop cannot work with that SSD.

onebuck · 06-06-2012, 07:51 AM

Hi,

I believe you are looking at the setup procedure wrong for initial SSD setup. Not optimize but configure the system to function properly initially for the 'SSD'.

Look at: So you want to be a Slacker! What do I do next?: Slackware & SSD Post #259

You will find useful information to help setup the SSD and system. Several external links within for additional reference information.

Some additional links;

Quote:

SSD + HDD: an OPTIMAL partitioning scheme

13.37 Boot fails if a particular SATA drive is in system

SSD' are getting cheaper therefore selected for use. But wisely??

SSD vs. HDD

Linux O.S. on SSD?

Best filesystem for SSD?

new ssd questions.

SSD - is it worth it?

Copy of my '/etc/fstab/';

Quote:

# cat /etc/fstab
/dev/sda3 swap swap defaults 0 0
/dev/sda5 / ext4 defaults,noatime,discard 0 1
/dev/sda6 /home ext4 defaults,noatime,discard 0 1
/dev/sda7 /usr ext4 defaults,noatime,discard 0 1
/dev/sda8 /var ext4 defaults,noatime,discard 0 1
/dev/sda9 /tmp ext4 defaults,noatime,discard 0 1
/dev/sda2 /mnt/win7 ntfs-3g defaults,noatime,fmask=111,dmask=000 1 0
#/dev/cdrom /mnt/cdrom auto noauto,owner,ro 0 0
/dev/fd0 /mnt/floppy auto noauto,owner 0 0
devpts /dev/pts devpts gid=5,mode=620 0 0
proc /proc proc defaults 0 0
tmpfs /dev/shm tmpfs defaults 0 0

Scheduler in use for SSD;

Code:

# cat /sys/block/sda/queue/scheduler
[noop] deadline cfq

Be sure to read post #26 within 'Slackware on an SSD'. That post should help you. One thing, you should setup the scheduler for the 'SSD' devices in your system and be sure to leave the other HDD scheduler as [cfq]. Some say to use 'deadline' for SSD scheduler but the noop is a FIFO an will service the SSD better since there are no latency for a spinning platter or moving heads within a SSD.
HTH!

hf2046 · 06-06-2012, 08:23 AM

You should also consider downgrading your SSD firmware or your BIOS. Sometimes the latest OCZ firmware introduces new problems when trying to solve other ones. The system manufacturers are also trying to solve the same problems. All of this results in some combinations of firmware / BIOS not playing nicely together. I know this firsthand from my experience with getting the OCZ Vertex 3 and the Dell Precision M4600 stable for daily use.

mysql_connect · 06-06-2012, 12:20 PM

Follow-up

Did as ponce suggested and boot with live Ubuntu.
Everything was fine, ran some test copying and mounts/umounts, no errors. So I took it one step further and I installed Ubuntu 12.04 amd64 on it, with ALL the updates and drivers and still no error. At this point I thought it was a slack issue, but after the restart required by updates it failed to start Ubuntu from SSD.
So I have narrowed it down to this:
- cold boot, starts with Ubuntu, works (tested for about 2 hours), Slackware sees and mounts it, copying works but after "chroot" it fails;
- after a restart, Ubuntu doesn't start, Slackware tries to access it with sata 3.0, sata 1.5 and gives up;
- if I remove the laptop's AC power and battery and leave it like that for 1-2 minutes, when I start again it works until the next restart.

So my guess is that it doesn't like to be re-initialized and Slackware64 somehow (power management maybe?) does that and it fails.
So any thoughts on what to do from here? Are there any magic rituals that I can perform or I take it to OCZ support and return the drive?

ponce · 06-06-2012, 12:28 PM

you can still try plugging it in your windows machine, start it with ubuntu/slack and see if there works.

in that case the problem could be related with the laptop's sata controller/bay.

hf2046 · 06-06-2012, 09:09 PM

Quote:

Originally Posted by mysql_connect

So my guess is that it doesn't like to be re-initialized and Slackware64 somehow (power management maybe?) does that and it fails.
So any thoughts on what to do from here? Are there any magic rituals that I can perform or I take it to OCZ support and return the drive?

Hopefully you've already contacted OCZ either through the support forums or directly about this. They need to know the problems you're having in order for them to fix it for you and (potentially) other users.

SSDs aren't plug and play like traditional rotational media. They have their quirks. I had random lockups with my Vertex 3 on Slack64 before the 2.15 firmware finally solved it. For a while I needed to downgrade the firmware and stick with an older BIOS to have a stable machine. If that's anathema to you, then I suggest returning the drive and save yourself some headaches. That would probably send a better message to OCZ: make sure your product is right before you ship it out.

mysql_connect · 06-07-2012, 12:55 AM

@ponce I plugged the SSD alone into the internal bay of the laptop (no optical, no caddy, only the SSD) and it did the same thing, worked with Ubuntu until the next restart.
@hf2046 I duplicated this thread on the OCZ forums and I'm waiting for them to respond, it's really frustrating because when it runs, Ubuntu from SSD is darn fast

.

Thank you all for your answers, I'll keep you posted on this.